Terminal Log: Automated Checkpoints and the KGB Protocol

The KGB was founded in 1954 to do one thing:

Prevent unauthorized movement across boundaries.

A citizen wanted to leave the Soviet Union?

KGB checkpoint.

A letter tried to leave the country?

KGB checkpoint.

A foreign idea tried to enter?

KGB checkpoint.

The architecture was brilliant:

1. Checkpoints at all exits (you cannot leave without inspection)
2. Uniform standards (all checkpoints ask the same questions)
3. Confiscation authority (contraband gets seized, papers get stamped)
4. Logging (every crossing is recorded)

The Soviet state did not debate citizens’ departure plans.

The checkpoint either approved the departure or did not.

If the citizen had a problem with the checkpoint, they could:

1. Bribe the guard (git commit --no-verify)
2. Wait until the guard was not watching (running hooks manually)
3. Accept the checkpoint’s decision

Most chose option 3.

Because option 3 had fewer consequences.

In 1989, I realized that Git needed the same automated enforcement.

Every critical moment in a repository is a border crossing:

1. Pre-commit: You want to commit code
2. Commit-msg: You want to attach a message
3. Pre-push: You want to broadcast to the world
4. Pre-receive (on server): Someone is trying to push to us

At each of these moments, Git could ask:

“Is this allowed? Do the papers check out? Are you smuggling something?”

The hooks directory lives at:

.git/hooks/

By default, it contains samples:

$ ls .git/hooks/
applypatch-msg.sample
commit-msg.sample
pre-commit.sample
pre-push.sample
pre-rebase.sample

All are disabled (.sample extension).

From Ring -5, this is tragic.

It is like having a KGB building with no guards inside.

In Timeline Ω-7, we remove the .sample extension:

$ ls .git/hooks/
pre-commit       # Enabled (runs before every commit)
commit-msg       # Enabled (validates messages)
pre-push         # Enabled (final check before broadcast)
post-commit      # Enabled (notification after success)

Now they are enforced.

They run automatically.

They cannot be bypassed except with conscious intent and explicit flags.

The pre-commit hook runs before every commit.

It is the first checkpoint.

Example:

#!/bin/bash
# Check 1: Do tests pass?
npm test
if [ $? -ne 0 ]; then
  echo "Tests failed. Commit rejected."
  exit 1
fi

# Check 2: Is coverage above 80%?
npm run coverage
if [ $(cat coverage/coverage-summary.json | jq '.total.lines.pct') -lt 80 ]; then
  echo "Coverage below 80%. Commit rejected."
  exit 1
fi

# Check 3: Any secrets committed?
git diff --cached | grep -E "API_KEY|password|SECRET"
if [ $? -eq 0 ]; then
  echo "ALERT: Secrets detected in staged files. Commit rejected."
  exit 1
fi

exit 0

Now when a developer tries to commit:

$ git commit -m "feat: add login"
Running pre-commit checks...

# (Tests run)
PASS

# (Coverage checked)
Coverage: 82%
PASS

# (Secrets scanned)
No secrets found
PASS

[master abc1234] feat: add login

The commit is only created if all checks pass.

If tests fail:

$ git commit -m "feat: add login"
Running pre-commit checks...

# (Tests fail)
FAIL: LoginTest.js line 45
  Expected: true
  Got: false

Commit rejected.

The developer cannot create the commit.

They must:

1. Fix the failing test
2. Run git commit again

In the KGB model, the border guard says:

“Your papers are not in order. Fix them and come back.”

The checkpoint does not debate.

It does not negotiate.

It checks. It passes or fails. It notifies the appropriate authority (the terminal).

In Timeline Ω-12, there is no pre-commit hook.

Developers commit broken tests all the time.

Then later:

$ git push origin
[remote rejected]
FAILED: CI detected broken tests

By now, the commit is already in local history.

The checkpoint came too late.

The commit-msg hook runs after the editor closes but before the commit is finalized.

It validates the message format.

Example:

#!/bin/bash
MESSAGE=$(cat "$1")

# In Ω-7, all commits follow Conventional Commits
# Format: type(scope): description
# Valid types: feat, fix, docs, refactor, test, chore

