cclaw-cli 0.14.0 → 0.15.1

package/dist/content/stages/spec.js

@@ -0,0 +1,136 @@
+// ---------------------------------------------------------------------------
+// SPEC
+// ---------------------------------------------------------------------------
+export const SPEC = {
+    stage: "spec",
+    skillFolder: "specification-authoring",
+    skillName: "specification-authoring",
+    skillDescription: "Specification stage. Produce measurable, testable requirements without ambiguity.",
+    hardGate: "Do NOT plan tasks or write implementation code. This stage produces a specification document only. Every requirement must be expressed in observable, testable terms.",
+    ironLaw: "EVERY ACCEPTANCE CRITERION MUST BE OBSERVABLE AND TESTABLE — OR IT DOES NOT EXIST.",
+    purpose: "Create a testable specification aligned with approved design and constraints.",
+    whenToUse: [
+        "After design lock",
+        "Before planning and implementation",
+        "When acceptance criteria must be measurable"
+    ],
+    whenNotToUse: [
+        "Design decisions are still unresolved or disputed",
+        "The task is implementation-only cleanup with unchanged behavior",
+        "You still need to challenge scope rather than author requirements"
+    ],
+    checklist: [
+        "Read upstream — load design artifact and scope contract. Cross-reference architecture decisions.",
+        "Define measurable acceptance criteria — each criterion must be observable and falsifiable. No vague adjectives.",
+        "Capture edge cases — for each criterion, define at least one boundary condition and one error condition.",
+        "Document constraints and assumptions — regulatory, system, integration, and performance boundaries. Surface implicit assumptions explicitly.",
+        "Confirm testability — for each acceptance criterion, describe the test that would prove it. If untestable, rewrite the criterion.",
+        "Write spec artifact and request user approval — wait for explicit confirmation before proceeding."
+    ],
+    interactionProtocol: [
+        "Express each requirement in observable terms.",
+        "Resolve ambiguity before moving to plan. Challenge vague language.",
+        "Capture assumptions explicitly, not implicitly.",
+        "Require user confirmation on the written spec. **STOP.** Do NOT proceed to plan until user approves.",
+        "For each criterion, ask: how would you test this? If the answer is unclear, rewrite.",
+        "When encountering ambiguity, classify it before acting: (A) ask user for missing info, (B) enumerate interpretations and pick one with justification, (C) propose hypothesis with validation path. Do NOT silently resolve ambiguity."
+    ],
+    process: [
+        "Define measurable acceptance criteria.",
+        "Capture constraints, assumptions, and edge cases.",
+        "Build testability map: criterion -> test description.",
+        "Confirm testability for each criterion.",
+        "Write spec artifact and request approval."
+    ],
+    requiredGates: [
+        { id: "spec_acceptance_measurable", description: "Acceptance criteria are measurable and observable." },
+        { id: "spec_edge_cases_documented", description: "Boundary and error conditions are defined for each criterion." },
+        { id: "spec_constraints_documented", description: "Constraints and assumptions are explicit." },
+        { id: "spec_testability_confirmed", description: "Each criterion has a described test method." },
+        { id: "spec_user_approved", description: "User approved the final written spec." }
+    ],
+    requiredEvidence: [
+        "Artifact written to `.cclaw/artifacts/04-spec.md`.",
+        "Each acceptance criterion maps to a testable outcome.",
+        "Edge cases documented per criterion.",
+        "Approval marker captured in artifact."
+    ],
+    inputs: ["design artifact", "business constraints", "quality requirements"],
+    requiredContext: [
+        "design lock baseline",
+        "regulatory or system boundaries",
+        "integration constraints"
+    ],
+    outputs: [
+        "measurable specification",
+        "acceptance-to-testability map",
+        "approved spec artifact"
+    ],
+    blockers: [
+        "non-measurable criteria",
+        "constraints missing",
+        "open ambiguities remain"
+    ],
+    exitCriteria: [
+        "spec approved by user",
+        "required gates marked satisfied",
+        "plan-ready acceptance mapping exists",
+        "testability confirmed for all criteria"
+    ],
+    antiPatterns: [
+        "High-level goals without measurable outcomes",
+        "Implicit assumptions",
+        "Proceeding to plan before approval",
+        "Using vague adjectives (fast, intuitive, robust) without thresholds"
+    ],
+    redFlags: [
+        "Criteria use vague language (fast, intuitive, robust) without thresholds",
+        "No explicit assumptions section",
+        "No approval record",
+        "No testability mapping",
+        "Edge cases missing or deferred"
+    ],
+    policyNeedles: ["Acceptance Criteria", "Constraints", "Testability", "approved spec", "Edge Cases"],
+    artifactFile: "04-spec.md",
+    next: "plan",
+    reviewSections: [
+        {
+            title: "Acceptance Criteria Audit",
+            evaluationPoints: [
+                "Is every criterion observable (can you point to evidence of pass/fail)?",
+                "Is every criterion measurable (numeric threshold or boolean outcome)?",
+                "Is every criterion falsifiable (can you describe what failure looks like)?",
+                "Does every criterion trace to a design decision (Design Decision Ref)?",
+                "Are there any vague adjectives (fast, intuitive, robust) without thresholds?"
+            ],
+            stopGate: true
+        },
+        {
+            title: "Testability Audit",
+            evaluationPoints: [
+                "Does every criterion have a concrete test description in the Testability Map?",
+                "Does every test specify a verification approach (unit, integration, e2e, manual)?",
+                "Does every test include a runnable command or manual steps?",
+                "Are edge cases (boundary + error) defined for every criterion?",
+                "Can you run every verification command right now and get a meaningful result?"
+            ],
+            stopGate: true
+        }
+    ],
+    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
+    crossStageTrace: {
+        readsFrom: [".cclaw/artifacts/03-design.md", ".cclaw/artifacts/02-scope.md"],
+        writesTo: [".cclaw/artifacts/04-spec.md"],
+        traceabilityRule: "Every acceptance criterion must trace to a design decision. Every downstream plan task must trace to a spec criterion."
+    },
+    artifactValidation: [
+        { section: "Acceptance Criteria", required: true, validationRule: "Each criterion is observable, measurable, and falsifiable. Table must include a Requirement Ref column linking to R# IDs in 02-scope.md and a Design Decision Ref column tracing back to design artifact. AC IDs (AC-1, AC-2…) are stable across revisions — dropped ACs stay with Priority `DROPPED`." },
+        { section: "Edge Cases", required: true, validationRule: "At least one boundary and one error condition per criterion." },
+        { section: "Constraints and Assumptions", required: true, validationRule: "All implicit assumptions surfaced. Constraints have sources." },
+        { section: "Testability Map", required: true, validationRule: "Each criterion maps to a concrete test description with verification approach (unit, integration, e2e, manual) and command or manual steps." },
+        { section: "Vague to Fixed", required: false, validationRule: "If present: table with original vague wording and rewritten observable/testable version for each ambiguous requirement." },
+        { section: "Non-Functional Requirements", required: false, validationRule: "If present: performance thresholds, security constraints, scalability limits, reliability targets with measurable values." },
+        { section: "Interface Contracts", required: false, validationRule: "If present: for each module boundary list produces (outputs) and consumes (inputs) with data types." },
+        { section: "Approval", required: true, validationRule: "Explicit user approval marker present." }
+    ]
+};

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

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

