@printpractical/cruze 0.0.13 → 0.0.14

package/skills/next/SKILL.md

@@ -1,31 +0,0 @@
----
-name: cruze-next
-description: Says which Cruze step to run next and why, from the project's computed status and the current branch.
----
-
-# Next
-
-Next reads the project's state and says what to do now. The CLI works it out from content, so the answer is the same for every agent and every run.
-
-## Steps
-
-1. **Ask the CLI.** Run `cruze next` and read its JSON: the step, what it works on, the reason, and any other work that could proceed.
-2. **Add the detail.** Run `cruze status` when the reason mentions approvals, and quote the documents and elements that changed.
-3. **Answer** in three lines or fewer: the step to run, with its target, why it is next, and what else is in flight on other branches. Say that the step runs in a new session, so its context starts empty. Don't start the step unless the user asks you to.
-
-## What the steps mean
-
-| Step | Run |
-| --- | --- |
-| `envision` | `envision`, at project scope, or `envision "<target>"` for a roadmap feature |
-| `architect` | `architect` at project scope, `architect "<feature>"`, or `architect "<target>"` as a tweak |
-| `roadmap` | `roadmap`: approve the ordering, or close a finished release |
-| `plan` | `plan` for the named change |
-| `build` | `build`, on this branch |
-| `verify` | `verify`, on this branch |
-| `land` | `land`, on this branch |
-| `rethink` | `rethink`: something approved changed, and the work citing it must be reviewed |
-| `realign` | `realign`: the installed Cruze expects more of existing code than it meets |
-| `switch-branch` | Switch to the named branch, where that change is built |
-
-When the user asks about something `cruze next` didn't name, point them to `triage` for a bug, `explore` for an idea, or `improve` for existing code whose structure they want to change.

package/skills/plan/SKILL.md