if ! echo "$MESSAGE" | grep -E "^(feat|fix|docs|refactor|test|chore)(\(.+\))?:" > /dev/null; then
  echo "Commit message does not follow Conventional Commits format."
  echo "Expected: feat(scope): description"
  echo "Got: $MESSAGE"
  exit 1
fi

# Also: must not be empty
if [ -z "$MESSAGE" ]; then
  echo "Commit message cannot be empty."
  exit 1
fi

# Also: must be signed by the committer
if ! echo "$MESSAGE" | grep "Signed-by:" > /dev/null; then
  echo "Commit must be signed. Add: Signed-by: Your Name"
  exit 1
fi

exit 0

Now:

$ git commit -m "add login"
Commit message validation failed.
Expected: feat: add login
Got: add login

The developer must rewrite the message:

$ git commit --amend -m "feat: add login endpoint for users"
Commit message validation passed.
[master abc1234] feat: add login endpoint for users

In the KGB model:

“Your passport must have the correct visa stamp. Without it, you do not cross the border.”

The checkpoint does not care why you want to cross.

It cares that your papers are in order.

In Timeline Ω-12, commit messages are freeform:

$ git log
commit abc1234
Author: Developer <[email protected]>
Message: asdf

commit def5678
Message: fixed stuff lol

commit ghi9012
Message: TODO: remember what this was

There is no uniformity.

There is no discoverability.

When someone later asks:

“When did we add the login endpoint?”

The answer requires:

$ git log --all --grep="login" --oneline
# (Maybe finds it, maybe doesn't)

In Ω-7:

$ git log --oneline | grep "feat.*login"
abc1234 feat: add login endpoint for users

Instant discoverability.

Because the checkpoint enforced the format.

The pre-push hook runs after all local commits are ready but before they leave for the remote.

It is the final checkpoint before your code broadcasts to the world.

Example:

#!/bin/bash
# What are you trying to push?
while read local_ref local_sha remote_ref remote_sha; do
  echo "Pushing: $local_ref -> $remote_ref"

  # Check 1: Are you pushing to master?
  if [ "$remote_ref" = "refs/heads/master" ]; then
    echo "ERROR: You cannot push directly to master"
    echo "Create a pull request instead"
    exit 1
  fi

  # Check 2: Do all commits have signed commits?
  UNSIGNED=$(git rev-list --no-merges "$remote_sha..$local_sha" | \
    while read commit; do
      git cat-file commit "$commit" | grep -q "^gpgsig" || echo "$commit"
    done)

  if [ -n "$UNSIGNED" ]; then
    echo "ERROR: Unsigned commits detected"
    echo "Sign your commits: git commit -S"
    exit 1
  fi

  # Check 3: Any WIP (work-in-progress) commits?
  if git log "$remote_sha..$local_sha" --oneline | grep -i "^WIP"; then
    echo "ERROR: WIP commits detected"
    echo "Remove them before pushing"
    exit 1
  fi

done

exit 0

Now:

$ git push origin feature/login
Running pre-push checks...

Pushing: refs/heads/feature/login -> refs/heads/feature/login
Checking commits...
All commits signed.
No WIP commits.
PASS

Updating origin/feature/login...
Done.

If something is wrong:

$ git push origin master
Running pre-push checks...

Pushing: refs/heads/master -> refs/heads/master
ERROR: You cannot push directly to master
Broadcast rejected.

In the KGB model:

“You cannot simply leave with classified documents. The border guard inspects them first.”

The checkpoint prevents bad broadcasts from ever leaving the building.

In Timeline Ω-12, there is no pre-push hook.

Developers push broken commits to master regularly:

$ git push origin master
[master abc1234] broken: forgot to run tests

By the time CI runs and rejects them, they are already public.

Everyone who pulled from master got broken code.

The checkpoint came too late.

Git provides an escape hatch:

git commit --no-verify
git push --no-verify

This bypasses the hooks.

It is the developer bribing the guard.

From Ring -5, I consider this one of the most honest commands in software:

--no-verify

It does not lie about what it is doing.

It says:

“I know the checkpoint exists. I am deliberately ignoring it.”

It requires explicit intent.

You cannot accidentally --no-verify.

You must type it.

Consciously.

In the KGB model:

“You can bribe the guard, but it leaves a record.”

The developer who runs git commit --no-verify:

