/sota-close

description: End-of-session closure pass — retract what proved wrong and correct it everywhere it reached, hand off open items where the next session will trip over them, update the docs this session made false, re-derive every number from its source, and commit the evidence. Run it at the END of a working session.

End-of-session closure pass. Work through these in order and report each one.

**Before step 1: your own summary is not a source.** By this point in a session the context has usually been compacted at least once, so most of what you would "recall" is your own earlier prose *about* the work rather than the work. Re-reading it re-runs the reasoning that produced it, which is the weakest check available. Every step below is executed against artifacts — `git diff`, `git log`, the file on disk, the command run again — never against recollection. A verbatim file quoted into context earlier is not primary either: it may predate an edit made since. Re-read the path.

**The order is load-bearing.** Steps 2–6 all *write*. Anything step 1 fails to catch gets propagated by them into a doc, a commit message, a memory file, or a hand-off — where the next session will read it as established.

0. Load the shell rules before the first sweep

Steps 1, 2 and 4 are mostly ad-hoc commands whose result you will report: `git log -S`, a grep for a wrong claim's copies, a count, a PR listing. Invoke the `sota-shell-scripting` skill and read its `rules/06` (ad-hoc commands) and `rules/09` (listers) **now**. The parenthesised citations below are pointers into those files, not substitutes for them: a citation loads nothing. Field-reported 2026-10-11 and seen again 2026-10-12: a closure pass that cited rules/06 throughout never loaded it.

1. Retract first

List every claim you made this session that later proved wrong, unverified, or was overtaken by something you found afterwards. Include the ones only you noticed. **If there are none, say so explicitly** — that is a valid answer, but it is also a claim, so it means you looked.

"What did I get wrong" is a bad recall query. Sweep the candidate shapes instead:

• anything you asserted *before* running the command that later confirmed it;
• any number produced by arithmetic on a remembered number rather than by counting;
• any absence — "nothing else uses this", "that isn't covered" — backed by a single search;
• any absence whose query used the **tracker's** name for a thing (a trigger row's or backlog

line's wording) rather than the data's own spelling — field-reported 2026-10-24: `r_terse` in the tracker, `terse` in the data, and "the first live run" committed over an earlier one;

• anything the user corrected you on, including corrections you accepted in passing;
• any "should work", "that's fixed", "done" not followed by output.

**Then find where the claim went.** A wrong claim does not stay where you said it. It gets written into a commit message, a doc sentence, a code comment, a ledger row, a memory file, a PR description. Grep its distinctive words across the tree *and* across this session's commits (`git log -S '<phrase>'`), **and across the agent's memory directory**, which lives outside the repository (e.g. `~/.claude/projects/<slug>/memory/`), so neither search reaches it. A stale line there is an instruction the next session follows (field-reported 2026-10-22: a memory index line still called a negative result final after the session had overturned it). **That directory is often a symlink**, and macOS's BSD `grep -r` given a symlink with no trailing slash reads nothing and exits 1, the same as a clean result. Search `<dir>/` (trailing slash), `<dir>/*.md` or `find -L`, with a control word you know is there (field-reported 2026-10-22: claim and control both 0 until the slash was added; `sota-shell-scripting` rules/06 §2). Correcting the copy you remember and leaving three behind is worse than not correcting at all: the retraction makes the survivors look reviewed.

**And a decision the user made on it.** No grep finds this copy, and it has the largest blast radius. A choice made on a retracted premise is void: restate the corrected premise and ask again before acting on it. Approval in one context does not extend to the next (field-reported 2026-10-22: a VM resize approved on a misread OOM kill, which was in fact a SIGTERM from another session's restart, was re-asked and re-chosen on the corrected premise).

**Delete or supersede — decide per line, this is where the pass goes wrong.**

• **Delete** when the line states *current state*: a README sentence, a rule's imperative, a

count, a capability claim. A caveat beside a wrong line leaves both readings live and the reader picks one. Prefer deleting a wrong line to annotating it.

• **Supersede** — keep the original, add the correction and its date beside it — when the line

is a *record*: a changelog entry, a measurement, a ledger verdict, a dated claim. Editing a record rewrites history and destroys the trail showing the number moved.

Cite the primary source for each correction: the command re-run and its output, the file at the line, the doc or advisory fetched now. "I realised it was wrong" is not a source.

2. Record open items where a new session will trip over them

A backlog row is not a hand-off. The next session reads what its harness puts in front of it: the worklist or resume file, the branch it lands on, `CLAUDE.md`/`AGENTS.md`, an open PR, a failing check. An item filed anywhere else is a note to yourself.

Per open item, one line with three fields: **what it is · where it now lives · what a future session would have to read to find it.** If the third answer is "search the repo", it is not recorded. Prefer the artifact the next session is already forced to read — a failing gate, a draft PR, a TODO at the line it applies to, the branch name itself.

**Re-test the deferral triggers your own work fired.** A deferral row names a condition ("re-run when a