cclaw-cli 0.48.35 → 0.51.0

package/dist/content/harness-tool-refs.js

@@ -1,268 +0,0 @@
-/**
- * Per-harness tool-mapping reference files.
- *
- * Addresses A.1#4: the four supported harnesses (claude, cursor, opencode, codex)
- * expose different primitive names for the same capabilities (ask-user,
- * delegate/Task, web fetch, file edit, code execution, ...). cclaw's stage skills
- * need to pick the right name at runtime without bloating every stage with per-harness
- * if/else ladders.
- *
- * Each file below is short (one table per capability), authoritative, and materialised
- * at `.cclaw/references/harness-tools/<harness>.md`. Stage skills and the meta-skill
- * cite the folder instead of duplicating the mappings inline.
- *
- * When a new harness is added (or an existing one renames a tool), update the
- * corresponding entry here — do NOT scatter tool names across skill text.
- */
-export const HARNESS_TOOL_REFS_DIR = "references/harness-tools";
-const CLAUDE_TOOLS_MD = `---
-harness: claude
-name: Claude Code tool map
-description: "Canonical mapping of cclaw capability names → Claude Code tool names. Cited by stage skills; do not duplicate in per-stage text."
----
-
-# Claude Code — Tool Map
-
-Use this file as the single source of truth for which Claude Code tool to call when a cclaw skill references a generic capability.
-
-## Core capabilities
-
-| cclaw capability | Claude Code tool | Notes |
-|---|---|---|
-| Ask user a structured question | \`AskUserQuestion\` | Max 4 options; lettered labels ≤12 chars. Fall back to plain-text lettered list on schema error. |
-| Dispatch a subagent (read-only or write) | \`Task\` with \`subagent_type\` | \`explore\` = read-only; \`generalPurpose\` = read-write. Background via \`run_in_background: true\`. |
-| Read file | \`Read\` | Prefer this over \`cat\` / \`head\` / \`tail\`. |
-| Edit file | \`StrReplace\` (exact match) or \`Write\` (overwrite) | Always \`Read\` before editing; avoid \`sed\`/\`awk\` unless asked. |
-| Create file | \`Write\` | Reject if the task can be solved by editing an existing file. |
-| Search file contents | \`Grep\` (ripgrep-backed) | Use \`output_mode: files_with_matches\` for file lists. |
-| Find files by name / glob | \`Glob\` | Pattern matches mtime-sorted. |
-| Shell command | \`Shell\` | Background long-running jobs with \`block_until_ms: 0\`; poll with \`Await\`. |
-| Fetch URL | \`WebFetch\` | Returns markdown. No auth, no binaries. |
-| Web search | \`WebSearch\` | Use for docs, real-time info, version lookups. |
-| Semantic code search | \`SemanticSearch\` | One directory per call; whole-repo via \`[]\`. |
-| Todo tracking | \`TodoWrite\` | Use \`merge: true\` to update; keep one task \`in_progress\`. |
-| Ask tool (multi-question) | \`AskQuestion\` (Cursor-only, unavailable in Claude) | NOT available in Claude — use \`AskUserQuestion\` instead. |
-| MCP tool call | \`CallMcpTool\` | Always read the tool's schema descriptor first. |
-
-## Decision-protocol mapping
-
-When a stage skill says "ask the user a structured question", in Claude Code that means:
-
-\`\`\`
-AskUserQuestion({
-  questions: [{
-    id: "...",
-    prompt: "One-sentence decision, plain English",
-    options: [
-      { id: "a", label: "Short label" },   // ≤12 chars
-      { id: "b", label: "Alt label" },
-      { id: "c", label: "Recommended" }
-    ]
-  }]
-})
-\`\`\`
-
-One question per call. Never batch.
-
-## Escalation / fall-back
-
-If a tool returns a schema error twice in a row (see the meta-skill's Error / Retry Budget), switch to plain-text equivalents:
-
-- \`AskUserQuestion\` → write a numbered list in the response, wait for reply.
-- \`Task\` (dispatch) → inline the work in the current turn.
-- \`WebFetch\` → ask the user for the URL's content.
-`;
-const CURSOR_TOOLS_MD = `---
-harness: cursor
-name: Cursor tool map
-description: "Canonical mapping of cclaw capability names → Cursor agent tool names. Cited by stage skills; do not duplicate in per-stage text."
----
-
-# Cursor — Tool Map
-
-Use this file as the single source of truth for which Cursor agent tool to call when a cclaw skill references a generic capability.
-
-## Core capabilities
-
-| cclaw capability | Cursor tool | Notes |
-|---|---|---|
-| Ask user a structured question | \`AskQuestion\` | \`questions\` is an array; each question has \`id\`, \`prompt\`, \`options\`, optional \`allow_multiple\`. |
-| Dispatch a subagent | \`Task\` with \`subagent_type\` | Available types: \`generalPurpose\`, \`explore\` (readonly), \`shell\`, \`browser-use\`, \`best-of-n-runner\`. |
-| Read file | \`Read\` | Line-numbered output; avoid \`cat\` / \`head\` / \`tail\`. |
-| Edit file | \`StrReplace\` | Unique \`old_string\` required; use \`replace_all: true\` for bulk renames. |
-| Create file | \`Write\` | Prefer editing existing files. |
-| Search file contents | \`Grep\` (ripgrep-backed) | Output modes: \`content\`, \`files_with_matches\`, \`count\`. |
-| Find files by name / glob | \`Glob\` | Auto-prepends \`**/\` when pattern does not start with it. |
-| Shell command | \`Shell\` | Long-running jobs go to background via \`block_until_ms: 0\`; poll with \`Await\`. |
-| Fetch URL | \`WebFetch\` | Markdown output. |
-| Web search | \`WebSearch\` | Use for real-time info, framework docs, news. |
-| Semantic code search | \`SemanticSearch\` | Prefer for exploratory "how does X work?" queries. |
-| Todo tracking | \`TodoWrite\` | Supports \`merge: true\` for partial updates. |
-| Generate image | \`GenerateImage\` | Only on explicit user request. |
-| Ask structured questions (Claude-style) | \`AskUserQuestion\` | NOT available in Cursor — use \`AskQuestion\`. |
-| MCP tool call | \`CallMcpTool\` | Cursor exposes MCP tools via this wrapper; read the descriptor first. |
-| Jupyter notebook edit | \`EditNotebook\` | Use for \`.ipynb\` only; cell-granular edits. |
-| Mode switching | \`SwitchMode\` | Propose plan/agent mode changes when task character shifts. |
-
-## Decision-protocol mapping
-
-In Cursor, structured asks look like:
-
-\`\`\`
-AskQuestion({
-  questions: [{
-    id: "...",
-    prompt: "One-sentence decision",
-    options: [
-      { id: "a", label: "Option A" },
-      { id: "b", label: "Option B" }
-    ]
-  }]
-})
-\`\`\`
-
-## Escalation / fall-back
-
-On repeated tool errors, fall back to plain-text equivalents just like Claude — see the meta-skill's Error / Retry Budget.
-`;
-const OPENCODE_TOOLS_MD = `---
-harness: opencode
-name: OpenCode tool map
-description: "Canonical mapping of cclaw capability names → OpenCode primitives. Cited by stage skills; do not duplicate in per-stage text."
----
-
-# OpenCode — Tool Map
-
-OpenCode exposes a leaner tool surface than Claude Code / Cursor, but it DOES have a native structured-ask primitive (\`question\`) — you just have to opt into it. When a cclaw skill describes a capability that OpenCode lacks entirely, fall back to the plain-text equivalent listed below.
-
-## Core capabilities
-
-| cclaw capability | OpenCode primitive | Notes |
-|---|---|---|
-| Ask user a structured question | \`question\` tool | Each call has a header, question text, and a list of options; users can pick an option or type a custom answer. Supports multiple questions with navigation. **Gated:** \`opencode.json\` must set \`permission.question: "allow"\`; ACP clients additionally need the \`OPENCODE_ENABLE_QUESTION_TOOL=1\` env var. If the tool is denied or unavailable, fall back to a plain-text lettered list (\`A) ... B) ... C) (recommended) ...\`). |
-| Dispatch a subagent | **Not available as a tool.** | Inline the work in the current turn, or split across multiple turns with the user driving. |
-| Read file | file-read primitive | Same role as \`Read\`. |
-| Edit file | file-edit primitive | Same role as \`StrReplace\`; confirm diff before writing. |
-| Create file | file-write primitive | Prefer editing existing files. |
-| Search file contents | \`rg\` via shell | Cite \`rg\` output verbatim as evidence when a skill requires a grep result. |
-| Find files by name / glob | \`fd\` or \`find\` via shell | Capture the command + output. |
-| Shell command | shell primitive | Long-running jobs require explicit background + polling — check the OpenCode docs for \`&\` semantics. |
-| Fetch URL | \`curl\` via shell | No markdown conversion; extract manually. |
-| Web search | **Not available.** | Ask the user to paste docs or provide a URL, then fetch via shell. |
-| Todo tracking | **Not available as a tool.** | Maintain a \`### TODO\` block inline in your response; keep one item in progress. |
-| MCP tool call | Depends on runtime config. | If MCP is enabled, use the documented invocation; otherwise treat as unavailable. |
-
-## Decision-protocol mapping
-
-When the \`question\` tool is enabled, issue one call per decision:
-
-\`\`\`
-question({
-  header: "<stage> decision",
-  question: "<one-sentence decision>",
-  options: [
-    "A) <label> — <trade-off>",
-    "B) <label> — <trade-off>",
-    "C) <label> — <trade-off>  (recommended, because <reason>)"
-  ]
-})
-\`\`\`
-
-If the tool is denied or the host doesn't expose it, fall back to plain text using the same skeleton:
-
-\`\`\`
-Decision: <one sentence>.
-
-A) <label> — <trade-off>
-B) <label> — <trade-off>
-C) <label> — <trade-off>  (recommended, because <one-line reason>)
-
-Please reply with the letter.
-\`\`\`
-
-## Escalation / fall-back
-
-OpenCode has the structured-ask primitive (\`question\`) but no isolated subagent dispatch, so delegation falls back to the role-switch playbook. Flow gates and artifacts are identical; only the delivery channel changes.
-`;
-const CODEX_TOOLS_MD = `---
-harness: codex
-name: Codex tool map
-description: "Canonical mapping of cclaw capability names → Codex CLI primitives. Cited by stage skills; do not duplicate in per-stage text."
----
-
-# Codex — Tool Map
-
-Codex (OpenAI Codex CLI) exposes file I/O, shell, skills, and lifecycle hooks (≥ v0.114, gated by the \`codex_hooks\` feature flag). It does NOT have isolated subagent dispatch, but it DOES expose a native structured-ask tool (\`request_user_input\`) on builds with the Plan / Collaboration mode templates. Fall back to plain text only when that tool is denied or hidden.
-
-## Core capabilities
-
-| cclaw capability | Codex primitive | Notes |
-|---|---|---|
-| Ask user a structured question | \`request_user_input\` tool | Accepts 1-3 short questions and returns the user's answers in the same order. Experimental; used by Codex's built-in Plan / Collaboration mode (see \`codex-rs/collaboration-mode-templates/templates/plan.md\`). Offer only meaningful options — filler choices are explicitly discouraged. Free-form answer strings are returned; keep the lettered options inline in the question text. Fall back to a plain-text lettered list if the tool is hidden or errors. |
-| Dispatch a subagent | **Not available as a tool.** | Codex has no named or generic subagent dispatch. cclaw closes the mandatory-delegation gate with the role-switch playbook (\`.cclaw/references/harnesses/codex-playbook.md\`). |
-| Read file | \`read\` / \`open\` primitive | Same role as \`Read\`. |
-| Edit file | \`edit\` / \`patch\` primitive | Same role as \`StrReplace\`. |
-| Create file | \`write\` primitive | Prefer editing existing files. |
-| Search file contents | \`rg\` via shell | Capture command + output verbatim. |
-| Find files by name / glob | \`fd\` / \`find\` / \`ls\` via shell | Capture command + output. |
-| Shell command | shell primitive | Codex CLI may restrict some binaries by default — check the effective permissions. |
-| Fetch URL | \`curl\` via shell | Extract markdown manually. |
-| Web search | **Not available.** | Ask user for docs / URL. |
-| Todo tracking | \`update_plan\` tool (Codex-native checklist) | \`update_plan\` is Codex's built-in progress / checklist surface and is **separate** from Plan / Collaboration mode — do not conflate them. cclaw also keeps an inline \`### TODO\` block in-turn as an audit mirror. |
-| MCP tool call | Depends on runtime config. | If MCP is wired, cite the descriptor; otherwise treat as unavailable. |
-
-## Decision-protocol mapping
-
-When \`request_user_input\` is available, issue a single call with 1-3 questions:
-
-\`\`\`
-request_user_input({
-  questions: [
-    "<stage> — <one-sentence decision>. Reply A/B/C. A) <label> — <trade-off>. B) <label> — <trade-off>. C) <label> — <trade-off> (recommended, <reason>)."
-  ]
-})
-\`\`\`
-
-Answers come back as free-form strings, not option IDs — keep the lettered options inline so the user's reply maps cleanly to the artifact decision log. When the tool is hidden (older build, non-collaboration mode), fall back to plain text with the same skeleton:
-
-\`\`\`
-Decision: <one sentence>.
-
-A) <label> — <trade-off>
-B) <label> — <trade-off>  (recommended, because <reason>)
-C) <label> — <trade-off>
-
-Please reply with the letter.
-\`\`\`
-
-## Escalation / fall-back
-
-\`request_user_input\` is the only structured-ask primitive Codex ships; dispatch still requires the role-switch playbook. Treat missing tools as "plain-text required", not "skip the step". The gate still has to pass; only the channel changes.
-`;
-const HARNESS_TOOL_REFS = {
-    claude: CLAUDE_TOOLS_MD,
-    cursor: CURSOR_TOOLS_MD,
-    opencode: OPENCODE_TOOLS_MD,
-    codex: CODEX_TOOLS_MD
-};
-export function harnessToolRefMarkdown(harness) {
-    return HARNESS_TOOL_REFS[harness];
-}
-export const HARNESS_TOOL_REFS_INDEX_MD = `---
-name: Harness tool maps
-description: "Index file. One reference per supported harness — cite the per-harness file instead of hardcoding tool names in stage skills."
----
-
-# Harness Tool Maps
-
-cclaw supports four harnesses; each exposes different primitive names for the same capabilities. Stage skills and utility skills cite the file matching the currently active harness and fall back to plain-text equivalents for capabilities that the harness lacks.
-
-| Harness | File | Notes |
-|---|---|---|
-| Claude Code | \`.cclaw/${HARNESS_TOOL_REFS_DIR}/claude.md\` | Richest tool surface (AskUserQuestion, Task, WebFetch, WebSearch, MCP, …). |
-| Cursor | \`.cclaw/${HARNESS_TOOL_REFS_DIR}/cursor.md\` | Near-parity with Claude; uses \`AskQuestion\` instead of \`AskUserQuestion\`. |
-| OpenCode | \`.cclaw/${HARNESS_TOOL_REFS_DIR}/opencode.md\` | Native \`question\` tool (permission-gated) for structured asks; no isolated subagent dispatch. |
-| Codex | \`.cclaw/${HARNESS_TOOL_REFS_DIR}/codex.md\` | Native \`request_user_input\` tool (experimental, Plan / Collaboration mode) for structured asks; no subagent dispatch. |
-
-When a new harness is added or an existing one renames a tool, update the corresponding file (and this index) — do NOT scatter tool names across skill text.
-`;

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

