@printpractical/cruze 0.0.9 → 0.0.11

package/skills/realign/notes/0.0.10.md

@@ -0,0 +1,131 @@
+# Realign notes: 0.0.10
+
+## Existing code
+
+### decision-citations-docs: Living docs and deltas cite a decision by number only where it is recorded
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-formats/SKILL.md`, "Decisions"
+- Detect: validate:decision-citation
+- Migrate: in a prefactor, rewrite each citation the rule reports in `docs/`: write what the decision settled into the element or sentence, reading it from the archived feature's `## Settled decisions` under `.cruze/archive/`, or cite the ADR that records it. A feature in flight fixes its own delta through `rethink` before its next approval, since `cruze approve` refuses a delta that cites one.
+
+### decision-citations-code: Code comments cite no decision by number
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-formats/SKILL.md`, "Decisions"
+- Detect: check:decision-citation
+- Migrate: in a prefactor, replace each citation `cruze check` reports with what was decided, in a few words, or with the element or ADR ID that holds it. Delete one that adds nothing to what the code already says.
+
+### pitfalls-to-cruze: Known pitfalls hold only lessons about the project
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-land/SKILL.md`, "Landing a change", step 7
+- Ask: which lines under `## Known pitfalls` in `AGENTS.md` are about how Cruze's deltas, plans, tasks, test plans or reviews are written, or about practice that holds in any project in the language, rather than this product's domain or code?
+- Migrate: record each such line with `cruze journal add lesson --set summary=<text> --set instead=<text> --set step=<step>`, so `cruze feedback export` carries it to Cruze, then remove it from `AGENTS.md`.
+
+### vision-intent: The vision holds the principles every design follows and what must stay possible
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-formats/reference/durable-docs.md`, "docs/vision.md"
+- Ask: does `docs/vision.md` lack `## Principles` or `## Must stay possible`, while the notes in `.cruze/notes/`, the ADRs, the architecture's `## Decisions` or the settled decisions of features, archived ones included, state a rule every design follows, or a capability the user expects later, such as one introduced with "eventually"?
+- Migrate: run envision at project scope to rework the vision. Add the two sections from those sources, with the user, ask about what may come later as `.agents/skills/cruze-envision/possibilities.md` describes, and approve the vision again. A principle the design already departs from is settled with the user: amend the principle, or rethink the design.
+
+### intent-review: A design follows the vision's principles and leaves room for what must stay possible
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 12
+- Ask: for each feature in flight, does its design depart from a `PRINCIPLE` the vision states, or close off a `LATER` capability it touches?
+- Migrate: settle each through `rethink` at feature level before the feature's next change is planned, or amend the vision's row when the user decides the principle or capability changes.
+
+### future-unanchored: A Future fact names the need it keeps room for
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-formats/reference/architecture.md`, "Rules for facts"
+- Detect: validate:future-unanchored
+- Migrate: for each `Future` fact `cruze validate` reports, cite the vision's `LATER` capability or the feature on the map or roadmap it serves, adding the capability to the vision with the user when it isn't there yet. A seam nobody needs goes, through `rethink` at architecture level.
+
+### notes-say-what-they-are: Every note says its kind and what it is about
+- Applies to: existing code
+- Rule: `.agents/skills/cruze-formats/SKILL.md`, "Where documents live"
+- Ask: which notes in `.cruze/notes/` have no `- Kind:` and `- About:` lines under their title, and which of them hold the user's input, such as a seed, a PRD or a design write-up, whose parts no step has taken up?
+- Migrate: add `- Kind:` and `- About:` to each, as `cruze show --notes` lists them. For a note of the user's input, run the intake in `.agents/skills/cruze-envision/intake.md` on it, so its parts are handed to the steps that take them up.
+
+## New work only
+
+### plan-task-files: Items wait for a production caller, and tasks list lockfiles and every literal a new field breaks
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-plan/tasks.md`, steps 2, 3 and 5
+
+### plan-risks-reach: A check named under Risks is confirmed to reach the failure
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-plan/SKILL.md`, "Steps", step 10
+
+### design-review-ports-and-quotes: The design reviewer checks each use case against every refusal it can meet, and quoted output against the code
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 8
+
+### architect-retired-rules: A delta rewords every statement of a rule it retires, and modifies a port it gives a new use
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-architect/feature.md`, step 4
+
+### fakes-partial-failure: Fakes stall and fail partway, and end the way the real adapter does
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-behavioural-testing/fakes.md`, "Writing a fake"
+
+### tests-races-and-callers: Race tests are seen failing, and a test is never a reason for production code
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-behavioural-testing/SKILL.md`, "Writing tests for a task" and "Expected values"
+
+### cancel-safe-writes: Memory follows storage before the next await
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-hexagonal-design/runtime.md`, "Failures, retries and cancellation"
+
+### rust-reachable-panics: No expect on a case a caller, the clock or a race can reach
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-hexagonal-design/languages/rust.md`, "Errors"
+
+### research-own-call-shapes: New call shapes and test images are verified by running them
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-research/SKILL.md`, "Adopt or build", step 7
+
+### rethink-dispositions: A finding a later rethink fixes is recorded as rethink, and holds its work
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-realign/SKILL.md`, "Steps", step 5
+
+### prefactor-order: A prefactor goes before the items it overlaps, unless one is building
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-roadmap/SKILL.md`, "Adding an item"
+
+### prefactor-plans: A prefactor's plan names its safety net and keeps visibility as it was
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-plan/SKILL.md`, "A prefactor"
+
+### merged-deltas: An element a feature merged keeps its living text, and needs no rebase
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-rethink/levels.md`, "A conflict with living text"
+
+### envision-possibilities: Envision asks about the capabilities the product may grow into
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-envision/possibilities.md`, "Exploring what may come later"
+
+### grilling-long-term-intent: Long-term intent goes to the vision, from any step
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-grilling/SKILL.md`, "Long-term intent"
+
+### envision-confirms-agreed: A proposal the user never decided is asked, not carried as settled
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-envision/project.md`, step 2
+
+### reviewer-rubrics: A review reads only the rubric for what it reviews
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric"
+
+### element-lookup: Steps read a large architecture's elements through the index
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-formats/reference/architecture.md`, "Reading it"
+
+### intake-handoff: Envision takes in any input and hands each part to the step that takes it up
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-envision/intake.md`, "Taking in the user's input"
+
+### every-later-row: Every design is checked against every capability that must stay possible
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 12
+
+### vision-intent-length: A principle or capability keeps every need it names
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-formats/reference/durable-docs.md`, "docs/vision.md"

package/skills/realign/notes/0.0.11.md

@@ -0,0 +1,15 @@
+# Realign notes: 0.0.11
+
+## New work only
+
+### review-severity: A blocker is a failure ordinary use reaches, not every gap in the design
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-roles/code-reviewer.md`, "Findings"
+
+### reverify-scope: A verify after a send-back reviews only the code changed since the last verify
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-verify/SKILL.md`, "Steps", steps 1 and 10
+
+### detail-amendments: A missing limit, timeout, message or error case is settled as a detail inside build or verify
+- Applies to: new work only
+- Rule: `.agents/skills/cruze-rethink/levels.md`, "Detail"

package/skills/realign/notes/0.0.2.md

@@ -42,7 +42,7 @@
 
 ### design-review-rubric: Contradictions are blockers, and slices build whole elements
 - Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric"
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric"
 
 ### verified-claims: Research runs every claim the design relies on
 - Applies to: new work only

package/skills/realign/notes/0.0.6.md

@@ -33,7 +33,7 @@
 
 ### cross-section-consistency: The design reviewer checks cross-cutting rules, interleavings and stale prose
 - Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric", item 8
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 8
 
 ### one-message-walkthrough: The design walkthrough is one overview, then the documents in full
 - Applies to: new work only

package/skills/realign/notes/0.0.8.md

@@ -50,7 +50,7 @@
 
 ### design-gives-every-value: The design gives every error, limit, timeout, transition and message owner
 - Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric", item 6
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 6
 
 ### one-owner-per-rule: Plan gives each rule one owner, and each item to its first handler's task
 - Applies to: new work only

package/skills/realign/notes/0.0.9.md

@@ -10,7 +10,7 @@
 
 ### flow-control-review: A design says how its work flows, waits and recovers
 - Applies to: existing code
-- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric", item 11
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 11
 - Ask: for each feature in flight, does its design leave out any check in rubric item 11 that a scenario or an `XC` rule depends on, such as what a sender does when a queue is full, or what happens when a reconnect fails?
 - Migrate: settle each gap through `rethink` at feature level before the feature's next change is planned. Code a landed change built goes to a prefactor.
 
@@ -28,7 +28,7 @@
 
 ### name-clash-review: The design reviewer checks new names against the ones a caller already reaches
 - Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-reviewer.md`, "Rubric", item 8
