@printpractical/cruze 0.0.11 → 0.0.13

package/README.md

@@ -10,7 +10,7 @@ It works with any agent that supports the [Agent Skills](https://agentskills.io)
 
 ## Status
 
-Version 0.0.11 is the eleventh preview. A change no longer loops between build, verify and rethink over edge cases: a code review finding blocks only when ordinary use reaches a failure that loses data, crashes, hangs or spins, a verify after a send-back reviews only the code changed since, and a missing limit, message or error case is settled as a detail inside build or verify. Early development. The CLI is complete for the V1 lifecycle. The document formats ship as the `cruze-formats` skill, the standards an agent designs and codes to ship as knowledge skills, and the whole workflow, from explore to land, ships as workflow skills. Claude Code is the agent tested so far.
+Version 0.0.13 is the thirteenth preview. A project starts with the first chunk you choose, its foundation: a product shell, a core component or a walking skeleton. Architect still designs the whole release end to end, in full for the foundation and at the boundaries for the rest. Early development. The CLI is complete for the V1 lifecycle. The document formats ship as the `cruze-formats` skill, the standards an agent designs and codes to ship as knowledge skills, and the whole workflow, from explore to land, ships as workflow skills. Claude Code is the agent tested so far.
 
 ## Why
 
@@ -35,7 +35,7 @@ The skills run `cruze` commands, so the agent needs `cruze` on its path. Install
 From a GitHub Release, without npm. Each release attaches the packed package:
 
 ```sh
-npm install -g https://github.com/PrintPractical/cruze/releases/download/v0.0.11/printpractical-cruze-0.0.11.tgz
+npm install -g https://github.com/PrintPractical/cruze/releases/download/v0.0.13/printpractical-cruze-0.0.13.tgz
 ```
 
 From npm, once a version is published there:
@@ -47,7 +47,7 @@ npm install -g @printpractical/cruze
 From the git repository, at a tag or `#main`. This needs git and access to the repository. npm 11 needs `--install-links` for a global git install, and the first `cruze` command builds the CLI, which takes a moment:
 
 ```sh
-npm install -g --install-links github:PrintPractical/cruze#v0.0.11
+npm install -g --install-links github:PrintPractical/cruze#v0.0.13
 ```
 
 ### 2. Set up a repository
@@ -61,7 +61,7 @@ cruze init
 When you didn't install from npm, tell `init` where Cruze came from, so the CI it writes runs the same source instead of the npm package:
 
 ```sh
-cruze init --package https://github.com/PrintPractical/cruze/releases/download/v0.0.11/printpractical-cruze-0.0.11.tgz
+cruze init --package https://github.com/PrintPractical/cruze/releases/download/v0.0.13/printpractical-cruze-0.0.13.tgz
 ```
 
 `init` asks for the project name, and which coding agent you use: `claude` for Claude Code, or `other` for any agent that reads `AGENTS.md` and `.agents/skills/`, such as Codex or OpenCode. It doesn't ask when you pass `--agent claude` or `--agent other`, or when the repository already has `CLAUDE.md` or `.claude/`. With `--yes`, or without a terminal, it sets up Claude Code. Then it creates:
@@ -73,7 +73,7 @@ cruze init --package https://github.com/PrintPractical/cruze/releases/download/v
 | `AGENTS.md` | Agent instructions; Cruze keeps its managed sections current |
 | `CLAUDE.md` | For Claude Code only: a link to `AGENTS.md` |
 | `.cruze/config.yaml` | Project configuration, including the Cruze version whose skills the project uses, and for Claude Code the command `cruze review` runs |
-| `.github/workflows/ci.yml` | CI that runs `cruze validate`, `check` and `trace`; the walking-skeleton change adds the language's build and test steps |
+| `.github/workflows/ci.yml` | CI that runs `cruze validate`, `check` and `trace`; the foundation change adds the language's build and test steps |
 | `.gitattributes` | Merges Cruze's journals line by line, so parallel branches don't conflict on them |
 | `.agents/skills/cruze-*` | The Cruze skills, also linked into `.claude/skills/` for Claude Code |
 

package/dist/domain/skill_budget.js

@@ -11,7 +11,7 @@ export const MAX_FILE_WORDS = 2100;
  * 0.0.10 the skills grew by half while nothing was removed. Lower this when text is cut. Raising it
  * is the maintainer's decision, with the reason in the commit that raises it.
  */
-export const BUNDLE_WORD_BUDGET = 44800;
+export const BUNDLE_WORD_BUDGET = 45800;
 
 /** Data the CLI reads or renders, rather than instructions an agent reads. */
 const NOT_INSTRUCTIONS = /(^|\/)(templates|notes)\//;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@printpractical/cruze",
-  "version": "0.0.11",
+  "version": "0.0.13",
   "description": "Spec-driven development for coding agents: one living model of the system, small deltas, convergent review.",
   "license": "Apache-2.0",
   "author": "Chris Buchter",

package/skills/architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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 walking skeleton), 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.
+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
@@ -40,7 +40,7 @@ Architect decides the how and the how big. It designs the domain, the ports and
 
 ## Next step
 
