Drew T
2.1 KiB
L2 — lever-removal-is-a-tracked-series
id: L2 · group: - · status: active · tags: legacy,memory · origin: legacy memory lever-removal-is-a-tracked-series.md · added: 2026-09-29
Drew (2026-09-09, mid-Phase-36): the pins and compiler hints are not just work to finish — their count over time is a
deliverable. Keep docs/levers.md current after every task that changes the count, with
tools/lever_progress.py --snapshot "<task>" (appends a milestone row to docs/lever-progress.tsv and re-renders the
document's generated block; --check refuses a stale series). Mirror the story-relevant numbers into
phase-ends/CURRENT_PHASE.md as the phase goes, so the retrospective is built from the record and not from memory.
Four audiences, all named by Drew: the post-100% chart, the project story, the wiki (a Levers page), and the
decomp-architect/ package — which needs the taxonomy plus an answer to "what should we have done from day one to stop
this creeping up on us post-100%, or is leaving it to a post-100% cleanup actually optimal?"
Why: the only phase that ever counts the levers is the phase that removes them, so if the series is not captured while the work happens it cannot be reconstructed afterwards — a census is a moment. The measured answer so far (P36): 38% of the class A/B population came off with no understanding at all (strip, compile, compare), which is the evidence for the day-one rule ban the silence, not the lever — a lever is allowed but is a marked, ledgered, published debt from the first bank, with a one-compile bank-time trial that would have refused a third of them where the context was still hot.
How to apply: at every task close run the census then lever_progress --snapshot; keep §5 of docs/levers.md (the
prevent-vs-defer argument) written from the generated numbers, never typed; feed each new rung/recipe and each measured
yield into §4. Related: matching-cookbook (§454 carries the mechanism), decomp-accelerator-ledger,
phaseend-verbosity-for-the-retrospective, project-endgame-deliverables.