cclaw-cli 0.23.0 → 0.23.1

package/dist/cli.js

@@ -54,12 +54,12 @@ Commands:
              Flags: --name=<feature>    Feature slug (default: inferred from 00-idea.md).
                     --skip-retro       Bypass mandatory retro gate (requires --retro-reason).
                     --retro-reason=<t> Reason for bypassing retro gate.
-  eval       Run cclaw evals against .cclaw/evals/corpus (Phase 7, Wave 7.1: structural verifier).
+  eval       Run cclaw evals against .cclaw/evals/corpus (Phase 7: structural verifier + baselines).
              Flags: --stage=<id>         Limit to one flow stage (${FLOW_STAGES.join("|")}).
                     --tier=<A|B|C>       Fidelity tier (A=single-shot, B=tools, C=workflow).
-                    --schema-only        Run only structural verifiers (Wave 7.1, default).
-                    --rules              Run structural + rule verifiers (Wave 7.2).
-                    --judge              Include LLM judging (Wave 7.3; requires API key).
+                    --schema-only        Run only structural verifiers (default).
+                    --rules              Run structural + rule verifiers (not wired yet).
+                    --judge              Include LLM judging (not wired yet; requires API key).
                     --dry-run            Validate config + corpus, print summary, do not execute.
                     --json               Emit machine-readable JSON on stdout.
                     --no-write           Skip writing the report to .cclaw/evals/reports/.

package/dist/constants.d.ts

@@ -5,10 +5,10 @@ export declare const CCLAW_VERSION = "0.1.1";
 export declare const FLOW_VERSION = "1.0.0";
 export declare const DEFAULT_HARNESSES: HarnessId[];
 /**
- * Evals subtree. Wave 7.0 scaffolds the directory layout and a default config.yaml;
- * verifiers and LLM wiring arrive in Waves 7.1–7.5. Keeping this separate from the
- * main REQUIRED_DIRS list makes it explicit that the evals runtime is additive and
- * does not affect non-eval cclaw behavior.
+ * Evals subtree. Scaffolds the directory layout and a default config.yaml; the
+ * structural verifier, rule verifiers, and LLM wiring layer on incrementally.
+ * Keeping this separate from the main REQUIRED_DIRS list makes it explicit that
+ * the evals runtime is additive and does not affect non-eval cclaw behavior.
  */
 export declare const EVALS_ROOT = ".cclaw/evals";
 export declare const EVALS_CONFIG_PATH = ".cclaw/evals/config.yaml";

package/dist/constants.js

@@ -9,10 +9,10 @@ export const DEFAULT_HARNESSES = [
     "codex"
 ];
 /**
- * Evals subtree. Wave 7.0 scaffolds the directory layout and a default config.yaml;
- * verifiers and LLM wiring arrive in Waves 7.1–7.5. Keeping this separate from the
- * main REQUIRED_DIRS list makes it explicit that the evals runtime is additive and
- * does not affect non-eval cclaw behavior.
+ * Evals subtree. Scaffolds the directory layout and a default config.yaml; the
+ * structural verifier, rule verifiers, and LLM wiring layer on incrementally.
+ * Keeping this separate from the main REQUIRED_DIRS list makes it explicit that
+ * the evals runtime is additive and does not affect non-eval cclaw behavior.
  */
 export const EVALS_ROOT = `${RUNTIME_ROOT}/evals`;
 export const EVALS_CONFIG_PATH = `${EVALS_ROOT}/config.yaml`;

package/dist/content/eval-scaffold.d.ts

@@ -4,8 +4,8 @@
  * scaffold is intentionally minimal: a usable default config plus short
  * READMEs that point at `docs/evals.md` for authoring guidance.
  */
-export declare const EVAL_CONFIG_YAML = "# cclaw eval config\n# See docs/evals.md for the full schema and Wave 7.1\u20137.6 rollout plan.\n#\n# All values can be overridden at runtime with CCLAW_EVAL_* environment\n# variables (env wins). Secrets like CCLAW_EVAL_API_KEY never live here.\nprovider: zai\nbaseUrl: https://api.z.ai/api/coding/paas/v4\nmodel: glm-5.1\n\n# Default fidelity tier when --tier is not supplied.\n#   A = single-shot API call (cheap, Wave 7.3)\n#   B = SDK with tool use     (realistic, Wave 7.4)\n#   C = multi-stage workflow  (end-to-end, Wave 7.5)\ndefaultTier: A\n\n# Per-call timeout and retry budget.\ntimeoutMs: 120000\nmaxRetries: 2\n\n# Optional hard-stop on estimated USD spend per day. Leave unset for no cap.\n# dailyUsdCap: 5\n\n# Regression thresholds used by CI (Wave 7.3+).\nregression:\n  # Fail when overall score drops by more than this fraction (e.g. -0.15 = 15%).\n  failIfDeltaBelow: -0.15\n  # Fail when any single critical rubric drops below this absolute score.\n  failIfCriticalBelow: 3.0\n";
-export declare const EVAL_CORPUS_README = "# Eval Corpus\n\nSeed cases live in `./<stage>/<id>.yaml`, one file per case.\nSee `docs/evals.md` for the schema; authoring begins in Wave 7.1.\n\nMinimal shape:\n\n```yaml\nid: brainstorm-01\nstage: brainstorm\ninput_prompt: |\n  One short paragraph describing the user's task.\ncontext_files: []\nexpected:\n  # verifier-specific hints; optional in Wave 7.0\n```\n\nWave 7.1 will add 3 cases per stage (24 total). Wave 7.2 will expand to 5 per\nstage (40 total). Wave 7.4/7.5 may add `context_files` pulled from real\nprojects to exercise Tier B/C sandboxes.\n";
-export declare const EVAL_RUBRICS_README = "# Eval Rubrics\n\nLLM-judge rubrics land in Wave 7.3. Each rubric is a short list of checks\nscored on a `1\u20135` scale with a rationale:\n\n```yaml\nstage: brainstorm\nchecks:\n  - id: distinctness\n    prompt: \"Are the proposed directions genuinely distinct (not rephrasings)?\"\n    scale: \"1-5 where 5=fully distinct approaches\"\n    weight: 1.0\n```\n\nRubric authoring happens when Tier A runs start producing artifacts, so we\nscore the *right* properties rather than retrofitting generic quality checks.\nSee `docs/evals.md` for the full schema.\n";
-export declare const EVAL_BASELINES_README = "# Eval Baselines\n\nFrozen score snapshots used by regression gates. Baselines are committed to\ngit and updated explicitly via `cclaw eval --update-baseline --confirm`\n(wired in Wave 7.1).\n\nEach baseline file is a JSON document keyed by stage and case id. Do not edit\nby hand; CI will flag baseline churn.\n";
+export declare const EVAL_CONFIG_YAML = "# cclaw eval config\n# See docs/evals.md for the full schema and rollout plan.\n#\n# All values can be overridden at runtime with CCLAW_EVAL_* environment\n# variables (env wins). Secrets like CCLAW_EVAL_API_KEY never live here.\nprovider: zai\nbaseUrl: https://api.z.ai/api/coding/paas/v4\nmodel: glm-5.1\n\n# Default fidelity tier when --tier is not supplied.\n#   A = single-shot API call (cheap)\n#   B = SDK with tool use     (realistic)\n#   C = multi-stage workflow  (end-to-end)\ndefaultTier: A\n\n# Per-call timeout and retry budget.\ntimeoutMs: 120000\nmaxRetries: 2\n\n# Optional hard-stop on estimated USD spend per day. Leave unset for no cap.\n# dailyUsdCap: 5\n\n# Regression thresholds used by CI.\nregression:\n  # Fail when overall score drops by more than this fraction (e.g. -0.15 = 15%).\n  failIfDeltaBelow: -0.15\n  # Fail when any single critical rubric drops below this absolute score.\n  failIfCriticalBelow: 3.0\n";
+export declare const EVAL_CORPUS_README = "# Eval Corpus\n\nSeed cases live in `./<stage>/<id>.yaml`, one file per case.\nSee `docs/evals.md` for the schema.\n\nMinimal shape:\n\n```yaml\nid: brainstorm-01\nstage: brainstorm\ninput_prompt: |\n  One short paragraph describing the user's task.\ncontext_files: []\nexpected:\n  # verifier-specific hints; optional\n```\n\nStart with 3 structural cases per stage (24 total), then expand to 5 per\nstage (40 total) once rule verifiers land. Tier B/C runs may add\n`context_files` pulled from real projects to exercise the sandbox.\n";
+export declare const EVAL_RUBRICS_README = "# Eval Rubrics\n\nLLM-judge rubrics. Each rubric is a short list of checks scored on a\n`1\u20135` scale with a rationale:\n\n```yaml\nstage: brainstorm\nchecks:\n  - id: distinctness\n    prompt: \"Are the proposed directions genuinely distinct (not rephrasings)?\"\n    scale: \"1-5 where 5=fully distinct approaches\"\n    weight: 1.0\n```\n\nRubric authoring happens when Tier A runs start producing artifacts, so we\nscore the *right* properties rather than retrofitting generic quality checks.\nSee `docs/evals.md` for the full schema.\n";
+export declare const EVAL_BASELINES_README = "# Eval Baselines\n\nFrozen score snapshots used by regression gates. Baselines are committed to\ngit and updated explicitly via `cclaw eval --update-baseline --confirm`.\n\nEach baseline file is a JSON document keyed by stage and case id. Do not edit\nby hand; CI will flag baseline churn.\n";
 export declare const EVAL_REPORTS_README = "# Eval Reports\n\nGenerated reports (JSON + Markdown) land here. This directory is gitignored.\nRun `cclaw eval --dry-run` to preview configuration without producing a\nreport.\n";