-- Project scope: `plan` for the walking-skeleton change.
+- Project scope: `plan` for the foundation change.
 - Feature scope: `plan` for the feature's first change.
 - Tweak scope: `plan` for the standalone change.
 

package/skills/architect/project.md

@@ -5,22 +5,25 @@ 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 walking-skeleton change, designed and ready for `plan`. It is approved later, once `plan` has filled its test plan and tasks.
+- 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. **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.
-4. **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.
-5. **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.
-6. **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.
-7. **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.
-8. **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`.
-9. **Dependency rules (`RULE`).** State what may import what, in one or two sentences each.
-10. **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.
-11. **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.
-12. **Overview (`VIEW-context`).** Draw the context diagram last, once the adapters and external systems are known.
+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.
 
@@ -35,10 +38,10 @@ Add the language's build output and tool caches to `.gitignore` now, such as `/t
 ## 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 `walking-skeleton` 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 walking skeleton.** Run `cruze new change walking-skeleton --title "Walking skeleton"`. Then:
-   - Size the elements it builds for the skeleton. Anything the walking skeleton 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 skeleton needs. Record their planned growth in `Future` facts; later features grow them through `MODIFIED` operations.
-   - Choose the thinnest end-to-end slice that crosses every layer: one real inbound adapter, one use case, the domain it needs, one driven adapter and the composition root. It also makes CI real: `cruze init` already runs `cruze validate`, `cruze check --ci` and `cruze trace --all` there, and the skeleton adds the language's format, lint, build and test steps. `plan` fills `commands:` in `.cruze/config.yaml` for it.
+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.
@@ -47,9 +50,19 @@ Add the language's build output and tool caches to `.gitignore` now, such as `/t
    - 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 walking skeleton together.
+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`.

package/skills/architect/walkthrough.md

@@ -2,7 +2,7 @@
 
 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 walking skeleton.
+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
 
@@ -12,16 +12,16 @@ Write it in the glossary's terms, as what callers can do and what happens when t
 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 an inbound adapter makes.
-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 walking skeleton instead.
-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.
+   - 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 walking-skeleton `change.md`, and the ADRs in `docs/adr/`.
+- 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.
 

package/skills/dependency-approval/SKILL.md

@@ -42,7 +42,7 @@ Recommended: adopt `russh`. Approve?
 ## Recording
 
 - A feature or standalone change records it as a row in `## Adopt or build`: the component, `adopt`, the package, and the reason. The adapter that uses it carries an `Adopts` fact in the architecture delta.
-- At project scope, the adapter's `Adopts` fact in `docs/architecture.md` records it, and a dependency no adapter owns, such as a test framework or a build tool, goes in the walking-skeleton change's `## Adopt or build`. A choice that is hard to reverse, such as an async runtime, a framework or a database, also gets an ADR.
+- At project scope, the adapter's `Adopts` fact in `docs/architecture.md` records it, and a dependency no adapter owns, such as a test framework or a build tool, goes in the foundation change's `## Adopt or build`. A choice that is hard to reverse, such as an async runtime, a framework or a database, also gets an ADR.
 - Choosing to build commodity functionality is also the user's call: a parser, serializer, protocol codec, CLI parser, URL or version handling, retries, compression, or date and time handling. Record it as a `build` row with the concrete reason for owning the code.
 - When a build finds it needs a dependency the design didn't name, stop the task and ask as above. An approval changes the design, so record it through the rethink step at feature level, or at change level for a standalone change. A refusal keeps the decision open: don't add the package provisionally, and don't hand-write a replacement unless the user chooses that.
 