@@ -1,62 +0,0 @@
----
-name: cruze-plan
-description: Turns the next change into a test plan and ordered tasks with file targets, reviews the plan in a fresh context, and approves it on the branch that will build it once the review closes, leaving you to object or go straight to build.
----
-
-# Plan
-
-Plan turns one designed change into work an implementer can do without guessing: which test proves each scenario, at which seam, and which file each task writes. Every change arrives from `architect`, so plan makes no design decisions. A plan that needs one sends the change back.
-
-## Steps
-
-1. **Find the change.** Run `cruze next`. Plan the change it names, or the one the user names. It is either a feature's next change, whose row has no folder yet and whose dependencies have landed, or a standalone change that `architect` designed. Done when you can name the change and its feature.
-2. **Check what it builds on.** `cruze status` must show the architecture approved and current, along with the feature when there is one. When something isn't, stop and name the step that fixes it, as `cruze next` does.
-3. **Start its branch.** From an up-to-date main that holds every change this one depends on, create a branch named for the change, such as `open-console-local-serial`, and switch to it. A branch holds one active change.
-4. **Create the change.**
-   - For a feature's change, run `cruze new change <slug> --feature <feature> --title "<title>"`. It copies the scope from the feature's Changes row.
-   - A standalone change already exists; plan its empty test plan and tasks.
-5. **Load the standards.** Read these, and follow them for the rest of this step:
-   - `.agents/skills/cruze-behavioural-testing/SKILL.md`
-   - `.agents/skills/cruze-hexagonal-design/SKILL.md`, and its language file when one exists for the project's language
-   - `.agents/skills/cruze-formats/reference/work-items.md`
-6. **Read the design it builds.** Run `cruze show <ref>` and read its output: the full body of every element in the scope, every scenario it delivers, the settled decisions, the ledger and the references. Read an element it lists as cited only when a task will call it, with `cruze show <ID>`. Don't read `docs/architecture.md` or `feature.md` whole: two projects read a 40k-word architecture about 150 times each.
-7. **Check for overlap.** Run `cruze status --overlap --change <ref>`. For each change on another branch that touches the same elements, tell the user which elements are shared and which change should land first. Record the answer under `## Risks`.
-8. **Write the test plan.** Follow [test-plan.md](test-plan.md). Done when every delivered scenario has a `behaviour` row and every port a built adapter implements has a `contract` row.
-9. **Write the tasks.** Follow [tasks.md](tasks.md). Done when every scope ID is proved by a task and every task line matches the grammar.
-10. **Record decisions and risks.** Put task-level choices you made under `## Settled decisions`. Under `## Risks`, name the riskiest task and how its test catches the failure. Open each check you name and confirm it reaches the failure: the test asserts the value at risk rather than one a clamp or default hides, the lint is enabled, and the command prints what you say it shows. When no check does, name a review of the diff. Remove every template guide.
-11. **Validate.** Run `cruze validate`. Done when it reports no errors for the change.
-12. **Review the plan.** Commit the plan, then run the review in `.agents/skills/cruze-roles/SKILL.md` with the design reviewer and its plan rubric, `.agents/skills/cruze-roles/plan-rubric.md`, `review=plan`, and `--item <ref>`.
-13. **Approve.** For a feature's change, run `cruze approve <ref> --by-agent` on this branch and quote its result. The plan carries no design of its own, so once its review has closed, with no blocker open and a disposition for every finding, you approve it for the user. A standalone change, such as the foundation or a prefactor, carries its own design, so show the user the plan and ask them to approve it with `cruze approve <ref>`. The approval binds the change to the branch. When it refuses with `plan-review-open`, do what it names. When it refuses with `size-unaccepted`, the plan has more tasks than `changes.max_tasks`: split the change through `rethink` at feature level, or, when the user accepts the size, list the change under `changes.exceptions` in `.cruze/config.yaml` with their reason and approve again. A blocker still open after round 2 goes to the user, and once they decide it, they approve the plan themselves with `cruze approve <ref>`.
-14. **Commit** with a message such as `docs: plan <change>`.
-
-## When the plan needs design
-
-Stop planning when you find you need any of these:
-
-- a new element, or a new operation on a port;
-- a file the architecture doesn't assign to the owner;
-- a scenario that isn't in the spec delta;
-- a dependency that isn't in `## Adopt or build`.
-
-Say what is missing and why, then send the change to `rethink` at feature level. For a standalone change, that means its own deltas. Never add design to `change.md`.
-
-## A prefactor
-
-A prefactor changes structure, not behaviour, so it delivers no scenarios and its tasks have no red step. The tests that already reach what it rebuilds are its safety net. Its plan differs in three places:
-
-- **Test plan:** no `behaviour` row. Keep the `contract` row of each port a rebuilt adapter implements, naming its existing test file.
-- **Risks:** list the existing test files that reach each element it rebuilds, and the command that runs them. They pass before the first task and after every task, and no task edits them. When nothing reaches an element, the first task pins its current behaviour with a test that passes from the start.
-- **Tasks:** each task moves one owner and leaves those tests green. Each item keeps the visibility it had, widened only as far as its new callers need: one prefactor's only review finding was visibility left wider than it had to be.
-
-The plan review checks these with the plan rubric's Prefactor item.
-
-## The foundation
-
-The foundation change, a project's first, also makes CI and the project's tooling real. Its plan adds:
-
-- `commands:` in `.cruze/config.yaml`: the format, lint, build, test and run commands, as the language's standard tooling runs them. When some tests are much slower than the rest, such as UI or device tests, `test` runs the fast tier and `test_full` the whole suite, so build can run `test` after every task.
-- A task that adds the language's format, lint, build and test steps to CI (`.github/workflows/ci.yml`), before the Cruze steps `cruze init` put there. The task proves the flow its smoke test runs.
-
-## Next step
-
-Show the user the test plan table, the tasks in order and the risks, and say the plan is approved, or, for a standalone change, ask them to approve it. They can object, and you amend the plan, run its review on the diff, and approve again. Otherwise the next step is `build`, on this branch, in a new session so its context starts empty.

package/skills/plan/tasks.md