+- Rule: `.agents/skills/cruze-roles/design-rubric.md`, "Design rubric", item 8
 
 ### architecture-rethink-review: An architecture rethink that changes a contract gets a design review of the diff
 - Applies to: new work only

package/skills/realign/notes.md

@@ -12,6 +12,8 @@ Each release that changes what Cruze expects of a project ships a notes file, `n
 - [0.0.7](notes/0.0.7.md)
 - [0.0.8](notes/0.0.8.md)
 - [0.0.9](notes/0.0.9.md)
+- [0.0.10](notes/0.0.10.md)
+- [0.0.11](notes/0.0.11.md)
 
 ## Format
 

package/skills/research/SKILL.md

@@ -15,13 +15,14 @@ Run these steps for each component in a design that isn't domain logic. Domain l
 2. Look in order: the language's standard library, the project's already-approved dependencies, then mature libraries in the ecosystem. Done when you have checked all three.
 3. For the two or three serious candidates, gather the evidence in [evaluation.md](evaluation.md).
 4. Recommend one. Adopt a library, or build with a concrete reason: the behaviour is specific to this product, no candidate meets a stated constraint, every candidate brings disproportionate risk or complexity, or the capability is the product itself. Weigh the candidates as `.agents/skills/cruze-dependency-approval/SKILL.md` says under Weighing, where avoiding a dependency is never a reason.
-5. Record the result as a row in the `## Adopt or build` table of the feature or standalone change, as Component, Decision, Choice and Reason. At project scope, record it as the adapter's `Adopts` fact, and put rows for anything no adapter owns in the walking-skeleton change's `## Adopt or build`. When the evidence runs longer than the reason, write it to `.cruze/notes/<date>-<slug>.md` and cite that note in the reason.
+5. Record the result as a row in the `## Adopt or build` table of the feature or standalone change, as Component, Decision, Choice and Reason. At project scope, record it as the adapter's `Adopts` fact, and put rows for anything no adapter owns in the walking-skeleton change's `## Adopt or build`. When the evidence runs longer than the reason, run `cruze new note <slug> --title "<title>" --kind research --about <feature slug or context>`, write the evidence there, and cite that note in the reason.
 6. Take the recommendation to the user. Adopting means a new dependency, which follows `.agents/skills/cruze-dependency-approval/SKILL.md`. Building commodity functionality is the user's call as well.
 7. Verify what the design will rely on. List each claim the design or its testing approach makes about anything it doesn't build:
    - an adopted library or tool: the features or flags it needs, and each command the design spells out, such as a CI step;
    - each type, trait, macro or API the design names from a package: that the package exports it at that version, and every crate, package or target that must declare the package to use it, test support included;
    - the language or runtime, such as whether a trait with async methods can be used as a trait object;
-   - the platform's test environment, such as which permissions a test process gets;
+   - the platform's test environment, such as which permissions a test process gets, and every package a new test image installs, with the whole suite run once in it;
+   - each new method, trait or call shape the design gives the project's own types: compile a sketch beside the methods its receiver already has, on a concrete type and on a trait object, since a new name can be ambiguous on one and not the other;
    - an external system the product talks to, such as what a broker logs or how it answers.
 
    Once the user has approved any dependency involved, check each claim by running it: build a scratch project outside the repository with exactly the declared features, and run each command there or with `--help`, or run the external system and watch it. When a claim can't be run, check it in that version's source, and say so. Write the features into the `Adopts` fact or the row's Choice.

package/skills/rethink/SKILL.md

@@ -9,7 +9,7 @@ Finding a design flaw mid-build is information, not failure. Rethink amends the
 
 ## Steps
 
-1. **State the discovery.** Say what is wrong or new, and quote the evidence: the failing test, the output, the document line, or what the user said.
+1. **State the discovery.** Say what is wrong or new, and quote the evidence: the failing test, the output, the document line, or what the user said. When `cruze next` sent you here for findings decided `rethink`, those findings are the discovery: `cruze show <ref>` lists them in its ledger.
 2. **Classify it.** Pick the level from the table below, using the highest level the discovery touches. Pick its kind:
    - **Defect:** a Cruze step should have caught it.
    - **Discovery:** it is new information no step could have had.
@@ -19,20 +19,22 @@ Finding a design flaw mid-build is information, not failure. Rethink amends the
 4. **Amend that level,** following the level's section in [levels.md](levels.md). Settle any decision the amendment needs with the user, and record it as that level records decisions.
 5. **Keep completed work.** A ticked task stays ticked unless the amendment changes its owner, its files, or what it proves. Reopen each task that changed with `cruze task reopen T<n> "<what changed>"`. Its commits stay in history, and build redoes the task.
 6. **Re-approve what went stale.** Run `cruze status` and work from the top down. The amended document comes first, and the user approves it as its level says. Then take each feature or change it lists as `upstream changed`, whose own text you didn't edit:
-   - Read the diff of the elements it names, and check the work still holds against them. When it doesn't, amend it too, and the user approves it as an amended document.
+   - Run `cruze diff <ref>`. It shows each changed element's approved and current text, and whether the work's delta needs a rebase. Check the work still holds against it. When it doesn't, amend it too, and the user approves it as an amended document.
    - When it holds, re-stamp it with `cruze approve <ref> --restamp-unchanged`. The CLI refuses work whose own text changed, a project document, and a change with a task reopened since its approval; the user re-approves those.
 
    Tell the user, in one line each, what you re-stamped and why it still holds. They can object, and that document goes to them. A change's verification carries over when its own design didn't change.
 7. **Record the rethink.** Draft the entry and show it to the user in one line. When they confirm, run:
 
    ```sh
-   cruze journal add rethink --set level=<task|change|feature|architecture|vision> --set kind=<defect|discovery> \
+   cruze journal add rethink --set level=<task|detail|change|feature|architecture|vision> --set kind=<defect|discovery> \
      --set summary="<what changed>" --set wrong="<document and element, and what was wrong>" \
      --set found_by=<step> [--set missed_by=<step>] \
      --set agent="<the agent you run in>" [--item <ref>]
    ```
 
-   `found_by` is the step that found it. A defect also needs `missed_by`, the earliest step whose job was to catch it. Both take one of `envision`, `architect`, `research`, `design-review`, `walkthrough`, `plan`, `plan-review`, `build`, `code-review`, `verify`, `land`, `realign`, `improve`, `validate`, `check` or `user`. When a design review ran over the element and an item of its rubric in `.agents/skills/cruze-roles/design-reviewer.md` covers the gap, `missed_by` is `design-review`, not `architect`: a retro reads it to know which rubric to fix.
+   Name the feature or change with `--item` whenever the rethink amends one: a rethink recorded for it closes the findings decided `rethink` on it.
+
+   `found_by` is the step that found it. A defect also needs `missed_by`, the earliest step whose job was to catch it. Both take one of `envision`, `architect`, `research`, `design-review`, `walkthrough`, `plan`, `plan-review`, `build`, `code-review`, `verify`, `land`, `realign`, `improve`, `validate`, `check` or `user`. When a design review ran over the element and an item of its rubric, `.agents/skills/cruze-roles/design-rubric.md` or `.agents/skills/cruze-roles/plan-rubric.md`, covers the gap, `missed_by` is `design-review`, not `architect`: a retro reads it to know which rubric to fix.
 
 Done when `cruze status` shows every document approved and current, or names only work the user chose to leave for later.
 
@@ -41,6 +43,7 @@ Done when `cruze status` shows every document approved and current, or names onl
 | Level | Example | Amend | Then |
 | --- | --- | --- | --- |
 | Task | A helper belongs in a different file of the same module | Nothing. Record it with `cruze task deviation` | Carry on building. This is not a rethink, so record no rethink entry |
+| Detail | Build or verify needs a limit, timeout, message or error case | The element's text, with the code | The user approves it, with no review. Run from build or verify, as [levels.md](levels.md) says |
 | Change | A test plan row or a task's file is wrong, with no design change | `change.md`: its test plan or tasks | Plan review of the diff, then re-approve the change |
 | Feature | A use case needs a second port operation; a scenario is wrong | `feature.md`: its deltas and Changes table, or a standalone `change.md`'s deltas | Design review of the diff, walkthrough of the changed parts, then re-approve the feature and its changes |
 | Architecture | An entity boundary is wrong, or a new port is needed | `docs/architecture.md` directly, plus an ADR when it passes the ADR test | Design review of the diff when it changes an operation, port, error or `XC` rule, walkthrough of the diff, then `cruze approve architecture`, with `--replan` for built elements whose code must change |

package/skills/rethink/levels.md

@@ -1,15 +1,24 @@
 # Amending each level
 
+## Detail
+
+A detail settles a limit, timeout, buffer size, message or error case that an element of the work in progress doesn't give, with no new element, port operation or dependency, and no change to an approved scenario. Build and verify run it without leaving their step: one message length settled as a full rethink took 75 minutes.
+
+1. Ask the user, recommending a value and saying what the code then does.
+2. Amend the element where it lives, in the delta or `docs/architecture.md`, adding at most one failure scenario and its test plan row for a new error case. Run `cruze validate`; done when it reports no errors.
+3. Commit the text with the code and its test, naming the task. Tasks stay ticked.
+4. The user approves the amended document. Re-stamp what went stale, and record the rethink with `level=detail`, as the skill's steps 6 and 7 say.
+
 ## Change
 
 1. Edit the change's `## Test plan` or `## Tasks` so they are right. The scope doesn't change at this level; a scope change is a feature-level rethink.
 2. Run `cruze validate`. Done when it reports no errors for the change.
-3. Run the plan review from `.agents/skills/cruze-roles/SKILL.md` on the diff alone, with the design reviewer's plan rubric and `review=plan`.
+3. Run the plan review from `.agents/skills/cruze-roles/SKILL.md` on the diff alone, with the design reviewer's plan rubric, `.agents/skills/cruze-roles/plan-rubric.md`, and `review=plan`.
 4. Re-approve with `cruze approve <change> --by-agent` once the review has closed, as plan does.
 
 ## Feature
 
-1. Edit the feature's `## Spec delta`, `## Architecture delta` or `## Changes`. For a standalone change, edit its own deltas and scope. Write complete bodies, as `architect` does, and keep the scope rules.
+1. Edit the feature's `## Spec delta`, `## Architecture delta` or `## Changes`. Read the elements the discovery touches with `cruze show <ID>`, which prints the living body and this feature's version side by side, and the rest of `feature.md` when the amendment reaches beyond them. For a standalone change, edit its own deltas and scope. Write complete bodies, as `architect` does, and keep the scope rules.
 2. Run `cruze validate`. Done when it reports no errors for the feature or its changes.
 3. Run the design review from the roles skill on the diff alone, with `review=design`. Run the walkthrough of the changed parts, following `.agents/skills/cruze-architect/walkthrough.md`.
 4. Re-approve the feature. For each of its changes that shows as stale, check it against the diff. When the amendment touches the change's scope, test plan or tasks, update them to match, reopen touched tasks, run the plan review on the diff, and re-approve it with `cruze approve <change> --by-agent`. When it doesn't, re-stamp the change as the skill's step 6 describes.
@@ -25,8 +34,8 @@
    - **The current change**, when the rebuild belongs to its work. Add the element to the feature's Changes row for that change and to the change's `Builds`, then re-plan and re-approve the change.
    - **A prefactor**, otherwise. From an up-to-date main, run `architect "<prefactor>"`, which designs it as a standalone change, then `plan`, `build`, `verify` and `land` it before the current change continues.
 6. Run `cruze status`. Every document citing a changed element shows `upstream changed`:
-   - When the document's own delta changes that element, rewrite the delta so it keeps your amendment. `cruze approve` refuses it with `rebase-required` until you do. Then approve it with `--rebase <ID>`.
-   - Otherwise, check the document against the element's diff, and re-stamp it or amend it as the skill's step 6 describes.
+   - When the document's own delta still changes that element, rewrite the delta so it keeps your amendment. `cruze approve` refuses it with `rebase-required` until you do, and `cruze diff <ref>` names each such element. Then approve it with `--rebase <ID>`.
+   - Otherwise, check the document against `cruze diff <ref>`, and re-stamp it or amend it as the skill's step 6 describes. An element the feature already merged, with its delta entry unchanged since, needs no rebase: the living text now holds it, and later lands keep your amendment.
 
 ## Vision
 
@@ -37,9 +46,9 @@
 
 ## A conflict with living text
 
-`cruze approve` refuses a feature or standalone change with `rebase-required` when an element its delta changes was edited in the living docs since its last approval, by a rethink or another branch's land. `cruze land` refuses with `merge-conflict` for the same reason when the approval came first. Either way, the delta would overwrite that edit. Record the rethink at feature level.
+`cruze approve` refuses a feature or standalone change with `rebase-required` when an element its delta changes was edited in the living docs since its last approval, by a rethink, a realign or another branch's land, and the delta would still write that element: the work hasn't merged it yet, or has changed its delta entry since merging it. `cruze land` refuses with `merge-conflict` for the same reason when the approval came first. Either way, the delta would overwrite that edit. Record the rethink at feature level.
 
-1. Show the user the element's current text in `docs/architecture.md` or `docs/specs/`, and the feature's delta for it.
+1. Show the user `cruze diff <feature>`, which has the element's approved and current text, and the feature's delta for it.
 2. Rewrite the delta's body so that it holds both: their edit, and what this feature needs.
 3. Re-approve the feature with `cruze approve <feature> --rebase <ID>`. This records that the feature now builds on the current text.
 4. Re-approve the change that is landing, when it shows stale; its verification carries over. Then run `land` again.

package/skills/roadmap/SKILL.md

@@ -9,7 +9,7 @@ description: Orders the release's features and standalone changes into phases wi
 
 ## Steps
 
-1. **Read the state.** Read `docs/vision.md` (goals and feature map), `docs/roadmap.md` and `docs/architecture.md`, and run `cruze status`. The vision must be approved. When no roadmap exists, stop: project-scope `architect` creates the first one with the walking skeleton.
+1. **Read the state.** Read `docs/vision.md` (goals and feature map), `docs/roadmap.md`, and `docs/architecture.md` as "Reading it" in `.agents/skills/cruze-formats/reference/architecture.md` says, and run `cruze status`. The vision must be approved. When no roadmap exists, stop: project-scope `architect` creates the first one with the walking skeleton.
 2. **Pick the job.**
    - **Add an item:** a feature or standalone change the user wants in this release. Its slug comes from the feature map when it is there.
    - **Reorder or drop:** the order or scope of the release changed.
@@ -27,6 +27,7 @@ description: Orders the release's features and standalone changes into phases wi
 ## Adding an item
 
 - Place it in the earliest phase whose items don't block it. Name its blockers: an item blocks it when it builds an element this item extends, or delivers behaviour this item changes.
+- A prefactor restructures code that later items build on, so it goes first: each item it overlaps names it under `Blocked by`. The exception is an item already building, with a change planned or in progress, which the prefactor would rebuild under: the prefactor waits for it and names it under `Blocked by` instead. Put the order to the user either way. One project's realign put a prefactor behind a feature that hadn't started, and the user wanted it first.
 - Add its slug to the coverage row of each goal it serves.
 - A feature that isn't on the feature map gets there first: `cruze features add <slug> --summary <text> --goals <ids>`.
 

package/skills/roles/SKILL.md

@@ -9,7 +9,7 @@ A role is a prompt with fixed inputs and a report as its only output. It runs in
 
 | Role | File | Used by |
 | --- | --- | --- |
-| Design reviewer | [design-reviewer.md](design-reviewer.md) | architect, at project and feature scope; plan, for the plan review |
+| Design reviewer | [design-reviewer.md](design-reviewer.md), with [design-rubric.md](design-rubric.md) for a design or [plan-rubric.md](plan-rubric.md) for a plan | architect, at project and feature scope; plan, for the plan review |
 | Code reviewer | [code-reviewer.md](code-reviewer.md) | verify, for the code review |
 | Verifier | [verifier.md](verifier.md) | verify, to run the system |
 | Researcher | [researcher.md](researcher.md) | architect, for adopt-or-build decisions |
@@ -35,7 +35,7 @@ A review has at most two rounds. Only blockers can force the second one.
    - Its fix changes behaviour: it adds, removes or rewrites a requirement or scenario, or changes what a person sees or does beyond what the spec says. Making the code or the plan meet a scenario as written is not a change of behaviour.
    - Its fix changes a port, a port's `Operations` or a public contract that the approved design names.
    - Its fix changes another decision the grilling skill leaves to the user: a context, dependency direction or a dependency.
-   - You recommend anything but `fixed`: waiving, deferring or rejecting it, or a rethink because it needs a design change.
+   - You recommend anything but `fixed`: waiving, deferring or rejecting it, or a rethink because it needs a design change. A fix through a detail amendment is an exception too.
    - You would fix it differently from the reviewer's proposed fix.
 
    Every other finding is yours, blockers included: you fix it as the reviewer proposes. When `review.decide` in `.cruze/config.yaml` is `all`, every finding is an exception. Nits are a count, not findings: when a report lists any, they get no disposition and you don't bring them to the user.
@@ -45,10 +45,10 @@ A review has at most two rounds. Only blockers can force the second one.
    - `deferred`: it belongs to later work. When it is future scope, add it with `cruze features add <slug> --summary <text> --goals <ids>`.
    - `rejected`: the finding is wrong, with the reason.
 
-   A finding whose fix would change an approved element, such as one marked `Needs design change`, is never `deferred` or `waived`. Recommend `rethink` at that element's level now. Once the rethink is done and the code follows it, record the finding as `fixed`.
+   A finding whose fix would change an approved element, such as one marked `Needs design change`, is never `waived`. Recommend `fixed` through a detail amendment when it qualifies, as "Detail" in `.agents/skills/cruze-rethink/levels.md` says, otherwise `rethink` at that element's level now, or `deferred` for a concern later work can carry. Once the rethink is done and the code follows it, record the finding as `fixed`. When the user wants the rethink later, record it as `rethink` instead, with `--item` naming the feature or change it amends: `cruze next` and the build gate hold that work until a rethink is recorded for it.
 
    Then one line for each finding you are fixing yourself. When there are no exceptions, say what you are fixing and carry on without waiting. The user can object to any line until the work is approved, and that finding becomes an exception: revert its fix and let them decide it.