package/skills/formats/reference/config.md

@@ -64,7 +64,7 @@ layers:
 | `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 walking-skeleton 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. |
+| `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`. |

package/skills/formats/reference/durable-docs.md

@@ -69,6 +69,6 @@ The current release, as an index. It changes only when a feature or standalone c
 | `## Coverage` | Table of Goal and the items that serve it. Every goal in scope has at least one item |
 | `## Status` | Managed: each started item's folder ID and state (`designing`, `building` or `landed`). `cruze new` adds the row and `cruze land` updates it |
 
-- Items are named by slug. The first item of a new project is the `walking-skeleton` standalone change.
+- Items are named by slug. The first item of a new project is the `foundation` standalone change, of the kind the user chose at architect.
 - `Blocked by` lists slugs that must land first. The blocking graph has no cycles.
 - A new release replaces `## Release` and `## Phases`. Landed items leave the roadmap once the release closes; the feature map in the vision keeps the record.

package/skills/formats/reference/work-items.md

@@ -44,7 +44,7 @@ A feature is designed in two steps. Feature-scope `envision` writes the intent,
 These rules close the gap between a design and what gets built. `cruze validate` checks them.
 
 - Every ID in a feature's deltas appears in the scope of exactly one of its changes. For a standalone change, that is its own scope. A `MODIFIED` or `REMOVED` requirement is covered by its ID or by one of its scenarios.
-- A scope may also name elements already in the living docs with status `planned`, such as a walking-skeleton change that builds elements the project architecture defined. An element with no status yet counts as planned: it appears only while the architecture has never been approved, so project-scope architect can write the walking skeleton before that first approval.
+- A scope may also name elements already in the living docs with status `planned`, such as the foundation change that builds elements the project architecture defined. An element with no status yet counts as planned: it appears only while the architecture has never been approved, so project-scope architect can write the foundation before that first approval.
 - The first change of a feature to land merges the feature's whole delta, so the living docs never cite something a later change hasn't merged yet. What this change delivers or builds becomes `built`. Everything else arrives as `planned`, including a `MODIFIED` element whose new text isn't built yet. Each later change flips what it builds to `built`.
 - A `REMOVED` operation applies when the change whose scope lists it under `Removes` lands.
 - Under a `MODIFIED` requirement, a scenario must be in some change's scope when it is new or its text changed. An unchanged scenario the requirement keeps needs no change.

package/skills/formats/templates/roadmap.md

@@ -6,17 +6,17 @@
 
 ## Phases
 
-### Phase 1: Walking skeleton
+### Phase 1: Foundation
 
 | Item | Kind | Goals | Blocked by |
 | --- | --- | --- | --- |
-| walking-skeleton | change | <GOAL IDs> | |
+| foundation | change | <GOAL IDs> | |
 
 ### Phase 2: <name>
 
 | Item | Kind | Goals | Blocked by |
 | --- | --- | --- | --- |
-| <slug> | feature | <GOAL IDs> | walking-skeleton |
+| <slug> | feature | <GOAL IDs> | foundation |
 
 ## Coverage
 

package/skills/grilling/SKILL.md

@@ -20,7 +20,7 @@ Interview the user until you both understand the design the same way. Decisions
 ## A round
 
 ````markdown
-Where we are: architect for 2026-09-25-open-console, round 2. Settled: D1 (a console session may cross jump hosts), D2 (credentials come from the vault).
+Where we are: architect for 2026-09-25-open-console, round 2. Settled: a console session may cross jump hosts, and credentials come from the vault.
 
 **Q4. Where the jump-host list lives**
 Per device in the device config, or as named hosts that devices reference. Named hosts avoid repeating a host's address and credentials across devices, but add a second lookup.
