Summary
next_seq allocates the next DW id by scanning \bDW-(\d+)\b over the whole ledger file,
prose included (deferredwork.py:274-282). So a DW-<n> token anywhere in a note, reason or
summary steers orchestrator id allocation.
Reproduced:
mark_done(ledger, "DW-1", "2026-06-11", "fixed, see DW-99999")
append_entry(ledger, title="next", ...) # -> "DW-100000"
The intervening id space is burned permanently — the ledger is append-only and next_seq's
docstring is explicit that a number is never reused.
Why it matters more after #305
Pre-existing and unchanged by #305: before that fix, an injected phantom ### DW-99: heading fed
DW_ID_RE identically. But #305's sanitizer preserves the token as prose rather than removing
it, so this is now the documented steady state rather than a corruption artifact.
deferred-work-format.md:25 also instructs LLM writers to number "by scanning the file for the
highest existing number", so a dev or migration session replicates the jump rather than correcting
it.
Fix shape
Derive next_seq from HEADING_RE matches (real entry headings) rather than a bare token scan,
keeping a floor so an id is never reused even if a heading is later edited away. The sweep numbering
check in validate_migration should keep passing.
Found during the #305 review.
Summary
next_seqallocates the next DW id by scanning\bDW-(\d+)\bover the whole ledger file,prose included (
deferredwork.py:274-282). So aDW-<n>token anywhere in a note, reason orsummary steers orchestrator id allocation.
Reproduced:
The intervening id space is burned permanently — the ledger is append-only and
next_seq'sdocstring is explicit that a number is never reused.
Why it matters more after #305
Pre-existing and unchanged by #305: before that fix, an injected phantom
### DW-99:heading fedDW_ID_REidentically. But #305's sanitizer preserves the token as prose rather than removingit, so this is now the documented steady state rather than a corruption artifact.
deferred-work-format.md:25also instructs LLM writers to number "by scanning the file for thehighest existing number", so a dev or migration session replicates the jump rather than correcting
it.
Fix shape
Derive
next_seqfromHEADING_REmatches (real entry headings) rather than a bare token scan,keeping a floor so an id is never reused even if a heading is later edited away. The sweep numbering
check in
validate_migrationshould keep passing.Found during the #305 review.