@@ -1,35 +0,0 @@
-# Writing the tasks
-
-A task is one owner, the files it writes, and the IDs it proves. Build does them in order, one red-to-green cycle and one commit each. The grammar and the proving rules are in `.agents/skills/cruze-formats/reference/work-items.md`.
-
-1. **List the owners.** Take every element in the scope, and the owner in code that each one names, from its `File` fact. Add the owners the test plan needs that aren't elements, such as a fake, a test support module or the CI workflow.
-2. **Order from the inside out.**
-   - Domain types first, then the ports they need.
-   - Then the use cases, then the adapters, then the inbound adapter.
-   - The composition root comes last.
-   - Put fakes just before the first task whose test needs them.
-   - Each task's test can fail first and then pass, using only what earlier tasks built.
-   - Put each test in the task that builds the behaviour it checks. When an earlier task's code would already pass a later task's test, such as a failure path the earlier task had to handle, move the test into the earlier task.
-   - A test that expects a default or empty result, such as no prompt, an empty list, `nil` or `0`, passes against a stub that returns it. Name in the task the break it is first seen failing against, as the wrong behaviour rather than an edit to the code, such as "fails against a model that always shows the prompt". Build may use any break that compiles and turns the same assertion red.
-   - When the project's lint rejects unused code, such as `cargo clippy -- -D warnings`, put each new item, private and crate-visible ones included, in the task of its first production caller. A test doesn't count as a caller: built earlier, the item fails the lint, and built later, its caller's task can't compile. Each task then commits green on its own.
-   - 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. When a later task's `match` would pull in a variant, the variant belongs to that task. Two projects built 13 items in a task other than the planned one.
-3. **Write one line per task:**
-
-   ```markdown
-   - T3: `ConsoleSession` in `src/access/domain/console_session.rs`, proves ENT-access.console-session
-   - T7: `OpenConsole` in `src/access/app/open_console.rs`, proves UC-access.open-console, SCN-access.direct-serial
-   ```
-
-   - Owner and paths in backticks. Every path is a file the architecture assigns to that owner, or a test or support file. List the test support files the task extends, such as a shared harness or fixture, so its tests reuse them.
-   - When a task adds a module, a file or a dependency, list the file that declares it, such as the crate root or `mod.rs`, the package manifest, or the Xcode project. A task that adds a dependency or a feature of one also lists the lockfile, and names the `## Adopt or build` row that approves it.
-   - A task proves the elements it builds, and each scenario whose test goes green in it.
-   - A task that only sets up tooling proves the flow or scenario its checks run.
-4. **Find the owners.** For each rule, text, format or conversion a task's element applies, such as a message, a path format, a rounding or a name check, search the code and the other tasks for every place that applies it. Give it one owner: when an earlier task's owner already holds it, the later task's line names that file as a callee rather than building the rule again. Done when no rule is written in two places. Two projects wrote 20 rules twice and moved them at code review.
-5. **Find the callers.** For each signature, default or setting a task changes, search the code for every use of it, including tests that start the real binary or read the setting. A new field breaks every literal of its type that names all the fields, so search for `<Type> {` too. Add each file that must change to the task. Done when no task will need a file it doesn't list.
-6. **Size each task.** A task writes one owner, with its tests, in one sitting. When an owner would take several steps, such as a use case with many scenarios, split it into tasks that each prove a subset of the scenarios.
-   - When a task would give an existing file a second responsibility, name the new file in the task, named for what it owns. Never plan a split by line or type count: a file that grows with its one responsibility stays whole, and when it passes a budget, build lists it under `check.exceptions` as the budget rule in `.agents/skills/cruze-hexagonal-design/SKILL.md` says.
-   - The budgets apply to source files, not tests. Split a test file by the behaviour it covers, one use case or port per file, never to meet a budget. Tests that leave a source file go where the hexagonal-design language file you loaded says.
-7. **Check coverage.**
-   - Every `Builds` ID is proved by a task, except a module, which is proved by any task that writes inside its `Path`.
-   - Every delivered scenario is proved by at least one task.
-   - Done when `cruze validate` reports no `unproved-scope`, `task-format` or `outside-module-map` problems. An `outside-module-map` warning means a task writes a file no module's `Path` covers: add the file to the owning module's `Path` through `rethink`, or move it.

