docs: rename the five legs to Shape/Build/Watch/Check/Learn

CONTRIBUTING.md

@@ -74,7 +74,8 @@ anything (a command, a config key, a doc heading, a term in help text):
    this rule was born from).
 
 Precedent renames: edge -> profile, surface/spoke/sources -> app,
-hub -> board (2026-07-16, sync module).
+hub -> board (2026-07-16, sync module), leg -> stage / Specify-Execute-Observe-Govern -> Shape-Build-Watch-Check
+(2026-07-18, ADR-0034 amendment; Learn kept).
 
 ## Source
 

README.md

@@ -53,33 +53,33 @@ An open loop (the agent roams free and judges its own output) is a fast slop mac
 | loops until the budget dies | bounded: fix-agent retries max 2, then escalates to a human |
 | one loop size fits all | risk lanes: tiny work skips the ceremony entirely |
 
-## The five legs
+## The five stages
 
-The lifecycle above is what one run looks like. Across runs, the kit is organized as five legs (ADR-0034): **Specify** shapes work into contracts, **Execute** builds inside them, **Observe** records what happened, **Govern** gates every boundary, and **Learn** distills the record into proposals for the next cycle.
+The lifecycle above is what one run looks like. Across runs, the kit is organized as five stages (formerly called "legs", ADR-0034): **Shape** turns work into contracts, **Build** builds inside them, **Watch** records what happened, **Check** gates every boundary, and **Learn** distills the record into proposals for the next cycle.
 
 ```mermaid
 flowchart LR
-  SP([Specify]) --> EX([Execute]) --> OB([Observe]) --> LN([Learn])
-  LN -->|cited proposals,<br/>human promotes| SP
-  GV([Govern]) -. gates every<br/>phase boundary .- EX
+  SH([Shape]) --> BD([Build]) --> WA([Watch]) --> LN([Learn])
+  LN -->|cited proposals,<br/>human promotes| SH
+  CH([Check]) -. gates every<br/>phase boundary .- BD
 ```
 
-This diagram is the legs. For how DATA actually moves through them (telemetry -> proposal -> board -> ship, the ledger write/read paths, and the module map of who calls whom), see [`docs/data-flow.md`](docs/data-flow.md).
+This diagram is the stages. For how DATA actually moves through them (telemetry -> proposal -> board -> ship, the ledger write/read paths, and the module map of who calls whom), see [`docs/data-flow.md`](docs/data-flow.md).
 
-Legs are metadata, not directories: each module keeps its name and install unit, and declares a primary leg. The authoritative assignment (machine copy in [`lib/config/module-registry.md`](lib/config/module-registry.md), rendered by `config list`):
+Stages are metadata, not directories: each module keeps its name and install unit, and declares a primary stage. The authoritative assignment (machine copy in [`lib/config/module-registry.md`](lib/config/module-registry.md), rendered by `config list`):
 
-| Leg | Modules / subsystems |
+| Stage | Modules / subsystems |
 |---|---|
-| Specify | `spec`, `classify`, `goal`, `board` (input side), `sync` (spoke intake; outward mirror is its Observe side) |
-| Execute | `queue`, `mega`, `worktree`, `quiz_gate` |
-| Observe | `stats`, `session` (capture side), `telemetry`, `sync` (outward mirror side; absorbed the bridge cockpit mirror 2026-07-16) |
-| Govern | `gate`, `money_gate`, `advisor` |
+| Shape (Specify) | `spec`, `classify`, `goal`, `board` (input side), `sync` (spoke intake; outward mirror is its Watch side) |
+| Build (Execute) | `queue`, `mega`, `worktree`, `quiz_gate` |
+| Watch (Observe) | `stats`, `session` (capture side), `telemetry`, `sync` (outward mirror side; absorbed the bridge cockpit mirror 2026-07-16) |
+| Check (Govern) | `gate`, `money_gate`, `advisor` |
 | Learn | `learn`, `weekend_batch`, `session` (harvest), `board` (staging/promote), `skill-curator`, `prose_rag` (registry assignment, pending ADR-0034 amendment) |
