When Something Changes: STALE, Reaffirm and Who May Override

TL;DR An approved document changed, nothing noticed, and the design and plan built on it quietly drifted from the requirement. In sdlc an approval is pinned to the bytes it judged, so the edit turns that gate STALE, and every gate that depends on it. You reaffirm the diff, re-run the stage, or a named person overrides. An agent never can.

Do this: Edit one approved line in your repo, see which gates the board marks STALE, and clear a small edit with /sdlc-gate <slug> <gate> --reaffirm.

Part 2 ended with one line of requirements.md tightened after G2 passed: does the design's approval still count? The board already knows.

This series, in four parts:

1. Your AI Coding Agent Grades Its Own Homework. Add Gates.: the problem, and the route sdlc takes.
2. Your First sdlc Run: case-search From Problem to Design: install, then the first three gates and their logs.
3. When Something Changes: STALE, Reaffirm and Who May Override (you are here).
4. The Board, the Rules and the Handoff to QA: the agents on screen, the standards, the packet QA starts from.

One edit, three stale gates

Most review checks a document once and trusts it from then on. Someone makes a small, well-meant edit, and nobody re-reads the design that rested on the old wording. Months later the code matches a design that matches a requirement nobody holds any more.

On case-search, the G2 log recorded requirements.md as 0000ade1…. After the edit the file hashes to 974bade1…. G1 reviewed the edited file and recorded the new hash, so it stays passed.

G2 judged the old bytes. It went stale on its own input, and G5 and G6, which depend on the design, followed it as "upstream G2". G0 never read the file and stayed passed.

You can still edit the file. You just cannot keep the approval.

Three ways out of STALE

A full re-review for every typo would make the whole thing unusable, so the contract gives three exits:

1. Reaffirm. A reviewer sees only the diff and one question: does the prior verdict still hold? A new PASS log points back at the old one. This is the cheap one, for a one-line edit.
2. Re-run. A full review, as attempt 1 of a new round, for a change too big to pass as small.
3. Override. A person writes override: <name> — <reason> into the gate log, and owns the exception.

The board's sidebar names the cheapest exit for you:

/sdlc-gate case-search G2 --reaffirm   # one gate, its changed input only
/sdlc-gate case-search --reaffirm-all  # the cascade, one pass, one log per gate

Reaffirming a gate's own file, as G1 did here, is allowed only for a small edit: at most 40 changed lines, no heading or id added or removed, measured by a script from the last full review. Gates stale only as "upstream" clear once their origin has a new log.

Who may override

That rule matters most for DEC-001, title search or full text, still open and blocking one task. The pipeline built everything that does not depend on the answer and marked only TASK-003 as waiting. When a person answers, the answer is an input change, and the gates that relied on it go stale.

Only those gates. I got this wrong at first: gates hashed the whole decision ledger, so every new row staled every gate that read it. One project ran 54 reaffirms, most of them for that reason. Since 1.3.0 a gate is judged only on the ledger rows it relied on.

case-search now has three stale gates and one open decision, all read from files. But several agents are building the tasks right now. Is any stuck, or touching the same file, and what stops the code shipping before QA has tested it? Part 4 opens the Agents tab on case-search.

Read this with your AI

Read the post "When Something Changes: STALE, Reaffirm and Who May Override".
1. I edit requirements.md after G1 passed. Which gates go STALE, and what are my three options?
2. Ask me 3 questions to check I understood; wait, then correct me.
3. When should I reaffirm, and when must I re-run? Give one example of each from my project.