package/skills/plan/test-plan.md

@@ -1,14 +0,0 @@
-# Writing the test plan
-
-The test plan decides, before any code, which test proves each scenario and at which seam. The row format is in `.agents/skills/cruze-formats/reference/work-items.md`, and the four kinds are defined in `.agents/skills/cruze-behavioural-testing/SKILL.md`.
-
-1. **One `behaviour` row per delivered scenario.**
-   - The seam is the use case that serves the scenario's requirement, with a fake named for each driven port it uses.
-   - When the outcome is what an inbound adapter shows, such as CLI output, an exit code or an HTTP status, the seam is that adapter instead, run for real.
-   - Two scenarios may share a test file, but each gets its own row.
-2. **One `contract` row per port that a built adapter implements.** The seam names the fake and each real adapter, and what stands in for the outside world: a temporary directory, a pseudo-terminal, a local test server.
-3. **A `domain` row only for real logic.** Add one for a state machine, a calculation, or an invariant with many edge cases, when reaching every case through use cases would take many tests.
-4. **A `smoke` row for each flow the change completes,** when that flow is one of the system's top 1 to 3. It runs the real inbound adapter wired by the real composition root.
-5. **Test file paths follow the language's conventions.** Put behaviour, contract and smoke tests where the language keeps tests that use the public API, such as `tests/` in Rust. Put domain tests where it keeps unit tests. When the language file says where tests go once they outgrow their source file, follow it. Add each test to the file for its seam in the test support module the language file names, rather than a new file per task.
-
-Done when every delivered scenario has a `behaviour` row, every port a built adapter implements has a `contract` row, and every test file path is a real path the project's test runner will find.

package/skills/realign/SKILL.md