-| (no leg) | `cosmetic` (statusline; orthogonal to the loop) |
+| (no stage) | `cosmetic` (statusline; orthogonal to the loop) |
 
-Two modules honestly span legs: **board** (Specify's intake on one side, Learn's staging/promote on the other) and **session** (Observe's capture, Learn's harvest).
+Two modules honestly span stages: **board** (Shape's intake on one side, Learn's staging/promote on the other) and **session** (Watch's capture, Learn's harvest).
 
-**What happens to a run's data after it ships:** every gate decision and run outcome appends to the ledgers (append-only, never rewritten). `stats` projects them read-only; `session intel` writes the weekly digest, harness scorecard included; `learn propose` distills cross-run evidence into cited proposals in a staging file; `learn drain` renders that staging for review; `board promote` is the human gate that turns a proposal into a backlog row feeding the next Specify. Every automated leg ends at a staging file or a rendered surface, never a direct write to a board or ledger: propose, never dispose.
+**What happens to a run's data after it ships:** every gate decision and run outcome appends to the ledgers (append-only, never rewritten). `stats` projects them read-only; `session intel` writes the weekly digest, harness scorecard included; `learn propose` distills cross-run evidence into cited proposals in a staging file; `learn drain` renders that staging for review; `board promote` is the human gate that turns a proposal into a backlog row feeding the next Shape stage. Every automated stage ends at a staging file or a rendered surface, never a direct write to a board or ledger: propose, never dispose.
 
 ## Install
 
@@ -155,7 +155,7 @@ That is the whole loop. The spec is the unit of handoff: a contractor running `/
 
 ```
 /kit:start          Detect state, suggest next command (entry point)
-/kit:onboard        Guided first-run: install mode, adopt, module picker, five-leg tour
+/kit:onboard        Guided first-run: install mode, adopt, module picker, five-stage tour
 /kit:think          Challenge the idea (5 min)
 /kit:design         Opt-in: shape the solution with you before /spec
 /kit:spec           Generate the spec + 4 parallel researchers (15-30 min)
@@ -274,7 +274,7 @@ Which hooks BLOCK vs warn vs neither is a declared contract: `docs/architecture.
 | /kit:review | Review | Paranoid single-pass code review |
 | /kit:review-team | Review | Parallel 3-lens review (security + architecture + test-coverage); findings confidence-gated, deduped by fingerprint, verdict-driving ones adversarially validated per finding |
 | /kit:test-plan-review-team | Verify | 5-lens adversarial critique of the spec's `## Test plan`, bounded revise loop, report-only |
-| /kit:onboard | Entry | Guided first-run: detect install mode (plugin/bash/both/none), offer /kit:adopt, pick modules, capture consumer knobs, disclose plugin-path gaps, five-leg tour; previews + confirms every write, decline = no-op |
+| /kit:onboard | Entry | Guided first-run: detect install mode (plugin/bash/both/none), offer /kit:adopt, pick modules, capture consumer knobs, disclose plugin-path gaps, five-stage tour; previews + confirms every write, decline = no-op |
 | /kit:adopt | Entry | Retrofit the operate-contract onto an existing repo (AGENTS.md, loader, proof marker, classifiers), idempotently |
 | /kit:docs | Docs | Cross-reference diff against all doc files, fix drift |
 | /kit:explain | Understand | Literate-diff explainer (background -> intuition -> prose-ordered diff -> diagram); composes narrate-log + svg-knowledge-diagram, grounded in the diff not the agent's narrative (ADR-0031) |

commands/onboard.md

@@ -170,17 +170,17 @@ nothing.
 
 ## G. The welcome tour: the loop in five sentences
 
-Close with the five-leg loop, one sentence per leg, then the next step. Keep it to five sentences:
+Close with the five-stage loop, one sentence per stage, then the next step. Keep it to five sentences:
 
-1. **Specify** -- you turn an intent into a spec (`/kit:spec`) and a lane, so the work has a written,
+1. **Shape** -- you turn an intent into a spec (`/kit:spec`) and a lane, so the work has a written,
    testable contract before any code.
