A runbook a junior can execute lives in the repo
Layer 4 is why this lesson exists. The harness can edit files, run commands, and ship a dispatch change. Anything that can change the world needs a way to undo it — written down next to the harness, not in a wiki tab someone has to interpret while the batch is still failing.
Run the editor. Two artifacts, same nickname. The wiki line is a page. The dict is a runbook: a signal to read, a threshold that means rollback, a named human if the decision needs one, and a path in the repo for the record.
That is the whole job. Detect. Decide rollback versus continue. Name a human if you cannot execute the decision alone. Write the record back. A junior on the on-call seat should be able to follow it from the checkout without inventing a process.
This is the ops role's failure path — one seat, one workflow. Not a company-wide rebuild.
What this lesson is NOT
- Not a war story. The numbers are quiet on purpose.
- Not a page that says "stay calm" and then stops.
- Not a hiring pitch.
What it IS: the failure path as data, the same way lesson 02 made the happy path a spec. Rollback is the point. If the runbook cannot tell a junior when to undo the last ship, it is still a wiki page.
What you'll build
execute_runbook(signals, runbook) — read the signal,
return rollback / continue / escalate, attach the named
human only when escalate fires, and produce the writeback
record a later checkout can grep.
The runbook you write is the one you would want sitting
in incidents/ the next time the nightly batch misses
its threshold.