Setback log

The one rule

Every incident must end in one of exactly three closures. Prose is not a closure. An incident that concludes "we should be careful about X" changes nothing and will recur.

Prefer GUARD. A generator that no longer emits a bad example row beats any number of warnings about bad example rows. Reach for RULE when the mistake is a judgment call rather than a mechanism. Use ACCEPTED sparingly and never as a synonym for "ran out of time" — say that instead, and leave it open.

Where it goes

• Project incidents → .agentic/incidents/
• Framework incidents → this repo's docs/incidents/

One file per incident, plus a row in that directory's INDEX.md.

Required content

Symptom — with the actual output, pasted. Not a description of the output. The exact error string is usually the diagnosis, and paraphrasing destroys it.

Cause — what was really happening. If you could not determine it, say so explicitly rather than offering a plausible guess; a wrong cause produces a wrong guard.

What was NOT at fault — name the components you cleared. This matters more than it sounds: the first reading of an incident routinely blames a model or a tool that turned out to be answering faithfully, and "replace the model" is an expensive wrong repair.

Closure — GUARD, RULE, or ACCEPTED, naming the exact file changed.

Triggers — when this should be recalled. Use only these:

preflight · dispatch · verify · git · search · write · shell · setup · publish

A closed set keeps setback-check reliable. If nothing fits, the incident is probably too vague to be actionable — sharpen it.

The INDEX row

| SB-0004 | Dispatched brief arrived as a copy of a probe | dispatch, verify | RULE convene: echo-token guard |

The last column is the point. A row with no closure is an open incident, and open incidents are the backlog.

What makes a good entry

Write for someone hitting this at 2am with no context. Concretely:

• Lead with what they will see, since that is what they can search for.
• Say what looked fine and was not — most of these fail silently, and the reader's problem is that everything appears to be working.
• If a check passed and meant nothing, say which check. That pattern recurs.

What does not belong here

A task that was merely hard. A decision that turned out suboptimal — that is a Decision Record, superseded. A one-off provider outage with no lesson. Logging those trains everyone to skim the log, which disables the whole mechanism.