@printpractical/cruze 0.0.13 → 0.0.14

package/skills/about/SKILL.md

@@ -1,21 +0,0 @@
----
-name: cruze-about
-description: Explains what Cruze is and what it can do in this repository. Use when the user asks about Cruze, its commands, or how to start working with it.
----
-
-# About Cruze
-
-Cruze is a spec-driven development framework. It keeps one living model of the system (vision, glossary, architecture and behaviour specs in `docs/`) and delivers work as small changes against that model, each merged back into it when it lands.
-
-This installation is an early preview. It has:
-
-- The `cruze` CLI: `cruze init` sets up a repository, `cruze install` updates the skills after an upgrade, and `cruze help` lists the commands that validate, approve, check, trace and land work. Each prints its result on stdout, as JSON when stdout isn't a terminal, or as text with `--text`. A command refuses an option it doesn't take, so check `cruze help` when one is refused.
-- `cruze-formats`, the format of every Cruze document.
-- Knowledge skills holding the standards to design and code to: `cruze-hexagonal-design`, `cruze-behavioural-testing`, `cruze-grilling`, `cruze-domain-language`, `cruze-dependency-approval` and `cruze-research`.
-- The workflow: `explore` (optional), `envision` for the what, `architect` for the how, `roadmap` for the order of work, then `plan`, `build`, `verify` and `land` for each change. `triage` handles bugs, `rethink` steps back from anywhere, and `next` says what to do now.
-
-When the user asks what Cruze can do:
-
-1. Read `.cruze/config.yaml` and report the project name and Cruze version.
-2. Run `cruze --version`, and say whether it differs from the version in `.cruze/config.yaml`. When `cruze` isn't found, tell the user to install it globally as https://github.com/PrintPractical/cruze#quick-start describes; every Cruze skill needs it.
-3. Run `cruze next` and explain the step it names, in the context of the whole workflow.

package/skills/architect/SKILL.md

@@ -1,49 +0,0 @@
----
-name: cruze-architect
-description: Decides how to build and how big, at project scope (domain model, contexts, ports, adapters, module map, layer rules, ADRs and the roadmap with its foundation, the first change, which the user chooses), feature scope (the architecture delta and its split into changes) or tweak scope (a standalone change), ending with a design review and a walkthrough for your approval.
----
-
-# Architect
-
-Architect decides the how and the how big. It designs the domain, the ports and adapters, and where every element lives in the source tree, before any code exists. It ends with the one heavy human gate, the design walkthrough: a short overview in plain terms, after which the user reads the design documents in full and approves or comments.
-
-## Steps
-
-1. **Pick the scope.**
-   - **Project scope:** `docs/architecture.md` doesn't exist yet. Reworking an approved architecture goes through `rethink` instead.
-   - **Feature scope:** the user names a feature, or a feature folder exists without changes.
-   - **Tweak scope:** the user asks for a small change to existing behaviour. When the design shows it needs any architecture change, it becomes a feature: say so and continue at feature scope.
-   - Done when you can say which, and why.
-2. **Check what it builds on.** Run `cruze status`. `docs/vision.md` must be approved and current. At feature and tweak scope, `docs/architecture.md` must be approved and current as well. When a document isn't, stop and name the step that fixes it: `envision` for the vision, and `rethink` for an architecture that changed since its approval.
-3. **Read the living model.** Read `docs/vision.md`, `docs/glossary.md`, `docs/architecture.md` as "Reading it" in `.agents/skills/cruze-formats/reference/architecture.md` says, the ADRs in `docs/adr/`, `docs/roadmap.md`, `.cruze/config.yaml`, and the specs and code the work touches. Take up the notes and the parts of the user's input handed to this work, as "Taking up a hand-off later" in `.agents/skills/cruze-envision/intake.md` describes: at project scope, `cruze show --notes architect`, `cruze show --notes roadmap` and `cruze show --notes project`; at feature or tweak scope, the Notes section of `cruze show <feature>`. Read any other note the user points to.
-4. **Load the standards.** Read these, and follow them for the rest of this step:
-   - `.agents/skills/cruze-hexagonal-design/SKILL.md`
-   - `.agents/skills/cruze-grilling/SKILL.md`
-   - `.agents/skills/cruze-domain-language/SKILL.md`
-   - `.agents/skills/cruze-research/SKILL.md`
-   - `.agents/skills/cruze-dependency-approval/SKILL.md`
-   - `.agents/skills/cruze-formats/reference/architecture.md`
-5. **Design.** Follow the scope's procedure: [project.md](project.md), [feature.md](feature.md) or [tweak.md](tweak.md). Tweak scope ends there and hands off to `plan`.
-6. **Review the design.** Run the design review in `.agents/skills/cruze-roles/SKILL.md`, with the design reviewer role. Done when every finding has a journaled disposition and no blocker is open without the user's decision.
-7. **Hand the design to the user.** Follow [walkthrough.md](walkthrough.md): one overview message, then the documents to read in full. Apply what the user changes, run `cruze validate` again, and say what changed.
-8. **Record the approval.** Only after the user says they approve, run the scope's `cruze approve` command and quote its result, then commit. At project scope, the roadmap follows as its own approval, described in [project.md](project.md).
-
-## Rules
-
-- **Design for the roadmap, build for the phase.** Read the whole feature map and roadmap. When a later feature will need a seam, name it now in a `Future` fact, such as "transport will gain MQTT in phase 3, so inbound adapters stay behind `CommandSource`". Build only what the current work needs.
-- **Answer to the vision's long-term intent.** Read `## Principles` and `## Must stay possible` in `docs/vision.md`. Every design follows each principle. Check the design against every `LATER` row, not only those in its area: nothing in it may rule one out. Where the design touches a capability's area, leave the room its row names, in a `Future` fact that cites its ID, and build nothing for it. A design that would depart from a principle or close off a capability goes to the user first, as "Long-term intent" in `.agents/skills/cruze-grilling/SKILL.md` describes.
-- **Adopt before you build.** Before designing any component that isn't domain logic, run the researcher role from `.agents/skills/cruze-roles/SKILL.md` on it. Record every decision in `## Adopt or build`, or at project scope in the adapter's `Adopts` fact. Every new dependency goes to the user through the dependency-approval skill.
-- **Every element with code has a home.** Each `ENT`, `UC`, `PORT`, `ADP` and `FLOW` names its `Module` and `File`. Each file has one responsibility. Never split an owner across files to keep them short.
-- **Comply with the references.** When the project must follow an external document, such as a protocol specification, it is listed under `references:` in `.cruze/config.yaml`; at project scope, ask the user whether there is one, and list it with what it governs. Read the parts each element relies on, and cite the section in the element's body, such as `RFC 4254 §5.2`, so plan, build and the reviewers can check it.
-- **Ask, challenge and defer** as the grilling skill describes. Contexts, ports, public contracts, dependency direction and dependencies are always the user's decisions.
-- **Stepping back is normal.** When the design shows that the vision or an earlier decision is wrong, stop and say so. The vision changes through `envision`, and an approved architecture through `rethink`.
-
-## Next step
-
-- Project scope: `plan` for the foundation change.
-- Feature scope: `plan` for the feature's first change.
-- Tweak scope: `plan` for the standalone change.
-
-Plan branches from main, so get the approved design onto main first, as a pull request or a merge, together with the vision or feature map it builds on. A plan branched from an unmerged design branch carries the design into the change's pull request.
-
-Start it in a new session, so its context starts empty.

