[hhff]

Builds on #111 (merge that first). Monitoring, part 5 of 5: the one place monitoring writes to production. It makes reviewed remediations, on the ladder, with a rollback across a migration as a one-way door.

What

• remediations. An owner setting, governance-edit. Each entry names a reviewed script under project/remediations/, pinned by its blob sha, with its params, the access it uses (uses CLIs, credentials), its undo and valid_minutes (60).

• production-remediation, a ladder class: start 1, ceiling 2. No standing rule covers it, and its default can't fire before its deadline, so the owner always sees a remediation coming, or it runs at its default after an outage's --deadline 15m.

• The answer is bound to what it approves.

  • The question and the decision each name exactly one remediation:<action>; a rollback also names release:<version>.
  • decide refuses an answer about another remediation or release, and an answer that isn't the recommendation.
  • An act in the class only comes from remediate.

• remediate <action> --decision <d-…> [--to <version>]:

  • runs main's blob, only if it is still the pinned one
  • runs once per decision, with a lock while it runs, and within valid_minutes of the answer
  • redacts and scrubs the output and frames it as untrusted
  • logs the act and observes remediation or remediation-failed

  A writing script isn't killed for printing too much, and a timeout says its effect is unknown and names the undo.

• A rollback across a production-migration act since its target release first went out (by a deploy a monitor's poll observed, at the deploy's own time) is a one-way door. It needs the owner's own answer, never from chat, to an ask --kind one-way-door with no default.

• Docs. supervisor.md gets the steps, the constitution gets the class and its row, and quality.md gets the remediation script checklist.

Why

• Remediations stay narrow. The owner chose reversible remediations on the ladder with a ceiling of 2.
• Rollbacks across migrations ask the owner. A rollback across a migration can lose data whatever the script says, so it is the owner's call.
• A pinned sha covers the script body. It keeps a later PR from changing what a listed remediation does without the owner's answer.

Tests

The remediation subtest covers:

• the refusals: no decision, a forged act, rung 1, an unknown action, two actions, no --blocks, an answer about another action, a "no" answer, and --to on a restart
• a run with its params and credential, redacted, logged once and refused twice
• a failing script
• a changed script on main refused
• rollback refusals: no target, the wrong target, an unseen release, an ordinary question across a migration, and a chat answer to a one-way door
• the owner's own one-way-door answer running it

Suite: everything passes except the tmux session test, which fails on main in this environment too.

---

Generated by Claude Code

[hhff]

Upstream loop: merged #111's update, adversarial review of this PR's diff

I merged monitoring-verify in as a merge commit. The conflicts were in:

• authorise: kept main's owner_rules and this PR's no-rule-for-production-remediation;
• citeTargets: kept both link and remediate;
• docs: remediations added to the governance-edit lists;
• tests.

What I checked. Remediate is the PR that acts on production, so I checked whether it can act beyond what the owner approved.

Findings

1. Blocker, fixed. A hand-written decision could run any listed remediation, even after the owner said no. The remediation-specific checks ran only in decide, and a decision line is the supervisor's own. remediate now re-checks the question the decision rests on:

   • The authority is answer or default only, never a standing rule or a rung.
   • The question is production-remediation (or the one-way door for a rollback).
   • Its --blocks name this remediation:<action>, and the same release: as the decision.
   • It was answered with its recommendation, or its default was applied at or after its deadline.

   Test: a decision written by hand on the owner's "no" is refused, "not its recommendation".

2. Should-fix, fixed. A default could fire before its deadline. A hand-written status: defaulted line before the deadline is refused at run time.

3. Should-fix, fixed. The script pin accepted a 7-character prefix. sha must now be the full 40-character blob id, compared exactly. A prefix could have been brute-forced by a supervisor-merged chore.

4. Should-fix, fixed by 1. A standing-rule decision is refused at run time.

5. Should-fix, partly fixed. A forged deploy line could dodge the rollback's one-way door.

   • Fixed: migrationsSince counts only the monitors' own lines.
   • Still open: a line the supervisor writes by hand into its own file looks the same. Failing closed when a release can't be anchored to a tag or commit would close it. Not done here.

6. Needs the owner's decision. A chat-relayed answer can approve a restart, scale or rollback that isn't a one-way door. production-remediation is a ladder class, so answer --from-chat accepts it. If "the owner always sees each one" is meant literally, remediate should require channel !== 'chat', or the class should join the chat-reserved set. I left this unchanged because it's a trust-model choice.

7. Nit, deferred. The last 600 characters of the script's output go into the observation's detail. They are redacted and scrubbed but not framed as untrusted.

8. Nit. The run-once check counts any act carrying the decision. A forged act can only block a run, not cause one.

--deadline (#110 now limits it) is allowed for production-remediation, as this PR's docs use it.

Tests: the full test/kit.test.mjs on Node 24.14.1: 134 of 135 passed. The one failure was main's G1 golden test, which fails on #110's ready line. I fixed that in #110, merged it up, and re-ran G1, which passes. Incidents and remediation pass.