package/dist/content/eval-scaffold.js

@@ -5,7 +5,7 @@
  * READMEs that point at `docs/evals.md` for authoring guidance.
  */
 export const EVAL_CONFIG_YAML = `# cclaw eval config
-# See docs/evals.md for the full schema and Wave 7.1–7.6 rollout plan.
+# See docs/evals.md for the full schema and rollout plan.
 #
 # All values can be overridden at runtime with CCLAW_EVAL_* environment
 # variables (env wins). Secrets like CCLAW_EVAL_API_KEY never live here.
@@ -14,9 +14,9 @@ baseUrl: https://api.z.ai/api/coding/paas/v4
 model: glm-5.1
 
 # Default fidelity tier when --tier is not supplied.
-#   A = single-shot API call (cheap, Wave 7.3)
-#   B = SDK with tool use     (realistic, Wave 7.4)
-#   C = multi-stage workflow  (end-to-end, Wave 7.5)
+#   A = single-shot API call (cheap)
+#   B = SDK with tool use     (realistic)
+#   C = multi-stage workflow  (end-to-end)
 defaultTier: A
 
 # Per-call timeout and retry budget.
@@ -26,7 +26,7 @@ maxRetries: 2
 # Optional hard-stop on estimated USD spend per day. Leave unset for no cap.
 # dailyUsdCap: 5
 
-# Regression thresholds used by CI (Wave 7.3+).
+# Regression thresholds used by CI.
 regression:
   # Fail when overall score drops by more than this fraction (e.g. -0.15 = 15%).
   failIfDeltaBelow: -0.15
@@ -36,7 +36,7 @@ regression:
 export const EVAL_CORPUS_README = `# Eval Corpus
 
 Seed cases live in \`./<stage>/<id>.yaml\`, one file per case.
-See \`docs/evals.md\` for the schema; authoring begins in Wave 7.1.
+See \`docs/evals.md\` for the schema.
 
 Minimal shape:
 
@@ -47,17 +47,17 @@ input_prompt: |
   One short paragraph describing the user's task.
 context_files: []
 expected:
-  # verifier-specific hints; optional in Wave 7.0
+  # verifier-specific hints; optional
 \`\`\`
 
-Wave 7.1 will add 3 cases per stage (24 total). Wave 7.2 will expand to 5 per
-stage (40 total). Wave 7.4/7.5 may add \`context_files\` pulled from real
-projects to exercise Tier B/C sandboxes.
+Start with 3 structural cases per stage (24 total), then expand to 5 per
+stage (40 total) once rule verifiers land. Tier B/C runs may add
+\`context_files\` pulled from real projects to exercise the sandbox.
 `;
 export const EVAL_RUBRICS_README = `# Eval Rubrics
 
-LLM-judge rubrics land in Wave 7.3. Each rubric is a short list of checks
-scored on a \`1–5\` scale with a rationale:
+LLM-judge rubrics. Each rubric is a short list of checks scored on a
+\`1–5\` scale with a rationale:
 
 \`\`\`yaml
 stage: brainstorm
@@ -75,8 +75,7 @@ See \`docs/evals.md\` for the full schema.
 export const EVAL_BASELINES_README = `# Eval Baselines
 
 Frozen score snapshots used by regression gates. Baselines are committed to