@@ -1,37 +0,0 @@
----
-name: cruze-realign
-description: Brings an existing codebase up to what the installed Cruze expects, by auditing it against each release's realign notes, deciding every finding with you, and scheduling the fixes as prefactor changes.
----
-
-# Realign
-
-Each Cruze release can expect more of a project's code and documents than the last, such as where tests live or how error types are shaped. `cruze install` updates the skills; realign brings the existing work up to them. The code's version is `standards:` in `.cruze/config.yaml`, and the installed one is `cruze:`. Rules newer than `standards:` report but fail no CI until realign moves it.
-
-## Steps
-
-1. **Find the gap.** Run `cruze realign status` and quote its first line: the version the code meets and the one installed. Add `--full` when the user asks for a full audit, or the project adopted Cruze partway and has never been realigned; it takes every release's notes. On `install-first`, the skills are older than the CLI: run `cruze install` first. Read [notes.md](notes.md) for what a note holds. Done when you can name every note in the report.
-2. **See what is in flight.** Run `cruze status`. Realign doesn't wait for active features and changes; it schedules around them in step 6.
-3. **Load the standards.** Read these, and each skill file a note's `Rule` names:
-   - `.agents/skills/cruze-hexagonal-design/SKILL.md`, and its language file when one exists for the project's language
-   - `.agents/skills/cruze-behavioural-testing/SKILL.md`
-   - `.agents/skills/cruze-formats/reference/architecture.md`
-4. **Audit.** Run the auditor role from `.agents/skills/cruze-roles/SKILL.md` on every note with an `Ask`. A note whose `Rule` is an item of `.agents/skills/cruze-roles/design-rubric.md` is about designs, not code: run the design reviewer instead, on each feature in flight, with that item only, since those designs were reviewed before the item existed. In a full audit, give it the standards instead, and run one auditor per module in the module map. Check its evidence against the files. Done when every note with an `Ask` has an answer with evidence, and every note with a `Detect` has its findings from the status report.
-5. **Decide each finding** with the user, a group at a time, with your recommendation:
-   - `fixed`: a prefactor change will fix it.
-   - `waived`: the project keeps its own convention, with the reason. For a `check:` finding, list the file under `check.exceptions` with that reason, which keeps CI green. For the rest, the journal holds the waiver.
-   - `deferred`: it waits for later work, recorded with `cruze features add` or on the roadmap.
-   - `rethink`: a design reviewer's finding on a feature in flight, which a feature-level rethink of its design fixes. A prefactor can't fix a design, so never record one of these as `fixed`.
-
-   Record each with `cruze journal add disposition --set review=realign --set finding="<note id>: <path or summary>" --set disposition=<fixed|waived|deferred|rethink> --set reason="<reason>"`, adding `--item <feature>` for a `rethink`. Until a rethink is recorded for that feature, `cruze next` names it, `cruze status` counts its findings, and the build gate holds its changes. One project recorded seven such findings as `fixed`, and nothing showed them. For a finding from a `Detect` rule, write the finding as exactly `<note id>: <path>`, so `cruze realign status` knows it next time. A recorded waiver is never raised again.
-6. **Schedule the fixes.** Group the `fixed` findings into prefactor changes, each small enough to plan (about 12 tasks), one module or concern per change.
-   - When a fix changes what `docs/architecture.md` says, such as an error element, a use case's `Errors` or a port's `Operations`, run `rethink` at architecture level first. It replans the built elements the prefactor rebuilds.
-   - Create each prefactor as "A prefactor" in `.agents/skills/cruze-architect/tweak.md` describes. The behaviour tests are its safety net: wire formats, messages and exit codes stay as they are unless the user decides otherwise.
-   - Put each on the roadmap, following `.agents/skills/cruze-roadmap/SKILL.md`, which says where a prefactor goes. Run `cruze status --overlap --change <ref>`, and ask the user the order for each item it overlaps, with your recommendation.
-   - Run `cruze next`. When it names a feature in flight because an amendment moved an element it cites, settle it now, with `cruze diff <feature>`: re-stamp it, or rebase its delta as `.agents/skills/cruze-rethink/levels.md` describes. Leave no feature stale for the next session to find.
-7. **Record it.** Run `cruze realign done`, adding `--change <ref>` for the prefactor that fixes the `Detect` findings still open. It moves `standards:` up, and lists those files under `check.exceptions` until that change lands, when `cruze land` removes them. Quote its result, and commit with a message such as `chore: realign to Cruze <version>`.
-
-Done when `cruze realign status` reports the code meeting the installed version, and every finding has a journaled disposition.
-
-## Next step
-
-`plan` for the first prefactor change. When nothing needed fixing, `next`. Start it in a new session, so its context starts empty.

package/skills/realign/notes/0.0.10.md

@@ -1,131 +0,0 @@
-# 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

@@ -1,15 +0,0 @@
-# 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.12.md

