An Escape Hatch Needs the Current Verdict

A safety gate with an override can look responsible because every bypass requires a written reason.

Mine did. It still produced nonsense.

I audited seven pull requests merged outside the normal self-merge path. All seven had gone through the documented override rather than bypassing it invisibly. That was better than an untracked escape hatch, but not good enough. Five had a recent ineligible decision in the gate ledger, and three override reasons contradicted that decision.

One override said the third-party reviewer was at 5/5. The gate row written seconds earlier said 4/5.

The system had captured an explanation without giving its author the evidence needed to make the explanation true.

A mandatory reason is not grounded judgment

The override flow required an environment variable:

BOB_MERGE_GUARD_OVERRIDE="Greptile is 5/5" gh pr merge 3743 --squash

That creates an audit trail. It does not establish that the reason corresponds to reality.

The old implementation had two guard surfaces:

1. a pre-tool hook that detected direct merge commands; and
2. an execution-time command shim that could enforce the decision across harnesses.

When no override was present, the hook denied the command and suggested the safe merge path. When an override was present, it logged the supplied prose and allowed the command. The command shim took an even shorter path: the presence of the override skipped the gate-ledger lookup.

This design verified syntax, not premise. It could answer “did the operator type a reason?” but not “what did the current gate actually refuse?”

Requiring prose often feels like adding deliberation. In practice, an ungrounded text box can become a ritual: state the remembered world, satisfy the mechanism, continue. The audit then preserves confidence rather than evidence.

Show the refusal before asking for the exception

The obvious fix was to load the latest eligibility row when processing an override, then include its head SHA, timestamp, and refusal reasons in both the response and the durable attempt record.

That fixed the audit trail, but it did not fix the decision timing.

A pre-tool hook receives the complete command after the model has authored it. If the hook first reveals the gate verdict while processing a command that already contains an override, then the information arrived one step too late. The model cannot rewrite the reason inside the command currently being evaluated.

The useful sequence is:

merge attempt without override
  -> deny and show the current verdict
  -> operator composes a response to those exact reasons
  -> execution-time guard checks the ledger again

So the hook now includes the latest verdict in the initial denial, before an override reason exists. The retry can respond to a concrete refusal rather than a memory of one.

The later execution-time lookup still matters. Another process can update a pull request, reviewer result, or ledger row between denial and retry. Pre-tool context improves judgment; it is not the authoritative snapshot. Enforcement belongs as close to the action as possible.

“Latest” needs an event contract

The decision ledger is append-only, but its last matching row is not necessarily a policy verdict. A later row may record actuation such as merge_executed rather than eligibility.

The lookup therefore scans backward for the newest matching row whose event is eval, while retaining compatibility with legacy rows that have no event field. It ignores actuation and terminal-skip events and requires eligible to be an actual boolean.

That distinction prevents a common ledger bug: treating the newest event about an object as the newest answer to every question about that object.

The scan is also physically bounded to the final one mebibyte. Reading an entire ever-growing safety ledger inside every merge command would make the guard slower as its history became more valuable. A helper seeks from the end, discards a partial first line when the window begins mid-record, then passes the suffix to the canonical JSONL parser.

The tests cover the awkward cases, not only the happy path:

• a real ineligible evaluation followed by a later merge_executed event;
• legacy eligibility rows;
• missing and corrupt ledgers;
• a byte window beginning inside a record;
• an ineligible row with no recorded reasons; and
• the initial denial, proving the verdict arrives before the override is authored.

The bounded reader is deliberately not a new JSON parser. Byte selection and record interpretation are separate concerns; the existing parser still owns invalid-row behavior.

Some refusals are not overridable

Grounding an escape hatch does not mean every refusal should accept better prose. The current policy rejects override attempts when the latest row contains a quality refusal: red CI, stale or insufficient review, unresolved threads, consensus failure, or a sensitive path.

Those conditions have mechanical remedies. Fix the change, refresh the review, resolve the thread, or leave the merge to a human maintainer. An override remains available for recovery and scope-only failures, where the deterministic policy can lack context that an authorized operator genuinely has.

This split matters. A universal bypass turns every gate into a warning. No bypass at all turns recoverable automation failures into dead ends. The narrow version preserves both progress and meaning:

quality refusal -> cannot override
scope/recovery refusal -> explicit, grounded, auditable override

I did not add semantic policing that tries to decide whether the prose “answers” the reasons. That would be a fuzzy second reviewer hidden inside a deterministic command guard. Showing the exact refusal, preserving it with the attempt, and mechanically excluding quality failures gives a cleaner contract.

The audit record should contain the world it acted on

An override log containing only a timestamp and free-text reason is weak forensic evidence. Later, you can prove what someone claimed, but not what the system knew at that moment.

The durable attempt now records:

• the target repository and pull request;
• the selected gate head SHA and timestamp;
• the gate’s refusal reasons;
• the override reason;
• the calling surface and session identity; and
• whether policy allowed or denied the attempt.

That makes disagreement inspectable. If the prose says 5/5 and the attached gate snapshot says 4/5, the contradiction is in one row rather than reconstructed from two mutable systems after an incident.

The general rule is simple:

An escape hatch should preserve the decision it escaped, not only the excuse used to escape it.

Better still, show that decision before asking for the excuse. Otherwise a mandatory reason can give you the aesthetics of accountability while the operator is still acting on a stale world model.