docs(handoff): the worker's checks follow D-60

The worker instructions still said `just check` before every PR; under
D-60 a worker compiles every target, runs fmt, clippy on the crates
touched and the unit's named tests, and the EM runs the exhaustive
gate once per wave.

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

plan/HANDOFF.md

@@ -30,7 +30,7 @@ Nothing is left to resume. The merges went in the 8.0.2 order with the conflicts
 ### How to run things
 
 - `mise install` once (Rust 1.99 with clippy and rustfmt, just, Kani, Lean, sccache, all pinned in `mise.toml`). Then `just` lists the recipes.
-- `just check` is the gate for every PR: `cargo fmt --all --check`, `cargo clippy --workspace --all-targets -- -D warnings`, rustdoc with `-D warnings`, `cargo test --workspace`, the server-only build. It takes a while; during development, run the crate's own tests (`cargo test -p ledger-core`, `cargo test -p ledger-store`, `cargo test -p ledger-cli --test documents`) and run `just check` before opening the PR.
+- `just check` is the exhaustive gate: `cargo fmt --all --check`, `cargo clippy --workspace --all-targets -- -D warnings`, rustdoc with `-D warnings`, `cargo test --workspace`, the server-only build. It takes over an hour and the EM runs it once per wave (D-60); a worker runs the crate's own tests (`cargo test -p ledger-core`, `cargo test -p ledger-store`, `cargo test -p ledger-cli --test documents`), fmt, and clippy on the crates touched. `CARGO_PROFILE_DEV_DEBUG=line-tables-only` in the shell keeps a worktree's `target/` to a fraction of its size.
 - `just prove` runs the Kani harnesses and the Lean proofs (about five minutes on a quiet machine; the slow harnesses are `just prove-slow`). Required for any unit that touches `crates/ledger-core/src/kernel.rs`, `crates/ledger-core/src/proofs.rs`, `verify/lean/`, or adds a `Ledger` command.
 - Over-the-wire tests (`crates/ledger-cli/tests/*.rs`) start a real books server in a temp root through `crates/ledger-cli/tests/common/mod.rs`; see recipe R-C step 6.
 
@@ -51,7 +51,7 @@ A worker's assignment is one message: the unit id, the exact section of `plan/se
 
 > You are implementing one unit of `plan/served.md` section 8.2 in a git worktree. Read `AGENTS.md`, then `plan/served.md` section 0, section 8.0 (all of it: the template, the recipes R-A to R-G, the 8.0.6 checklist, 8.0.7), then your unit's section, then the parts of 8.3 and of sections 2 to 7 your unit's text points to. Do not read other units' sections to borrow from them; every name you may use (features, event types, setting keys, tools, roles, handbook sections, rule numbers, test files) is allocated in 8.0.3, and if your unit needs a name not listed there, stop and ask the EM.
 >
-> Follow your unit's Build steps in order. Each step compiles and passes `cargo test` for the crates it touches on its own; `just check` passes before every PR; `just prove` passes before any PR touching `kernel.rs`, `proofs.rs`, `verify/lean/` or a `Ledger` command. Every code bullet in your unit ends with where it lives (`crate/path/file.rs::symbol`): edit exactly there; for a "(new)" symbol, put it where the bullet says. Use the recipe named in the bullet (R-A for a journal feature, R-B for an event type, R-C for an MCP tool, R-D for a setting key, R-E for a handbook section, R-F for a Needs-attention item, R-G for the For-P12 paragraph); the recipe is the checklist of files you must touch, and tests fail on a partial state.
+> Follow your unit's Build steps in order. Each step compiles and passes the tests of the crates it touches on its own (D-60: the check is proportional to the change; you never run `just check` or `just prove` yourself, the EM runs them once per wave after the merges and sends back what they find). A unit touching `kernel.rs`, `proofs.rs`, `verify/lean/` or a `Ledger` command runs only the harness or theorem it added (`cargo kani --harness <name>`, `lake build` in `verify/lean`). Every code bullet in your unit ends with where it lives (`crate/path/file.rs::symbol`): edit exactly there; for a "(new)" symbol, put it where the bullet says. Use the recipe named in the bullet (R-A for a journal feature, R-B for an event type, R-C for an MCP tool, R-D for a setting key, R-E for a handbook section, R-F for a Needs-attention item, R-G for the For-P12 paragraph); the recipe is the checklist of files you must touch, and tests fail on a partial state.
 >
 > Name every test exactly as your unit names it, in the file it names. Update the six docs the same PR (`docs/parity.md`, `docs/spec/rules.md`, `docs/mcp-interface.md`, `docs/testing.md`, `docs/verification.md`, `docs/architecture.md`) where your unit says so; a test fails if a tool is undocumented. If your unit changes a journal line's shape, do every item of 8.0.6 and say so in the PR.
 >
@@ -61,7 +61,7 @@ A worker's assignment is one message: the unit id, the exact section of `plan/se
 >
 > If a Build step is impossible as written (a symbol it names does not exist, a type does not match, a test it names cannot be written as described), stop, write down exactly what you found, and ask the EM. Do not work around it silently. If you are stuck for more than an hour on a question the plan does not answer, write the question into the PR, pick the answer that keeps the books right under section 2's invariants, and flag it.
 >
-> Finished means: every item of your unit's "Done when" list is true and checkable without the owner's books; `just check` (and `just prove` where required) is green on your branch rebased on `main`; your "As built" block is written. Then report to the EM with the PR link and the list of Done-when items, each with how it was checked.
+> Finished means: every item of your unit's "Done when" list is true and checkable without the owner's books; the workspace compiles with every target (`cargo build --workspace --all-targets`), `cargo fmt --all --check` passes, `cargo clippy -p <each crate you touched> --all-targets -- -D warnings` passes, and the unit's named tests pass on your branch rebased on `main`; your "As built" block is written. Then report to the EM with the PR link and the list of Done-when items, each with how it was checked.
 
 ### Reviewing and merging (the EM)