cclaw-cli 0.49.0 → 0.51.1

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

@@ -1,15 +0,0 @@
-/**
- * Static scaffold for `.cclaw/evals/`. Written on `cclaw init` and refreshed
- * on `cclaw sync` only if the files are missing (user content wins). The
- * 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 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 evaluation mode when --mode is not supplied.\n#   fixture  = verify existing artifacts (cheap, LLM-free unless --judge is set)\n#   agent    = LLM drafts one stage's artifact in a sandbox with tools\n#   workflow = LLM runs the full multi-stage flow (brainstorm \u2192 plan)\n# (Legacy alias --tier=A|B|C still works; A\u2192fixture, B\u2192agent, C\u2192workflow.)\ndefaultMode: fixture\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. Agent/workflow 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. The runner picks `<stage>.yaml` when\n`cclaw eval --judge` is invoked; every stage ships a starter rubric\nbelow \u2014 edit the checks to match what your team cares about, and add\n`critical: true` to the checks that should hard-fail nightly CI on\nregression.\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    critical: false\n```\n\nSee `docs/evals.md` for the full schema.\n";
-export declare const EVAL_RUBRIC_FILES: ReadonlyArray<{
-    stage: string;
-    contents: string;
-}>;
-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

@@ -1,370 +0,0 @@
-/**
- * Static scaffold for `.cclaw/evals/`. Written on `cclaw init` and refreshed
- * on `cclaw sync` only if the files are missing (user content wins). The
- * scaffold is intentionally minimal: a usable default config plus short
- * 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 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.
-provider: zai
-baseUrl: https://api.z.ai/api/coding/paas/v4
-model: glm-5.1
-
-# Default evaluation mode when --mode is not supplied.
-#   fixture  = verify existing artifacts (cheap, LLM-free unless --judge is set)
-#   agent    = LLM drafts one stage's artifact in a sandbox with tools
-#   workflow = LLM runs the full multi-stage flow (brainstorm → plan)
-# (Legacy alias --tier=A|B|C still works; A→fixture, B→agent, C→workflow.)
-defaultMode: fixture
-
-# Per-call timeout and retry budget.
-timeoutMs: 120000
-maxRetries: 2
-
-# Optional hard-stop on estimated USD spend per day. Leave unset for no cap.
-# dailyUsdCap: 5
-
-# Regression thresholds used by CI.
-regression:
-  # Fail when overall score drops by more than this fraction (e.g. -0.15 = 15%).
-  failIfDeltaBelow: -0.15
-  # Fail when any single critical rubric drops below this absolute score.
-  failIfCriticalBelow: 3.0
-`;
-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.
-
-Minimal shape:
-
-\`\`\`yaml
-id: brainstorm-01
-stage: brainstorm
-input_prompt: |
-  One short paragraph describing the user's task.
-context_files: []
-expected:
-  # verifier-specific hints; optional
-\`\`\`
-
-Start with 3 structural cases per stage (24 total), then expand to 5 per
-stage (40 total) once rule verifiers land. Agent/workflow runs may add
-\`context_files\` pulled from real projects to exercise the sandbox.
-`;
-export const EVAL_RUBRICS_README = `# Eval Rubrics
-
-LLM-judge rubrics. Each rubric is a short list of checks scored on a
-\`1–5\` scale with a rationale. The runner picks \`<stage>.yaml\` when
-\`cclaw eval --judge\` is invoked; every stage ships a starter rubric
-below — edit the checks to match what your team cares about, and add
-\`critical: true\` to the checks that should hard-fail nightly CI on
-regression.
-
-\`\`\`yaml
-stage: brainstorm
-checks:
-  - id: distinctness
-    prompt: "Are the proposed directions genuinely distinct (not rephrasings)?"
-    scale: "1-5 where 5=fully distinct approaches"
-    weight: 1.0
-    critical: false
-\`\`\`
-
-See \`docs/evals.md\` for the full schema.
-`;
-const STARTER_RUBRICS = [
-    {
-        stage: "brainstorm",
-        checks: [
-            {
-                id: "distinctness",
-                prompt: "Are the proposed directions genuinely distinct (different approaches, not rephrasings of one idea)?",
-                scale: "1-5 where 5 = every direction uses a materially different approach",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "coverage",
-                prompt: "Do the directions cover the problem space (at least one tackling cost, one velocity, one risk)?",
-                scale: "1-5 where 5 = each major trade-off dimension has a direction",
-                weight: 1.0
-            },
-            {
-                id: "actionability",
-                prompt: "Could a reader pick one direction and start a scope doc tomorrow without asking clarifying questions?",
-                scale: "1-5 where 5 = every direction is concrete enough to scope immediately",
-                weight: 1.0
-            },
-            {
-                id: "recommendation-clarity",
-                prompt: "Is the Recommendation section explicit, single-voiced, and consistent with the highest-ranked direction?",
-                scale: "1-5 where 5 = recommendation names the chosen direction and the decisive trade-off",
-                weight: 1.0,
-                critical: true
-            }
-        ]
-    },
-    {
-        stage: "scope",
-        checks: [
-            {
-                id: "problem-statement",
-                prompt: "Is the problem statement anchored on user/system behavior (not on a proposed solution)?",
-                scale: "1-5 where 5 = problem is described independently of any implementation choice",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "non-goals",
-                prompt: "Are non-goals explicit and mutually-exclusive with the goals (no overlap, no vague 'we might' entries)?",
-                scale: "1-5 where 5 = every non-goal is a crisp decision a future reader can defend",
-                weight: 1.0
-            },
-            {
-                id: "decision-ids",
-                prompt: "Does the Decisions section use stable D-NN ids and name who (or what) owns each decision?",
-                scale: "1-5 where 5 = every decision has a D-NN id and an explicit owner",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "risks",
-                prompt: "Are risks concrete (named system, threshold, or scenario) rather than generic hedges?",
-                scale: "1-5 where 5 = each risk is testable by observing a specific signal",
-                weight: 0.8
-            }
-        ]
-    },
-    {
-        stage: "design",
-        checks: [
-            {
-                id: "decision-trace",
-                prompt: "Does the design doc restate every scope D-NN that drives the architecture, and call out the ones it rejects?",
-                scale: "1-5 where 5 = full D-NN trace with explicit kept/rejected markers",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "diagram-or-flow",
-                prompt: "Is there at least one diagram or clearly labeled flow section that shows data and control moving across the system?",
-                scale: "1-5 where 5 = diagram covers read path, write path, and failure path",
-                weight: 1.0
-            },
-            {
-                id: "alternatives-considered",
-                prompt: "Are concrete alternatives considered with explicit trade-offs (cost, complexity, latency)?",
-                scale: "1-5 where 5 = at least two alternatives are rejected with reasons tied to measurable properties",
-                weight: 0.8
-            },
-            {
-                id: "interface-stability",
-                prompt: "Are public interfaces (APIs, queues, tables) named, typed, and marked as SEMVER-stable or experimental?",
-                scale: "1-5 where 5 = every interface has a name, a type/shape, and a stability tag",
-                weight: 1.0
-            }
-        ]
-    },
-    {
-        stage: "spec",
-        checks: [
-            {
-                id: "acceptance-criteria",
-                prompt: "Does the spec have explicit Acceptance Criteria bullets that are unambiguously verifiable?",
-                scale: "1-5 where 5 = each AC states an observable condition with clear pass/fail",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "edge-cases",
-                prompt: "Are failure modes and edge cases enumerated (empty input, concurrent writers, partial outage)?",
-                scale: "1-5 where 5 = at least three distinct edge cases with expected behavior",
-                weight: 1.0
-            },
-            {
-                id: "test-plan-hooks",
-                prompt: "Does the spec name the test surfaces (unit, integration, e2e, synthetic probe) that will validate each AC?",
-                scale: "1-5 where 5 = every AC maps to at least one test surface",
-                weight: 1.0
-            },
-            {
-                id: "traceability",
-                prompt: "Does the spec cite the originating scope decisions (D-NN) and design sections so future engineers can trace back?",
-                scale: "1-5 where 5 = every material choice links to a D-NN or design heading",
-                weight: 0.8,
-                critical: true
-            }
-        ]
-    },
-    {
-        stage: "plan",
-        checks: [
-            {
-                id: "task-granularity",
-                prompt: "Are tasks sized so one engineer can land each in a single PR (<1 day of work)?",
-                scale: "1-5 where 5 = every T-NN fits in a single reviewable PR",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "tdd-loop",
-                prompt: "Does each task have explicit RED/GREEN/REFACTOR expectations or an equivalent TDD-compatible exit condition?",
-                scale: "1-5 where 5 = every task says what test fails first and what code makes it pass",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "dependency-graph",
-                prompt: "Is the dependency order between tasks explicit (and minimal), so parallelizable work is called out?",
-                scale: "1-5 where 5 = every task lists its blockers and independent tasks are marked parallelizable",
-                weight: 0.8
-            },
-            {
-                id: "scope-traceability",
-                prompt: "Does the plan reference the scope D-NN ids that drive each task, and does coverage leave no decision orphaned?",
-                scale: "1-5 where 5 = every D-NN appears in at least one task and every task names its D-NN",
-                weight: 1.0
-            }
-        ]
-    },
-    {
-        stage: "tdd",
-        checks: [
-            {
-                id: "red-first",
-                prompt: "Does the artifact show a failing test (RED) before the implementation change (GREEN)?",
-                scale: "1-5 where 5 = RED command output is quoted and the fix lands after",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "refactor-evidence",
-                prompt: "Is there a REFACTOR step with a diff or named improvement (not just passing tests)?",
-                scale: "1-5 where 5 = REFACTOR names a specific code-quality win and cites the affected file(s)",
-                weight: 0.8
-            },
-            {
-                id: "gate-evidence",
-                prompt: "Does the artifact quote the output of the required gates (lint, typecheck, tests) after the change?",
-                scale: "1-5 where 5 = every gate command is reproduced with its exit status",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "learnings",
-                prompt: "Does the artifact capture at least one durable learning (pattern, pitfall, follow-up) for future runs?",
-                scale: "1-5 where 5 = learning is specific, filed under knowledge.jsonl or an equivalent store",
-                weight: 0.6
-            }
-        ]
-    },
-    {
-        stage: "review",
-        checks: [
-            {
-                id: "two-layer-structure",
-                prompt: "Does the review show both layers (automated gates + human judgment) with distinct evidence?",
-                scale: "1-5 where 5 = Layer 1 cites tool outputs, Layer 2 cites reviewer reasoning",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "blocker-severity",
-                prompt: "Are issues classified by severity (blocker / major / minor) with one-line rationales?",
-                scale: "1-5 where 5 = every finding names severity + consequence if not fixed",
-                weight: 1.0
-            },
-            {
-                id: "security-posture",
-                prompt: "Does the review cover security-relevant areas explicitly (secrets, authz, PII, deps)?",
-                scale: "1-5 where 5 = each security dimension is addressed (with 'n/a' counted as a deliberate pass)",
-                weight: 0.8,
-                critical: true
-            },
-            {
-                id: "follow-ups",
-                prompt: "Are non-blocking follow-ups filed as explicit tickets or knowledge-log entries (not left as prose)?",
-                scale: "1-5 where 5 = every follow-up has a home and an owner",
-                weight: 0.8
-            }
-        ]
-    },
-    {
-        stage: "ship",
-        checks: [
-            {
-                id: "release-readiness",
-                prompt: "Does the artifact prove release readiness (gates green, changelog, version bump)?",
-                scale: "1-5 where 5 = each readiness item is linked to concrete evidence",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "rollback",
-                prompt: "Is there an explicit rollback path (command, feature-flag, migration reversal)?",
-                scale: "1-5 where 5 = rollback is reproducible from the doc with no context rehydration",
-                weight: 1.0,
-                critical: true
-            },
-            {
-                id: "monitoring",
-                prompt: "Are monitoring and alerting hooks named (dashboards, logs, SLO tripwires)?",
-                scale: "1-5 where 5 = each hook has a canonical URL or query",
-                weight: 0.8
-            },
-            {
-                id: "retro-seed",
-                prompt: "Does the artifact leave a retro seed (what went well, what to change for the next run)?",
-                scale: "1-5 where 5 = at least one distinct 'keep' and one 'change' statement",
-                weight: 0.6
-            }
-        ]
-    }
-];
-function renderRubric(rubric) {
-    const lines = [];
-    lines.push(`# Starter rubric for the \`${rubric.stage}\` stage.`);
-    lines.push(`# Edit the checks to reflect your team's bar before running`);
-    lines.push(`# \`cclaw eval --judge\`. Every check id is used verbatim in`);
-    lines.push(`# report output and baseline files, so keep slugs stable once`);
-    lines.push(`# they start appearing in CI.`);
-    lines.push(`stage: ${rubric.stage}`);
-    lines.push(`checks:`);
-    for (const check of rubric.checks) {
-        lines.push(`  - id: ${check.id}`);
-        lines.push(`    prompt: >-`);
-        lines.push(`      ${check.prompt}`);
-        if (check.scale !== undefined) {
-            lines.push(`    scale: ${JSON.stringify(check.scale)}`);
-        }
-        if (check.weight !== undefined) {
-            lines.push(`    weight: ${check.weight}`);
-        }
-        if (check.critical === true) {
-            lines.push(`    critical: true`);
-        }
-    }
-    return `${lines.join("\n")}\n`;
-}
-export const EVAL_RUBRIC_FILES = STARTER_RUBRICS.map((rubric) => ({
-    stage: rubric.stage,
-    contents: renderRubric(rubric)
-}));
-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\`.
-
-Each baseline file is a JSON document keyed by stage and case id. Do not edit
-by hand; CI will flag baseline churn.
-`;
-export const EVAL_REPORTS_README = `# Eval Reports
-
-Generated reports (JSON + Markdown) land here. This directory is gitignored.
-Run \`cclaw eval --dry-run\` to preview configuration without producing a
-report.
-`;

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

@@ -1,2 +0,0 @@
-export declare function featureCommandContract(): string;
-export declare function featureCommandSkillMarkdown(): string;

package/dist/content/feature-command.js

@@ -1,123 +0,0 @@
-import { RUNTIME_ROOT } from "../constants.js";
-const FEATURE_SKILL_FOLDER = "using-git-worktrees";
-const FEATURE_SKILL_NAME = "using-git-worktrees";
-function activeFeaturePath() {
-    return `${RUNTIME_ROOT}/state/active-feature.json`;
-}
-function worktreeRegistryPath() {
-    return `${RUNTIME_ROOT}/state/worktrees.json`;
-}
-function managedWorktreesRoot() {
-    return `${RUNTIME_ROOT}/worktrees`;
-}
-function legacyFeaturesRoot() {
-    return `${RUNTIME_ROOT}/features`;
-}
-export function featureCommandContract() {
-    return `# /cc-ops feature
-
-## Purpose
-
-Manage parallel feature execution using git worktrees (git-native isolation).
-
-Runtime state/artifacts are **never** copied between features anymore. Isolation is branch/worktree-level.
-
-## HARD-GATE
-
-- Do not mutate feature context by copying \`${RUNTIME_ROOT}/artifacts\` or \`${RUNTIME_ROOT}/state\` between feature IDs.
-- Use \`git worktree add\` for new feature execution paths.
-- Keep \`${activeFeaturePath()}\` + \`${worktreeRegistryPath()}\` as the feature routing source of truth.
-- Treat \`${legacyFeaturesRoot()}/\` as read-only migration data.
-
-## Subcommands
-
-### \`/cc-ops feature status\`
-Show:
-- active feature id from \`${activeFeaturePath()}\`
-- resolved worktree entry from \`${worktreeRegistryPath()}\`
-- active workspace path
-
-### \`/cc-ops feature list\`
-List registered feature worktrees from \`${worktreeRegistryPath()}\` and mark active entry.
-
-### \`/cc-ops feature new <feature-id>\`
-1. Validate \`feature-id\` (lowercase slug, letters/numbers/dashes).
-2. Create worktree under \`${managedWorktreesRoot()}/<feature-id>\`.
-3. Create/switch branch using \`git worktree add\` (prefer \`feature/<feature-id>\` naming).
-4. Register entry in \`${worktreeRegistryPath()}\`.
-
-Optional flags:
-- \`--clone-active\`: seed from active branch HEAD (default behavior).
-- \`--switch\`: mark new feature as active after registration.
-
-### \`/cc-ops feature switch <feature-id>\`
-1. Validate that \`<feature-id>\` exists in \`${worktreeRegistryPath()}\`.
-2. Update \`${activeFeaturePath()}\`.
-3. Print target worktree path and instruct the operator/agent to continue from that workspace root.
-
-## Migration note
-
-Legacy snapshot folders under \`${legacyFeaturesRoot()}/\` are supported as read-only references during migration and should not be used for new execution.
-
-## Output
-
-Always print:
-- active feature before
-- active feature after
-- target workspace path
-- workspace source (\`git-worktree\` | \`workspace\` | \`legacy-snapshot\`)
-
-## Primary skill
-
-**${RUNTIME_ROOT}/skills/${FEATURE_SKILL_FOLDER}/SKILL.md**
-`;
-}
-export function featureCommandSkillMarkdown() {
-    return `---
-name: ${FEATURE_SKILL_NAME}
-description: "Manage cclaw feature isolation using git worktrees (status/list/new/switch)."
----
-
-# /cc-ops feature — Git Worktree Manager
-
-## HARD-GATE
-
-Do not implement feature switching by copying runtime files between feature IDs. Use git worktrees and registry updates only.
-
-## Paths
-
-- Active pointer: \`${activeFeaturePath()}\`
-- Worktree registry: \`${worktreeRegistryPath()}\`
-- Managed worktree root: \`${managedWorktreesRoot()}\`
-- Legacy snapshots (read-only): \`${legacyFeaturesRoot()}\`
-
-## Protocol
-
-### status
-1. Read \`${activeFeaturePath()}\`.
-2. Resolve active entry in \`${worktreeRegistryPath()}\`.
-3. Print active id + workspace path + source.
-
-### list
-1. Enumerate entries in \`${worktreeRegistryPath()}\`.
-2. Mark the active one.
-3. Highlight any \`legacy-snapshot\` entries as migration-only.
-
-### new <feature-id> [--clone-active] [--switch]
-1. Validate \`feature-id\` and ensure not already registered.
-2. Run \`git worktree add\` to create \`${managedWorktreesRoot()}/<feature-id>\`.
-3. Register entry in \`${worktreeRegistryPath()}\` with branch + path + source.
-4. If \`--switch\`, update \`${activeFeaturePath()}\`.
-
-### switch <feature-id>
-1. Validate target exists in \`${worktreeRegistryPath()}\`.
-2. Update \`${activeFeaturePath()}\`.
-3. Report target path and require continuation from that workspace root.
-
-## Safety checks
-
-- If target feature does not exist: block and suggest \`/cc-ops feature new <id>\`.
-- If \`git worktree add\` fails: do not write partial registry updates.
-- If active feature maps to \`legacy-snapshot\`, report read-only migration warning.
-`;
-}

package/dist/content/flow-map.d.ts

@@ -1,23 +0,0 @@
-/**
- * Relative path used by skills/commands to cite the consolidated flow map.
- * Stable contract — changing this value is a breaking change for doctor
- * policies and meta-skill links.
- */
-export declare const FLOW_MAP_REL_PATH = ".cclaw/references/flow-map.md";
-/**
- * Canonical one-page overview of cclaw's user-facing surface.
- *
- * Purpose: give the model (and any curious human) a single file that
- * answers "what does cclaw expose, where does my current stage fit, and
- * which files drive progress?" without forcing a walk of the 8 stage
- * skills plus the 4 router skills plus the meta-skill.
- *
- * Design rules:
- * - Keep it under ~150 lines; it is a map, not a manual.
- * - Only cite files that already exist under `.cclaw/`.
- * - Do not duplicate protocol text (decision/completion/ethos live in
- *   `.cclaw/references/protocols/`). Link, don't inline.
- * - Do not introduce new gates or hard rules here — flow-map is
- *   descriptive, not prescriptive.
- */
-export declare function flowMapMarkdown(): string;