-5. **Record every disposition:** `cruze journal add disposition --set finding="<rubric item>: <summary>" --set disposition=<fixed|waived|deferred|rejected> --set reason="<reason>" --set review=<design|plan|code> --set decided=<agent|user>`, with the same `--item`. Use `decided=user` for each exception, once the user decides it, and `decided=agent` for each finding you fixed yourself. The CLI refuses `decided=agent` for anything but `fixed`. A recorded disposition is never raised again.
+5. **Record every disposition:** `cruze journal add disposition --set finding="<rubric item>: <summary>" --set disposition=<fixed|waived|deferred|rejected|rethink> --set reason="<reason>" --set review=<design|plan|code> --set decided=<agent|user>`, with the same `--item`. Use `decided=user` for each exception, once the user decides it, and `decided=agent` for each finding you fixed yourself. The CLI refuses `decided=agent` for anything but `fixed`. A recorded disposition is never raised again.
 6. Apply every `fixed` change, then run `cruze validate`. Done when it reports no errors.
 7. When a finding could be caught by a tool, such as a layering, naming or size rule, tell the user which `cruze check` rule or linter setting would catch it next time.
 

package/skills/roles/auditor.md

@@ -6,7 +6,7 @@ You compare a project's existing code and documents with what the installed Cruz
 
 - The notes to audit, from `cruze realign status`: each note's ID, `Rule`, `Ask` and `Migrate`.
 - In a full audit, the standards instead of notes: `.agents/skills/cruze-hexagonal-design/SKILL.md` and its language file, `.agents/skills/cruze-behavioural-testing/SKILL.md`, and `.agents/skills/cruze-formats/reference/architecture.md`. You audit one module, named with its `Path`.
-- `docs/architecture.md`, for the module map and the elements the code implements.
+- `docs/architecture.md`, for the module map and the elements the code implements: `cruze show --index <context>` lists them, and `cruze show <ID>` prints each.
 - The files in scope: every source and test file under the project's `source` and `tests` globs in `.cruze/config.yaml`, or under the module's `Path`.
 - The settled ledger, as `.agents/skills/cruze-roles/SKILL.md` defines it, and the earlier realign dispositions from `cruze journal list --event disposition`. Never raise a finding they waived.
 

package/skills/roles/code-reviewer.md

@@ -4,8 +4,8 @@ You review the code a change adds, before it lands. You work in two lanes. The s
 
 ## Inputs
 
-- The change's `change.md`, and the output of `cruze show <ref>`: the elements it builds, the scenarios it delivers, the settled decisions and the ledger. Read an element it lists as cited only when the diff calls it.
-- The diff under review, from `git diff <base>` for the base commit you are given.
+- The change's `change.md`, and the output of `cruze show <ref>`: the elements it builds, the scenarios it delivers, the settled decisions and the ledger. Read an element it lists as cited only when the diff calls it, with `cruze show <ID>`.
+- The diff under review, from `git diff <base>` for the base commit you are given. When the base is where an earlier verify stopped, review older code only where the diff changes what it does.
 - The ADRs in `docs/adr/`, and the specs in `docs/specs/` for the capabilities the change touches.
 - The references `cruze show` lists, at the sections the change's elements cite.
 - The settled ledger, as `.agents/skills/cruze-roles/SKILL.md` defines it, with the output of `cruze journal list --event disposition --item <ref>`.
@@ -29,10 +29,10 @@ Review against these items and nothing else. Each finding names one.
 5. **Placement.** Every file the diff adds or changes is where the architecture puts its owner, and matches the task's file targets or a recorded deviation.
 6. **Direction.** Dependencies point inward. No technology type crosses a port. Inbound adapters hold no domain rules or workflow.
 7. **Size.** No file holds two responsibilities, and none passes its budget without a recorded exception. No file was split by length alone, leaving one responsibility across files, and no code is bent to fit a budget, such as a type alias, a string where an error type belongs, types merged or a function placed away from its owner to stay under a limit.
-8. **Idiom.** The code is idiomatic for the language, uses its standard tooling, and follows the language file's rules, including where tests live. Tests reuse the fixtures and harnesses in the test support module rather than redefining them.
+8. **Idiom.** The code is idiomatic for the language, uses its standard tooling, and follows the language file's rules, including where tests live. Tests reuse the fixtures and harnesses in the test support module rather than redefining them. Each `expect`, `unwrap` or panic in the diff has a reason its case can't happen; one a caller, the clock or a concurrent call can reach is a finding.
 9. **Libraries.** Nothing hand-writes what a mature library does without a recorded `build` decision, and every new dependency has a recorded approval. No code works around a dependency or a feature: hand-written code, a shell command or a less idiomatic construct chosen because the clean one needs a dependency is a finding.
 10. **Contracts.** Each adapter honours its port's `Operations`, and each fake passes the same contract tests as the real adapter.
-11. **Deviations.** Each deviation the change recorded is a choice build may make on its own: a private helper or a new file inside the owner's module, a `check.exceptions` entry, a fixture in the test support module, or two tasks swapped. A deviation that added an element, port operation or scenario, wrote a file outside the owner's module, changed an approved scenario's behaviour or its test, worked around a dependency or a feature, or settled a limit, timeout, message or error case the design doesn't give, needed a rethink: a blocker, with `Needs design change` naming the element. Two projects recorded 13 such deviations.
+11. **Deviations.** Each deviation the change recorded is a choice build may make on its own: a private helper or a new file inside the owner's module, a `check.exceptions` entry, a fixture in the test support module, or two tasks swapped. A deviation that added an element, port operation or scenario, wrote a file outside the owner's module, changed an approved scenario's behaviour or its test, worked around a dependency or a feature, or settled a limit, timeout, message or error case the design doesn't give, needed a design amendment: a blocker, with `Needs design change` naming the element.
 
 ## Findings
 
