writeonce/docs/superpowers
shoney.arickathil 3f88b07abb docs(db2-delta): implementation plan for keys-resident delta updates
- 6 tasks: the record kind, the fold, updates + indexes, the request
  path and group commit, replay + compaction, then lifting the loader
  refusal and proving it end to end
- the fold is written ONCE and called from three places; the tests are
  arranged to prove each caller separately, and the plan says that
  wanting a second fold "just for this caller" means the design failed
- Task 2 includes a same-field ordering test specifically, because a
  fold walking the chain backwards the wrong way returns plausible data
  and is otherwise invisible
- Task 6 step 1 audits the db.c request arms BEFORE lifting anything —
  they were never audited for keys-residency the way the inline path
  was, and the last audit of that kind found delete corrupting memory
- self-review found the spec's crash criterion had no task: added a step
  that commits a delta, skips the re-point, and replays, which is the
  state a crash between barrier and flush leaves behind
- every symbol the plan names verified to exist in database/src
- code-free per house convention; the writing-plans skill wants code
  blocks and the project rule overrides it

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit abb8fc9454bdca9d8d703c8cfeb224f89a93d14d)
2026-08-30 20:37:27 +02:00
..
plans docs(db2-delta): implementation plan for keys-resident delta updates 2026-08-30 20:37:27 +02:00
specs docs(db2-keys): spec — delta records for keys-resident updates 2026-08-30 20:37:27 +02:00