cclaw-cli 0.48.35 → 0.51.0

package/dist/content/doctor-references.js

@@ -1,150 +0,0 @@
-import { RUNTIME_ROOT } from "../constants.js";
-export const DOCTOR_REFERENCE_DIR = `${RUNTIME_ROOT}/references/doctor`;
-export const DOCTOR_REFERENCE_MARKDOWN = {
-    "README.md": `# Doctor Reference Index
-
-Reference docs for \`cclaw doctor\` checks.
-
-## Categories
-
-- \`runtime-layout.md\` - runtime directories, generated commands, and skill files
-- \`hooks-and-lifecycle.md\` - hook wiring and harness lifecycle integration
-- \`harness-and-routing.md\` - harness shims, AGENTS/CLAUDE routing blocks, cursor rule
-- \`state-and-gates.md\` - flow-state integrity and gate evidence contracts
-- \`delegation-and-preamble.md\` - mandatory delegations and lightweight announce discipline
-- \`traceability.md\` - spec/plan/tdd trace matrix expectations
-- \`tooling-capabilities.md\` - local runtime prerequisites (node only)
-- \`config-and-policy.md\` - config schema, rules policy, and validation references
-`,
-    "runtime-layout.md": `# Runtime Layout
-
-## Expected surfaces
-
-- \`.cclaw/\` root and generated subdirectories
-- stage command contracts under \`.cclaw/commands/\`
-- stage skills under \`.cclaw/skills/\`
-- utility command contracts (\`start\`, \`next\`, \`learn\`, \`status\`)
-- state files under \`.cclaw/state/\`
-
-## Typical fixes
-
-1. Run \`cclaw sync\` to re-materialize generated assets.
-2. If runtime is severely drifted, run \`cclaw upgrade\`.
-3. Avoid manual edits under generated runtime paths unless explicitly supported.
-`,
-    "hooks-and-lifecycle.md": `# Hooks And Lifecycle
-
-## Expected behavior
-
-- session start rehydrates flow + knowledge digest
-- pre-tool hooks run prompt/workflow guards
-- post-tool hooks run context monitor
-- stop hooks checkpoint progress
-- OpenCode uses plugin-based lifecycle integration
-
-## Typical fixes
-
-1. Re-run \`cclaw sync\` after harness config changes.
-2. Ensure harness is enabled in \`.cclaw/config.yaml\`.
-3. Validate hook JSON shape and remove malformed manual edits.
-`,
-    "harness-and-routing.md": `# Harness And Routing
-
-## Expected behavior
-
-- command shims exist for every enabled harness
-- managed routing block is present in \`AGENTS.md\` (and \`CLAUDE.md\` when applicable)
-- cursor rule mirrors workflow activation guidance
-- opencode plugin path is registered in opencode config
-
-## Typical fixes
-
-1. Confirm \`harnesses\` list in \`.cclaw/config.yaml\`.
-2. Run \`cclaw sync\` to re-generate shims/routing files.
-3. Remove stale harness artifacts for disabled harnesses via \`cclaw sync\`.
-`,
-    "state-and-gates.md": `# State And Gates
-
-## Expected behavior
-
-- \`flow-state.json\` has activeRunId, current stage, and consistent track/skippedStages
-- current-stage gate evidence is internally consistent
-- completed stages only include passed required gates
-
-## Typical fixes
-
-1. Run \`cclaw doctor --reconcile-gates\` to refresh current-stage gate catalog.
-2. Repair inconsistent stage artifacts, then re-run doctor.
-3. Do not manually mutate gate arrays without matching artifact evidence.
-`,
-    "delegation-and-preamble.md": `# Delegation And Preamble
-
-## Delegation contract
-
-- mandatory delegations for the current stage must be completed or waived
-- waivers should include an explicit reason
-- stale entries from previous runs are ignored by current-run checks
-- delegation entries use span-compatible fields (\`spanId\`, \`startTs\`, \`endTs\`, \`retryCount\`, \`evidenceRefs\`)
-
-## Announce discipline contract
-
-- no dedicated preamble runtime log is required
-- substantial turns should still start with a concise announce (stage + goal + next action)
-- do not spam repeated announces when intent did not change
-
-## Typical fixes
-
-1. Append missing delegation records with \`completed\` or \`waived\` status.
-2. Record harness-limitation waivers when native delegation is unavailable.
-3. Keep announces concise and only refresh when plan/risk materially changes.
-`,
-    "traceability.md": `# Traceability
-
-## Expected behavior
-
-- spec criteria map to plan tasks
-- plan tasks map to tdd slices/tests
-- no orphaned criteria/tasks/tests when downstream artifacts exist
-
-## Typical fixes
-
-1. Add stable IDs to spec/plan/tdd sections.
-2. Ensure mapping tables include every active criterion/task/slice.
-3. Re-run \`cclaw doctor\` after artifact updates.
-`,
-    "tooling-capabilities.md": `# Tooling Capabilities
-
-## Required
-
-- \`node\` (>=20) — the only runtime dependency. All hooks, git-hook relays, and the
-  \`cclaw\` CLI itself run on Node.js. No \`bash\`, \`python3\`, or \`jq\` required.
-- \`git\` — needed for worktree and pre-commit/pre-push relays.
-
-## Not required (removed)
-
-Earlier releases relied on \`bash\` to execute generated shell hooks and on
-\`python3\`/\`jq\` as JSON fallback parsers. Node-only mode removes both: hooks
-dispatch through \`.cclaw/hooks/run-hook.cmd <hook-name>\` (which forwards to
-Node), so these tools
-are no longer part of the supported runtime contract.
-
-## Typical fixes
-
-1. Install Node.js 20 or newer (matches \`package.json\` \`engines\`) and ensure \`node\` is on \`PATH\`.
-2. Re-run \`cclaw sync\` to regenerate hook configs after upgrading Node.
-`,
-    "config-and-policy.md": `# Config And Policy
-
-## Expected behavior
-
-- \`.cclaw/config.yaml\` parses and uses supported keys/values
-- \`.cclaw/rules/rules.json\` matches generated policy schema
-- policy needles and required sections remain present in generated contracts
-
-## Typical fixes
-
-1. Repair invalid config values and run \`cclaw sync\`.
-2. Re-generate policy files via \`cclaw sync\` if drift is detected.
-3. Keep generated contracts aligned with stage schemas and policy needles.
-`
-};

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.
-`;
-}