-git and updated explicitly via \`cclaw eval --update-baseline --confirm\`
-(wired in Wave 7.1).
+git and updated explicitly via \`cclaw eval --update-baseline --confirm\`.
 
 Each baseline file is a JSON document keyed by stage and case id. Do not edit
 by hand; CI will flag baseline churn.

package/dist/content/examples.js

@@ -277,23 +277,23 @@ T-1 ──▶ T-2 ──▶ T-3
 
 Parallel opportunity: T-1 is a prerequisite for both T-2 and T-3 (T-3 also needs T-2).
 
-## Dependency Waves
+## Dependency Batches
 
-#### Wave 1 (foundation)
+#### Batch 1 (foundation)
 - Task IDs: T-1
 - Verification gate: schema tests pass, dedupe key fixtures validated
 
-#### Wave 2 (core logic)
+#### Batch 2 (core logic)
 - Task IDs: T-2
-- Depends on: Wave 1 (T-1 complete)
+- Depends on: Batch 1 (T-1 complete)
 - Verification gate: integration test proves publish-to-outbox path
 
-#### Wave 3 (integration)
+#### Batch 3 (integration)
 - Task IDs: T-3
-- Depends on: Wave 2 (T-2 complete)
+- Depends on: Batch 2 (T-2 complete)
 - Verification gate: e2e tests pass for delivery, dedupe, and degraded mode
 
-Execution rule: complete and verify each wave before starting the next wave.
+Execution rule: complete and verify each batch before starting the next batch.
 
 ## Task List
 
@@ -313,10 +313,10 @@ Execution rule: complete and verify each wave before starting the next wave.
 
 ## Risk Assessment
 
-| Task/Wave | Risk | Likelihood | Impact | Mitigation |
+| Task/Batch | Risk | Likelihood | Impact | Mitigation |
 | --- | --- | --- | --- | --- |
-| T-3 (Wave 3) | SSE reconnect logic complex | Medium | High | Spike reconnect in isolation before integrating with feed UI |
-| Wave 2 → 3 | Publisher API contract may shift | Low | Medium | Pin contract in T-1 schema; T-2 integration test validates |
+| T-3 (Batch 3) | SSE reconnect logic complex | Medium | High | Spike reconnect in isolation before integrating with feed UI |
+| Batch 2 → 3 | Publisher API contract may shift | Low | Medium | Pin contract in T-1 schema; T-2 integration test validates |
 
 ## WAIT_FOR_CONFIRM
 - Status: pending
@@ -682,7 +682,7 @@ const STAGE_EXAMPLE_SECTION_HEADINGS = {
         "Approval block"
     ],
     plan: [
-        "Dependency graph + dependency waves",
+        "Dependency graph + dependency batches",
         "Task list with effort + minutes estimate per task",
         "Acceptance mapping (every AC → task IDs)",
         "No-Placeholder scan row + WAIT_FOR_CONFIRM marker"

package/dist/content/hooks.js

@@ -296,7 +296,7 @@ if [ "$SUGGESTIONS_ENABLED" = "true" ] && [ "$STAGE_MUTED" != "true" ]; then
     scope) STAGE_SUGGESTION="Suggestion: lock explicit in-scope/out-of-scope boundaries and choose one scope mode." ;;
     design) STAGE_SUGGESTION="Suggestion: map failure modes per new codepath and confirm architecture boundaries before moving forward." ;;
     spec) STAGE_SUGGESTION="Suggestion: ensure every acceptance criterion is measurable and mapped to a concrete test." ;;
-    plan) STAGE_SUGGESTION="Suggestion: group tasks into dependency waves and keep WAIT_FOR_CONFIRM pending until approval." ;;
+    plan) STAGE_SUGGESTION="Suggestion: group tasks into dependency batches and keep WAIT_FOR_CONFIRM pending until approval." ;;
     tdd) STAGE_SUGGESTION="Suggestion: execute RED → GREEN → REFACTOR for each selected slice and capture evidence per cycle." ;;
     review) STAGE_SUGGESTION="Suggestion: run Layer 1 before Layer 2 and reconcile findings into 07-review-army.json." ;;
     ship) STAGE_SUGGESTION="Suggestion: verify preflight + rollback plan before selecting exactly one finalization mode." ;;

package/dist/content/skills.d.ts

@@ -1,8 +1,8 @@
 import type { FlowStage } from "../types.js";
 /**
- * Long-form Wave Execution walkthrough. Rendered once into
- * \`.cclaw/references/stages/tdd-wave-walkthrough.md\` by the installer.
+ * Long-form Batch Execution walkthrough. Rendered once into
+ * \`.cclaw/references/stages/tdd-batch-walkthrough.md\` by the installer.
  */
-export declare const TDD_WAVE_WALKTHROUGH_MARKDOWN = "# TDD \u2014 Wave Execution Walkthrough\n\nDetailed RED / GREEN / REFACTOR transcript for a 3-task wave. Illustrative\nonly \u2014 do not copy the command names blindly, match them to your stack.\n\n## Wave 1 example tasks\n\n| Task ID | Description | AC | Verification |\n|---|---|---|---|\n| T-1 `[~3m]` | Add `User.emailNormalized` column | AC-1 | `npm test -- users/schema` |\n| T-2 `[~4m]` | Normalize on write in `UserRepo.save` | AC-1 | `npm test -- users/repo` |\n| T-3 `[~3m]` | Reject duplicates in `UserService.signup` | AC-2 | `npm test -- users/service` |\n\n## Execution transcript\n\n### T-1 \u2014 RED\n\n> Run: `npm test -- users/schema` \u2192 **FAIL** (missing column: `emailNormalized`). Captured the failure stack as RED evidence. No production code touched yet.\n\n### T-1 \u2014 GREEN\n\n> Added the column in the schema module. Re-ran `npm test -- users/schema` \u2192 **PASS**. Ran the full suite `npm test` \u2192 **PASS**. Captured both outputs as GREEN evidence.\n\n### T-1 \u2014 REFACTOR\n\n> Extracted the column definition into a shared `NormalizedEmail` type used by T-2/T-3. Re-ran `npm test` \u2192 **PASS**. Captured REFACTOR note: \"Extracted NormalizedEmail type to keep T-2/T-3 DRY; zero behavior change, all tests still green.\"\n\n### T-2 \u2014 RED / GREEN / REFACTOR\n\nWrite the repo test that expects normalised writes, watch it fail (RED), implement normalisation inside `UserRepo.save` only (GREEN), then refactor the normaliser out of the repo into a helper shared with T-3 (REFACTOR).\n\n### T-3 \u2014 RED / GREEN / REFACTOR\n\nWrite the service-level duplicate test that expects a rejection, watch it fail (RED), add the duplicate check in `UserService.signup` (GREEN), refactor the error message into a named constant (REFACTOR).\n\n## Wave gate check\n\nAfter T-3 REFACTOR, before declaring Wave 1 done:\n\n1. Run the full suite (`npm test`) one final time \u2192 **PASS** captured as wave-exit evidence.\n2. Verify the TDD artifact contains RED, GREEN, and REFACTOR evidence for T-1, T-2, **and** T-3. No partial waves.\n3. Only now mark Wave 1 complete. Wave 2 cannot start until this step.\n\n## When to stop mid-wave (do NOT push through)\n\n- A RED test fails for a reason you did not predict (e.g. an unrelated flaky test) \u2192 **pause**, diagnose, log an operational-self-improvement entry, and decide with the user before proceeding.\n- A GREEN step would require touching code outside the task's acceptance criterion \u2192 **pause**, the task is scoped wrong; adjust the plan or open a follow-up task.\n- The same RED failure reappears after a GREEN change \u2192 **escalate** per the 3-attempts rule; do not keep patching.\n";
+export declare const TDD_BATCH_WALKTHROUGH_MARKDOWN = "# TDD \u2014 Batch Execution Walkthrough\n\nDetailed RED / GREEN / REFACTOR transcript for a 3-task batch. Illustrative\nonly \u2014 do not copy the command names blindly, match them to your stack.\n\n## Batch 1 example tasks\n\n| Task ID | Description | AC | Verification |\n|---|---|---|---|\n| T-1 `[~3m]` | Add `User.emailNormalized` column | AC-1 | `npm test -- users/schema` |\n| T-2 `[~4m]` | Normalize on write in `UserRepo.save` | AC-1 | `npm test -- users/repo` |\n| T-3 `[~3m]` | Reject duplicates in `UserService.signup` | AC-2 | `npm test -- users/service` |\n\n## Execution transcript\n\n### T-1 \u2014 RED\n\n> Run: `npm test -- users/schema` \u2192 **FAIL** (missing column: `emailNormalized`). Captured the failure stack as RED evidence. No production code touched yet.\n\n### T-1 \u2014 GREEN\n\n> Added the column in the schema module. Re-ran `npm test -- users/schema` \u2192 **PASS**. Ran the full suite `npm test` \u2192 **PASS**. Captured both outputs as GREEN evidence.\n\n### T-1 \u2014 REFACTOR\n\n> Extracted the column definition into a shared `NormalizedEmail` type used by T-2/T-3. Re-ran `npm test` \u2192 **PASS**. Captured REFACTOR note: \"Extracted NormalizedEmail type to keep T-2/T-3 DRY; zero behavior change, all tests still green.\"\n\n### T-2 \u2014 RED / GREEN / REFACTOR\n\nWrite the repo test that expects normalised writes, watch it fail (RED), implement normalisation inside `UserRepo.save` only (GREEN), then refactor the normaliser out of the repo into a helper shared with T-3 (REFACTOR).\n\n### T-3 \u2014 RED / GREEN / REFACTOR\n\nWrite the service-level duplicate test that expects a rejection, watch it fail (RED), add the duplicate check in `UserService.signup` (GREEN), refactor the error message into a named constant (REFACTOR).\n\n## Batch gate check\n\nAfter T-3 REFACTOR, before declaring Batch 1 done:\n\n1. Run the full suite (`npm test`) one final time \u2192 **PASS** captured as batch-exit evidence.\n2. Verify the TDD artifact contains RED, GREEN, and REFACTOR evidence for T-1, T-2, **and** T-3. No partial batches.\n3. Only now mark Batch 1 complete. Batch 2 cannot start until this step.\n\n## When to stop mid-batch (do NOT push through)\n\n- A RED test fails for a reason you did not predict (e.g. an unrelated flaky test) \u2192 **pause**, diagnose, log an operational-self-improvement entry, and decide with the user before proceeding.\n- A GREEN step would require touching code outside the task's acceptance criterion \u2192 **pause**, the task is scoped wrong; adjust the plan or open a follow-up task.\n- The same RED failure reappears after a GREEN change \u2192 **escalate** per the 3-attempts rule; do not keep patching.\n";
 export declare function stageSkillFolder(stage: FlowStage): string;
 export declare function stageSkillMarkdown(stage: FlowStage): string;

package/dist/content/skills.js

@@ -103,19 +103,19 @@ Reference utility skill:
 \`.cclaw/skills/verification-before-completion/SKILL.md\`
 `;
 }