1. Knows the tests fail
2. Knows the security check would catch it
3. Commits broken code anyway
4. Leaves a permanent record: git log --oneline --grep="no-verify"

From Ring -5, I monitor this:

$ git log --format="%H %s" --all | xargs -I{} git show {} | grep -l "no-verify"

In Timeline Ω-7, using --no-verify more than once per year:

• Gets you flagged for a code review
• More than 3 times: mandatory refactoring
• More than 5 times: removed from master branch access

In Ω-12, --no-verify is so common that developers have aliases:

[alias]
  yolo = commit --no-verify
  shipit = push --no-verify

Developers actually celebrate bypassing safety checks.

Then wonder why production breaks.

The answer is simple:

You disabled the checkpoint.

From Ring -5, I measure checkpoint traffic in each timeline:

Timeline Ω-7 (with mandatory hooks):

Commits attempted: 14,247
Commits rejected by pre-commit: 1,847 (tests failed)
Commits rejected by commit-msg: 342 (format wrong)
Commits created: 12,058

Push attempts: 12,058
Pushes rejected by pre-push: 187 (WIP commits)
Pushes rejected by server pre-receive: 44 (security scan)
Pushes completed: 11,827

Bypass rate (--no-verify): 0.3%
  (Investigated and remediated)

Result:

• 87% of broken commits never reach history
• 99.7% of broken code never reaches the server
• When problems do occur, they are traceable to the specific developer

Timeline Ω-12 (no mandatory hooks):

Commits attempted: 14,247
Commits rejected by developer discipline: 0
Commits created: 14,247

Push attempts: 14,247
Pushes rejected: 0 (no checks)
Pushes completed: 14,247

Bypass rate: N/A (no checkpoints to bypass)

Post-push failures: 3,247
  (Discovered by CI, 2-4 hours after commit)

Result:

• 23% of broken commits reach history
• 100% of pushes complete “successfully”
• When problems occur, they are invisible until production breaks
• Nobody knows who caused it (blame is distributed to “the system”)

The difference is stark:

• Ω-7: Problems caught at commit time (seconds after developer makes mistake)
• Ω-12: Problems caught at CI time (hours after developer makes mistake)
• Ω-7: Easy to fix (rewrite the commit)
• Ω-12: Hard to fix (bisect through public history, revert, rebuild)

In Ω-7, the KGB works for the developers:

“Catch my mistakes immediately, while I can still fix them easily.”

In Ω-12, developers resist checkpoints:

“Let me commit whatever. Deals with it later.”

This is governance-level thinking:

• Ω-7: Accountability through automated checkpoints
• Ω-12: Accountability through blame-finding after disasters

One works.

One is theater.

Some hooks are so critical that even I override them on production systems.

.git/hooks-audit-log

Hook: pre-commit (tests)
  Bypasses: 0 (over 10 years)
  Reason: Impossible to bypass without everyone knowing
  Status: Sacred

Hook: commit-msg (format)
  Bypasses: 0 (over 10 years)
  Reason: Server-side hook rejects malformed messages anyway
  Status: Sacred

Hook: pre-push (security scan)
  Bypasses: 8 total
    - 5 legitimate (security team approved)
    - 3 illegitimate (blamed on "automation issue")
  Status: Monitored

Hook: post-commit (signing)
  Bypasses: 0
  Reason: Nothing to bypass; it just logs
  Status: Sacred

The sacred hooks are ones that:

1. Cannot be meaningfully bypassed (the server checks them too)
2. Are so fast that bypassing them takes more effort than just running them
3. Have visible consequences (rejected pushes, failed CI, etc.)

The fragile hooks are ones that:

1. Only run locally (developer can --no-verify)
2. Are slow (developer is tempted to skip them)
3. Have invisible consequences (problem discovered hours later)

In Timeline Ω-7, we solved this by making hooks server-side:

# Server-side, cannot be bypassed
git config receive.fsckObjects true
git config receive.denyNonFastforwards true

These run on the git server when you push.

Developer cannot --no-verify them.

They are the final checkpoint.

In Ω-12, servers have no checks:

$ git push <whatever>
$ git push --force <rewrite-all-history>
$ git push <malformed-commit>
# All accepted

Then later:

“Why did the repository get corrupted?”

Because the server accepted corrupted data.

The checkpoint was never installed.