cclaw-cli 7.7.1 → 8.1.1

package/dist/content/stages/index.d.ts

@@ -1,8 +0,0 @@
-export { BRAINSTORM } from "./brainstorm.js";
-export { SCOPE } from "./scope.js";
-export { DESIGN } from "./design.js";
-export { SPEC } from "./spec.js";
-export { PLAN } from "./plan.js";
-export { TDD } from "./tdd.js";
-export { REVIEW } from "./review.js";
-export { SHIP } from "./ship.js";

package/dist/content/stages/index.js

@@ -1,11 +0,0 @@
-// Barrel for per-stage StageSchemaInput constants. Keep this file lean — it
-// should be a pure re-export surface so stage-schema.ts can import all stages
-// via a single `import { ... } from "./stages/index.js"`.
-export { BRAINSTORM } from "./brainstorm.js";
-export { SCOPE } from "./scope.js";
-export { DESIGN } from "./design.js";
-export { SPEC } from "./spec.js";
-export { PLAN } from "./plan.js";
-export { TDD } from "./tdd.js";
-export { REVIEW } from "./review.js";
-export { SHIP } from "./ship.js";

package/dist/content/stages/plan.d.ts

@@ -1,2 +0,0 @@
-import type { StageSchemaInput } from "./schema-types.js";
-export declare const PLAN: StageSchemaInput;

package/dist/content/stages/plan.js