-2. **Execute** -- the build runs against that spec (`/kit:execute`), worker then verifier then a
+2. **Build** -- the build runs against that spec (`/kit:execute`), worker then verifier then a
    bounded fix retry, the smallest verifiable increment at a time.
-3. **Observe** -- every run leaves an append-only trail that `stats` projects on demand, so you can
+3. **Watch** -- every run leaves an append-only trail that `stats` projects on demand, so you can
    see what actually happened without a second source of truth.
-4. **Govern** -- the ship-gate blocks a push whose lane skipped a required gate or a stateful change
+4. **Check** -- the ship-gate blocks a push whose lane skipped a required gate or a stateful change
    with no recorded proof, so "done" means proven, not claimed.
-5. **Learn** -- retros and the Learn leg distill each run's lessons back into the backlog, closing the
+5. **Learn** -- retros and the Learn stage distill each run's lessons back into the backlog, closing the
    loop so the next cycle starts smarter.
 
 Then: **"Next: run `/kit:start` -- it detects where this repo stands and hands you the single right

docs/CHANGELOG.md

@@ -43,7 +43,8 @@ All notable changes to dwarves-kit are documented here.
   nature). Tests: `tests/test-sync-cron-install.sh` +
   `tests/test-sync-cron-launcher.sh`.
 - **`sync` module: two-way board↔apps sync (SPEC-001/SPEC-002 P1).** The ops-toolkit
-  backlog-sync engine graduates into the kit as registered module `sync` (leg Specify)
+  backlog-sync engine graduates into the kit as registered module `sync` (stage: Shape,
+  formerly leg Specify -- renamed by ID-292, see below)
   at `lib/sync/`: `board sync` mirrors an adopted repo's BACKLOG.md to Apple Reminders /
   Notion / Hermes kanban / Multica with per-app three-way merge (board wins; app
   deletions tombstone; inbox intake with `#inbox` quarantine). Config on the ADR-0034
