Add an emergency protocol: suspend verification-for-certainty when a human declares an emergency

[twistedmelonman]

The problem

Every protocol in ~/.claude/CLAUDE.md is tuned for correctness under normal conditions, and correctness is bought with delay. There is currently no protocol for the case where delay is the expensive thing.

When Andrew says something is an emergency, the agent today still:

• runs code-reviewer and adversarial-reviewer on every commit (Protocol 4), minutes each
• runs the pre-push full-diff review and Semgrep before the push goes out
• runs the full test suite before pushing
• calls advisor() before "substantive work" and again before declaring done
• builds known-bad controls to prove a check works before trusting its result
• re-measures anything it already measured once, on the Verification Discipline rule

Each of those is individually correct and collectively adds up to many minutes of wall-clock while a site is down. Worse, the failure mode is invisible to the agent: it experiences itself as being thorough, which is exactly the behavior the rest of CLAUDE.md rewards.

Andrew's own words for what this feels like from the outside: "DON'T SPIN YOUR WHEELS ON TESTS AND VERIFYING AND THINKING."

What triggers it

An explicit human declaration — "this is an emergency", "EMERGENCY", "prod is down", "drop everything". Never agent-inferred. The agent does not get to decide that something is urgent enough to lower its own standards; that is the whole reason the trigger is a human utterance.

The declaration stays in force until Andrew says the emergency is over. It does not silently expire mid-incident.

The general rule

Andrew's framing, which is broader and better than any checklist:

Skip any regular procedure that demands "go back and look again" or "think about it for a while."

That is the test to apply to a step that is not enumerated below. If the step exists to make the agent slower and more certain, it is suspended. If it exists to stop the agent from destroying something, it stays.

Suspended during an emergency

• Protocol 4 local review. No code-reviewer, no adversarial-reviewer at commit time. No pre-push full-diff review dry-run.
• Full test suite before push. See the open question below — the repo pre-push hook runs it automatically, and the only current override is --no-verify, which is hook-blocked and human-only by design.
• advisor() calls. Both the before-substantive-work call and the before-declaring-done call.
• Known-bad controls. Trust the check; do not first prove the check works.
• Verification Discipline re-measurement. Batch-of-3 verification, "resolve the thing don't match its label", re-checking a prior claim before relaying it. Act on the first reading.
• Anything else matching the general rule above.

Never suspended

These cost seconds, not minutes, and each one exists to prevent an unrecoverable outcome rather than an incorrect one:

• Protocol 1 — never commit to main. Always branch. Costs a second and preserves the ability to revert, which matters more during an incident, not less.
• Merge-lock. Still human-only, still required. It is the only mechanism preventing an agent from merging unilaterally, and an emergency is precisely when a wrong merge is most costly. (Andrew explicitly left this one in place when asked.)
• Destructive-operation confirmation. rm -rf, force-push, history rewrite, schema changes, data deletion still stop and ask. An emergency is a reason to move fast, not a reason to be unable to undo.
• The after-action report. See below.

Two obligations that must not become new wheel-spinning

Andrew's constraint, verbatim: "this must happen either in a forked, not dependent subagent, or be deferred."

This is the subtle part. Both obligations below are things the agent must do — but doing them inline would reintroduce exactly the delay the protocol exists to remove.

1. After-action report. A plain list of every shortcut taken and every claim that went unverified, so Andrew knows what to re-check once the fire is out.
2. Follow-up debt issue. Filed so the skipped steps do not silently become permanent.

Neither may block the fix. Each is either:

• dispatched to a forked subagent that the main line does not wait on, or
• deferred until after the emergency is declared over.

The main thread's job during an emergency is the fix and nothing else.

Open question — the --no-verify collision

"Skip the full test suite before push" cannot currently be honored. Repo pre-push hooks (dotfiles' .project-hooks/pre-push, for one) run the suite as part of the hook, and the only way past a git hook is --no-verify, which is:

• forbidden by CLAUDE.md's Git Rules,
• blocked by a PreToolUse hook,
• human-only by deliberate design.

So this needs a real decision rather than a line in a doc:

• (a) An emergency env var the pre-push hook itself honors — e.g. EMERGENCY=1 skips the suite but still runs the secret-leak scan. Keeps --no-verify forbidden and keeps the bypass auditable in the hook's own logs.
• (b) Andrew runs the push himself during emergencies, the way STRICT_PREPUSH=0 is handled today.
• (c) Accept the suite runtime as the floor and drop this item from the suspended list.

(a) seems right — it makes the bypass explicit, scoped, and loggable instead of blanket — but it is a change to enforcement infrastructure and should not be decided in passing.

Where this lands

~/.claude/CLAUDE.md as a new protocol, with the trigger phrase discoverable from the Quick Access block at the top. It has to be findable in the first seconds of an incident; a protocol nobody can locate mid-emergency is not a protocol.

https://claude.ai/code/session_01TkReZXv8XkcWNbcaiWfcvg