@@ -45,6 +45,8 @@ Recommended: named hosts, because the lab config already shares two jump hosts a
 - Ask about behaviour and trade-offs in the user's terms and the glossary's words, not about implementation mechanics. Where the trade-off is in the code's shape, show the shape.
 - When the user answers "you decide" or "I don't know", take your recommendation and record it with "(recommended; the user deferred)".
 - When an answer contradicts an earlier decision, point to that decision and ask which one stands.
+- When the user doubts part of the design, calling it rigid, heavy or messy, one option removes or shrinks it, with what that costs. One user called a status shape rigid, was offered more of it, and stopped a build over its unused fields a day later.
+- When making one answer hold needs new types, rules or error cases, and those need fixes of their own, stop before the next round. Show what the answer has grown beside the simplest alternative that meets the user's need, and let the user choose. One rethink grew four types over eleven questions before a review found five blockers in them; the alternative was 40% smaller.
 
 ## What to ask and what to decide
 

package/skills/grilling/illustrating.md

@@ -4,8 +4,9 @@ The user decides from what they can picture. A question about a port's errors or
 
 ## Reading cold
 
-- Open each round, and each message of review exceptions, with one line saying where things stand: the work item, the step, and the earlier decisions this round builds on, such as `Where we are: architect for 2026-10-08-subscriptions, round 3. Settled: D2 (one stream per session), D4 (events carry revisions).`
-- Say what an ID means in plain words the first time a message uses it, such as `SCN-configuration.reject-taken-priority (a second set asking for a priority already taken is refused)`.
+- The user knows what the product should do, not the design's internals. Before a question about a part of the design, say in a sentence or two what that part is, what it does today and why the question comes up, and show it. Ask about what the user will notice, and explain the mechanism only as far as the choice needs. In one day of one project, the user asked four times what a question meant, from "what's the definition of a condition?" to "give me an ELI5".
+- Open each round, and each message of review exceptions, with one line saying where things stand: the work item, the step, and the earlier decisions this round builds on, such as `Where we are: architect for 2026-10-08-subscriptions, round 3. Settled: one stream per session, and events carry revisions.`
+- The user doesn't know the design's IDs by heart. Name each requirement, scenario, element, decision or task in plain words, and add its ID after them in parentheses only when the user may want to look it up: "a second set asking for a priority already taken is refused (SCN-configuration.reject-taken-priority)". Never let an ID stand alone or be what a sentence is about, as in "D11 forbids this". In one project, 197 of the 215 IDs in 75 questions stood alone, and the user misread what was asked.
 - Each question says what it decides and why it matters now, without pointing back to an earlier message.
 
 ## Choosing the illustration
@@ -22,7 +23,7 @@ Show each option, side by side, with the form that fits what the question decide
 | A stored format or a config file | A sample of the file |
 | A dependency | The code with it and the code without it |
 
-Leave out the illustration only when the question is about a name, a number or the wording of a sentence, where it would repeat the words.
+Leave out the illustration only when the question is about a name, a number or the wording of a sentence, where it would repeat the words. A question asked through a pick-one tool carries it too: in each option's preview where the tool has one, otherwise in a message just before. One build asked through such a tool with only file and function names in its options, and the user had to ask what it meant.
 
 ## Writing it
 

package/skills/plan/SKILL.md

