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
-`ledger-core`.
+`just check` and `just prove` both pass before a batch of work touching
+`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.