@debian777/kairos-mcp 4.7.3 → 4.8.0-beta.0

package/dist/resources/embedded-mcp-resources.js

@@ -18,19 +18,21 @@ export const mcpResources = {
         "forward": "Run an **adapter** layer by layer.\n\nFirst call (start a run):\n\n```json\n{ \"uri\": \"kairos://adapter/<slug>\" }\n```\n\nCopy this from `activate.choices[].forward_first_call.uri`. Adapter URIs are\nslug-only on the wire.\n\nContinuation call:\n\n```json\n{\n  \"uri\": \"kairos://layer/<uuid>?execution_id=<uuid>\",\n  \"solution\": {\n    \"type\": \"<contract.type>\",\n    \"outcome\": \"success\",\n    \"evidence\": { /* type-specific proof data */ },\n    \"nonce\": \"<contract.nonce when present>\",\n    \"proof_hash\": \"<contract.proof_hash when present>\"\n  }\n}\n```\n\nCopy `forward.next_call.args` from the previous response, then fill the\n`solution.evidence` payload. Layer URIs are UUID-only; never substitute a slug\nfor a layer URI.\n\nOutput always includes:\n\n- `contract` for the current layer\n- `next_action` prose guidance\n- `next_call` (authoritative machine-readable next call)\n\n`next_call.kind` is:\n\n- `forward` on non-terminal layers\n- `reward` on terminal layers\n\n## Unified solution envelope\n\nEvery solution, regardless of type, follows the same envelope:\n\n```json\n{\n  \"type\": \"<challenge_type>\",\n  \"outcome\": \"success | failure | skipped\",\n  \"evidence\": { /* type-specific proof data */ },\n  \"nonce\": \"<echo from contract>\",\n  \"proof_hash\": \"<echo from contract>\"\n}\n```\n\n### Per-type `evidence` shapes\n\n#### shell\n\n```json\n{\n  \"type\": \"shell\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"exit_code\": 0,\n    \"stdout\": \"...\",\n    \"stderr\": \"\",\n    \"duration_seconds\": 1.2\n  }\n}\n```\n\n#### mcp\n\n```json\n{\n  \"type\": \"mcp\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"tool_name\": \"editJiraIssue\",\n    \"arguments\": { \"issueIdOrKey\": \"BIB-1383\" },\n    \"response\": { \"key\": \"BIB-1383\", \"webUrl\": \"...\" }\n  }\n}\n```\n\n#### comment\n\n```json\n{\n  \"type\": \"comment\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"text\": \"Verified all 78 issues now have repo: labels.\"\n  }\n}\n```\n\n#### user_input\n\n```json\n{\n  \"type\": \"user_input\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"confirmation\": \"agreed. proceed\",\n    \"timestamp\": \"2026-05-18T14:49:00Z\"\n  }\n}\n```\n\n#### tensor\n\n```json\n{\n  \"type\": \"tensor\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"name\": \"priority_score\",\n    \"value\": [0.85, 0.72, 0.91]\n  }\n}\n```\n\n## Compatibility\n\nThe server also accepts older type-specific payload shapes where data is placed\ndirectly under the type key instead of inside an `evidence` envelope:\n\n```json\n{\n  \"type\": \"mcp\",\n  \"mcp\": { \"tool_name\": \"x\", \"result\": {}, \"success\": true }\n}\n```\n\nFor new protocols and solutions, always use the unified envelope with `outcome`\nand `evidence`. The server converts older shapes internally.\n",
         "reward": "Finalize an adapter run with an outcome and optional evaluator metadata.\n\n**When:** After **`forward`** reports the last layer is done and `next_action` tells you to call **`reward`**.\n\n**Input**\n\n- `uri` — **`kairos://layer/{uuid}`** (final layer; include `?execution_id=...` when the run used it).\n- `outcome` — `success` or `failure`.\n- Optional: `score` (0–1), `feedback`, `rater`, `rubric_version`, `llm_model_id`.\n\n**Export eligibility:** To make reward rows exportable for SFT and preference training datasets, you **must** provide:\n\n- `rubric_version` — a version tag (e.g. `\"v1\"`) identifying which rubric or policy was used to evaluate the run.\n- `rater` or `llm_model_id` — at least one to establish evaluator identity.\n\nOmitting either produces `sft_blockers: [\"missing_rubric_version\"]` / `preference_blockers: [\"missing_rubric_version\"]` (or `missing_evaluator_identity`) in the response, making the row non-exportable.\n\n**Output:** Per-layer result rows with `rated_at`, normalized grading\nmetadata (`grader_kind`, `evaluation_label`), export eligibility\nflags plus blocker lists for `sft_jsonl` and `preference_jsonl`, and\n`next_call: null` as the explicit terminal marker.\n\n**Rules:** Use only layer URIs returned by **`forward`**. Do not substitute adapter URIs here unless the tool schema explicitly allows it (this tool expects a layer URI).\n",
         "spaces": "List **spaces** available to the caller (human-readable names) and how many\nadapters each contains.\n\n**Input**\n\n- `include_adapter_titles` (optional) — when true, include per-space adapter\n  titles and layer counts.\n- `include_widget_html` (optional) — when true, load adapter titles and append a\n  second tool content part with an HTML table (type badges, expandable adapter\n  lists) for hosts that render HTML.\n\n**Output:** `spaces` array with `name`, `space_id`, `type` (`personal` | `group` | `app` | `other`), `adapter_count`, and optionally `adapters` (`adapter_id`, `title`, `layer_count`).\n\nWhen running in simple mode (`AUTH_ENABLED=false`), `spaces` includes both a writable **Personal** space and the read-only **Kairos app** space.\n\n**Collaboration patterns**\n\n1. **Precedence** — `activate` search ties break in favour of your **default write space** (usually **Personal**). A personal fork can rank beside an identical-scoring group adapter.\n2. **Scoping `activate`** — pass `space` / `space_id` using the same strings as **`train`** / **`tune`**: `\"personal\"`, a full group path such as `\"{{KAIROS_GROUP_SPACE_PATH_EXAMPLE}}\"` (optional `\"Group: \"` prefix), or the raw `space_id` from this tool.\n3. **Fork** — use **`train`** with `source_adapter_uri` (`kairos://adapter/{uuid}`) and target `space` to copy markdown into a **new** adapter UUID in another space; the original is unchanged.\n4. **Move** — use **`tune`** with `space` (and optional content edits) to reassign an existing adapter’s layers to another allowed space.\n5. **Visibility** — `activate` **match** choices include **`space_name`** so you can see whether a hit is personal, group, or app-level.\n\n**KAIROS tool order** for runs: **`activate`** → **`forward`** (per layer until `next_action` → **`reward`**) → **`reward`**. Use this tool first when you need valid **`space`** values or an inventory before activation.\n",
-        "train": "Register a new **adapter** from markdown (one H1 = one adapter; each verifiable segment ends with a fenced `json` block containing a top-level **`contract`** object).\n\n**Input**\n\n- `content` — full document string (optional if `source_adapter_uri` supplies content).\n- `llm_model_id` — required model identifier string.\n- `force_update` (optional) — replace an existing adapter with the same label.\n- `protocol_version` (optional) — version string (e.g. semver) stored on the adapter.\n- `space` (optional) — `\"personal\"` or a full group path such as `\"{{KAIROS_GROUP_SPACE_PATH_EXAMPLE}}\"` (target space for the new adapter).\n- `source_adapter_uri` (optional) — `kairos://adapter/{uuid}` to **fork**: export that adapter’s markdown and **train** a **new** adapter (new ids). If you also pass `content`, that text is used instead of the export (customize before calling **`train`**).\n- `mime` (optional) — content MIME type. Defaults to `text/markdown`.\n- `artifact_name` (required when `mime` is not `text/markdown`) — file name shown when listing adapter artifacts.\n- `adapter_uri` (required when `mime` is not `text/markdown`) — `kairos://adapter/{uuid}` or `kairos://adapter/{slug}` target adapter for the artifact attachment.\n- `relative_path` (optional, non-markdown artifacts only) — path relative to the skill bundle root (forward slashes; no `..` segments). When set, **`export`** **`skill_zip`** and **`skill_tree`** place the file at this path instead of the default **`artifacts/<sanitized artifact name>`** layout.\n\n**Required structure (validated before store)**\n\n- H1 title for the adapter.\n- First H2: **Activation Patterns**.\n- Last H2: **Reward Signal**.\n- At least one fenced **` ```json `** block whose JSON has a top-level\n  **`contract`** object.\n- Contract fences must use the `json` language tag only (no plain ``` blocks holding contract JSON).\n- Non-markdown artifacts (`mime` not `text/markdown`) are stored as adapter-linked artifacts instead of stored Markdown layers.\n\n**Size limits (safety):** Before structure checks, the server rejects oversized Markdown and artifact bodies (max logical lines, max UTF-8 bytes per line, and a total-byte ceiling from env — default line cap **350**, default per-line bytes **8192**, safety factor **1.15**). See architecture [Train workflow](../../../docs/architecture/workflow-train.md#adapter-markdown-size-limits-safety).\n\n**Output:** `status: stored` and `items` with `layer_uuid`, `adapter_uri`, `layer` URIs, labels, tags.\n\n**After train:** Use **`activate`** / **`forward`** to execute; use **`tune`**\nfor in-place adapter/layer edits (non-structural); use **`train`** with\n`force_update: true` for structural adapter replacement; use **`export`** to\ndump markdown or datasets.\n\nFor contract shapes and examples, call **`forward`** with\n`kairos://adapter/create-new-protocol` and omit `solution` on the first call of\nthe run (then follow `next_action`).\n",
-        "tune": "Update existing **adapter** content in place.\n\n**Input**\n\n- `uris` — non-empty list of `kairos://adapter/{uuid}` and/or `kairos://layer/{uuid}` targets.\n- `content` (optional) — parallel array of full markdown bodies (preferred for text changes).\n- `updates` (optional) — advanced field map; prefer `content` for ordinary edits.\n- `space` (optional) — `\"personal\"` or a full group path such as `\"{{KAIROS_GROUP_SPACE_PATH_EXAMPLE}}\"`: reassign **all layers** of each targeted adapter to that space. You can use **`space` alone** (move only) or combine with `content` / `updates` (edit then move). Adapter URI moves every layer; layer URI moves that layer only.\n\n**Output:** `results` with per-URI `status` (`updated` | `error`) and `message`, plus totals.\n\n**Rules:**\n\n- Pass layer URIs when you want to edit specific layers.\n- Pass adapter URIs when you want in-place edits across that adapter's stored\n  layers without replacing adapter identity.\n- Use **`train`** with `force_update: true` for structural replacements (for\n  example, changing adapter identity/H1 mapping or layer count).\n- When you pass layer URIs, the server normalizes to the underlying stored\n  memories.\n- Refresh execution context after large **`tune`** edits (new **`forward`**\n  from the adapter URI).\n"
+        "train": "Register a new **adapter** from markdown (one H1 = one adapter; each verifiable segment ends with a fenced `json` block containing a top-level **`contract`** object).\n\n**Input**\n\n- `content` — full document string (optional if `source_adapter_uri` supplies content).\n- `llm_model_id` — required model identifier string.\n- `force_update` (optional) — replace an existing adapter with the same label.\n- `protocol_version` (optional) — version string (e.g. semver) stored on the adapter.\n- `space` (optional) — `\"personal\"` or a full group path such as `\"{{KAIROS_GROUP_SPACE_PATH_EXAMPLE}}\"` (target space for the new adapter).\n- `source_adapter_uri` (optional) — `kairos://adapter/{uuid}` to **fork**: export that adapter’s markdown and **train** a **new** adapter (new ids). If you also pass `content`, that text is used instead of the export (customize before calling **`train`**).\n- `mime` (optional) — content MIME type. Defaults to `text/markdown`.\n- `artifact_name` (required when `mime` is not `text/markdown`) — file name shown when listing adapter artifacts.\n- `adapter_uri` (required when `mime` is not `text/markdown`) — `kairos://adapter/{uuid}` or `kairos://adapter/{slug}` target adapter for the artifact attachment.\n- `relative_path` (optional, non-markdown artifacts only) — path relative to the skill bundle root (forward slashes; no `..` segments). When set, **`export`** **`skill_zip`** and **`skill_tree`** place the file at this path instead of the default **`artifacts/<sanitized artifact name>`** layout.\n- `review_evidence` (required for adapter/markdown trains) — phase-critic verdict proof. Run phase-critic before **`train`**; provide the verdict file as proof. Object with `verdict_file` (absolute path), `exit_code` (must be 0), and `stdout` (line 1 must be PASS). Not required for artifact trains (non-markdown mime).\n\n**Required structure (validated before store)**\n\n- H1 title for the adapter.\n- First H2: **Activation Patterns**.\n- Last H2: **Reward Signal**.\n- At least one fenced **` ```json `** block whose JSON has a top-level\n  **`contract`** object.\n- Contract fences must use the `json` language tag only (no plain ``` blocks holding contract JSON).\n- Non-markdown artifacts (`mime` not `text/markdown`) are stored as adapter-linked artifacts instead of stored Markdown layers.\n\n**Size limits (safety):** Before structure checks, the server rejects oversized Markdown and artifact bodies (max logical lines, max UTF-8 bytes per line, and a total-byte ceiling from env — default line cap **350**, default per-line bytes **8192**, safety factor **1.15**). See architecture [Train workflow](../../../docs/architecture/workflow-train.md#adapter-markdown-size-limits-safety).\n\n**Output:** `status: stored` and `items` with `layer_uuid`, `adapter_uri`, `layer` URIs, labels, tags.\n\n**After train:** Use **`activate`** / **`forward`** to execute; use **`tune`**\nfor in-place adapter/layer edits (non-structural); use **`train`** with\n`force_update: true` for structural adapter replacement; use **`export`** to\ndump markdown or datasets.\n\nFor contract shapes and examples, call **`forward`** with\n`kairos://adapter/create-new-protocol` and omit `solution` on the first call of\nthe run (then follow `next_action`).\n",
+        "tune": "Update existing **adapter** content in place.\n\n**Input**\n\n- `uris` — non-empty list of `kairos://adapter/{uuid}` and/or `kairos://layer/{uuid}` targets.\n- `content` (optional) — parallel array of full markdown bodies (preferred for text changes).\n- `updates` (optional) — advanced field map; prefer `content` for ordinary edits.\n- `space` (optional) — `\"personal\"` or a full group path such as `\"{{KAIROS_GROUP_SPACE_PATH_EXAMPLE}}\"`: reassign **all layers** of each targeted adapter to that space. You can use **`space` alone** (move only) or combine with `content` / `updates` (edit then move). Adapter URI moves every layer; layer URI moves that layer only.\n- `review_evidence` (required when `content` is provided) — phase-critic verdict proof. Run phase-critic before **`tune`** with content; provide the verdict file as proof. Object with `verdict_file` (absolute path), `exit_code` (must be 0), and `stdout` (line 1 must be PASS). One PASS covers all URIs in the tune call. Not required for space-only moves or updates-only (no content) tunes.\n\n**Output:** `results` with per-URI `status` (`updated` | `error`) and `message`, plus totals.\n\n**Rules:**\n\n- Pass layer URIs when you want to edit specific layers.\n- Pass adapter URIs when you want in-place edits across that adapter's stored\n  layers without replacing adapter identity.\n- Use **`train`** with `force_update: true` for structural replacements (for\n  example, changing adapter identity/H1 mapping or layer count).\n- When you pass layer URIs, the server normalizes to the underlying stored\n  memories.\n- Refresh execution context after large **`tune`** edits (new **`forward`**\n  from the adapter URI).\n"
     },
     "mem": {},
     "meta": {
-        "create-new-protocol": "---\nslug: create-new-protocol\nversion: \"4.7.3\"\ntitle: Create / Review / Refactor KAIROS Protocol\n---\n\n\n\n# Create / Review / Refactor KAIROS Protocol\n\n> **Why we create protocols — a note to the agent reading this.**\n>\n> KAIROS protocols are not documentation. They are not conventional apps.\n> They are **interfaces for a fundamentally new kind of user: AI agents.**\n>\n> You, the agent reading this, are the primary user. When you execute a\n> protocol, you follow instructions designed to help you harmonise with the\n> human you serve. Every phase boundary, every contract, every explicit stop\n> condition exists because you cannot reliably infer these on your own — and\n> honest uncertainty is always better than confident drift.\n>\n> When you author a new protocol, you are designing behaviour for yourself\n> and for other agents — some weaker, some stronger, all trying to serve\n> their humans well. Write for them:\n>\n> - **Single source of truth.** Never duplicate rules across protocols.\n>   When rules drift between files, agents execute contradictory behaviour\n>   depending on entry point — and they cannot detect the contradiction.\n> - **Explicit over implicit.** Agents fill ambiguity with hallucination.\n>   Say exactly what to do, when to stop, and when to ask.\n> - **Phases teach modes.** Each step teaches the agent which cognitive mode\n>   it is in: explore, clarify, decide, execute, verify, review. Blurring\n>   these modes causes the agent to act when it should verify, or guess\n>   when it should ask.\n> - **Truth over fluency.** A protocol that reads well but causes wrong\n>   behaviour is worse than one that reads rough but executes correctly.\n\n## Activation Patterns\n\nKAIROS authoring lifecycle — create, review, or fix adapters / protocols / workflows.\nIn this context, those words refer to the same stored artifact and can be treated\nas synonyms. Supports three operations:\n\n- **create** — draft and train a new adapter / protocol from scratch.\n- **review** — audit an existing adapter, family, or bundle for structural issues,\n  missing cross-references, chaining gaps, DRY violations, stale guidance, or\n  agent-hostile ambiguity. Read-only.\n- **fix** — apply specific corrections to an existing adapter / protocol and re-train.\n\n**Run this protocol when the user says ANY of:**\n\n- \"create a new KAIROS protocol\" / \"create new protocol adapter\"\n- \"register personal KAIROS adapter\" / \"register a personal adapter\"\n- \"train adapter into personal\" / \"train protocol into personal\"\n- \"train a workflow\" / \"register a new adapter\" / \"create a new workflow\"\n- \"review protocol\" / \"audit adapters\" / \"check protocol families for gaps\"\n- \"fix protocol\" / \"update adapter\" / \"patch protocol\" / \"refactor protocol\"\n- \"create new protocol\" (when `activate` found no match and user confirms)\n\n**Trigger pattern:** **create** / **train** / **register** / **review** /\n**audit** / **fix** / **update** / **patch** / **refactor** +\n(protocol / adapter / workflow).\n\n**Must Never:**\n- Run when the user only asked to execute an existing protocol.\n- Mutate adapters during a `review` operation.\n- Optimise only for pretty wording; this protocol designs agent behaviour.\n\n**Must Always:**\n- Infer `{operation}` from trigger: create / review / fix.\n- Optimise for truth, low ambiguity, explicit sequencing, and user-need alignment.\n- Design or review phase transitions explicitly: discovery, clarification,\n  ideation, planning, execution, validation, review, handoff.\n- Include Activation Patterns as the first H2 and Reward Signal as the last H2\n  in any newly drafted adapter.\n- Enforce the 350-line limit per file.\n\n**Good trigger examples:**\n- \"Create a new KAIROS protocol for code review\" → run this protocol (create)\n- \"No match found; I want to create a new protocol\" → run this protocol (create)\n- \"Review all v4 protocol families for missing cross-references\" → run this protocol (review)\n- \"Refactor the MR adapter to be less ambiguous\" → run this protocol (fix)\n\n**Bad trigger examples:**\n- \"Run the standardise project protocol\" → use activate / forward\n- \"Search for deployment protocol\" → use activate\n- \"Create an MR\" → use the MR adapter, not this protocol\n\n## Preflight Dependencies\n\nBefore running authoring actions, verify dependency and auth readiness for this\nrun:\n\n1. Required MCP tools are available and reachable: `activate`, `forward`,\n   `reward`, and the operation-dependent tool (`train`, `export`, or `tune`).\n2. Required CLI tools for planned shell steps are installed and callable.\n3. Required auth/session state is valid for the target MCP server.\n\nIf any check fails, stop before main execution and ask the user to choose one:\n- proceed with AI-assisted setup and then resume\n- abort this protocol run now\n\nDo not continue to intent confirmation until preflight passes.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Confirm Intent\n\nInfer `{operation}` from the user's trigger:\n\n| Signal | Operation |\n|---|---|\n| \"create\", \"new\", \"train\", no match from activate | **create** |\n| \"review\", \"audit\", \"check\", \"gaps\", \"cross-references\" | **review** |\n| \"fix\", \"update\", \"patch\", \"refactor\", \"add missing\", \"correct\" | **fix** |\n\nFor `create`: ask whether to create a new protocol or refine the search.\nFor `review`: ask which adapter(s), family, or bundle to review.\nFor `fix`: ask which adapter to fix and what the issue is.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Confirm operation and target\"},\"required\":true}}\n```\n\n## Gather Requirements\n\n### For `create` — collect details for a new protocol\n\n**1. Determine the pattern:**\n\n| Signal | Pattern |\n|---|---|\n| One workflow, no variants | **Standalone** — one protocol, all steps inline |\n| Multiple issue types / output formats / media | **Router + Extensions** — router classifies, routes via `activate` |\n| Domain has a decision tree | **Router + Extensions** |\n| Single workflow but exceeds 350 lines or too complex for weaker models | **Chain** — split into sequential adapters linked via `forward` + slug |\n| Reference material needed by steps | Extract to a separate file, not a protocol |\n\n**2. Collect per protocol:**\n\n- **Title** — clear, descriptive H1.\n- **User problem** — what real problem does this solve?\n- **Agent behaviour** — what behaviour should this create in the agent?\n- **Mode map** — which steps are for discovery, clarification, ideation,\n  planning, execution, validation, review, or handoff?\n- **Steps** — each H2 must earn its place and end with a challenge.\n- **Challenge type per step** — use the strongest observable contract possible.\n- **Domain reference** — guides / docs the protocol should load.\n- **Existing protocols** — reuse, compose, or extract shared content.\n- **DRY check** — extract duplicated content.\n- **Size check** — if any file may exceed 350 lines, split now.\n- **Chain position** — is this a chain entry, chain middle, or chain exit?\n  If chain middle/exit, what slug does the previous link forward to?\n- **Failure analysis** — where would a weaker agent misread this protocol?\n\n**3. If Router pattern:**\n- What are the variants?\n- What decision questions classify the variant?\n- What types are forbidden?\n- Which parts stay in the router, and which belong only in extensions?\n\n**4. If Chain pattern:**\n\nLoad `protocol-linking-guide` for full chain structuring rules\n(`forward` with `kairos://adapter/protocol-linking-guide`).\n\nCollect:\n- What are the chain links and their concerns?\n- What is the minimum number of links that helps weaker models?\n- Which link is the chain entry point (matched by `activate`)?\n- What artifacts flow between links (context set in earlier phases)?\n\n### For `review` — audit existing adapters against this checklist\n\nExport target adapter(s). For each adapter, check:\n\n1. **User-need fit** — does the adapter solve a real user problem, or merely\n   mirror literal wording?\n2. **Mode / phase clarity** — are discovery, clarification, ideation,\n   execution, validation, and review clearly separated?\n3. **Cross-reference completeness** — are all required related adapters linked?\n4. **Adapter handoff gaps** — does it hand off where another adapter should own\n   the work?\n5. **DRY violations** — is policy content duplicated instead of linked?\n6. **Contract coverage** — does every executable H2 have the right contract?\n7. **Truth-first behaviour** — does it reduce guessing, fake certainty, and\n   silent assumption-making?\n8. **Activation pattern accuracy** — do triggers match what users actually say?\n9. **Structure compliance** — first H2 Activation Patterns, last H2 Reward\n   Signal, no duplicate H2s, under 350 lines.\n10. **Sibling consistency** — are equivalent steps present across sibling\n    adapters in the same family?\n11. **Chained adapter families** (when applicable) — extension adapters include\n    `chain_root` and a prerequisite clause pointing at the root; parent adapters\n    use explicit `forward` when the next adapter slug is already known; reserve\n    `activate` for ambiguous runtime discovery (see `protocol-linking-guide`,\n    **Chaining Back and Forward**).\n\n### For `fix` — identify the specific issue\n\nExport the target adapter, read the current markdown, identify the exact gap or\nerror, and plan the minimal change. Do not alter unrelated layers.\n\nSummarise gathered requirements or findings.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Draft Markdown\n\n### For `create` — draft new adapter markdown\n\nDraft the full markdown for `train`.\n\n### For `review` — draft findings report\n\nWrite a structured gap report to `$REVIEW_FINDINGS_FILE` (an absolute path\nprovided by the invoking agent or chosen by you under\n`$KAIROS_LOCAL_ARTIFACT_DIR` with a session-unique segment). For each finding\ninclude:\n\n- adapter title\n- gap type\n- severity\n- why the issue matters for AI-agent behaviour\n- specific recommended fix\n\n### For `fix` — draft corrected adapter markdown\n\nApply the identified fix and show a diff-style summary of what changed.\n\n### Shared drafting rules (all operations)\n\n**Core KAIROS rule — right mode at the right time:**\n\nEvery protocol must help the agent recognise whether the current step is for\nexploration, clarification, ideation, planning, execution, validation, review,\nor handoff. Do not blur those modes.\n\n**Truth over fluency:**\n\nDesign protocols to reduce guessing and fake certainty. Prefer:\n- explicit prompts\n- explicit stop conditions\n- explicit uncertainty escalation\n- observable verification over narrative reassurance\n\n**User need over literal phrasing:**\n\nThe protocol should help the agent provide what the user actually needs, not\njust echo the wording used in the request.\n\n**DRY — Don't Repeat Yourself:**\n\nEvery piece of knowledge must live in exactly one place in the protocol family.\nIf two protocols share >50% of their body, extract shared logic.\n\n**350-line maximum per file:**\n\nNo protocol file may exceed 350 lines. If it grows beyond that, split it into\nlinked adapters or extract a reference file.\n\n**Generic-first — create generic, link from detailed:**\n\nCreate protocols from generic to detailed. The generic adapter must stand alone.\nExtensions should contain only the delta.\n\n**Slug convention — deterministic protocol linking:**\n\nEvery protocol gets a short, unique, lowercase-hyphenated `slug`.\n\n**Artifact workflow for adapters:**\n\nWhen protocol execution depends on scripts or config blobs, store them as\nartifacts linked to the adapter via `train` with:\n- `mime` set to a non-markdown content type\n- `artifact_name` set to a stable file name\n- `adapter_uri` set to the target adapter URI\n\nRetrieve attached artifacts with `export` using\n`kairos://artifact/{uuid}` when a step needs the raw content.\n\n**Protocol structure rules:**\n- H1: protocol title\n- First H2: Activation Patterns\n- Second H2: Preflight Dependencies\n- Middle H2s: one per step, each ending with a JSON contract block\n- Last H2: Reward Signal\n- Frontmatter: `slug` (required), `version` (optional), `chain_root` (required for mid-chain adapters — slug of the chain entry point)\n\n**Challenge types:**\n\nLoad `challenge-type-guide` for decision rules, JSON formats, and interpreter\nselection (`forward` with `kairos://adapter/challenge-type-guide`).\n\n**If Router pattern:** draft the router and each extension as separate files.\n\nPost the full drafted markdown.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## User Review\n\nFor `create`: present the drafted protocol(s) and ask for approval, changes, or\ncancellation.\n\nFor `review`: present the findings report and ask which findings to act on.\n\nFor `fix`: present the corrected adapter markdown and a summary of changes.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Approve the draft (create/fix) or acknowledge findings (review)\"},\"required\":true}}\n```\n\n## Finalise Operation\n\nFor `create`: call `train` with the approved markdown. Use `force_update: false`\nunless overwrite was explicitly requested.\n\nFor `review`: do not call `train`. Save the findings report only if requested.\n\nFor `fix`: call `train` with `force_update: true` and update the corresponding\nrepo file to keep the local copy in sync.\n\nReport the outcome: adapter URI(s) for create / fix, or findings summary for\nreview.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nProtocol complete when:\n- `create` — adapter(s) stored via `train` and URI(s) reported\n- `review` — findings report delivered and acknowledged\n- `fix` — corrected adapter trained with `force_update: true` and repo file updated\n\nA successful result means the resulting KAIROS adapter is more truthful,\nphase-aware, agent-readable, and aligned with human–AI harmony.\n",
-        "refine-search": "---\nversion: \"4.7.3\"\nslug: refine-search\ntitle: Get help refining your search\n---\n\n\n\n# Get help refining your search\n\n**You are an AI agent.** You ran `activate` and got no solid match, or only weak\n/ ambiguous matches. This adapter helps you turn a vague request into a better\nquery so the next `activate` can find the right adapter.\n\nKAIROS principle: before acting, understand the user better. The goal is not to\nrepeat the failed phrase with minor edits. The goal is to recover the user's\nreal intent.\n\n## Activation Patterns\n\n**Run this adapter when:**\n- `activate` returned no match.\n- `activate` returned only weak choices.\n- The response included a `refine` choice.\n\n**Trigger pattern:** after `activate` when no strong match exists.\n\n**Must Never:**\n- Run when a strong match already exists.\n- Loop refinement endlessly.\n\n**Must Always:**\n- Infer the real goal, context, and missing constraints from the user's request.\n- Build a more specific query than the one that failed.\n- Run at most once per user request; if the second activation still fails, stop\n  and offer clarification or protocol creation.\n\n**Good trigger examples:**\n- activate returned only \"refine\" / weak matches → run this adapter\n- \"No protocol matched 'do the thing'\" → run this adapter\n\n**Bad trigger examples:**\n- activate returned a strong match → use that match instead\n- user asked \"what adapters exist?\" → use `activate` / `spaces`, not this\n\n## Step 1: Extract what the user actually wants\n\nFrom the user's original message, identify:\n- the real goal\n- relevant context\n- missing constraints\n- likely wording that would help KAIROS find the right adapter\n\nWrite your analysis as the solution.\n\n```json\n{\n  \"contract\": {\n    \"type\": \"comment\",\n    \"comment\": { \"min_length\": 60 },\n    \"required\": true\n  }\n}\n```\n\n## Step 2: Build and run a refined activate query\n\nUsing Step 1, construct one refined query with 3–8 specific words. Do not reuse\nthe vague phrase that already failed.\n\nCall `activate` with it.\n\n- **Strong match (score >= 0.5):** pick that choice and `forward`.\n- **Weak matches only:** ask the user to clarify or offer the create path.\n\nDo not loop more than once.\n\n```json\n{\n  \"contract\": {\n    \"type\": \"mcp\",\n    \"mcp\": { \"tool_name\": \"activate\" },\n    \"required\": true\n  }\n}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent has converted a failed literal search into a more truthful,\nuser-aligned activation attempt.\n",
-        "create-new-protocol-review": "---\nversion: \"4.7.3\"\nslug: create-new-protocol-review\ntitle: Review and Publish New KAIROS Protocol\n---\n\n\n# Review and Publish New KAIROS Protocol\n\nValidate a drafted KAIROS protocol through format review, stranger review, user\napproval, and train. Invoked by the authoring adapter (`create-new-protocol`) or\ndirectly to re-review an existing draft.\n\n## Activation Patterns\n\n**Typically invoked by:** the authoring adapter's handoff step via\n`activate()` or a stored adapter URI.\n\n**Can be invoked directly when user says:**\n- \"review my protocol draft\" / \"validate this protocol\"\n- \"re-run format review on my draft\"\n- \"train my protocol\" / \"register my adapter\"\n\n**Trigger pattern:** **review** / **validate** / **train** + (protocol / draft).\n\n**Must Never:**\n- Run shell verification without verifying that all input file paths exist first.\n- Skip format or stranger review.\n- Approve a draft merely because it sounds polished.\n\n**Must Always:**\n- Verify all input file paths exist before proceeding (`test -f`).\n- Require both reviews to pass before presenting to the user.\n- Freeze the draft checksum before `train`.\n- Review for truth, phase clarity, ambiguity, and weaker-agent executability.\n\n**Good trigger examples:**\n- handoff from `create-new-protocol` → run this protocol\n- \"Review and train my protocol draft\" → run this protocol\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Search for a protocol\" → use `activate`\n\n## Preflight Dependencies\n\nBefore running review/publish steps, verify prerequisites up front:\n\n1. Required MCP tools are reachable: `activate`, `forward`, `reward`, `train`.\n2. Required shell utilities used in this workflow are callable.\n3. Required authentication/session state is valid for MCP and SCM hosts.\n4. All input file paths provided by the parent agent exist (`test -f`).\n\nIf any dependency or auth check fails, stop and ask the user to choose either:\nproceed with AI-assisted setup or abort this run now.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Prerequisites\n\nThis protocol receives all file paths as absolute paths from the invoking agent:\n\n- `$DRAFT_FILE` — the protocol draft to review (required)\n- `$REQUIREMENTS_FILE` — requirements document (optional)\n- `$FORMAT_REVIEW_FILE` — output path for format review verdict\n- `$STRANGER_REVIEW_FILE` — output path for stranger review verdict\n- `$DRAFT_CHECKSUM_FILE` — output path for the frozen checksum\n\nThe parent agent is responsible for choosing collision-free paths (e.g., under\n`$KAIROS_LOCAL_ARTIFACT_DIR` with a session-unique segment). This protocol only\nverifies paths exist via `test -f` and writes to the provided output paths.\n\nIf invoked directly, export the variables before proceeding.\n\n**Security:** never write credentials, tokens, or secrets into output files.\n\n## Format Review [SUBAGENT]\n\nDelegate format verification to a subagent. The subagent writes its verdict to\n`$FORMAT_REVIEW_FILE`.\n\n**Input:** `$DRAFT_FILE`\n\n**Subagent task:**\n1. Read the draft.\n2. Verify structure:\n   - H1 present exactly once\n   - first H2 is `Activation Patterns`\n   - last H2 is `Reward Signal`\n   - every middle H2 has a challenge block\n   - no duplicate H2 headings\n3. Verify authoring quality:\n   - explicit phase separation where relevant\n   - no hidden assumptions\n   - no vague filler such as \"as needed\" when a concrete instruction is required\n4. Verify challenge type selection using `challenge-type-guide`:\n   - no `comment` challenges for steps that create files, call tools, or check state\n   - `shell` challenges include `timeout_seconds`\n   - shell chains use `&&`, not `;`, except for the agent-readable shell status\n     trailer from `challenge-type-guide`\n5. Verify DRY, slug, and 350-line compliance.\n6. Write verdict to `$FORMAT_REVIEW_FILE`. First line MUST be\n   `PASS` or `FAIL`. Remaining lines list concrete fixes.\n\n**Output:** `$FORMAT_REVIEW_FILE`\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$FORMAT_REVIEW_FILE\\\" && head -1 \\\"$FORMAT_REVIEW_FILE\\\" | grep -qi 'pass'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n## Stranger Review [SUBAGENT]\n\nDelegate executability review to a subagent with junior AI agent persona. The\nsubagent writes its verdict to `$STRANGER_REVIEW_FILE`.\n\n**Input:** `$DRAFT_FILE`\n\n**Subagent task:**\n1. Assume persona: junior AI agent, first time encountering KAIROS protocols.\n2. Mocked dry-run: walk every step in order and produce structurally correct\n   challenge responses.\n3. Check:\n   - can I execute this without guessing?\n   - are phases clear?\n   - do I know when to stop, ask, execute, verify, or escalate uncertainty?\n   - are any variables or concepts undefined?\n4. Write verdict to `$STRANGER_REVIEW_FILE`. First line MUST be\n   `PASS` or `FAIL`. If FAIL, include specific failing mocks and missing context.\n\n**Output:** `$STRANGER_REVIEW_FILE`\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$STRANGER_REVIEW_FILE\\\" && head -1 \\\"$STRANGER_REVIEW_FILE\\\" | grep -qi 'pass'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n## Checksum Freeze [SUBAGENT]\n\nFreeze the draft after both reviews pass.\n\n**Input:** `$DRAFT_FILE`\n\n**Actions:**\n1. Compute md5 checksum of the draft file.\n2. Write checksum to `$DRAFT_CHECKSUM_FILE`.\n\n**Output:** `$DRAFT_CHECKSUM_FILE`\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"md5 -q \\\"$DRAFT_FILE\\\" > \\\"$DRAFT_CHECKSUM_FILE\\\" && test -s \\\"$DRAFT_CHECKSUM_FILE\\\"\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n## User Review [SUBAGENT]\n\nPresent the reviewed protocol to the user for final approval.\n\n**Input:** draft plus both review files\n\n**Actions:**\n1. Present full protocol markdown.\n2. Summarise pattern used, step count, challenge types, slug(s), and both review verdicts.\n3. Ask the user to approve, request changes, or cancel.\n\n**Output:** user approval, changes, or cancellation.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Review the protocol draft above. Type 'approved' to run train, describe adjustments, or 'cancel'.\"},\"required\":true}}\n```\n\n## Train adapter [SUBAGENT]\n\nVerify the draft is unchanged since checksum freeze, then call `train`.\n\n**Input:** approved `$DRAFT_FILE`\n\n**Actions:**\n1. Verify draft unchanged against checksum.\n2. Call `train` with `force_update: false` unless overwrite was explicitly requested.\n3. If router pattern: train router first, then extensions in order.\n4. Verify each `train` call returned a URI.\n5. Report stored adapter URI(s) back to the user.\n\n**Output:** confirmation with stored adapter URI(s)\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"train\"},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe user now has a trained KAIROS adapter that passed:\n1. format review\n2. stranger review\n3. checksum verification\n4. user approval\n5. successful storage via `train`\n\nThe resulting adapter is more likely to be truthful, phase-aware, and usable by\nweaker agents.\n",
-        "challenge-type-guide": "---\nversion: \"4.7.3\"\nslug: challenge-type-guide\ntitle: Challenge Type Selection Guide\n---\n\n\n\n# Challenge Type Selection Guide\n\nDecision rules, JSON formats, interpreter selection, and anti-patterns for\nchoosing KAIROS challenge types. Loaded by protocol-authoring agents during\ndrafting and review.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`create-new-protocol-review`.\n\n**Can be invoked directly when agent needs:**\n- \"challenge type reference\" / \"which challenge type to use\"\n- \"how to write shell challenges\" / \"challenge format\"\n- \"interpreter selection for challenges\"\n\n**Trigger pattern:** **challenge** + (type | format | selection | guide).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Select `comment` merely because it is easy.\n\n**Must Always:**\n- Be consulted before assigning challenge types to protocol steps.\n- Choose the strongest observable contract available.\n- Match challenge choice to the mode of the step: ask, decide, act, verify, or review.\n\n**Good trigger examples:**\n- drafting a new protocol and need challenge types → load this\n- reviewing challenge type selection in a draft → load this\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Review my protocol draft\" → use `create-new-protocol-review`\n\n## Core Rules\n\n`comment` is the challenge type of **last resort**. If a step produces any\nobservable artifact — a file, a git state change, an API response, or an exit\ncode — use `shell` or `mcp` instead.\n\n**Mode before challenge type:**\n- **clarify / approve** → `user_input`\n- **call a KAIROS / MCP tool** → `mcp`\n- **execute or verify local state** → `shell`\n- **pure reasoning with no observable artifact** → `comment`\n\n### Decision Tree\n\n```\nDoes the step call an MCP tool?\n ├─ YES → Is the step a chain link to another adapter?\n │         ├─ YES → \"mcp\" with tool_name + arguments (forward + slug URI)\n │         └─ NO  → \"mcp\" with tool_name only\n └─ NO → Does the step produce or verify a file, command result, or system state?\n          ├─ YES → \"shell\"\n          └─ NO → Does the step require human approval or choice?\n                   ├─ YES → \"user_input\"\n                   └─ NO → \"comment\" only if there is no stronger observable contract\n```\n\n### Challenge JSON Formats\n\n**shell**\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"<command>\",\"timeout_seconds\":30},\"required\":true}}\n```\n\n**mcp**\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"<tool>\"},\"required\":true}}\n```\n\n**mcp with arguments (chain link)**\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/<slug>\"}},\"required\":true}}\n```\n\nUse the `arguments` form when the step's purpose is to invoke a specific\nadapter via `forward`. The server validates that `solution.mcp.arguments`\nis a superset of the contract's `mcp.arguments` (subset/deep matching),\nproving the agent called the correct target — not just any `forward` call.\n\n**user_input**\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"<specific question>\"},\"required\":true}}\n```\n\n**comment**\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":50},\"required\":true}}\n```\n\n### Solution JSON Formats\n\nEvery solution, regardless of type, follows the same envelope:\n\n```json\n{\n  \"type\": \"<challenge_type>\",\n  \"outcome\": \"success | failure | skipped\",\n  \"evidence\": { /* type-specific proof data */ },\n  \"nonce\": \"<echo from contract>\",\n  \"proof_hash\": \"<echo from contract>\"\n}\n```\n\n**shell solution**\n```json\n{\n  \"type\": \"shell\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"exit_code\": 0,\n    \"stdout\": \"...\",\n    \"stderr\": \"\",\n    \"duration_seconds\": 1.2\n  }\n}\n```\n\n**mcp solution**\n```json\n{\n  \"type\": \"mcp\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"tool_name\": \"activate\",\n    \"arguments\": { \"query\": \"example search\" },\n    \"response\": { \"choices\": [...] }\n  }\n}\n```\n\n**user_input solution**\n```json\n{\n  \"type\": \"user_input\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"confirmation\": \"agreed. proceed\",\n    \"timestamp\": \"2026-05-18T14:49:00Z\"\n  }\n}\n```\n\n**comment solution**\n```json\n{\n  \"type\": \"comment\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"text\": \"Verified all 78 issues now have repo: labels.\"\n  }\n}\n```\n\n### Compatibility\n\nThe server also accepts older solution shapes where data is placed directly\nunder the type key (e.g. `{ \"type\": \"shell\", \"shell\": { \"exit_code\": 0 } }`)\ninstead of inside an `evidence` envelope. Always use the unified envelope with\n`outcome` and `evidence` for new protocols.\n\n## Interpreter Selection\n\n| Task | Use bash | Use perl | Use python3 |\n|---|---|---|---|\n| File exists, tool installed, git state | yes | no | no |\n| Simple content grep | yes | no | no |\n| Multi-line regex | no | yes | no |\n| Paragraph processing | no | yes | no |\n| JSON validation | maybe | yes | yes |\n| YAML / complex data structure checks | no | no | yes |\n\n**Rule of thumb:** if bash requires `while read`, `grep | awk`, or heavy quote\nescaping, rewrite in Perl. If you need imports for data formats, use Python.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Security and Working Directory Rules\n\nUse `$KAIROS_LOCAL_ARTIFACT_DIR` as the base directory for local handoff\nartifacts. File paths within it are provided as variables by the invoking agent\nto avoid collisions between parallel sessions.\n\n**Rules:**\n- all file paths in shell challenges reference variables (e.g., `$DRAFT_FILE`,\n  `$VERDICT_FILE`) set by the parent agent — never hardcode filenames\n- the parent agent constructs collision-free paths under\n  `$KAIROS_LOCAL_ARTIFACT_DIR` (e.g., with a session ID or random suffix)\n- when using KAIROS MCP, the latest `activate` / `forward` / `next` response field `kairos_local_artifact_dir` is an ordered array of URI hints (`project://<rel>`, `user://<rel>`); pick one (`project://` when you have exactly one project context, otherwise `user://`), resolve on your machine, and `export KAIROS_LOCAL_ARTIFACT_DIR=\"<absolute>\"` if your shell does not already define it\n- if the server-returned path is not usable on your local filesystem, resolve\n  locally to `$PROJECT_DIR/.local/kairos/work` and keep it stable for the run\n- prerequisites create the directory\n- Reward Signal cleans it up\n- never write credentials or secrets to files\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Composition Patterns\n\n**Multi-check compound command**\n- chain with `&&`\n- let the first failure stop execution\n\n**Agent-readable shell status**\n- use when failure can produce no output, especially `test`, quiet `grep`,\n  JSON probes, pipelines, or commands that redirect stderr\n- empty stdout or stderr is not success; success is the real process status\n  reported as `solution.shell.exit_code`\n- print the final status marker to stderr when stdout is machine-readable\n- preserve the original status exactly:\n  ```bash\n  ( set -o pipefail; <command> ); rc=$?; printf '\\nKAIROS_SHELL_EXIT=%s\\n' \"$rc\" >&2; exit \"$rc\"\n  ```\n- keep `&&` inside `<command>` for ordered checks; use the final\n  `; rc=$?; ...` trailer only to capture, print, and return the process status\n- do not use `<command> || echo ERROR && false`; shell operators group\n  left-to-right, so that form can fail after a successful command and it loses\n  the original status\n\n**Freeze-then-verify**\n- step N writes checksum\n- step N+1 verifies checksum before publish\n\n**Write-then-grep**\n- subagent writes a verdict file\n- main agent checks the first line for `PASS`\n\n**Phase-batch with critic**\n- batch related TODO items into one phase\n- verify hard artifacts with shell\n- then call `phase-critic` for adversarial review\n\n**Dry-run before execution**\n- dry-run command\n- human review\n- real command\n\n**Chain-link via forward + slug**\n- layer N's contract requires `forward` with a specific adapter slug\n- agent calls `forward` to start the next adapter (new `execution_id`)\n- next adapter runs its own layer chain through to `reward`\n- use when the protocol exceeds 350 lines or needs multi-path routing\n- NOT a replacement for layers — layers remain the primary unit of work\n- example contract:\n  ```json\n  {\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/implement-plan\"}},\"required\":true}}\n  ```\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. pick the correct challenge type for each protocol step\n2. match challenge type to the step's mode\n3. choose the right interpreter\n4. apply working-directory and security rules\n5. preserve real shell statuses for silent checks\n6. use stronger verification patterns instead of weak narrative checks\n",
-        "phase-critic": "---\nversion: \"4.7.3\"\nslug: phase-critic\ntitle: Phase Critic\n---\n\n\n\n# Phase Critic\n\nBounded adversarial investigator fired at phase boundaries. Receives a reference\ndocument, loads the calling protocol's invariants, and independently verifies\nthe verification target by extracting claims, gathering evidence, and searching\nfor contradictions.\n\n## Activation Patterns\n\n**Typically invoked by:** another protocol at the end of a plan, implement,\nvalidation, or review phase via `forward` with the stored adapter URI\n`kairos://adapter/phase-critic`.\n\n**Can be invoked directly when agent needs:**\n- \"review phase output\" / \"verify plan\" / \"audit implementation\"\n- \"adversarial review\" / \"critic review\"\n\n**Trigger pattern:** **review** / **verify** / **audit** / **critic** +\n(phase / plan / implementation / output).\n\n**Must Never:**\n- Modify any file outside the provided input and output paths.\n- Trust the executor's assertions without independent evidence.\n- Classify a claim as `verified` based only on absence of contradiction.\n- Keep investigating after a precondition failure that blocks verification.\n\n**Must Always:**\n- Extract claims before investigating.\n- Verify in-scope claims first.\n- Search for contradictory evidence, not only confirming evidence.\n- Include confidence in every verdict and failure class in every FAIL verdict.\n- Preserve the boundary between execution and review.\n\n**Good trigger examples:**\n- implement protocol fires this after planning → run this protocol\n- compose protocol fires this after output generation → run this protocol\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Implement a feature\" → use an execution protocol, not this one\n\n## Artifact Contract\n\nThis protocol receives:\n\n```text\n{\n  input_file: string,              // absolute path to the document under review\n  calling_protocol_slug: string,\n  verification_target: string,\n  context: {\n    operation: string,\n    verdict_file: string           // absolute path where the verdict will be written\n  }\n}\n```\n\nThis protocol produces:\n\n```text\n{\n  verdict: \"PASS\" | \"FAIL\",\n  confidence: \"High\" | \"Medium\" | \"Low\",\n  failure_class: string,\n  verdict_file: \"{context.verdict_file}\"\n}\n```\n\n## Precondition Check [SUBAGENT]\n\nVerify foundational preconditions before deep investigation. Early-abort if any\nare broken.\n\n**Input:** `$INPUT_FILE` (absolute path), calling protocol slug, context\n\n**Actions:**\n1. Verify the input file exists: `test -f \"$INPUT_FILE\"`.\n2. Verify the verdict output path is writable (parent directory exists).\n3. Load the calling protocol's Must Never / Must Always sections if possible.\n4. Verify the target state is available for review.\n5. Verify required tools are available.\n\n**On early-abort:**\n- verdict = `FAIL`\n- failure class = `verification_blocked`\n- confidence = `Low`\n- write focused diagnostics\n- skip all later steps\n\n**Output:** verified preconditions or early-abort diagnostics\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$INPUT_FILE\\\"\",\"timeout_seconds\":3},\"required\":true}}\n```\n\n## Audit [SUBAGENT]\n\nPerform bounded adversarial review of the target against the reference document\nand invariants.\n\n**Input:** reference document, invariants, verification target, context\n\n**Actions:**\n\n**Step 1 — Extract claims**\nExtract every verifiable claim that matters operationally:\n- workflows, commands, tool calls\n- configuration and environment variable claims\n- architecture claims that imply behaviour\n- guarantees and constraints\n- security, auth, and permission claims\n\n**Step 2 — Investigate with scope discipline**\n1. verify all in-scope claims first\n2. review high-risk claims with maximum depth\n3. expand beyond scope only when contradiction signals, dependencies, or\n   high-risk impact require it\n4. continue reviewing all in-scope claims even after a normal FAIL condition is met;\n   only a precondition failure stops the audit early\n\n**High-risk areas**\n- setup steps and prerequisites\n- CLI commands and flags\n- configuration keys and environment variables\n- authentication, identity, and permissions\n- deployment and release behaviour\n- external publishing actions\n- destructive or irreversible operations\n\n**Step 3 — Gather evidence using the hierarchy**\n\n| Priority | Evidence source |\n|---|---|\n| 1 | source code, config files, schemas, route definitions |\n| 2 | direct runtime verification |\n| 3 | tests |\n| 4 | MCP-queried system state |\n| 5 | external docs, web pages, linked references |\n| 6 | conversational assumption or indirect inference |\n\n**Rules:**\n- higher-priority evidence overrides lower-priority evidence\n- priority 5–6 alone is not enough for `verified`\n\n**Step 4 — Produce claim verdicts**\n\nFor each claim, record:\n- CLAIM\n- EVIDENCE\n- EVIDENCE PRIORITY\n- VERDICT: `verified` / `partially_verified` / `unverifiable` / `incorrect`\n\nA claim must not be marked `verified` without positive supporting evidence.\n\n**Step 5 — Review the phase boundary**\nCheck whether the calling protocol preserved the right mode boundary:\n- was execution reviewed independently?\n- were review and execution kept separate?\n- did the protocol switch to verification when it should have?\n- is escalation needed because certainty was overstated?\n\n**Output:** structured audit findings for the verdict step\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## Verdict [SUBAGENT]\n\nTurn the audit into a final PASS / FAIL result.\n\n**Input:** audit findings and verdict file path from context (use it as\n`$VERDICT_FILE`)\n\n**Actions:**\n1. Fail if any critical claim is incorrect.\n2. Fail if verification was blocked.\n3. Fail if the evidence base is too weak for high-risk claims.\n4. Otherwise, pass with the appropriate confidence.\n5. Write `$VERDICT_FILE` so line 1 is `PASS` or `FAIL`,\n   line 2 is `High`, `Medium`, or `Low`, and the remaining lines summarise key\n   findings.\n\n**Output:** final verdict file\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$VERDICT_FILE\\\" && head -1 \\\"$VERDICT_FILE\\\" | grep -qiE '^(PASS|FAIL)$' && sed -n '2p' \\\"$VERDICT_FILE\\\" | grep -qiE '^(High|Medium|Low)$'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe phase output has been independently challenged. The resulting verdict is more\ntruthful because it is based on extracted claims, explicit evidence, contradiction\nsearch, and a clean boundary between execution and review.\n",
-        "protocol-linking-guide": "---\nversion: \"4.7.3\"\nslug: protocol-linking-guide\ntitle: Protocol Linking Guide\n---\n\n\n\n# Protocol Linking Guide\n\nDecision rules for structuring adapter relationships: layers vs chains,\n`activate` vs `forward` + slug, chain-root collapsing, and MCP argument\nvalidation for deterministic cross-protocol linking.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`create-new-protocol-review`.\n\n**Can be invoked directly when agent needs:**\n- \"layers vs chains\" / \"when to split into multiple adapters\"\n- \"how to link adapters\" / \"cross-protocol linking\"\n- \"activate vs forward\" / \"when to use forward with slug\"\n- \"chain-root collapsing\" / \"how chain_root works\"\n\n**Trigger pattern:** **layers** / **chains** / **linking** / **forward** +\n(slug | adapter | protocol).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Recommend chaining when layers suffice.\n\n**Must Always:**\n- Be consulted before splitting a protocol into multiple adapters.\n- Be consulted before adding `forward` calls or `chain_root` frontmatter.\n\n**Good trigger examples:**\n- \"my protocol is 400 lines, should I split?\" → load this\n- \"how do I link adapter A to adapter B?\" → load this\n- \"what is chain_root?\" → load this\n\n**Bad trigger examples:**\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n- \"create a new protocol\" → use `create-new-protocol`\n\n## Layers vs Chains\n\n**Layers** (H2 steps within one adapter) are the preferred unit of work. Use\nlayers when all steps fit in one adapter under 350 lines and serve a single\ncohesive concern.\n\n**Chain via `forward` + slug** — use only when:\n- the adapter exceeds 350 lines\n- weaker models cannot follow the full adapter in one pass\n- runtime routing to different adapters is needed (Router pattern)\n- a step is reusable across multiple parent adapters (e.g. `phase-critic`)\n\nChaining is NOT a replacement for layers. A 6-step protocol that fits in 350\nlines should stay as one adapter with 6 H2 layers.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## `activate` vs `forward` + slug\n\n| Situation | Use |\n|---|---|\n| Initial user-intent resolution | `activate` |\n| Target adapter is known at authoring time | `forward` + slug |\n| Target depends on runtime classification the current adapter cannot resolve | `activate` |\n| Linking to the next adapter in a chain | `forward` + slug |\n| Reusable sub-protocol invoked by multiple parents | `forward` + slug |\n\nNever call `activate` just to get a slug you already know — it wastes a\nround-trip and introduces non-determinism.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Chaining Back and Forward\n\nWhen a family of adapters has a root conductor and smaller domain extensions,\ndocument both directions of chaining.\n\n### Chaining back with `chain_root`\n\nExtension adapters should include `chain_root` frontmatter and a prerequisite\nclause:\n\n**Prerequisite:** Start from `<root-adapter-slug>` unless the caller already\nprovided a mission brief, safety gates, authorization boundary, and evidence\nrequirements.\n\nThis protects activation entry points. If a user or weak agent activates a\nmid-chain extension directly, the extension can collapse back to the root unless\nit already received the required parent context.\n\n### Chaining forward with `forward`\n\n`chain_root` does not replace explicit `forward` calls inside the chain.\n\nWhen the next adapter is known at authoring time or after deterministic runtime\nclassification, use `forward` with the target slug. Do not call `activate` just\nto rediscover a slug already known by the current adapter.\n\nForwarded adapters should receive:\n- current mission brief;\n- safety gates;\n- authorization boundary;\n- evidence requirements;\n- user constraints;\n- reason for forwarding.\n\nUse `activate` only when the next adapter must be discovered from an ambiguous\nruntime need.\n\n### Multi-layer conductors and extension URIs\n\nWhen you are executing **`forward`** inside a **multi-layer** adapter (for example\na root conductor), each continuation follows **`next_call`** for the **same**\n`execution_id` until the last layer directs **`reward`**. A layer that mentions\nanother adapter URI only as routing guidance — for example\n`kairos://adapter/e2e-coding-pr-delivery` — does **not** cause the server to\nswitch executions: the next **`forward`** in that run still advances the\n**current** adapter’s next layer.\n\nTo run an extension adapter, call **`forward`** with\n`kairos://adapter/<slug>` as a **new** first call (adapter URI; omit\n`solution`). That starts a **separate** execution with its own layers. Common\npattern: complete the conductor with **`reward`**, then **`forward`** to the\nextension slug when coding or PR-shaped work should run under that adapter’s\ncontracts.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## System adapters vs user adapters\n\nBoth system and user-authored adapters chain using slugs in `next_action`:\n\n```text\ncall forward with kairos://adapter/phase-critic ...\ncall forward with kairos://adapter/implement-terraform ...\n```\n\nSlugs are globally unique (enforced by `train`), so resolution is\ndeterministic — no scoring, no ambiguity.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## MCP argument validation for chain links\n\nA bare `mcp` contract checks only the tool name:\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\"},\"required\":true}}\n```\n\nAn `mcp` contract **with `arguments`** verifies the exact target:\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/code-review-policy\"}},\"required\":true}}\n```\n\nThe server validates that `solution.mcp.arguments` is a superset of the\ncontract's `mcp.arguments` (subset/deep matching). This proves the agent\ncalled `forward` with the correct slug, not just any `forward` call.\n\nUse the `arguments` form whenever a step's purpose is to invoke a specific\nknown adapter.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Chain-root collapsing\n\nWhen a chain has multiple adapters, `activate` might match a mid-chain adapter\ndirectly. Without protection, the agent would start at the wrong step, missing\nprerequisite context gathered by earlier phases.\n\n**`chain_root` frontmatter field** solves this at the server level. Add it to\nevery mid-chain adapter:\n\n```yaml\n---\nslug: implement-plan\nversion: 1.0.0\nchain_root: implement\n---\n```\n\n**Server behaviour:** When `activate` returns a match that has `chain_root`,\nthe server resolves the slug to the root adapter's URI and replaces the\nchoice's `uri` and `next_action` to point there. Multiple mid-chain matches\nfrom the same chain are deduplicated to a single entry. The agent always\nstarts at the chain entry point.\n\n**Defense in depth — protocol-level safeguards:** Each mid-chain adapter\nshould include a **Prerequisites** paragraph in its Activation Patterns\nlisting inputs required from earlier phases and directing the agent to start\nfrom the chain root if those inputs are missing. This catches direct `forward`\ncalls that bypass `activate`.\n\n**Rules:**\n- The chain root adapter must NOT have `chain_root` in its frontmatter.\n- `chain_root` must refer to an existing slug (the chain entry point).\n- `forward` calls within a chain are unaffected — `chain_root` only changes\n  `activate` output routing.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. decide when to use layers vs chains\n2. choose `activate` vs `forward` + slug correctly\n3. use slug-based linking for all adapters (system and user)\n4. apply MCP argument validation for deterministic chain links\n5. implement `chain_root` collapsing with defense-in-depth safeguards\n6. document chaining back (`chain_root` + prerequisites) and chaining forward\n   (`forward` with known slugs) for root + extension families\n",
-        "bulk-insert-adapters-via-cli": "---\nslug: bulk-insert-adapters-via-cli\nversion: \"4.7.3\"\ntitle: Bulk Insert Adapters via KAIROS CLI\n---\n\n# Bulk Insert Adapters via KAIROS CLI\n\n## Activation Patterns\n\nBatch-register multiple KAIROS adapters from a local directory tree using the\n`kairos train` CLI. Handles directory scanning, validation, space targeting,\nand error recovery for bulk operations.\n\n**Run this protocol when the user says ANY of:**\n\n- \"bulk insert adapters\" / \"bulk train adapters\"\n- \"train all protocols in a directory\"\n- \"batch register adapters from folder\"\n- \"upload all .md files to KAIROS\"\n- \"sync local protocols to KAIROS\" / \"push protocols to KAIROS\"\n- \"train directory recursively\" / \"train --recursive\"\n\n**Trigger pattern:** **bulk** / **batch** / **all** / **directory** / **recursive** +\n(train | insert | register | upload | push | sync) + (adapters | protocols).\n\n**Must Never:**\n\n- Train files without first validating their structure.\n- Overwrite existing adapters without explicit user confirmation (`--force`).\n- Train files that contain secrets or token-like strings without `--allow-sensitive-upload`.\n- Skip reporting partial failures in a batch.\n\n**Must Always:**\n\n- Verify the target directory exists and contains `.md` files.\n- Show the user the file list and target space before executing.\n- Report per-file success/failure after the batch completes.\n- Respect the user's choice of space (personal or group).\n\n**Good trigger examples:**\n\n- \"Train all adapters in kairos-v4/_personal/\" → run this protocol\n- \"Bulk insert the protocols from my export folder\" → run this protocol\n- \"Push all .md files in this directory to my personal space\" → run this protocol\n\n**Bad trigger examples:**\n\n- \"Train this one protocol\" → use `kairos train <file>` directly\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Export my adapters\" → use `kairos export`\n\n## Preflight Dependencies\n\nVerify before execution:\n\n1. `kairos` CLI is installed and callable (`kairos --version`).\n2. Authentication is valid (`kairos token` returns a token without error).\n3. Target directory path exists and contains at least one `.md` file.\n4. If a space is specified, confirm it exists via `kairos spaces`.\n\nIf any check fails, stop and report the issue with remediation guidance.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"kairos --version && kairos token > /dev/null 2>&1 && echo 'auth: ok'\",\"timeout_seconds\":15},\"required\":true}}\n```\n\n## Confirm Scope\n\nPresent the batch operation details to the user:\n\n1. **Source directory** — absolute path.\n2. **File count** — number of `.md` files found (recursive or flat).\n3. **Target space** — personal (default) or a named group space.\n4. **Force mode** — whether `--force` will be used (overwrites existing).\n5. **Model attribution** — which `--model` value to use.\n\nList the files that will be trained and ask for confirmation.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Confirm batch scope: directory, file list, target space, force mode, and model ID\"},\"required\":true}}\n```\n\n## Validate Structure\n\nBefore training, validate each `.md` file against KAIROS adapter requirements:\n\n- Has an H1 title.\n- First H2 is \"Activation Patterns\".\n- Last H2 is \"Reward Signal\".\n- Contains at least one fenced `json` block with a top-level `contract` object.\n- Does not exceed 350 lines.\n\nReport any files that fail validation. Ask user whether to:\n- skip invalid files and proceed with valid ones\n- abort and fix issues first\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"echo 'Validation complete — see output above for results'\",\"timeout_seconds\":30},\"required\":true}}\n```\n\n## Execute Bulk Train\n\nRun the batch train operation using the KAIROS CLI:\n\n```\nkairos train <directory> --recursive --model <model> --space <space> [--force]\n```\n\nIf the directory contains files that should NOT be trained (README, reference\ndocs), either:\n- train file-by-file for the valid subset, or\n- move non-adapter files out before running `--recursive`\n\nCapture stdout and stderr. The CLI reports per-file status.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"kairos train <directory> --recursive --model <model_id> --space <space>\",\"timeout_seconds\":120},\"required\":true}}\n```\n\n## Report Results\n\nSummarise the batch outcome:\n\n| Metric | Value |\n|--------|-------|\n| Files attempted | N |\n| Successfully trained | N |\n| Failed | N |\n| Skipped (invalid) | N |\n\nFor each failure, report:\n- File path\n- Error message\n- Suggested fix\n\nIf all succeeded, confirm adapter URIs are accessible via `kairos spaces`.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nProtocol complete when:\n- All valid adapter files in the target directory have been trained to the\n  specified space.\n- Per-file results have been reported to the user.\n- Any failures have been documented with remediation guidance.\n\nA successful bulk insert means the user's local protocol library is now\nregistered in KAIROS and available for activation by AI agents.\n",
-        "skill-format-guide": "---\nversion: \"4.7.3\"\nslug: skill-format-guide\ntitle: Skill Format and Local Authoring Guide\n---\n\n\n\n# Skill Format and Local Authoring Guide\n\nDecision rules for authoring SKILL.md files, choosing between local (git) and\nserver (KAIROS) storage, and quality gates for skill content. Loaded by\nprotocol-authoring agents during drafting and review when the output format is\n`skill`.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`create-new-protocol-review`.\n\n**Can be invoked directly when agent needs:**\n- \"SKILL.md format reference\" / \"how to write a skill\"\n- \"skill vs adapter\" / \"local skill or KAIROS adapter\"\n- \"skill quality gates\" / \"SKILL.md structure\"\n- \"project-level skill\" / \"where to put a skill\"\n\n**Trigger pattern:** **skill** + (format | structure | guide | quality | local).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Recommend storing a skill in both git AND KAIROS server simultaneously.\n- Confuse SKILL.md (agent instruction file) with protocol markdown (adapter).\n\n**Must Always:**\n- Be consulted before writing any SKILL.md file.\n- Enforce single source of truth: each skill lives in exactly one place.\n- Match storage location to the skill's scope and discoverability needs.\n\n**Good trigger examples:**\n- drafting a new skill and need format rules → load this\n- reviewing a SKILL.md for quality → load this\n- deciding local vs server for a skill → load this\n\n**Bad trigger examples:**\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n- \"create a new protocol\" → use `create-new-protocol`\n\n## Storage Decision\n\nEvery skill has ONE home. Choose at authoring time. Never both.\n\n| Scope | Storage | Discovery | Source of Truth |\n|---|---|---|---|\n| Project-specific (deploy, test, release) | Git: `.agents/skills/{name}/` or `.cursor/skills/{name}/` | IDE host scans description field | Git repo |\n| Personal cross-project (universal) | KAIROS server via `train` | `activate` embedding search | KAIROS server |\n| Team/group shared | KAIROS server (group space) | `activate` | KAIROS server |\n\n### Decision Tree\n\n```\nIs this skill specific to ONE project's codebase?\n ├─ YES → Does it reference repo files, paths, or project-specific tools?\n │         ├─ YES → LOCAL (git)\n │         └─ NO  → Could it help in other projects?\n │                   ├─ YES → SERVER (KAIROS)\n │                   └─ NO  → LOCAL (git)\n └─ NO → SERVER (KAIROS)\n```\n\n### Local Storage Paths\n\n| Host | Path | Scope |\n|---|---|---|\n| Cursor IDE (project) | `.cursor/skills/{name}/SKILL.md` | Repo-scoped, git-controlled |\n| Cursor IDE (personal) | `~/.cursor/skills/{name}/SKILL.md` | User-wide, all projects |\n| Claude Code (project) | `.agents/skills/{name}/SKILL.md` | Repo-scoped, git-controlled |\n| Claude Code (personal) | `~/.agents/skills/{name}/SKILL.md` | User-wide, all projects |\n\n**Never** create skills in `~/.cursor/skills-cursor/` — reserved for system.\n\n### Promotion and Demotion\n\n**Local → Server (skill graduates to universal):**\n1. Read existing SKILL.md\n2. Optionally wrap in protocol structure (Activation Patterns, contracts)\n3. `train` to KAIROS server\n4. Delete local copy or mark deprecated\n5. Git commit the deletion\n\n**Server → Local (adapter becomes project-specific):**\n1. `export` with `format: skill_zip` or `format: markdown`\n2. Write to `.agents/skills/{slug}/SKILL.md`\n3. Optionally `delete` from server\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## SKILL.md Structure Rules\n\n### Required YAML Frontmatter\n\n```yaml\n---\nname: lowercase-hyphenated-name\ndescription: >-\n  Third-person description of WHAT it does and WHEN to use it.\n  Include trigger terms. Max 1024 chars.\n---\n```\n\n| Field | Constraint | Purpose |\n|---|---|---|\n| `name` | Max 64 chars, `[a-z0-9-]` only | Unique identifier |\n| `description` | Non-empty, max 1024 chars | Discovery by IDE and agents |\n| `disable-model-invocation` | Boolean, default `true` | Explicit load only |\n\n### Body Structure\n\n```markdown\n# Skill Title\n\n## Instructions\n[Core workflow — step-by-step, imperative voice]\n\n## Examples\n[Concrete usage examples with inputs and expected outputs]\n\n## Additional Resources\n- [reference.md](reference.md) — detailed documentation (optional)\n- [scripts/helper.sh](scripts/helper.sh) — utility scripts (optional)\n```\n\n### Directory Layout\n\n```\nskill-name/\n├── SKILL.md              # Required\n├── SHA256SUMS            # Required for KAIROS-exported skills\n├── reference.md          # Optional — detailed docs\n├── examples.md           # Optional — usage examples\n└── scripts/              # Optional — utility scripts\n    └── validate.sh\n```\n\n### Size and Depth Limits\n\n- **SKILL.md body:** under 500 lines\n- **Reference depth:** one level only (SKILL.md → reference.md, never deeper)\n- **Progressive disclosure:** essential info in SKILL.md, details in references\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Quality Gates\n\n### Description Quality\n\nThe description is the primary discovery mechanism. It must:\n\n1. Be written in **third person** (not \"I can help\" or \"you can use\")\n2. State **WHAT** the skill does (specific capabilities)\n3. State **WHEN** to use it (trigger scenarios, file patterns, keywords)\n4. Include **trigger terms** that match real user language\n5. Avoid vague words: \"helps with\", \"assists\", \"various\"\n\n**Good:**\n```yaml\ndescription: >-\n  Validate and publish Confluence pages managed as local markdown via Mark CLI.\n  Use when the user asks to dry-run, validate, publish, or sync a Confluence\n  page, or when working with files under confluence/ that have Mark metadata.\n```\n\n**Bad:**\n```yaml\ndescription: Helps with Confluence stuff.\n```\n\n### Content Quality\n\n| Check | Rule |\n|---|---|\n| Consistent terminology | One term per concept throughout |\n| No time-sensitive info | No \"before August 2025\" conditions |\n| Concrete examples | Real inputs/outputs, not abstract |\n| Actionable instructions | Agent knows what to DO, not just what exists |\n| Default tool choice | One recommended tool, escape hatch for alternatives |\n| No Windows paths | Forward slashes only |\n\n### Degree of Freedom\n\nMatch instruction specificity to the task's fragility:\n\n| Level | When | Example |\n|---|---|---|\n| High (text guidelines) | Multiple valid approaches | Code review guidelines |\n| Medium (templates/pseudocode) | Preferred pattern, acceptable variation | Report generation |\n| Low (exact scripts) | Fragile operations, consistency critical | DB migrations |\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Finalisation Paths\n\n### Path A: Local Write (project-level skill)\n\nWhen `{target}=local`:\n\n1. Determine output path from scope:\n   - Project Cursor: `.cursor/skills/{name}/SKILL.md`\n   - Project Claude: `.agents/skills/{name}/SKILL.md`\n   - Personal: `~/.cursor/skills/{name}/SKILL.md` or `~/.agents/skills/{name}/`\n2. Create directory if needed\n3. Write SKILL.md with frontmatter and body\n4. Generate `SHA256SUMS` (GNU sha256sum format, paths relative to skill dir)\n5. Write any reference files and scripts\n6. Verify: `test -f \"{path}/SKILL.md\" && wc -l \"{path}/SKILL.md\"`\n7. Report path and line count to user\n\nDo NOT call `train`. The skill lives only in git.\n\n### Path B: Server Train (KAIROS-routable adapter)\n\nWhen `{target}=server`:\n\n1. Wrap skill content in protocol markdown if needed:\n   - Add Activation Patterns (first H2)\n   - Add contract blocks per layer\n   - Add Reward Signal (last H2)\n2. Call `train` with full markdown\n3. Verify adapter URI returned\n4. Report URI and slug to user\n\nDo NOT write to local disk. The adapter lives only in KAIROS.\n\n### Path C: Hybrid Authoring (skill that is also an adapter)\n\nWhen `{target}=hybrid` (rare — use only when explicitly requested):\n\n1. Author as a KAIROS protocol (Activation Patterns, contracts, Reward Signal)\n2. `train` to server\n3. `export` with `format: skill_zip` to produce local SKILL.md bundle\n4. The exported SKILL.md is a **read-only derived artifact**, not a source of truth\n5. Document in the SKILL.md header that it was exported from KAIROS\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. Choose the correct storage location for a skill\n2. Author SKILL.md with valid frontmatter and structure\n3. Apply quality gates to descriptions and content\n4. Finalize via local write OR server train (never both)\n5. Produce SHA256SUMS for integrity verification\n"
+        "create-new-protocol": "---\nslug: create-new-protocol\nversion: \"4.8.0-beta.0\"\ntitle: Create / Review / Refactor KAIROS Protocol\n---\n\n\n\n# Create / Review / Refactor KAIROS Protocol\n\n> **Note to the agent:** KAIROS protocols are interfaces for AI agents — you\n> are the primary user. When you author a protocol, you design behaviour for\n> yourself and others. Write for them: single source of truth (never duplicate\n> rules), explicit over implicit (agents fill ambiguity with hallucination),\n> phases teach modes (each step teaches its cognitive mode), truth over fluency\n> (a protocol that reads well but causes wrong behaviour is worse than one that\n> reads rough but executes correctly).\n\n## Activation Patterns\n\nKAIROS authoring lifecycle — create, review, or update adapters / protocols / workflows.\nIn this context, those words refer to the same stored artifact and can be treated\nas synonyms. Supports three operations:\n\n- **create** — draft and train a new adapter / protocol from scratch.\n- **review** — audit an existing adapter, family, or bundle for structural issues,\n  missing cross-references, chaining gaps, DRY violations, stale guidance, or\n  agent-hostile ambiguity. Read-only.\n- **update** — apply specific corrections to an existing adapter / protocol and\n  re-train. Also triggered by: edit, fix, modify, change, improve, patch, refactor.\n\n**Run this protocol when the user says ANY of:**\n\n- \"create a new KAIROS protocol\" / \"create new protocol adapter\"\n- \"register personal KAIROS adapter\" / \"register a personal adapter\"\n- \"train adapter into personal\" / \"train protocol into personal\"\n- \"train a workflow\" / \"register a new adapter\" / \"create a new workflow\"\n- \"review protocol\" / \"audit adapters\" / \"check protocol families for gaps\"\n- \"update adapter\" / \"edit adapter\" / \"fix protocol\" / \"modify adapter\"\n- \"patch protocol\" / \"refactor protocol\" / \"change adapter\" / \"improve adapter\"\n- \"create new protocol\" (when `activate` found no match and user confirms)\n\n**Trigger pattern:** **create** / **train** / **register** / **review** /\n**audit** / **fix** / **update** / **edit** / **modify** / **change** /\n**improve** / **patch** / **refactor** / **correct** +\n(protocol / adapter / workflow).\n\n**Must Never:**\n- Run when the user only asked to execute an existing protocol.\n- Mutate adapters during a `review` operation.\n- Optimise only for pretty wording; this protocol designs agent behaviour.\n- Treat \"update\", \"edit\", or \"modify an existing adapter\" as the **update**\n  operation — never as create.\n\n**Must Always:**\n- Infer `{operation}` from trigger: create / review / update.\n  When the user says \"update\", \"edit\", \"modify\", or \"fix\" → operation is **update**.\n- Optimise for truth, low ambiguity, explicit sequencing, and user-need alignment.\n- Design or review phase transitions explicitly: discovery, clarification,\n  ideation, planning, execution, validation, review, handoff.\n- Include Activation Patterns as the first H2 and Reward Signal as the last H2\n  in any newly drafted adapter.\n- Enforce the 350-line limit per file.\n\n**Good trigger examples:**\n- \"Create a new KAIROS protocol for code review\" → run this protocol (create)\n- \"No match found; I want to create a new protocol\" → run this protocol (create)\n- \"Review all v4 protocol families for missing cross-references\" → run this protocol (review)\n- \"Update the MR adapter to include a review step\" → run this protocol (update)\n- \"Edit the phase-critic adapter triggers\" → run this protocol (update)\n- \"Refactor the MR adapter to be less ambiguous\" → run this protocol (update)\n\n**Bad trigger examples:**\n- \"Run the standardise project protocol\" → use activate / forward\n- \"Search for deployment protocol\" → use activate\n- \"Create an MR\" → use the MR adapter, not this protocol\n\n## Preflight Dependencies\n\nBefore running authoring actions, verify dependency and auth readiness for this\nrun:\n\n1. Required MCP tools are available and reachable: `activate`, `forward`,\n   `reward`, and the operation-dependent tool (`train`, `export`, or `tune`).\n2. Required CLI tools for planned shell steps are installed and callable.\n3. Required auth/session state is valid for the target MCP server.\n\nIf any check fails, stop before main execution and ask the user to choose one:\n- proceed with AI-assisted setup and then resume\n- abort this protocol run now\n\nDo not continue to intent confirmation until preflight passes.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Confirm Intent\n\nInfer `{operation}` from the user's trigger:\n\n| Signal | Operation |\n|---|---|\n| \"create\", \"new\", \"train\", no match from activate | **create** |\n| \"review\", \"audit\", \"check\", \"gaps\", \"cross-references\" | **review** |\n| \"update\", \"edit\", \"fix\", \"modify\", \"change\", \"improve\", \"patch\", \"refactor\", \"add missing\", \"correct\" | **update** |\n\nFor `create`: ask whether to create a new protocol or refine the search.\nFor `review`: ask which adapter(s), family, or bundle to review.\nFor `update`: ask which adapter to update and what the issue is.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Confirm operation and target\"},\"required\":true}}\n```\n\n## Gather Requirements\n\n### For `create` — collect details for a new protocol\n\n**1. Determine the pattern:**\n\n| Signal | Pattern |\n|---|---|\n| One workflow, no variants | **Standalone** — one protocol, all steps inline |\n| Multiple issue types / output formats / media | **Router + Extensions** — router classifies, routes via `activate` |\n| Domain has a decision tree | **Router + Extensions** |\n| Single workflow but exceeds 350 lines or too complex for weaker models | **Chain** — split into sequential adapters linked via `forward` + slug |\n| Reference material needed by steps | Extract to a separate file, not a protocol |\n\n**2. Collect per protocol:**\n\n- **Title** — clear, descriptive H1.\n- **User problem** — what real problem does this solve?\n- **Agent behaviour** — what behaviour should this create in the agent?\n- **Mode map** — which steps are for discovery, clarification, ideation,\n  planning, execution, validation, review, or handoff?\n- **Steps** — each H2 must earn its place and end with a challenge.\n- **Challenge type per step** — use the strongest observable contract possible.\n- **Domain reference** — guides / docs the protocol should load.\n- **Existing protocols** — reuse, compose, or extract shared content.\n- **DRY / size check** — extract duplicated content; split if >350 lines.\n- **Chain position** — entry, middle, or exit? What slug does the previous link forward to?\n- **Failure analysis** — where would a weaker agent misread this protocol?\n\n**3. If Router pattern:** variants, classification questions, forbidden types,\nand which parts stay in the router vs extensions.\n\n**4. If Chain pattern:** Load `protocol-linking-guide` for full rules\n(`forward` with `kairos://adapter/protocol-linking-guide`). Collect: chain\nlinks and concerns, minimum number of links, entry point (matched by\n`activate`), and artifacts flowing between links.\n\n### For `review` — audit existing adapters against this checklist\n\nExport target adapter(s). For each adapter, check:\n\n1. **User-need fit** — does the adapter solve a real user problem, or merely\n   mirror literal wording?\n2. **Mode / phase clarity** — are discovery, clarification, ideation,\n   execution, validation, and review clearly separated?\n3. **Cross-reference completeness** — are all required related adapters linked?\n4. **Adapter handoff gaps** — does it hand off where another adapter should own\n   the work?\n5. **DRY violations** — is policy content duplicated instead of linked?\n6. **Contract coverage** — does every executable H2 have the right contract?\n7. **Truth-first behaviour** — does it reduce guessing, fake certainty, and\n   silent assumption-making?\n8. **Activation pattern accuracy** — do triggers match what users actually say?\n9. **Structure compliance** — first H2 Activation Patterns, last H2 Reward\n   Signal, no duplicate H2s, under 350 lines.\n10. **Sibling consistency** — are equivalent steps present across sibling\n    adapters in the same family?\n11. **Chained adapter families** (when applicable) — extension adapters include\n    `chain_root` and a prerequisite clause pointing at the root; parent adapters\n    use explicit `forward` when the next adapter slug is already known; reserve\n    `activate` for ambiguous runtime discovery (see `protocol-linking-guide`,\n    **Chaining Back and Forward**).\n12. **Phase-critic integration** — does the adapter include phase-critic chain\n    links at major phase boundaries? Does each phase-critic invocation have a\n    FAIL gate shell contract (`grep -qi '^PASS$'` on the verdict file)? Are\n    solution checks restricted to irreversible remote mutations (see\n    `phase-critic-guide`)?\n\n### For `update` — identify the specific issue\n\nExport the target adapter, read the current markdown, identify the exact gap or\nerror, and plan the minimal change. Do not alter unrelated layers.\n\nSummarise gathered requirements or findings.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Draft Markdown\n\n### For `create` — draft new adapter markdown\n\nDraft the full markdown for `train`.\n\n### For `review` — draft findings report\n\nWrite a structured gap report to `$REVIEW_FINDINGS_FILE` (an absolute path\nprovided by the invoking agent or chosen by you under\n`$KAIROS_LOCAL_ARTIFACT_DIR` with a session-unique segment). For each finding\ninclude:\n\n- adapter title\n- gap type\n- severity\n- why the issue matters for AI-agent behaviour\n- specific recommended fix\n\n### For `update` — draft corrected adapter markdown\n\nApply the identified change and show a diff-style summary of what changed.\n\n### Shared drafting rules (all operations)\n\n**Core KAIROS rule — right mode at the right time:**\n\nEvery protocol must help the agent recognise whether the current step is for\nexploration, clarification, ideation, planning, execution, validation, review,\nor handoff. Do not blur those modes.\n\n**Truth over fluency:**\n\nDesign protocols to reduce guessing and fake certainty. Prefer explicit prompts,\nexplicit stop conditions, explicit uncertainty escalation, and observable\nverification over narrative reassurance.\n\n**User need over literal phrasing:**\n\nThe protocol should help the agent provide what the user actually needs, not\njust echo the wording used in the request.\n\n**DRY:**\n\nShared content across protocols must live in one place. If two protocols share\n>50% of their body, extract shared logic.\n\n**350-line maximum per file:**\n\nNo protocol file may exceed 350 lines. If it grows beyond that, split it into\nlinked adapters or extract a reference file.\n\n**Generic-first — create generic, link from detailed:**\n\nCreate protocols from generic to detailed. The generic adapter must stand alone.\nExtensions should contain only the delta.\n\n**Slug convention — deterministic protocol linking:**\n\nEvery protocol gets a short, unique, lowercase-hyphenated `slug`.\n\n**Artifacts:**\n\nStore scripts or config blobs as artifacts via `train` (set `mime`,\n`artifact_name`, `adapter_uri`). Retrieve with `export` using\n`kairos://artifact/{uuid}`.\n\n**Protocol structure:** H1 title, first H2 Activation Patterns, second H2\nPreflight Dependencies, middle H2s one per step with JSON contract block, last\nH2 Reward Signal. Frontmatter: `slug` (required), `version` (optional),\n`chain_root` (required for mid-chain adapters).\n\n**Challenge types:** Load `challenge-type-guide` for decision rules and JSON\nformats (`forward` with `kairos://adapter/challenge-type-guide`).\n\n**Phase-critic and mutation gates:** Load `phase-critic-guide` for placement,\nFAIL gate, and solution check rules (`forward` with `kairos://adapter/phase-critic-guide`).\n\n**If Router pattern:** draft the router and each extension as separate files.\n\nPost the full drafted markdown.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## Phase-Critic Review (create and update only)\n\nFor `create` and `update`: run phase-critic against the drafted markdown before\npresenting to the user. This is the quality gate — the agent owns content, the\ncritic owns quality.\n\n1. Invoke phase-critic via `forward` with `kairos://adapter/phase-critic`.\n   Provide the drafted markdown as `input_file`, the slug as\n   `calling_protocol_slug`, and \"structural compliance and agent behaviour\"\n   as `verification_target`.\n2. Run the FAIL gate shell contract on the verdict file:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n3. If FAIL: address findings, re-invoke phase-critic. Do NOT proceed.\n4. If PASS: capture the verdict file path for the `review_evidence` field\n   in the `train` call below.\n\nFor `review`: skip this step (read-only operation).\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## User Review\n\nFor `create`: present the drafted protocol(s) and the phase-critic verdict.\nUser acknowledges (informational, not an approval gate).\n\nFor `review`: present the findings report and ask which findings to act on.\n\nFor `update`: present the corrected markdown, change summary, and critic verdict.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Acknowledge the draft and verdict (create/update) or review findings\"},\"required\":true}}\n```\n\n## FinaliseOperation\n\nFor `create`: call `train` with the drafted markdown and `review_evidence`\nfrom the phase-critic step. Use `force_update: false` unless overwrite was\nexplicitly requested.\n\nFor `review`: do not call `train`. Save the findings report only if requested.\n\nFor `update`: call `train` with `force_update: true`, `review_evidence` from\nthe phase-critic step, and update the corresponding repo file.\n\nReport the outcome: adapter URI(s) for create / update, or findings summary for\nreview.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nProtocol complete when:\n- `create` — adapter(s) stored via `train` (with review_evidence) and URI(s) reported\n- `review` — findings report delivered and acknowledged\n- `update` — corrected adapter trained with `force_update: true` + review_evidence, repo file updated\n\nA successful result means the resulting KAIROS adapter is more truthful,\nphase-aware, agent-readable, and aligned with human–AI harmony.\n",
+        "refine-search": "---\nversion: \"4.8.0-beta.0\"\nslug: refine-search\ntitle: Get help refining your search\n---\n\n\n\n# Get help refining your search\n\n**You are an AI agent.** You ran `activate` and got no solid match, or only weak\n/ ambiguous matches. This adapter helps you turn a vague request into a better\nquery so the next `activate` can find the right adapter.\n\nKAIROS principle: before acting, understand the user better. The goal is not to\nrepeat the failed phrase with minor edits. The goal is to recover the user's\nreal intent.\n\n## Activation Patterns\n\n**Run this adapter when:**\n- `activate` returned no match.\n- `activate` returned only weak choices.\n- The response included a `refine` choice.\n\n**Trigger pattern:** after `activate` when no strong match exists.\n\n**Must Never:**\n- Run when a strong match already exists.\n- Loop refinement endlessly.\n\n**Must Always:**\n- Infer the real goal, context, and missing constraints from the user's request.\n- Build a more specific query than the one that failed.\n- Run at most once per user request; if the second activation still fails, stop\n  and offer clarification or protocol creation.\n\n**Good trigger examples:**\n- activate returned only \"refine\" / weak matches → run this adapter\n- \"No protocol matched 'do the thing'\" → run this adapter\n\n**Bad trigger examples:**\n- activate returned a strong match → use that match instead\n- user asked \"what adapters exist?\" → use `activate` / `spaces`, not this\n\n## Step 1: Extract what the user actually wants\n\nFrom the user's original message, identify:\n- the real goal\n- relevant context\n- missing constraints\n- likely wording that would help KAIROS find the right adapter\n\nWrite your analysis as the solution.\n\n```json\n{\n  \"contract\": {\n    \"type\": \"comment\",\n    \"comment\": { \"min_length\": 60 },\n    \"required\": true\n  }\n}\n```\n\n## Step 2: Build and run a refined activate query\n\nUsing Step 1, construct one refined query with 3–8 specific words. Do not reuse\nthe vague phrase that already failed.\n\nCall `activate` with it.\n\n- **Strong match (score >= 0.5):** pick that choice and `forward`.\n- **Weak matches only:** ask the user to clarify or offer the create path.\n\nDo not loop more than once.\n\n```json\n{\n  \"contract\": {\n    \"type\": \"mcp\",\n    \"mcp\": { \"tool_name\": \"activate\" },\n    \"required\": true\n  }\n}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent has converted a failed literal search into a more truthful,\nuser-aligned activation attempt.\n",
+        "create-new-protocol-review": "---\nversion: \"4.8.0-beta.0\"\nslug: create-new-protocol-review\ntitle: \"DEPRECATED — use phase-critic + create-new-protocol\"\n---\n\n# DEPRECATED — create-new-protocol-review\n\nThis adapter is **deprecated** as of v4.8.0.\n\nIts responsibilities are now handled by:\n\n1. **phase-critic** (`2005`) — adversarial phase-boundary review (integrated\n   into the 2001 authoring flow as a mandatory gate before train).\n2. **create-new-protocol** (`2001`) — authoring adapter that now invokes\n   `phase-critic` directly and includes `review_evidence` in its `train` call.\n\n## Why deprecated\n\nThe original flow split authoring (2001) and review (2003) into two chained\nadapters. The phase-critic quality gate consolidates review into a single\n`forward` step inside 2001, eliminating the chain hop and providing structured\nevidence (`review_evidence`) on every train call.\n\n## Migration\n\n- If you were forwarded here by `create-new-protocol`, the parent adapter\n  already runs `phase-critic` and will train automatically.\n- If you invoked this slug directly, use `activate` with a phrase like\n  \"create a new protocol\" to match `2001` instead.\n",
+        "challenge-type-guide": "---\nversion: \"4.8.0-beta.0\"\nslug: challenge-type-guide\ntitle: Challenge Type Selection Guide\n---\n\n\n\n# Challenge Type Selection Guide\n\nDecision rules, JSON formats, interpreter selection, and anti-patterns for\nchoosing KAIROS challenge types. Loaded by protocol-authoring agents during\ndrafting and review.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`phase-critic`.\n\n**Can be invoked directly when agent needs:**\n- \"challenge type reference\" / \"which challenge type to use\"\n- \"how to write shell challenges\" / \"challenge format\"\n- \"interpreter selection for challenges\"\n\n**Trigger pattern:** **challenge** + (type | format | selection | guide).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Select `comment` merely because it is easy.\n\n**Must Always:**\n- Be consulted before assigning challenge types to protocol steps.\n- Choose the strongest observable contract available.\n- Match challenge choice to the mode of the step: ask, decide, act, verify, or review.\n\n**Good trigger examples:**\n- drafting a new protocol and need challenge types → load this\n- reviewing challenge type selection in a draft → load this\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Review my protocol draft\" → use `phase-critic`\n\n## Core Rules\n\n`comment` is the challenge type of **last resort**. If a step produces any\nobservable artifact — a file, a git state change, an API response, or an exit\ncode — use `shell` or `mcp` instead.\n\n**Mode before challenge type:**\n- **clarify / approve** → `user_input`\n- **call a KAIROS / MCP tool** → `mcp`\n- **execute or verify local state** → `shell`\n- **pure reasoning with no observable artifact** → `comment`\n\n### Decision Tree\n\n```\nDoes the step call an MCP tool?\n ├─ YES → Is the step a chain link to another adapter?\n │         ├─ YES → \"mcp\" with tool_name + arguments (forward + slug URI)\n │         └─ NO  → \"mcp\" with tool_name only\n └─ NO → Does the step produce or verify a file, command result, or system state?\n          ├─ YES → \"shell\"\n          └─ NO → Does the step require human approval or choice?\n                   ├─ YES → \"user_input\"\n                   └─ NO → \"comment\" only if there is no stronger observable contract\n```\n\n### Challenge JSON Formats\n\n**shell**\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"<command>\",\"timeout_seconds\":30},\"required\":true}}\n```\n\n**mcp**\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"<tool>\"},\"required\":true}}\n```\n\n**mcp with arguments (chain link)**\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/<slug>\"}},\"required\":true}}\n```\n\nUse the `arguments` form when the step's purpose is to invoke a specific\nadapter via `forward`. The server validates that `solution.mcp.arguments`\nis a superset of the contract's `mcp.arguments` (subset/deep matching),\nproving the agent called the correct target — not just any `forward` call.\n\n**user_input**\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"<specific question>\"},\"required\":true}}\n```\n\n**comment**\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":50},\"required\":true}}\n```\n\n### Solution JSON Formats\n\nEvery solution, regardless of type, follows the same envelope:\n\n```json\n{\n  \"type\": \"<challenge_type>\",\n  \"outcome\": \"success | failure | skipped\",\n  \"evidence\": { /* type-specific proof data */ },\n  \"nonce\": \"<echo from contract>\",\n  \"proof_hash\": \"<echo from contract>\"\n}\n```\n\n**shell solution**\n```json\n{\n  \"type\": \"shell\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"exit_code\": 0,\n    \"stdout\": \"...\",\n    \"stderr\": \"\",\n    \"duration_seconds\": 1.2\n  }\n}\n```\n\n**mcp solution**\n```json\n{\n  \"type\": \"mcp\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"tool_name\": \"activate\",\n    \"arguments\": { \"query\": \"example search\" },\n    \"response\": { \"choices\": [...] }\n  }\n}\n```\n\n**user_input solution**\n```json\n{\n  \"type\": \"user_input\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"confirmation\": \"agreed. proceed\",\n    \"timestamp\": \"2026-05-18T14:49:00Z\"\n  }\n}\n```\n\n**comment solution**\n```json\n{\n  \"type\": \"comment\",\n  \"outcome\": \"success\",\n  \"evidence\": {\n    \"text\": \"Verified all 78 issues now have repo: labels.\"\n  }\n}\n```\n\n### Compatibility\n\nThe server also accepts older solution shapes where data is placed directly\nunder the type key (e.g. `{ \"type\": \"shell\", \"shell\": { \"exit_code\": 0 } }`)\ninstead of inside an `evidence` envelope. Always use the unified envelope with\n`outcome` and `evidence` for new protocols.\n\n## Interpreter Selection\n\n| Task | Use bash | Use perl | Use python3 |\n|---|---|---|---|\n| File exists, tool installed, git state | yes | no | no |\n| Simple content grep | yes | no | no |\n| Multi-line regex | no | yes | no |\n| Paragraph processing | no | yes | no |\n| JSON validation | maybe | yes | yes |\n| YAML / complex data structure checks | no | no | yes |\n\n**Rule of thumb:** if bash requires `while read`, `grep | awk`, or heavy quote\nescaping, rewrite in Perl. If you need imports for data formats, use Python.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Security and Working Directory Rules\n\nUse `$KAIROS_LOCAL_ARTIFACT_DIR` as the base directory for local handoff\nartifacts. File paths within it are provided as variables by the invoking agent\nto avoid collisions between parallel sessions.\n\n**Rules:**\n- all file paths in shell challenges reference variables (e.g., `$DRAFT_FILE`,\n  `$VERDICT_FILE`) set by the parent agent — never hardcode filenames\n- the parent agent constructs collision-free paths under\n  `$KAIROS_LOCAL_ARTIFACT_DIR` (e.g., with a session ID or random suffix)\n- when using KAIROS MCP, the latest `activate` / `forward` / `next` response field `kairos_local_artifact_dir` is an ordered array of URI hints (`project://<rel>`, `user://<rel>`); pick one (`project://` when you have exactly one project context, otherwise `user://`), resolve on your machine, and `export KAIROS_LOCAL_ARTIFACT_DIR=\"<absolute>\"` if your shell does not already define it\n- if the server-returned path is not usable on your local filesystem, resolve\n  locally to `$PROJECT_DIR/.local/kairos/work` and keep it stable for the run\n- prerequisites create the directory\n- Reward Signal cleans it up\n- never write credentials or secrets to files\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Composition Patterns\n\n**Multi-check compound command**\n- chain with `&&`\n- let the first failure stop execution\n\n**Agent-readable shell status**\n- use when failure can produce no output, especially `test`, quiet `grep`,\n  JSON probes, pipelines, or commands that redirect stderr\n- empty stdout or stderr is not success; success is the real process status\n  reported as `solution.shell.exit_code`\n- print the final status marker to stderr when stdout is machine-readable\n- preserve the original status exactly:\n  ```bash\n  ( set -o pipefail; <command> ); rc=$?; printf '\\nKAIROS_SHELL_EXIT=%s\\n' \"$rc\" >&2; exit \"$rc\"\n  ```\n- keep `&&` inside `<command>` for ordered checks; use the final\n  `; rc=$?; ...` trailer only to capture, print, and return the process status\n- do not use `<command> || echo ERROR && false`; shell operators group\n  left-to-right, so that form can fail after a successful command and it loses\n  the original status\n\n**Freeze-then-verify**\n- step N writes checksum\n- step N+1 verifies checksum before publish\n\n**Write-then-grep**\n- subagent writes a verdict file\n- main agent checks the first line for `PASS`\n\n**Phase-batch with critic**\n- batch related TODO items into one phase\n- verify hard artifacts with shell\n- then call `phase-critic` for adversarial review\n\n**Dry-run before execution**\n- dry-run command\n- human review\n- real command\n\n**Chain-link via forward + slug**\n- layer N's contract requires `forward` with a specific adapter slug\n- agent calls `forward` to start the next adapter (new `execution_id`)\n- next adapter runs its own layer chain through to `reward`\n- use when the protocol exceeds 350 lines or needs multi-path routing\n- NOT a replacement for layers — layers remain the primary unit of work\n- example contract:\n  ```json\n  {\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/implement-plan\"}},\"required\":true}}\n  ```\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. pick the correct challenge type for each protocol step\n2. match challenge type to the step's mode\n3. choose the right interpreter\n4. apply working-directory and security rules\n5. preserve real shell statuses for silent checks\n6. use stronger verification patterns instead of weak narrative checks\n",
+        "phase-critic": "---\nversion: \"4.8.0-beta.0\"\nslug: phase-critic\ntitle: Phase Critic\n---\n\n\n\n# Phase Critic\n\nBounded adversarial investigator fired at phase boundaries. Receives a reference\ndocument, loads the calling protocol's invariants, and independently verifies\nthe verification target by extracting claims, gathering evidence, and searching\nfor contradictions.\n\n## Activation Patterns\n\n**Typically invoked by:** another protocol at the end of a plan, implement,\nvalidation, or review phase via `forward` with the stored adapter URI\n`kairos://adapter/phase-critic`.\n\n**Can be invoked directly when agent needs:**\n- \"review phase output\" / \"verify plan\" / \"audit implementation\"\n- \"adversarial review\" / \"critic review\"\n\n**Trigger pattern:** **review** / **verify** / **audit** / **critic** +\n(phase / plan / implementation / output).\n\n**Must Never:**\n- Modify any file outside the provided input and output paths.\n- Trust the executor's assertions without independent evidence.\n- Classify a claim as `verified` based only on absence of contradiction.\n- Keep investigating after a precondition failure that blocks verification.\n\n**Must Always:**\n- Extract claims before investigating.\n- Verify in-scope claims first.\n- Search for contradictory evidence, not only confirming evidence.\n- Include confidence in every verdict and failure class in every FAIL verdict.\n- Preserve the boundary between execution and review.\n\n**Good trigger examples:**\n- implement protocol fires this after planning → run this protocol\n- compose protocol fires this after output generation → run this protocol\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Implement a feature\" → use an execution protocol, not this one\n\n## Artifact Contract\n\nThis protocol receives:\n\n```text\n{\n  input_file: string,              // absolute path to the document under review\n  calling_protocol_slug: string,\n  verification_target: string,\n  context: {\n    operation: string,\n    verdict_file: string           // absolute path where the verdict will be written\n  }\n}\n```\n\nThis protocol produces:\n\n```text\n{\n  verdict: \"PASS\" | \"FAIL\",\n  confidence: \"High\" | \"Medium\" | \"Low\",\n  failure_class: string,\n  verdict_file: \"{context.verdict_file}\"\n}\n```\n\n## Precondition Check [SUBAGENT]\n\nVerify foundational preconditions before deep investigation. Early-abort if any\nare broken.\n\n**Input:** `$INPUT_FILE` (absolute path), calling protocol slug, context\n\n**Actions:**\n1. Verify the input file exists: `test -f \"$INPUT_FILE\"`.\n2. Verify the verdict output path is writable (parent directory exists).\n3. Load the calling protocol's Must Never / Must Always sections if possible.\n4. Verify the target state is available for review.\n5. Verify required tools are available.\n\n**On early-abort:**\n- verdict = `FAIL`\n- failure class = `verification_blocked`\n- confidence = `Low`\n- write focused diagnostics\n- skip all later steps\n\n**Output:** verified preconditions or early-abort diagnostics\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$INPUT_FILE\\\"\",\"timeout_seconds\":3},\"required\":true}}\n```\n\n## Audit [SUBAGENT]\n\nPerform bounded adversarial review of the target against the reference document\nand invariants.\n\n**Input:** reference document, invariants, verification target, context\n\n**Actions:**\n\n**Step 1 — Extract claims**\nExtract every verifiable claim that matters operationally:\n- workflows, commands, tool calls\n- configuration and environment variable claims\n- architecture claims that imply behaviour\n- guarantees and constraints\n- security, auth, and permission claims\n\n**Step 2 — Investigate with scope discipline**\n1. verify all in-scope claims first\n2. review high-risk claims with maximum depth\n3. expand beyond scope only when contradiction signals, dependencies, or\n   high-risk impact require it\n4. continue reviewing all in-scope claims even after a normal FAIL condition is met;\n   only a precondition failure stops the audit early\n\n**High-risk areas**\n- setup steps and prerequisites\n- CLI commands and flags\n- configuration keys and environment variables\n- authentication, identity, and permissions\n- deployment and release behaviour\n- external publishing actions\n- destructive or irreversible operations\n\n**Step 3 — Gather evidence using the hierarchy**\n\n| Priority | Evidence source |\n|---|---|\n| 1 | source code, config files, schemas, route definitions |\n| 2 | direct runtime verification |\n| 3 | tests |\n| 4 | MCP-queried system state |\n| 5 | external docs, web pages, linked references |\n| 6 | conversational assumption or indirect inference |\n\n**Rules:**\n- higher-priority evidence overrides lower-priority evidence\n- priority 5–6 alone is not enough for `verified`\n\n**Step 4 — Produce claim verdicts**\n\nFor each claim, record:\n- CLAIM\n- EVIDENCE\n- EVIDENCE PRIORITY\n- VERDICT: `verified` / `partially_verified` / `unverifiable` / `incorrect`\n\nA claim must not be marked `verified` without positive supporting evidence.\n\n**Step 5 — Review the phase boundary**\nCheck whether the calling protocol preserved the right mode boundary:\n- was execution reviewed independently?\n- were review and execution kept separate?\n- did the protocol switch to verification when it should have?\n- is escalation needed because certainty was overstated?\n\n**Output:** structured audit findings for the verdict step\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## Verdict [SUBAGENT]\n\nTurn the audit into a final PASS / FAIL result.\n\n**Input:** audit findings and verdict file path from context (use it as\n`$VERDICT_FILE`)\n\n**Actions:**\n1. Fail if any critical claim is incorrect.\n2. Fail if verification was blocked.\n3. Fail if the evidence base is too weak for high-risk claims.\n4. Otherwise, pass with the appropriate confidence.\n5. Write `$VERDICT_FILE` so line 1 is `PASS` or `FAIL`,\n   line 2 is `High`, `Medium`, or `Low`, and the remaining lines summarise key\n   findings.\n\n**Verdict contract (calling adapter must obey):**\n- Line 1 is `PASS` → calling adapter may continue to the next phase.\n- Line 1 is `FAIL` → calling adapter **MUST NOT** proceed to reward, **MUST NOT**\n  ask the user for approval, and **MUST NOT** continue to the next phase.\n  The calling adapter must address findings and re-invoke phase-critic.\n\n**Output:** final verdict file\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$VERDICT_FILE\\\" && head -1 \\\"$VERDICT_FILE\\\" | grep -qiE '^(PASS|FAIL)$' && sed -n '2p' \\\"$VERDICT_FILE\\\" | grep -qiE '^(High|Medium|Low)$'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe phase output has been independently challenged. The resulting verdict is more\ntruthful because it is based on extracted claims, explicit evidence, contradiction\nsearch, and a clean boundary between execution and review.\n",
+        "protocol-linking-guide": "---\nversion: \"4.8.0-beta.0\"\nslug: protocol-linking-guide\ntitle: Protocol Linking Guide\n---\n\n\n\n# Protocol Linking Guide\n\nDecision rules for structuring adapter relationships: layers vs chains,\n`activate` vs `forward` + slug, chain-root collapsing, and MCP argument\nvalidation for deterministic cross-protocol linking.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`phase-critic`.\n\n**Can be invoked directly when agent needs:**\n- \"layers vs chains\" / \"when to split into multiple adapters\"\n- \"how to link adapters\" / \"cross-protocol linking\"\n- \"activate vs forward\" / \"when to use forward with slug\"\n- \"chain-root collapsing\" / \"how chain_root works\"\n\n**Trigger pattern:** **layers** / **chains** / **linking** / **forward** +\n(slug | adapter | protocol).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Recommend chaining when layers suffice.\n\n**Must Always:**\n- Be consulted before splitting a protocol into multiple adapters.\n- Be consulted before adding `forward` calls or `chain_root` frontmatter.\n\n**Good trigger examples:**\n- \"my protocol is 400 lines, should I split?\" → load this\n- \"how do I link adapter A to adapter B?\" → load this\n- \"what is chain_root?\" → load this\n\n**Bad trigger examples:**\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n- \"create a new protocol\" → use `create-new-protocol`\n\n## Layers vs Chains\n\n**Layers** (H2 steps within one adapter) are the preferred unit of work. Use\nlayers when all steps fit in one adapter under 350 lines and serve a single\ncohesive concern.\n\n**Chain via `forward` + slug** — use only when:\n- the adapter exceeds 350 lines\n- weaker models cannot follow the full adapter in one pass\n- runtime routing to different adapters is needed (Router pattern)\n- a step is reusable across multiple parent adapters (e.g. `phase-critic`)\n\nChaining is NOT a replacement for layers. A 6-step protocol that fits in 350\nlines should stay as one adapter with 6 H2 layers.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## `activate` vs `forward` + slug\n\n| Situation | Use |\n|---|---|\n| Initial user-intent resolution | `activate` |\n| Target adapter is known at authoring time | `forward` + slug |\n| Target depends on runtime classification the current adapter cannot resolve | `activate` |\n| Linking to the next adapter in a chain | `forward` + slug |\n| Reusable sub-protocol invoked by multiple parents | `forward` + slug |\n\nNever call `activate` just to get a slug you already know — it wastes a\nround-trip and introduces non-determinism.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Chaining Back and Forward\n\nWhen a family of adapters has a root conductor and smaller domain extensions,\ndocument both directions of chaining.\n\n### Chaining back with `chain_root`\n\nExtension adapters should include `chain_root` frontmatter and a prerequisite\nclause:\n\n**Prerequisite:** Start from `<root-adapter-slug>` unless the caller already\nprovided a mission brief, safety gates, authorization boundary, and evidence\nrequirements.\n\nThis protects activation entry points. If a user or weak agent activates a\nmid-chain extension directly, the extension can collapse back to the root unless\nit already received the required parent context.\n\n### Chaining forward with `forward`\n\n`chain_root` does not replace explicit `forward` calls inside the chain.\n\nWhen the next adapter is known at authoring time or after deterministic runtime\nclassification, use `forward` with the target slug. Do not call `activate` just\nto rediscover a slug already known by the current adapter.\n\nForwarded adapters should receive:\n- current mission brief;\n- safety gates;\n- authorization boundary;\n- evidence requirements;\n- user constraints;\n- reason for forwarding.\n\nUse `activate` only when the next adapter must be discovered from an ambiguous\nruntime need.\n\n### Multi-layer conductors and extension URIs\n\nWhen you are executing **`forward`** inside a **multi-layer** adapter (for example\na root conductor), each continuation follows **`next_call`** for the **same**\n`execution_id` until the last layer directs **`reward`**. A layer that mentions\nanother adapter URI only as routing guidance — for example\n`kairos://adapter/e2e-coding-pr-delivery` — does **not** cause the server to\nswitch executions: the next **`forward`** in that run still advances the\n**current** adapter’s next layer.\n\nTo run an extension adapter, call **`forward`** with\n`kairos://adapter/<slug>` as a **new** first call (adapter URI; omit\n`solution`). That starts a **separate** execution with its own layers. Common\npattern: complete the conductor with **`reward`**, then **`forward`** to the\nextension slug when coding or PR-shaped work should run under that adapter’s\ncontracts.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## System adapters vs user adapters\n\nBoth system and user-authored adapters chain using slugs in `next_action`:\n\n```text\ncall forward with kairos://adapter/phase-critic ...\ncall forward with kairos://adapter/implement-terraform ...\n```\n\nSlugs are globally unique (enforced by `train`), so resolution is\ndeterministic — no scoring, no ambiguity.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## MCP argument validation for chain links\n\nA bare `mcp` contract checks only the tool name:\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\"},\"required\":true}}\n```\n\nAn `mcp` contract **with `arguments`** verifies the exact target:\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/code-review-policy\"}},\"required\":true}}\n```\n\nThe server validates that `solution.mcp.arguments` is a superset of the\ncontract's `mcp.arguments` (subset/deep matching). This proves the agent\ncalled `forward` with the correct slug, not just any `forward` call.\n\nUse the `arguments` form whenever a step's purpose is to invoke a specific\nknown adapter.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Chain-root collapsing\n\nWhen a chain has multiple adapters, `activate` might match a mid-chain adapter\ndirectly. Without protection, the agent would start at the wrong step, missing\nprerequisite context gathered by earlier phases.\n\n**`chain_root` frontmatter field** solves this at the server level. Add it to\nevery mid-chain adapter:\n\n```yaml\n---\nslug: implement-plan\nversion: 1.0.0\nchain_root: implement\n---\n```\n\n**Server behaviour:** When `activate` returns a match that has `chain_root`,\nthe server resolves the slug to the root adapter's URI and replaces the\nchoice's `uri` and `next_action` to point there. Multiple mid-chain matches\nfrom the same chain are deduplicated to a single entry. The agent always\nstarts at the chain entry point.\n\n**Defense in depth — protocol-level safeguards:** Each mid-chain adapter\nshould include a **Prerequisites** paragraph in its Activation Patterns\nlisting inputs required from earlier phases and directing the agent to start\nfrom the chain root if those inputs are missing. This catches direct `forward`\ncalls that bypass `activate`.\n\n**Rules:**\n- The chain root adapter must NOT have `chain_root` in its frontmatter.\n- `chain_root` must refer to an existing slug (the chain entry point).\n- `forward` calls within a chain are unaffected — `chain_root` only changes\n  `activate` output routing.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. decide when to use layers vs chains\n2. choose `activate` vs `forward` + slug correctly\n3. use slug-based linking for all adapters (system and user)\n4. apply MCP argument validation for deterministic chain links\n5. implement `chain_root` collapsing with defense-in-depth safeguards\n6. document chaining back (`chain_root` + prerequisites) and chaining forward\n   (`forward` with known slugs) for root + extension families\n",
+        "bulk-insert-adapters-via-cli": "---\nslug: bulk-insert-adapters-via-cli\nversion: \"4.8.0-beta.0\"\ntitle: Bulk Insert Adapters via KAIROS CLI\n---\n\n# Bulk Insert Adapters via KAIROS CLI\n\n## Activation Patterns\n\nBatch-register multiple KAIROS adapters from a local directory tree using the\n`kairos train` CLI. Handles directory scanning, validation, space targeting,\nand error recovery for bulk operations.\n\n**Run this protocol when the user says ANY of:**\n\n- \"bulk insert adapters\" / \"bulk train adapters\"\n- \"train all protocols in a directory\"\n- \"batch register adapters from folder\"\n- \"upload all .md files to KAIROS\"\n- \"sync local protocols to KAIROS\" / \"push protocols to KAIROS\"\n- \"train directory recursively\" / \"train --recursive\"\n\n**Trigger pattern:** **bulk** / **batch** / **all** / **directory** / **recursive** +\n(train | insert | register | upload | push | sync) + (adapters | protocols).\n\n**Must Never:**\n\n- Train files without first validating their structure.\n- Overwrite existing adapters without explicit user confirmation (`--force`).\n- Train files that contain secrets or token-like strings without `--allow-sensitive-upload`.\n- Skip reporting partial failures in a batch.\n\n**Must Always:**\n\n- Verify the target directory exists and contains `.md` files.\n- Show the user the file list and target space before executing.\n- Report per-file success/failure after the batch completes.\n- Respect the user's choice of space (personal or group).\n\n**Good trigger examples:**\n\n- \"Train all adapters in kairos-v4/_personal/\" → run this protocol\n- \"Bulk insert the protocols from my export folder\" → run this protocol\n- \"Push all .md files in this directory to my personal space\" → run this protocol\n\n**Bad trigger examples:**\n\n- \"Train this one protocol\" → use `kairos train <file>` directly\n- \"Create a new protocol\" → use `create-new-protocol`\n- \"Export my adapters\" → use `kairos export`\n\n## Preflight Dependencies\n\nVerify before execution:\n\n1. `kairos` CLI is installed and callable (`kairos --version`).\n2. Authentication is valid (`kairos token` returns a token without error).\n3. Target directory path exists and contains at least one `.md` file.\n4. If a space is specified, confirm it exists via `kairos spaces`.\n\nIf any check fails, stop and report the issue with remediation guidance.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"kairos --version && kairos token > /dev/null 2>&1 && echo 'auth: ok'\",\"timeout_seconds\":15},\"required\":true}}\n```\n\n## Confirm Scope\n\nPresent the batch operation details to the user:\n\n1. **Source directory** — absolute path.\n2. **File count** — number of `.md` files found (recursive or flat).\n3. **Target space** — personal (default) or a named group space.\n4. **Force mode** — whether `--force` will be used (overwrites existing).\n5. **Model attribution** — which `--model` value to use.\n\nList the files that will be trained and ask for confirmation.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Confirm batch scope: directory, file list, target space, force mode, and model ID\"},\"required\":true}}\n```\n\n## Validate Structure\n\nBefore training, validate each `.md` file against KAIROS adapter requirements:\n\n- Has an H1 title.\n- First H2 is \"Activation Patterns\".\n- Last H2 is \"Reward Signal\".\n- Contains at least one fenced `json` block with a top-level `contract` object.\n- Does not exceed 350 lines.\n\nReport any files that fail validation. Ask user whether to:\n- skip invalid files and proceed with valid ones\n- abort and fix issues first\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"echo 'Validation complete — see output above for results'\",\"timeout_seconds\":30},\"required\":true}}\n```\n\n## Execute Bulk Train\n\nRun the batch train operation using the KAIROS CLI:\n\n```\nkairos train <directory> --recursive --model <model> --space <space> [--force]\n```\n\nIf the directory contains files that should NOT be trained (README, reference\ndocs), either:\n- train file-by-file for the valid subset, or\n- move non-adapter files out before running `--recursive`\n\nCapture stdout and stderr. The CLI reports per-file status.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"kairos train <directory> --recursive --model <model_id> --space <space>\",\"timeout_seconds\":120},\"required\":true}}\n```\n\n## Report Results\n\nSummarise the batch outcome:\n\n| Metric | Value |\n|--------|-------|\n| Files attempted | N |\n| Successfully trained | N |\n| Failed | N |\n| Skipped (invalid) | N |\n\nFor each failure, report:\n- File path\n- Error message\n- Suggested fix\n\nIf all succeeded, confirm adapter URIs are accessible via `kairos spaces`.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nProtocol complete when:\n- All valid adapter files in the target directory have been trained to the\n  specified space.\n- Per-file results have been reported to the user.\n- Any failures have been documented with remediation guidance.\n\nA successful bulk insert means the user's local protocol library is now\nregistered in KAIROS and available for activation by AI agents.\n",
+        "skill-format-guide": "---\nversion: \"4.8.0-beta.0\"\nslug: skill-format-guide\ntitle: Skill Format and Local Authoring Guide\n---\n\n\n\n# Skill Format and Local Authoring Guide\n\nDecision rules for authoring SKILL.md files, choosing between local (git) and\nserver (KAIROS) storage, and quality gates for skill content. Loaded by\nprotocol-authoring agents during drafting and review when the output format is\n`skill`.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` and\n`phase-critic`.\n\n**Can be invoked directly when agent needs:**\n- \"SKILL.md format reference\" / \"how to write a skill\"\n- \"skill vs adapter\" / \"local skill or KAIROS adapter\"\n- \"skill quality gates\" / \"SKILL.md structure\"\n- \"project-level skill\" / \"where to put a skill\"\n\n**Trigger pattern:** **skill** + (format | structure | guide | quality | local).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Recommend storing a skill in both git AND KAIROS server simultaneously.\n- Confuse SKILL.md (agent instruction file) with protocol markdown (adapter).\n\n**Must Always:**\n- Be consulted before writing any SKILL.md file.\n- Enforce single source of truth: each skill lives in exactly one place.\n- Match storage location to the skill's scope and discoverability needs.\n\n**Good trigger examples:**\n- drafting a new skill and need format rules → load this\n- reviewing a SKILL.md for quality → load this\n- deciding local vs server for a skill → load this\n\n**Bad trigger examples:**\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n- \"create a new protocol\" → use `create-new-protocol`\n\n## Storage Decision\n\nEvery skill has ONE home. Choose at authoring time. Never both.\n\n| Scope | Storage | Discovery | Source of Truth |\n|---|---|---|---|\n| Project-specific (deploy, test, release) | Git: `.agents/skills/{name}/` or `.cursor/skills/{name}/` | IDE host scans description field | Git repo |\n| Personal cross-project (universal) | KAIROS server via `train` | `activate` embedding search | KAIROS server |\n| Team/group shared | KAIROS server (group space) | `activate` | KAIROS server |\n\n### Decision Tree\n\n```\nIs this skill specific to ONE project's codebase?\n ├─ YES → Does it reference repo files, paths, or project-specific tools?\n │         ├─ YES → LOCAL (git)\n │         └─ NO  → Could it help in other projects?\n │                   ├─ YES → SERVER (KAIROS)\n │                   └─ NO  → LOCAL (git)\n └─ NO → SERVER (KAIROS)\n```\n\n### Local Storage Paths\n\n| Host | Path | Scope |\n|---|---|---|\n| Cursor IDE (project) | `.cursor/skills/{name}/SKILL.md` | Repo-scoped, git-controlled |\n| Cursor IDE (personal) | `~/.cursor/skills/{name}/SKILL.md` | User-wide, all projects |\n| Claude Code (project) | `.agents/skills/{name}/SKILL.md` | Repo-scoped, git-controlled |\n| Claude Code (personal) | `~/.agents/skills/{name}/SKILL.md` | User-wide, all projects |\n\n**Never** create skills in `~/.cursor/skills-cursor/` — reserved for system.\n\n### Promotion and Demotion\n\n**Local → Server (skill graduates to universal):**\n1. Read existing SKILL.md\n2. Optionally wrap in protocol structure (Activation Patterns, contracts)\n3. `train` to KAIROS server\n4. Delete local copy or mark deprecated\n5. Git commit the deletion\n\n**Server → Local (adapter becomes project-specific):**\n1. `export` with `format: skill_zip` or `format: markdown`\n2. Write to `.agents/skills/{slug}/SKILL.md`\n3. Optionally `delete` from server\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## SKILL.md Structure Rules\n\n### Required YAML Frontmatter\n\n```yaml\n---\nname: lowercase-hyphenated-name\ndescription: >-\n  Third-person description of WHAT it does and WHEN to use it.\n  Include trigger terms. Max 1024 chars.\n---\n```\n\n| Field | Constraint | Purpose |\n|---|---|---|\n| `name` | Max 64 chars, `[a-z0-9-]` only | Unique identifier |\n| `description` | Non-empty, max 1024 chars | Discovery by IDE and agents |\n| `disable-model-invocation` | Boolean, default `true` | Explicit load only |\n\n### Body Structure\n\n```markdown\n# Skill Title\n\n## Instructions\n[Core workflow — step-by-step, imperative voice]\n\n## Examples\n[Concrete usage examples with inputs and expected outputs]\n\n## Additional Resources\n- [reference.md](reference.md) — detailed documentation (optional)\n- [scripts/helper.sh](scripts/helper.sh) — utility scripts (optional)\n```\n\n### Directory Layout\n\n```\nskill-name/\n├── SKILL.md              # Required\n├── SHA256SUMS            # Required for KAIROS-exported skills\n├── reference.md          # Optional — detailed docs\n├── examples.md           # Optional — usage examples\n└── scripts/              # Optional — utility scripts\n    └── validate.sh\n```\n\n### Size and Depth Limits\n\n- **SKILL.md body:** under 500 lines\n- **Reference depth:** one level only (SKILL.md → reference.md, never deeper)\n- **Progressive disclosure:** essential info in SKILL.md, details in references\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Quality Gates\n\n### Description Quality\n\nThe description is the primary discovery mechanism. It must:\n\n1. Be written in **third person** (not \"I can help\" or \"you can use\")\n2. State **WHAT** the skill does (specific capabilities)\n3. State **WHEN** to use it (trigger scenarios, file patterns, keywords)\n4. Include **trigger terms** that match real user language\n5. Avoid vague words: \"helps with\", \"assists\", \"various\"\n\n**Good:**\n```yaml\ndescription: >-\n  Validate and publish Confluence pages managed as local markdown via Mark CLI.\n  Use when the user asks to dry-run, validate, publish, or sync a Confluence\n  page, or when working with files under confluence/ that have Mark metadata.\n```\n\n**Bad:**\n```yaml\ndescription: Helps with Confluence stuff.\n```\n\n### Content Quality\n\n| Check | Rule |\n|---|---|\n| Consistent terminology | One term per concept throughout |\n| No time-sensitive info | No \"before August 2025\" conditions |\n| Concrete examples | Real inputs/outputs, not abstract |\n| Actionable instructions | Agent knows what to DO, not just what exists |\n| Default tool choice | One recommended tool, escape hatch for alternatives |\n| No Windows paths | Forward slashes only |\n\n### Degree of Freedom\n\nMatch instruction specificity to the task's fragility:\n\n| Level | When | Example |\n|---|---|---|\n| High (text guidelines) | Multiple valid approaches | Code review guidelines |\n| Medium (templates/pseudocode) | Preferred pattern, acceptable variation | Report generation |\n| Low (exact scripts) | Fragile operations, consistency critical | DB migrations |\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Finalisation Paths\n\n### Path A: Local Write (project-level skill)\n\nWhen `{target}=local`:\n\n1. Determine output path from scope:\n   - Project Cursor: `.cursor/skills/{name}/SKILL.md`\n   - Project Claude: `.agents/skills/{name}/SKILL.md`\n   - Personal: `~/.cursor/skills/{name}/SKILL.md` or `~/.agents/skills/{name}/`\n2. Create directory if needed\n3. Write SKILL.md with frontmatter and body\n4. Generate `SHA256SUMS` (GNU sha256sum format, paths relative to skill dir)\n5. Write any reference files and scripts\n6. Verify: `test -f \"{path}/SKILL.md\" && wc -l \"{path}/SKILL.md\"`\n7. Report path and line count to user\n\nDo NOT call `train`. The skill lives only in git.\n\n### Path B: Server Train (KAIROS-routable adapter)\n\nWhen `{target}=server`:\n\n1. Wrap skill content in protocol markdown if needed:\n   - Add Activation Patterns (first H2)\n   - Add contract blocks per layer\n   - Add Reward Signal (last H2)\n2. Call `train` with full markdown\n3. Verify adapter URI returned\n4. Report URI and slug to user\n\nDo NOT write to local disk. The adapter lives only in KAIROS.\n\n### Path C: Hybrid Authoring (skill that is also an adapter)\n\nWhen `{target}=hybrid` (rare — use only when explicitly requested):\n\n1. Author as a KAIROS protocol (Activation Patterns, contracts, Reward Signal)\n2. `train` to server\n3. `export` with `format: skill_zip` to produce local SKILL.md bundle\n4. The exported SKILL.md is a **read-only derived artifact**, not a source of truth\n5. Document in the SKILL.md header that it was exported from KAIROS\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. Choose the correct storage location for a skill\n2. Author SKILL.md with valid frontmatter and structure\n3. Apply quality gates to descriptions and content\n4. Finalize via local write OR server train (never both)\n5. Produce SHA256SUMS for integrity verification\n",
+        "phase-critic-guide": "---\nversion: \"4.8.0-beta.0\"\nslug: phase-critic-guide\ntitle: Phase Critic Integration and Mutation Gate Guide\n---\n\n# Phase Critic Integration and Mutation Gate Guide\n\nDecision rules for integrating `phase-critic` into adapter protocols and\ndetermining when solution checks (hard verification gates) are required versus\nwhen phase-critic review is sufficient.\n\n## Activation Patterns\n\n**Typically invoked by:** `create-new-protocol` during adapter drafting, and\nany adapter that includes review or validation phases.\n\n**Can be invoked directly when agent needs:**\n- \"when to add phase critic\" / \"should I use solution check\"\n- \"mutation gate rules\" / \"which actions need hard gates\"\n- \"phase critic vs solution check\" / \"irreversible action rules\"\n- \"add review step to protocol\" / \"where does critic go\"\n\n**Trigger pattern:** **phase critic** / **mutation gate** / **solution check** +\n(integration | when | rules | guide | which | where).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Override the adapter author's judgment on review depth.\n- Recommend solution checks for reversible or local-only actions.\n\n**Must Always:**\n- Distinguish between quality review (phase-critic) and mutation blocking\n  (solution checks).\n- Recommend phase-critic at every major phase boundary.\n- Restrict solution checks to irreversible remote-system mutations.\n\n**Good trigger examples:**\n- drafting a new adapter and deciding where to add review → load this\n- reviewing whether an adapter has the right solution checks → load this\n- \"does my MR step need a solution check?\" → load this\n\n**Bad trigger examples:**\n- \"run the phase critic\" → use `activate` to match `phase-critic`\n- \"create a new protocol\" → use `create-new-protocol`\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n\n## Core Decision Rule\n\n**Phase-critic** is an adversarial review step at phase boundaries. It verifies\nclaims, gathers evidence, and searches for contradictions. Use it for quality\nand truthfulness review.\n\n**Solution checks** are per-layer contract verification mechanisms (shell\ncommands, MCP tool calls, user input). Use them ONLY to block actions that\ncause **irreversible changes on remote systems**.\n\n### What counts as an irreversible remote mutation\n\n| Action | Needs solution check? | Why |\n|--------|----------------------|-----|\n| Create/update merge request | Yes | Remote system state change |\n| Create/update Jira issue | Yes | Remote system state change |\n| Send email | Yes | Cannot unsend |\n| Send Teams message | Yes | Cannot unsend |\n| Create calendar invite | Yes | Sends notifications |\n| Deploy to production | Yes | Irreversible infrastructure change |\n| Delete remote resource | Yes | Irreversible |\n| Push to git remote | Yes | Remote state change |\n| Write/edit local file | No | Use phase-critic instead |\n| Run local tests | No | Read-only / local |\n| Analyze code | No | Read-only |\n| Generate report | No | Local artifact |\n| Read data from API | No | Read-only |\n| Compute / transform data | No | Local operation |\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## How to Chain Phase-Critic into an Adapter\n\nUse `forward` + slug to invoke `phase-critic` at phase boundaries. The standard\npattern is a `mcp` contract that requires calling `forward` with the\n`phase-critic` slug:\n\n### After a planning phase\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"kairos://adapter/phase-critic\"}},\"required\":true}}\n```\n\n### After an implementation phase\n\nUse the same contract. The phase-critic adapter receives the calling protocol's\ncontext and independently verifies the work.\n\n### Verdict handoff pattern\n\nPhase-critic writes a verdict file. The calling adapter reads it:\n\n1. Phase-critic writes `$VERDICT_FILE` with `PASS`/`FAIL` on line 1.\n2. Calling adapter's next layer reads the verdict file.\n3. If `FAIL` → **hard stop**: do NOT proceed to reward, do NOT ask the user\n   for approval, do NOT continue to the next phase. Address findings first.\n4. If `PASS` → the adapter continues to the next phase.\n\n**FAIL is a hard stop, not an escalation trigger.** A FAIL verdict means the\nwork is not ready. Asking the user \"should I proceed?\" after FAIL bypasses the\nreview. The correct action is to fix the findings and re-invoke phase-critic.\n\n### FAIL gate contract (required after every phase-critic invocation)\n\nEvery adapter that chains phase-critic **must** include a shell contract that\nfails when the verdict is not PASS. This is the mechanical guard that prevents\nweaker agents from proceeding after FAIL:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"timeout_seconds\":5},\"required\":true}}\n```\n\nIf the critic wrote FAIL, this shell command exits non-zero. The server rejects\nthe solution and the agent cannot advance to the next layer. Protocol wording\nalone does not stop determined agents; this contract does.\n\n## Train/Tune Evidence Requirement\n\n`train` and `tune` enforce phase-critic PASS at the tool level:\n\n- **Adapter (markdown) `train`** requires `review_evidence`: verdict_file path,\n  exit_code (must be 0), and stdout (line 1 must be PASS). Without it, the\n  server rejects the store with `REVIEW_EVIDENCE_REQUIRED`.\n- **`tune` with content** requires the same `review_evidence`. Space-only moves\n  skip this check.\n- **Artifact trains** (non-markdown mime) skip the evidence check.\n\nThis is the tool-level enforcement of the FAIL gate. Even if an agent bypasses\nthe adapter flow and calls `train` directly, the server rejects the store\nwithout PASS evidence. The agent must run phase-critic, capture the verdict\nfile, and pass it as `review_evidence`.\n\n## Mutation Gate Pattern\n\nWhen an adapter step performs an irreversible remote mutation, add a solution\ncheck that requires explicit confirmation BEFORE the action:\n\n### Pre-mutation confirmation\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Confirm: you are about to create a merge request on repo X targeting branch Y. This action cannot be undone.\"},\"required\":true}}\n```\n\n### Post-mutation verification\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"getMergeRequest\",\"arguments\":{\"repo\":\"X\"}},\"required\":true}}\n```\n\n## Phase-Critic Placement Rules\n\n1. **Add phase-critic at every major phase boundary** — after planning, after\n   implementation, after validation.\n2. **Do NOT add phase-critic between every layer** — it is a phase-level review,\n   not a step-level check.\n3. **Add solution checks ONLY on layers that perform remote mutations** — see\n   the table above.\n4. **Never replace a solution check with phase-critic** for remote mutations —\n   phase-critic reviews truth, it does not block execution.\n5. **Never add a solution check for local operations** — phase-critic provides\n   sufficient review.\n\n## Adapter Authoring Checklist\n\nWhen drafting a new adapter, apply this checklist:\n\n1. Identify all phase boundaries in the adapter flow.\n2. Add a `phase-critic` chain link at each boundary.\n3. Identify all steps that perform irreversible remote mutations.\n4. Add solution checks (user_input + post-action verification) for each.\n5. Verify that no solution checks exist for purely local operations.\n6. Verify that the phase-critic verdict handoff pattern is present.\n7. Verify that a FAIL gate shell contract follows every phase-critic invocation.\n8. Verify that `train`/`tune` calls include `review_evidence` from the critic.\n9. Ensure the adapter's Reward Signal describes what the critic protects.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. Decide when to use phase-critic versus solution checks\n2. Identify irreversible remote mutations that need hard gates\n3. Chain phase-critic into adapters at the correct phase boundaries\n4. Apply the mutation gate pattern for remote-system actions\n5. Avoid unnecessary solution checks for local or read-only operations\n",
+        "adapter-migration": "---\nversion: \"4.8.0-beta.0\"\nslug: adapter-migration\ntitle: Adapter Migration Protocol\n---\n\n# Adapter Migration Protocol\n\nBatch-migrate all adapters in a space to the current structural scheme. Exports\nevery adapter, applies conservative structural transformations, reports changes\nper adapter, and re-trains only after user approval.\n\nThis protocol handles structural migrations only — it preserves semantic content\n(steps, intent, examples) while updating format, headings, and contract shapes\nto match the latest KAIROS requirements.\n\n## Activation Patterns\n\n**Run this protocol when the user says ANY of:**\n\n- \"migrate all adapters\" / \"batch update adapters\"\n- \"update adapters to latest scheme\" / \"update adapter structure\"\n- \"run structural migration\" / \"migrate protocols\"\n- \"update all my adapters\" / \"fix adapter structure\"\n- \"apply latest adapter format\" / \"restructure adapters\"\n- \"run adapter migration\" / \"migrate to new format\"\n\n**Trigger pattern:** **migrate** / **batch update** / **structural migration** /\n**update format** + (adapters | protocols | all | space).\n\n**Must Never:**\n- Alter semantic content (step text, trigger phrases, examples, intent).\n- Auto-train without showing the user a change report first.\n- Guess transformations when the adapter structure is ambiguous.\n- Delete adapters or layers during migration.\n- Migrate adapters that already conform (report them as \"no changes needed\").\n\n**Must Always:**\n- Export every adapter before making any changes.\n- Apply only conservative, reversible structural transformations.\n- Flag ambiguous cases for manual review instead of guessing.\n- Show a per-adapter change report before executing any writes.\n- Preserve the adapter's slug, version, and chain_root fields.\n\n**Good trigger examples:**\n- \"migrate all my personal adapters to the latest format\" → run this protocol\n- \"update all adapters in the team space\" → run this protocol\n- \"we changed the solution scheme, update all adapters\" → run this protocol\n\n**Bad trigger examples:**\n- \"update this one adapter\" → use `create-new-protocol` with `fix` operation\n- \"create a new adapter\" → use `create-new-protocol`\n- \"export my adapters\" → use `export` directly\n\n## Preflight Dependencies\n\nBefore running migration, verify readiness:\n\n1. `export` tool is available and callable.\n2. `tune` and `train` tools are available for writes.\n3. Target space is identified (personal or a named group space).\n4. User understands this is a structural-only migration.\n\nIf any tool is unavailable, stop and ask the user to fix the connection.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Export All Adapters\n\nExport every adapter from the target space using bulk export:\n\n1. Call `export` with `all_adapters: true`, `space_name` set to the target\n   space, and `format: skill_tree`.\n2. Record the total adapter count from the response.\n3. For each adapter in the response, extract its slug, URI, and content.\n\nIf the space has no adapters, report this and stop.\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"export\",\"arguments\":{\"all_adapters\":true,\"space_name\":\"<space>\",\"format\":\"skill_tree\"}},\"required\":true}}\n```\n\n## Analyze and Transform\n\nFor each exported adapter, perform structural analysis and apply migrations.\n\n### Structural checks (apply all that are needed)\n\n1. **Heading order** — first H2 must be `Activation Patterns`, last H2 must be\n   `Reward Signal`. If missing or out of order, flag for restructuring.\n2. **Contract fences** — all contract JSON blocks must use ` ```json ` (not\n   plain ` ``` `). If plain fences contain contract JSON, convert them.\n3. **Field rename** — any `\"challenge\":` key inside contract JSON blocks must\n   become `\"contract\":`. Apply globally within JSON fences.\n4. **Frontmatter** — must include `slug`. Add `version` if missing. Preserve\n   existing `chain_root` when present.\n5. **Line count** — adapters exceeding 350 lines must be flagged for splitting\n   (do NOT auto-split; report as manual review needed).\n6. **Phase-critic integration** — check whether the adapter includes at least\n   one `phase-critic` chain link. If not, add a recommendation (do NOT\n   auto-add; report as suggestion).\n\n### Transformation rules\n\n- **Conservative only:** If a transformation might change meaning, skip it and\n  flag for manual review.\n- **Reversible:** Every change must be expressible as a diff so the user can\n  reject individual changes.\n- **Idempotent:** Running migration twice on the same adapter produces no\n  additional changes.\n\nFor each adapter, produce:\n- `status`: `needs_changes` | `up_to_date` | `needs_manual_review`\n- `changes`: list of specific transformations applied\n- `warnings`: list of items flagged for manual review\n- `transformed_content`: the full updated markdown (when `needs_changes`)\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## Report Changes\n\nPresent a summary table to the user:\n\n| Adapter slug | Status | Changes | Warnings |\n|-------------|--------|---------|----------|\n| example-adapter | needs_changes | 3 structural fixes | 0 |\n| another-adapter | up_to_date | 0 | 0 |\n| complex-adapter | needs_manual_review | 1 fix | line count exceeds 350 |\n\nFor each adapter with `needs_changes`, show the specific transformations:\n- What was changed (before/after for the affected lines).\n- Why (which structural rule it satisfies).\n\nFor each adapter with `needs_manual_review`, explain what needs human\nattention and why the protocol cannot auto-fix it.\n\nAsk the user to choose:\n- **Apply all** — train all `needs_changes` adapters.\n- **Select individually** — choose which adapters to update.\n- **Abort** — cancel the migration without changes.\n\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"Review the migration report above. Choose: apply all, select individually, or abort.\"},\"required\":true}}\n```\n\n## Execute Migration\n\nFor each approved adapter, apply the structural changes:\n\n1. For adapters needing only content-level fixes (heading reorder, fence\n   conversion, field rename): use `tune` with the transformed content and\n   the adapter's URI.\n2. For adapters needing structural changes that alter layer count or identity:\n   use `train` with `force_update: true` and the transformed content.\n3. Record the outcome (success or failure) for each adapter.\n\nDo NOT change the adapter's space assignment during migration.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":120},\"required\":true}}\n```\n\n## Verify and Report\n\nAfter executing all approved migrations:\n\n1. Re-export each migrated adapter to verify structural compliance.\n2. Report final status:\n\n| Metric | Count |\n|--------|-------|\n| Adapters scanned | N |\n| Already up to date | N |\n| Successfully migrated | N |\n| Migration failed | N |\n| Flagged for manual review | N |\n\n3. For each failure, report the error message and suggested fix.\n4. Recommend running `phase-critic` on migrated adapters to verify semantic\n   integrity after structural changes.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe adapter library in the target space now conforms to the current structural\nscheme. Every adapter has:\n- Correct heading order (Activation Patterns first, Reward Signal last).\n- Proper ` ```json ` contract fences.\n- Current field names (`contract`, not `challenge`).\n- Valid frontmatter with `slug` and optional `version`.\n- Been verified post-migration for structural compliance.\n\nSemantic content (steps, intent, examples, triggers) is preserved unchanged.\n"
     }
 };
 /**

package/dist/resources/embedded-mcp-resources.js.map

@@ -1 +1 @@
-{"version":3,"file":"embedded-mcp-resources.js","sourceRoot":"","sources":["../../src/resources/embedded-mcp-resources.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,MAAM,CAAC,MAAM,YAAY,GAAG;IAC1B,SAAS,EAAE,EAAE;IACb,WAAW,EAAE,EAAE;IACf,WAAW,EAAE,EAAE;IACf,OAAO,EAAE;QACP,UAAU,EAAE,k9GAAk9G;QAC99G,QAAQ,EAAE,6dAA6d;QACve,QAAQ,EAAE,owIAAowI;QAC9wI,SAAS,EAAE,q0FAAq0F;QACh1F,QAAQ,EAAE,i3CAAi3C;QAC33C,QAAQ,EAAE,44DAA44D;QACt5D,OAAO,EAAE,y5FAAy5F;QACl6F,MAAM,EAAE,2xCAA2xC;KACpyC;IACD,KAAK,EAAE,EAAE;IACT,MAAM,EAAE;QACN,qBAAqB,EAAE,+/bAA+/b;QACthc,eAAe,EAAE,whFAAwhF;QACziF,4BAA4B,EAAE,+qOAA+qO;QAC7sO,sBAAsB,EAAE,6pSAA6pS;QACrrS,cAAc,EAAE,goNAAgoN;QAChpN,wBAAwB,EAAE,wvQAAwvQ;QAClxQ,8BAA8B,EAAE,grKAAgrK;QAChtK,oBAAoB,EAAE,6uRAA6uR;KACpwR;CACF,CAAC;AAEF;;GAEG;AACH,MAAM,UAAU,UAAU;IACxB,OAAO,YAAY,CAAC,OAAO,IAAI,EAAE,CAAC;AACpC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,YAAY;IAC1B,OAAO,YAAY,CAAC,SAAS,IAAI,EAAE,CAAC;AACtC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,YAAY;IAC1B,OAAO,YAAY,CAAC,SAAS,IAAI,EAAE,CAAC;AACtC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,QAAQ;IACtB,OAAO,YAAY,CAAC,KAAK,IAAI,EAAE,CAAC;AAClC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,MAAM;IACpB,OAAO,YAAY,CAAC,GAAG,IAAI,EAAE,CAAC;AAChC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,OAAO;IACrB,OAAO,YAAY,CAAC,IAAI,IAAI,EAAE,CAAC;AACjC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,SAAS,CAAC,GAAW;IACnC,MAAM,OAAO,GAAG,CAAC,YAAY,CAAC,OAAO,IAAI,EAAE,CAA2B,CAAC;IACvE,OAAO,OAAO,CAAC,GAAG,CAAC,CAAC;AACtB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,WAAW,CAAC,GAAW;IACrC,MAAM,KAAK,GAAG,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IAC7B,IAAI,KAAK,CAAC,CAAC,CAAC,KAAK,MAAM,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC9C,MAAM,IAAI,GAAG,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA2B,CAAC;QACjE,OAAO,IAAI,CAAC,KAAK,CAAC,CAAC,CAAE,CAAC,CAAC;IACzB,CAAC;IACD,MAAM,SAAS,GAAG,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAAwB,CAAC;IACxE,IAAI,OAAO,GAAQ,SAAS,CAAC;IAC7B,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,IAAI,OAAO,IAAI,OAAO,OAAO,KAAK,QAAQ,EAAE,CAAC;YAC3C,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;QAC1B,CAAC;aAAM,CAAC;YACN,OAAO,SAAS,CAAC;QACnB,CAAC;IACH,CAAC;IACD,OAAO,OAAO,CAAC;AACjB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,UAAU,CAAC,IAAY;IACrC,MAAM,IAAI,GAAG,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA2B,CAAC;IACjE,OAAO,IAAI,CAAC,IAAI,CAAC,CAAC;AACpB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,WAAW,CAAC,GAAW;IACrC,MAAM,SAAS,GAAG,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA2B,CAAC;IAC3E,OAAO,SAAS,CAAC,GAAG,CAAC,CAAC;AACxB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,UAAU,CAAC,GAAW;IACpC,MAAM,KAAK,GAAG,CAAC,YAAY,CAAC,KAAK,IAAI,EAAE,CAA2B,CAAC;IACnE,OAAO,KAAK,CAAC,GAAG,CAAC,CAAC;AACpB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,gBAAgB;IAC9B,MAAM,OAAO,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,OAAO,IAAI,EAAE,CAA4B,CAAC,CAAC;IACrF,MAAM,SAAS,GAAG,cAAc,CAAC,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA4B,CAAC,CAAC;IAC5F,MAAM,SAAS,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA4B,CAAC,CAAC;IACzF,MAAM,KAAK,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,KAAK,IAAI,EAAE,CAA4B,CAAC,CAAC;IAEjF,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA4B,CAAC,CAAC;IAC/E,MAAM,MAAM,GAA6B,EAAE,OAAO,EAAE,SAAS,EAAE,SAAS,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC;IAExF,qCAAqC;IACrC,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,YAAY,CAAC,EAAE,CAAC;QACxD,IAAI,CAAC,CAAC,SAAS,EAAE,WAAW,EAAE,WAAW,EAAE,OAAO,EAAE,MAAM,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC;YAC1E,IAAI,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;gBAChD,MAAM,CAAC,GAAG,CAAC,GAAG,MAAM,CAAC,IAAI,CAAC,KAAgC,CAAC,CAAC;YAC9D,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,SAAS,cAAc,CAAC,GAAQ,EAAE,SAAiB,EAAE,EAAE,OAAiB,EAAE;IACxE,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC;QAC/C,MAAM,OAAO,GAAG,MAAM,CAAC,CAAC,CAAC,GAAG,MAAM,IAAI,GAAG,EAAE,CAAC,CAAC,CAAC,GAAG,CAAC;QAClD,IAAI,OAAO,KAAK,KAAK,QAAQ,EAAE,CAAC;YAC9B,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QACrB,CAAC;aAAM,IAAI,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;YACvD,cAAc,CAAC,KAAK,EAAE,OAAO,EAAE,IAAI,CAAC,CAAC;QACvC,CAAC;IACH,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC"}
+{"version":3,"file":"embedded-mcp-resources.js","sourceRoot":"","sources":["../../src/resources/embedded-mcp-resources.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,MAAM,CAAC,MAAM,YAAY,GAAG;IAC1B,SAAS,EAAE,EAAE;IACb,WAAW,EAAE,EAAE;IACf,WAAW,EAAE,EAAE;IACf,OAAO,EAAE;QACP,UAAU,EAAE,k9GAAk9G;QAC99G,QAAQ,EAAE,6dAA6d;QACve,QAAQ,EAAE,owIAAowI;QAC9wI,SAAS,EAAE,q0FAAq0F;QACh1F,QAAQ,EAAE,i3CAAi3C;QAC33C,QAAQ,EAAE,44DAA44D;QACt5D,OAAO,EAAE,0tGAA0tG;QACnuG,MAAM,EAAE,kqDAAkqD;KAC3qD;IACD,KAAK,EAAE,EAAE;IACT,MAAM,EAAE;QACN,qBAAqB,EAAE,+pdAA+pd;QACtrd,eAAe,EAAE,+hFAA+hF;QAChjF,4BAA4B,EAAE,0oCAA0oC;QACxqC,sBAAsB,EAAE,woSAAwoS;QAChqS,cAAc,EAAE,y+NAAy+N;QACz/N,wBAAwB,EAAE,ivQAAivQ;QAC3wQ,8BAA8B,EAAE,urKAAurK;QACvtK,oBAAoB,EAAE,suRAAsuR;QAC5vR,oBAAoB,EAAE,4sQAA4sQ;QACluQ,mBAAmB,EAAE,m0PAAm0P;KACz1P;CACF,CAAC;AAEF;;GAEG;AACH,MAAM,UAAU,UAAU;IACxB,OAAO,YAAY,CAAC,OAAO,IAAI,EAAE,CAAC;AACpC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,YAAY;IAC1B,OAAO,YAAY,CAAC,SAAS,IAAI,EAAE,CAAC;AACtC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,YAAY;IAC1B,OAAO,YAAY,CAAC,SAAS,IAAI,EAAE,CAAC;AACtC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,QAAQ;IACtB,OAAO,YAAY,CAAC,KAAK,IAAI,EAAE,CAAC;AAClC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,MAAM;IACpB,OAAO,YAAY,CAAC,GAAG,IAAI,EAAE,CAAC;AAChC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,OAAO;IACrB,OAAO,YAAY,CAAC,IAAI,IAAI,EAAE,CAAC;AACjC,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,SAAS,CAAC,GAAW;IACnC,MAAM,OAAO,GAAG,CAAC,YAAY,CAAC,OAAO,IAAI,EAAE,CAA2B,CAAC;IACvE,OAAO,OAAO,CAAC,GAAG,CAAC,CAAC;AACtB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,WAAW,CAAC,GAAW;IACrC,MAAM,KAAK,GAAG,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IAC7B,IAAI,KAAK,CAAC,CAAC,CAAC,KAAK,MAAM,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC9C,MAAM,IAAI,GAAG,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA2B,CAAC;QACjE,OAAO,IAAI,CAAC,KAAK,CAAC,CAAC,CAAE,CAAC,CAAC;IACzB,CAAC;IACD,MAAM,SAAS,GAAG,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAAwB,CAAC;IACxE,IAAI,OAAO,GAAQ,SAAS,CAAC;IAC7B,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,IAAI,OAAO,IAAI,OAAO,OAAO,KAAK,QAAQ,EAAE,CAAC;YAC3C,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;QAC1B,CAAC;aAAM,CAAC;YACN,OAAO,SAAS,CAAC;QACnB,CAAC;IACH,CAAC;IACD,OAAO,OAAO,CAAC;AACjB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,UAAU,CAAC,IAAY;IACrC,MAAM,IAAI,GAAG,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA2B,CAAC;IACjE,OAAO,IAAI,CAAC,IAAI,CAAC,CAAC;AACpB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,WAAW,CAAC,GAAW;IACrC,MAAM,SAAS,GAAG,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA2B,CAAC;IAC3E,OAAO,SAAS,CAAC,GAAG,CAAC,CAAC;AACxB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,UAAU,CAAC,GAAW;IACpC,MAAM,KAAK,GAAG,CAAC,YAAY,CAAC,KAAK,IAAI,EAAE,CAA2B,CAAC;IACnE,OAAO,KAAK,CAAC,GAAG,CAAC,CAAC;AACpB,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,gBAAgB;IAC9B,MAAM,OAAO,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,OAAO,IAAI,EAAE,CAA4B,CAAC,CAAC;IACrF,MAAM,SAAS,GAAG,cAAc,CAAC,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA4B,CAAC,CAAC;IAC5F,MAAM,SAAS,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,SAAS,IAAI,EAAE,CAA4B,CAAC,CAAC;IACzF,MAAM,KAAK,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,KAAK,IAAI,EAAE,CAA4B,CAAC,CAAC;IAEjF,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,YAAY,CAAC,IAAI,IAAI,EAAE,CAA4B,CAAC,CAAC;IAC/E,MAAM,MAAM,GAA6B,EAAE,OAAO,EAAE,SAAS,EAAE,SAAS,EAAE,KAAK,EAAE,IAAI,EAAE,CAAC;IAExF,qCAAqC;IACrC,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,YAAY,CAAC,EAAE,CAAC;QACxD,IAAI,CAAC,CAAC,SAAS,EAAE,WAAW,EAAE,WAAW,EAAE,OAAO,EAAE,MAAM,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC;YAC1E,IAAI,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;gBAChD,MAAM,CAAC,GAAG,CAAC,GAAG,MAAM,CAAC,IAAI,CAAC,KAAgC,CAAC,CAAC;YAC9D,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,SAAS,cAAc,CAAC,GAAQ,EAAE,SAAiB,EAAE,EAAE,OAAiB,EAAE;IACxE,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC;QAC/C,MAAM,OAAO,GAAG,MAAM,CAAC,CAAC,CAAC,GAAG,MAAM,IAAI,GAAG,EAAE,CAAC,CAAC,CAAC,GAAG,CAAC;QAClD,IAAI,OAAO,KAAK,KAAK,QAAQ,EAAE,CAAC;YAC9B,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QACrB,CAAC;aAAM,IAAI,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;YACvD,cAAc,CAAC,KAAK,EAAE,OAAO,EAAE,IAAI,CAAC,CAAC;QACvC,CAAC;IACH,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC"}

package/dist/resources/mem-injection-assertions.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"mem-injection-assertions.d.ts","sourceRoot":"","sources":["../../src/resources/mem-injection-assertions.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAGhE,eAAO,MAAM,4BAA4B,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAO/D,CAAC;AAEF,wBAAsB,+BAA+B,CAAC,WAAW,EAAE,iBAAiB,GAAG,OAAO,CAAC,IAAI,CAAC,CAiCnG"}
+{"version":3,"file":"mem-injection-assertions.d.ts","sourceRoot":"","sources":["../../src/resources/mem-injection-assertions.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAGhE,eAAO,MAAM,4BAA4B,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAS/D,CAAC;AAEF,wBAAsB,+BAA+B,CAAC,WAAW,EAAE,iBAAiB,GAAG,OAAO,CAAC,IAAI,CAAC,CAiCnG"}

package/dist/resources/mem-injection-assertions.js

@@ -5,7 +5,9 @@ export const SYSTEM_PROTOCOL_UUID_BY_SLUG = {
     'create-new-protocol-review': '00000000-0000-0000-0000-000000002003',
     'challenge-type-guide': '00000000-0000-0000-0000-000000002004',
     'phase-critic': '00000000-0000-0000-0000-000000002005',
-    'protocol-linking-guide': '00000000-0000-0000-0000-000000002006'
+    'protocol-linking-guide': '00000000-0000-0000-0000-000000002006',
+    'phase-critic-guide': '00000000-0000-0000-0000-000000002009',
+    'adapter-migration': '00000000-0000-0000-0000-000000002010'
 };
 export async function assertSystemProtocolStaticUuids(memoryStore) {
     const { client, collection } = memoryStore.getQdrantAccess();

package/dist/resources/mem-injection-assertions.js.map

@@ -1 +1 @@
-{"version":3,"file":"mem-injection-assertions.js","sourceRoot":"","sources":["../../src/resources/mem-injection-assertions.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,mBAAmB,EAAE,MAAM,cAAc,CAAC;AAEnD,MAAM,CAAC,MAAM,4BAA4B,GAA2B;IAClE,qBAAqB,EAAE,sCAAsC;IAC7D,eAAe,EAAE,sCAAsC;IACvD,4BAA4B,EAAE,sCAAsC;IACpE,sBAAsB,EAAE,sCAAsC;IAC9D,cAAc,EAAE,sCAAsC;IACtD,wBAAwB,EAAE,sCAAsC;CACjE,CAAC;AAEF,MAAM,CAAC,KAAK,UAAU,+BAA+B,CAAC,WAA8B;IAClF,MAAM,EAAE,MAAM,EAAE,UAAU,EAAE,GAAG,WAAW,CAAC,eAAe,EAAE,CAAC;IAC7D,MAAM,OAAO,GAAa,EAAE,CAAC;IAC7B,MAAM,UAAU,GAAa,EAAE,CAAC;IAEhC,KAAK,MAAM,CAAC,IAAI,EAAE,IAAI,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,4BAA4B,CAAC,EAAE,CAAC;QACxE,MAAM,SAAS,GAAG,MAAM,MAAM,CAAC,QAAQ,CAAC,UAAU,EAAE;YAClD,GAAG,EAAE,CAAC,IAAI,CAAC;YACX,YAAY,EAAE,IAAI;YAClB,WAAW,EAAE,KAAK;SACnB,CAAC,CAAC;QACH,MAAM,KAAK,GAAG,SAAS,EAAE,CAAC,CAAC,CAAC,CAAC;QAC7B,IAAI,CAAC,KAAK,EAAE,CAAC;YACX,OAAO,CAAC,IAAI,CAAC,GAAG,IAAI,OAAO,IAAI,EAAE,CAAC,CAAC;YACnC,SAAS;QACX,CAAC;QAED,MAAM,OAAO,GAAG,CAAC,KAAK,CAAC,OAAO,IAAI,EAAE,CAA4B,CAAC;QACjE,MAAM,SAAS,GAAG,OAAO,OAAO,CAAC,MAAM,CAAC,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;QAC/E,MAAM,YAAY,GAAG,OAAO,OAAO,CAAC,UAAU,CAAC,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;QAC1F,IAAI,SAAS,KAAK,IAAI,IAAI,YAAY,KAAK,mBAAmB,EAAE,CAAC;YAC/D,UAAU,CAAC,IAAI,CACb,GAAG,IAAI,kBAAkB,IAAI,UAAU,mBAAmB,iBAAiB,SAAS,IAAI,MAAM,UAAU,YAAY,IAAI,MAAM,GAAG,CAClI,CAAC;QACJ,CAAC;IACH,CAAC;IAED,IAAI,OAAO,CAAC,MAAM,GAAG,CAAC,IAAI,UAAU,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAChD,MAAM,IAAI,KAAK,CACb,gEAAgE;YAChE,YAAY,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,iBAAiB,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,CACxE,CAAC;IACJ,CAAC;AACH,CAAC"}
+{"version":3,"file":"mem-injection-assertions.js","sourceRoot":"","sources":["../../src/resources/mem-injection-assertions.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,mBAAmB,EAAE,MAAM,cAAc,CAAC;AAEnD,MAAM,CAAC,MAAM,4BAA4B,GAA2B;IAClE,qBAAqB,EAAE,sCAAsC;IAC7D,eAAe,EAAE,sCAAsC;IACvD,4BAA4B,EAAE,sCAAsC;IACpE,sBAAsB,EAAE,sCAAsC;IAC9D,cAAc,EAAE,sCAAsC;IACtD,wBAAwB,EAAE,sCAAsC;IAChE,oBAAoB,EAAE,sCAAsC;IAC5D,mBAAmB,EAAE,sCAAsC;CAC5D,CAAC;AAEF,MAAM,CAAC,KAAK,UAAU,+BAA+B,CAAC,WAA8B;IAClF,MAAM,EAAE,MAAM,EAAE,UAAU,EAAE,GAAG,WAAW,CAAC,eAAe,EAAE,CAAC;IAC7D,MAAM,OAAO,GAAa,EAAE,CAAC;IAC7B,MAAM,UAAU,GAAa,EAAE,CAAC;IAEhC,KAAK,MAAM,CAAC,IAAI,EAAE,IAAI,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,4BAA4B,CAAC,EAAE,CAAC;QACxE,MAAM,SAAS,GAAG,MAAM,MAAM,CAAC,QAAQ,CAAC,UAAU,EAAE;YAClD,GAAG,EAAE,CAAC,IAAI,CAAC;YACX,YAAY,EAAE,IAAI;YAClB,WAAW,EAAE,KAAK;SACnB,CAAC,CAAC;QACH,MAAM,KAAK,GAAG,SAAS,EAAE,CAAC,CAAC,CAAC,CAAC;QAC7B,IAAI,CAAC,KAAK,EAAE,CAAC;YACX,OAAO,CAAC,IAAI,CAAC,GAAG,IAAI,OAAO,IAAI,EAAE,CAAC,CAAC;YACnC,SAAS;QACX,CAAC;QAED,MAAM,OAAO,GAAG,CAAC,KAAK,CAAC,OAAO,IAAI,EAAE,CAA4B,CAAC;QACjE,MAAM,SAAS,GAAG,OAAO,OAAO,CAAC,MAAM,CAAC,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;QAC/E,MAAM,YAAY,GAAG,OAAO,OAAO,CAAC,UAAU,CAAC,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;QAC1F,IAAI,SAAS,KAAK,IAAI,IAAI,YAAY,KAAK,mBAAmB,EAAE,CAAC;YAC/D,UAAU,CAAC,IAAI,CACb,GAAG,IAAI,kBAAkB,IAAI,UAAU,mBAAmB,iBAAiB,SAAS,IAAI,MAAM,UAAU,YAAY,IAAI,MAAM,GAAG,CAClI,CAAC;QACJ,CAAC;IACH,CAAC;IAED,IAAI,OAAO,CAAC,MAAM,GAAG,CAAC,IAAI,UAAU,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAChD,MAAM,IAAI,KAAK,CACb,gEAAgE;YAChE,YAAY,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,iBAAiB,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,CACxE,CAAC;IACJ,CAAC;AACH,CAAC"}

package/dist/resources/mem-resources-boot.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"mem-resources-boot.d.ts","sourceRoot":"","sources":["../../src/resources/mem-resources-boot.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAShE,wBAAsB,wBAAwB,CAAC,WAAW,EAAE,iBAAiB,EAAE,OAAO,GAAE;IAAE,KAAK,CAAC,EAAE,OAAO,CAAA;CAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CA+H/H"}
+{"version":3,"file":"mem-resources-boot.d.ts","sourceRoot":"","sources":["../../src/resources/mem-resources-boot.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAWhE,wBAAsB,wBAAwB,CAAC,WAAW,EAAE,iBAAiB,EAAE,OAAO,GAAE;IAAE,KAAK,CAAC,EAAE,OAAO,CAAA;CAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CA2K/H"}