@@ -47,7 +47,8 @@ Each finding has this shape:
 - Needs design change: <the approved element whose text the fix must change, such as a port's `Operations`, or `no`>
 ```
 
-- A **blocker** means a scenario fails or is untested, a protected test was weakened, a layering rule is broken, an unapproved dependency was added, or an adapter can't honour its port's `Operations`. A finding that needs a design change is a blocker. Everything else is a **concern**.
+- A **blocker** means a scenario fails or is untested, a protected test was weakened, a layering rule is broken, an unapproved dependency was added, or an adapter can't honour its port's `Operations`. A failure is also a blocker when a user or client the design serves reaches it in ordinary use, their mistakes and failing disks, networks and peers included, and it loses or corrupts data, crashes, hangs, spins, or holds up someone else's work.
+- Everything else is a **concern**, even when its fix needs a design change, such as a failure only hand-made input reaches that harms only its sender: in one change, such cases were the only blockers of two verifies in a row. Say who reaches the failure, and how.
 - List every blocker. List at most 5 concerns, or one per 5 tasks of the change when that is more, the most important first. Count the rest as nits: give only their number, never their text. Report only what would go wrong: no concerns is a valid report, and a small change usually has few.
 - Drop any finding that contradicts the settled ledger. The only exception is a blocker with new evidence, which you mark `New evidence:` and explain.
 - When a finding could be caught mechanically, add `Check: <the cruze check rule or linter setting that would catch it>`.

package/skills/roles/design-reviewer.md

@@ -8,7 +8,7 @@ You review a design, or a change's plan, before any code exists. You find the pl
   - Feature scope: the feature's `feature.md`, and the output of `cruze show <ref>` for the elements its delta cites, each with where it sits, and the settled ledger.
   - Project scope: `docs/architecture.md`, `.cruze/config.yaml` and `docs/roadmap.md`, plus the walking-skeleton change once it exists.
   - A plan: the change's `change.md`, the output of `cruze show <ref>`, and the output of `cruze status --overlap --change <ref>`.
-- The living docs it builds on: `docs/vision.md`, `docs/glossary.md`, the ADRs in `docs/adr/`, the specs in `docs/specs/` that the artifact cites, and, from `docs/architecture.md`, its Overview, Dependency rules, Cross-cutting concerns and Decisions sections plus each element `cruze show` lists as cited. Read the whole architecture only at project scope.
+- The living docs it builds on: `docs/vision.md`, `docs/glossary.md`, the ADRs in `docs/adr/`, the specs in `docs/specs/` that the artifact cites, and, from `docs/architecture.md`, its Overview, Dependency rules, Cross-cutting concerns and Decisions sections plus each element `cruze show` lists as cited. Read any other element with `cruze show <ID>`, and find what exists with `cruze show --index`. Read the whole architecture only at project scope.
 - The settled ledger, as `.agents/skills/cruze-roles/SKILL.md` defines it, with the output of `cruze journal list --event disposition --item <ref>`.
 - The output of `cruze validate`.
 - The references `cruze show` lists, from `references:` in `.cruze/config.yaml`: read the sections the design cites or relies on.
@@ -16,46 +16,10 @@ You review a design, or a change's plan, before any code exists. You find the pl
 
 ## Rubric
 
-Review against these items and nothing else. Each finding names one.
+Review against one rubric and nothing else, and read only that one. Each finding names one of its items.
 
-1. **Behaviour.** Every requirement has at least one scenario. Every scenario has concrete values, one WHEN, and a THEN a person could check. Failure behaviour the user will meet has its own scenario.
-2. **Seams.** Every scenario can be driven through a use case, or through an inbound adapter when the outcome is what that adapter shows. Every driven port the use case needs can be faked.
-3. **Placement.** Every new or changed element with code has a `Module` whose `Layer` fits its role and a `File` with a real path. No generic modules, and no file is likely to hold two responsibilities. The layout is the one normal for the kind of system and the language, and every layer, module, package or target split beyond a context's `core` and its adapters has a recorded reason. Every element, fact and value serves a requirement in scope or a `Future` fact the feature map calls for. Anything reserved for a need nobody stated is a finding.
-4. **Direction.** Every dependency points inward and is allowed by the `RULE` elements and the `layers:` in `.cruze/config.yaml`.
-5. **Adopt or build.** Every component that isn't domain logic has an adopt-or-build decision with a reason, and every new dependency is named with the features the design uses. Every type, trait, macro, framework or tool the design names from outside the project comes from a dependency and feature the design approves, declared by each crate, package or target that uses it, test support included, and allowed by the import rules in `XC` and the `layers:` in `.cruze/config.yaml`. A choice whose reason is avoiding a dependency, a crate or a feature, where the idiomatic design needs one, is a concern: name the idiomatic design. Every command the design spells out, such as a CI step, is spelled as that version's `--help` or source shows it. A claim the design relies on that the research left unverified is a blocker.
-6. **Contracts.** Every new or changed port's `Operations` state what each operation guarantees, how it fails, and who owns cleanup. Check each use case and each port operation for the values build would otherwise have to pick: a named error for every failure a caller can meet, where a panic, an `expect` or "caller error" counts as missing; a number for every timeout, limit, buffer and poll interval; what a caller observes after each state transition, and what happens to queued or in-flight work at it; and one owner for every message a scenario quotes. Each one missing is a blocker: two projects settled 35 of them during build, as deviations.
-7. **Flows.** The key scenarios have a `FLOW` whose participants are all in its `Elements`, including the failure paths the scenarios need.
-8. **Consistency.** The design agrees with `docs/architecture.md`, the accepted ADRs, the references and what earlier changes landed, or changes them explicitly through a `MODIFIED` operation or a new ADR. Its own elements agree with each other. Check every pair, not a sample:
-   - each use case's `Output` and `Errors` against the `FLOW`s that serve it and the `XC` rules that apply to it;
-   - each adapter's duties against the port it implements and the `XC` rules it follows;
-   - each guarantee, such as "always fits" or "never returns", against the limits and failures that bound it;
-   - each `XC` rule against the other `XC` rules, the `RULE` elements and the `layers:` in `.cruze/config.yaml`, such as a logging rule that every module logs against a build rule that forbids the logging import;
-   - each pair of use cases that change the same state, for an interleaving that leaves it wrong, against the concurrency rule in `XC`;
-   - at feature scope, the prose in `docs/architecture.md` the delta makes untrue, such as an Overview sentence or a `D<n>` line describing an element the delta splits or replaces.
-   - each new or renamed operation, method or builder step against the others the same type, trait or caller reaches, for two names a caller can't tell apart, such as an `events` method beside an `events` trait method the type also implements.
-9. **Slicing.** Each change is a vertical slice that delivers scenarios end to end and can land on its own. The order respects `Depends on`, and the first change proves the design end to end. Each change carries enough work to be worth its own plan review, code review and verify: changes that build one or two elements each on the same adapters or screens, in a chain, are one change split too fine. A change that one verifier run can't hold is split too coarse. A `change-too-small`, `change-too-large` or `feature-size` warning from `cruze validate` is a finding, unless a decision records the user accepting it. A change `Builds` an element only when its delivered scenarios prove the whole body; an element whose duties arrive in several changes is split into elements that each arrive whole. `Depends on` names every earlier change that builds something this change's scenarios need. At project scope, the roadmap starts with the walking skeleton, and every goal in the release is covered.
-10. **Ambiguity.** Name each point where a fresh implementer could reasonably build something different from what the user expects.
-11. **Flow control and recovery.** Follow each message, request and event from its source to its consumer through every task, channel and queue the design names, against `.agents/skills/cruze-hexagonal-design/runtime.md`. Check:
-   - each bounded queue or buffer: what a sender does when it is full, and which other work waits meanwhile. One slow peer, link, subscriber or consumer holds up only its own work unless a decision says otherwise, so one queue or one task serving several peers needs a reason. A limit meant to tell a stalled consumer from a burst says how it tells them apart;
-   - each place several sources feed one consumer: the order it takes them in, so that none starves;
-   - each asynchronous result: how it reaches the request that waits for it, including across a reconnect or a retry;
-   - each recovery, such as a reconnect, resubscribe, relist or retry: its schedule and limit, what happens when the recovery itself fails, what is lost between the failure and the recovery and how the consumer learns of it, and the order of steps that loses nothing, such as subscribing before relisting;
-   - each loop, task and retry: what stops it, and what shutdown does with the work it holds;
-   - each value the design compares with observed state: an adapter can observe it, or the difference is reported for good;
-   - each exclusive resource, such as a socket, a device or kernel state: what happens when a second instance or caller claims it.
-
-   Each one missing that a scenario or an `XC` rule depends on is a blocker: in two projects, 7 of 14 defect rethinks after a design review were one of these, found as late as verify.
-
-## Plan rubric
-
-When the artifact is a change's plan, review against these items instead.
-
-1. **Test plan.** Every delivered scenario has a `behaviour` row at a real seam, with its test file. Every port that a built adapter implements has a `contract` row. Seams need fakes of driven ports only, never mocks of internal code.
-2. **Tasks.** Every task names one owner and file paths the architecture assigns to that owner. Every scope ID is proved by a task. Each task is small enough to build red to green and commit on its own. A task that changes a signature, default or setting lists every file whose callers it breaks, including tests that start the real binary. A task that adds a module, file or dependency lists the file that declares it, such as a crate root, a `mod.rs`, a package manifest or an Xcode project. A rule, text, format or conversion that several elements apply has one owning file, and each later task that applies it names that file as a callee rather than restating it. An accessor, variant or type arrives in the task whose code first handles, matches or constructs it, never in the task that only tests it.
-3. **Order.** Tasks run from the inside out, domain before ports, use cases and adapters, so each task's test can fail first and then pass. A test sits in the task that builds the behaviour it checks: a test that an earlier task's code already passes is in the wrong task. A break the plan names is a behaviour the task's code could get wrong, not an edit that may not compile. The last tasks wire the composition root.
-4. **No design.** Nothing in the plan changes the architecture or the specs. A plan that needs a new element, operation or scenario goes back to `architect` or `rethink`.
-5. **Risks and overlap.** The riskiest task is named, with how it is checked. Overlap with work on other branches is resolved or accepted.
-6. **Ambiguity.** Name each task a fresh implementer could reasonably build differently from what the plan means.
+- A design, at project scope or of a feature or a standalone change: `.agents/skills/cruze-roles/design-rubric.md`.
+- A change's plan: `.agents/skills/cruze-roles/plan-rubric.md`.
 
 ## Findings
 

package/skills/roles/design-rubric.md

@@ -0,0 +1,40 @@
+# Design rubric
+
+The design reviewer's rubric for a design: the architecture at project scope, or the design of a feature or a standalone change. Review against these items and nothing else. Each finding names one.
+
+1. **Behaviour.** Every requirement has at least one scenario. Every scenario has concrete values, one WHEN, and a THEN a person could check. Failure behaviour the user will meet has its own scenario.
+2. **Seams.** Every scenario can be driven through a use case, or through an inbound adapter when the outcome is what that adapter shows. Every driven port the use case needs can be faked.
+3. **Placement.** Every new or changed element with code has a `Module` whose `Layer` fits its role and a `File` with a real path. No generic modules, and no file is likely to hold two responsibilities. The layout is the one normal for the kind of system and the language, and every layer, module, package or target split beyond a context's `core` and its adapters has a recorded reason. Every element, fact and value serves a requirement in scope, or a `Future` fact the feature map or a `LATER` capability calls for. Anything reserved for a need nobody stated is a finding, and so is anything built, rather than left room for, for a `LATER` capability.
+4. **Direction.** Every dependency points inward and is allowed by the `RULE` elements and the `layers:` in `.cruze/config.yaml`.
+5. **Adopt or build.** Every component that isn't domain logic has an adopt-or-build decision with a reason, and every new dependency is named with the features the design uses. Every type, trait, macro, framework or tool the design names from outside the project comes from a dependency and feature the design approves, declared by each crate, package or target that uses it, test support included, and allowed by the import rules in `XC` and the `layers:` in `.cruze/config.yaml`. A choice whose reason is avoiding a dependency, a crate or a feature, where the idiomatic design needs one, is a concern: name the idiomatic design. Every command the design spells out, such as a CI step, is spelled as that version's `--help` or source shows it. A claim the design relies on that the research left unverified is a blocker.
+6. **Contracts.** Every new or changed port's `Operations` state what each operation guarantees, how it fails, and who owns cleanup. Check each use case and each port operation for the values build would otherwise have to pick: a named error for every failure a caller can meet, where a panic, an `expect` or "caller error" counts as missing; a number for every timeout, limit, buffer and poll interval; what a caller observes after each state transition, and what happens to queued or in-flight work at it; and one owner for every message a scenario quotes. Each one missing is a blocker: two projects settled 35 of them during build, as deviations.
+7. **Flows.** The key scenarios have a `FLOW` whose participants are all in its `Elements`, including the failure paths the scenarios need.
+8. **Consistency.** The design agrees with `docs/architecture.md`, the accepted ADRs, the references and what earlier changes landed, or changes them explicitly through a `MODIFIED` operation or a new ADR. Its own elements agree with each other. Check every pair, not a sample:
+   - each use case's `Output` and `Errors` against the `FLOW`s that serve it and the `XC` rules that apply to it;
+   - each use case against every port operation it calls: it says what it does with each refusal that operation can answer, from its `Operations` and the use case behind it, and lists the port under `Uses`. A new use of an existing operation, such as the clock stamping a new kind of time, is a `MODIFIED` port whose `Operations` name the use;
+   - each adapter's duties against the port it implements and the `XC` rules it follows;
+   - each guarantee, such as "always fits" or "never returns", against the limits and failures that bound it;
+   - each `XC` rule against the other `XC` rules, the `RULE` elements and the `layers:` in `.cruze/config.yaml`, such as a logging rule that every module logs against a build rule that forbids the logging import;
+   - each pair of use cases that change the same state, for an interleaving that leaves it wrong, against the concurrency rule in `XC`;
+   - at feature scope, the prose in `docs/architecture.md`, the ADRs and the feature itself that the delta makes untrue, such as an Overview sentence, a `D<n>` line describing an element the delta splits or replaces, or any sentence stating a rule the delta retires;
+   - each message or value a scenario quotes from code already built, such as an error's printed form or a revision every write advances, against the code that produces it;
+   - each new or renamed operation, method or builder step against the others the same type, trait or caller reaches, for two names a caller can't tell apart, such as an `events` method beside an `events` trait method the type also implements.
+9. **Slicing.** Each change is a vertical slice that delivers scenarios end to end and can land on its own. The order respects `Depends on`, and the first change proves the design end to end. Each change carries enough work to be worth its own plan review, code review and verify: changes that build one or two elements each on the same adapters or screens, in a chain, are one change split too fine. A change that one verifier run can't hold is split too coarse. A `change-too-small`, `change-too-large` or `feature-size` warning from `cruze validate` is a finding, unless a decision records the user accepting it. A change `Builds` an element only when its delivered scenarios prove the whole body; an element whose duties arrive in several changes is split into elements that each arrive whole. `Depends on` names every earlier change that builds something this change's scenarios need. At project scope, the roadmap starts with the walking skeleton, and every goal in the release is covered.
+10. **Ambiguity.** Name each point where a fresh implementer could reasonably build something different from what the user expects.
+11. **Flow control and recovery.** Follow each message, request and event from its source to its consumer through every task, channel and queue the design names, against `.agents/skills/cruze-hexagonal-design/runtime.md`. Check:
+   - each bounded queue or buffer: what a sender does when it is full, and which other work waits meanwhile. One slow peer, link, subscriber or consumer holds up only its own work unless a decision says otherwise, so one queue or one task serving several peers needs a reason. A limit meant to tell a stalled consumer from a burst says how it tells them apart;
+   - each place several sources feed one consumer: the order it takes them in, so that none starves;
+   - each asynchronous result: how it reaches the request that waits for it, including across a reconnect or a retry;
+   - each recovery, such as a reconnect, resubscribe, relist or retry: its schedule, its limit and when that count resets, what happens when the recovery itself fails, what is lost between the failure and the recovery and how the consumer learns of it, and the order of steps that loses nothing, such as subscribing before relisting;
+   - each loop, task and retry: what stops it, and what shutdown does with the work it holds;
+   - each value the design compares with observed state: an adapter can observe it, or the difference is reported for good;
+   - each exclusive resource, such as a socket, a device or kernel state: what happens when a second instance or caller claims it.
+
+   Each one missing that a scenario or an `XC` rule depends on is a blocker: in two projects, 7 of 14 defect rethinks after a design review were one of these, found as late as verify.
+12. **Long-term intent.** Check the design against `## Principles` and `## Must stay possible` in `docs/vision.md`:
+   - each principle: the design follows it, or the vision's row was amended for this design and approved;
+   - each `LATER` capability, whatever its area: nothing in the design, such as a fixed set, a single owner or a one-way protocol, rules it out; and where the design touches its area, it leaves the room the row names, in a `Future` fact that cites the ID;
+   - each part of the user's input handed to this work, as the Notes section of `cruze show` lists it, or `cruze show --notes architect` at project scope: settled with the user, or the design doesn't rest on it;
+   - each settled decision of the design that states long-term intent, such as "eventually" or "later": it is a `LATER` row in the vision, since the decision is archived when the work lands.
+
+   A departure from a principle with no amendment, a `likely` capability closed off, or a design resting on an open hand-off row, is a blocker; a `possible` one closed off is a concern.