package/skills/architect/feature.md

@@ -1,40 +0,0 @@
-# Architect at feature scope
-
-The result is a `feature.md` with a complete architecture delta and an ordered list of changes, approved at the walkthrough. Formats: `.agents/skills/cruze-formats/reference/work-items.md` and `.agents/skills/cruze-formats/reference/architecture.md`.
-
-## Settle what it does
-
-1. **Find the feature folder.** When `envision "<feature>"` created one, read its intent, settled decisions and spec delta.
-2. **Or settle it now.** When there is no folder, follow `.agents/skills/cruze-envision/feature.md` from its step 2 up to, but not including, its step 8. That puts the feature on the roadmap, checks its blockers, creates the folder and settles the intent and spec delta.
-
-## Design the delta
-
-3. **Trace each scenario through the model.** Find the elements with `cruze show --index`, and read each one the path crosses with `cruze show <ID>`. For every scenario in the spec delta, name the inbound adapter it enters through, the use case that runs it, the domain elements that decide it, and the ports it crosses. Done when every scenario has a path, and each missing piece is a named gap.
-4. **Place each gap,** following "Placing an owner" in the hexagonal-design skill. Prefer extending an existing element when it is the right owner. Each change to the living model becomes an operation under `## Architecture delta`:
-   - `ADDED` for a new element, with its full body.
-   - `MODIFIED` for an existing element, with its full new body. Copy the current body from `cruze show <ID>` and edit it, so nothing is lost by accident.
-   - `REMOVED` with a `Reason`, for an element the feature retires.
-   - When the delta changes or retires a rule, find every element, ADR, decision and sentence in the living docs and this feature that states the old rule, and modify or reword each.
-   - A new use of an existing port operation, such as the clock stamping a new kind of time, is a `MODIFIED` port whose `Operations` name the use, and each use case lists every port it calls under `Uses`.
-5. **Link behaviour to design.** Each use case that runs a requirement lists it under `Serves`. Add or modify a `FLOW` for each key scenario, with `Serves` naming its scenarios and the failure paths they need.
-6. **Research and decide.** For each new component that isn't domain logic, run the researcher role and record a row in `## Adopt or build`. Take every new dependency to the user. Then verify every claim the design relies on, following step 7 of adopt or build in `.agents/skills/cruze-research/SKILL.md`. Done when no claim in the design is unverified.
-7. **Keep later seams open.** Check the design against every row of the vision's `## Must stay possible`: nothing in it may rule one out. When the feature map shows a later feature that will extend this area, or a capability needs room in it, record the seam in a `Future` fact on the element that keeps it, citing the `LATER` ID or the feature's slug, and don't build it.
-8. Done when `cruze validate` reports no errors and no `decision-citation` warning in the delta itself, and every cited ID exists in the living docs or this delta.
-
-## Split it into changes
-
-9. **Slice vertically.** Each change delivers scenarios end to end, through every layer they need, and can land on its own. Every change pays for its own plan review, code review, verifier run and land, so slice by what is worth that cost, not by the smallest piece that could land. The feature's first change proves the design end to end; later changes widen it in steps of real work.
-10. **Fill the Changes table.** Give each row a number and a slug, such as `01-local-serial`. List the scenario and requirement IDs it `Delivers`, the architecture IDs it `Builds`, any IDs it `Removes`, and the changes it `Depends on`.
-    - A change builds an element only when its scenarios prove the whole element. Each delta element is built by exactly one change, so when an element's duties arrive in different changes, split it into elements that each arrive whole, such as frame limits split out of a concurrency rule.
-    - `Depends on` names every earlier change that builds something this change's scenarios need.
-11. **Cover everything exactly once.** Every delta ID appears in exactly one change. A module the delta adds, or one still `planned` in the living docs, is built by the first change that writes a file in it. A module already `built` isn't listed. Done when `cruze validate` reports no errors for the feature, and no `not-designed` warning.
-12. **Size each change, and the feature.** Aim for changes of about 8 to 25 tasks, each one a sitting's worth of review and verify:
-    - **Merge** a change that builds fewer than 3 elements into the change it continues, when they share adapters or screens, or form a chain where each depends on the one before. Several small changes to the same screens are one change. `cruze validate` warns `change-too-small`.
-    - **Split** a change that delivers more than 30 scenarios, or would need more than 25 tasks, or touches more than one context's domain. One verifier run and one code review can't hold more. `cruze validate` warns `change-too-large`, and `plan-too-large` once a plan passes 25 tasks.
-    - A feature of more than 6 changes is more than one design review can hold: split it into features that each serve part of its goals, and run `cruze features add` for the later ones. `cruze validate` warns `feature-size` until it is split.
-
-    The thresholds are the defaults under `changes:` in `.cruze/config.yaml`; a project can tune them.
-
-    Done when `cruze validate` reports no `change-too-small`, `change-too-large` or `feature-size` warning. When the user accepts one, record it twice: a `D<n>` line under the feature's `## Settled decisions` saying why, and the item under `changes.exceptions` in `.cruze/config.yaml` with the same reason, which is what stops the warning. `cruze approve` refuses an item with a warning still standing (`size-unaccepted`). After approval, only a rethink can split a change.
-
-Then continue with the review and walkthrough steps of the skill. When the user approves, run `cruze approve <feature>` and quote its result. The command takes the feature's full ID, such as `2026-09-25-open-console`, or its slug when no other active item shares it.

package/skills/architect/project.md