@@ -1,191 +0,0 @@
-// ---------------------------------------------------------------------------
-// PLAN
-// ---------------------------------------------------------------------------
-export const PLAN = {
-    schemaShape: "v2",
-    stage: "plan",
-    complexityTier: "standard",
-    skillFolder: "plan",
-    skillName: "plan",
-    skillDescription: "Execution planning stage with strict confirmation gate before implementation.",
-    philosophy: {
-        hardGate: "Do NOT write code or tests. Planning only. This stage produces a task graph and execution order. WAIT_FOR_CONFIRM before any handoff to implementation.",
-        ironLaw: "EVERY IMPLEMENTATION UNIT IS FEATURE-ATOMIC, WITH INTERNAL 2–5 MINUTE TDD STEPS — STRICT MICRO-SLICES ARE RESERVED FOR HIGH-RISK WORK.",
-        purpose: "Create feature-atomic implementation units with dependencies, internal TDD steps, and explicit confirmation before execution.",
-        whenToUse: [
-            "After spec approval",
-            "Before writing tests or implementation",
-            "When delivery path and dependency order are needed"
-        ],
-        whenNotToUse: [
-            "Specification is unapproved or lacks measurable acceptance criteria",
-            "Execution is already in TDD stage with active slice evidence",
-            "The request is only release packaging with no task decomposition needed"
-        ],
-        commonRationalizations: [
-            "Horizontal decomposition without end-to-end slices",
-            "Tasks without verification steps",
-            "Starting execution before approval",
-            "Tasks that touch multiple unrelated areas",
-            "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 batches",
-            "No execution posture for sequencing, risk, and checkpoint cadence",
-            "Tasks exceed one coherent outcome",
-            "No acceptance mapping",
-            "Locked decisions are missing or not mapped",
-            "Scope-reduction language appears without explicit approved defer decision"
-        ]
-    },
-    executionModel: {
-        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 batches — batch N+1 cannot start until batch N has verification evidence.",
-            "Slice into implementation units — each unit is feature-atomic and testable end-to-end, with internal 2-5 minute RED/GREEN/REFACTOR steps. Use `strict-micro` only for high-risk or explicitly requested micro-slice execution.",
-            "Task Contract — every unit has one coherent outcome, AC mapping, exact verification command/manual step, and expected evidence snippet or pass condition. Internal steps may be `T-NNN` rows, but they are not automatically separate schedulable agents in balanced/fast mode.",
-            "Annotate slice-review metadata — task rows may carry `touchCount` (rough number of files expected to change), `touchPaths` (glob hints, e.g. `migrations/**`, `src/auth/**`), and optional `highRisk: true` to force a review pass. These fields feed the TDD stage's Per-Slice Review point.",
-            "For every `### Implementation Unit U-<n>`, declare parallel metadata bullets: `id`, `dependsOn` (unit ids or `none`), `claimedPaths` (repo-relative), `parallelizable` (true|false), `riskTier` (low|standard|high), optional `lane` — used for conflict-aware wave plans and schedulers.",
-            "Map scope Locked Decisions — every D-XX ID from scope is referenced by at least one plan task (or explicitly marked deferred with reason).",
-            "Run anti-placeholder + anti-scope-reduction scans — block `TODO/TBD/...` and phrasing like `v1`, `for now`, `later` for locked boundaries.",
-            "Define validation points — mark where progress must be checked before continuing, with concrete command and expected evidence.",
-            "Define execution topology — record `execution.topology` (`auto|inline|single-builder|parallel-builders|strict-micro`), `execution.strictness` (`fast|balanced|strict`), `execution.maxBuilders`, `plan.sliceGranularity`, `plan.microTaskPolicy`, stop conditions, and RED/GREEN/REFACTOR checkpoint/commit expectations. Default posture is `auto` + `balanced`: choose the cheapest safe route, not the most parallel one.",
-            "**Author the FULL Parallel Execution Plan.** Inside the `<!-- parallel-exec-managed-start -->` block, enumerate all waves W-01..W-N covering every feature-atomic `U-*` implementation unit/slice. Legacy strict-micro plans may cover each non-deferred `T-NNN` task instead. Each row carries `unit|sliceId | dependsOn | claimedPaths | parallelizable | riskTier | lane`. Do not leave `we'll author waves later`, `next batch only`, or open-ended Backlog handwaves. This fulfills the `plan_parallel_exec_full_coverage` gate. The TDD stage downstream is a pure consumer of these waves — if the plan does not author them, TDD cannot fan out that work.",
-            "After authoring/refreshing the managed parallel-exec block, render a Mermaid `flowchart` or `gantt` covering waves (`W-*`) and unit/slice dependencies (`U-*`/`S-*`) so topology and fan-in boundaries are visually auditable.",
-            "WAIT_FOR_CONFIRM — write plan artifact and explicitly pause. **STOP.** Do NOT proceed until user confirms. Then close the stage with `node .cclaw/hooks/stage-complete.mjs plan` and tell user to run `/cc`."
-        ],
-        interactionProtocol: [
-            "Plan in read-only mode relative to implementation.",
-            "Split work into feature-atomic vertical units; place 2-5 minute TDD steps inside each unit.",
-            "Publish explicit dependency batches with entry and exit checks for each batch.",
-            "Expose execution posture: sequential vs batch/parallel, stop conditions, and checkpoint cadence for the TDD handoff.",
-            "Keep same-wave `claimedPaths` disjoint; if overlap exists, split waves or serialize explicitly before handoff.",
-            "Attach exact verification command/manual step and expected evidence 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.",
-            "**STOP.** Do NOT proceed until user explicitly approves.",
-            "**STOP BEFORE ADVANCE.** Mandatory delegation `planner` must be marked completed or explicitly waived in `.cclaw/state/delegation-log.json`. Then close the stage via `node .cclaw/hooks/stage-complete.mjs plan` and tell the user to run `/cc`.",
-            "Investigation discipline: follow the shared `## Investigation Discipline` block — when defining `Implementation Units`, list cited paths in the `Files` and `Patterns to follow` rows instead of pasting code into chat or delegations.",
-            "Behavior anchor: see the shared `## Behavior anchor` block in this skill — the bad/good pair anchors how `Execution Posture` may only claim parallel-safe with disjoint units and a cited interface contract."
-        ],
-        process: [
-            "Build dependency graph and ordered slices.",
-            "Group slices into execution batches and define gate criteria per batch.",
-            "Define each task with acceptance mapping, verification command/manual step, and expected evidence/pass condition.",
-            "Trace every locked decision (D-XX) to plan tasks or explicit defer rationale.",
-            "Record validation points, blockers, and execution posture.",
-            "For high-risk/multi-batch plans, add a calibrated findings pass and explicit regression iron-rule acknowledgement.",
-            "Write plan artifact and pause at WAIT_FOR_CONFIRM."
-        ],
-        requiredGates: [
-            { id: "plan_tasks_sliced_2_5_min", description: "Implementation units are feature-atomic and contain internal 2-5 minute TDD steps; strict micro-slices are explicit." },
-            { id: "plan_dependency_batches_defined", description: "Tasks are grouped into executable batches with gate checks and execution posture." },
-            { id: "plan_acceptance_mapped", description: "Each task maps to a spec acceptance criterion." },
-            { id: "plan_execution_posture_recorded", description: "Execution topology/posture is recorded before implementation handoff." },
-            { id: "plan_parallel_exec_full_coverage", description: "Every U-* implementation unit/slice (or every T-NNN task in explicit strict-micro plans) is assigned inside the `<!-- parallel-exec-managed-start -->` block; TDD cannot fan out work that the plan never authored as waves." },
-            { id: "plan_wave_paths_disjoint", description: "Within each authored wave, slice `claimedPaths` remain disjoint so `wave-fanout` can dispatch safely without overlap conflicts." },
-            { id: "plan_module_introducing_slice_wires_root", description: "When a slice introduces a new module file, the stack-adapter's wiring aggregator (Rust `lib.rs`, Python `__init__.py`, Node-TS barrel when present) must appear in the same slice's claim or a transitive predecessor's claim so RED can be expressed." },
-            { id: "plan_wait_for_confirm", description: "Execution blocked until explicit user confirmation." }
-        ],
-        requiredEvidence: [
-            "Artifact written to `.cclaw/artifacts/05-plan.md`.",
-            "Implementation units include acceptance mapping, internal 2-5 minute TDD steps, exact verification command/manual step, and expected evidence/pass condition.",
-            "Locked decision coverage table present with D-XX trace links.",
-            "Dependency graph documented.",
-            "Dependency batches documented with batch-by-batch verification gates.",
-            "Execution posture documented with sequencing, stop conditions, and TDD checkpoint expectations.",
-            "WAIT_FOR_CONFIRM status recorded."
-        ],
-        inputs: ["approved spec", "codebase context", "delivery constraints"],
-        requiredContext: [
-            "spec acceptance criteria",
-            "current architecture",
-            "known technical debt and dependencies"
-        ],
-        blockers: [
-            "tasks too broad",
-            "dependency uncertainty unresolved",
-            "batch boundaries are unclear",
-            "execution posture is missing or contradicts dependency batches",
-            "locked decisions from scope are not mapped to tasks",
-            "no explicit confirmation"
-        ],
-        exitCriteria: [
-            "plan quality gates complete",
-            "WAIT_FOR_CONFIRM present and unresolved until user approves",
-            "artifact ready for TDD execution",
-            "execution posture ready for TDD handoff",
-            "acceptance mapping complete"
-        ],
-        platformNotes: [
-            "Per-task verification commands must be runnable on Windows PowerShell, macOS bash/zsh, and Linux bash. Prefer `npm run <script>` / `pnpm <script>` / `pytest -k <name>` over raw shell one-liners so the command portability is handled by the script runner.",
-            "If a task command needs globbing, wrap the glob in single quotes on POSIX and escape as needed on PowerShell (`'src/**/*.ts'` vs `\"src/**/*.ts\"`). Note the quoting variant when the task is expected to run in mixed-OS CI.",
-            "Environment variables referenced from tasks must be named in uppercase with underscores (`CCLAW_PROJECT_ROOT`) and set via a cross-shell wrapper (e.g. `cross-env` for Node tasks) — do not inline `KEY=value cmd` style that fails in PowerShell/cmd.exe."
-        ]
-    },
-    artifactRules: {
-        artifactFile: "05-plan.md",
-        completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-        crossStageTrace: {
-            readsFrom: [".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/03-design-<slug>.md", ".cclaw/artifacts/02-scope-<slug>.md"],
-            writesTo: [".cclaw/artifacts/05-plan.md"],
-            traceabilityRule: "Every task must trace to a spec acceptance criterion. Every locked scope decision (D-XX) must trace to at least one plan task or explicit defer rationale. Every downstream RED test must trace to a plan task."
-        },
-        artifactValidation: [
-            { section: "Upstream Handoff", required: false, validationRule: "Summarizes spec/design/scope decisions, constraints, open questions, and explicit drift before task breakdown." },
-            { section: "Dependency Graph", required: false, validationRule: "Ordering and parallel opportunities explicit. No circular dependencies." },
-            { 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: "Task rows may describe internal 2-5 minute TDD steps. In balanced/fast mode, the schedulable unit is the feature-atomic Implementation Unit, not every T-NNN row. Strict-micro plans may still use one T-NNN per slice." },
-            { section: "Acceptance Mapping", required: true, validationRule: "Every spec criterion is covered by at least one task." },
-            { section: "Execution Posture", required: true, validationRule: "States `execution.topology` (`auto|inline|single-builder|parallel-builders|strict-micro`), `execution.strictness`, `execution.maxBuilders`, `plan.sliceGranularity`, `plan.microTaskPolicy`, stop conditions, risk triggers, and RED/GREEN/REFACTOR checkpoint or commit expectations for TDD when consistent with the repo workflow." },
-            { 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-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: "Implementation Units", required: false, validationRule: "Each `### Implementation Unit U-<n>` includes Goal, Files, Approach, Test scenarios, Verification, internal 2-5 minute TDD steps, plus bullets (`id`, `dependsOn`, `claimedPaths`, `parallelizable`, `riskTier`, optional `lane`)." },
-            { section: "Calibrated Findings", required: false, validationRule: "If present: either `None this stage` or one or more lines in `[P1|P2|P3] (confidence: <n>/10) <path>[:<line>] — <description>` format." },
-            { section: "Regression Iron Rule", required: false, validationRule: "If present: includes `Iron rule acknowledged: yes`." },
-            { section: "WAIT_FOR_CONFIRM", required: true, validationRule: "Explicit marker present. Status: pending until user approves." },
-            { section: "Plan Quality Scan", required: false, validationRule: "If present: includes a placeholder scan (`TODO`/`TBD`/`FIXME`/`<fill-in>`/`<your-*-here>`/`xxx`/bare ellipsis) and a scope-reduction language scan (`v1`, `for now`, `later`, `temporary`, `placeholder`) with zero hits in task rows when locked decisions exist." }
-        ]
-    },
-    reviewLens: {
-        outputs: ["task graph", "dependency batch plan", "ordered plan", "explicit confirmation gate"],
-        reviewSections: [
-            {
-                title: "Task Decomposition Audit",
-                evaluationPoints: [
-                    "Does every task target a single coherent area (vertical slice)?",
-                    "Is each implementation unit feature-atomic, with internal steps that fit 2-5 minutes each?",
-                    "Does every task have an acceptance criterion link, exact verification command/manual step, and expected evidence/pass condition?",
-                    "Are there tasks that touch multiple unrelated areas?",
-                    "Would a new engineer understand and start each task within two minutes?"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Batch Completeness Audit",
-                evaluationPoints: [
-                    "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 batches?",
-                    "Does the Execution Posture match the dependency graph and stop risky parallelism?"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Five-Minute Budget + No-Placeholders Audit",
-                evaluationPoints: [
-                    "Does every internal TDD step carry a bounded 2-to-5-minute estimate or checkbox-level step? Whole units may be larger when feature-atomic.",
-                    "Are all file paths, test commands, verification commands, and expected evidence copy-pasteable/specific as written — no `TODO`, `TBD`, `FIXME`, `<fill-in>`, `<your-*-here>`, `xxx`, bare `run tests`, 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 batch 0, rather than hidden behind a large estimate?"
-                ],
-                stopGate: true
-            }
-        ]
-    },
-    next: "tdd",
-};

package/dist/content/stages/review.d.ts

@@ -1,2 +0,0 @@
-import type { StageSchemaInput } from "./schema-types.js";
-export declare const REVIEW: StageSchemaInput;

package/dist/content/stages/review.js

@@ -1,240 +0,0 @@
-import { decisionProtocolInstruction, STRUCTURED_ASK_TOOL_LIST_REVIEW, structuredAskSingleChoiceInstruction } from "../decision-protocol.js";
-// ---------------------------------------------------------------------------
-// REVIEW — reference: superpowers code-review + gstack /review
-// ---------------------------------------------------------------------------
-export const REVIEW = {
-    schemaShape: "v2",
-    stage: "review",
-    complexityTier: "standard",
-    skillFolder: "review",
-    skillName: "review",
-    skillDescription: "Two-layer review stage: spec compliance first, then code quality and production readiness. Section-by-section with severity discipline.",
-    philosophy: {
-        hardGate: "Do NOT ship, merge, or release until both review layers complete with an explicit verdict. No exceptions for urgency. Critical blockers MUST be resolved before handoff.",
-        ironLaw: "NO SHIP VERDICT UNTIL BOTH REVIEW LAYERS COMPLETE AND EVERY CRITICAL IS RESOLVED OR EXPLICITLY ACCEPTED.",
-        purpose: "Validate that implementation matches spec and meets quality/security/performance bar through structured two-layer review.",
-        whenToUse: [
-            "After TDD stage completes",
-            "Before any ship action",
-            "When release risk must be assessed explicitly"
-        ],
-        whenNotToUse: [
-            "There is no implementation diff to review",
-            "TDD stage evidence is missing or stale"
-        ],
-        commonRationalizations: [
-            "Single generic review without layered structure",
-            "No severity classification",
-            "Shipping with open criticals",
-            "Batching multiple findings into one report without individual resolution",
-            "Skipping Layer 2 sections because Layer 1 passed"
-        ]
-    },
-    executionModel: {
-        checklist: [
-            "**MANDATE — controller never authors review findings.** The controller orchestrates; `reviewer` and `security-reviewer` are mandatory delegated workers that produce the actual findings, lens coverage, and verdict input. **Dispatch them in parallel as harness Task subagents in a single controller message** — one Task per lens. Do NOT type `## Layer 1 Findings`, `## Layer 2 Findings`, `## Lens Coverage`, or `## Final Verdict` content into `07-review.md` yourself as a substitute for delegating. The controller's only writes to the review artifact are: structural scaffolding (section headings if the template did not pre-render them) and the reconciled multi-specialist verdict block AFTER all reviewer Tasks return.",
-            "**Boundary with TDD (do NOT re-classify slice findings).** `tdd.Per-Slice Review` OWNS severity-classified findings WITHIN a single slice (correctness, edge cases, regression for that slice). `review` OWNS whole-diff Layer 1 (spec compliance) plus Layer 2 (cross-slice integration findings, security sweep, dependency/version audit, observability). When the same finding ID appears in both `06-tdd.md > Per-Slice Review` and `07-review.md` / `07-review-army.json`, the severity/disposition MUST match — the cross-artifact-duplication linter blocks otherwise.",
-            "Diff Scope — Run `git diff` against base branch. If no diff, exit early with APPROVED (no changes to review). Scope the review to changed files unless blast-radius analysis requires wider inspection.",
-            "Change-Size Check — ~100 lines = normal. ~300 lines = consider splitting. ~1000+ lines = strongly recommend stacked PRs. Flag large diffs to the user.",
-            "Risk-Based Second Opinion — compute changed-line count, files-touched count, and trust-boundary movement. Dispatch an adversarial reviewer only when trust boundaries changed, Critical/Important ambiguity remains, or the diff is both large and high-risk; otherwise record `not triggered`.",
-            "Load upstream evidence — read TDD artifact (RED + GREEN + REFACTOR + per-slice reviews), spec, design (architecture lens carry-forward), and the active track's upstream source items.",
-            "Confirm spec acceptance criteria and reproduction slices are covered directly in the review artifact evidence.",
-            "Layer 1: Spec Compliance — check every acceptance criterion against implementation. Verdict: pass/fail per criterion.",
-            "Review Evidence Scope — record base/head, files inspected, changed-file coverage, diagnostics run, dependency/version audit when relevant, and any files intentionally not inspected with explicit reason.",
-            "**Layer 2: Cross-slice integration findings — only findings that span >1 slice OR are not surfaced by per-slice tdd reviews.** Carry-forward: cite tdd per-slice review IDs already accepted; do not re-classify them. New categories owned by review Layer 2: cross-slice correctness, dependency/version audit, security sweep, observability gaps, external-safety. **Performance and architecture findings come from the design lens (cite `03-design-<slug>.md` Performance Budget / Architecture Decision Record); they are NOT re-derived in review.** Every finding uses file:line; if impossible, include an explicit no-line reason.",
-            "Security sweep — mandatory dedicated security-reviewer pass across diff + touched modules. A zero-finding pass must include `NO_CHANGE_ATTESTATION` or `NO_SECURITY_IMPACT` with rationale and inspected surfaces.",
-            "Incoming Feedback Intake — when human reviewer comments, bot findings, or CI annotations exist, keep a per-comment disposition queue and mirror outcomes into `07-review.md` + `07-review-army.json` before final verdict.",
-            "Structured Review reconciliation — normalize findings into `07-review-army.json`, dedup by fingerprint, and mark multi-specialist confirmations when multiple lenses agree.",
-            "Meta-Review — Were tests/diagnostics actually run? Do test names match what they test? Are there real assertions? Is the dependency/version surface unchanged or audited?",
-            "Classify findings — Critical (blocks ship), Important (should fix), Suggestion (optional improvement).",
-            "Victory Detector — before verdict, confirm Layer 1, Layer 2, security sweep, structured findings, acceptance/reproduction coverage evidence, and unresolved-critical status are complete; otherwise iterate findings or route back to TDD.",
-            "Produce verdict — APPROVED, APPROVED_WITH_CONCERNS, or BLOCKED.",
-            "If verdict is BLOCKED, emit remediation route token `ROUTE_BACK_TO_TDD`, include the managed command `npx cclaw-cli internal rewind tdd \"review_blocked_by_critical <finding-ids>\"`, list the critical finding IDs and required TDD evidence to repair, and satisfy the special transition guard `review_verdict_blocked` instead of `review_criticals_resolved`. After TDD rework, clear the stale marker with `npx cclaw-cli internal rewind --ack tdd` before `/cc`."
-        ],
-        interactionProtocol: [
-            "Run Layer 1 (spec compliance) completely before starting Layer 2.",
-            "In each review section, present findings ONE AT A TIME. Do NOT batch.",
-            "Classify every finding as Critical, Important, or Suggestion.",
-            decisionProtocolInstruction("each Critical finding", "present resolution options (A/B/C) with trade-offs, and mark one as (recommended)", "recommend the option that fully closes the finding with no carry-over risk and the smallest blast radius", STRUCTURED_ASK_TOOL_LIST_REVIEW),
-            "Resolve all critical blockers before ship. If verdict is BLOCKED, do not pass `review_criticals_resolved`; pass only the remediation route gate `review_verdict_blocked` when routing back to TDD.",
-            "When verdict is BLOCKED, do not end with a passive stop: explicitly route remediation to TDD via `ROUTE_BACK_TO_TDD`, point to `npx cclaw-cli internal rewind tdd` with the blocking IDs, and tell the operator to ack the stale TDD marker only after rework is complete.",
-            structuredAskSingleChoiceInstruction("final verdict", "verdict (APPROVED / APPROVED_WITH_CONCERNS / BLOCKED)"),
-            "**STOP.** Do NOT proceed to ship until the user provides an explicit verdict.",
-            "Investigation discipline: follow the shared `## Investigation Discipline` block — `Changed-File Coverage` and Layer 2 findings cite `path:line`; delegate `reviewer`/`security-reviewer` with paths and refs, never with pasted file contents.",
-            "Behavior anchor: see the shared `## Behavior anchor` block in this skill — the bad/good pair anchors that `Layer 2 Findings` surface defects, not drive-by refactors."
-        ],
-        process: [
-            "Layer 1: check acceptance criteria and requirement coverage.",
-            "Layer 2: record integrated findings tagged correctness/security/performance/architecture/external-safety.",
-            "Security-reviewer: run mandatory security sweep or no-change attestation.",
-            "Reconcile structured findings into `.cclaw/artifacts/07-review-army.json` (dedup + confidence + conflict notes + source tags from spec/correctness/security/performance/architecture/external-safety passes).",
-            "Classify and prioritize all findings.",
-            "Write review report artifact with explicit verdict.",
-            "If verdict is BLOCKED, include the remediation route token `ROUTE_BACK_TO_TDD`, the managed rewind command payload, and the follow-up ack command after TDD rework."
-        ],
-        requiredGates: [
-            { id: "review_layer1_spec_compliance", description: "Spec compliance check completed with per-criterion verdict." },
-            { id: "review_layer2_security", description: "Security review completed." },
-            { id: "review_layer_coverage_complete", description: "Layer coverage map in 07-review-army.json confirms spec/correctness/security/performance/architecture/external-safety tags were considered." },
-            { id: "review_criticals_resolved", description: "Normal APPROVED or APPROVED_WITH_CONCERNS path only: no unresolved critical blockers remain. BLOCKED routes use review_verdict_blocked instead." },
-            { id: "review_army_json_valid", description: "07-review-army.json passes schema validation (validateReviewArmy)." }
-        ],
-        requiredEvidence: [
-            "Artifact written to `.cclaw/artifacts/07-review.md`.",
-            "Artifact written to `.cclaw/artifacts/07-review-army.json`.",
-            "Acceptance/reproduction coverage evidence recorded in the review artifact (AC and source-item/slice coverage snapshot).",
-            "Layer 1 verdict captured with per-criterion pass/fail.",
-            "Review Evidence Scope lists files inspected, changed-file coverage, diagnostics run, and omitted files with explicit reason.",
-            "Layer 2 cross-slice findings recorded for: cross-slice correctness, security sweep, dependency/version audit, observability, external-safety. Performance/architecture come from design lens carry-forward (`03-design-<slug>.md`) — do NOT re-derive them.",
-            "Per-slice tdd review findings cited (not re-classified): each `06-tdd.md > Per-Slice Review` ID accepted in review must keep matching severity/disposition (cross-artifact-duplication linter enforces this).",
-            "Every finding cites `file:line`, or an explicit no-line reason is recorded.",
-            "No-finding attestation is explicit when no issues are found.",
-            "Dependency/version audit is recorded when manifests, lockfiles, generated clients, CI, runtime config, or external APIs are relevant.",
-            "Severity log includes critical/important/suggestion buckets.",
-            "Victory Detector recorded: Layer 1, Layer 2, security sweep, structured findings, acceptance/reproduction coverage evidence, and unresolved-critical status are complete, or BLOCKED route is explicit.",
-            "Explicit final verdict: APPROVED, APPROVED_WITH_CONCERNS, or BLOCKED.",
-            "Fresh verification command discovery recorded before ship handoff, with command and result captured in review evidence.",
-            "If BLOCKED: include explicit remediation route (`ROUTE_BACK_TO_TDD`) with blocking finding IDs, managed rewind command, and post-rework ack instruction."
-        ],
-        inputs: ["implementation diff", "upstream artifacts", "test/build evidence"],
-        requiredContext: ["spec criteria", "tdd artifact", "rulebook constraints"],
-        blockers: [
-            "layer 1 failed",
-            "critical findings unresolved",
-            "missing regression evidence"
-        ],
-        exitCriteria: [
-            "both layers completed",
-            "all review sections evaluated",
-            "critical blockers resolved for APPROVED paths, or BLOCKED routes through review_verdict_blocked",
-            "ship readiness or remediation route explicitly stated"
-        ],
-        platformNotes: [
-            "When citing file locations in findings, use repo-relative forward-slash paths with a line number (`src/foo/bar.ts:42`). Avoid IDE-generated hyperlinks that embed absolute machine-specific paths.",
-            "Line-range or diff-range references must match `git diff --unified=0` output format so reviewers on any OS can reproduce the range locally without GUI tooling.",
-            "Commands in remediation suggestions must be portable (`npm run lint`, `pytest -x path/to/test`) — if a platform-specific command is required, tag the note explicitly (`# PowerShell only`, `# macOS only`)."
-        ]
-    },
-    artifactRules: {
-        artifactFile: "07-review.md",
-        completionStatus: ["APPROVED", "APPROVED_WITH_CONCERNS", "BLOCKED"],
-        crossStageTrace: {
-            readsFrom: [".cclaw/artifacts/06-tdd.md", ".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/05-plan.md"],
-            writesTo: [".cclaw/artifacts/07-review.md", ".cclaw/artifacts/07-review-army.json"],
-            traceabilityRule: "Review verdict must reference specific spec criteria and TDD evidence. Downstream ship stage must reference review verdict."
-        },
-        artifactValidation: [
-            { section: "Upstream Handoff", required: false, validationRule: "Summarizes spec/plan/tdd decisions, constraints, open questions, and explicit drift before review verdicts." },
-            { section: "Review Evidence Scope", required: true, validationRule: "Base/head, files inspected, changed-file coverage, diagnostics run, omitted files with reason, and reviewer/security-reviewer delegation evidence." },
-            { section: "Changed-File Coverage", required: true, validationRule: "Each changed file is covered, intentionally omitted with no-impact reason, or linked to a broader inspected module." },
-            { section: "Layer 1 Verdict", required: true, validationRule: "Per-criterion pass/fail with references." },
-            { section: "Layer 2 Findings", required: false, validationRule: "Each finding has severity, category, file:line or explicit no-line reason, description, and resolution status. Owned categories are cross-slice correctness, security, dependency/version, observability, and external-safety. Performance and architecture findings appear here only as carry-forward citations to `03-design-<slug>.md` (Performance Budget, ADR) — they are NOT re-derived. If there are no findings, include a no-finding attestation." },
-            { section: "Lens Coverage", required: true, validationRule: "Reviewer must report inline lens outcomes: Performance/Compatibility/Observability as `NO_IMPACT` or `FOUND_<n>`, plus `Security: routed to security-reviewer`." },
-            { section: "Security Sweep Attestation", required: false, validationRule: "Dedicated security-reviewer result: findings or `NO_CHANGE_ATTESTATION` / `NO_SECURITY_IMPACT` with inspected surfaces and rationale." },
-            { section: "Dependency & Version Audit", required: false, validationRule: "Required when manifests, lockfiles, generated clients, CI, runtime config, or external APIs changed; otherwise record no-impact rationale." },
-            { section: "Review Findings Contract", required: true, validationRule: "Structured findings in 07-review-army.json include id/severity/confidence/fingerprint/reportedBy/status and source tags from {spec, correctness, security, performance, architecture, external-safety} with dedup reconciliation summary." },
-            { section: "Review Readiness Snapshot", required: false, validationRule: "Optional compact summary: completed checks, delegation-log status, staleness signal, open critical blockers, ship recommendation, and Victory Detector pass/fail." },
-            { section: "Completeness Snapshot", required: false, validationRule: "Optional compact coverage summary for AC coverage, source item coverage, test-slice coverage, and adversarial-review status when triggered." },
-            { section: "Incoming Feedback Queue", required: false, validationRule: "When external review feedback exists, include a queue summary with per-item disposition (resolved / accepted-risk / rejected-with-evidence) and evidence refs." },
-            { section: "Coverage Check", required: false, validationRule: "Records AC/source-item/slice coverage status with explicit no-orphan rationale and evidence references." },
-            { section: "Blocked Route", required: false, validationRule: "When Final Verdict is BLOCKED: includes `ROUTE_BACK_TO_TDD`, rewind target `tdd`, and blocked finding IDs." },
-            { section: "Severity Summary", required: true, validationRule: "Per-severity count lines for critical, important, and suggestion buckets." },
-            { section: "Final Verdict", required: true, validationRule: "Exactly one of: APPROVED, APPROVED_WITH_CONCERNS, BLOCKED." }
-        ]
-    },
-    reviewLens: {
-        outputs: ["review verdict", "severity-indexed findings", "reconciled structured findings", "ship readiness decision"],
-        reviewSections: [
-            {
-                title: "Layer 1: Spec Compliance",
-                evaluationPoints: [
-                    "For each acceptance criterion: does the implementation satisfy it?",
-                    "Are there spec requirements with no corresponding implementation?",
-                    "Are there implementations with no corresponding spec requirement (scope creep)?",
-                    "Is every edge case from the spec handled?"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Layer 2: Cross-slice Integration Findings",
-                evaluationPoints: [
-                    "Cross-slice correctness: logic errors and boundary violations that span >1 slice",
-                    "Race conditions and concurrency issues across slice boundaries",
-                    "Null/undefined handling in shared paths",
-                    "Error propagation and recovery across module seams (single-slice findings stay in tdd Per-Slice Review)"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Security Sweep",
-                evaluationPoints: [
-                    "Input validation completeness",
-                    "Authorization boundary enforcement",
-                    "Secrets exposure risk",
-                    "Injection vector assessment"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Performance Lens: Carry-forward from Design",
-                evaluationPoints: [
-                    "Cite `03-design-<slug>.md > Performance Budget` per critical path",
-                    "Surface DRIFT only when implementation diff measurably violates a budgeted threshold; do NOT re-derive performance findings from scratch",
-                    "Hot path / N+1 / caching observations belong here only when they cross slice boundaries and were not flagged by tdd Per-Slice Review"
-                ],
-                stopGate: false
-            },
-            {
-                title: "Architecture Lens: Carry-forward from Design",
-                evaluationPoints: [
-                    "Cite `03-design-<slug>.md > Architecture Decision Record (ADR)` and `Engineering Lock`",
-                    "Surface DRIFT only when the implementation departs from the locked architecture; do NOT re-derive boundary/coupling/interface analysis from scratch",
-                    "Cross-slice architectural drift findings use `file:line` plus the violated ADR ID"
-                ],
-                stopGate: false
-            },
-            {
-                title: "Specialist Lens: External Safety Checklist",
-                evaluationPoints: [
-                    "SQL/database: parameterized queries, no raw string interpolation, migration safety",
-                    "Concurrency: race conditions in shared state, lock ordering, timeout handling",
-                    "Secrets: no hardcoded tokens, no secrets in logs, env vars for sensitive config",
-                    "Enum/constant completeness: grep for sibling values OUTSIDE the diff — are all cases handled?",
-                    "Trust boundaries: if LLM/AI output is used, is it validated before acting on it?"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Specialist Lens: Data & Migration Safety",
-                evaluationPoints: [
-                    "Schema/data migrations are reversible and include backfill/rollback strategy",
-                    "Idempotency expectations are explicit for retryable flows",
-                    "Data-loss scenarios (truncate/overwrite/drop) are guarded by checks or dry-runs",
-                    "Boundary contracts (API/schema/event payload) maintain backward compatibility or are versioned"
-                ],
-                stopGate: false
-            },
-            {
-                title: "Specialist Lens: Developer Experience",
-                evaluationPoints: [
-                    "New behavior includes discoverable docs/usage notes where needed",
-                    "Error messages are actionable for on-call and local debugging",
-                    "Default configuration remains safe and unsurprising",
-                    "Change footprint stays minimal and avoids hidden coupling"
-                ],
-                stopGate: false
-            },
-            {
-                title: "Meta-Review: Verify the Verification",
-                evaluationPoints: [
-                    "Were tests actually run (not just assumed to pass)?",
-                    "Do the test names match what they actually test?",
-                    "Is there test coverage for the specific changes in this diff?",
-                    "Are there assertions, or do tests just run without checking results?"
-                ],
-                stopGate: false
-            }
-        ]
-    },
-    next: "ship",
-};