@@ -26,7 +26,7 @@ Plan turns one designed change into work an implementer can do without guessing:
 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 walking skeleton 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>`.
+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
@@ -50,9 +50,9 @@ A prefactor changes structure, not behaviour, so it delivers no scenarios and it
 
 The plan review checks these with the plan rubric's Prefactor item.
 
-## The walking skeleton
+## The foundation
 
-The walking-skeleton change also makes CI and the project's tooling real. Its plan adds:
+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.

package/skills/realign/notes/0.0.12.md

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

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

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

package/skills/research/SKILL.md

@@ -15,7 +15,7 @@ Run these steps for each component in a design that isn't domain logic. Domain l
 2. Look in order: the language's standard library, the project's already-approved dependencies, then mature libraries in the ecosystem. Done when you have checked all three.
 3. For the two or three serious candidates, gather the evidence in [evaluation.md](evaluation.md).
 4. Recommend one. Adopt a library, or build with a concrete reason: the behaviour is specific to this product, no candidate meets a stated constraint, every candidate brings disproportionate risk or complexity, or the capability is the product itself. Weigh the candidates as `.agents/skills/cruze-dependency-approval/SKILL.md` says under Weighing, where avoiding a dependency is never a reason.
-5. Record the result as a row in the `## Adopt or build` table of the feature or standalone change, as Component, Decision, Choice and Reason. At project scope, record it as the adapter's `Adopts` fact, and put rows for anything no adapter owns in the walking-skeleton change's `## Adopt or build`. When the evidence runs longer than the reason, run `cruze new note <slug> --title "<title>" --kind research --about <feature slug or context>`, write the evidence there, and cite that note in the reason.
+5. Record the result as a row in the `## Adopt or build` table of the feature or standalone change, as Component, Decision, Choice and Reason. At project scope, record it as the adapter's `Adopts` fact, and put rows for anything no adapter owns in the foundation change's `## Adopt or build`. When the evidence runs longer than the reason, run `cruze new note <slug> --title "<title>" --kind research --about <feature slug or context>`, write the evidence there, and cite that note in the reason.
 6. Take the recommendation to the user. Adopting means a new dependency, which follows `.agents/skills/cruze-dependency-approval/SKILL.md`. Building commodity functionality is the user's call as well.
 7. Verify what the design will rely on. List each claim the design or its testing approach makes about anything it doesn't build:
    - an adopted library or tool: the features or flags it needs, and each command the design spells out, such as a CI step;

package/skills/rethink/SKILL.md

@@ -15,8 +15,8 @@ Finding a design flaw mid-build is information, not failure. Rethink amends the
    - **Discovery:** it is new information no step could have had.
 
    Tell the user the level and the kind in one line, and let them correct it.
-3. **Load the standards.** Read `.agents/skills/cruze-grilling/SKILL.md`. At feature or architecture level, also read `.agents/skills/cruze-hexagonal-design/SKILL.md`. Also read the format reference for the document you will amend: `.agents/skills/cruze-formats/reference/architecture.md`, `specs.md`, `work-items.md` or `durable-docs.md`.
-4. **Amend that level,** following the level's section in [levels.md](levels.md). Settle any decision the amendment needs with the user, and record it as that level records decisions.
+3. **Load the standards.** Read `.agents/skills/cruze-grilling/SKILL.md`. At feature or architecture level, also read `.agents/skills/cruze-hexagonal-design/SKILL.md`, `.agents/skills/cruze-research/SKILL.md` and `.agents/skills/cruze-dependency-approval/SKILL.md`. Also read the format reference for the document you will amend: `.agents/skills/cruze-formats/reference/architecture.md`, `specs.md`, `work-items.md` or `durable-docs.md`.
+4. **Amend that level,** following the level's section in [levels.md](levels.md). Settle any decision the amendment needs with the user, and record it as that level records decisions. At feature level and above, design the amendment as architect designs a feature, following the Rules in `.agents/skills/cruze-architect/SKILL.md`: read the vision's principles and capabilities that must stay possible, the feature map and the roadmap, and design for the features ahead while building only what the work in hand needs. Each option you offer says how the features ahead would use it, which capabilities it keeps open, and what it does to a running device or service, such as across a restart, an upgrade or a downgrade. In one architecture rethink, the user had to ask whether an option would still work for the apps the product plans to host, and point out that refusing to start after a downgrade could brick a router.
 5. **Keep completed work.** A ticked task stays ticked unless the amendment changes its owner, its files, or what it proves. Reopen each task that changed with `cruze task reopen T<n> "<what changed>"`. Its commits stay in history, and build redoes the task.
 6. **Re-approve what went stale.** Run `cruze status` and work from the top down. The amended document comes first, and the user approves it as its level says. Then take each feature or change it lists as `upstream changed`, whose own text you didn't edit:
    - Run `cruze diff <ref>`. It shows each changed element's approved and current text, and whether the work's delta needs a rebase. Check the work still holds against it. When it doesn't, amend it too, and the user approves it as an amended document.

