braindump

Compaction quality

A compaction summary is the only deliberate artifact that survives. It is not the only thing that carries through — measured at the wall, roughly 168k tokens of residue survive a 1M-window compaction (system prompt, tools, recent turns; post ≈ 50,958 + 0.117 × pre, n=1,037) and the summary itself is ~3% of that. What the residue keeps is the recent end of the window. What has exactly one chance to survive is everything else: the reasoning, the files you read, the dead ends you ruled out, and above all the middle of a long session — summariser faithfulness is measured as U-shaped, strong at both ends and weakest in the middle (PoSum-Bench). So the summary is not a recap for a human. It is the input to a stranger who has to continue your work and who will confidently redo whatever you left out.

Write it as two tiers, not one. That single structural decision carries most of the value here, and the evidence for it is in references/evidence.md.

Running as a Gemini model? Read gemini.md in this directory first, then follow this file with the overrides it names. It turns the four Tier-1 sweeps into a counted ledger, adds a bound ledger that reads every stated maximum back off the written summary, and treats a scorer reporting no spans as an unverified class rather than a pass. Other models skip it.

The two tiers

Tier 1 — pinned. Reproduced verbatim, never compressed, placed first.

Four categories, and only these four. Keeping this tier short is as important as filling it: instruction-following degrades as instruction count rises — measured on Sonnet 4.6, follow-rate falls from 0.964 at one stacked instruction to 0.447 at twenty — so a bloated pinned tier defeats itself. Treat ~20 pinned items as the ceiling, and consolidate before exceeding it.

1. Standing constraints and prohibitions — every "always", "never", "don't", scope fence and boundary the user or the project set. Quote them word for word.
2. User corrections — every time the user rejected, redirected or corrected you. Quoted, with what it supersedes. A correction from a peer agent or subagent counts: in a fleet run it is often the most consequential one in the window.
3. Rejected approaches and dead ends, each with its reason — "tried X, failed because Y, don't retry unless Z". Sweep for two kinds, because they live in different parts of the transcript and a single undifferentiated sweep returns only whichever is nearer:
   • Method dead ends — how to work. A verification command that lies, a shell quoting trap, a tool invoked the wrong way, a check that reads green when it is not.
   • Product dead ends — what to build. A rejected architecture, a library that emits the wrong artifact, a coercion that corrupts stored data, a route deliberately not added.
4. Exact identifiers — absolute paths, commands, error strings, failing test names, IDs, ports, versions, flags. The tokens a successor cannot re-derive or guess.