--- title: "When Something Changes: STALE, Reaffirm and Who May Override" author: "Harry" published: 2026-10-31T04:14:13.433Z updated: 2026-10-31T05:05:44.515Z category: "AI Agents: SDLC & STLC" tags: ["sdlc"] canonical: "https://fxblog.dev/posts/ai-agent-workflow-stale-reaffirm-override" --- # When Something Changes: STALE, Reaffirm and Who May Override ## Key takeaways - A gate log stores the SHA-256 of every file it judged, so an edit to an approved file turns that gate STALE. - Staleness follows the dependency graph: a stale design reaches the plan but leaves unrelated gates alone. - Reaffirm gives a reviewer only the diff and one question, whether the prior verdict still holds; a gate that is stale only by upstream clears when its origin has a new log. - A gate's own artifact may be reaffirmed only for an edit of at most 40 lines with no heading or id change. - Only a named person may override a gate or accept a default for an open decision; an agent never can. > **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 --reaffirm`. [Part 2](02-how-a-gate-works.md) 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. ![The sdlc board for case-search: G0 and G1 passed, G2 design stale with a ring around it, G5 and G6 stale behind it, G7 authoring](https://fxblog.dev/media/01a18fc9-1a7b-7639-9cff-dbcd738830c0/1600) _One edit, three stale gates, read from the log files_ 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: — ` into the gate log, and owns the exception. ![After the edit to case-search: --reaffirm shows a reviewer only the diff; if the verdict holds, a new PASS; if not, G2 re-runs; only a named person may override, never an agent](https://fxblog.dev/media/01a18fc9-21d9-727b-9430-496e9afd2237/1600) _Cheap when the change is small, full when it is not, and a person when neither fits_ The board's sidebar names the cheapest exit for you: ![The sdlc sidebar for case-search: G2 to G6 stale because an input changed after review, and What next suggesting /sdlc-gate case-search G2 --reaffirm](https://fxblog.dev/media/01a18fc9-2958-7461-b1ba-abce2ad859a4/1600) _Copy the command, paste it into Claude Code_ ```text /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 > **Danger** > > An agent that writes an override for itself breaks the contract (`§4.5`). Only a named person may override a gate, or accept an agent's default for an open decision. 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. > **Note** > > Try it in your own repo: edit one approved line, and the board names every gate that no longer holds. 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 ```text 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. ``` > **Success** > > A stale gate clears by reaffirm, re-run or a named person. Next: **The Board, the Rules and the Handoff to QA**. ## FAQ ### What happens if I edit an approved document? Its hash no longer matches the gate log, so that gate and every gate depending on it go STALE. A small edit can be reaffirmed from its diff; a large one re-runs the stage. ### Can the agent override a failed or stale gate? No. An override is written in the log with a person's name and a reason, and an agent writing one for itself breaks the contract. ### Does an open decision stop the pipeline? No. The stage builds everything that does not depend on the answer and marks only the dependent work as blocked by the DEC id.