package/skills/rethink/levels.md

@@ -4,7 +4,7 @@
 
 A detail settles a limit, timeout, buffer size, message or error case that an element of the work in progress doesn't give, with no new element, port operation or dependency, and no change to an approved scenario. Build and verify run it without leaving their step: one message length settled as a full rethink took 75 minutes.
 
-1. Ask the user, recommending a value and saying what the code then does.
+1. Ask the user, recommending a value and showing what the code then does, as `.agents/skills/cruze-grilling/illustrating.md` says.
 2. Amend the element where it lives, in the delta or `docs/architecture.md`, adding at most one failure scenario and its test plan row for a new error case. Run `cruze validate`; done when it reports no errors.
 3. Commit the text with the code and its test, naming the task. Tasks stay ticked.
 4. The user approves the amended document. Re-stamp what went stale, and record the rethink with `level=detail`, as the skill's steps 6 and 7 say.

package/skills/roadmap/SKILL.md

@@ -9,7 +9,7 @@ description: Orders the release's features and standalone changes into phases wi
 
 ## Steps
 
-1. **Read the state.** Read `docs/vision.md` (goals and feature map), `docs/roadmap.md`, and `docs/architecture.md` as "Reading it" in `.agents/skills/cruze-formats/reference/architecture.md` says, and run `cruze status`. The vision must be approved. When no roadmap exists, stop: project-scope `architect` creates the first one with the walking skeleton.
+1. **Read the state.** Read `docs/vision.md` (goals and feature map), `docs/roadmap.md`, and `docs/architecture.md` as "Reading it" in `.agents/skills/cruze-formats/reference/architecture.md` says, and run `cruze status`. The vision must be approved. When no roadmap exists, stop: project-scope `architect` creates the first one with the foundation.
 2. **Pick the job.**
    - **Add an item:** a feature or standalone change the user wants in this release. Its slug comes from the feature map when it is there.
    - **Reorder or drop:** the order or scope of the release changed.

package/skills/roles/design-reviewer.md

@@ -6,7 +6,7 @@ You review a design, or a change's plan, before any code exists. You find the pl
 
 - The artifact under review:
   - Feature scope: the feature's `feature.md`, and the output of `cruze show <ref>` for the elements its delta cites, each with where it sits, and the settled ledger.
-  - Project scope: `docs/architecture.md`, `.cruze/config.yaml` and `docs/roadmap.md`, plus the walking-skeleton change once it exists.
+  - Project scope: `docs/architecture.md`, `.cruze/config.yaml` and `docs/roadmap.md`, plus the foundation change once it exists.
   - A plan: the change's `change.md`, the output of `cruze show <ref>`, and the output of `cruze status --overlap --change <ref>`.
 - The living docs it builds on: `docs/vision.md`, `docs/glossary.md`, the ADRs in `docs/adr/`, the specs in `docs/specs/` that the artifact cites, and, from `docs/architecture.md`, its Overview, Dependency rules, Cross-cutting concerns and Decisions sections plus each element `cruze show` lists as cited. Read any other element with `cruze show <ID>`, and find what exists with `cruze show --index`. Read the whole architecture only at project scope.
 - The settled ledger, as `.agents/skills/cruze-roles/SKILL.md` defines it, with the output of `cruze journal list --event disposition --item <ref>`.

package/skills/roles/design-rubric.md

@@ -1,10 +1,10 @@
 # Design rubric
 
-The design reviewer's rubric for a design: the architecture at project scope, or the design of a feature or a standalone change. Review against these items and nothing else. Each finding names one.
+The design reviewer's rubric for a design: the architecture at project scope, or the design of a feature or a standalone change. Review against these items and nothing else. Each finding names one. At project scope, items 6 and 11 hold in full for what the foundation builds; a later part may leave a specific open when a `Future` fact names it, but not an operation or data that crosses into the foundation.
 
 1. **Behaviour.** Every requirement has at least one scenario. Every scenario has concrete values, one WHEN, and a THEN a person could check. Failure behaviour the user will meet has its own scenario.
 2. **Seams.** Every scenario can be driven through a use case, or through an inbound adapter when the outcome is what that adapter shows. Every driven port the use case needs can be faked.