@@ -57,8 +58,15 @@ All notable changes to dwarves-kit are documented here.
   paths). Proof: `lib/sync/docs/proof-of-done.md`.
 - **Plain words rule (CONTRIBUTING.md) + ranked jargon inventory**
   (`docs/research/2026-07-16-plain-words-inventory.md`); rename backlog: ID-291 (cheap
-  cluster), ID-292 (legs → Shape/Build/Watch/Check/Learn, needs an ADR-0034
-  amendment), ID-293 (big cluster, parked).
+  cluster), ID-292 (shipped below), ID-293 (big cluster, parked).
+- **The five legs renamed to Shape/Build/Watch/Check/Learn (ID-292).** `Specify`,
+  `Execute`, `Observe`, `Govern` become `Shape`, `Build`, `Watch`, `Check` (`Learn`
+  kept); the container word `leg` becomes `stage`. ADR-0034 amended per its own lock
+  (decision 3's as-decided table left unrewritten); `lib/config/module-registry.md`
+  carries the old names as a one-release parenthetical alias, README/architecture/
+  data-flow/MANUAL/kit-contract/onboard docs and the registry-lint assertions in
+  `tests/test-meta.sh` swept to the new vocabulary. Docs-first: no module or
+  code-identifier renames.
 - **Model-routing enforcement pinned + proven (SPEC-116).** Resolves `orchestrate-hardening`
   open-fork 3: the enforcement site is `lib/queue/orchestrate.sh` (`_route()` + the serial/wave delegate
   dispatch sites, which already existed under SPEC-087), not `lib/classify/route-suggest.sh` (a decompose-time

docs/MANUAL.md

@@ -28,15 +28,15 @@ For the full playbook (every scenario, the autonomy dial, the freeform front doo
 
 ## Command reference (the kit invokes these from your intent; you rarely type them)
 
-Index by loop leg (ADR-0034; the README's "The five legs" section tells the full story). Front-door and meta commands sit outside the legs on purpose:
+Index by loop stage (formerly "leg", ADR-0034; the README's "The five stages" section tells the full story). Front-door and meta commands sit outside the stages on purpose:
 
-| Leg | Commands |
+| Stage | Commands |
 |---|---|
 | (front door) | `/kit:start`, `/kit:onboard`, `/kit:adopt` |
-| Specify | `/kit:grill`, `/kit:think`, `/kit:design`, `/kit:devs-team`, `/kit:visual-team`, `/kit:ui-design`, `/kit:assign`, `/kit:spec`, `/kit:spec-validate`, `/kit:test-plan` |
-| Execute | `/kit:execute`, `/kit:next`, `/kit:dispatch`, `/kit:mega`, `/kit:debug` |
-| Observe | `/kit:explain`, `/kit:pitch` (render the record outward; the read plane itself is the `stats` skill + `session` CLI, not a command) |
-| Govern | `/kit:review`, `/kit:review-team`, `/kit:test-plan-review-team`, `/kit:verify`, `/kit:quiz-gate`, `/kit:ship` |
+| Shape | `/kit:grill`, `/kit:think`, `/kit:design`, `/kit:devs-team`, `/kit:visual-team`, `/kit:ui-design`, `/kit:assign`, `/kit:spec`, `/kit:spec-validate`, `/kit:test-plan` |
+| Build | `/kit:execute`, `/kit:next`, `/kit:dispatch`, `/kit:mega`, `/kit:debug` |
+| Watch | `/kit:explain`, `/kit:pitch` (render the record outward; the read plane itself is the `stats` skill + `session` CLI, not a command) |
+| Check | `/kit:review`, `/kit:review-team`, `/kit:test-plan-review-team`, `/kit:verify`, `/kit:quiz-gate`, `/kit:ship` |
 | Learn | `/kit:retro`, `/kit:docs`, `/kit:absorb` |
 | (meta) | `/kit:kit-health`, `/kit:draft-agent` |
 
@@ -60,7 +60,7 @@ Index by loop leg (ADR-0034; the README's "The five legs" section tells the full
 **Reads:** install mode via `lib/onboard-detect.sh` (plugin / bash / both / none); adoption state via `lib/adopt.sh --check`; the module roster + consumer knobs via `bin/config list|explain` (the SPEC-198 registry, never a hardcoded list)
 **Writes:** nothing of its own -- it only ever drives `lib/adopt.sh` (to inject the contract and/or seed `<repo>/.kit.toml` with your module choices), and every such write is previewed (`--dry-run` or a shown plan) and confirmed first; a decline is a strict no-op
 **When to invoke:** the first ten minutes on a new machine or a repo you have not adopted yet. It ties together the four things that have to line up before the loop works: which install mode is live, whether this repo is adopted, which modules are on, and which env knobs make them non-inert.
-**What it does, in order:** (A) detect the install mode and explain it in one line each -- for `both` it discloses the double-hooks hazard and points at the one-path fix but never mutates settings; for `none` it prints the two install paths and stops. (B) offer `/kit:adopt` for the current repo (preview then confirm; an already-adopted repo is reported healthy and nothing is written). (C) pick modules -- the list is generated from the registry, and the choice is written by driving `lib/adopt.sh --with` (this is how the plugin path, which has no `install.sh --with`, still gets per-repo module selection). (D) for the chosen modules only, surface the consumer knobs that make them non-inert -- a `.kit.toml`-keyed knob is offered as a previewed write, an env-only knob (e.g. `PROSE_RAG_INJECT`, `MONEY_GATE_REPOS`) yields printed `export` guidance. (E) on the plugin path, disclose the gaps honestly (no statusLine HUD, a frozen SHA vs `git pull`, the `KIT_FORCE_FULL` escape and its hazard). (F) on the bash path, INSTALL-STAMP staleness is ONE printed line + a `/kit:kit-health` pointer, never an upgrade flow. (G) end with the five-leg loop in five sentences + `/kit:start` as the next step.
+**What it does, in order:** (A) detect the install mode and explain it in one line each -- for `both` it discloses the double-hooks hazard and points at the one-path fix but never mutates settings; for `none` it prints the two install paths and stops. (B) offer `/kit:adopt` for the current repo (preview then confirm; an already-adopted repo is reported healthy and nothing is written). (C) pick modules -- the list is generated from the registry, and the choice is written by driving `lib/adopt.sh --with` (this is how the plugin path, which has no `install.sh --with`, still gets per-repo module selection). (D) for the chosen modules only, surface the consumer knobs that make them non-inert -- a `.kit.toml`-keyed knob is offered as a previewed write, an env-only knob (e.g. `PROSE_RAG_INJECT`, `MONEY_GATE_REPOS`) yields printed `export` guidance. (E) on the plugin path, disclose the gaps honestly (no statusLine HUD, a frozen SHA vs `git pull`, the `KIT_FORCE_FULL` escape and its hazard). (F) on the bash path, INSTALL-STAMP staleness is ONE printed line + a `/kit:kit-health` pointer, never an upgrade flow. (G) end with the five-stage loop in five sentences + `/kit:start` as the next step.
 **Fence (ADR-0034 decision 4):** onboard ORCHESTRATES; it calls start + adopt + config and reimplements none of them. It never changes `install.sh`, `adopt.sh`, or `bin/config`.
 **Common gotcha:** it is not an upgrade wizard. If the kit is already installed and this repo is already adopted, onboard is a read-only health tour that writes nothing; to change modules later you hand-edit `<repo>/.kit.toml [modules]` and re-run `/kit:adopt --refresh`.
 

docs/architecture.md

@@ -1,6 +1,6 @@
 # Architecture
 
-How dwarves-kit fits together. Read PHILOSOPHY.md first for the WHY; this file is the WHAT and HOW. The harness-level loop story (the five legs: Specify → Execute → Observe → Govern → Learn, and which module serves which) lives in the README's "The five legs" section, backed by ADR-0034 and the machine registry `lib/config/module-registry.md`; this file does not restate it.
+How dwarves-kit fits together. Read PHILOSOPHY.md first for the WHY; this file is the WHAT and HOW. The harness-level loop story (the five stages, formerly "legs": Shape → Build → Watch → Check → Learn, and which module serves which) lives in the README's "The five stages" section, backed by ADR-0034 and the machine registry `lib/config/module-registry.md`; this file does not restate it.
 
 ## Component layout
 
@@ -143,7 +143,7 @@ Total: 31 commands + 25 agents = **56 entries** (10 build · 3 code · 9 test ·
 |---|---|---|---|---|
 | `/kit:retro` | command | Reflect | cross-phase | Post-ship narrative mirror of the entire V; captures learnings, not a gate |
 | `/kit:start` | command | Session entry | cross-phase | Detects project state and recommends the right next command; never executes |
-| `/kit:onboard` | command | First-run onboarding | cross-phase | Interactive first-run orchestrator (SPEC-199): detects install mode via `lib/onboard-detect.sh`, offers `/kit:adopt`, picks modules (bridging the plugin path's missing `--with`), captures consumer knobs from the SPEC-198 registry, discloses plugin-path gaps, ends with the five-leg tour; CALLS start/adopt/config, reimplements none (ADR-0034 fence); previews + confirms every write |
+| `/kit:onboard` | command | First-run onboarding | cross-phase | Interactive first-run orchestrator (SPEC-199): detects install mode via `lib/onboard-detect.sh`, offers `/kit:adopt`, picks modules (bridging the plugin path's missing `--with`), captures consumer knobs from the SPEC-198 registry, discloses plugin-path gaps, ends with the five-stage tour; CALLS start/adopt/config, reimplements none (ADR-0034 fence); previews + confirms every write |
 | `/kit:adopt` | command | Repo onboarding | cross-phase | Injects the operate-contract + proof marker + a CLAUDE.md pointer into a target repo (idempotent, via `lib/adopt.sh`); wires the classifiers so the ship-gate engages there |
 | `/kit:kit-health` | command | Maintainer audit | cross-phase | Self-assessment against PHILOSOPHY.md; run before tagging; not part of the normal cycle |
 | `/kit:absorb` | command | Upstream maintenance | cross-phase | Audits Credits drift + seed-rescan; proposal-only; maintainer-only connective tissue |