@@ -1,2 +0,0 @@
-export declare function opsCommandContract(): string;
-export declare function opsCommandSkillMarkdown(): string;

package/dist/content/ops-command.js

@@ -1,71 +0,0 @@
-import { RUNTIME_ROOT } from "../constants.js";
-const OPS_SKILL_FOLDER = "flow-ops";
-const OPS_SKILL_NAME = "flow-ops";
-export function opsCommandContract() {
-    return `# /cc-ops
-
-## Purpose
-
-Unified operational command surface for non-stage flow actions.
-
-Subcommands:
-- \`feature\` -> \`/cc-ops feature\`
-- \`tdd-log\` -> \`/cc-ops tdd-log\`
-- \`retro\` -> \`/cc-ops retro\`
-- \`compound\` -> \`/cc-ops compound\`
-- \`archive\` -> \`/cc-ops archive\`
-- \`rewind\` -> \`/cc-ops rewind\`
-
-## HARD-GATE
-
-- \`/cc-ops\` is a routing wrapper; execute only one target subcommand per call.
-- Preserve target command safety contracts (retro gate, archive gate, rewind atomicity, etc.).
-
-## Routing
-
-1. Parse required subcommand token.
-2. Dispatch:
-   - \`feature\` -> \`${RUNTIME_ROOT}/commands/feature.md\`
-   - \`tdd-log\` -> \`${RUNTIME_ROOT}/commands/tdd-log.md\`
-   - \`retro\` -> \`${RUNTIME_ROOT}/commands/retro.md\`
-   - \`compound\` -> \`${RUNTIME_ROOT}/commands/compound.md\`
-   - \`archive\` -> \`${RUNTIME_ROOT}/commands/archive.md\`
-   - \`rewind\` -> \`${RUNTIME_ROOT}/commands/rewind.md\`
-3. Unknown subcommand -> print supported values and stop.
-
-## Headless mode
-
-For skill-to-skill dispatch, emit exactly one JSON envelope:
-
-\`\`\`json
-{"version":"1","kind":"stage-output","stage":"ship","payload":{"command":"/cc-ops","subcommand":"archive","status":"completed"},"emittedAt":"<ISO-8601>"}
-\`\`\`
-
-Validate envelopes with:
-\`cclaw internal envelope-validate --stdin\`
-
-## Primary skill
-
-**${RUNTIME_ROOT}/skills/${OPS_SKILL_FOLDER}/SKILL.md**
-`;
-}
-export function opsCommandSkillMarkdown() {
-    return `---
-name: ${OPS_SKILL_NAME}
-description: "Unified operational router for feature/tdd-log/retro/compound/archive/rewind commands."
----
-
-# /cc-ops
-
-## HARD-GATE
-
-This wrapper only dispatches. It must not apply state mutations itself.
-
-## Protocol
-
-1. Require a subcommand (\`feature|tdd-log|retro|compound|archive|rewind\`).
-2. Route to the matching command contract + skill pair.
-3. Preserve pass-through args after the subcommand (e.g. \`/cc-ops rewind design\`).
-4. Echo which subcommand was dispatched for auditability.
-`;
-}

