docs: the paused wave has landed; D-60, how much checking a merge gets; Q-9

The plan and the status documents say what is true after the merges
of 2026-10-29: served.md section 0, the 8.0.1 rows and unit Status
lines for S4.4, S5, S6, S7 and P6 (landed, with commits), the 8.0.2
resume paragraph turned into the record of what the merges found,
P6's At-merge bullet (the write-off and dedup interaction, the five
tests its interrupted gate never reached, schema 18), P9a's Done-when 1
verified by the green two-user job, D-58 and D-59 in order.

D-60 (the owner): per merge a compile and the unit's own tests; the
exhaustive gates once per batch, at the end. AGENTS.md's two gate
sentences, HANDOFF.md's merging procedure and the plan carry it, with
the reason: five full gates around five merges took twelve hours and
the one gate at the end found the same five tests.

Q-9 (open, for the owner): P6's `ledger-store` -> `ledger-import`
dependency, with the options and the recommendation; architecture.md
marks the arrow as under review. testing.md records the merge's test
changes under P6. STATUS.md gains "Now (2026-10-29)" with the gate
figures (170 suites, 2,944 tests, 77 minutes), the CI state and the
next steps; HANDOFF.md, roadmap.md, gui.md and the parties doc drop
the paused-branch wording; README counts 129 tools and about 2,950
tests.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HS8WZziDnyxunC23MUxrLp

AGENTS.md

@@ -128,8 +128,15 @@ So the bar, for every agent, every change:
    leave it with more formal coverage than you found it. Proptest,
    mutation testing, fuzzing, Kani, and Lean all stack. Use all of them.
 
-`just check` and `just prove` both pass before every commit that touches
+`just check` and `just prove` both pass before a batch of work touching
-`ledger-core`.
+`ledger-core` is pushed: once, at the end of the batch, with everything
+they find fixed in one pass. Inside a batch (a merge, a fix, a unit's
+commits), the check is proportional to the change: the workspace
+compiles and the tests the change touched pass. The owner's rule
+(plan D-60, 2026-10-29): the first wave's five branches took twelve
+hours to land with a full gate around every merge, and the one gate at
+the end found the same five tests. GitHub's `check` job runs `just
+check` on every push and is the exhaustive gate in the background.
 
 ## Parity tracking
 
@@ -162,7 +169,10 @@ clone, with status. Rules:
   just, Kani, Lean, cargo-mutants, cargo-fuzz. If a recipe needs a tool,
   it goes in `mise.toml`; nothing gets installed by hand.
 - Rust stable, edition 2024. `just check` must pass: fmt, clippy with zero
-  warnings, every test. `just prove` must pass for core changes.
+  warnings, every test. `just prove` must pass for core changes. Both run
+  once per batch, before the push, never around every merge or commit
+  inside one (D-60); the cheap checks (compile, the touched tests, clippy
+  on the touched crate) run as you go.
 - Conventional commits: `feat:`, `fix:`, `docs:`, `test:`, `refactor:`.
   One logical change per commit. The commit message explains the *accounting*
   reasoning, not just the code.

README.md

@@ -39,7 +39,7 @@ through MCP. Self-hosted, no rent.
 This is the storytold way applied to accounting: agents verify against
 oracles, never ship what they haven't demonstrated.
 
-- About 2,700 tests across the two workspaces (2026-10-28): invariant tests encoding accounting law, golden-file
+- About 2,950 tests across the two workspaces (2026-10-29): invariant tests encoding accounting law, golden-file
   report snapshots, property tests (proptest), end-to-end MCP tests through
   a real books server.
 - **Formal proofs of the accounting laws** (`just prove`,
@@ -113,7 +113,7 @@ just          # lists the recipes: check, build, prove, demo, ...
 ```
 crates/ledger-core/    # engine: money, accounts, journal, ledger, reports
 crates/ledger-store/   # journal + SQLite projection + blob store
-crates/ledger-mcp/     # MCP server: 122 tools, resources, handbook, receipt policy
+crates/ledger-mcp/     # MCP server: 129 tools, resources, handbook, receipt policy
 crates/ledger-import/  # QBO CSV import, IIF/XLSX export
 crates/ledger-config/  # wanderbooks.toml company settings
 crates/ledger-cli/     # `wanderbooks`: the one executable (every mode)

docs/architecture.md

@@ -31,7 +31,7 @@ the specification in `bookspec/` (which never depends on the engine).
 | `ledger-core` | the semantics engine: money, chart, journal, `Ledger` commands, reports, periods, assets, schedules, parties, A/R and A/P, payroll, projects, settings and conventions, the kernel and its Kani harnesses | nothing |
 | `ledger-vault` | the TIN vault: XChaCha20-Poly1305 records under the book's key | nothing |
 | `ledger-config` | the `wanderbooks.toml` codec (adoption in, `books.export_settings` out) and the receipt policy until P4 moves it into the core | `ledger-core` |
-| `ledger-store` | the source of truth: the hash-chained JSONL journal, its format gate, the SQLite projection (schema 16; a file per schema), the blob store, backups, the access log, `Snapshot` for readers | `ledger-core` |
+| `ledger-store` | the source of truth: the hash-chained JSONL journal, its format gate, the SQLite projection (schema 18; a file per schema), the blob store, backups, the access log, `Snapshot` for readers | `ledger-core`, `ledger-import` (the file reader, P6; Q-9) |
 | `ledger-import` | formats: QuickBooks CSV in; IIF, XLSX, Typst PDFs (statements, the invoice, labels) out | `ledger-core` |
 | `ledger-package` | the shared read-only view over `Store` or `Snapshot` (`PackageBooks`): the CPA package, the 1099 worksheet, the invoice document, Needs attention | `ledger-core`, `ledger-store`, `ledger-config`, `ledger-import`, `ledger-vault` |
 | `ledger-mcp` | the books server: the MCP tools (122), resources, the handbook, scopes, the door and the access log, backups' scheduling | all of the above |
@@ -50,12 +50,14 @@ test `crates/ledger-core/tests/oracle_gnucash.rs` with `oracle/gnucash/`
 (`PackageBooks` is the shared view; extraction is in-process in
 `ledger-import`, P6).
 