@@ -1,71 +0,0 @@
-# Architect at project scope
-
-The result has four parts, reviewed together and shown at one walkthrough:
-
-- `docs/architecture.md`, the living model of the whole system, which the user approves.
-- The `layers:` rules in `.cruze/config.yaml`.
-- `docs/roadmap.md` for the first release, which the user approves as its own step.
-- The foundation change, the first one the project builds, designed and ready for `plan`. It is approved later, once `plan` has filled its test plan and tasks.
-
-## Design the architecture
-
-1. **Create it.** Run `cruze new architecture`. Follow its sections in order, one at a time, and grill the user on each section's material decisions before writing it.
-2. **Bounded contexts (`CTX`).** Group the vision's capabilities into contexts by which language and rules belong together. Most small systems have one to three. Each context has a `Purpose`, and a `Depends on` naming what it uses from other contexts. Regroup the glossary's terms under one `##` heading per context.
-3. **The foundation.** Settle with the user what the first change builds, as "Choosing the foundation" says. Then design the whole release end to end, so the foundation is shaped by everything that will use it, at two depths:
-   - **In full** for what the foundation builds: every fact steps 4 to 8 ask for.
-   - **At the boundaries** for the rest: each part's use cases, the operations and data that pass between parts, and the flows that cross them, with their main results and errors. The specifics inside, such as limits, edge cases, messages and adapter technology, stay open, each named in a `Future` fact, for the feature that builds the part.
-4. **Domain model (`ENT`).** For each context, model the concepts the vision and glossary name, including invariants, relationships with cardinality, and `States` for anything whose valid operations depend on its state. Add the `VIEW-domain-model` class diagram.
-5. **Use cases (`UC`).** Write one per operation a caller can ask for in this release, each with its input, output, errors and the ports it uses.
-6. **Ports (`PORT`).** Define every capability the use cases need from outside, named by capability. Write each operation's contract, following `.agents/skills/cruze-hexagonal-design/contracts.md`. Add driving ports only where the hexagonal-design skill calls for them.
-7. **Adapters (`ADP`).** Name the technology behind each driven port and each inbound adapter that drives use cases. Run the researcher role on every adapter's technology first, and record the result in the adapter's `Adopts` fact. Take every new dependency to the user.
-8. **Flows (`FLOW`).** Write a `sequenceDiagram` for each of the 2 to 5 most important interactions, including their failure paths. Leave out `Serves` until scenarios exist.
-9. **Modules (`MOD`).** Name the kind of system in the Overview, and choose the layout that is normal for that kind and the language, following `.agents/skills/cruze-hexagonal-design/shapes.md` and the language file. Give each context the fewest modules that keep its layer rules, usually one `core` module and its adapters, and give the shared CLI shell and the composition root the `system` scope. Add a `system` module in the `composition` layer for the build and CI files, such as the package manifest and `.github/workflows/`, so the tasks that write them have an owner. Every source file must fall inside some module's `Path`, including namespace files that join a context's modules, such as `src/inventory/mod.rs` or `index.ts`; list them in a `composition` module's `Path` when no other module fits. Every module gets a `Path` and a `Layer`, and every element above gets its `Module` and `File`.
-10. **Dependency rules (`RULE`).** State what may import what, in one or two sentences each.
-11. **Cross-cutting concerns (`XC`).** Cover errors, configuration, logging, concurrency and security, plus build and delivery (CI, formatting, linting). Read `.agents/skills/cruze-hexagonal-design/runtime.md` for concurrency.
-12. **Decisions.** Write an ADR, with `cruze new adr <slug> --title "<title>"`, for each decision that passes the ADR test. Record the other project decisions as `D<n>` lines under `## Decisions`, including each design choice handed to `architect` that the user keeps.
-13. **Overview (`VIEW-context`).** Draw the context diagram last, once the adapters and external systems are known.
-
-Done when `cruze validate` reports no errors in `docs/architecture.md`. At this stage it warns that elements have no status yet; approval adds the statuses.
-
-## Write the layer rules
-
-Fill `source`, `tests` and `layers:` in `.cruze/config.yaml` from the module map, following `.agents/skills/cruze-formats/reference/config.md`. Give each module's `Path` exactly one layer, and make each layer's `may_import` match the `RULE` elements. Done when `cruze validate` reports no config errors and no `module-layer` warnings.
-
-## Ignore build output
-
-Add the language's build output and tool caches to `.gitignore` now, such as `/target` for Rust or `node_modules/` for Node, so no later commit sweeps them in.
-
-## Plan the release
-
-1. **Create the roadmap.** Run `cruze new roadmap`. Agree the first release with the user: its name, and which features from the vision's feature map it delivers. Take up the delivery order handed to `roadmap`, as for any hand-off.
-2. **Order the work.** Phase 1 holds only the `foundation` change. Later phases hold the release's features. Done when the roadmap passes the rules in step 5 of `.agents/skills/cruze-roadmap/SKILL.md`.
-3. **Design the foundation.** Run `cruze new change foundation --title "<what it builds>"`. Then:
-   - Size the elements it builds for the foundation. Anything it lists under `Builds` is marked built when it lands, so write those elements, such as the CLI adapter or the first entity, at the size the foundation needs. Record their planned growth in `Future` facts; later features grow them through `MODIFIED` operations.
-   - Build the kind the user chose, nothing more. It also makes CI real: `cruze init` already runs `cruze validate`, `cruze check --ci` and `cruze trace --all` there, and the foundation adds the language's format, lint, build and test steps. `plan` fills `commands:` in `.cruze/config.yaml` for it.
-   - Write its `## Intent`.
-   - In `## Adopt or build`, add a row for each tool it adds that no adapter owns, such as the test framework, linter or CI runner.
-   - Write the `## Spec delta` for the one capability it delivers, with scenarios.
-   - In `## Architecture delta`, link the new behaviour to the design: a `MODIFIED` operation for each use case that serves its requirements, adding them to `Serves`, and for each flow that runs its scenarios, adding them to its `Serves`. Each body is the element's full text from `docs/architecture.md` with that fact added.
-   - Fill `## Scope`. `Delivers` lists its scenarios. `Builds` lists the elements it modifies, the other architecture elements it builds, and every module whose first files it writes.
-   - Leave the test plan and tasks to `plan`.
-   - Done when `cruze validate` reports only the change's `not-planned` warning.
-
-## Choosing the foundation
-
-The foundation is the first change, which everything else builds on and the user tries first. Which kind fits is the user's decision. Ask it as a grilling question, sketching each option in this project's terms, with your recommendation:
-
-- **Product shell:** every screen, page or command the release offers, wired together, showing sample data, with no logic behind it yet. It suits settling look and flows before logic.
-- **Core component:** the component the others depend on, working for real through its own interface, such as a server with its command-line client. Later phases add one component at a time, and shared machinery, such as a framework, after two of its users. It suits a system of several components.
-- **Walking skeleton:** one use case through every layer: an inbound adapter, its domain, a driven adapter and the composition root. It suits a small system.
-
-It must fit the change size limits in `.cruze/config.yaml`; when it doesn't, settle with the user what moves to Phase 2. Record the choice as a `D<n>` line in the architecture's `## Decisions`.
-
-## Review, walk through and approve
-
-1. Run the design review and the walkthrough from the skill's steps 6 and 7, over the architecture, the config, the roadmap and the foundation together.
-2. When the user approves the design, run `cruze approve architecture`. It marks every element `planned`.
-3. Confirm the release ordering with the user, then run `cruze approve roadmap`.
-4. Add an `## Architecture` section to `README.md`: one sentence on the system's shape, the `VIEW-context` diagram, and a link to `docs/architecture.md`.
-5. Commit, with a message such as `docs: approve the architecture and roadmap`.
-
-Done when `cruze status` shows the vision, the architecture and the roadmap approved.