package/dist/content/protocols.d.ts

@@ -1,7 +0,0 @@
-export declare const PROTOCOLS_REL_DIR = ".cclaw/references/protocols";
-export declare const DECISION_PROTOCOL_REL_PATH = ".cclaw/references/protocols/decision.md";
-export declare const COMPLETION_PROTOCOL_REL_PATH = ".cclaw/references/protocols/completion.md";
-export declare const ETHOS_PROTOCOL_REL_PATH = ".cclaw/references/protocols/ethos.md";
-export declare function decisionProtocolMarkdown(): string;
-export declare function completionProtocolMarkdown(): string;
-export declare function ethosProtocolMarkdown(): string;

package/dist/content/protocols.js

@@ -1,215 +0,0 @@
-import { RUNTIME_ROOT } from "../constants.js";
-export const PROTOCOLS_REL_DIR = `${RUNTIME_ROOT}/references/protocols`;
-export const DECISION_PROTOCOL_REL_PATH = `${PROTOCOLS_REL_DIR}/decision.md`;
-export const COMPLETION_PROTOCOL_REL_PATH = `${PROTOCOLS_REL_DIR}/completion.md`;
-export const ETHOS_PROTOCOL_REL_PATH = `${PROTOCOLS_REL_DIR}/ethos.md`;
-export function decisionProtocolMarkdown() {
-    return `# Decision Protocol
-
-Shared format for decisions that require user confirmation.
-
-## Core sequence
-
-1. State the decision in one sentence.
-2. Provide 2-4 labeled options (A, B, C...).
-3. Mark one option as **recommended** with a short rationale.
-4. Use the harness's structured-ask tool when available:
-   - Claude: \`AskUserQuestion\` (up to ~4 options × multi-question).
-   - Cursor: \`AskQuestion\` (≥2 options, multi-question, optional \`allow_multiple\`).
-   - OpenCode: \`question\` tool (options + "type custom" fallback).
-     Requires \`permission.question: "allow"\` in \`opencode.json\`; ACP
-     clients additionally need \`OPENCODE_ENABLE_QUESTION_TOOL=1\`.
-   - Codex: \`request_user_input\` (1-3 short questions; experimental,
-     surfaced in Plan / Collaboration mode).
-   - Fallback (any harness where the native tool is hidden, denied, or
-     returns a schema error): a numbered / lettered plain-text list
-     keeping the same Re-ground / Simplify / RECOMMENDATION / Options
-     skeleton described below.
-5. Wait for user choice before proceeding.
-
-## Decision skeleton
-
-Every Decision Protocol call — regardless of harness — follows this
-four-part skeleton. Do not skip a part; if a part is trivially empty,
-say so explicitly (e.g. "Re-ground: same branch, same task as prior
-turn").
-
-1. **Re-ground (1-2 sentences).** State the project, the active
-   feature slug, the active stage (from \`flow-state.json\`), and the
-   decision's plain-English context. Pull these values from the source
-   of truth, not from conversation memory.
-2. **Simplify (2-4 sentences).** Explain the choice in plain English a
-   smart 16-year-old could follow. No internal jargon, no raw function
-   names, no implementation trivia. Say what each option DOES and
-   what changes for the user.
-3. **Recommend.** One line of the form
-   \`RECOMMENDATION: Choose [Letter] because [one-line reason]\`.
-   Always prefer the more complete option unless an explicit constraint
-   says otherwise (see Completeness calibration below). Never present
-   options as equivalent when they are not.
-4. **Options.** Lettered options \`A) ... B) ... C) ...\`. Each option
-   includes one-line \`Completeness: X/10\` plus, when effort differs
-   noticeably, a \`(human: ~Xh / agent: ~Ym)\` estimate.
-
-## Completeness calibration
-
-Use the same 1-10 scale for every option so comparisons stay honest:
-
-- **10** = complete implementation: all stated edges handled,
-  traceable to spec, no known deferred work.
-- **7** = covers the happy path; one or two non-critical edges
-  deferred with an explicit follow-up.
-- **5** = partial; either drops edge cases silently or hands off
-  required work to a future run.
-- **3** = shortcut; skips spec criteria, violates an Iron Law, or
-  defers significant work without tracking.
-- **1** = acknowledged placeholder (\`TBD\`, \`TODO\`, "static for now").
-
-Calibration rules:
-
-- Mark any option at \`Completeness: ≤5\` and require the user to
-  acknowledge the gap before picking it.
-- If two options are both \`≥8\`, recommend the higher one.
-- "Static for now" / "we will add later" phrasing always scores \`≤3\`
-  and must be surfaced in Simplify, not buried in an option label.
-
-## Ask format
-
-- One question per call.
-- Option labels are short and unambiguous; the full reasoning lives in
-  Simplify + per-option Completeness.
-- If tool schema fails once, fall back to plain text immediately but
-  keep the skeleton (Re-ground / Simplify / RECOMMENDATION / lettered
-  Options with Completeness scores).
-- Log the chosen letter into the stage artifact's decision log with
-  the Completeness score; do not rely on chat history.
-
-## Retry and escalation
-
-- Same tool fails twice -> stop using that tool in this interaction.
-- Three tool failures in one stage -> pause and surface blocker to user.
-- Same technical approach fails three times -> escalate with evidence and ask for direction.
-`;
-}
-export function completionProtocolMarkdown() {
-    return `# Stage Completion Protocol
-
-Shared closeout sequence applied by every stage skill.
-
-## Required order
-
-1. Verify mandatory delegations are completed or explicitly waived.
-2. Persist stage artifact under \`.cclaw/artifacts/\`.
-3. Use the canonical helper:
-   - \`node .cclaw/hooks/stage-complete.mjs <stage>\`
-   - helper responsibilities: validate mandatory delegations, validate
-     current-stage gate evidence/artifact lint, update
-     \`stageGateCatalog\` + \`guardEvidence\`, and advance \`currentStage\`.
-4. Run \`npx cclaw doctor\` and resolve failures.
-5. **Capture through-flow learnings** — see the policy below. Knowledge
-   accrues continuously across stages, not just at retro.
-6. Notify user with stage completion and next action (\`/cc-next\`).
-7. Stop; do not auto-run the next stage unless user asks.
-
-## Through-flow knowledge capture
-
-Knowledge is recorded **throughout the run**, not saved up for retro.
-Each stage contributes a different kind of insight:
-
-| Stage       | Typical \`type\`  | What to capture                                       |
-|-------------|-----------------|-------------------------------------------------------|
-| brainstorm  | \`lesson\`        | rejected framings and why (only when non-obvious)     |
-| scope       | \`rule\`          | explicit out-of-scope boundaries worth remembering    |
-| design      | \`pattern\`       | architectural trade-offs and their rationale          |
-| spec        | \`rule\`          | non-negotiable acceptance criteria shape              |
-| plan        | \`pattern\`       | effective decomposition / risk-ordering heuristics    |
-| tdd         | \`pattern\`       | red→green→refactor cycle lessons, test-design notes   |
-| review      | \`lesson\`        | recurring defects / blockers caught in this codebase  |
-| ship        | \`lesson\`        | rollback triggers, preflight gotchas                  |
-| retro       | \`compound\`      | process accelerators for the **next** run             |
-
-Rules:
-
-- Append 1–3 strict-schema JSONL lines to \`.cclaw/knowledge.jsonl\` per
-  stage when that stage produced non-obvious decisions, patterns, or
-  lessons. Obvious restatements of the checklist do not count.
-- Use \`type=rule|pattern|lesson\` during stages; reserve \`type=compound\`
-  for the retro step so the retro vs. through-flow signal stays
-  distinguishable.
-- Set \`origin_stage\` to the stage that emitted the entry and
-  \`origin_feature\` to the active feature slug.
-
-## Automatic learning capture policy
-
-- \`standard\` / \`medium\` tracks: required for \`design\`, \`tdd\`, and \`review\`;
-  recommended for other stages.
-- \`quick\` track: recommended only (avoid overhead for tiny fixes).
-- "No learning captured" is acceptable only when explicitly justified (e.g. pure
-  mechanical change, no new trade-offs). Record the justification in the
-  stage artifact, not in knowledge.jsonl.
-
-## Resume protocol
-
-On resume, if artifact exists but not all gates are passed:
-
-1. Reconcile already-proven gates from artifact evidence.
-2. Confirm unresolved gates with the user one at a time.
-3. Update \`guardEvidence\` for each confirmed gate.
-`;
-}
-export function ethosProtocolMarkdown() {
-    return `# Engineering Ethos
-
-Shared operating principles across all stages.
-
-## 1) Boil the Lake
-
-When the "complete version" costs only slightly more than a shortcut, prefer the
-complete version. Do not leave obvious quality gaps for hypothetical follow-ups.
-
-## 2) Search Before Building
-
-Before adding new code/templates/rules:
-
-1. Search existing artifacts/docs.
-2. Search existing knowledge entries.
-3. Search codebase for reusable implementations.
-4. Prefer built-in/library primitives over custom helpers.
-
-## 3) User Sovereignty
-
-AI recommends. User decides. If your recommendation changes the user's stated
-direction, ask first and wait for explicit approval.
-
-## 4) Iron-Law Discipline
-
-Every stage has a non-negotiable Iron Law. If a proposed action violates it,
-stop and escalate via Decision Protocol instead of rationalizing exceptions.
-
-## 5) Complete Before Ship
-
-No release shortcuts:
-- review verdict must be explicit,
-- preflight evidence must be fresh,
-- rollback must be written before finalization.
-
-## 6) Compound, Don't Repeat
-
-Knowledge is recorded **throughout** the run, not saved for the retro.
-When a reusable lesson appears in design, plan, tdd, or review, append one
-strict-schema JSONL entry to \`.cclaw/knowledge.jsonl\` using
-\`type=rule|pattern|lesson\`. Reserve \`type=compound\` for post-ship retro.
-Repeated lessons (frequency ≥ 3) are lifted into stable
-rules/protocols/skills during the automatic compound pass so the same
-class of mistake gets harder to repeat.
-
-## Turn Announce Discipline
-
-Keep orchestration visible without maintaining a dedicated preamble runtime log.
-
-- Start substantial turns with a 1-2 sentence announce: current stage, intent, next action.
-- Skip announce for trivial single-command actions.
-- Never repeat boilerplate announces when the intent did not change.
-- If plan or risk changes materially, post a fresh announce before executing.
-`;
-}

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

@@ -1,2 +0,0 @@
-export declare function retroCommandContract(): string;
-export declare function retroCommandSkillMarkdown(): string;