-3. **Placement.** Every new or changed element with code has a `Module` whose `Layer` fits its role and a `File` with a real path. No generic modules, and no file is likely to hold two responsibilities. The layout is the one normal for the kind of system and the language, and every layer, module, package or target split beyond a context's `core` and its adapters has a recorded reason. Every element, fact and value serves a requirement in scope, or a `Future` fact the feature map or a `LATER` capability calls for. Anything reserved for a need nobody stated is a finding, and so is anything built, rather than left room for, for a `LATER` capability.
+3. **Placement.** Every new or changed element with code has a `Module` whose `Layer` fits its role and a `File` with a real path. No generic modules, and no file is likely to hold two responsibilities. The layout is the one normal for the kind of system and the language, and every layer, module, package or target split beyond a context's `core` and its adapters has a recorded reason. Every element, fact and value serves a requirement in scope, or a `Future` fact the feature map or a `LATER` capability calls for. Anything reserved for a need nobody stated is a finding, and so is anything built, rather than left room for, for a `LATER` capability. A field or value serves a need only when a person, a tool or another element reads it in a scenario or a `LATER` row; a scenario that only checks it is written doesn't count. A design carried over from an earlier build or a seed is checked the same way: one project built a clock port and timestamp parsing for a status field nothing read.
 4. **Direction.** Every dependency points inward and is allowed by the `RULE` elements and the `layers:` in `.cruze/config.yaml`.
 5. **Adopt or build.** Every component that isn't domain logic has an adopt-or-build decision with a reason, and every new dependency is named with the features the design uses. Every type, trait, macro, framework or tool the design names from outside the project comes from a dependency and feature the design approves, declared by each crate, package or target that uses it, test support included, and allowed by the import rules in `XC` and the `layers:` in `.cruze/config.yaml`. A choice whose reason is avoiding a dependency, a crate or a feature, where the idiomatic design needs one, is a concern: name the idiomatic design. Every command the design spells out, such as a CI step, is spelled as that version's `--help` or source shows it. A claim the design relies on that the research left unverified is a blocker.
 6. **Contracts.** Every new or changed port's `Operations` state what each operation guarantees, how it fails, and who owns cleanup. Check each use case and each port operation for the values build would otherwise have to pick: a named error for every failure a caller can meet, where a panic, an `expect` or "caller error" counts as missing; a number for every timeout, limit, buffer and poll interval; what a caller observes after each state transition, and what happens to queued or in-flight work at it; and one owner for every message a scenario quotes. Each one missing is a blocker: two projects settled 35 of them during build, as deviations.
@@ -19,7 +19,7 @@ The design reviewer's rubric for a design: the architecture at project scope, or
    - at feature scope, the prose in `docs/architecture.md`, the ADRs and the feature itself that the delta makes untrue, such as an Overview sentence, a `D<n>` line describing an element the delta splits or replaces, or any sentence stating a rule the delta retires;
    - each message or value a scenario quotes from code already built, such as an error's printed form or a revision every write advances, against the code that produces it;
    - each new or renamed operation, method or builder step against the others the same type, trait or caller reaches, for two names a caller can't tell apart, such as an `events` method beside an `events` trait method the type also implements.