-Pending (the P6 branch, 2026-10-27, unmerged): P6 made `ledger-store`
+Under review (Q-9, asked 2026-10-29 when P6 landed): P6 made
-depend on `ledger-import` so the writer can extract a file's text at
+`ledger-store` depend on `ledger-import` so the writer can extract a
-attach time and on the backfill command. That keeps the direction inward
+file's text at attach time and on the backfill command. That keeps the
-but pulls Typst, the fonts and hayro into the store's dependency closure;
+direction inward (`ledger-import` depends on the core alone and must
-whether it stands, or extraction moves to the server before the store
+never depend on the store) but pulls Typst, the fonts and hayro into the
-call, is decided at P6's review.
+store's dependency closure. The plan's recommendation is a small library
+crate holding the reader that both depend on; until the owner decides,
+the arrow stands as drawn above.
 
 `ledger-core` itself (`crates/ledger-core/src/`): `money`, `account`,
 `journal`, `ledger` (the command surface and replay), `kernel` (every
@@ -128,7 +130,7 @@ and version; `Store::verify` checks the text blob's hash and never
 re-derives it. The server's filing scan (`tin_files`) and the viewer's PDF
 rasterizer read through the same module, so a PDF's text is read one way.
 Annotations and settlements are ledger state (`ledger_core::evidence`,
-`Ledger::differs_from`), projected into schema 16's `annotations` table;
+`Ledger::differs_from`), projected into schema 18's `annotations` table;
 extractions have a table of their own. The viewer's Documents page groups
 by category and filters by subject; Needs attention reads both through
 `PackageBooks`.
@@ -165,7 +167,7 @@ engine keeps them beside the ledger (`ledger_core::settings::Settings`,
 `ledger_core::conventions::Conventions`, fields of `Ledger`), so the store,
 its replay and the viewer's `Snapshot` share one reading; `Ledger::
 differs_from` and `verify` compare them, and the projection has a table
-for each (schema 16 on 2026-10-28; a file per schema). `ledger-config` is the codec between them and a
+for each (schema 18 on 2026-10-29; a file per schema). `ledger-config` is the codec between them and a
 `wanderbooks.toml` (`codec::import`, `codec::export`): adoption (`wanderbooks
 books adopt`) moves an older books dir's file in through it, once, and
 `books.export_settings` writes the books' settings out as one. The books

docs/parties-and-attachments.md

@@ -4,7 +4,8 @@ Design for two features built together (the owner, 2026-10-15): a directory
 of the parties the company deals with, and attachments that link to any
 subject. Status: built (2026-10-15 to 2026-10-17: parties with roles, the
 TIN vault, attachments linked to any subject; the party's contact block,
-D-55, is built on branch S4.4 as of 2026-10-28). The design is kept as
+D-55, landed with P4b S4.4 on 2026-10-29; the same bytes filed twice are
+one attachment since P6, the same day). The design is kept as
 written; departures are in `plan/served.md` and `docs/spec/rules.md` B-26.
 
 ## Why together

docs/testing.md

@@ -3354,6 +3354,30 @@ use in `ledger-gui` or `ledger-mcp` (the extract crate is the only one);
 backfill command test; (5) the PR carries the 8.0.6 checklist; (6)
 `just check` green and both fuzz targets run ten minutes clean.
 
+**At merge (2026-10-29, `9351f89d`, `bfd453b6`).** The branch's gate had
+been interrupted, so the merge ran it to the end for the first time.
+Five tests from before P6 still encoded the invariant its step 4
+replaced, or counts from before extraction records existed, and were
+brought to the new rule rather than the rule to them:
+`blob_dedup_and_hash_verification` expects one attachment row under the
+first filing's name; `power_loss_at_any_byte_of_the_last_append_is_recovered`
+copies `blobs/` with the journal and the database, since `verify` now
+reads an extraction's text blob; `refused_commands_never_reach_the_journal`
+allows `AttachReceipt` and `FileDocument` to journal nothing when the
+bytes are already on file; the viewer's reconciliation helper files each
+statement with its own bytes; and the tall sidebar's shapes golden
+(`crates/ledger-gui/tests/goldens/sidenav-1440x920.shapes`, re-blessed
+with `SIDENAV_BLESS=1`) carries the fixture's new attention, event and
+file counts, no layout change. One interaction with S7 was a defect, not
+a test: `write_off_invoice` attached its notice after journaling the
+entry, so a notice whose bytes were already on file and linked to
+another entry was refused by the one-receipt-one-entry rule after the
+money had moved; the store now runs `check_linkable` on the
+deduplicated record before the journal line, and
+`a_write_off_whose_notice_is_anothers_receipt_is_refused_before_posting`
+(`tests/arap_standing.rs`) pins it. The bookspec adapter and the old-books
+fixture file each write-off's notice with its own bytes.
+
 **For P12 (mutation targets, none run, D-33):** `ledger-import::extract`:
 the caps' comparisons (`MAX_BYTES`, `MAX_PAGES`, `MAX_TEXT_BYTES`, the
 `cap_text` boundary walk), `extract`'s order (PDF by type or magic, XLSX

plan/HANDOFF.md

@@ -14,18 +14,18 @@ You are the engineering manager (EM) of a team implementing the remaining work o
 4. `plan/STATUS.md` (where the live books stand) and `docs/architecture.md`.
 5. Only when a unit is assigned: that unit's section in `plan/served.md` 8.2, and the parts of 8.3 (the P4b reference design) it points into.
 
-### What is true today (2026-10-28)
+### What is true today (2026-10-29)
 
-- `main` is `44ee4083`. Landed since the hand-off: U0a, U0b, U0c, P7, P9a, P13 steps 1-3, P4b S4.1, S4.2, S4.3 (all 2026-10-26 to 2026-10-27). Live on the owner's books: P0 to P3, Projects, P4b S1 (`document_standing`); everything behind `documents_v2` waits for the owner's upgrade (Q-5).
+- `main` is `bfd453b6`. Landed since the hand-off: U0a, U0b, U0c, P7, P9a, P13 steps 1-3, P4b S4.1, S4.2, S4.3 (2026-10-26 to 2026-10-27), then S4.4, S5, S6, S7 and P6 (2026-10-29, merged from the paused branches by the planning session). Live on the owner's books: P0 to P3, Projects, P4b S1 (`document_standing`); everything behind `documents_v2` waits for the owner's upgrade (Q-5).
-- Built but unmerged, on branches paused 2026-10-27: S4.4 (`002fb9f8`), S5 (`ad649be3`), S6 (`6c4480cd`), S7 (`4b4fecb9`), P6 (`ce366408`, a checkpoint whose gate never finished). Their worktrees are `../wb-<unit>`. "Resuming the paused worktrees" below is the first thing to do.
+- Nothing is built and unmerged. Branch `ci-fixes` (`76285434`, a fuzz target's renamed path and a regression test) is the one branch left to merge.
-- Not started: S4.5, P4, P5, P8, P10, P11a (starts now: D-56), P11b, P12, P13 steps 4-6.
+- Not started: S4.5 (next), P4, P5, P8, P10, P11a (starts now: D-56; step 0 first), P11b, P12, P13 steps 4-6.
 - The plan's section 8 was rewritten on 2026-10-26 for this hand-off and revised on 2026-10-28 (section 0, "What changed on 2026-10-28"; `plan/2026-10-28_DRIFT_REPORT.md`). Sections 1 to 7 are the older design and carry strike-throughs (`~~text~~ → D-n`) and "As built" notes where the build or a decision departed; where section 8 and an earlier section disagree, section 8 is right.
 - Mutation testing is paused until unit P12 (decision D-33). Workers never run `cargo mutants`; each unit writes a "For P12" paragraph in `docs/testing.md` instead (recipe R-G).
 - The owner's live books are never touched by anyone on this team. The only books a worker uses are test fixtures and throwaway books made by `wanderbooks setup` in a scratch root. A unit's new writes are refused on the owner's books until the owner's format upgrade; merging never waits for that.
 
-### Resuming the paused worktrees (2026-10-27 pause)
+### The paused worktrees (2026-10-27 pause) landed on 2026-10-29
 
-The five branches were stopped mid-gate; nothing was merged, rebased or discarded. Resume in this order, one at a time (the single-owner rule): S4.4, S5, S6, S7, P6, then S4.5. For each: rebase on `main`; resolve the known conflicts (served.md 8.0.2, "Resuming the paused wave": `crates/ledger-cli/tests/documents.rs` is an add/add on every P4b branch after the first, concatenate; `types.rs` keeps both appends; P6 retakes schema 18 and resolves eight files); renumber the laws in `docs/verification.md` at merge (S1 is 34 on `main`; S5 35, S6 36, S7 37); re-run `just check`, and `just prove` for S7 and any branch that touched `verify/lean/` or a `Ledger` command, after the rebase, since the pause killed the running gates; review against the unit's text and its As-built block (each branch carries its own); merge; move the 8.0.1 row to landed and append to `plan/STATUS.md`. P6's checkpoint is not a reviewed unit: run its gate to the end and review its `ledger-store` → `ledger-import` dependency before merging (ask the owner if you would keep it). Q-5 and Q-8 were answered 2026-10-28 (D-57, D-58).
+Nothing is left to resume. The merges went in the 8.0.2 order with the conflicts that paragraph predicted; what P6's first complete gate found is in its As-built block (8.2) and `plan/STATUS.md`. Two lessons for the next pause: a checkpoint whose gate was interrupted is not a reviewed unit (P6's five unreached tests and the write-off interaction cost a day of gates), and in this colocated repo never run a `jj` command while a `git merge` is in progress in the same checkout (jj's auto-import resets git's index; one merge had to be redone in a scratch worktree). Q-5 and Q-8 were answered 2026-10-28 (D-57, D-58); Q-9 (P6's `ledger-store` → `ledger-import` dependency) is with the owner.
 
 ### How to run things
 
@@ -67,6 +67,7 @@ A worker's assignment is one message: the unit id, the exact section of `plan/se
 
 - Review a PR against the unit's text and `AGENTS.md`, not against taste. Check: every named test exists and passes; the recipes' files were all touched (R-C: `types.rs`, the handler, `scopes.rs`, `docs/mcp-interface.md`, the over-the-wire test; R-A: the constant, the `_is_its_own_feature` test, the `ensure_feature` call sites, the `books_p2_served_cut_over_whole` entry; R-B: `EVENT_TYPES`, the two arms, the fuzz generator, `differs_from`); the 8.0.6 checklist where the journal's shape changed; no golden figure moved unless the unit says it may; no new dependency in `ledger-core` (AGENTS.md); no path, `just` or toml word in any tool text (`tool_text_lint`).
 - Merge in the 8.0.2 order. The three single-owner moments (U0a; P4's sweep; P5's envelope) merge with no other MCP branch open. Schema numbers are taken at merge: the second unit to merge rebases and takes the next number (8.0.3).