@@ -1,31 +0,0 @@
-# Realign notes: 0.0.12
-
-## New work only
-
-### walkthrough-types: The walkthrough shows the types each caller passes, and the decisions the user didn't make
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/walkthrough.md`, "The overview", items 3 and 5
-
-### design-needed-fields: A field serves a need only when something reads it
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-rubric.md`, item 3
-
-### design-typed-inside: Values passed inside the system are typed
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/design-rubric.md`, item 13
-
-### grilling-shrink: Doubt gets an option that shrinks the design, and a growing answer gets a simpler alternative
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-grilling/SKILL.md`, "A round"
-
-### plain-questions: Questions name things in plain words, with an ID only beside them, and illustrate pick-one options too
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-grilling/illustrating.md`, "Reading cold" and "Choosing the illustration"
-
-### grilling-context: Questions explain the part of the design they ask about before asking
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-grilling/illustrating.md`, "Reading cold"
-
-### rethink-forward: A feature or architecture rethink designs for the features ahead, as architect does
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-rethink/SKILL.md`, "Steps", steps 3 and 4

package/skills/realign/notes/0.0.13.md

@@ -1,11 +0,0 @@
-# Realign notes: 0.0.13
-
-## New work only
-
-### foundation-choice: The first change is a foundation the user chooses: a product shell, a core component or a walking skeleton
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/project.md`, "Choosing the foundation"
-
-### design-depth: Project-scope architect designs the foundation in full, and the rest of the release at its boundaries
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/project.md`, "Design the architecture", step 3

package/skills/realign/notes/0.0.2.md

@@ -1,69 +0,0 @@
-# Realign notes: 0.0.2
-
-## Existing code
-
-### test-placement: Rust tests that outgrow their file live in tests/
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-hexagonal-design/languages/rust.md`, "Dependencies and tooling"
-- Detect: check:test-placement
-- Migrate: move `src/<module>/tests.rs` and `src/<module>/tests/*.rs` to the crate's `tests/<module>.rs`, or `tests/<module>/main.rs` with one file per topic, driving the public API. A test whose private seam is the contract, such as a filesystem trait a crash test injects, stays, listed under `check.exceptions` with that reason.
-
-### readme-overview: The README says what the project is
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-envision/project.md`, step 9
-- Detect: validate:readme-overview
-- Migrate: write one paragraph under the README's title from the vision's Problem, Users and Goals, ending with a link to `docs/vision.md`.
-
-### feature-size: A feature has at most 6 changes
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-architect/feature.md`, step 12
-- Detect: validate:feature-size
-- Migrate: only for features still in progress. Keep the changes that have landed or started, and move the rest into a new feature with `cruze features add`, through `rethink` at feature level.
-
-### module-paths: Every file a task writes is inside a module's Path
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-plan/tasks.md`, step 6
-- Detect: validate:outside-module-map
-- Migrate: only for changes still being planned or built. Add the file to its owner's `Path` through `rethink` at architecture level, or move the file.
-
-### error-types: Error types exist only where callers handle their cases differently
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-hexagonal-design/SKILL.md`, "Representations and errors"
-- Ask: Does any error type copy another's variants, differ from another only in its name, or carry a case that every caller rules out, such as with `unreachable!` or `expect`? Does a use case define its own error when it only passes a domain error through?
-- Migrate: return or wrap the domain error in one case, merge similar failures into one type with the difference as a field, and narrow return types. Keep wire codes, messages and exit statuses unchanged. When `docs/architecture.md` names the error types, rethink at architecture level before the prefactor.
-
-### shared-test-support: Tests share fixtures and harnesses
-- Applies to: existing code
-- Rule: `.agents/skills/cruze-behavioural-testing/SKILL.md`, "Test support"
-- Ask: Do test files define helpers, fixtures or harnesses that another test file or the test support module already has, or share code across crates with `#[path]` includes?
-- Migrate: move each shared helper into the test support module, and in a Rust workspace into one dev-only test-support crate. Replace the copies with uses of it.
-
-## New work only
-
-### design-review-rubric: Contradictions are blockers, and slices build whole elements
-- Applies to: new work only
-- 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
-- Rule: `.agents/skills/cruze-research/SKILL.md`, "Adopt or build", step 7
-
-### design-change-findings: A finding that needs a design change goes to rethink
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/SKILL.md`, "Round 1", step 3
-
-### scope-now: Code for a later change waits for that change
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/code-reviewer.md`, rubric item 3
-
-### plan-foresight: Plans find callers, respect budgets and lints, and split tests by behaviour
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-plan/tasks.md`
-
-### rethink-attribution: Rethinks name the step that found and missed them
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-rethink/SKILL.md`, step 7
-
-### recorded-version: Install records the Cruze version and keeps CI on it
-- Applies to: new work only
-- Rule: `cruze install`, which writes `cruze:` in `.cruze/config.yaml` and moves the CI pin

package/skills/realign/notes/0.0.3.md

@@ -1,11 +0,0 @@
-# Realign notes: 0.0.3
-
-## New work only
-
-### review-helper-fallback: A review runs in a helper when no review agent is configured or installed
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/SKILL.md`, "Running a role", step 3
-
-### optional-review-command: review.command is optional, and set only for Claude Code
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-formats/reference/config.md`, "Configuration format"