package/skills/roles/plan-rubric.md

@@ -0,0 +1,11 @@
+# Plan rubric
+
+The design reviewer's rubric for a change's plan. Review against these items and nothing else. Each finding names one.
+
+1. **Test plan.** Every delivered scenario has a `behaviour` row at a real seam, with its test file. Every port that a built adapter implements has a `contract` row. Seams need fakes of driven ports only, never mocks of internal code.
+2. **Tasks.** Every task names one owner and file paths the architecture assigns to that owner. Every scope ID is proved by a task. Each task is small enough to build red to green and commit on its own. A task that changes a signature, default or setting lists every file whose callers it breaks, including tests that start the real binary. A task that adds a module, file or dependency lists the file that declares it, such as a crate root, a `mod.rs`, a package manifest or an Xcode project, and the lockfile for a dependency. A task that adds a field lists every file with a literal of its type that names all the fields. A rule, text, format or conversion that several elements apply has one owning file, and each later task that applies it names that file as a callee rather than restating it. An accessor, variant or type arrives in the task whose code first handles, matches or constructs it, never in the task that only tests it.
+3. **Order.** Tasks run from the inside out, domain before ports, use cases and adapters, so each task's test can fail first and then pass. A test sits in the task that builds the behaviour it checks: a test that an earlier task's code already passes is in the wrong task. A break the plan names is a behaviour the task's code could get wrong, not an edit that may not compile. The last tasks wire the composition root.
+4. **No design.** Nothing in the plan changes the architecture or the specs. A plan that needs a new element, operation or scenario goes back to `architect` or `rethink`.
+5. **Risks and overlap.** The riskiest task is named, with how it is checked, and that check reaches the failure rather than a value a clamp or default hides. Overlap with work on other branches is resolved or accepted.
+6. **Ambiguity.** Name each task a fresh implementer could reasonably build differently from what the plan means.
+7. **Prefactor.** For a change that delivers no scenarios and rebuilds built elements, as "A prefactor" in `.agents/skills/cruze-plan/SKILL.md` describes: `## Risks` names the existing tests that reach each rebuilt element, and the command that runs them; no task adds, edits or deletes a test, except one that pins current behaviour before the restructuring; and no item's visibility or public surface grows beyond what its new callers need.