+- **The cost of checking is proportional to the change (D-60, the owner, 2026-10-29).** Per merge: the workspace compiles (`cargo build --workspace --all-targets`) and the unit's own named tests pass; then the next merge. `just check`, `just prove` and the fuzz runs take an hour or more on this machine and run **once per batch**, after the last merge, and what they find is fixed in one pass. Push after the cheap checks; GitHub's `check` job runs `just check` on every push and is the exhaustive gate in the background. Never a full gate before and after each merge: the first wave's five branches cost twelve hours that way, and the one gate at the end found the same five tests.
 - After each merge: move the unit's row in 8.0.1 to "landed (commit, date)"; make sure its "As built" block is filled; append a paragraph to `plan/STATUS.md`.
 - Ask the owner only the questions in 10.3, at the moments stated (Q-5 when S4 lands; Q-4 before P11a's signing step; Q-6 before P9b; Q-7 when P11b starts), one at a time, in plain English, with the recommendation given there. Record the answer as a new D-n row in 10.1 and note which units it affects. Any other decision a worker needs that the plan does not make: look for it in section 10 first; if it is not there, ask the owner the same way and record it; never let a worker guess.
 - The owner's format upgrade (D-39, D-52) is the owner's own command on his books after S7 and P4 have landed (8.3.14 item 8; 5.6's P4b row). It is not a team step.

plan/STATUS.md

@@ -1,6 +1,66 @@
 # STATUS — 2026-10-28: nine units landed, five built on paused branches; P11a starts
 
-## Now (2026-10-28): land the paused wave, then S4.5; start P11a beside it
+## Now (2026-10-29): the wave has landed; S4.5 next, P11a step 0 beside it
+
+**Where things stand.** `main` is `bfd453b6`. The five branches paused
+on 2026-10-27 are merged, in the 8.0.2 order, each with `just check`
+green after it: S4.4 (`d329bd6f`, 2,883 tests), S5 (`3a3f03d8`, 2,893),
+S6 (`be580598`, 2,912), S7 (`7ebeeed2`, 2,923; `just prove` green: 52
+Kani harnesses, 95 Lean theorems) and P6 (`9351f89d` with its fixes;
+the batch's one full gate on `bfd453b6`: 170 suites, 2,944 tests
+passed, 0 failed, 7 ignored, 77 minutes). Landed since the hand-off of 2026-10-26: fourteen
+units. Not started: S4.5, P4, P5, P8, P10, P11a, P11b, P12, P13 steps
+4-6. The live books are unchanged since the P3 cutover and the
+`document_standing` upgrade of 2026-10-24; `documents_v2`, `drafts_v2`
+and `attachment_text` wait for the one upgrade after P4 (D-57).
+
+**What the merges found.** The P4b branches merged as the dry runs
+predicted (the `documents.rs` add/add, the `types.rs` appends, laws 35
+to 37, schema 17 then 18). P6 was different: its checkpoint's gate had
+never run to the end, and the four units merged before it did not know
+its dedup rule (the same bytes filed twice are one record, linked to
+each subject). Three things followed, all fixed on `main` and recorded
+in P6's As-built block: S7's write-off attached its evidence after
+journaling the entry, so a notice whose bytes were already on file was
+refused by the one-receipt-one-entry rule after the money had moved
+(the check now runs before the journal line); the replay fuzzer and the
+journeys count lagged the new event; and five tests the interrupted
+gate never reached still encoded the invariant P6 replaced, or counts
+from before extraction records existed (`bfd453b6`). No golden with a
+figure in it moved; the one golden re-blessed is the sidebar's shape
+hash, whose attention, event and file counts changed with the fixture.
+
+**CI.** `check` and `two-user` are green on every push since
+`fb83af59`; the two-user job needed the fixture copies owned by the
+server account (`79fb7ff2`), and its first green run is P9a's Done-when
+1. The weekly mutation shards are gone from `scheduled.yml` (D-59). The
+weekly `fuzz_settings_replay` crash is fixed on branch `ci-fixes`
+(`76285434`: the fuzzer used the renamed database path) with a
+regression test for the one `fuzz_store_replay` finding, a writer and a
+viewer disagreeing on an unknown convention kind, which does not
+reproduce locally (the hand-written case passes; ten local minutes
+found nothing); the job now keeps its crash input as an artifact for
+the next run.
+
+**Open for the owner (the question tool):** Q-9, whether
+`ledger-store` keeps its dependency on `ledger-import` (P6 made the
+writer read a file's text as it is filed).
+
+**Next, in order:** (1) merge `ci-fixes`; (2) S4.5, the last P4b slice;
+(3) P11a step 0 (the macOS and Windows keyring stores, the Windows data
+root and pipes, a cross-platform CI build) and the packaging trial,
+staffed now; (4) P4 (adding `confirmed` to the settlement tools too),
+then the owner's one format upgrade (D-57), P5, P8, P10; P13 steps 4-6
+beside; P11b after P11a; P12 last.
+
+**Housekeeping done 2026-10-29:** the five unit worktrees and their
+`target/` directories removed (about 800 GB), 26 dead jj workspaces
+forgotten, branch `S4.4` deleted. Still to delete once `ci-fixes`
+lands: branches `S5`, `S6`, `S7`, `P6`, `merge-queue`, the `wb-merge`
+worktree; `rescue/p4-invproj-20261026` holds nothing `main` lacks
+(owner's call).
+
+## 2026-10-28: the drift review and the merge plan
 
 **Where things stand.** `main` is `44ee4083`. Since the hand-off of
 2026-10-26, nine units landed in two days: U0c (`198aa2a1`), P7

plan/gui.md

@@ -139,10 +139,10 @@ Built since, by the "Served" plan (`plan/served.md`):
   says "update wanderbooks", never half-read), `tests/view_model.rs`
   (every figure shown is the engine's).
 
-On the paused branches (2026-10-27): the invoice page shows sends (S5),
+Landed 2026-10-29: the invoice page shows sends (S5), a discount-deadline
-a discount-deadline column and the tie-out badge (S6), write-offs on the
+column and the tie-out badge (S6), write-offs on the timeline (S7),
-timeline (S7), documents grouped by category and subject (P6). S4.5 adds
+documents grouped by category and subject (P6). S4.5 adds the number,
-the number, terms, bill-to and the issued copy to Save.
+terms, bill-to and the issued copy to Save.
 
 Next, in the plan's order: S4.5's page changes; P4's draft states in
 Needs attention; P11a (the installed app: the viewer is its face, with

plan/roadmap.md

@@ -48,15 +48,16 @@ audit defects), projects, receivables and payables first class
 (documents read their figures from tagged standing lines), the invoice
 PDF, terms, numbers and line accounts in the core and the journal.
 
-## In flight (2026-10-28)
+## Landed 2026-10-29
 
-Built on paused branches, to be rebased and landed in order: P4b S4.4
+The wave paused on 2026-10-27, merged in order on `main`: P4b S4.4 (the
-(the create tools preview and confirm; the party contact block, D-55),
+create tools preview and confirm; the party contact block, D-55), S5
-S5 (sent tracking), S6 (paying on terms: multi-document payments,
+(sent tracking), S6 (paying on terms: multi-document payments,
 discounts, the processor fee, bills due, aging exports), S7 (bad debts),
-P6 (the evidence pipeline: extraction, dedup, annotations). Then S4.5
+P6 (the evidence pipeline: extraction, dedup, annotations). In flight:
-(the PDF, viewer and handbook of `documents_v2`) and the owner's one
+nothing. Next: S4.5 (the PDF, viewer and handbook of `documents_v2`),
-`documents_v2` upgrade of the live books (Q-5).
+P11a step 0 beside it, and after P4 the owner's one upgrade of the live
+books (D-57).
 
 ## Next
 

plan/served.md

@@ -59,6 +59,8 @@ Written 2026-10-26, when the plan was reworked for a team of engineers working i
 
 **What changed on 2026-10-28.** The team's first wave was paused on 2026-10-27 (`plan/STATUS.md`). This revision records where that left things: 8.0.1 and the unit Status lines name the five branches built but unmerged (S4.4, S5, S6, S7, P6) and 8.0.2 the merge hazards between them, the owner's destination (D-56: the installed app; P11a starts now) and the resume order; 8.0.3 lists the names the EM approved during the wave (`tools/sent.rs`, `tools/settlements.rs`, `books.set_entry_settles`, `recipients`); P11a gains step 0 (the platform groundwork the design had assigned to P11 without a step); Q-5 is marked due and Q-8 added; superseded Landlock sentences in section 2 and `server.toml` in 3.2 and 3.4 are struck. The full comparison of plan, code and documents is `plan/2026-10-28_DRIFT_REPORT.md`.
 
+**What changed on 2026-10-29.** The paused wave landed: S4.4 (`d329bd6f`), S5 (`3a3f03d8`), S6 (`be580598`), S7 (`7ebeeed2`) and P6 (`9351f89d`, with the integration fixes listed in its As-built block), each merged in the 8.0.2 order on `main` with `just check` green after it, and `just prove` after S7. 8.0.1 and the unit Status lines record it; 8.0.2's resume paragraph is now the record of what the merges found (the dedup and write-off interaction, P6's five unreached tests). The owner answered Q-5 and Q-8 (D-57, D-58), took mutation testing out of CI (D-59), and the two-user job is green (P9a Done-when 1). Next: S4.5, and P11a step 0 beside it.
+
 ---
 
 ## 1. Summary
@@ -817,16 +819,16 @@ One row per unit of work. A unit is what one engineer takes into one git worktre
 | U0a | Split `server.rs` by tool group | landed 2026-10-27 (`45396bdc`) | none | U0b, U0c, S4.1, S4.2, S7.1 (core steps only) | none | 3-4 |
 | U0b | The attention engine over `PackageBooks` | landed 2026-10-27 (`26d3a994`) | none | U0a, U0c, S4.1, S4.2 | none | 4-6 |
 | U0c | `docs/testing.md` sections for S1-B, S2, S3; `docs/mcp-interface.md` cleanup of stale P4b notes | landed 2026-10-26 (`198aa2a1`) | none | everything | none | 0.5-1 |
-| P4b S4 | `documents_v2`: numbers, terms, line accounts, snapshots, preview and confirm, the issued PDF filed, party email and terms, invoicing settings | in progress: S4.1-S4.3 landed 2026-10-27 (`d19fb464`); S4.4 built on branch `S4.4` (`002fb9f8`), paused 2026-10-27, unmerged; S4.5 not started | S4.1 and S4.2 need nothing; S4.3 needs S4.1, S4.2; S4.4 needs U0a, S4.3; S4.5 needs S4.4 | S5 (after S4.2), S7 (core after S1), P6, P9a, P11a, P13 | `documents_v2` (one upgrade after S7, D-52) | 12-16 |
+| P4b S4 | `documents_v2`: numbers, terms, line accounts, snapshots, preview and confirm, the issued PDF filed, party email and terms, invoicing settings | in progress: S4.1-S4.3 landed 2026-10-27 (`d19fb464`); S4.4 landed 2026-10-29 (`d329bd6f`, gate 2,883 tests green); S4.5 not started, **next** | S4.1 and S4.2 need nothing; S4.3 needs S4.1, S4.2; S4.4 needs U0a, S4.3; S4.5 needs S4.4 | S5 (after S4.2), S7 (core after S1), P6, P9a, P11a, P13 | `documents_v2` (one upgrade after S7, D-52) | 12-16 |
-| P4b S5 | Sent tracking | built on branch `S5` (`ad649be3`), paused 2026-10-27, unmerged; schema 17 | S1; S4.2 for the defaults (works without it, see the unit) | S4.3 onward, S6 | `documents_v2` | 3-4 |
+| P4b S5 | Sent tracking | landed 2026-10-29 (`3a3f03d8`; schema 17; law 35) | S1; S4.2 for the defaults (works without it, see the unit) | S4.3 onward, S6 | `documents_v2` | 3-4 |
-| P4b S6 | Paying on terms: multi-document payments, discounts, the processor fee, bills due, aging exports | built on branch `S6` (`6c4480cd`), paused 2026-10-27, unmerged; no schema change; `confirmed` deferred to P4 | S4.1 (`Terms`), U0a | S5, S7, P6 | `documents_v2` | 8-10 |
+| P4b S6 | Paying on terms: multi-document payments, discounts, the processor fee, bills due, aging exports | landed 2026-10-29 (`be580598`; no schema change; law 36); `confirmed` deferred to P4 | S4.1 (`Terms`), U0a | S5, S7, P6 | `documents_v2` | 8-10 |
-| P4b S7 | Bad debts (write-offs) | built on branch `S7` (`4b4fecb9`), paused 2026-10-27, unmerged | S1; S4.3 for the same-call evidence attach; U0a | S4.4 onward, S5, S6 | `documents_v2` | 4-6 |
+| P4b S7 | Bad debts (write-offs) | landed 2026-10-29 (`7ebeeed2`; law 37; `just prove` green) | S1; S4.3 for the same-call evidence attach; U0a | S4.4 onward, S5, S6 | `documents_v2` | 4-6 |
 | P4 | Draft states, the evidence gate in one place, the preview digest, the digest tool | not started | S4-S7 merged (one sweep over every confirm tool), U0b | P6, P9a, P11a, P13 | `drafts_v2` (same upgrade as `documents_v2`, D-52) | 8-10 |
 | P5 | Agent surface complete: the result envelope, prompts, `books.start` v2, journal history, agent evals | not started | P4, U0b; the envelope step is single-owner and merges when no other MCP branch is open | P6, P9a, P11a, P13 | `source_revisions` | 10-12 |
-| P6 | Evidence pipeline: extraction, dedup, annotations, company record categories | built on branch `P6`, checkpointed `ce366408` (gate interrupted; not for merge as is: rebase, retake schema 18, run `just check` to the end, review the store → import dependency) | U0a, U0b | S4-S7, P4, P5 (not its envelope step), P9a, P11a, P13 | `attachment_text` | 8-10 |
+| P6 | Evidence pipeline: extraction, dedup, annotations, company record categories | landed 2026-10-29 (`9351f89d`, schema 18, with the integration fixes `b66fc893`, `0cbb49b6`, `fb83af59`, `6c26160e`, `bfd453b6`); the `ledger-store` → `ledger-import` dependency is Q-9 | U0a, U0b | S4-S7, P4, P5 (not its envelope step), P9a, P11a, P13 | `attachment_text` | 8-10 |
 | P7 | The TIN scanner's separators; vault v2 closed (D-48) | landed 2026-10-26 (`3e65c83f`) | none | everything | none | 1 |
 | P8 | Audit and attestations | not started | P6 (extraction), P4 (drafts), U0b | P9a, P11a, P13 | `audits` | 10-12 |
-| P9a | Self-host recipe, `books adopt` move with the head check, static bearer over a tunnel, the two-user CI job | landed 2026-10-27 (`c8541ea9`); Done-when 1-2 are owner/EM to verify | none (code); a second machine to try it on | everything | none | 3-4 |
+| P9a | Self-host recipe, `books adopt` move with the head check, static bearer over a tunnel, the two-user CI job | landed 2026-10-27 (`c8541ea9`); Done-when 1 verified 2026-10-29 (the two-user job green on `fb83af59`, after `79fb7ff2` gave the server account the fixture copies); Done-when 2 (the recipe on a clean VM) is the owner's | none (code); a second machine to try it on | everything | none | 3-4 |
 | P9b | claude.ai through an external identity provider (D-7 b, Q-6) | not planned until Q-6 is answered | P9a | | | |
 | P9c | Remote viewer replica, invitations | not planned (D-51) | | | | |
 | P10 | The re-audit runbook and its CI mirror; the owner runs the re-audit | not started | P5, P6, P8 | P11a, P13 | none | 1 (+ owner days) |
@@ -857,7 +859,7 @@ The shortest path to P10 (the owner's goal: the whole re-audit through the MCP a
 
 **The destination (D-56, 2026-10-28).** The owner's destination is one installed app for Mac, Windows and Linux (P11a, then P11b), and after it the hosted service of section 11. P11a is therefore staffed now, beside the P4b finish, not "any time"; its step 0 (the platform groundwork) comes first, because today the executable's agent path works on Linux alone (the keyring store exists for Linux only). The P10 chain keeps its order and runs beside it.
 
-**Resuming the paused wave (paused 2026-10-27; see `plan/STATUS.md`).** Five units are built on branches and unmerged. Land them in this order, each rebased on `main` with its `just check` (and `just prove` where the unit says) re-run after the rebase, since the pause killed every gate: (1) S4.4 (`002fb9f8`; merges clean); (2) S5 (`ad649be3`; conflicts: `crates/ledger-cli/tests/documents.rs` add/add, which every P4b branch created from 8.0.3's one allocated file, so concatenate; `crates/ledger-mcp/src/types.rs`, both appends kept; schema 17 stands); (3) S6 (`6c4480cd`; `documents.rs`, `docs/mcp-interface.md`); (4) S7 (`4b4fecb9`; `documents.rs`, `types.rs`, `crates/ledger-store/src/lib.rs`; `just prove` for `writeOff_within_bounds`); (5) P6 (`ce366408` is a checkpoint, not a reviewed unit: rebase, resolve `types.rs`, `store/src/lib.rs`, `store/src/schema.rs` (retake schema 18: it took 16, which S4.3 holds), `store/tests/store.rs`, `docs/parity.md`, `docs/receipt-store.md`, `docs/spec/rules.md`, `docs/testing.md`; run its gate to the end; review its `ledger-store` → `ledger-import` dependency before merging). Law numbers in `docs/verification.md` at merge: S1's documents law is 34 (added on `main` 2026-10-28); S5's `Step.markSent` becomes 35 and S6's `settle_is_exact` 36 (both branches wrote 34); S7's write-off 37. Then S4.5, the only unstarted P4b slice. The single-owner rule of U0a holds throughout: no two of these merge at once.
+**The paused wave, landed (2026-10-29).** The five branches paused on 2026-10-27 were merged on `main` in this order, one at a time, each with `just check` green after it: S4.4 (`d329bd6f`; clean), S5 (`3a3f03d8`; `crates/ledger-cli/tests/documents.rs` add/add concatenated, `types.rs` both appends, schema 17, law 35), S6 (`be580598`; `documents.rs`, `docs/mcp-interface.md`; law 36), S7 (`7ebeeed2`; `documents.rs`, `types.rs`, `store/src/lib.rs`; law 37; `just prove` green), P6 (`9351f89d`; schema 18, eight files resolved; its gate run to the end for the first time, which found the integration defects recorded in its As-built block). The tests S5, S6 and S7 wrote before S4.4's confirm contract gained `confirmed: true` and the bill fields at merge; the scopes `TABLE` is 129 tools. The one review point left is P6's `ledger-store` → `ledger-import` dependency (Q-9). Then S4.5, the only unstarted P4b slice. The single-owner rule of U0a holds throughout: no two units merge at once.
 
 Recommended staffing for a team of five: engineer A on U0a then S4.4/S4.5; B on U0b then P6; C on S4.1/S4.3 then S6; D on S4.2 then S5 then S7; E on P13 steps 1-3, then P9a, then P11a. The EM merges in the order above and holds the three single-owner moments: U0a (before any MCP-touching branch opens), P4's one sweep over the confirm tools, and P5's envelope step.
 
@@ -1285,7 +1287,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
 
 #### P4b S4: `documents_v2`
 
-1. **Status:** in progress: S4.1 (`13282cf8`), S4.2 (`bf91c5a7`) and S4.3 (`d19fb464`) landed 2026-10-27; S4.4 built on branch `S4.4` (`002fb9f8`), paused 2026-10-27, unmerged (its As-built block is on the branch); S4.5 not started.
+1. **Status:** in progress: S4.1 (`13282cf8`), S4.2 (`bf91c5a7`) and S4.3 (`d19fb464`) landed 2026-10-27; S4.4 landed 2026-10-29 (`d329bd6f`, merged clean from branch `S4.4` at `002fb9f8`); S4.5 not started, the next unit.
 2. **Depends on:** S1-S3 (landed). Inside the unit: S4.1 and S4.2 need nothing and may run in two worktrees; S4.3 needs both; S4.4 needs U0a and S4.3; S4.5 needs S4.4. S6 may start when S4.1 has merged; S5 when S4.2 has; S7.2 when S4.3 has. Go-ahead: `documents_v2`, one upgrade after S7 (D-52; Q-5 asks the owner whether to upgrade earlier). Until the go-ahead, on the owner's books a document carrying any new field is refused with `format_upgrade_pending`; a document carrying none posts exactly as before.
 3. **Feature and schema:** feature `documents_v2` (R-A; shared with S5, S6, S7, so S4 creates the constant and the test and the later slices add their call sites). New fields on `invoice.created` and `bill.created` and on their lines, and on `party.updated`, as 8.0.3 lists; no new event type. Provisional schema 16: columns on the documents and document lines tables, a `parties.email` and two terms columns.
 4. **Build:**
@@ -1343,7 +1345,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
 
 #### P4b S5: sent tracking (`invoice.sent`)
 
-1. **Status:** built on branch `S5` (`ad649be3`, 2026-10-27), paused, unmerged; its As-built block is on the branch.
+1. **Status:** landed 2026-10-29 (`3a3f03d8`, from branch `S5` at `ad649be3`); its law is 35 in `docs/verification.md`.
 2. **Depends on:** S1. S4.2 gives the defaults (`to` from the party's email; `invoicing.unsent_days`, `invoicing.reminder_days`); if S5 merges before S4.2, `to` is required and the day counts are the constants 2 and 14, and both paths are tested. MCP step needs U0a. Go-ahead: `documents_v2` (D-52).
 3. **Feature and schema:** feature `documents_v2` (S5 adds its `ensure_feature` call site; the constant is S4's, or S5 creates it per R-A if S5 merges first); new event type `invoice.sent { invoice_id, on, by, via, to: [String], kind, reference?, note? }` (R-B); provisional schema 17: table `invoice_sends`.
 4. **Build:**
@@ -1368,7 +1370,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
 
 #### P4b S6: paying on terms (multi-document payments, discounts, the processor fee, bills due, aging exports)
 
-1. **Status:** built on branch `S6` (`6c4480cd`, 2026-10-27), paused, unmerged; its As-built block is on the branch (`confirmed` deferred to P4's sweep; handlers in `tools/settlements.rs`).
+1. **Status:** landed 2026-10-29 (`be580598`, from branch `S6` at `6c4480cd`); its law is 36; `confirmed` deferred to P4's sweep; handlers in `tools/settlements.rs`.
 2. **Depends on:** S4.1 (`Terms`, `discount_by`, `kernel::discount_max`), U0a. Go-ahead: `documents_v2` (D-52).
 3. **Feature and schema:** feature `documents_v2` (call site in `Store::ensure_payment_features`); no new event type: `invoice.payment_received` and `bill.paid` gain `line` (the index of the control line this event tags), `discount`, `discount_line`, `discount_reason`, `fee`, `fee_line` (8.0.3). A payment entry that settles N documents is N events naming the same entry, each with its `line`; legacy events without `line` keep the positional rule ("the first untagged control line for the amount", rules.md B-38 item 1, test `several_payment_events_on_one_entry_tag_its_lines_in_order`). Provisional schema 18 if a column is needed for discounts and fees in the projection's payments table.
 4. **Build:**
@@ -1395,7 +1397,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
 
 #### P4b S7: bad debts (`write_off_invoice`)
 
-1. **Status:** built on branch `S7` (`4b4fecb9`, 2026-10-27), paused, unmerged; its As-built block is on the branch.
+1. **Status:** landed 2026-10-29 (`7ebeeed2`, from branch `S7` at `4b4fecb9`); its law is 37; `just prove` green after the merge.
 2. **Depends on:** S1; S4.3 for the same-call attach (the write-off needs its evidence filed in the same store call); U0a for the MCP step. Go-ahead: `documents_v2`.
 3. **Feature and schema:** feature `documents_v2`; new event type `invoice.written_off { invoice_id, entry_id, date, amount, reason }` (R-B). No schema change expected (the entry and its tag carry the figures; a column only if the projection's documents table needs `written_off`).
 4. **Build:**
@@ -1461,7 +1463,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
 
 #### P6: evidence pipeline
 
-1. **Status:** built on branch `P6`, checkpointed `ce366408` (2026-10-27, "not for merge": its `just check` was interrupted by the pause and must run to the end after a rebase that retakes schema 18); its As-built block is on the branch. Rewritten 2026-10-26 (D-32: no sandbox; D-46: no inline bytes; D-17: no email-in; no migration tools).
+1. **Status:** landed 2026-10-29 (`9351f89d`, from the checkpoint `ce366408`, schema 18; the merge's own fixes are in the As-built block's last bullet). Open: Q-9, the `ledger-store` → `ledger-import` dependency. Rewritten 2026-10-26 (D-32: no sandbox; D-46: no inline bytes; D-17: no email-in; no migration tools).
 2. **Depends on:** U0a, U0b. Independent of P4b and P4. Go-ahead: `attachment_text`.
 3. **Feature and schema:** feature `attachment_text`; event types `attachment.text_extracted { attachment_id, text_sha256, extractor, version, pages, status: ok | none | failed }`, `attachment.annotated { attachment_id, fields { receipt_number?, payee?, amount?, date?, instrument?, category?, source?, reimbursable_to? }, note? }`, `entry.settles { entry_id, settles: [entry_id] }` (R-B); `attachment.withdrawn` gains `duplicate_of?`. Provisional schema 20: tables `extractions`, `annotations`.
 4. **Build:**
@@ -1484,6 +1486,7 @@ Each unit follows the 8.0.4 template. "A-n" is an owner answer numbered in 8.3.1
    - `books.find_attachment`'s `sha256` is exempt from the D-46 inline-argument refusal (it names a search key, not bytes), and `no_tool_takes_a_path` exempts an annotation's `source` (what a human says a record came from, never a place).
    - Two `ledger-store/tests/spec_store.rs` tests encoded the invariant step 4 replaces (two records for one blob); they are rewritten as `same_bytes_are_one_attachment_linked_to_both` and `the_first_filings_name_and_type_stay`.
    - Schema 16 (8.0.3's provisional 20 was a guide; numbers are taken at merge). No kernel, Kani or Lean change: no money moves, so `just prove` is unchanged.
+   - **At merge (2026-10-29, `9351f89d` and after).** The checkpoint's gate had never run to the end, and the five units merged before it did not know its dedup. Found and fixed on `main`: (a) `write_off_invoice` (S7) attached its evidence after journaling the entry, so a notice whose bytes were already on file came back as the existing record and the one-receipt-one-entry rule refused it after the money moved; it now checks `check_linkable` on the deduplicated record before journaling (`6c26160e` makes each bookspec write-off file its own notice); (b) `fuzz_store_replay`'s `TYPES` lacked `invoice.written_off` (`0cbb49b6`), the MCP journeys count moved to 124 (`b66fc893`), one Lean docstring doubled on `Books` (`fb83af59`); (c) five tests the interrupted gate never reached still encoded the invariant step 4 replaced or counts from before extraction records: `blob_dedup_and_hash_verification` (one record, not two), the power-loss replay (the copy left out `blobs/`, which `verify` now reads for the text), the refusals property (a filing of bytes already on file journals nothing), the viewer's statement helper (each statement its own bytes) and the tall sidebar's shapes golden (the fixture's attention, event and file counts moved; no layout changed) (`bfd453b6`). The `attach_receipt` spec block's INVARIANT 3 now says what step 4 built. Schema 18 (S4.3 holds 16, S5 17).
    - 8.0.6: `tests/store.rs::books_written_under_older_rules_still_open` gained the three new event shapes; the fixture `tests/fixtures/old-books/p6_evidence` was written by the version before the unit (its API, its `expected.json`); the cutover test's refused list gained `books.annotate_attachment`; `attachment_text_is_its_own_feature` and the `tests/format.rs` arms pass; no figure moves, so no golden changed; merging needs no go-ahead (the live books refuse the new writes until the owner gives it).
 
 **Struck from P6:** ~~`ledger-extract` sandboxed subprocess (rlimits, seccomp, Landlock), `extractor_sandboxed`~~ → D-32, D-53; ~~`lopdf`~~ → hayro; ~~`attach_email`, `attachment.rendered`, `fuzz_eml`~~ → D-17 (email-in waits for the hosted service; a receipt that is an email is printed to PDF by the human, as the first company's convention says); ~~`compare_reference`, `record_inventory`, `check_inventory`, `inventory.recorded`, `reference.compared`~~ → the Sheet and the books as of 2026-10-11 are frozen and the final `verify-sheet` run is a filed workpaper; P10 step 5 cites it (IZ-3b, Z-6); ~~`inline_base64_requires_sha`~~ → D-46; ~~`reimbursed` by FIFO~~ → `entry.settles` only; ~~"the books dir's `company/` folder retired"~~ → done at the P1 and P2 cutovers.
@@ -2072,8 +2075,9 @@ The owner decisions of 2026-10-16 (at the top of this document) replace the form
 | D-55 | Party contact details (owner, 2026-10-27: asked which fields, chose "Full contact block") | A party carries, all optional and journaled on `party.updated` behind `documents_v2`: `phone`, `contact` (a named person), `billing_address`, `shipping_address`, `billing_email`. The existing `email` stays the general address and the existing `address` the general/business one; when `billing_email` or `billing_address` is set, an invoice's bill-to uses it, else the general one. `PartySnapshot` carries the same at issue; the issued PDF prints the contact person, phone, billing address and billing email, and prints a Ship-to line when a shipping address is set. `books.update_party` and `books.create_invoice`'s `bill_to` override take all six; `""` clears a text field. Both emails go through `parties::check_email` (one `@`, no spaces, the full-TIN scan). S4.4 builds the core, store, journal and MCP parts; S4.5 the PDF. Folded into `documents_v2` because the owner's upgrade has not happened (D-52), so no second go-ahead. No projection columns: there is no parties table in the SQLite projection, and replay plus `differs_from` carry the facts. Terms per side are already D-52/S4.2's and are unchanged. |
 | D-56 | The destination, and when P11a starts (owner, 2026-10-28: the work is "ultimately taking it to a single bundled server+GUI installation for Mac/Windows/Linux and then beyond") | **The installed app is this plan's destination** (D-19, D-22 and D-24 to D-27 unchanged), and the hosted service of section 11 is what comes after it. So P11a is no longer "any time": it starts as soon as an engineer is free, beside the P4b finish, with its new step 0 first (the macOS and Windows keyring stores, the Windows data root and pipes, a macOS and Windows CI build), because today the executable's agent path works on Linux alone. The P10 chain (P4, P5, P8) keeps its order and runs beside it. |
 | D-57 | Q-5 answered (owner, 2026-10-28, the question tool: "Once, after everything") | **One format upgrade of the live books, after S7 and P4 have landed**, declaring `documents_v2` and `drafts_v2` together (D-52 confirmed). Until then the new writes are refused on the owner's books with the upgrade remedy; a few days without numbered invoices is the accepted cost. A-14 records it. |
-| D-59 | Mutation testing in CI (owner, 2026-10-29, asked how the always-red weekly mutation shards should run until P12: "Don't think we need to run the long ass shit like mutation testing in CI. It's more for local test runs.") | **Mutation testing is a local run, never a CI job.** The mutation shards are removed from `scheduled.yml`, which keeps the proofs, the GnuCash oracle and the fuzz targets weekly; `just mutants-*` stays for the desktop, and P12 runs the whole pass there (D-33). The 2026-10-26 weekly run's survivors (real ones in every crate, and timeouts) are P12's list. |
 | D-58 | Q-8 answered (owner, 2026-10-28, the question tool: "Yes, all stand as built") | **D-47 to D-54 are the owner's decisions**, no longer the review's recommendations: reversals stay posted (D-47), the vault stays v1 (D-48), the P4b deferrals (D-49), the preview digest with no key (D-50), the P9 split (D-51), one P4b upgrade (D-52), no jobs and no new crates (D-53), the P11 split (D-54). The "the owner may revisit" clauses on those rows are closed. |
+| D-59 | Mutation testing in CI (owner, 2026-10-29, asked how the always-red weekly mutation shards should run until P12: "Don't think we need to run the long ass shit like mutation testing in CI. It's more for local test runs.") | **Mutation testing is a local run, never a CI job.** The mutation shards are removed from `scheduled.yml`, which keeps the proofs, the GnuCash oracle and the fuzz targets weekly; `just mutants-*` stays for the desktop, and P12 runs the whole pass there (D-33). The 2026-10-26 weekly run's survivors (real ones in every crate, and timeouts) are P12's list. |
+| D-60 | How much checking each merge gets (owner, 2026-10-29, after the paused wave took twelve hours to land with a full gate around every merge: "merge, and then just ... compile it once, make sure it compiles. Maybe run some specific tests related to that and then move to the next one, merge ... And then after you have done either several of them or even all of them, then run the super exhaustive test suites") | **Per merge, a compile and the unit's own tests; the exhaustive gates (`just check`, `just prove`, fuzz) once per batch, at the end, and their findings fixed together.** GitHub's `check` job stays the gate on every push. `plan/HANDOFF.md` "Reviewing and merging" carries the rule; AGENTS.md's "before every commit" is read as before every push of a batch, not before every merge inside one. | Every remaining unit; the EM's merge procedure |
 
 ### 10.2 Deferred
 
@@ -2082,7 +2086,7 @@ The owner decisions of 2026-10-16 (at the top of this document) replace the form
 
 ### 10.3 Open questions for the owner, and the closed ones
 
-**Open (2026-10-28): Q-4, Q-6, Q-7.** Each is asked when its unit starts, one at a time, in plain English; none blocks the units before it. Q-5 and Q-8 were answered on 2026-10-28 (D-57, D-58) and are kept below for the record.
+**Open (2026-10-29): Q-9 now; Q-4, Q-6, Q-7 when their units start.** Each is asked one at a time, in plain English; none blocks the units before it. Q-5 and Q-8 were answered on 2026-10-28 (D-57, D-58) and are kept below for the record.
 
 **Q-4 (before P11a step 5).** Releases: should the app check updates against our own signed release list as well (two keys, one on your hardware token and one offline, a version that only goes up, an expiry), as decided on 2026-10-18 (D-25), or is the packaging tool's own single-key signature plus Apple's and Microsoft's code signing enough? The second is simpler and already refuses an older version; the first also stops a frozen or replayed update list. Recommended: the first, as decided, since the key work is small once the token exists.
 
@@ -2092,6 +2096,8 @@ The owner decisions of 2026-10-16 (at the top of this document) replace the form
 
 **Q-7 (when P11b starts).** When the app connects Codex to a company's books folder, may it mark that folder as trusted in Codex's own settings, or should Codex ask you itself the first time? Recommended: let Codex ask.
 
+**Q-9 (asked 2026-10-29, after P6 landed).** P6 made the part of the program that writes the books (`ledger-store`) depend on the part that reads and writes file formats (`ledger-import`), so a receipt's text is read the moment it is filed. That is the right behavior, but `ledger-import` also carries the PDF typesetter the invoice is printed with, so the books writer now builds and tests with a typesetter it never uses, and the crate map has an arrow it did not have (`docs/architecture.md`). Three choices: (a) keep it as built and write the rule down (the format crate must never depend on the writer; it doesn't today); (b) move the reader (`extract.rs`: the PDF text and page reader, the spreadsheet reader) into a small library crate of its own that both depend on (not D-53's closed `ledger-extract` subprocess: a plain library, in-process as today; the EM allocates its name in 8.0.3), so the writer sheds the typesetter and the map is layered again (about half a day for the implementing team, no behavior change); (c) take reading out of the writer and make every caller read the file and hand the text in, which removes the arrow but makes "a file is read as it is filed" a duty each caller can forget. Recommended: (b), as a small unit for the implementing team once S4.5 is in, because it keeps P6's guarantee and the architecture's layering, and it is mechanical; (a) is acceptable if build times in `ledger-store` never bother anyone.
+
 **Q-8 (closed 2026-10-28 → D-58: all stand).** The 2026-10-26 review made eight engineering decisions in your name (D-47 to D-54: reversals stay posted with no reversal drafts; the vault stays v1; the P4b deferrals; the preview digest with no key; the P9 and P11 splits; one `documents_v2` upgrade; no jobs and no new crates), and S5, S6, S7 and P6 were built on them. Do they stand? Recommended: yes, as built; any you reverse becomes a new unit.
 
 **Closed: the P2 cutover questions (Q-1 to Q-3).** Answered 2026-10-17 and 2026-10-20; the cutover happened 2026-10-20 (P2 slice 9). Kept for the record: