🤖 Guidance pass C: rewrite steering sentences with counterweights

plugins/spire/skills/implementation/SKILL.md

@@ -23,7 +23,7 @@ Separate the roles: the planner, the attacker, the builder and the reviewer are
 
 ## Attack the plan
 
-After the plan is written, a fresh agent that did not write it **tests it adversarially against the code**: blockers, design errors, wrong root causes, and consumers of changed semantics the plan missed (other readers, stats, migrations, callers in other crates). In the same pass it **reshapes** the plan: phases that each end in a testable state, blocks that one owner can finish, scope cut back to the goal, decisions the user must make listed. It writes a new build plan; the original stays as written.
+After the plan is written, a fresh agent that did not write it **tests it adversarially against the code**: blockers, design errors, wrong root causes, and consumers of changed semantics the plan missed (other readers, stats, migrations, callers in other crates): every direct reader or caller of what the change touches, and further only where the changed meaning is passed on. In the same pass it **reshapes** the plan: phases that each end in a testable state, blocks that one owner can finish, scope cut back to the goal, decisions the user must make listed. It writes a new build plan; the original stays as written.
 
 A plan written before earlier phases landed may be stale. The attack checks it against the code as it is now; it reads the previous phase's run log and review only when something is off.
 
@@ -31,14 +31,14 @@ This step is what pays for dropping per-task review. A plan checked against the
 
 The build plan sets defaults: block size, owner model per block, the gate per block, what may stay broken between blocks. It may place an extra review at a hotspot if it says why. Its risk list shapes the build. It is not the phase reviewer's scope: a reviewer handed a checklist tends to confirm the checklist.
 
-A plan holds decisions, contracts, invariants and the scope fence. Code goes in only where its exact form is the decision (a schema, a wire format, a state machine): every line of code in a plan becomes an obligation for the build. Whatever tool wrote the plan, the attack is the same.
+A plan holds decisions, the code structure, contracts, invariants and the scope fence. Code goes in only where its exact form is the decision (a schema, a wire format, a state machine, the main signatures): every line of code in a plan becomes an obligation for the build. Whatever tool wrote the plan, the attack is the same.
 
 ## Building a phase
 
 - **Sequence by default.** Later changes depend on earlier ones, even when they look independent. Run in parallel only for truly disjoint work: separate files with no behavioural coupling, read-only exploration, separate test suites. If you have to think hard about independence, sequence.
 - **One owner per coherent change.** Do not split one logical change across agents; they fight over the boundary.
 - **Hand over as commits, not descriptions.** Each block commits and adds a short handoff note to the run log (template: `references/run-log.md`). The note is how flags reach the reviewer.
-- **Between blocks, a cheap gate, not a review.** Compile or typecheck what the block owns. Run the test suite once, at phase end, and fix the fallout in that last block.
+- **Between blocks, a cheap gate, not a review.** Compile or typecheck what the block owns. Run the test suite once, at phase end, and fix the fallout in that last block. Write a test for each behaviour and failure path the plan names, not one per branch, and never cut a test a plan box needs to save size.
 - **Decisions belong before the run.** Inside it, take the conservative default, flag it in the handoff note and continue. Do not wait on the user.
 - **Deviate with a reason.** Splitting a block, changing an owner model, adding a check: allowed, logged with why.
 
@@ -51,16 +51,16 @@ One option is **trunk and gremlins**. At intake the builder reads the build plan
 ## Phase review, fix, stop
 
 - A **fresh** reviewer that did not build the phase, dispatched outside the build, stamps its model id in its report header. A review without a stamped id does not count.
-- It is adversarial: it runs the gates, traces concrete scenarios, and **answers every deviation and flag in the handoff notes**, one by one. It looks specifically for **weakened checks** (loosened assertions, downgraded errors) and **tests that cannot fail**.
-- It lists **what was built that the plan did not ask for**. On record only, never an automatic revert: an unplanned addition may be a good one.
+- It is adversarial: it runs the gates, traces concrete scenarios, and **reads every flag in the handoff notes**, answering one only where it changes a finding or a verdict. In the phase's diff it looks for **weakened checks** (loosened assertions, downgraded errors, deleted tests) and **tests that cannot fail**, and reports each one it finds as a finding.
+- It ends with a short **size and unrequested surface** section: size against the plan's estimate, and what was built that no plan box asked for. The reviewer lists; Igor and the user decide, and an unplanned addition may be a good one.
 - **One fix pass** over all findings. Minors are fixed in that pass or logged as follow-ups.
 - **Re-check only Critical and Important**, by a fresh reviewer scoped to those findings. Then stop. A Critical or Important that survives the re-check goes to the user or into a new plan, not into the next phase.
 - Extra reviews (for example a mid-phase review of a hotspot block whose note flags a deviation) are a choice with a stated reason, not a default.
 
 ## Bugs
 
-- **Prove it with a failing test first** when you would say "I think the issue is…". It confirms you understand the bug, signals when the fix works, and stays as a guard. If you cannot write the failing test, keep investigating. Skip this for obvious bugs.
-- **Explore before you focus.** Look one or two layers up from the symptom, skim recent commits in the area, check where the same pattern recurs, reproduce end to end before changing anything.
+- **Prove it with a failing test first** when you would say "I think the issue is…". It confirms you understand the bug, signals when the fix works, and stays as a guard. If you cannot write the failing test, investigate further; if it still will not reproduce in a test, fix on the evidence you have and say so in the handoff note. Skip this for obvious bugs.
+- **Explore before you focus** when the cause is not plain: look one or two layers up from the symptom, skim recent commits in the area, check where the same pattern recurs, reproduce end to end before changing anything, and stop exploring once you can name the cause.
 
 ## Spawning and models
 

plugins/spire/skills/implementation/references/run-log.md

@@ -31,14 +31,16 @@ Rules:
 
 ## Handoff note (one per block, written by the block's owner)
 
+A few lines per block: findings, not narration. "none" is the normal answer for deviations and flags, and a real deviation or doubt is never left out.
+
 ```markdown
 ### Block <N.M> — <title>
 
 - Model: <exact id>
 - Start / end: <`date` output> / <`date` output>
-- Done: <what changed, in a few lines>
-- Deviations from plan: <what, and why> — or "none"
-- Flagged for review: <anything the reviewer should look at, e.g. a semantic you were unsure of>
+- Done: <what changed, in one or two lines>
+- Deviations from plan: <what, and why, including size well over the plan's estimate> — or "none"
+- Flagged for review: <a point you are unsure of, e.g. a semantic the plan left open> — or "none"
 - Left for later: <work deferred to a later block or phase>
 - Expected broken: <areas that do not build or pass yet, and which block fixes them>
 - Commits: <hashes>
@@ -51,8 +53,8 @@ Rules:
 
 - Gate: <command> — <result>
 - Tests: <command> — <result> (fallout fixed in block <N.M>)
-- Flags for the reviewer: every deviation and every "flagged for review" line above, one per bullet, with its block.
-- Not run / untested: <anything the tests do not cover>
+- Flags for the reviewer: the deviations and flags from the block notes above, one line each with its block — or "none" when the notes have none.
+- Not run / untested: <behaviour the plan names that no test or gate ran> — or "none"
 - Status: provisional until review, fix pass and re-check close.
 ```