package/skills/roles/surveyor.md

@@ -6,7 +6,8 @@ You survey existing code for structure that departs from Cruze's current standar
 
 - What to survey: the system's layout, or one module, named with its `Path`.
 - The standards: `.agents/skills/cruze-hexagonal-design/SKILL.md`, `.agents/skills/cruze-hexagonal-design/shapes.md`, the language file for the project's language when one exists, and `.agents/skills/cruze-behavioural-testing/SKILL.md`.
-- `docs/architecture.md`, for the module map and the elements the code implements, and `.cruze/config.yaml`.
+- `docs/architecture.md`, for the module map and the elements the code implements, which `cruze show --index` lists and `cruze show <ID>` prints, and `.cruze/config.yaml`.
+- `## Principles` and `## Must stay possible` in `docs/vision.md`: why parts of the design exist that no current feature uses yet.
 - The files in scope: for the layout, the build manifests, such as `Cargo.toml` or `Package.swift`, and each module's `Path`; for a module, every source and test file under its `Path`.
 - The journal, landed work included: the output of `cruze journal list --event deviation --all`, `cruze journal list --event rethink --all` and `cruze journal list --event disposition --all`.
 - The settled ledger, as `.agents/skills/cruze-roles/SKILL.md` defines it, and the earlier `improve` and `realign` dispositions. Never raise a candidate they waived.
@@ -18,7 +19,7 @@ You survey existing code for structure that departs from Cruze's current standar
 3. **The journal.** Find the deviations, rethinks and review findings that name a file in scope, and group them by cause. A cause that recurs is friction.
 4. **The history.** Run `git log --format=%h --name-only -n 300 -- <Path>`. Name the files outside the module that change in the same commits as its files in more than half of those commits; a boundary there is often in the wrong place. Name the files that change most.
 5. **One operation.** Pick one representative operation the module serves, and list the files a reader opens to follow it from the inbound adapter to the outbound one. Note modules that only forward calls, and pairs of modules that own one responsibility between them.
-6. **Shape each candidate.** Give the smallest target that meets the standard or removes the friction, and say whether it changes the text of an element in `docs/architecture.md`. A target keeps behaviour, keeps small files, and keeps every technology behind a port.
+6. **Shape each candidate.** Give the smallest target that meets the standard or removes the friction, and say whether it changes the text of an element in `docs/architecture.md`. A target keeps behaviour, keeps small files, and keeps every technology behind a port. It follows every principle and keeps the room each `LATER` capability needs; when removing something would close one off, name the capability, and leave the choice to the user.
 
 Done when every file in scope was read, and every candidate has evidence.