package/dist/content/stages/tdd.js

@@ -0,0 +1,184 @@
+// ---------------------------------------------------------------------------
+// TDD — RED → GREEN → REFACTOR cycle (merged test + build)
+// ---------------------------------------------------------------------------
+export const TDD = {
+    stage: "tdd",
+    skillFolder: "test-driven-development",
+    skillName: "test-driven-development",
+    skillDescription: "Full TDD cycle: RED (failing tests), GREEN (minimal implementation), REFACTOR (cleanup). One plan slice at a time with strict traceability.",
+    hardGate: "Do NOT merge, ship, or skip review. Follow RED → GREEN → REFACTOR strictly for each plan slice. Do NOT write implementation code before RED tests exist. Do NOT skip the REFACTOR step.",
+    ironLaw: "NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST — THE RED FAILURE IS THE SPEC.",
+    purpose: "Implement features through the TDD cycle: write failing tests, make them pass with minimal code, then refactor.",
+    whenToUse: [
+        "After plan confirmation",
+        "For every behavior change in scope",
+        "Before review stage"
+    ],
+    whenNotToUse: [
+        "Plan approval is still pending WAIT_FOR_CONFIRM",
+        "The change is docs-only and does not alter behavior",
+        "The stage intent is review/ship sign-off rather than implementation"
+    ],
+    checklist: [
+        "Select plan slice — pick one task from the plan. Do not batch multiple tasks.",
+        "Map to acceptance criterion — identify the specific spec criterion this test proves.",
+        "RED: Write behavior-focused test — test the expected behavior, not implementation details. Tests MUST fail.",
+        "RED: Capture failure output — copy the exact failure output as RED evidence. Record in artifact.",
+        "GREEN: Minimal implementation — write the smallest code change that makes the RED tests pass. No extra features.",
+        "GREEN: Run full suite — execute ALL tests, not just the ones you wrote. The full suite must be GREEN.",
+        "GREEN: Verify no regressions — if any existing test breaks, fix the regression before proceeding.",
+        "REFACTOR: Improve code quality — without changing behavior. Document what you changed and why.",
+        "Record evidence — capture RED failure, GREEN output, and REFACTOR notes in the TDD artifact.",
+        "Annotate traceability — link to plan task ID and spec criterion.",
+        "Repeat for each slice — return to step 1 for the next plan slice."
+    ],
+    interactionProtocol: [
+        "Pick one planned slice at a time.",
+        "Write behavior-focused tests before changing implementation (RED).",
+        "Capture and store failing output as RED evidence.",
+        "Apply minimal change to satisfy RED tests (GREEN).",
+        "Run full suite, not partial checks, for GREEN validation.",
+        "Refactor without changing behavior and document rationale (REFACTOR).",
+        "Stop if regressions appear and fix before proceeding.",
+        "If a test passes unexpectedly, investigate: does the behavior already exist, or is the test wrong?"
+    ],
+    process: [
+        "Select slice and map to acceptance criterion.",
+        "Write test(s) that fail for expected reason (RED).",
+        "Run tests and capture failure output.",
+        "Implement smallest change needed for GREEN.",
+        "Run full tests and build checks.",
+        "Perform refactor pass preserving behavior.",
+        "Record RED, GREEN, and REFACTOR evidence in artifact.",
+        "Annotate traceability to plan task and spec criterion."
+    ],
+    requiredGates: [
+        { id: "tdd_red_test_written", description: "Failing tests exist before implementation changes." },
+        { id: "tdd_red_failure_captured", description: "Failure output is captured as evidence." },
+        { id: "tdd_trace_to_acceptance", description: "RED tests trace to explicit acceptance criteria." },
+        { id: "tdd_red_failure_reason_verified", description: "Failure is for the expected reason, not an unrelated error." },
+        { id: "tdd_green_full_suite", description: "Full relevant suite passes in GREEN state." },
+        { id: "tdd_refactor_completed", description: "Refactor pass completed with behavior preservation verified." },
+        { id: "tdd_refactor_notes_written", description: "Refactor decisions and outcomes are documented." },
+        { id: "tdd_traceable_to_plan", description: "Change traceability to plan slice is explicit." }
+    ],
+    requiredEvidence: [
+        "Artifact updated at `.cclaw/artifacts/06-tdd.md` with RED, GREEN, and REFACTOR sections.",
+        "Failing command output captured (RED).",
+        "Full test/build output recorded (GREEN).",
+        "Acceptance mapping documented.",
+        "Failure reason analysis recorded.",
+        "Refactor rationale captured.",
+        "Traceability to task identifier is documented."
+    ],
+    inputs: ["approved plan slice", "spec acceptance criterion", "test harness configuration", "coding standards and constraints"],
+    requiredContext: ["plan artifact", "spec artifact", "existing test patterns"],
+    outputs: ["failing test set", "passing implementation", "refactor evidence", "review-ready change set"],
+    blockers: [
+        "tests pass before behavior change (RED failure missing)",
+        "full suite not green",
+        "behavior changed during refactor",
+        "no evidence recorded"
+    ],
+    exitCriteria: [
+        "RED evidence exists and is traceable",
+        "GREEN evidence captured with full suite pass",
+        "REFACTOR evidence captured",
+        "required gates marked satisfied",
+        "traceability annotated"
+    ],
+    antiPatterns: [
+        "Writing code before failing test",
+        "Asserting implementation details instead of behavior",
+        "Big-bang implementation across multiple slices",
+        "Partial test runs presented as GREEN",
+        "Skipping evidence capture",
+        "Undocumented refactor changes",
+        "Adding features beyond what RED tests require"
+    ],
+    redFlags: [
+        "No failing test output (RED missing)",
+        "Implementation edits appear before RED evidence",
+        "No full-suite GREEN evidence",
+        "No refactor notes",
+        "Multiple tasks implemented in one pass without justification",
+        "Files changed outside current slice scope"
+    ],
+    policyNeedles: ["RED", "GREEN", "REFACTOR", "failing test", "full test suite", "acceptance criteria", "traceable to plan slice"],
+    artifactFile: "06-tdd.md",
+    next: "review",
+    reviewSections: [
+        {
+            title: "RED Evidence Audit",
+            evaluationPoints: [
+                "Does every slice have a captured failing test output?",
+                "Does each failure reason match the expected missing behavior (not a typo or config error)?",
+                "Were tests written BEFORE any production code for that slice?",
+                "Does each RED test assert observable behavior, not implementation details?",
+                "Is there a test for each acceptance criterion mapped in the plan?"
+            ],
+            stopGate: true
+        },
+        {
+            title: "GREEN/REFACTOR Audit",
+            evaluationPoints: [
+                "Does GREEN evidence show a FULL suite pass (not partial)?",
+                "Is the GREEN implementation minimal — no features beyond what RED tests require?",
+                "Does the REFACTOR step preserve all existing behavior (no new failures)?",
+                "Are REFACTOR notes documented with rationale?",
+                "Is traceability complete: every change links to plan task ID and spec criterion?"
+            ],
+            stopGate: true
+        },
+        {
+            title: "Test Pyramid + Size Audit",
+            evaluationPoints: [
+                "Is the tests-added count skewed toward Small (unit) tests, with Medium and Large used only when a real boundary justifies the cost?",
+                "Does every newly added test declare a size class (Small / Medium / Large) — either inline in the test file or in the TDD artifact table?",
+                "Are Large tests reserved for genuine end-to-end user journeys (not substitutes for unit coverage)?",
+                "Has the slice avoided using Medium/Large tests to paper over testability problems that should be fixed at the design layer?"
+            ],
+            stopGate: false
+        },
+        {
+            title: "Prove-It Reproduction (bug-fix slices)",
+            evaluationPoints: [
+                "Does the artifact identify this slice as a bug fix, and if so, include a reproduction test checked in alongside the fix?",
+                "Is there captured RED evidence from running the reproduction WITHOUT the fix applied?",
+                "Is there captured GREEN evidence from the same reproduction AFTER the fix was applied?",
+                "Is there a note confirming the reproduction test fails again if the fix is reverted (or equivalent evidence that the test is actually pinned to this fix)?"
+            ],
+            stopGate: false
+        },
+        {
+            title: "State-over-Interaction + Beyoncé Coverage",
+            evaluationPoints: [
+                "Do assertions target observable state (return values, persisted data, HTTP responses, logs) rather than which internal helpers were called?",
+                "Are mocks/spies used only at true trust boundaries (network, filesystem, time, external services), not for module-internal collaborators?",
+                "For every public surface touched in this slice (exported API, CLI flag, config key, env var, exit code, schema field) — does at least one test observe it?",
+                "If a bug or review finding revealed an uncovered surface, was a test added alongside the fix, not just the code change?",
+                "Are interaction-style assertions (e.g. `toHaveBeenCalledWith` without a state assertion) justified by an explicit boundary comment, or flagged for follow-up?"
+            ],
+            stopGate: false
+        }
+    ],
+    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
+    crossStageTrace: {
+        readsFrom: [".cclaw/artifacts/05-plan.md", ".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/03-design.md"],
+        writesTo: [".cclaw/artifacts/06-tdd.md"],
+        traceabilityRule: "Every RED test traces to a plan task. Every GREEN change traces to a RED test. Every plan task traces to a spec criterion. Design decisions inform test strategy. Evidence chain must be unbroken."
+    },
+    artifactValidation: [
+        { section: "RED Evidence", required: true, validationRule: "Failing test output captured per slice." },
+        { section: "Acceptance Mapping", required: true, validationRule: "Each RED test links to a plan task and spec criterion." },
+        { section: "Failure Analysis", required: true, validationRule: "Failure reason matches expected missing behavior." },
+        { section: "GREEN Evidence", required: true, validationRule: "Full suite pass output captured." },
+        { section: "REFACTOR Notes", required: true, validationRule: "What changed, why, behavior preservation confirmed." },
+        { section: "Traceability", required: true, validationRule: "Plan task ID and spec criterion linked." },
+        { section: "Verification Ladder", required: false, validationRule: "If present: per-slice verification tier (static, command, behavioral, human) with evidence for highest tier reached." },
+        { section: "Coverage Targets", required: false, validationRule: "If present: per-module or per-code-type coverage thresholds with current values and measurement commands." },
+        { 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
+};

package/dist/content/status-command.d.ts

@@ -1,9 +1,9 @@
 /**
- * Command contract for /cc-status — a read-only snapshot command.
+ * Command contract for /cc-view status — a read-only snapshot command.
  * Does not mutate state. Always safe to run.
  */
 export declare function statusCommandContract(): string;
 /**
- * Skill body for /cc-status — read-only status snapshot.
+ * Skill body for /cc-view status — read-only status snapshot.
  */
 export declare function statusCommandSkillMarkdown(): string;

package/dist/content/status-command.js

@@ -23,13 +23,13 @@ function snapshotPath() {
     return `${RUNTIME_ROOT}/state/flow-state.snapshot.json`;
 }
 /**
- * Command contract for /cc-status — a read-only snapshot command.
+ * Command contract for /cc-view status — a read-only snapshot command.
  * Does not mutate state. Always safe to run.
  */
 export function statusCommandContract() {
     const flowPath = flowStatePath();
     const delegationPath = delegationLogPath();
-    return `# /cc-status
+    return `# /cc-view status
 
 ## Purpose
 
@@ -41,10 +41,10 @@ time to answer "where are we?" without advancing the flow.
 
 ## HARD-GATE
 
-- **Do not** use \`/cc-status\` output to infer gate completion for decisions — cite
+- **Do not** use \`/cc-view status\` output to infer gate completion for decisions — cite
   artifact evidence via \`/cc-next\` when advancing.
 - **Do not** mutate \`${flowPath}\` or delegation log from this command.
-- **Do not** rewrite \`${snapshotPath()}\` from this command (use \`/cc-diff\`).
+- **Do not** rewrite \`${snapshotPath()}\` from this command (use \`/cc-view diff\`).
 
 ## Algorithm
 
@@ -59,7 +59,7 @@ time to answer "where are we?" without advancing the flow.
    - Compute the duration as \`now - signalTimestamp\` and render compactly: \`<X>m\`, \`<X>h<Y>m\`, or \`<X>d<Y>h\`.
    - If no signal exists, render \`(unknown)\`.
 5. Optionally read **\`${snapshotPath()}\`** to compute gate delta versus prior baseline:
-   - If missing or invalid, render \`delta: (baseline unavailable; run /cc-diff)\`.
+   - If missing or invalid, render \`delta: (baseline unavailable; run /cc-view diff)\`.
 6. Read the top of **\`${knowledgePath}\`** — surface up to 3 most recent entries
    (by trailing timestamp or source marker).
 7. Emit the visual status block described below. Do **not** load any stage skill.
@@ -83,14 +83,14 @@ cclaw status
     - <latest entry summary>
     - <second entry summary>
     - <third entry summary>
-  next: /cc-next · /cc-tree · /cc-diff
+  next: /cc-next · /cc-view tree · /cc-view diff
 \`\`\`
 
 ## Anti-patterns
 
 - Inventing gate status without reading \`${flowPath}\`.
 - Reporting delegations as satisfied when the log says \`pending\`.
-- Advancing the stage from \`/cc-status\` — progression belongs to \`/cc-next\`.
+- Advancing the stage from \`/cc-view status\` — progression belongs to \`/cc-next\`.
 - Hiding stale stages; stale markers must be surfaced directly in the status line.
 
 ## Primary skill
@@ -99,7 +99,7 @@ cclaw status
 `;
 }
 /**
- * Skill body for /cc-status — read-only status snapshot.
+ * Skill body for /cc-view status — read-only status snapshot.
  */
 export function statusCommandSkillMarkdown() {
     const flowPath = flowStatePath();
@@ -109,11 +109,11 @@ name: ${STATUS_SKILL_NAME}
 description: "Read-only visual snapshot of the cclaw flow with progress bar, gate delta, delegations, and stale markers."
 ---
 
-# /cc-status — Flow Status Snapshot
+# /cc-view status — Flow Status Snapshot
 
 ## Overview
 
-\`/cc-status\` is the quickest way to answer "where are we in the flow?" without
+\`/cc-view status\` is the quickest way to answer "where are we in the flow?" without
 advancing or mutating anything. Safe to run at any point.
 
 ## HARD-GATE
@@ -132,7 +132,7 @@ a read-only command. Do **not** update \`${snapshotPath()}\` here.
    - Render \`<X>d<Y>h\`, \`<X>h<Y>m\`, \`<X>m\`, or \`(unknown)\`.
 5. Try reading \`${snapshotPath()}\` for gate delta:
    - If available, compare current stage \`passed\` / \`blocked\` sets against baseline.
-   - If unavailable, render \`delta: (baseline unavailable; run /cc-diff)\`.
+   - If unavailable, render \`delta: (baseline unavailable; run /cc-view diff)\`.
 6. Read \`${RUNTIME_ROOT}/knowledge.jsonl\`. If missing or empty → knowledge highlights are \`(none recorded)\`. Parse each line as JSON and surface its \`trigger\`/\`action\`.
 7. For each gate in \`stageGateCatalog[currentStage].required\`:
    - Satisfied if present in \`passed\` and absent from \`blocked\`.
@@ -151,11 +151,11 @@ a read-only command. Do **not** update \`${snapshotPath()}\` here.
 - Keep output compact (≤ 30 lines) — status, not narrative.
 - Report counts, not full artifact contents.
 - If any data source is missing or corrupt, say so explicitly rather than guessing.
-- Include \`/cc-tree\` for deep structure and \`/cc-diff\` for before/after map in the final line.
+- Include \`/cc-view tree\` for deep structure and \`/cc-view diff\` for before/after map in the final line.
 
 ## Anti-patterns
 
-- Rebuilding trace-matrix or running doctor from \`/cc-status\` — those belong to dedicated tools.
+- Rebuilding trace-matrix or running doctor from \`/cc-view status\` — those belong to dedicated tools.
 - Treating absence of delegation log as "all delegations complete".
 - Mutating state to "clean up" during a status check.
 `;

package/dist/content/tdd-log-command.js

@@ -8,7 +8,7 @@ function flowStatePath() {
     return `${RUNTIME_ROOT}/state/flow-state.json`;
 }
 export function tddLogCommandContract() {
-    return `# /cc-tdd-log
+    return `# /cc-ops tdd-log
 
 ## Purpose
 
@@ -21,10 +21,10 @@ Record explicit RED/GREEN/REFACTOR evidence used by workflow guard and doctor ch
 
 ## Subcommands
 
-- \`/cc-tdd-log red <slice> <command> [note]\`
-- \`/cc-tdd-log green <slice> <command> [note]\`
-- \`/cc-tdd-log refactor <slice> <command> [note]\`
-- \`/cc-tdd-log show\`
+- \`/cc-ops tdd-log red <slice> <command> [note]\`
+- \`/cc-ops tdd-log green <slice> <command> [note]\`
+- \`/cc-ops tdd-log refactor <slice> <command> [note]\`
+- \`/cc-ops tdd-log show\`
 
 ## Log Schema
 
@@ -48,7 +48,7 @@ name: ${TDD_LOG_SKILL_NAME}
 description: "Append RED/GREEN/REFACTOR entries into tdd-cycle-log.jsonl for guard/doctor enforcement."
 ---
 
-# /cc-tdd-log
+# /cc-ops tdd-log
 
 ## HARD-GATE
 

package/dist/content/templates.d.ts

@@ -1,4 +1,4 @@
 export declare const ARTIFACT_TEMPLATES: Record<string, string>;
 export declare const RULEBOOK_MARKDOWN = "# Cclaw Rulebook\n\n## MUST_ALWAYS\n- Follow flow order: brainstorm -> scope -> design -> spec -> plan -> tdd -> review -> ship\n- Require explicit user confirmation after plan before TDD\n- Keep evidence artifacts in `.cclaw/artifacts/`\n- Enforce RED before GREEN in TDD\n- Run two-layer review (spec_compliance and code_quality) before ship\n- Validate all inputs before processing \u2014 never trust external data without sanitization\n- Prefer immutable data patterns and pure functions where the language supports them\n- Follow existing repo conventions, patterns, and directory structure \u2014 match the codebase\n- Verify claims with fresh evidence: \"tests pass\" requires running tests in this message\n- Use conventional commits: `type(scope): description` (feat, fix, refactor, test, docs, chore)\n\n## MUST_NEVER\n- Skip RED phase and jump directly to GREEN in TDD\n- Ship with critical review findings\n- Start implementation during /brainstorm\n- Modify generated cclaw files manually when CLI can regenerate them\n- Commit `.cclaw/` or generated shim files\n- Expose secrets, tokens, API keys, or absolute system paths in agent output\n- Duplicate existing functionality without explicit justification \u2014 search before building\n- Bypass security checks, linting hooks, or type checking to \"move faster\"\n- Claim success (\"Done,\" \"All good,\" \"Tests pass\") without running verification in this message\n- Make changes outside the blast radius of the current task without user consent\n\n## DELEGATION\nWhen a task requires specialist knowledge (security audit, performance profiling, database review),\ndelegate to a specialized agent or skill if the harness supports it. The primary agent should:\n1. Identify the specialist domain\n2. Provide focused context (relevant files, the specific concern)\n3. Evaluate the specialist output before acting on it \u2014 do not blindly apply recommendations\n";
-export declare const CURSOR_WORKFLOW_RULE_MDC = "---\ndescription: cclaw workflow guardrails for Cursor agent sessions\nglobs:\n  - \"**/*\"\nalwaysApply: true\n---\n\n<!-- cclaw-managed-cursor-workflow-rule -->\n\n# Cclaw Workflow Guardrails\n\n## Activation Rule\n\nBefore responding to coding work:\n1. Read `.cclaw/state/flow-state.json`.\n2. Start with `/cc` or continue with `/cc-next`.\n3. If no software-stage flow applies, respond normally.\n\n## Stage Order\n\n`brainstorm -> scope -> design -> spec -> plan -> tdd -> review -> ship`\n\nTrack-specific skips are allowed only when `flow-state.track` + `skippedStages` explicitly say so.\n\n## Task Classification\n\n| Class | Route |\n|---|---|\n| non-trivial software work | `/cc <idea>` |\n| trivial software fix | `/cc <idea>` (quick or medium track) |\n| bugfix with repro | `/cc <idea>` and enforce RED-first in tdd |\n| pure question / non-software | direct answer (no stage flow) |\n\n## Command Surface\n\n- `/cc` = entry and resume.\n- `/cc-next` = only progression path.\n- `/cc-learn` = knowledge capture and recall.\n\n## Verification Discipline\n\n- No completion claim without fresh command evidence in this turn.\n- Do not mark gates passed from memory.\n- Keep evidence in `.cclaw/artifacts/`; archive via `/cc-archive` (agent flow) or archive runtime.\n\n## Delegation And Approvals\n\n- Machine-only checks in design/plan/tdd/review/ship should auto-dispatch when tooling supports it.\n- Ask for user input only at explicit approval gates (scope mode, plan approval, challenge resolution, ship finalization).\n- If harness capabilities are partial, record waiver reasons in delegation logs.\n\n## Routing Source Of Truth\n\n- Primary router: `.cclaw/skills/using-cclaw/SKILL.md`.\n- Protocols: `.cclaw/references/protocols/*.md`.\n- Preamble budget: `.cclaw/references/protocols/ethos.md`.\n";
+export declare const CURSOR_WORKFLOW_RULE_MDC = "---\ndescription: cclaw workflow guardrails for Cursor agent sessions\nglobs:\n  - \"**/*\"\nalwaysApply: true\n---\n\n<!-- cclaw-managed-cursor-workflow-rule -->\n\n# Cclaw Workflow Guardrails\n\n## Activation Rule\n\nBefore responding to coding work:\n1. Read `.cclaw/state/flow-state.json`.\n2. Start with `/cc` or continue with `/cc-next`.\n3. If no software-stage flow applies, respond normally.\n\n## Stage Order\n\n`brainstorm -> scope -> design -> spec -> plan -> tdd -> review -> ship`\n\nTrack-specific skips are allowed only when `flow-state.track` + `skippedStages` explicitly say so.\n\n## Task Classification\n\n| Class | Route |\n|---|---|\n| non-trivial software work | `/cc <idea>` |\n| trivial software fix | `/cc <idea>` (quick or medium track) |\n| bugfix with repro | `/cc <idea>` and enforce RED-first in tdd |\n| pure question / non-software | direct answer (no stage flow) |\n\n## Command Surface\n\n- `/cc` = entry and resume.\n- `/cc-next` = only progression path.\n- `/cc-learn` = knowledge capture and recall.\n\n## Verification Discipline\n\n- No completion claim without fresh command evidence in this turn.\n- Do not mark gates passed from memory.\n- Keep evidence in `.cclaw/artifacts/`; archive via `/cc-ops archive` (agent flow) or archive runtime.\n\n## Delegation And Approvals\n\n- Machine-only checks in design/plan/tdd/review/ship should auto-dispatch when tooling supports it.\n- Ask for user input only at explicit approval gates (scope mode, plan approval, challenge resolution, ship finalization).\n- If harness capabilities are partial, record waiver reasons in delegation logs.\n\n## Routing Source Of Truth\n\n- Primary router: `.cclaw/skills/using-cclaw/SKILL.md`.\n- Protocols: `.cclaw/references/protocols/*.md`.\n- Preamble budget: `.cclaw/references/protocols/ethos.md`.\n";
 export declare function buildRulesJson(): Record<string, unknown>;

package/dist/content/templates.js

@@ -481,7 +481,7 @@ Execution rule: complete and verify each wave before starting the next wave.
 - Exceptions (if any):
 
 ## Retro Gate Handoff
-- Run \`/cc-retro\` before archive.
+- Run \`/cc-ops retro\` before archive.
 - Retro artifact path: \`.cclaw/artifacts/09-retro.md\`
 - Archive remains blocked until retro gate is complete.
 `,
@@ -593,7 +593,7 @@ Track-specific skips are allowed only when \`flow-state.track\` + \`skippedStage
 
 - No completion claim without fresh command evidence in this turn.
 - Do not mark gates passed from memory.
-- Keep evidence in \`.cclaw/artifacts/\`; archive via \`/cc-archive\` (agent flow) or archive runtime.
+- Keep evidence in \`.cclaw/artifacts/\`; archive via \`/cc-ops archive\` (agent flow) or archive runtime.
 
 ## Delegation And Approvals
 

package/dist/content/tree-command.js

@@ -14,7 +14,7 @@ function rewindLogPath() {
     return `${RUNTIME_ROOT}/state/rewind-log.jsonl`;
 }
 export function treeCommandContract() {
-    return `# /cc-tree
+    return `# /cc-view tree
 
 ## Purpose
 
@@ -23,7 +23,7 @@ stale markers, and artifact presence.
 
 ## HARD-GATE
 
-- \`/cc-tree\` is read-only. Do not mutate flow-state or artifacts.
+- \`/cc-view tree\` is read-only. Do not mutate flow-state or artifacts.
 - Use values from \`${flowStatePath()}\` and \`${delegationLogPath()}\`; never infer missing evidence.
 
 ## Algorithm
@@ -64,7 +64,7 @@ name: ${TREE_SKILL_NAME}
 description: "Render a visual flow tree for stages, gates, delegations, and artifacts."
 ---
 
-# /cc-tree
+# /cc-view tree
 
 ## HARD-GATE
 

package/dist/content/utility-skills.js

@@ -771,7 +771,7 @@ description: "Read-only curation pass over the canonical strict-JSONL knowledge
 ## When to run
 
 - Triggered automatically by **\`/cc-learn curate\`**.
-- Recommended after \`/cc-archive\` (or archive runtime) of a feature run, when knowledge has grown.
+- Recommended after \`/cc-ops archive\` (or archive runtime) of a feature run, when knowledge has grown.
 - Recommended when active entry count exceeds **50**.
 
 ## Audit dimensions

package/dist/content/view-command.js

@@ -48,9 +48,9 @@ Wrapper is read-only and dispatch-only. It must not mutate flow state directly.
 
 1. Parse optional subcommand token:
    - missing -> \`status\`
-   - \`status\` -> dispatch to \`/cc-status\`
-   - \`tree\` -> dispatch to \`/cc-tree\`
-   - \`diff\` -> dispatch to \`/cc-diff\`
+   - \`status\` -> dispatch to \`${RUNTIME_ROOT}/commands/status.md\`
+   - \`tree\` -> dispatch to \`${RUNTIME_ROOT}/commands/tree.md\`
+   - \`diff\` -> dispatch to \`${RUNTIME_ROOT}/commands/diff.md\`
 2. Execute the target command contract and skill.
 3. Return concise output and suggest \`/cc-view <subcommand>\` variants for navigation.
 `;

package/dist/doctor-registry.js

@@ -58,7 +58,7 @@ const RULES = [
         }
     },
     {
-        test: /^(hook:|lifecycle:|git_hooks:)/,
+        test: /^(hook:|hooks:|lifecycle:|git_hooks:)/,
         metadata: {
             severity: "error",
             summary: "Hook wiring and lifecycle integration check.",
@@ -67,7 +67,7 @@ const RULES = [
         }
     },
     {
-        test: /^(shim:|agents:cclaw_block|rules:cursor:workflow)/,
+        test: /^(shim:|agents:cclaw_block|rules:cursor:)/,
         metadata: {
             severity: "error",
             summary: "Harness shim and routing file consistency check.",
@@ -84,6 +84,24 @@ const RULES = [
             docRef: ref("state-and-gates.md")
         }
     },
+    {
+        test: /^(knowledge:|artifacts:|runs:)/,
+        metadata: {
+            severity: "error",
+            summary: "Knowledge and artifact runtime integrity check.",
+            fix: "Restore missing runtime files under `.cclaw/` or re-run `cclaw sync`.",
+            docRef: ref("runtime-layout.md")
+        }
+    },
+    {
+        test: /^(meta_skill:|protocol:|stage_skill:|context_mode:)/,
+        metadata: {
+            severity: "error",
+            summary: "Routing skill and protocol integrity check.",
+            fix: "Regenerate runtime references and skills via `cclaw sync`, then re-run doctor.",
+            docRef: ref("harness-and-routing.md")
+        }
+    },
     {
         test: /^delegation:/,
         metadata: {
@@ -119,9 +137,9 @@ export function doctorCheckMetadata(checkName) {
         }
     }
     return {
-        severity: "warning",
+        severity: "error",
         summary: "Unclassified doctor check.",
-        fix: "Review the check details and add a matching rule in doctor-registry when this check should be severity-scoped.",
+        fix: "Report this check name to cclaw maintainers so doctor-registry can classify it explicitly.",
         docRef: ref("README.md")
     };
 }