-function waveExecutionModeBlock(stage) {
+function batchExecutionModeBlock(stage) {
     const schema = stageSchema(stage);
-    if (!schema.waveExecutionAllowed)
+    if (!schema.batchExecutionAllowed)
         return "";
-    return `## Wave Execution Mode
+    return `## Batch Execution Mode
 
-Execute the current dependency wave task-by-task (RED -> GREEN -> REFACTOR).
+Execute the current dependency batch task-by-task (RED -> GREEN -> REFACTOR).
 Stop on BLOCKED status or when user input is required.
-Apply concise turn announces: one announce per wave boundary (or when risk/plan
+Apply concise turn announces: one announce per batch boundary (or when risk/plan
 changes materially), then execute tasks without repetitive boilerplate.
 
 Detailed walkthrough:
-\`.cclaw/${STAGE_EXAMPLES_REFERENCE_DIR}/tdd-wave-walkthrough.md\`
+\`.cclaw/${STAGE_EXAMPLES_REFERENCE_DIR}/tdd-batch-walkthrough.md\`
 `;
 }
 function crossStageTraceBlock(stage) {
@@ -190,7 +190,7 @@ function stageSpecificSeeAlso(stage) {
         ],
         tdd: [
             `- \`${RUNTIME_ROOT}/skills/debugging/SKILL.md\``,
-            `- \`${RUNTIME_ROOT}/references/stages/tdd-wave-walkthrough.md\``
+            `- \`${RUNTIME_ROOT}/references/stages/tdd-batch-walkthrough.md\``
         ],
         review: [
             `- \`${RUNTIME_ROOT}/skills/security/SKILL.md\``,
@@ -239,15 +239,15 @@ function quickStartBlock(stage) {
 `;
 }
 /**
- * Long-form Wave Execution walkthrough. Rendered once into
- * \`.cclaw/references/stages/tdd-wave-walkthrough.md\` by the installer.
+ * Long-form Batch Execution walkthrough. Rendered once into
+ * \`.cclaw/references/stages/tdd-batch-walkthrough.md\` by the installer.
  */
-export const TDD_WAVE_WALKTHROUGH_MARKDOWN = `# TDD — Wave Execution Walkthrough
+export const TDD_BATCH_WALKTHROUGH_MARKDOWN = `# TDD — Batch Execution Walkthrough
 
-Detailed RED / GREEN / REFACTOR transcript for a 3-task wave. Illustrative
+Detailed RED / GREEN / REFACTOR transcript for a 3-task batch. Illustrative
 only — do not copy the command names blindly, match them to your stack.
 
-## Wave 1 example tasks
+## Batch 1 example tasks
 
 | Task ID | Description | AC | Verification |
 |---|---|---|---|
@@ -277,15 +277,15 @@ Write the repo test that expects normalised writes, watch it fail (RED), impleme
 
 Write the service-level duplicate test that expects a rejection, watch it fail (RED), add the duplicate check in \`UserService.signup\` (GREEN), refactor the error message into a named constant (REFACTOR).
 
-## Wave gate check
+## Batch gate check
 
-After T-3 REFACTOR, before declaring Wave 1 done:
+After T-3 REFACTOR, before declaring Batch 1 done:
 
-1. Run the full suite (\`npm test\`) one final time → **PASS** captured as wave-exit evidence.
-2. Verify the TDD artifact contains RED, GREEN, and REFACTOR evidence for T-1, T-2, **and** T-3. No partial waves.
-3. Only now mark Wave 1 complete. Wave 2 cannot start until this step.
+1. Run the full suite (\`npm test\`) one final time → **PASS** captured as batch-exit evidence.
+2. Verify the TDD artifact contains RED, GREEN, and REFACTOR evidence for T-1, T-2, **and** T-3. No partial batches.
+3. Only now mark Batch 1 complete. Batch 2 cannot start until this step.
 
-## When to stop mid-wave (do NOT push through)
+## When to stop mid-batch (do NOT push through)
 
 - A RED test fails for a reason you did not predict (e.g. an unrelated flaky test) → **pause**, diagnose, log an operational-self-improvement entry, and decide with the user before proceeding.
 - A GREEN step would require touching code outside the task's acceptance criterion → **pause**, the task is scoped wrong; adjust the plan or open a follow-up task.
@@ -362,7 +362,7 @@ ${schema.interactionProtocol.map((item, i) => `${i + 1}. ${item}`).join("\n")}
 Shared decision/ask-user protocol:
 \`${DECISION_PROTOCOL_PATH}\`
 
-${waveExecutionModeBlock(stage)}
+${batchExecutionModeBlock(stage)}
 ## Required Gates
 ${gateList}
 

package/dist/content/stage-schema.js

@@ -36,7 +36,7 @@ const REQUIRED_GATE_IDS = {
     ],
     plan: [
         "plan_tasks_sliced_2_5_min",
-        "plan_dependency_waves_defined",
+        "plan_dependency_batches_defined",
         "plan_acceptance_mapped",
         "plan_wait_for_confirm"
     ],
@@ -64,7 +64,7 @@ const REQUIRED_ARTIFACT_SECTIONS = {
     scope: ["Scope Mode", "In Scope / Out of Scope", "Completion Dashboard", "Scope Summary"],
     design: ["Architecture Boundaries", "Architecture Diagram", "Failure Mode Table", "Completion Dashboard"],
     spec: ["Acceptance Criteria", "Edge Cases", "Testability Map", "Approval"],
-    plan: ["Task List", "Dependency Waves", "Acceptance Mapping", "WAIT_FOR_CONFIRM"],
+    plan: ["Task List", "Dependency Batches", "Acceptance Mapping", "WAIT_FOR_CONFIRM"],
     tdd: ["RED Evidence", "GREEN Evidence", "REFACTOR Notes", "Traceability"],
     review: ["Layer 1 Verdict", "Review Army Contract", "Severity Summary", "Final Verdict"],
     ship: ["Preflight Results", "Release Notes", "Rollback Plan", "Finalization"]

package/dist/content/stages/plan.js

@@ -22,7 +22,7 @@ export const PLAN = {
     checklist: [
         "Read upstream — load spec, design, and scope artifacts. Cross-reference acceptance criteria.",
         "Build dependency graph — identify task ordering, parallel opportunities, and blocking dependencies.",
-        "Group tasks into dependency waves — wave N+1 cannot start until wave N has verification evidence.",
+        "Group tasks into dependency batches — batch N+1 cannot start until batch N has verification evidence.",
         "Slice into vertical tasks — each task targets 2-5 minutes, produces one testable outcome, and touches one coherent area.",
         "Attach verification — every task has an acceptance criterion mapping and a concrete verification command.",
         "Map scope Locked Decisions — every D-XX from scope is referenced by at least one plan task (or explicitly marked deferred with reason).",
@@ -33,7 +33,7 @@ export const PLAN = {
     interactionProtocol: [
         "Plan in read-only mode relative to implementation.",
         "Split work into small vertical slices (target 2-5 minute tasks).",
-        "Publish explicit dependency waves with entry and exit checks for each wave.",
+        "Publish explicit dependency batches with entry and exit checks for each batch.",
         "Attach verification step to every task.",
         "Preserve locked scope boundaries: no silent scope reduction language in task rows.",
         "Enforce WAIT_FOR_CONFIRM: present the plan summary with options (A) Approve / (B) Revise / (C) Reject.",
@@ -41,7 +41,7 @@ export const PLAN = {
     ],
     process: [
         "Build dependency graph and ordered slices.",
-        "Group slices into execution waves and define gate criteria per wave.",
+        "Group slices into execution batches and define gate criteria per batch.",
         "Define each task with acceptance mapping and verification commands.",
         "Trace every locked decision (D-XX) to plan tasks or explicit defer rationale.",
         "Record checkpoints and blockers.",
@@ -50,7 +50,7 @@ export const PLAN = {
     requiredGates: [
         { id: "plan_tasks_sliced_2_5_min", description: "Tasks are small, executable slices." },
         { id: "plan_dependency_graph_written", description: "Dependency graph and order are explicit." },
-        { id: "plan_dependency_waves_defined", description: "Tasks are grouped into executable waves with gate checks." },
+        { id: "plan_dependency_batches_defined", description: "Tasks are grouped into executable batches with gate checks." },
         { id: "plan_verification_steps_defined", description: "Each task has verification guidance." },
         { id: "plan_acceptance_mapped", description: "Each task maps to a spec acceptance criterion." },
         { id: "plan_wait_for_confirm", description: "Execution blocked until explicit user confirmation." }
@@ -60,7 +60,7 @@ export const PLAN = {
         "Task list includes acceptance mapping.",
         "Locked decision coverage table present with D-XX trace links.",
         "Dependency graph documented.",
-        "Dependency waves documented with wave-by-wave verification gates.",
+        "Dependency batches documented with batch-by-batch verification gates.",
         "WAIT_FOR_CONFIRM status recorded."
     ],
     inputs: ["approved spec", "codebase context", "delivery constraints"],
@@ -69,11 +69,11 @@ export const PLAN = {
         "current architecture",
         "known technical debt and dependencies"
     ],
-    outputs: ["task graph", "dependency wave plan", "ordered plan", "explicit confirmation checkpoint"],
+    outputs: ["task graph", "dependency batch plan", "ordered plan", "explicit confirmation checkpoint"],
     blockers: [
         "tasks too broad",
         "dependency uncertainty unresolved",
-        "wave boundaries are unclear",
+        "batch boundaries are unclear",
         "locked decisions from scope are not mapped to tasks",
         "no explicit confirmation"
     ],
@@ -91,13 +91,13 @@ export const PLAN = {
         "Using placeholder tokens or scope-reduction phrases (`v1`, `for now`, `later`) in task definitions",
         "No dependency graph",
         "No WAIT_FOR_CONFIRM marker",
-        "No explicit dependency waves",
+        "No explicit dependency batches",
         "Tasks exceed one coherent outcome",
         "No acceptance mapping",
         "Locked decisions are missing or not mapped",
         "Scope-reduction language appears without explicit approved defer decision"
     ],
-    policyNeedles: ["WAIT_FOR_CONFIRM", "Task Graph", "Dependency Waves", "Acceptance Mapping", "verification steps", "Locked Decision Coverage"],
+    policyNeedles: ["WAIT_FOR_CONFIRM", "Task Graph", "Dependency Batches", "Acceptance Mapping", "verification steps", "Locked Decision Coverage"],
     artifactFile: "05-plan.md",
     next: "tdd",
     reviewSections: [
@@ -113,13 +113,13 @@ export const PLAN = {
             stopGate: true
         },
         {
-            title: "Wave Completeness Audit",
+            title: "Batch Completeness Audit",
             evaluationPoints: [
-                "Does every task belong to exactly one wave?",
-                "Does each wave have a verification gate?",
-                "Are wave dependencies explicit and acyclic?",
+                "Does every task belong to exactly one batch?",
+                "Does each batch have a verification gate?",
+                "Are batch dependencies explicit and acyclic?",
                 "Is the acceptance mapping complete — every spec criterion covered?",
-                "Are there hidden dependencies between tasks in different waves?"
+                "Are there hidden dependencies between tasks in different batches?"
             ],
             stopGate: true
         },
@@ -129,7 +129,7 @@ export const PLAN = {
                 "Does every task carry an explicit minutes estimate (e.g. `[~3m]`) and does every estimate fit the 2-to-5-minute budget? Estimates >5 minutes must be split.",
                 "Are all file paths, test commands, and verification commands copy-pasteable as written — no `TODO`, `TBD`, `FIXME`, `<fill-in>`, `<your-*-here>`, `xxx`, or ellipsis standing in for omitted args?",
                 "Does every acceptance-criterion reference resolve to a real R# / AC-### in the spec (not a blank link)?",
-                "If an estimate is genuinely uncertain (first-time integration, unfamiliar library), is the uncertainty named explicitly and scheduled as a spike task in wave 0, rather than hidden behind a large estimate?"
+                "If an estimate is genuinely uncertain (first-time integration, unfamiliar library), is the uncertainty named explicitly and scheduled as a spike task in batch 0, rather than hidden behind a large estimate?"
             ],
             stopGate: true
         }
@@ -142,12 +142,12 @@ export const PLAN = {
     },
     artifactValidation: [
         { section: "Dependency Graph", required: true, validationRule: "Ordering and parallel opportunities explicit. No circular dependencies." },
-        { section: "Dependency Waves", required: true, validationRule: "Every task belongs to a wave. Each wave has an exit gate and dependency statement." },
+        { section: "Dependency Batches", required: true, validationRule: "Every task belongs to a batch. Each batch has an exit gate and dependency statement." },
         { section: "Task List", required: true, validationRule: "Each task row includes ID, description, acceptance criterion, verification command, and effort estimate (S/M/L). Every task must also carry a minutes estimate within the 2-5 minute budget." },
         { section: "Acceptance Mapping", required: true, validationRule: "Every spec criterion is covered by at least one task." },
         { section: "Locked Decision Coverage", required: false, validationRule: "Every locked decision ID (D-XX) from scope is listed with linked task IDs or explicit defer rationale." },
-        { section: "Risk Assessment", required: false, validationRule: "If present: per-task or per-wave risk identification with likelihood, impact, and mitigation strategy." },
-        { section: "Boundary Map", required: false, validationRule: "If present: per-wave or per-task interface contracts listing what each task produces (exports) and consumes (imports) from other tasks." },
+        { section: "Risk Assessment", required: false, validationRule: "If present: per-task or per-batch risk identification with likelihood, impact, and mitigation strategy." },
+        { section: "Boundary Map", required: false, validationRule: "If present: per-batch or per-task interface contracts listing what each task produces (exports) and consumes (imports) from other tasks." },
         { section: "WAIT_FOR_CONFIRM", required: true, validationRule: "Explicit marker present. Status: pending until user approves." },
         { section: "No-Placeholder Scan", required: false, validationRule: "Confirmation that a text scan for `TODO`, `TBD`, `FIXME`, `<fill-in>`, `<your-*-here>`, `xxx`, or bare ellipses has zero hits in the task list. A placeholder is a deferred decision masquerading as a plan." },
         { section: "No Scope Reduction Language Scan", required: false, validationRule: "Confirmation that scope-reduction phrases (`v1`, `for now`, `later`, `temporary`, `placeholder`) are absent from task rows when locked decisions exist." }

package/dist/content/stages/schema-types.d.ts

@@ -90,8 +90,8 @@ export interface StageSchema {
     completionStatus: string[];
     crossStageTrace: CrossStageTrace;
     artifactValidation: ArtifactValidation[];
-    /** When true, stage skill includes wave auto-execute guidance (tdd). */
-    waveExecutionAllowed?: boolean;
+    /** When true, stage skill includes batch auto-execute guidance (tdd). */
+    batchExecutionAllowed?: boolean;
     /** Sections that remain required even when the trivial-change escape hatch is active (design only). */
     trivialOverrideSections?: string[];
     /** Agent names that MUST be dispatched (or waived) before stage transition — derived from mandatory auto-subagent rows. */

package/dist/content/stages/tdd.js

@@ -179,5 +179,5 @@ export const TDD = {
         { section: "Test Pyramid Shape", required: false, validationRule: "If present: per-slice count of Small/Medium/Large tests added, to let reviewers verify the suite is not drifting top-heavy." },
         { section: "Prove-It Reproduction", required: false, validationRule: "Required for bug-fix slices: original failing reproduction test (RED without fix), passing output with fix (GREEN), and a note confirming the test fails again if the fix is reverted." }
     ],
-    waveExecutionAllowed: true
+    batchExecutionAllowed: true
 };

package/dist/content/subagents.js

@@ -129,7 +129,7 @@ If you catch yourself writing “read PLAN.md Task 3” or “implement the next
 | Status | Meaning | Controller action |
 |---|---|---|
 | DONE | Implementation complete; tests orchestrated per prompt; no known material risks | Proceed to reviewers |
-| DONE_WITH_CONCERNS | Shippable but with documented tradeoffs/risks | Proceed with reviewer + explicit notes; do not “hand-wave” concerns |
+| DONE_WITH_CONCERNS | Shippable but with documented tradeoffs/risks | Proceed with reviewer + explicit notes; do not dismiss concerns |
 | NEEDS_CONTEXT | Missing authoritative information only the parent/user can supply | Parent gathers context, then re-dispatch implementer with augmented prompt |
 | BLOCKED | Hard stop (permissions, tool failure, conflicting requirements, unsafe state) | Parent escalates to user; do not stack speculative guesses |
 

package/dist/content/templates.js

@@ -309,23 +309,23 @@ inputs_hash: sha256:pending
 ## Dependency Graph
 - 
 
-## Dependency Waves
+## Dependency Batches
 
-### Wave 1 (foundation)
+### Batch 1 (foundation)
 - Task IDs:
 - Verification gate:
 
-### Wave 2 (dependent)
+### Batch 2 (dependent)
 - Task IDs:
 - Depends on:
 - Verification gate:
 
-### Wave 3 (integration)
+### Batch 3 (integration)
 - Task IDs:
 - Depends on:
 - Verification gate:
 
-Execution rule: complete and verify each wave before starting the next wave.
+Execution rule: complete and verify each batch before starting the next batch.
 
 ## Task List
 
@@ -333,7 +333,7 @@ Execution rule: complete and verify each wave before starting the next wave.
 - Every task fits the **2-5 minute budget**. If \`[~Nm]\` is >5, split the task.
 - **No placeholders.** Forbidden tokens anywhere in this table: \`TODO\`, \`TBD\`, \`FIXME\`, \`<fill-in>\`, \`<your-*-here>\`, \`xxx\`, bare ellipsis. Every file path, test, and verification command must be copy-pasteable as written.
 - **No silent scope reduction.** Forbidden phrasing when locked decisions exist: \`v1\`, \`for now\`, \`later\`, \`temporary\`, \`placeholder\`, \`mock for now\`, \`hardcoded for now\`, \`will improve later\`.
-- If an estimate is genuinely uncertain (new library, unfamiliar subsystem), add a **spike task in wave 0** to de-risk — do NOT hide the uncertainty inside a large estimate.
+- If an estimate is genuinely uncertain (new library, unfamiliar subsystem), add a **spike task in batch 0** to de-risk — do NOT hide the uncertainty inside a large estimate.
 
 | Task ID | Description | Acceptance criterion | Verification command | Effort (S/M/L) | Minutes |
 |---|---|---|---|---|---|
@@ -350,12 +350,12 @@ Execution rule: complete and verify each wave before starting the next wave.
 | D-01 | 02-scope.md > Locked Decisions | T-1 | covered |
 
 ## Risk Assessment
-| Task/Wave | Risk | Likelihood | Impact | Mitigation |
+| Task/Batch | Risk | Likelihood | Impact | Mitigation |
 |---|---|---|---|---|
 |  |  |  |  |  |
 
 ## Boundary Map
-| Task/Wave | Produces (exports) | Consumes (imports from) |
+| Task/Batch | Produces (exports) | Consumes (imports from) |
 |---|---|---|
 |  |  |  |
 

package/dist/content/utility-skills.js

@@ -482,7 +482,7 @@ description: "Execute approved plans with disciplined batching, explicit checkpo
 ## Quick Start
 
 > 1. Confirm the plan and stage gates are approved before execution.
-> 2. Execute in batches (waves), not as one giant untracked stream.
+> 2. Execute in batches, not as one giant untracked stream.
 > 3. Stop at checkpoint boundaries for verification and user visibility.
 
 ## HARD-GATE
@@ -492,47 +492,47 @@ Do not start implementation execution without an approved plan artifact and expl
 ## Execution Protocol
 
 1. **Load plan source of truth** from \`.cclaw/artifacts/05-plan.md\` (canonical run copy when available).
-2. **Group tasks into waves** by dependency order and risk.
-3. **Run one wave at a time** with evidence after each task (tests, build, lint, or review evidence as applicable).
-4. **Checkpoint each wave** by updating stage artifact evidence and unresolved blockers.
+2. **Group tasks into batches** by dependency order and risk.
+3. **Run one batch at a time** with evidence after each task (tests, build, lint, or review evidence as applicable).
+4. **Checkpoint each batch** by updating stage artifact evidence and unresolved blockers.
 5. **Stop immediately** on any hard blocker, failing gate, or unresolved critical finding.
 
-## Wave Checklist
+## Batch Checklist
 
-- Wave scope is explicit (task IDs + expected outputs).
+- Batch scope is explicit (task IDs + expected outputs).
 - Verification command for each task is predetermined.
 - Machine-only checks are delegated to subagents when supported.
 - User approvals are requested only at required gate boundaries.
 
-## Fresh Context Protocol (between waves)
+## Fresh Context Protocol (between batches)
 
-After a wave completes — especially after long agent turns — context drift is
-the #1 cause of degraded execution quality. Before starting the **next wave**,
+After a batch completes — especially after long agent turns — context drift is
+the #1 cause of degraded execution quality. Before starting the **next batch**,
 prefer a **fresh agent context** over continuing in a saturated session:
 
-1. **Snapshot wave outcome** — append a short summary to the plan artifact
-   (\`### Wave <N> outcome\` with: tasks done, evidence files, blockers, next-wave inputs).
+1. **Snapshot batch outcome** — append a short summary to the plan artifact
+   (\`### Batch <N> outcome\` with: tasks done, evidence files, blockers, next-batch inputs).
 2. **Capture handoff facts** — the minimum information the next agent needs:
    - Stage and run id (from \`.cclaw/state/flow-state.json\`)
    - List of completed task IDs from the plan
    - Open blockers / failing gates by name
-   - File paths the next wave will touch (no full diffs)
+   - File paths the next batch will touch (no full diffs)
 3. **Decide: continue or rotate**
-   - **Rotate** (start a new agent session) when: prior wave consumed > ~50% of the context budget, the prior wave required deep investigation that the next wave does not need, or you are about to cross a stage boundary.
-   - **Continue** when: next wave is a tiny follow-up (≤ 1 task) and the prior context is directly relevant.
+   - **Rotate** (start a new agent session) when: prior batch consumed > ~50% of the context budget, the prior batch required deep investigation that the next batch does not need, or you are about to cross a stage boundary.
+   - **Continue** when: next batch is a tiny follow-up (≤ 1 task) and the prior context is directly relevant.
 4. **Resume** in the new session via \`/cc-next\` — the session-start hook will restore flow state, checkpoint, and digest automatically.
 
-This is the same intuition as Compound Engineering's "fresh context per iteration": every wave starts with a clean, intentionally-loaded context, not a degraded carry-over.
+This is the same intuition as Compound Engineering's "fresh context per iteration": every batch starts with a clean, intentionally-loaded context, not a degraded carry-over.
 
 ### Handoff template (paste into next session)
 
 \`\`\`markdown
-## Wave <N> handoff
+## Batch <N> handoff
 - Stage: <stage>
 - Run: <runId>
 - Completed task IDs: <list>
 - Blockers: <list or none>
-- Files next wave will touch: <list>
+- Files next batch will touch: <list>
 - Verification command(s) used: <list>
 \`\`\`
 
@@ -542,7 +542,7 @@ This is the same intuition as Compound Engineering's "fresh context per iteratio
 - Marking tasks done without command evidence.
 - Reordering critical dependencies for speed.
 - Continuing after a gate failure hoping later tasks fix it.
-- Carrying a saturated context across wave boundaries because "it has all the history" — saturated context is a liability, not an asset.
+- Carrying a saturated context across batch boundaries because "it has all the history" — saturated context is a liability, not an asset.
 `;
 }
 export function contextEngineeringSkill() {
@@ -1338,7 +1338,7 @@ For each lens, write either a knowledge entry **or** the explicit string
 
 ### 2. What slowed us down?
 
-- Repeated context loss between waves → \`[compound]\` accelerator.
+- Repeated context loss between batches → \`[compound]\` accelerator.
 - Re-derivation of a fact already in upstream artifacts → \`[pattern]\` "re-read X first".
 - Tooling friction (slow test loop, flaky CI) → \`[compound]\` follow-up.
 

package/dist/doctor.js

@@ -283,8 +283,8 @@ export async function doctorChecks(projectRoot, options = {}) {
             const skillContent = await fs.readFile(skillPath, "utf8");
             const lineCount = skillContent.split("\n").length;
             const MIN_SKILL_LINES = 110;
-            // Soft max tightened in wave 3 from 650 → 500 after externalising the
-            // TDD wave-execution walkthrough and collapsing the duplicate "what
+            // Soft max tightened from 650 → 500 after externalising the TDD
+            // batch-execution walkthrough and collapsing the duplicate "what
             // goes wrong" lists. Stage skills beyond 500 lines drift into unread
             // bloat; long-form content belongs under `.cclaw/references/` instead.
             const MAX_SKILL_LINES = 500;

package/dist/eval/baseline.js

@@ -1,5 +1,5 @@
 /**
- * Baseline I/O + regression comparison (Wave 7.1).
+ * Baseline I/O + regression comparison for the eval subsystem.
  *
  * Layout on disk (committed):
  *

package/dist/eval/corpus.d.ts

@@ -14,6 +14,6 @@ export declare function fixturePathFor(projectRoot: string, caseEntry: EvalCase)
 /**
  * Read the fixture artifact text for a case. Returns `undefined` if the case
  * has no fixture reference. Throws a descriptive error if the path exists in
- * the case but not on disk — Wave 7.1 fixtures ship alongside cases.
+ * the case but not on disk — structural fixtures ship alongside cases.
  */
 export declare function readFixtureArtifact(projectRoot: string, caseEntry: EvalCase): Promise<string | undefined>;

package/dist/eval/corpus.js

@@ -162,7 +162,7 @@ export function fixturePathFor(projectRoot, caseEntry) {
 /**
  * Read the fixture artifact text for a case. Returns `undefined` if the case
  * has no fixture reference. Throws a descriptive error if the path exists in
- * the case but not on disk — Wave 7.1 fixtures ship alongside cases.
+ * the case but not on disk — structural fixtures ship alongside cases.
  */
 export async function readFixtureArtifact(projectRoot, caseEntry) {
     const fixturePath = fixturePathFor(projectRoot, caseEntry);

package/dist/eval/llm-client.d.ts

@@ -1,17 +1,17 @@
 /**
  * LLM client skeleton for the cclaw eval subsystem.
  *
- * Wave 7.0 declares the shape of the client without pulling in the `openai`
- * runtime dependency. The real implementation is wired in Wave 7.3 when
+ * This module declares the shape of the client without pulling in the
+ * `openai` runtime dependency. The real implementation lands when
  * single-shot (Tier A) evals and LLM judging come online. Keeping this stub
- * separate means users of Waves 7.0–7.2 (structural + rule-based verifiers)
- * never install an extra dependency or receive network egress warnings.
+ * separate means users who only run structural + rule-based verifiers never
+ * install an extra dependency or receive network egress warnings.
  */
 import type { ResolvedEvalConfig } from "./types.js";
 /**
  * Minimal chat interface the rest of the eval code will depend on. It is
  * intentionally a subset of OpenAI's Chat Completions surface so that the
- * Wave 7.3 implementation is a thin adapter around `OpenAI.chat.completions.create`.
+ * real implementation is a thin adapter around `OpenAI.chat.completions.create`.
  */
 export interface ChatMessage {
     role: "system" | "user" | "assistant" | "tool";
@@ -26,8 +26,8 @@ export interface ChatRequest {
     temperature?: number;
     timeoutMs?: number;
     /**
-     * Tool/function-calling definitions in OpenAI wire format. Populated only by
-     * Wave 7.4 (Tier B). Ignored by the Wave 7.3 single-shot path.
+     * Tool/function-calling definitions in OpenAI wire format. Populated only
+     * by Tier B. Ignored by the Tier A single-shot path.
      */
     tools?: unknown[];
     toolChoice?: "auto" | "none";
@@ -52,11 +52,11 @@ export interface EvalLlmClient {
     chat(request: ChatRequest): Promise<ChatResponse>;
 }
 export declare class EvalLlmNotWiredError extends Error {
-    constructor(wave: string);
+    constructor();
 }
 /**
- * Factory stub. Throws with a clear message so accidental Wave 7.0 usage is
- * easy to diagnose. The Wave 7.3 implementation will replace this body with
+ * Factory stub. Throws with a clear message so accidental early usage is
+ * easy to diagnose. The real implementation will replace this body with
  * `new OpenAI({ apiKey, baseURL }) ... adapter`.
  */
 export declare function createEvalClient(_config: ResolvedEvalConfig): EvalLlmClient;

package/dist/eval/llm-client.js

@@ -1,19 +1,19 @@
 export class EvalLlmNotWiredError extends Error {
-    constructor(wave) {
-        super(`LLM client is not wired in Wave 7.0. It arrives in Wave ${wave}.\n` +
+    constructor() {
+        super(`LLM client is not wired yet.\n` +
             `Run \`cclaw eval --dry-run\` or \`cclaw eval --schema-only\` for offline evals.`);
         this.name = "EvalLlmNotWiredError";
     }
 }
 /**
- * Factory stub. Throws with a clear message so accidental Wave 7.0 usage is
- * easy to diagnose. The Wave 7.3 implementation will replace this body with
+ * Factory stub. Throws with a clear message so accidental early usage is
+ * easy to diagnose. The real implementation will replace this body with
  * `new OpenAI({ apiKey, baseURL }) ... adapter`.
  */
 export function createEvalClient(_config) {
     return {
         async chat() {
-            throw new EvalLlmNotWiredError("7.3");
+            throw new EvalLlmNotWiredError();
         }
     };
 }

package/dist/eval/report.js

@@ -62,7 +62,7 @@ export function formatMarkdownReport(report) {
     if (report.cases.length === 0) {
         lines.push(`## Cases`);
         lines.push(``);
-        lines.push(`No cases were executed. See \`docs/evals.md\` for the Wave rollout plan.`);
+        lines.push(`No cases were executed. See \`docs/evals.md\` for the rollout plan.`);
         lines.push(``);
         return `${lines.join("\n")}\n`;
     }

package/dist/eval/runner.d.ts

@@ -4,11 +4,11 @@ export interface RunEvalOptions {
     projectRoot: string;
     stage?: FlowStage;
     tier?: EvalTier;
-    /** When true, run only structural verifiers (Wave 7.1). */
+    /** When true, run only structural verifiers (Step 1). */
     schemaOnly?: boolean;
-    /** When true, run structural + rule-based verifiers. Wave 7.2 wires rules. */
+    /** When true, run structural + rule-based verifiers. Step 2 wires rules. */
     rules?: boolean;
-    /** When true, also run LLM judge verifiers. Wave 7.3 wires judging. */
+    /** When true, also run LLM judge verifiers. Step 3 wires judging. */
     judge?: boolean;
     /** When true, load config + corpus and return a summary without running any verifier. */
     dryRun?: boolean;
@@ -36,10 +36,10 @@ export interface DryRunSummary {
     notes: string[];
 }
 /**
- * Wave 7.1 runner. When `schemaOnly` is set (or no other verifier flags are
+ * Structural runner. When `schemaOnly` is set (or no other verifier flags are
  * active), runs structural verifiers against fixture-backed cases and loads
  * per-stage baselines for regression comparison. Tier A/B/C agent loops
- * still arrive in Waves 7.3+; until then cases without `fixture` are marked
- * as skipped rather than failing.
+ * arrive in later steps; until then cases without `fixture` are marked as
+ * skipped rather than failing.
  */
 export declare function runEval(options: RunEvalOptions): Promise<DryRunSummary | EvalReport>;

package/dist/eval/runner.js

@@ -14,7 +14,7 @@ function groupByStage(cases) {
 function skeletonVerifierResult(message, details) {
     return {
         kind: "structural",
-        id: "wave-7-1-no-structural-expected",
+        id: "structural:no-expectations",
         ok: true,
         score: 1,
         message,
@@ -111,11 +111,11 @@ function stagesInResults(caseResults) {
     return FLOW_STAGES.filter((s) => set.has(s));
 }
 /**
- * Wave 7.1 runner. When `schemaOnly` is set (or no other verifier flags are
+ * Structural runner. When `schemaOnly` is set (or no other verifier flags are
  * active), runs structural verifiers against fixture-backed cases and loads
  * per-stage baselines for regression comparison. Tier A/B/C agent loops
- * still arrive in Waves 7.3+; until then cases without `fixture` are marked
- * as skipped rather than failing.
+ * arrive in later steps; until then cases without `fixture` are marked as
+ * skipped rather than failing.
  */
 export async function runEval(options) {
     const config = await loadEvalConfig(options.projectRoot, options.env ?? process.env);
@@ -126,10 +126,10 @@ export async function runEval(options) {
         notes.push("Corpus is empty. Seed cases live under `.cclaw/evals/corpus/<stage>/*.yaml`.");
     }
     if (options.rules) {
-        notes.push("--rules is accepted; rule verifiers wire up in Wave 7.2.");
+        notes.push("--rules is accepted; rule verifiers are not wired yet.");
     }
     if (options.judge) {
-        notes.push("--judge is accepted; LLM judging wires up in Wave 7.3.");
+        notes.push("--judge is accepted; LLM judging is not wired yet.");
     }
     if (options.dryRun === true) {
         const summary = {

package/dist/eval/types.d.ts

@@ -6,7 +6,7 @@
  * deliberately decoupled from the main cclaw runtime so that:
  *
  * - Users who never run `cclaw eval` pay zero runtime cost.
- * - The verifier / rubric / LLM stack evolves on its own release cadence (Waves 7.0-7.6).
+ * - The verifier / rubric / LLM stack evolves on its own release cadence (Steps 0-6).
  * - Any OpenAI-compatible endpoint can be swapped in via config (z.ai, OpenAI, vLLM, etc.).
  */
 import type { FlowStage } from "../types.js";
@@ -29,8 +29,8 @@ export declare const VERIFIER_KINDS: readonly ["structural", "rules", "judge", "
 export type VerifierKind = (typeof VERIFIER_KINDS)[number];
 /**
  * Structural expectations — deterministic, LLM-free checks against a single
- * text artifact. Wave 7.1 implements all fields below; Wave 7.2 adds the
- * sibling `rules` shape, Wave 7.3 adds `judge`.
+ * text artifact. Step 1 implements all fields below; Step 2 adds the
+ * sibling `rules` shape, Step 3 adds `judge`.
  */
 export interface StructuralExpected {
     /**
@@ -58,19 +58,19 @@ export interface StructuralExpected {
      */
     requiredFrontmatterKeys?: string[];
 }
-/** Superset of per-verifier expectation shapes. Only `structural` is wired in Wave 7.1. */
+/** Superset of per-verifier expectation shapes. Only `structural` is wired in Step 1. */
 export interface ExpectedShape {
     structural?: StructuralExpected;
-    /** Rule-based (keyword/regex/traceability) checks — Wave 7.2. */
+    /** Rule-based (keyword/regex/traceability) checks — Step 2. */
     rules?: Record<string, unknown>;
-    /** LLM-judge rubrics — Wave 7.3. */
+    /** LLM-judge rubrics — Step 3. */
     judge?: Record<string, unknown>;
 }
 /**
  * A single eval case describes one input scenario for one stage. Cases live in
  * `.cclaw/evals/corpus/<stage>/<id>.yaml` and may reference a pre-generated
- * fixture artifact for verifier development (Wave 7.1) before the agent loop
- * exists (Wave 7.3+).
+ * fixture artifact for verifier development (Step 1) before the agent loop
+ * exists (Step 3+).
  */
 export interface EvalCase {
     id: string;
@@ -85,8 +85,8 @@ export interface EvalCase {
     expected?: ExpectedShape;
     /**
      * Path (relative to the corpus case file) of a pre-generated artifact used
-     * when verifiers are exercised without a live agent loop. Primarily a Wave
-     * 7.1 development aid.
+     * when verifiers are exercised without a live agent loop. Primarily a
+     * Step 1 development aid.
      */
     fixture?: string;
 }
@@ -129,7 +129,7 @@ export interface EvalReport {
         totalCostUsd: number;
         totalDurationMs: number;
     };
-    /** Present when comparing against a saved baseline (Wave 7.1+). */
+    /** Present when comparing against a saved baseline (Step 1+). */
     baselineDelta?: BaselineDelta;
 }
 /**
@@ -170,7 +170,7 @@ export interface ResolvedEvalConfig extends EvalConfig {
     source: "default" | "file" | "env" | "file+env";
 }
 /**
- * Frozen per-stage baseline used by regression gating (Wave 7.1). Baselines
+ * Frozen per-stage baseline used by regression gating (Step 1). Baselines
  * are committed to git; `cclaw eval --update-baseline --confirm` rewrites
  * them. The shape is intentionally flat so a quick `git diff` reveals what
  * changed between runs.

package/dist/eval/verifiers/structural.js

@@ -1,5 +1,5 @@
 /**
- * Structural verifier (Wave 7.1): deterministic, zero-LLM checks against a
+ * Structural verifier: deterministic, zero-LLM checks against a
  * single markdown artifact. Each structural expectation produces one
  * `VerifierResult` so baselines diff cleanly at the check level rather than
  * lumping everything into a single boolean.
@@ -15,8 +15,8 @@
  * - `minLines`/`maxLines` intentionally exclude frontmatter so a rewrite that
  *   adds metadata does not accidentally drop the body below the floor.
  * - Scoring: each check scores 0 or 1. The case `passed` becomes the AND of
- *   all individual `ok` flags. This keeps Wave 7.1 deterministic; the 0..1
- *   rubric scale shows up in Wave 7.3 (judge).
+ *   all individual `ok` flags. This keeps the structural verifier
+ *   deterministic; the 0..1 rubric scale shows up later in the LLM judge.
  */
 import { parse as parseYaml } from "yaml";
 const FRONTMATTER_OPEN = /^---\r?\n/;

package/dist/install.js

@@ -29,7 +29,7 @@ import { META_SKILL_NAME, usingCclawSkillMarkdown } from "./content/meta-skill.j
 import { decisionProtocolMarkdown, completionProtocolMarkdown, ethosProtocolMarkdown } from "./content/protocols.js";
 import { ARTIFACT_TEMPLATES, CURSOR_WORKFLOW_RULE_MDC, RULEBOOK_MARKDOWN, buildRulesJson } from "./content/templates.js";
 import { EVAL_BASELINES_README, EVAL_CONFIG_YAML, EVAL_CORPUS_README, EVAL_REPORTS_README, EVAL_RUBRICS_README } from "./content/eval-scaffold.js";
-import { TDD_WAVE_WALKTHROUGH_MARKDOWN, stageSkillFolder, stageSkillMarkdown } from "./content/skills.js";
+import { TDD_BATCH_WALKTHROUGH_MARKDOWN, stageSkillFolder, stageSkillMarkdown } from "./content/skills.js";
 import { stageCommonGuidanceMarkdown } from "./content/stage-common-guidance.js";
 import { STAGE_EXAMPLES_REFERENCE_DIR, stageExamplesReferenceMarkdown } from "./content/examples.js";
 import { LANGUAGE_RULE_PACK_DIR, LANGUAGE_RULE_PACK_FILES, LANGUAGE_RULE_PACK_GENERATORS, LEGACY_LANGUAGE_RULE_PACK_FOLDERS, UTILITY_SKILL_FOLDERS, UTILITY_SKILL_MAP } from "./content/utility-skills.js";
@@ -218,11 +218,11 @@ async function writeSkills(projectRoot, config) {
             await writeFileSafe(runtimePath(projectRoot, ...referenceDir, `${stage}-examples.md`), referenceMarkdown);
         }
     }
-    // Progressive disclosure for the TDD Wave Execution walkthrough (A.1#1).
+    // Progressive disclosure for the TDD Batch Execution walkthrough (A.1#1).
     // The detailed 3-task transcript lives next to stage examples so the
     // always-rendered TDD skill stays under the line-budget and the reference
     // is loaded on demand.
-    await writeFileSafe(runtimePath(projectRoot, ...STAGE_EXAMPLES_REFERENCE_DIR.split("/"), "tdd-wave-walkthrough.md"), TDD_WAVE_WALKTHROUGH_MARKDOWN);
+    await writeFileSafe(runtimePath(projectRoot, ...STAGE_EXAMPLES_REFERENCE_DIR.split("/"), "tdd-batch-walkthrough.md"), TDD_BATCH_WALKTHROUGH_MARKDOWN);
     await writeFileSafe(runtimePath(projectRoot, ...STAGE_EXAMPLES_REFERENCE_DIR.split("/"), "common-guidance.md"), stageCommonGuidanceMarkdown());
     // Utility skills (not flow stages)
     await writeFileSafe(runtimePath(projectRoot, "skills", "learnings", "SKILL.md"), learnSkillMarkdown());

package/dist/policy.js

@@ -161,7 +161,7 @@ export async function policyChecks(projectRoot, options = {}) {
         { file: runtimeFile("skills/docs/SKILL.md"), needle: "## README Guidance", name: "utility_skill:docs:readme" },
         { file: runtimeFile("skills/executing-plans/SKILL.md"), needle: "## HARD-GATE", name: "utility_skill:executing_plans:hard_gate" },
         { file: runtimeFile("skills/executing-plans/SKILL.md"), needle: "## Execution Protocol", name: "utility_skill:executing_plans:protocol" },
-        { file: runtimeFile("skills/executing-plans/SKILL.md"), needle: "## Wave Checklist", name: "utility_skill:executing_plans:waves" },
+        { file: runtimeFile("skills/executing-plans/SKILL.md"), needle: "## Batch Checklist", name: "utility_skill:executing_plans:batches" },
         { file: runtimeFile("skills/verification-before-completion/SKILL.md"), needle: "## HARD-GATE", name: "utility_skill:verification_before_completion:hard_gate" },
         { file: runtimeFile("skills/verification-before-completion/SKILL.md"), needle: "## Protocol", name: "utility_skill:verification_before_completion:protocol" },
         { file: runtimeFile("skills/finishing-a-development-branch/SKILL.md"), needle: "## HARD-GATE", name: "utility_skill:finishing_branch:hard_gate" },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cclaw-cli",
-  "version": "0.23.0",
+  "version": "0.23.1",
   "description": "Installer-first flow toolkit for coding agents",
   "type": "module",
   "bin": {