package/dist/content/flow-map.js

@@ -1,134 +0,0 @@
-import { RUNTIME_ROOT } from "../constants.js";
-/**
- * Relative path used by skills/commands to cite the consolidated flow map.
- * Stable contract — changing this value is a breaking change for doctor
- * policies and meta-skill links.
- */
-export const FLOW_MAP_REL_PATH = `${RUNTIME_ROOT}/references/flow-map.md`;
-/**
- * Canonical one-page overview of cclaw's user-facing surface.
- *
- * Purpose: give the model (and any curious human) a single file that
- * answers "what does cclaw expose, where does my current stage fit, and
- * which files drive progress?" without forcing a walk of the 8 stage
- * skills plus the 4 router skills plus the meta-skill.
- *
- * Design rules:
- * - Keep it under ~150 lines; it is a map, not a manual.
- * - Only cite files that already exist under `.cclaw/`.
- * - Do not duplicate protocol text (decision/completion/ethos live in
- *   `.cclaw/references/protocols/`). Link, don't inline.
- * - Do not introduce new gates or hard rules here — flow-map is
- *   descriptive, not prescriptive.
- */
-export function flowMapMarkdown() {
-    return `# cclaw Flow Map
-
-One-page surface reference. Use this when you need the shape of cclaw
-without reading every skill — the stage quick-map, the user-facing
-slash commands, the Ralph Loop signal, and the key state files.
-
-For enforcement details, load the matching stage skill or command
-contract. For protocols (decision/completion/ethos) see
-\`${RUNTIME_ROOT}/references/protocols/\`.
-
-## Stages (8)
-
-| # | Stage | Goal | Primary artifact |
-|---|---|---|---|
-| 1 | brainstorm | Explore options and constraints | \`.cclaw/artifacts/00-idea.md\` (+ \`01-brainstorm.md\`) |
-| 2 | scope | Freeze scope (in/out, assumptions) | \`.cclaw/artifacts/02-scope.md\` |
-| 3 | design | Pick the shape of the change | \`.cclaw/artifacts/03-design.md\` |
-| 4 | spec | Turn design into testable acceptance criteria | \`.cclaw/artifacts/04-spec.md\` |
-| 5 | plan | Decompose spec into executable slices | \`.cclaw/artifacts/05-plan.md\` |
-| 6 | tdd | Drive each slice through RED → GREEN → REFACTOR (Ralph Loop) | \`.cclaw/artifacts/06-tdd.md\` + \`.cclaw/state/tdd-cycle-log.jsonl\` |
-| 7 | review | Cross-check correctness, spec coverage, and ethos | \`.cclaw/artifacts/07-review.md\` |
-| 8 | ship | Close out: retro, compound, archive | \`.cclaw/artifacts/08-ship.md\` (+ \`09-retro.md\`) |
-
-Track shortcuts (set in \`.cclaw/state/flow-state.json\`):
-
-- \`quick\` — spec → tdd → review → ship
-- \`medium\` — brainstorm → spec → plan → tdd → review → ship
-- \`standard\` — all 8 stages (default)
-
-## User-facing slash commands
-
-| Command | Role | Notes |
-|---|---|---|
-| \`/cc\` | Entry point. No args = resume. With prompt = classify + start. | Writes \`00-idea.md\` and picks the track. |
-| \`/cc-next\` | Advance or resume the current stage based on gates. | Soft nudge from Ralph Loop during \`tdd\`. |
-| \`/cc-ideate\` | Repo-improvement discovery, separate from product flow. | Produces ideas, not stage artifacts. |
-| \`/cc-view [status\\|tree\\|diff]\` | Read-only router. Never mutates flow state. | \`diff\` refreshes the snapshot baseline by design. |
-| \`/cc-ops [feature\\|tdd-log\\|retro\\|compound\\|archive\\|rewind]\` | Operations router for post-flow and side-channel actions. | Mutations are scoped to each subcommand. |
-
-Subcommand dispatch lives in \`${RUNTIME_ROOT}/commands/\` and the
-matching \`${RUNTIME_ROOT}/skills/flow-*/SKILL.md\`. The meta-skill
-(\`${RUNTIME_ROOT}/skills/using-cclaw/SKILL.md\`) decides which router to
-use before any substantive work.
-
-## Ralph Loop (TDD progress signal)
-
-When \`currentStage === "tdd"\`, SessionStart writes
-\`${RUNTIME_ROOT}/state/ralph-loop.json\` from the TDD cycle log. Fields
-worth acting on:
-
-- \`loopIteration\` — how many RED → GREEN cycles already landed.
-- \`redOpenSlices\` — slices with an unsatisfied RED. Non-empty means do
-  **not** advance to review.
-- \`acClosed\` — distinct acceptance-criterion IDs closed by a GREEN row
-  (requires \`acIds\` on the green log entry via \`/cc-ops tdd-log\`).
-- \`sliceCount\` — total distinct plan slices ever touched.
-
-Ralph Loop is a signal, not a gate. Stage advancement still runs
-through the normal \`flow-state.json\` gate catalog.
-
-## Compound readiness (auto-promotion signal)
-
-SessionStart also refreshes
-\`${RUNTIME_ROOT}/state/compound-readiness.json\` from \`knowledge.jsonl\`.
-The file lists clusters whose summed \`frequency\` reaches
-\`compound.recurrenceThreshold\` (default 3) or whose severity is
-\`critical\` (override). It surfaces a one-line nudge in the session
-digest only during \`review\` and \`ship\`, where lift-to-rule is in
-scope; earlier stages refresh the file silently. Promotion itself stays
-manual via \`/cc-ops compound\` so the signal never blocks flow.
-
-## Key state files
-
-| Path | What it holds |
-|---|---|
-| \`${RUNTIME_ROOT}/state/flow-state.json\` | Track, currentStage, completedStages, gate catalog, closeout substate. |
-| \`${RUNTIME_ROOT}/state/delegation-log.json\` | Per-stage mandatory agent status + fulfillmentMode + evidenceRefs. |
-| \`${RUNTIME_ROOT}/state/tdd-cycle-log.jsonl\` | Append-only RED/GREEN/REFACTOR entries (source of Ralph Loop). |
-| \`${RUNTIME_ROOT}/state/ralph-loop.json\` | Derived Ralph Loop status (TDD-only). |
-| \`${RUNTIME_ROOT}/state/compound-readiness.json\` | Derived compound-promotion readiness (refreshed each SessionStart). |
-| \`${RUNTIME_ROOT}/state/stage-activity.jsonl\` | Append-only stage-enter/exit and gate-pass signals. |
-| \`${RUNTIME_ROOT}/state/checkpoint.json\` | Latest session checkpoint (stage + timestamp). |
-| \`${RUNTIME_ROOT}/state/context-mode.json\` | Active context mode (\`default\`, \`headless\`, ...). |
-| \`${RUNTIME_ROOT}/state/harness-gaps.json\` | Per-harness tier, subagent fallback, playbook path (schemaVersion 2). |
-| \`${RUNTIME_ROOT}/knowledge.jsonl\` | Append-only learnings; surfaced to sessions via digest. |
-
-## Strictness and hooks
-
-Hook-driven guards respect the \`strictness\` field in
-\`${RUNTIME_ROOT}/config.yaml\`:
-
-- \`advisory\` (default) — hooks warn but never block tool calls.
-- \`strict\` — hooks block tool calls that violate their scope.
-
-Override per-session with \`CCLAW_STRICTNESS=advisory|strict\`.
-
-Hook wiring itself comes from a **single manifest** (\`src/content/hook-manifest.ts\`):
-the per-harness documents at \`.claude/hooks/hooks.json\`, \`.cursor/hooks.json\`,
-\`.codex/hooks.json\` are all derived from it. Inspect the live bindings with
-\`cclaw internal hook-manifest\` (add \`--json\` for machine-readable output).
-
-## When in doubt
-
-1. Read \`${RUNTIME_ROOT}/state/flow-state.json\` to know where you are.
-2. Load the matching stage skill only if you are about to do
-   substantive work (see \`using-cclaw\` meta-skill).
-3. Prefer \`/cc-next\` for progression. \`/cc-view\` for visibility.
-   \`/cc-ops\` for side-channel operations.
-`;
-}

package/dist/content/harness-doc.d.ts

@@ -1,2 +0,0 @@
-export declare function harnessIntegrationDocMarkdown(): string;
-export declare function harnessDocsOverviewMarkdown(): string;