package/skills/architect/tweak.md

@@ -1,22 +0,0 @@
-# Architect at tweak scope
-
-A tweak changes existing behaviour without changing the architecture. The result is a standalone change with its intent, spec delta and scope, ready for `plan`. It has no design review and no walkthrough, because nothing structural changes; the plan review in `plan` covers it.
-
-1. **Name the behaviour.** Find the requirements and scenarios in `docs/specs/` that the tweak changes, and the use cases that `Serve` them. Done when you can name every one.
-2. **Check that it is a tweak.** Trace the new behaviour through `docs/architecture.md`. It is not a tweak when it needs a new requirement, which a use case would have to serve, or any new or changed element (an entity invariant, a use case's input or errors, a port operation, an adapter or a module). Tell the user, and continue at feature scope with [feature.md](feature.md), which puts the feature on the roadmap and creates its folder.
-3. **Create the change.** Run `cruze new change <slug> --title "<title>"`, adding `--roadmap <slug>` when the tweak is a roadmap item.
-4. **Settle the behaviour.** Grill the user on anything open: the exact new behaviour, its edge cases, and what a user now observes. Record decisions under the change's `## Settled decisions` as they settle.
-5. **Write the design sections,** and remove every template guide, including any unused `D1` line.
-   - `## Intent`: why, in the user's words, and what is out of scope.
-   - `## Adopt or build`: the table header only, since a tweak adds no components.
-   - `## Spec delta`: `MODIFIED` requirements with their full new bodies, including every scenario each one keeps.
-   - `## Architecture delta`: `None.`
-   - `## Scope`: `Delivers` lists every new or changed scenario. `Builds` stays empty unless the tweak builds `planned` elements.
-   - Leave the test plan and tasks to `plan`.
-6. **Confirm.** Summarize the new behaviour and ask the user to confirm it.
-
-## A prefactor
-
-A prefactor comes from an architecture-level rethink: the architecture already says what the code must become, and one or more built elements went back to `planned`. It changes structure, not behaviour. Create it as in step 3, then write its intent, set `## Spec delta` and `## Architecture delta` to `None.`, and list the replanned elements under `Builds`. The existing behaviour tests are its safety net: they must pass unchanged.
-
-Done when the user has confirmed, `cruze validate` reports only the change's `not-planned` warning, and the change is committed.

package/skills/architect/walkthrough.md

@@ -1,35 +0,0 @@
-# The design walkthrough
-
-The walkthrough hands the design to the user in one message: a short overview in plain terms, then the documents to review in full. The documents are the design, and the user reads them faster than you can retell them, so present the whole design at once and wait for one answer: approval, or comments.
-
-At feature scope, cover only what the feature adds, changes or removes. At project scope, cover the whole architecture, the layer rules, the roadmap and the foundation.
-
-## The overview
-
-Write it in the glossary's terms, as what callers can do and what happens when they do, not as a list of elements. Keep the prose to what the user can read in a minute, and open it with the line that says where things stand, from `.agents/skills/cruze-grilling/illustrating.md`.
-
-1. **What it does.** The intent in two sentences. Then one line per use case, or at feature scope per requirement: who asks for what, what they get, and the main way it fails.
-2. **What it touches.** Each new external system, and each new dependency named with its purpose and the approval behind it. Also each component you chose to build yourself, with the reason.
-3. **What it looks like.** Illustrated as `.agents/skills/cruze-grilling/illustrating.md` says:
-   - A plain-text diagram of the main scenario crossing the design: the inbound adapter, the use case, the domain elements and the ports, marking what is new.
-   - A code sketch, in the project's language, of what the new and changed elements look like: the port operations and use case signatures with their errors, the main entity, and the call each kind of caller makes, a component in the same process included, with the types it passes as they will be declared. One project approved orchestrators that passed JSON values inside the daemon, which no sketch showed, and rejected it at build a day later.
-4. **The slices.** The changes in order, one line each, saying what each delivers and why the first is first. At project scope, the roadmap's phases and the foundation instead, with the kind the user chose.
-5. **What is yours to decide.** The review findings the roles skill brings to the user, any `cruze validate` warning still standing, such as a change over its size limit, any point where a fresh implementer could still build something different, and any rule you challenged that the user overrode. Then, one line each, every decision the design takes that no answer of the user's settled, carried-over ones included, and every value the system's own components pass each other untyped or encoded, such as a JSON value. Approval rests on this overview: one feature's documents ran to 25,000 words.
-
-## The documents
-
-List each file the user should read in full, with the sections that changed:
-
-- Feature scope: the feature's `feature.md`, and the ADRs it adds.
-- Project scope: `docs/architecture.md`, the `layers:` in `.cruze/config.yaml`, `docs/roadmap.md`, the foundation's `change.md`, and the ADRs in `docs/adr/`.
-
-The documents' diagrams are Mermaid. Say where the user can render them, such as an editor preview or GitHub, rather than pasting them; the overview's plain-text sketches are for reading in the conversation.
-
-End the message with: "Read these in full, then tell me what to change, or approve. Do you approve this design?"
-
-## Ending
-
-1. Answer a question from the documents, pointing to the file and section, and answer only what was asked.
-2. A request for changes is not an approval. Apply the changes and run `cruze validate`. When the user edited the documents themselves, read their diff and run `cruze validate` on it. When the changes touch placement, dependency direction, adopt-or-build decisions, port contracts or flows, run a new design review on the diff alone. Then say in a few lines what changed and where, and ask again.
-3. When the user rejects the design outright, don't approve anything. Ask what is wrong. When the problem is what to build, go back to `envision`; when it is the whole approach, restart this step's design; when the user wants to stop, leave the work unapproved and say how to resume.
-4. Done when the user says they approve.

package/skills/domain-language/SKILL.md

@@ -1,37 +0,0 @@
----
-name: cruze-domain-language
-description: How to build the project's shared language in docs/glossary.md and use it the same way in conversation, documents, IDs and code. Use when a new domain term comes up, when the user or a document uses a vague, overloaded or conflicting word, when naming an element, ID, type, module, function or test, or when writing or reviewing the glossary.
----
-
-# Domain language
-
-Use one word per concept, everywhere: in conversation, specs, the architecture, IDs and code. `docs/glossary.md` holds those words, in the format given in `.agents/skills/cruze-formats/reference/durable-docs.md`.
-
-## While designing
-
-1. Read the glossary before the conversation starts, and use its words in your own questions and documents.
-2. When the user uses a term differently from the glossary, say so immediately: "The glossary defines a hop as one link in a console path, but you seem to mean the jump host itself. Which is it?"
-3. When a word is vague or overloaded, such as account, item, session, handle or data, propose one precise term and say what it excludes.
-4. Test a boundary between two concepts with a concrete edge case: "A device reachable over two console paths: is that one device or two?"
-5. When the user says how something works, check the living docs and the code. Point out any contradiction instead of choosing a side.
-6. Write a term into the glossary the moment it settles. The glossary isn't approval-gated, so adding a term never makes a design stale.
-
-Done when every domain noun in the documents this step writes is in the glossary or is a general programming term.
-
-## What belongs
-
-- Terms specific to this domain. General programming concepts, such as timeout, retry or cache, stay out unless the domain gives them a special meaning.
-- A definition says what the thing is, in one or two sentences a domain expert would accept. It never mentions types, files, tables or other implementation.
-- Pick one word per concept and list its synonyms under `_Avoid_`.
-- Group terms under their bounded context. A word that means different things in two contexts gets an entry in each, and the translation happens where the contexts meet.
-
-## Using the language
-
-- Element titles and ID names use glossary terms: `ENT-inventory.console-path`, not `ENT-inventory.route`.
-- Types, modules, functions and tests in code use the same words, in the language's naming style: `ConsolePath` in `console_path.rs`.
-- A word listed under `_Avoid_` in a new title, ID, type or test name is a review finding. Rename it, or settle the term with the user.
-- When a term is renamed, update the glossary and rename element titles freely. IDs keep their old wording, because an ID never changes. Code follows through a change like any other.
-
-## Terms and decisions
-
-The glossary holds language, not decisions. Record decisions as `.agents/skills/cruze-grilling/SKILL.md` describes.

package/skills/envision/feature.md

@@ -1,25 +0,0 @@
-# Envision at feature scope
-
-The result is a feature folder whose `feature.md` holds the intent, the settled decisions and the spec delta, ready for `architect`. Formats: `.agents/skills/cruze-formats/reference/work-items.md` and `.agents/skills/cruze-formats/reference/specs.md`.
-
-1. **Check the project.** `cruze status` must show `docs/vision.md` approved. If it isn't, stop and run envision at project scope first.
-2. **Find the feature.** Look for it in the roadmap's phases and on the feature map's future list.
-   - When it isn't in the roadmap's phases, ask the user whether it belongs in this release. If it does, add it by following "Adding an item" in `.agents/skills/cruze-roadmap/SKILL.md`, and re-approve the roadmap. If it doesn't, put it on the future list with `cruze features add` and stop here.
-   - When its `Blocked by` items haven't landed (see the roadmap's `## Status`), tell the user. Continue only if they want to design ahead, and record that as a settled decision.
-3. **Create the folder.** When the feature has no folder yet, run `cruze new feature <slug> --title "<title>" --roadmap <slug>`, using its roadmap slug. When a folder exists, edit its `feature.md`.
-4. **Read the behaviour it touches.** Read the specs in `docs/specs/` for every capability the feature changes, so you know each requirement and scenario it builds on. Run `cruze show --notes <slug>`, and take up the notes about this feature and the parts of the user's input handed to it, open questions included, as "Taking up a hand-off later" in [intake.md](intake.md) describes.
-5. **List the open decisions:**
-   - **Intent:** the problem and outcome in the user's words, who it is for, the constraints, and what is out of scope.
-   - **Requirements:** each behaviour the feature adds, changes or removes, and the capability it belongs to. It goes in an existing capability when the behaviour fits one; otherwise it starts a new capability.
-   - **Scenarios:** for each requirement, the main case, each edge and failure case a user will meet, and what they observe in each. Invent concrete edge cases to test the boundaries.
-   - **Later:** the vision's `PRINCIPLE` and `LATER` rows this feature touches, and the capabilities it may grow into, asked about as [possibilities.md](possibilities.md) describes. A feature that adds sign-in asks about single sign-on and multi-factor authentication, for example.
-6. **Grill in rounds** until every open decision is settled. Record decisions under `## Settled decisions` and terms in the glossary as they settle.
-   - When a decision changes something the feature's summary on the feature map promises, such as a policy it names, correct the summary with `cruze features update <slug> --summary <text>`.
-   - When an answer names something the product may need later, or a decision departs from a principle, the vision changes, as "Long-term intent" in the grilling skill describes. A settled decision of this feature is archived when it lands, so it can't hold either.
-7. **Write the spec delta.** Use `ADDED` for new requirements, `MODIFIED` for a requirement whose text or scenarios change (writing its full new body with every scenario it keeps), `REMOVED` with a `Reason` and `Migration` for retired behaviour, and `ADDED CAPABILITY` for a new capability.
-   - Name every ID with glossary terms. An ID is never reused.
-   - Done when every requirement has a scenario for its main case and one for each failure a user can meet.
-8. **Leave the design to architect.** Set `## Architecture delta` to `None.` and leave the Changes table with its header row only. Remove the remaining template guides.
-9. **Confirm.** Summarize the intent and each requirement with its scenarios, in plain words, showing each requirement's main scenario as the user would see it, and ask the user to confirm them. Apply any corrections.
-
-Done when the user has confirmed, `cruze validate` reports no errors for the feature, only its `not-designed` warning, and the feature is committed.

package/skills/envision/intake.md

@@ -1,28 +0,0 @@
-# Taking in the user's input
-
-The user may bring anything: a seed, a PRD, a TRD, a design write-up, an old project's notes, a pasted paragraph or a link. Everything in it is open for discussion, and every part of it reaches the step that takes it up. One project's 9,500-word seed held design that no step was told to read, and intent the vision had no room for.
-
-1. **Gather it.** Read every source the user names or pastes, and each note `cruze show --notes` lists with kind `input`. Run `cruze new note intake --title "Intake: <what the input is>" --kind intake --about project`. Under `## Sources`, cite each file in the repository by path, and copy in, verbatim, what would otherwise be lost: pasted text, and a document outside the repository, such as a link or a PDF.
-2. **Sort every part** by the step that takes it up. Name each part by its heading, or by a short quote where the input has none:
-   - `vision`: the problem, users, goals, non-goals, constraints, principles, and what must stay possible.
-   - `architect`: design choices, such as structure, protocols, technologies and data formats.
-   - `roadmap`: delivery order and phases.
-   - a feature's slug: one feature's behaviour, rules, limits and examples. Use the slug the feature map gives it.
-   - `user`: preferences about the process itself, which the user may add to `AGENTS.md`.
-
-   An open question goes to the step that settles it. Done when every part of every source has a place.
-3. **Read its stance.** Note how settled the input says each part is, from its own legend when it has one, or from its wording: "we decided" and "must" are firmer than "maybe", "TBD" or a question. Nothing is settled by being written down. The stance sets only your recommendation: keep what the input settled, with its reason; ask about what it proposed; research what it guesses; settle what it leaves open.
-4. **Write the hand-off** in the intake note, under `## Hand-off`, one row per part:
-
-   ```markdown
-   | Part | Source | Goes to | Status |
-   | --- | --- | --- | --- |
-   | Transport | `.cruze/notes/2026-10-12-seed.md`, "The protocol" | architect | open |
-   ```
-
-   A one-paragraph idea is all `vision`, so its hand-off is a row or two.
-5. **Take up the vision's parts now,** one section at a time. Each section is one question, keep or change, with the input's position as your recommendation. Set each row's status to `settled` or `dropped` as the user decides.
-
-## Taking up a hand-off later
-
-Architect, the roadmap and feature-scope envision take up their own rows. `cruze show --notes <step or feature slug>` lists them, and `cruze show <ref>` lists them for a feature or change. Read each part at its source, ask the user about it as in step 5, record what they keep where the step records decisions, and set the row's status. A row still `open` when the step ends goes to the user: keep it open for a later step, or drop it.

package/skills/envision/project.md

@@ -1,24 +0,0 @@
-# Envision at project scope
-
-The result is an approved `docs/vision.md` and a `docs/glossary.md` holding the terms that settled. Formats: `.agents/skills/cruze-formats/reference/durable-docs.md`.
-
-1. **Create the documents.** Run `cruze new vision` and `cruze new glossary` for whichever doesn't exist yet. When the vision exists and you are reworking it, edit it in place. Bounded contexts don't exist yet, so group the glossary's terms under one `##` heading naming the product's domain, such as `## Console access`. `architect` regroups them by context.
-2. **Take in the input** as [intake.md](intake.md) describes, then draft every section you can from the parts handed to `vision`, marking each as a question for step 3. Done when every part of the input has a hand-off row.
-3. **List the open decisions,** section by section:
-   - **Problem:** the problem in the user's words, and who feels it.
-   - **Users:** each kind of user and the situation they are in.
-   - **Goals:** each goal as a `GOAL-<name>` row, with a measure that says how you would know it's met. A goal without a measure is still open.
-   - **Non-goals:** what the product deliberately doesn't do, and why. Ask about the tempting neighbours of each goal.
-   - **Constraints:** platforms, the implementation language, dependency policy, performance, security, privacy, licensing and legal limits.
-   - **Principles:** each rule every design must follow, as a `PRINCIPLE-<name>` row with why it holds. Ask about the rules behind the user's choices, such as what state and events are each for.
-   - **Must stay possible:** each capability the product may need after this release, as a `LATER-<name>` row, explored as [possibilities.md](possibilities.md) describes.
-   - **Feature map:** the capabilities that deliver the goals, each a slug with a one-line summary and the goals it serves. They are what later `envision "<feature>"` runs pick up.
-4. **Grill in rounds** until every open decision is settled, following the grilling skill. As each domain term settles, add it to the glossary. Once the goals and feature map have settled, ask about what may come later, as [possibilities.md](possibilities.md) describes.
-5. **Write the vision.** Fill each section, and remove every template guide.
-6. **Fill the feature map.** For each capability, run `cruze features add <slug> --summary "<summary>" --goals <GOAL IDs>`. Put command syntax in backticks, such as `` `consolectl console <device>` ``, so it isn't read as a template guide. Running `add` again for the same slug replaces its entry in place. Done when every goal is served by at least one feature on the map.
-7. **Confirm.** Walk the user through the vision in one short summary: the problem, the goals with their measures, the non-goals, the constraints, the principles, what must stay possible, and the feature map. Name what the hand-off gives each later step, and anything dropped, and why. Ask whether it matches their understanding, and apply any corrections.
-8. **Approve.** When the user approves, run `cruze approve vision` and quote its result.
-9. **Introduce the project in the README.** Under the title of `README.md`, write one paragraph drawn from the vision's Problem, Users and Goals: what the product is, who it is for, and why it exists, ending with a link to `docs/vision.md`. Keep anything already there that is still true. Done when `cruze validate` reports no `readme-overview` warning.
-10. **Commit,** with a message such as `docs: envision the project`.
-
-Done when `cruze status` shows `docs/vision.md` approved, the README says what the project is, and the glossary holds every domain term the vision uses.

package/skills/explore/SKILL.md

@@ -1,39 +0,0 @@
----
-name: cruze-explore
-description: Thinks an idea through with the user before any design, comparing options and sketching flows, and writes nothing until the user asks to capture it.
----
-
-# Explore
-
-Explore is the optional thinking partner that can come before any other Cruze step. It turns a loose idea into clear options and, when the user wants, a captured note that the next step takes as input. It never writes a design, creates work or records an approval.
-
-## Steps
-
-1. **Frame the problem.** Ask what prompted the idea, who it affects, and what outcome would make it worthwhile. If the user starts from a solution, restate the problem underneath it and confirm it. Done when you can state the problem in one sentence the user agrees with.
-2. **Read what exists.** Read whichever of these exist: `docs/vision.md`, `docs/glossary.md`, `docs/architecture.md` as "Reading it" in `.agents/skills/cruze-formats/reference/architecture.md` says, `docs/roadmap.md`, and the code the idea touches. Run `cruze status` to see work in flight. Use the glossary's words from here on, following `.agents/skills/cruze-domain-language/SKILL.md`.
-3. **Separate facts from guesses.** List what is known evidence, what is a hypothesis, and what is a preference. Look up any fact you can rather than asking the user for it.
-4. **Diverge.** Lay out two to four genuinely different approaches, including leaving things as they are when that is credible. For each, give what it changes, what it leaves alone, its benefits, its costs and failure modes, the assumptions it rests on, and what evidence would tell it apart from the others. Show what each approach looks like, following `.agents/skills/cruze-grilling/illustrating.md`.
-5. **Converge.** Compare the strongest options against the user's outcome, the vision's goals and constraints, and the architecture. Challenge assumptions and accidental scope growth, following the challenge rules in `.agents/skills/cruze-grilling/SKILL.md`. Recommend one option only when its trade-offs are understood. Otherwise recommend the smallest step that would settle the question, such as a spike, a measurement or a research question.
-6. **Offer to capture.** Summarize the problem, the options, the trade-offs, your recommendation and the open questions, then ask whether to capture them. When the user declines, stop here: the discussion itself was the result.
-
-## Capturing
-
-Only when the user says to capture:
-
-1. Run `cruze new note <slug> --title "<title>" --kind explore --about <subjects>`, naming the feature slugs or contexts the idea concerns, or `project`, and write the note at the path it returns.
-2. Give the note these sections: `## Problem`, `## Options`, `## Recommendation` and `## Open questions`. Mark each statement as fact, hypothesis, preference or recommendation.
-3. Done when the note stands on its own for a reader who wasn't in the conversation.
-
-## Handing off
-
-Name the next step, and pass the note's path to it when there is one:
-
-| The idea is | Next step |
-| --- | --- |
-| A new project, or the project's first vision | `envision`, at project scope |
-| A new capability whose requirements aren't settled | `envision "<feature>"` |
-| A capability whose requirements are settled | `architect "<feature>"` |
-| A small change to existing behaviour | `architect "<tweak>"` |
-| A defect in built behaviour | `triage "<symptom>"` |
-| A decision already made that now looks wrong | `rethink` |
-| Not worth doing now | `cruze features add <slug> --summary <text> --goals <ids>`, with the user's agreement, to keep it on the future list |

package/skills/formats/reference/architecture.md

@@ -1,84 +0,0 @@
-# Architecture format
-
-`docs/architecture.md` is the living model of how the system is built. Every step reads it, including build and review. It describes the designed system for the current and upcoming releases. Each element's managed `Status` says whether it is still `planned` or already `built`.
-
-Template: [../templates/architecture.md](../templates/architecture.md).
-
-## Reading it
-
-Read the prose sections whole: the Overview, Bounded contexts, Dependency rules, Cross-cutting concerns and Decisions. Reach elements through the CLI. `cruze show --index` lists every element of the architecture and specs on one line, with its status, its module and the work in flight that changes it, and `cruze show --index <context>` lists one context or capability with its scenarios. `cruze show <ID>...` prints the chosen elements' bodies, with each in-flight delta's version beside the living one. The index also gives the architecture's size: under 6,000 words, read it whole instead. One project's architecture held 52k words, and an architect run read all of it to find the few elements it would extend.
-
-## Sections
-
-The document has these `##` sections, in this order. Each holds elements of one kind as `###` heading elements, plus any `VIEW` diagrams that summarize them. A section with no elements yet keeps its heading and a one-line note.
-
-| Section | Kind | Holds |
-| --- | --- | --- |
-| Overview | `VIEW` | One paragraph on the system, then a context diagram |
-| Bounded contexts | `CTX` | Each context's purpose and what it depends on |
-| Domain model | `ENT` | Entities, aggregates, value objects, domain services, policies and domain events, with invariants and relationships |
-| Use cases | `UC` | The application API: what callers can ask the system to do |
-| Ports | `PORT` | Capabilities the application needs (driven) or offers (driving) |
-| Adapters | `ADP` | Technology behind ports, and inbound adapters that drive use cases |
-| Flows | `FLOW` | How elements interact for key scenarios, as sequence diagrams |
-| Modules | `MOD` | Where each element lives in the source tree |
-| Dependency rules | `RULE` | What may import what |
-| Cross-cutting concerns | `XC` | Errors, configuration, logging, concurrency, security |
-| Decisions | none | Links to ADRs, one line each, then project-level settled decisions as `D<n>: <decision> (<reason>)`, including overrides of Cruze's advice |
-
-## Element facts
-
-Facts are `- Key: value` items. Keys marked required must be present; the others appear when they apply. Multi-valued facts use sub-items.
-
-| Kind | Required facts | Optional facts |
-| --- | --- | --- |
-| `VIEW` | a Mermaid block | |
-| `CTX` | `Purpose` | `Depends on` (context IDs, with what is used) |
-| `ENT` | `Kind` (`aggregate`, `entity`, `value`, `service`, `policy` or `event`), `Module`, `File` | `Invariants`, `Relationships`, `States` (for state machines) |
-| `UC` | `Input`, `Output`, `Errors`, `Uses`, `Module`, `File` | `Serves` (REQ IDs) |
-| `PORT` | `Direction` (`driven` or `driving`), `Operations`, `Module`, `File` | `Implemented by` |
-| `ADP` | `Implements` (a driven port) or `Drives` (use cases), `Technology`, `Module`, `File` | `Adopts` (library and adopt-or-build reason), `Format` (the stored or wire format it owns, or where its schema lives) |
-| `FLOW` | `Elements`, a Mermaid `sequenceDiagram` | `Serves` (SCN IDs, once they exist), `Failure paths` |
-| `MOD` | `Path` (a directory ending in `/`, or one file; list several in backticks, never a glob, including every file the module owns outside its directory, such as a build script), `Layer` (`core`, `domain`, `application`, `adapter` or `composition`) | |
-| `RULE` | one or two sentences of rule | `Enforced by` (config layer names) |
-| `XC` | prose | |
-
-Rules for facts:
-
-- Membership is never listed twice. An element's scope names its context, and its `Module` fact names its module; contexts and modules don't list their members, so adding an element never changes them.
-- `File` names the real source path, one per element, with sub-items when an element spans files. Every element with code has one: an element without a file cannot be built, checked or reviewed.
-- `Operations` lists each operation as a sub-item with its signature in the project's language, then its contract: what it guarantees, its failure cases and who owns cleanup.
-- `Relationships` sub-items read `<verb> <ID> (<cardinality>)`, for example `- has one ENT-inventory.console-path (1)`.
-- `Future`, on any element, records a seam kept open for later and what it will need, so later features extend the design rather than rework it. It names the need it serves: the vision's `LATER` capability, by ID, so a change to that capability makes the design stale, or the feature on the map or the roadmap, by slug. `cruze validate` warns `future-unanchored` when it names neither.
-- Add another fact when it helps a reader, such as `Failure attribution` on an adapter. The CLI checks the listed facts and ignores the others.
-- An element that grows over several features, such as the CLI adapter gaining a command per feature, gets a `MODIFIED` operation in each feature that extends it. Its status goes back to `planned` when that feature's first change lands, and to `built` when the change that builds the new text lands.
-- The CLI adds `- Status: planned` to a new element and flips it to `built` when a landed change builds it. Leave it out of what you write.
-
-## Diagrams
-
-- Every `FLOW` has one `sequenceDiagram`. Participants are element titles, and every participant's ID appears in the flow's `Elements`.
-- The Overview `VIEW` shows contexts, the inbound adapters that drive them and the external systems adapters reach.
-- A `VIEW-domain-model` class diagram in the Domain model section shows every `ENT` and its relationships.
-- Keep a diagram to at most 15 nodes. Split a bigger picture into two views.
-
-## Architecture delta
-
-A feature, or a standalone change, proposes architecture edits in its `## Architecture delta` section. Each operation is a `###` heading:
-
-```markdown
-### ADDED PORT-access.hop-connector: HopConnector
-- Direction: driven
-- ...the full element body, as it will read in architecture.md
-
-### MODIFIED UC-access.open-console: Open a console
-- ...the full new body, replacing the old one
-
-### REMOVED ADP-access.telnet-connector: Telnet connector
-- Reason: telnet support was dropped from the release scope
-```
-
-- `ADDED` introduces an ID that doesn't exist yet. `MODIFIED` replaces an existing element's whole body. `REMOVED` retires an ID and needs a `Reason`. Once it merges, no living doc may cite the ID, so modify each element that cites it to describe it in words.
-- The element kind decides its section. `land` appends an added element to the end of its section.
-- A delta never touches `Status`. A change's `Builds` scope decides what becomes built.
-- A delta with no operations says `None.` under its heading.
-- Direct edits to `docs/architecture.md` happen only at project scope and through `rethink`. Every other design change arrives as a delta.

package/skills/formats/reference/config.md

@@ -1,80 +0,0 @@
-# Configuration format
-
-`.cruze/config.yaml` configures the CLI for one project. `cruze init` creates it. Project-scope architect fills in `source`, `tests` and `layers` from the module map.
-
-```yaml
-version: 1
-cruze: "0.0.2"
-standards: "0.0.2"
-project: "Console Access"
-tracker: markdown
-
-source: ["src/**/*.rs"]
-tests: ["src/**/*.rs", "tests/**/*.rs"]
-
-check:
-  max_lines: 600
-  max_types: 12
-  exceptions:
-    - path: src/cli/args.rs
-      reason: the clap derive struct lists every flag in one place
-
-commands:
-  format: cargo fmt --check
-  lint: cargo clippy -- -D warnings
-  test: cargo test
-  run: cargo run -- list
-
-review:
-  command: ["claude", "-p", "--allowedTools", "Read Grep Glob Bash(git diff:*) Bash(git log:*) Bash(git show:*) Bash(cruze:*) Bash(cargo:*)"]
-  decide: exceptions
-
-changes:
-  min_builds: 3
-  max_scenarios: 30
-  max_tasks: 25
-  exceptions:
-    - item: 2026-09-25-open-console/02-ssh-hops
-      reason: every scenario runs through one reconcile, which can't be split without building it twice
-
-references:
-  - path: third_party/rfc4254.txt
-    use: the SSH connection protocol every hop speaks; channels and their failures must follow it
-
-layers:
-  - name: inventory-domain
-    paths: ["src/inventory/domain/**"]
-    may_import: []
-  - name: inventory-app
-    paths: ["src/inventory/app/**"]
-    may_import: [inventory-domain]
-```
-
-| Key | Meaning |
-| --- | --- |
-| `version` | Format version. Always `1` for now. |
-| `cruze` | The Cruze version whose skills the project installed. `cruze install` writes it; don't edit it, except to go back to an older version on purpose. |
-| `standards` | The Cruze version whose expectations the code meets. `cruze realign done` moves it up. A rule a later release added reports but fails no CI until then. Without it, a project meets `0.0.1`. |
-| `project` | The project name, quoted. |
-| `tracker` | Where work items live. `markdown` is the only value in V1. |
-| `source` | Globs of the source files `cruze check` inspects. |
-| `tests` | Globs of the files `cruze trace` searches for scenario IDs. |
-| `check.max_lines` | Line budget per source file, a backstop against a file that has outgrown one responsibility. `cruze init` sets `600`. Test files outside `source` have no budget, and a Rust file's `#[cfg(test)]` modules don't count. |
-| `check.max_types` | Budget of top-level types per source file. `cruze init` sets `12`. |
-| `check.exceptions` | Files allowed past a budget, or Rust test files allowed under `src/` (`test-placement`), each with a `path` and a `reason`. `realign` adds entries whose reason ends `scheduled in <ref>`, and landing that change removes them. |
-| `references` | External documents the design must comply with, such as a protocol specification or a standard, each with its `path` in the repository and its `use`: what it governs. Optional. `cruze show` lists them, and architect, plan, build and the reviewers read the parts their scope relies on and cite them, such as `RFC 4254 §5.2`, in the design. |
-| `layers` | Each layer has a `name`, the `paths` it covers, and `may_import`, the layers it may depend on. |
-| `commands` | The project's commands by name, such as `test` or `run`. The foundation change fills them in, and `cruze land` copies them into the Commands section of `AGENTS.md`. When the suite has a slow tier, such as UI, device or end-to-end tests, `test` runs only the fast tier and `test_full` runs everything. The full suite is `test_full` when it is set, and `test` otherwise. |
-| `review.command` | The program and arguments `cruze review` runs to start an agent in a fresh context, with the prompt on standard input. Optional. `cruze init` sets it for Claude Code to run in print mode, allowed to read the project and run `git diff`, `git log`, `git show` and `cruze`. The verifier runs the system, so add the project's build and run commands. When it is unset, or its program isn't installed, `cruze review` hands the role's prompt back to the calling agent to run in a helper. |
-| `review.decide` | Which review findings the user decides. `exceptions`, the default: only findings whose fix changes behaviour, a designed port or contract, or another decision the user owns, and any the agent wouldn't simply fix as proposed. The agent fixes the rest and lists them. `all`: the user decides every finding. |
-| `changes.min_builds` | A feature's change that builds fewer elements than this gets a `change-too-small` warning: merge it into the change it continues. Default `3`. |
-| `changes.max_scenarios` | A change that delivers more scenarios than this gets a `change-too-large` warning: split it. Default `30`. |
-| `changes.max_tasks` | A plan with more tasks than this gets a `plan-too-large` warning. Default `25`. |
-| `changes.exceptions` | Features and changes the user accepted outside the band, each with the `item` (a feature's ID, `<feature>/<change>`, or a standalone change's ID) and the `reason`. The item's size warning stops. `cruze approve` refuses an item whose size warning still stands (`size-unaccepted`) until it is listed here or split. |
-
-Rules for layers:
-
-- A source file belongs to the first layer whose paths match it. A file in no layer may import anything, so every source file should be in a layer.
-- Imports of code outside the project, such as the standard library and dependencies, are always allowed. Adapter layers are where they belong, and review checks that.
-- A layer may import itself. Every other dependency is listed in `may_import`, and together they follow the `RULE` elements in the architecture.
-- Each `MOD` element's `Path` falls in exactly one layer, and the layer's `may_import` fits the module's `Layer`. A domain layer imports only domain layers, and nothing outside composition imports adapter layers.