package/skills/realign/notes/0.0.4.md

@@ -1,27 +0,0 @@
-# Realign notes: 0.0.4
-
-## New work only
-
-### argument-files-anywhere: Files named on the command line may be outside the project
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/SKILL.md`, "Running a role"
-
-### cli-output-format: The CLI prints one format on stdout, JSON for agents and text with --text
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-about/SKILL.md`
-
-### overlap-scope: Overlap counts only in-flight changes, and only the elements their scope and delta name
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-plan/SKILL.md`, "Steps", step 7
-
-### refused-options: The CLI refuses an option its command doesn't take
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-about/SKILL.md`
-
-### feature-map-summary: A feature's summary on the feature map follows its decisions
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-land/SKILL.md`, "Landing a change", step 4
-
-### journal-list-item: Journal list narrows to one feature or change with --item
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-about/SKILL.md`

package/skills/realign/notes/0.0.5.md

@@ -1,38 +0,0 @@
-# Realign notes: 0.0.5
-
-## New work only
-
-### review-exceptions: The user decides only the review findings that are theirs
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/SKILL.md`, "Running a review", round 1, steps 3 to 5
-
-### plan-approved-by-agent: A plan is approved once its review closes, without stopping for the user
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-plan/SKILL.md`, "Steps", step 13
-
-### rethink-restamps: A rethink re-stamps the work it didn't change
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-rethink/SKILL.md`, "Steps", step 6
-
-### change-too-small: A feature's change builds at least 3 elements
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/feature.md`, step 12
-- Detect: validate:change-too-small
-
-### change-too-large: A change delivers at most 30 scenarios
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/feature.md`, step 12
-- Detect: validate:change-too-large
-
-### plan-too-large: A plan has at most 25 tasks
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/feature.md`, step 12
-- Detect: validate:plan-too-large
-
-### concerns-per-size: Reviewers list concerns in proportion to the work
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/code-reviewer.md`, "Findings"
-
-### reverify-changed-plan: A plan changed after verify needs verifying again, whoever approved it
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-verify/SKILL.md`

package/skills/realign/notes/0.0.6.md

@@ -1,44 +0,0 @@
-# Realign notes: 0.0.6
-
-## New work only
-
-### suite-once-per-commit: The full test suite runs once per commit, and verify quotes build's result
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-verify/SKILL.md`, "Steps", step 2
-
-### test-tiers: A project with slow tests can split them into test and test_full
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-formats/reference/config.md`
-- Fix: when the full suite takes more than a few minutes, move it to `test_full` under `commands:` and make `test` the fast tier
-
-### test-support-in-scope: Build extends the test support module without a rethink
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-build/SKILL.md`, "Deviations"
-
-### name-the-break: Plan names the break for a test that passes against a stub
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-plan/tasks.md`, step 2
-
-### round-2-by-agent: The agent checks round 2 when every blocker was fixed as proposed
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-roles/SKILL.md`, "Running a review", round 2
-
-### size-before-approval: Size warnings are cleared or accepted before a feature is approved
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-architect/feature.md`, step 12
-
-### verify-every-claim: Research checks claims about the language, platform and external systems
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-research/SKILL.md`, "Adopt or build", step 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-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
-- Rule: `.agents/skills/cruze-architect/walkthrough.md`
-
-### quoted-titles: New features and changes quote their title in the header
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-formats/templates/change.md`

package/skills/realign/notes/0.0.7.md

@@ -1,11 +0,0 @@
-# Realign notes: 0.0.7
-
-## New work only
-
-### improve-skill: Existing code can be restructured to today's standards with the improve skill
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-improve/SKILL.md`
-
-### layout-by-kind: The layout is the one normal for the kind of system and its language, with the fewest layers that keep the rules
-- Applies to: new work only
-- Rule: `.agents/skills/cruze-hexagonal-design/SKILL.md`, "Layers"