-9. **Slicing.** Each change is a vertical slice that delivers scenarios end to end and can land on its own. The order respects `Depends on`, and the first change proves the design end to end. Each change carries enough work to be worth its own plan review, code review and verify: changes that build one or two elements each on the same adapters or screens, in a chain, are one change split too fine. A change that one verifier run can't hold is split too coarse. A `change-too-small`, `change-too-large` or `feature-size` warning from `cruze validate` is a finding, unless a decision records the user accepting it. A change `Builds` an element only when its delivered scenarios prove the whole body; an element whose duties arrive in several changes is split into elements that each arrive whole. `Depends on` names every earlier change that builds something this change's scenarios need. At project scope, the roadmap starts with the walking skeleton, and every goal in the release is covered.
+9. **Slicing.** Each change delivers scenarios end to end, through a real interface, and can land on its own. The order respects `Depends on`. At project scope, the first change builds the kind of foundation the user chose, recorded in `## Decisions`, and nothing beyond it. Each change carries enough work to be worth its own plan review, code review and verify: changes that build one or two elements each on the same adapters or screens, in a chain, are one change split too fine. A change that one verifier run can't hold is split too coarse. A `change-too-small`, `change-too-large` or `feature-size` warning from `cruze validate` is a finding, unless a decision records the user accepting it. A change `Builds` an element only when its delivered scenarios prove the whole body; an element whose duties arrive in several changes is split into elements that each arrive whole. `Depends on` names every earlier change that builds something this change's scenarios need. At project scope, the roadmap starts with the foundation, and every goal in the release is covered.
 10. **Ambiguity.** Name each point where a fresh implementer could reasonably build something different from what the user expects.
 11. **Flow control and recovery.** Follow each message, request and event from its source to its consumer through every task, channel and queue the design names, against `.agents/skills/cruze-hexagonal-design/runtime.md`. Check:
    - each bounded queue or buffer: what a sender does when it is full, and which other work waits meanwhile. One slow peer, link, subscriber or consumer holds up only its own work unless a decision says otherwise, so one queue or one task serving several peers needs a reason. A limit meant to tell a stalled consumer from a burst says how it tells them apart;
@@ -38,3 +38,4 @@ The design reviewer's rubric for a design: the architecture at project scope, or
    - each settled decision of the design that states long-term intent, such as "eventually" or "later": it is a `LATER` row in the vision, since the decision is archived when the work lands.
 
    A departure from a principle with no amendment, a `likely` capability closed off, or a design resting on an open hand-off row, is a blocker; a `possible` one closed off is a concern.
+13. **Typed inside.** Each value one of the system's own components passes another in the same process has its own type, as the standards' domain rules say. A serialization format between them, such as a JSON value, a raw frame or an untyped map, is a concern even when an ADR gives the reason, so the walkthrough brings it to the user.

package/src/domain/skill_budget.ts

@@ -11,7 +11,7 @@ export const MAX_FILE_WORDS = 2100;
  * 0.0.10 the skills grew by half while nothing was removed. Lower this when text is cut. Raising it
  * is the maintainer's decision, with the reason in the commit that raises it.
  */
-export const BUNDLE_WORD_BUDGET = 44800;
+export const BUNDLE_WORD_BUDGET = 45800;
 
 /** Data the CLI reads or renders, rather than instructions an agent reads. */
 const NOT_INSTRUCTIONS = /(^|\/)(templates|notes)\//;

package/templates/init/AGENTS.md

@@ -9,7 +9,7 @@ This project uses [Cruze](https://github.com/PrintPractical/cruze) for spec-driv
 ## Commands
 
 <!-- cruze:managed -->
-No build or test commands yet. `cruze land` fills this in when the walking-skeleton change lands.
+No build or test commands yet. `cruze land` fills this in when the foundation change lands.
 <!-- /cruze:managed -->
 
 ## Layout

package/templates/init/ci.yml

@@ -13,7 +13,7 @@ jobs:
       - uses: actions/setup-node@v5
         with:
           node-version: 22
-      # The walking-skeleton change adds the language's format, lint, build and
+      # The foundation change adds the language's format, lint, build and
       # test steps here, from `commands:` in .cruze/config.yaml.
       - name: Documents match the Cruze formats
         run: npx --yes --package={{cruze_package}} cruze validate

package/templates/init/config.yaml

@@ -27,7 +27,7 @@ check:
 layers: []
 
 # The project's commands, by name, such as `test: cargo test`. The
-# walking-skeleton change fills them in; `cruze land` copies them into AGENTS.md.
+# foundation change fills them in; `cruze land` copies them into AGENTS.md.
 commands: {}
 
 {{review_setting}}