{"id":50853330,"url":"https://github.com/aihxp/mythify","last_synced_at":"2026-06-14T16:05:35.448Z","repository":{"id":364401966,"uuid":"1266983528","full_name":"aihxp/mythify","owner":"aihxp","description":"Give any model Mythos-class operational discipline: planning loops, executed verification, and persistent memory via a drop-in protocol, a zero-dependency CLI, and an MCP server.","archived":false,"fork":false,"pushed_at":"2026-06-12T22:10:19.000Z","size":304,"stargazers_count":0,"open_issues_count":4,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-12T23:15:07.335Z","etag":null,"topics":["agent-harness","ai-agents","autonomous-agents","claude","claude-code","claude-desktop","developer-tools","llm","mcp","mcp-server","prompt-engineering"],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/aihxp.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-06-12T05:55:18.000Z","updated_at":"2026-06-12T22:09:17.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/aihxp/mythify","commit_stats":null,"previous_names":["aihxp/mythify"],"tags_count":6,"template":false,"template_full_name":null,"purl":"pkg:github/aihxp/mythify","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aihxp%2Fmythify","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aihxp%2Fmythify/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aihxp%2Fmythify/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aihxp%2Fmythify/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/aihxp","download_url":"https://codeload.github.com/aihxp/mythify/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aihxp%2Fmythify/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34326281,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-14T02:00:07.365Z","response_time":62,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agent-harness","ai-agents","autonomous-agents","claude","claude-code","claude-desktop","developer-tools","llm","mcp","mcp-server","prompt-engineering"],"created_at":"2026-06-14T16:05:34.567Z","updated_at":"2026-06-14T16:05:35.432Z","avatar_url":"https://github.com/aihxp.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Mythify\n\n[![CI](https://github.com/aihxp/mythify/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/mythify/actions/workflows/ci.yml)\n[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)\n\nEvidence protocol for AI coding agents.\n\nMythify improves the harness, not the underlying model. It makes agents plan\nwhen the work needs it, persist state outside the chat, verify claims with real\ncommands, and leave an audit trail of what passed, what failed, and what remains.\n\nThe shortest path is in [docs/start-here.md](docs/start-here.md). Start there if\nyou want to use Mythify before learning the full command surface.\n\n## Start Here\n\nFrom a local clone, install user-local launchers and initialize a project:\n\n```bash\n./scripts/install_user.sh --project /path/to/your/project\ncd /path/to/your/project\nmythify classify \"Fix the failing parser test\"\nmythify plan create \"Fix the failing parser test\" --steps '[{\"title\":\"Reproduce and fix\",\"success_criteria\":\"parser tests pass\"}]'\nmythify step 1 in_progress\n```\n\nThen do the work and record evidence:\n\n```bash\nmythify verify run \"python3 -m unittest discover -s tests\" --claim \"parser tests pass\"\nmythify step 1 completed \"verify run exit 0: parser tests pass\"\nmythify summary\n```\n\nThat loop is the product: goal, action, executed verification, durable record.\nThe rest of the CLI and MCP surface exists for larger workflows.\n\nThe patterns are distilled from the research in\n[docs/research-report.md](docs/research-report.md), which carries its own\ncaveat: training beats prompting. Mythify closes the discipline gap, not the\ncapability gap.\n\n## Components\n\n| Component | Path | Purpose |\n| :--- | :--- | :--- |\n| Protocol variants | `CLAUDE.md`, `AGENTS.md`, `.cursorrules` | Drop-in rules files, generated from `protocol/PROTOCOL.md` by `scripts/build_variants.py`. |\n| CLI | `scripts/mythify.py` | Zero-dependency Python 3.9+ orchestrator for plans, memory, lessons, outcome loops, verification, and reflection. |\n| User installer | `scripts/install_user.sh` | User-local launcher installer for the CLI and packaged MCP server from a checkout. |\n| Shared manifests | `protocol/operation-registry.json`, `protocol/classification-rules.json`, `protocol/surface-manifest.json` | Shared facts used by the CLI, MCP server, tests, and docs to prevent drift. |\n| MCP server | `mcp-server/` | Node 18+ server exposing the same state directory through 36 MCP tools, including task classification, host model switch state, provider probes, local model runs, host CLI probes, bounded host CLI worker runs, execution probes and runs, lifecycle probes, outcome loops, workflow status, verification history, background task status, outcome progress, release readiness, fanout worker timeline, phase status, and parallel delegation (fanout). |\n| Skill | `skills/mythify/` | Manus-style skill package; `scripts/package_skill.py` builds `dist/mythify.skill`. |\n\nAll components read and write the same per-project `.mythify/` state directory, so\nthey interoperate: a plan created by the CLI is visible to the MCP server and vice\nversa.\n\nArchitecture posture: Mythify is moving toward one shared contract core, not a\nsingle runtime. The Python CLI and Node MCP server remain native adapters, while\nduplicated facts move into checked protocol files, registries, generated docs,\nschemas, or manifests one surface at a time.\n\nMigration guide: [docs/cli-to-model-runtime-migration.md](docs/cli-to-model-runtime-migration.md)\nshows how to move from CLI-only usage to optional host, local model, API\nprovider, execution substrate, and lifecycle lanes without hidden routing or\nautomatic spending.\n\nEach quick start begins from a local clone:\n\n```bash\ngit clone https://github.com/aihxp/mythify.git\ncd mythify\n```\n\n## Quick start A: drop-in\n\nCopy a protocol variant and the CLI into your project, then initialize a workspace:\n\n```bash\ncp CLAUDE.md /path/to/your/project/          # or AGENTS.md, or .cursorrules\nmkdir -p /path/to/your/project/scripts\nmkdir -p /path/to/your/project/protocol\ncp scripts/mythify.py /path/to/your/project/scripts/\ncp protocol/operation-registry.json /path/to/your/project/protocol/\ncp protocol/classification-rules.json /path/to/your/project/protocol/\ncd /path/to/your/project\npython3 scripts/mythify.py protocol check CLAUDE.md\npython3 scripts/mythify.py init\n```\n\nThe protocol file steers the agent; the CLI gives it durable plans, memory, lessons,\nand executed verification. `protocol check` confirms the copied protocol file and\nCLI came from the same source protocol before you start relying on them.\n\n## Quick start B: MCP server\n\nInstall dependencies, then point your MCP client at the server:\n\n```bash\ncd mcp-server\nnpm install\n```\n\nAdapt `mcp-server/mcp-config.example.json` for your client:\n\n```json\n{\n  \"mcpServers\": {\n    \"mythify\": {\n      \"command\": \"node\",\n      \"args\": [\"/absolute/path/to/mythify/mcp-server/src/index.js\"],\n      \"env\": {\n        \"MYTHIFY_DIR\": \"/absolute/path/to/your/project/.mythify\"\n      }\n    }\n  }\n}\n```\n\nEnvironment variables:\n\n- `MYTHIFY_DIR` pins the state directory (created on demand). Without it, the server\n  walks up from its working directory to find a `.mythify/` folder, or lazily creates\n  `\u003ccwd\u003e/.mythify` on first write.\n- `MYTHIFY_DISABLE_RUN=1` makes execution refuse: both the CLI `verify run` command\n  and the MCP `verify_run` tool execute nothing and record nothing (the CLI exits 2,\n  the unverified code). Use this in environments where shell execution is not allowed.\n- `MYTHIFY_REQUIRE_VERIFIED_STEP=1` is an opt-in gate: marking a step `completed`\n  (CLI `step` or MCP `plan_update_step`) then requires a recorded passing `verify run`\n  since the step started, not just a non-empty result. Default off keeps the existing\n  behavior.\n- New verification records include active step context when a step is\n  `in_progress`: `plan`, `step_id`, `step_title`, and `step_status`. Null\n  context and older records remain compatible with existing readers.\n\n## Quick start C: build the skill\n\n```bash\npython3 scripts/package_skill.py\n(cd mcp-server \u0026\u0026 npm pack)\n```\n\nThis zips `skills/mythify/` into `dist/mythify.skill` with `SKILL.md` at the zip\nroot and `references/` beside it, and creates the MCP npm tarball under\n`mcp-server/`. See [docs/release.md](docs/release.md) for the full release gate\nand GitHub release process. If you would rather not build the skill yourself, a\nprebuilt `mythify.skill` is attached to each GitHub release at\n[https://github.com/aihxp/mythify/releases](https://github.com/aihxp/mythify/releases).\n\n## How it works\n\n### The autonomy loop\n\nFor any non-trivial task the protocol runs a disciplined loop:\n\n```\nPLAN -\u003e ACT -\u003e VERIFY -\u003e REFLECT -\u003e (CORRECT or ADVANCE)\n```\n\n- PLAN: decompose the goal into verifiable steps (`plan create`, `plan add-step`).\n- ACT: execute the current step with normal tools, one step at a time.\n- VERIFY: run an executable check (`verify run`); fall back to `verify claim` only\n  when nothing executable exists.\n- REFLECT: record what happened and what comes next (`reflect`).\n- CORRECT or ADVANCE: mark the step `failed` with evidence and retry, or mark it\n  `completed` with evidence and move to the next pending step (`step`).\n\nCeremony is proportional. A trivial task (single edit or question) uses no protocol\ncommands. A focused low-risk bugfix or test task can use the fast profile: skip plan\nstate, do the focused work, then record `verify run` before claiming completion. A\nmulti-step single-session task uses a plan plus executed verification of completion\nclaims. Long-horizon or multi-session work uses the full loop with memory and lessons.\n\n### Verification: evidence over attestation\n\nCompletion claims are checked by executing commands and reading exit codes, not by\nself-report. A failing check, a fix, and a passing re-run look like this:\n\n```\n$ python3 scripts/mythify.py verify run \"python3 -m unittest discover -s tests\" --claim \"All tests pass\"\n[FAIL] UNVERIFIED: All tests pass (exit 1, 0.84s)\n--- stderr (tail) ---\nFAIL: test_step_requires_evidence (test_mythify.StepTests)\nAssertionError: 1 != 0\n\n$ # fix the bug, then re-run\n$ python3 scripts/mythify.py verify run \"python3 -m unittest discover -s tests\" --claim \"All tests pass\"\n[OK] VERIFIED: All tests pass (exit 0, 0.79s)\n```\n\n`verify run` exits 0 when the command verified and 2 when it did not, so the agent\n(and your scripts) can branch on the result. Self-reported claims go through\n`verify claim`; they are recorded and displayed as second-class evidence:\n\n```\n[WARN] ATTESTED: \u003cclaim\u003e (self-reported, not machine-checked; prefer verify run)\n```\n\nAn attested entry is never marked verified.\n\n## Outcome loops\n\nUse an outcome loop when the user gives a result more than a recipe: \"make the\nbenchmark pass\", \"produce the best draft under this metric\", or \"keep trying\nuntil the verifier is green.\" The host chat stays the cockpit. Mythify records\nthe target, verifier, optional metric, and iteration budget, then tells the host\nwhether to retry, stop, or report success after each bounded attempt.\n\n```bash\npython3 scripts/mythify.py outcome start \\\n  \"Improve parser reliability\" \\\n  --success \"parser regression tests pass\" \\\n  --verify \"python3 -m unittest tests/test_parser.py\" \\\n  --metric \"python3 scripts/score_parser.py\" \\\n  --max-iterations 3\n```\n\nThe host then makes one focused attempt and checks the result:\n\n```bash\npython3 scripts/mythify.py outcome check --notes \"added empty input guard\"\n```\n\n`outcome check` exits 0 when the verifier and metric pass, and 2 when the loop\nneeds another attempt or has exhausted the budget. Results are durable in\n`.mythify/outcomes/\u003cname\u003e/goal.json` and `iterations.jsonl`, so Codex Desktop,\nClaude Desktop, Cursor Desktop, and the CLI can all resume the same loop\nthrough the same MCP state.\n\n## State layout\n\nEach project owns a `.mythify/` directory:\n\n```\n.mythify/\n|-- memory.json\n|-- host-model.json              optional recorded host chat model request\n|-- outcomes/\n|   |-- active                   text file containing the active outcome slug\n|   `-- \u003cslug\u003e/\n|       |-- goal.json\n|       `-- iterations.jsonl\n|-- plans/\n|   |-- active                   text file containing the slug of the active plan\n|   |-- \u003cslug\u003e.json\n|   `-- archive/\n|       `-- \u003cslug\u003e.json\n|-- lessons/\n|   `-- \u003cslug\u003e.json\n|-- logs/\n|   `-- archive/\n|       `-- \u003clog-stem\u003e-\u003cYYYYMMDDHHMMSS\u003e.jsonl\n|-- provider-audit.jsonl         append-only spawned provider worker audit log\n|-- verifications.jsonl\n`-- reflections.jsonl\n```\n\nThe only global state is the cross-project lessons store in `~/.mythify/lessons/`.\nAll JSON writes are atomic, and corrupt files are renamed aside with a `[WARN]`\ninstead of crashing.\n\n`protocol/operation-registry.json` backs the shared memory operation contract.\nThe Python CLI and MCP server both read it for memory categories, the default\ncategory, and the guarded `memory_clear` refusal text.\n\nUse `logs compact` to keep long-lived workspaces readable. It archives the raw\ntop-level verification and reflection logs under `.mythify/logs/archive/`, then\nkeeps the most recent valid records in the active logs. Compaction is\nmaintenance, not verification evidence.\n\n## CLI command reference\n\n| Command | Behavior | Exit code |\n| :--- | :--- | :--- |\n| `init` | Create `./.mythify` with subdirectories and empty memory.json. If already inside a workspace, print `[WARN]` and exit 0. | 0 |\n| `protocol check [PATH ...] [--json]` | Verify copied protocol files match the CLI's embedded source protocol hash. With no paths, check source repo protocol when present and local `CLAUDE.md`, `AGENTS.md`, and `.cursorrules` files. | 0 if every checked file matches; 1 on missing metadata or drift |\n| `status` | Orientation: active plan with step icons, next pending step and its criteria, one-line counts (memory, lessons, verifications, reflections). | 0; 1 if no workspace |\n| `dashboard [--recent N] [--json]` | Read-only workflow dashboard: active plan, current and next step, active outcome, memory and lesson counts, verification totals, recent verification records, and recent reflections. | 0; 1 if no workspace |\n| `history [--recent N] [--json]` | Read-only verification history: executed and attested records, verdicts, commands, exit codes, duration, and plan or step context from durable state. | 0; 1 if no workspace |\n| `background [--recent N] [--json]` | Read-only background task view: outcome loops, fanout jobs, task counts, current statuses, and next actions from durable state. | 0; 1 if no workspace |\n| `progress [--recent N] [--json]` | Read-only outcome loop progress: active and recent outcomes, iteration budget, verifier exit details, metric score when present, and next action from durable state. | 0; 1 if no workspace |\n| `readiness [--json]` | Read-only release readiness: recorded verification gates, project git state, roadmap state, and release-review status without rerunning gates or declaring the release safe. | 0; 1 if no workspace |\n| `timeline [--recent N] [--json]` | Read-only fanout worker timeline: recent fanout jobs, task start and finish events, duration, status, errors, and output metadata from durable state. | 0; 1 if no workspace |\n| `phase [--recent N] [--json]` | Read-only phase view: active plan steps grouped into Understand, Design, Build, Judge, and Verify, with supporting evidence counts from durable state. | 0; 1 if no workspace |\n| `classify TASK [--json] [--triage never\\|auto\\|always] [--platform auto\\|codex-desktop\\|claude-desktop\\|cursor-desktop] [--effort auto\\|low\\|medium\\|high] [--speed auto\\|standard\\|fast] [--session-model MODEL] [--spawn-ceiling auto\\|lower_only\\|same_or_lower\\|allow_stronger] [--reviewer-strength auto\\|same_or_lower\\|allow_stronger]` | Classify a task before planning. Returns task type, risk, ambiguity, ceremony level, execution profile, verification strategy, fanout recommendation, fast model triage fit, model policy, and task-based host recommendation. `--triage auto` runs a local fast model only when the gate is recommended or required. | 0 |\n| `host-model switch MODEL [--platform P] [--current-model M] [--thinking E] [--speed S] [--reason TEXT] [--json]` | Record a requested host chat model switch in `.mythify/host-model.json`, including `host_capability`, `switch_result`, `host_confirmation`, and `adapter_proof_scan`. This updates Mythify session model policy; the host still owns the actual current chat model unless a future adapter confirms it. | 0; 1 if no workspace |\n| `host-model status [--json]` | Show the recorded host model switch, capability fields, switch result, host confirmation status, and adapter proof scan, if any. | 0; 1 if no workspace |\n| `host-model clear [--json]` | Remove the recorded host model switch. | 0; 1 if no workspace |\n| `outcome start GOAL --success TEXT --verify COMMAND [--metric COMMAND] [--max-iterations N] [--allowed-paths CSV] [--visibility MODE] [--name NAME] [--json]` | Start a supervised outcome loop, set it active, and record the verifier, optional metric, scope hints, visibility policy, and retry budget. | 0; 1 if no workspace or invalid budget |\n| `outcome check [NAME] [--notes TEXT] [--timeout N] [--json]` | Run the verifier and optional metric for the active or named outcome, append an iteration record, and return the next action. | 0 if verified, 2 if still unmet or failed, 1 if not found |\n| `outcome status [NAME] [--json]` | Show outcome status, verifier, metric, iteration budget, and latest next action. | 0; 1 if not found |\n| `outcome results [NAME] [--json]` | Show every recorded verifier iteration plus final status. | 0 if succeeded, 2 otherwise, 1 if not found |\n| `outcome stop [NAME] --reason TEXT [--json]` | Mark an active or named outcome stopped and clear the active pointer when it matches. | 0; 1 if not found |\n| `plan create GOAL [--steps JSON] [--name NAME]` | Create plan, set it active. `--steps` is a JSON array of `{\"title\": str, \"success_criteria\": str (optional)}`. Without `--steps`, create an empty plan and suggest `plan add-step`. Invalid JSON: `[FAIL]`, exit 1. | 0 |\n| `plan add-step TITLE [--criteria TEXT] [--plan NAME]` | Append a step (id = max + 1) to the named or active plan. | 0; 1 if plan not found |\n| `plan list` | List plans with active marker and per-plan progress, plus archived count. | 0 |\n| `plan show [NAME]` | Full detail of the named or active plan. | 0; 1 if not found |\n| `plan switch NAME` | Set the active plan pointer. | 0; 1 if not found |\n| `plan archive [NAME]` | Move plan file to `plans/archive/`; clear the active pointer if it pointed there. On filename conflict in archive, append a timestamp. | 0; 1 if plan not found |\n| `step ID STATUS [RESULT] [--plan NAME]` | Update step status. STATUS must be one of the five enum values, otherwise `[FAIL]`, exit 1. `completed` and `failed` REQUIRE the RESULT argument (evidence or failure description); without it print `[FAIL] Evidence required: pass a RESULT describing what proves this status.` and exit 1. After updating, print the next pending step. | 0 |\n| `memory set KEY VALUE [--category C]` | Category one of fact, decision, discovery, state; default fact. | 0 |\n| `memory get [QUERY] [--category C]` | Case-insensitive substring match over keys and values; optional category filter. | 0 |\n| `memory clear [KEY] [--all]` | KEY removes one entry. `--all` clears everything. Neither: `[FAIL]` explaining the guard, exit 1. | 0 |\n| `lesson add TITLE DETAIL [--tags a,b] [--global]` | Record a lesson in the project store, or the global store with `--global`. | 0 |\n| `lesson list [--tag TAG] [--scope project\\|global\\|all]` | Default scope all; label each lesson `(project)` or `(global)`; `--tag` filters. | 0 |\n| `logs compact [--keep N] [--dry-run] [--json]` | Archive raw top-level verification and reflection logs, then keep the most recent valid records in active logs. Default keep is 1000. `--dry-run` writes nothing. | 0; 1 if keep is invalid |\n| `verify run COMMAND [--claim TEXT] [--timeout N]` | Execute COMMAND through the shell, capture exit code, duration, and output tails, append an executed record, print the verdict. Default timeout 300 seconds. | 0 if verified, 2 if unverified |\n| `verify claim CLAIM EVIDENCE` | Append an attested record and print the `[WARN] ATTESTED` line. | 0 |\n| `reflect [JSON]` or `reflect --action A --outcome O --observation OBS --next N [--root-cause R] [--lesson L]` | Record a structured reflection. Required keys: action, outcome (enum success, partial, failure), observation, next. A provided lesson is auto-recorded as a project lesson tagged `auto-reflected`. JSON positional takes precedence over flags. Missing keys or bad outcome: `[FAIL]`, exit 1. | 0 |\n| `summary` | Full session report: plans and progress, memory count, project and global lesson counts, verification stats (executed passed, executed failed, attested count), reflection count. | 0 |\n\n## MCP tool reference\n\n| Tool | Input schema | Behavior |\n| :--- | :--- | :--- |\n| `classify_task` | `{task: string, format?: enum(text, json), triage?: enum(never, auto, always), triage_engine?: enum(claude-cli, codex-cli, cursor-agent, command), triage_model?: string, triage_timeout_seconds?: number, platform?: enum(auto, unknown, codex-desktop, codex-cli, claude-desktop, claude-code, cursor-desktop, cursor-agent), effort?: enum(auto, low, medium, high), speed?: enum(auto, standard, fast), session_model?: string, spawn_ceiling?: enum(auto, lower_only, same_or_lower, allow_stronger), reviewer_strength?: enum(auto, same_or_lower, allow_stronger)}` | Classify a task before planning. With `triage: auto`, runs one fast local model pass only when the gate is recommended or required. The JSON result includes `execution_profile` for protocol overhead and `model_policy` for host model, task-based host recommendation, spawned engine, spawned model, per-role effort, speed, spawn ceiling, and reviewer strength opt-in. |\n| `host_model_switch` | `{action?: enum(switch, status, clear), platform?: enum(auto, unknown, codex-desktop, codex-cli, claude-desktop, claude-code, cursor-desktop, cursor-agent), target_model?: string, current_model?: string, thinking?: enum(auto, low, medium, high, xhigh, max), speed?: enum(auto, standard, fast), reason?: string, format?: enum(text, json)}` | Record, show, or clear a requested host chat model switch. `switch` writes `.mythify/host-model.json`, returns host-specific switch guidance, `host_capability`, `switch_result`, `host_confirmation`, and `adapter_proof_scan`, and makes later `classify_task` and `fanout_start` calls use the recorded model as the session model when no explicit or env session model is supplied. |\n| `provider_probe` | `{provider?: enum(generic-openai-compatible, ollama, lm-studio, llama-cpp, vllm), base_url?: string, model?: string, check?: enum(models, chat, both), api_key_env?: string, timeout_seconds?: number, prompt?: string, format?: enum(text, json)}` | Probe an OpenAI-compatible provider through `/v1/models` and optionally `/v1/chat/completions`. Generic defaults to `MYTHIFY_OPENAI_COMPAT_BASE_URL`, `MYTHIFY_OPENAI_COMPAT_MODEL`, and `MYTHIFY_OPENAI_COMPAT_API_KEY`; `provider: \"ollama\"` defaults to `MYTHIFY_OLLAMA_BASE_URL` or `http://localhost:11434/v1`; `provider: \"lm-studio\"` defaults to `MYTHIFY_LM_STUDIO_BASE_URL` or `http://localhost:1234/v1`; `provider: \"llama-cpp\"` defaults to `MYTHIFY_LLAMA_CPP_BASE_URL` or `http://localhost:8080/v1`; `provider: \"vllm\"` defaults to `MYTHIFY_VLLM_BASE_URL` or `http://localhost:8000/v1`. Local profiles use their provider-specific model env vars and send no auth header by default. Probe output is material, not verification evidence. |\n| `local_model_run` | `{provider?: enum(generic-openai-compatible, ollama, lm-studio, llama-cpp, vllm), role?: enum(reader, triage), base_url?: string, model?: string, prompt: string, api_key_env?: string, timeout_seconds?: number, max_tokens?: number, format?: enum(text, json)}` | Run a reader or triage prompt against a localhost OpenAI-compatible provider. `provider: \"ollama\"`, `provider: \"lm-studio\"`, `provider: \"llama-cpp\"`, and `provider: \"vllm\"` use local profile defaults. Model output is material, not verification evidence, and the tool writes no Mythify state. |\n| `host_cli_probe` | `{host?: enum(kimi-code, opencode, antigravity), bin?: string, timeout_seconds?: number, format?: enum(text, json)}` | Probe Kimi Code, OpenCode, or Antigravity CLI availability by running version and help commands only. Probe output includes non-mutating proof statuses for current-chat apply, current-chat confirm, worker model override, and thinking override. It is material, not verification evidence, and does not execute a prompt or start workers. |\n| `host_cli_run` | `{host?: enum(kimi-code, opencode, antigravity), bin?: string, prompt: string, cwd?: string, timeout_seconds?: number, model?: string, agent?: string, format?: enum(text, json)}` | Run a bounded Kimi Code, OpenCode, or Antigravity non-interactive prompt. Antigravity requires explicit `cwd`, never passes permission-bypass flags, and treats worker output as material, not verification evidence. The tool writes no Mythify state. |\n| `execution_probe` | `{adapter?: enum(google-colab-cli), bin?: string, timeout_seconds?: number, format?: enum(text, json)}` | Probe Google Colab CLI availability by running version and help commands only. Probe output is material, not verification evidence, and does not provision runtimes, request accelerators, or execute jobs. |\n| `execution_run` | `{adapter?: enum(google-colab-cli), bin?: string, cwd?: string, script_path: string, script_args?: string[], accelerator_type?: enum(cpu, gpu, tpu), accelerator?: enum(T4, L4, G4, H100, A100, v5e1, v6e1), billing_ack?: boolean, data_movement_ack?: boolean, cleanup_ack?: boolean, timeout_seconds?: number, format?: enum(text, json)}` | Run a guarded Google Colab CLI ephemeral job through `colab run`. It requires explicit billing, data movement, and cleanup acknowledgements, never passes `--keep`, writes no Mythify state, and treats remote output as material, not verification evidence. |\n| `lifecycle_probe` | `{adapter?: enum(google-agents-cli, google-adk-cli), bin?: string, timeout_seconds?: number, format?: enum(text, json)}` | Probe Google Agents CLI or ADK CLI availability by running version, help, and eval-help commands only. Returns `lifecycle_lane_contract` with allowed probe commands, disabled lifecycle actions, future guarded actions, eval and deployment prerequisites, mutation policy, and material-only evidence status. Probe output is material, not verification evidence, and does not scaffold, run evals, deploy, publish, mutate cloud resources, or write project state. |\n| `workflow_status` | `{recent?: number, format?: enum(text, json)}` | Read-only dashboard for active plan, current and next step, active outcome, evidence counts, recent verification records, and recent reflections. It does not mutate state and does not treat model confidence as evidence. |\n| `verification_history` | `{recent?: number, format?: enum(text, json)}` | Read-only history of executed and attested verification records, including verdict, command or evidence, exit code, duration, and plan or step context. It does not rerun checks or upgrade attested claims. |\n| `background_status` | `{recent?: number, format?: enum(text, json)}` | Read-only background task view for durable outcome loops and fanout jobs, including task counts, statuses, and next actions. It does not mutate state or treat model confidence as progress. |\n| `outcome_progress` | `{recent?: number, format?: enum(text, json)}` | Read-only progress view for active and recent outcome loops, including iteration budget, verifier exit details, metric score when present, and next action. It does not run checks, make attempts, stop loops, or treat notes as verification. |\n| `release_readiness` | `{format?: enum(text, json)}` | Read-only release readiness view from recorded verification gates, project git state, and roadmap state. It does not rerun gates or declare the release safe. |\n| `fanout_timeline` | `{recent?: number, format?: enum(text, json)}` | Read-only timeline of fanout job creation, task starts, task finishes, duration, status, errors, and output metadata. It does not mutate state or treat worker output as verification evidence. |\n| `phase_status` | `{recent?: number, format?: enum(text, json)}` | Read-only Understand, Design, Build, Judge, Verify phase view for active plan steps and durable evidence counts. It does not mutate state or treat model confidence as progress. |\n| `outcome_start` | `{goal: string, success: string, verify_command: string, metric_command?: string, max_iterations?: number, allowed_paths?: string[], visibility?: enum(auto, quiet, summary, verbose, threaded), name?: string, format?: enum(text, json)}` | Start a supervised outcome loop and set it active. The host agent makes bounded attempts between checks; Mythify records evidence and next action. |\n| `outcome_check` | `{name?: string, notes?: string, timeout_seconds?: number, format?: enum(text, json)}` | Run the verifier and optional metric, append an iteration, record executed verification evidence, and return success, retry, or budget-exhausted guidance. Refuses when `MYTHIFY_DISABLE_RUN=1`. |\n| `outcome_status` | `{name?: string, format?: enum(text, json)}` | Show active or named outcome status, verifier, metric, iteration budget, and next action. |\n| `outcome_results` | `{name?: string, format?: enum(text, json)}` | Show all recorded verifier iterations and final outcome state. |\n| `outcome_stop` | `{name?: string, reason: string, format?: enum(text, json)}` | Mark an outcome stopped and clear the active pointer when it matches. |\n| `memory_store` | `{key: string, value: string, category: enum(fact, decision, discovery, state) = \"fact\"}` | Upsert by key. Returns `[OK]` summary. |\n| `memory_recall` | `{query?: string, category?: enum(fact, decision, discovery, state, all)}` | Substring search as in the CLI. |\n| `memory_clear` | `{key?: string, confirm_clear_all?: boolean}` | With key: remove one. Without key and without `confirm_clear_all: true`: refuse with an explanation, do not clear. |\n| `lesson_record` | `{title: string, detail: string, tags?: string[], scope: enum(project, global) = \"project\"}` | Write a lesson file per the format. |\n| `lesson_recall` | `{tag?: string, scope: enum(project, global, all) = \"all\"}` | List lessons, labeled by scope. |\n| `plan_create` | `{goal: string, name?: string, steps?: [{title: string, success_criteria?: string}]}` | Ids auto-assigned 1-based. Sets active plan. |\n| `plan_add_step` | `{title: string, success_criteria?: string, plan?: string}` | Append to named or active plan. |\n| `plan_update_step` | `{step_id: number, status: enum(pending, in_progress, completed, failed, skipped), result?: string, plan?: string}` | Enforce the evidence rule: `completed` or `failed` without `result` returns `[FAIL] Evidence required ...` and does NOT modify the plan. On success, include the next pending step in the response. |\n| `plan_status` | `{plan?: string}` | Goal, progress count, step list with icons. |\n| `verify_run` | `{command: string, claim?: string, timeout_seconds?: number = 300}` | Execute through the shell, record an executed verification, return the verdict with output tails. If env `MYTHIFY_DISABLE_RUN=1`, refuse with an explanation and record nothing. |\n| `verify_claim` | `{claim: string, evidence: string}` | Record an attested entry, return the `[WARN] ATTESTED` line. |\n| `reflect` | `{action_taken: string, outcome: enum(success, partial, failure), observation: string, root_cause?: string, next_action: string, lesson?: string}` | Append reflection; auto-record lesson if provided (project scope, tag `auto-reflected`). Note: jsonl field names follow the file format (`action`, `next`), not the tool parameter names. |\n| `fanout_start` | `{tasks: [{title: string, prompt: string, context_paths?: string[], role?: enum(worker, reviewer), model?: string, engine?: string, effort?: enum(auto, low, medium, high), speed?: enum(auto, standard, fast)}], purpose?: string, model?: string, engine?: string, effort?: enum(auto, low, medium, high), speed?: enum(auto, standard, fast), visibility?: enum(auto, quiet, summary, verbose, threaded), session_model?: string, spawn_ceiling?: enum(auto, lower_only, same_or_lower, allow_stronger), reviewer_allow_stronger?: boolean, hosted_provider_billing_ack?: boolean, hosted_provider_data_ack?: boolean, hosted_provider_material_ack?: boolean, timeout_seconds?: number}` | Validate the job (1 to `MYTHIFY_FANOUT_MAX_TASKS` tasks, non-empty prompts, engine resolvable, kill switch and depth guard, context files readable, spawned model does not exceed the ceiling unless a reviewer-specific opt-in applies, hosted provider API engines require billing, data, and material-only acknowledgements), create `.mythify/fanout/\u003cjob_id\u003e/job.json`, return the job id immediately, and run the workers in the background with a concurrency pool. Tasks must be fully independent; each task is a fresh model call that costs real money or subscription quota. Visibility defaults to summary unless `visibility`, `purpose`, or task prompts request quiet, verbose, or threaded reporting. |\n| `fanout_status` | `{job_id?: string}` | Default: most recent job. Per-task lines with the step icon convention plus counts, engine, model, effort, speed, elapsed, and visibility. Quiet jobs show aggregate progress and failures only. Tasks left running by a restarted server are marked `interrupted` and reported as such. |\n| `fanout_results` | `{job_id?: string, task_id?: number}` | Return outputs of completed and failed tasks (failures include the error and remediation). Per-task text is capped at 20000 characters with a note pointing at the full output file. Warns when tasks are still running. |\n\n## Fast model triage\n\n`classify` always runs a deterministic classifier first. That output includes\n`execution_profile: direct | fast | standard | full` and\n`model_triage: skip | optional | recommended | required`. The default is to\nstop at deterministic classification, so it is fast and free:\n\n```bash\npython3 scripts/mythify.py classify \"make this better\" --json\n```\n\nWhen you want a cheap second read, opt in:\n\n```bash\npython3 scripts/mythify.py classify \"make this better\" --json --triage auto\n```\n\n`--triage auto` runs one fast model only when the gate is `recommended` or\n`required`; `--triage always` forces it. MCP clients use the same options on\n`classify_task`.\n\nExecution profiles choose protocol overhead. `direct` means answer or make the\nsingle reversible edit with no protocol state. `fast` means skip plan state for\nfocused low-risk work, but still use `verify run`. `standard` means create a plan\nwith verifiable steps. `full` means use plan, memory, step updates, verification,\nreflection, and summary.\n\nClassification also returns a `model_policy` object so Desktop clients do not\nhave to guess which model setting applies where:\n\n- `provider_defaults`: advisory provider defaults for session, triage, reader,\n  fanout worker, reviewer, and verifier roles. These fields do not route work\n  by themselves. They make the default provider posture explicit and use\n  `fallback_policy: \"no_implicit_cross_provider_fallback\"`.\n  `provider_defaults.timeout_metadata_fields` and\n  `provider_defaults.cost_metadata_fields` name the standardized fields Mythify\n  records for timeouts and cost posture.\n  `provider_defaults.provider_catalog` records the provider posture for\n  `host`, `host_cli`, `local_openai_compatible`, `api_provider`, `command`,\n  and `local_command`: allowed roles, default roles, billing posture,\n  execution boundary, evidence status, state-write posture, and fallback\n  policy. Each resolved role also includes its selected `provider_profile`.\n  `provider_defaults.adapter_interface_contract` defines the shared adapter\n  metadata shape across host, desktop agent, model provider, API provider,\n  custom adapter, execution substrate, and agent lifecycle lanes. It is a\n  metadata contract only: it does not enable runtime routing, fallback, or new\n  state writes.\n  `provider_defaults.role_assignment_contract` maps session, triage, reader,\n  fanout worker, reviewer, verifier, remote execution, and agent lifecycle\n  roles to eligible adapter-interface lanes and provider posture. MCP also\n  reports eligible candidate IDs from the adapter registry. The contract keeps\n  `runtime_routing_changed: false`, preserves no-hidden-fallback discipline,\n  and marks worker, remote execution, and lifecycle outputs as material rather\n  than verification evidence.\n  `provider_defaults.api_provider_contract` lists metadata-supported hosted\n  API providers, currently OpenAI, Anthropic, and hosted OpenAI-compatible\n  endpoints. It records auth env names, billing posture, timeout fields, cost\n  metadata fields, pricing URLs, and `execution_enabled: false` for general\n  provider role routing. The explicit fanout API path is recorded separately\n  with `fanout_execution_enabled: true`, engines `anthropic` and `openai`,\n  required acknowledgement fields, `.mythify/provider-audit.jsonl`, and\n  `fanout_output_material_status: \"material_not_verification\"`.\n  `provider_defaults.custom_adapter_contract` records two user-defined adapter\n  paths. `command` is enabled only through `MYTHIFY_TRIAGE_COMMAND` or\n  `MYTHIFY_FANOUT_COMMAND`, reads the prompt on stdin, obeys role timeouts,\n  writes no Mythify state, and returns material rather than verification\n  evidence. `http` is metadata-only: it records env names for a future custom\n  HTTP worker, but keeps `execution_enabled: false` until method allowlists,\n  auth handling, request templating, response extraction, cost metadata, and\n  evidence boundaries are explicitly designed.\n  Each resolved role also includes `timeout` and `cost` objects. `timeout`\n  records the timeout seconds, source, enforcer, and whether callers can\n  override it. `cost` records billing posture, estimate support, explicit\n  `not_estimated` status, nullable estimate cents, pricing URL, and usage\n  metadata fields. Mythify does not estimate dollars without real usage data.\n- `session`: the active conversation model is host-selected. Codex Desktop,\n  Claude Desktop, Cursor Desktop, and CLI hosts own that dropdown or command\n  flag. `host_model_switch` and `host-model switch` can record the intended\n  model in Mythify state, but the host still applies the current chat switch.\n  The `host_confirmation` record keeps user-reported current model input\n  separate from any future host-confirmed current model evidence.\n  The `adapter_proof_scan` record reports supported, unsupported, or unknown\n  apply and confirm paths without mutating host state.\n  The future proof criteria for current-chat apply, current-chat confirm,\n  worker model override, and thinking override are tracked in\n  [docs/host-apply-confirm-proof-watchlist.md](docs/host-apply-confirm-proof-watchlist.md).\n  `session.recommendation` maps the classified prompt to host settings:\n  target profile, target model, thinking, speed, and whether to keep,\n  downgrade, upgrade, or set the host model.\n- `triage`: the optional fast problem-framing worker, including spawned engine,\n  spawned model policy, effort, timeout, cost posture, and sandbox.\n- `reader`: optional read-only model role for inspecting supplied material.\n  It defaults to the localhost OpenAI-compatible provider path and can use the\n  explicit Ollama profile. It returns material, not verification evidence.\n- `fanout_worker`: the default policy for independent spawned workers.\n  Includes the recommended chat visibility mode, defaulting to `summary`\n  unless the prompt asks for quiet, verbose, or threaded reporting.\n- `reviewer`: whether a separate review worker is useful and what effort it\n  should use. Reviewers default to same-or-lower than the initiating session;\n  `--reviewer-strength allow_stronger` and MCP\n  `reviewer_strength: \"allow_stronger\"` record classifier policy. Actual\n  fanout still requires `role: \"reviewer\"` plus per-job\n  `reviewer_allow_stronger: true` before a reviewer can exceed the session\n  model without the broader `spawn_ceiling: \"allow_stronger\"` escape hatch.\n- `verifier`: always command-first. Executable `verify_run` evidence beats\n  model judgment.\n\nUse `--platform codex-desktop`, `--platform claude-desktop`, or\n`--platform cursor-desktop` when the host is known. Use `--effort` and\n`--speed` only as policy preferences for spawned roles; they do not override\nthe current desktop chat model.\n\nTask-based host recommendations keep cheap prompts cheap. For example,\n`classify \"what is 1 + 1?\" --json --platform codex-desktop --session-model gpt-5.5`\nreturns a `session.recommendation` to downgrade to the fast profile,\n`gpt-5.4-mini`, low thinking, and fast speed. A research prompt such as\n`make me a research paper about memory consolidation in LLM agents` returns\nthe strong profile, `gpt-5.5`, high thinking, and standard speed on Codex\nDesktop. Claude maps the same profiles to `haiku`, `sonnet`, and `opus`;\nCursor maps them to the local `gpt-5.3-codex` variants.\n\nUse `--session-model` or `MYTHIFY_SESSION_MODEL` when the host can tell\nMythify the initiating model. If neither is set, Mythify falls back to the\nrecorded `.mythify/host-model.json` target from `host_model_switch` or\n`host-model switch`. Mythify classifies that name into a rough tier\n(`small`, `fast`, `standard`, `strong`, `frontier`, or `unknown`) and applies\n`--spawn-ceiling` or `MYTHIFY_SPAWN_CEILING`. The default ceiling is\n`same_or_lower`: spawned workers should be equivalent to or lower than the\nsession model. `allow_stronger` is the broad global opt-in. Prefer the\nreviewer-scoped opt-ins when only an independent reviewer should be stronger.\n\nProvider defaults can be made explicit with environment variables:\n`MYTHIFY_ROLE_SESSION_PROVIDER`, `MYTHIFY_ROLE_TRIAGE_PROVIDER`,\n`MYTHIFY_ROLE_READER_PROVIDER`, `MYTHIFY_ROLE_WORKER_PROVIDER`,\n`MYTHIFY_ROLE_REVIEWER_PROVIDER`, and `MYTHIFY_ROLE_VERIFIER_PROVIDER`.\nInvalid values are ignored and reported in `model_policy.provider_defaults`.\n\nBuilt-in role provider catalog:\n\n| Provider | Default roles | Allowed roles | Execution boundary | Evidence |\n| :--- | :--- | :--- | :--- | :--- |\n| `host` | `session` | `session`, `reader` | Host-selected current conversation | Host output is not verification |\n| `host_cli` | `triage`, `fanout_worker`, `reviewer` | `triage`, `fanout_worker`, `reviewer` | Bounded local host CLI worker | Worker output is material, not verification |\n| `local_openai_compatible` | `reader` | `triage`, `reader` | Localhost OpenAI-compatible model provider | Model output is material, not verification |\n| `api_provider` | none | `fanout_worker`, `reviewer` | Guarded fanout API execution with explicit hosted provider acknowledgements | Provider output is material, not verification |\n| `command` | none | `triage`, `fanout_worker`, `reviewer` | Explicit user command | Command output is material, not verification |\n| `local_command` | `verifier` | `verifier` | Local executed verifier | Exit code is verification evidence |\n\nFast triage engines are local-first and do not require API keys:\n\n| Env or option | Default | Meaning |\n| :--- | :--- | :--- |\n| `--triage-engine`, `MYTHIFY_TRIAGE_ENGINE` | auto | `claude-cli`, `codex-cli`, `cursor-agent`, or `command`. |\n| `--triage-model`, `MYTHIFY_TRIAGE_MODEL` | engine default | Fast model. `claude-cli` defaults to `haiku`; Codex and Cursor use their local defaults unless set. |\n| `MYTHIFY_TRIAGE_COMMAND` | unset | Shell command for the `command` engine. Reads the triage prompt on stdin and must print JSON. |\n| `MYTHIFY_TRIAGE_CLAUDE_BIN`, `MYTHIFY_TRIAGE_CODEX_BIN`, `MYTHIFY_TRIAGE_CURSOR_BIN` | resolved | Override local CLI binary paths. Fanout binary env vars are used as fallbacks. |\n\nThe triage model must return JSON with fields such as `primary_type`,\n`secondary_types`, `hidden_questions`, `verification_plan`, `fanout_plan`, and\n`recommended_first_step`. Mythify records the parsed JSON in the classification\nresult; it does not treat that model output as verification.\n\n## Parallel delegation (fanout)\n\nThe MCP server can fan work out to parallel sub-workers. The orchestrating\nmodel declares a one-shot task list with `fanout_start`, and the server does\nthe orchestration: spawning, sequencing, and collecting. This deliberately\navoids turn-by-turn coordination, which weaker models cannot sustain. Each\nworker is one fresh model invocation with no memory of the conversation, so\nevery task prompt must stand alone, with files supplied through\n`context_paths`. Worker outputs are material, not verification: merge them,\nthen verify the merged work with `verify_run`. Fanout is MCP-only; the CLI\ndoes not implement it (a CLI host has shell access and usually its own\nparallelism).\n\nSubagent visibility defaults to `summary`. In the main chat, the host should\nshow worker titles, status counts, and notable findings without dumping every\nworker transcript. Use `visibility: \"quiet\"` for background-only work,\n`visibility: \"verbose\"` when the user asks to see detailed worker output, and\n`visibility: \"threaded\"` when the user asks for visible worker chats. Threaded\nmode is a host request: Mythify records it, but visible Codex, Claude, or\nCursor threads require native host support. `visibility: \"auto\"` or an omitted\nvisibility field infers the mode from `purpose` and task prompts, falling back\nto `summary`.\n\n### Engines\n\nSix engines run the workers. The headline options need no API keys: workers\nrun through local CLIs that use the subscription login you already have in\nyour terminal.\n\n| Engine | Mechanism | Billing | Models |\n| :--- | :--- | :--- | :--- |\n| `claude-cli` | Spawns the `claude` binary in print mode, one process per task, with the assembled prompt on stdin. | Claude subscription (or whatever auth the claude CLI resolves) | Aliases `haiku`, `sonnet`, `opus`, `fable`, or any full model ID |\n| `codex-cli` | Spawns `codex exec` non-interactively, with the assembled prompt on stdin and the final message captured from `--output-last-message`. | Codex CLI login, usually your ChatGPT/Codex subscription or configured Codex auth | Any model your Codex CLI supports; omit the model to use your Codex default |\n| `cursor-agent` | Spawns `cursor-agent --print` (or `cursor agent --print`) against a temporary prompt file under `.mythify/`. | Cursor Agent login, usually your Cursor subscription or configured Cursor auth | Any model your Cursor Agent account exposes; omit the model to use your Cursor default |\n| `anthropic` | POST `https://api.anthropic.com/v1/messages`. | API key (`ANTHROPIC_API_KEY`) | Any Claude model ID |\n| `openai` | POST `\u003cMYTHIFY_FANOUT_BASE_URL\u003e/chat/completions`. | Provider API key (`MYTHIFY_FANOUT_API_KEY`) | Any model the endpoint serves |\n| `command` | Runs the `MYTHIFY_FANOUT_COMMAND` shell template; prompt on stdin, stdout is the output, exit 0 is success. | Whatever the command does | Anything (generic CLI agents) |\n\nThe `command` engine is the supported custom command adapter path. Its output\nis still worker material, not verification evidence; the orchestrator must\ninspect it and then run `verify_run` for any completion claim.\n\nThe hosted provider engines, `anthropic` and `openai`, require explicit\nacknowledgements before a job starts: `hosted_provider_billing_ack: true`,\n`hosted_provider_data_ack: true`, and `hosted_provider_material_ack: true`.\nThe first acknowledges metered external billing, the second acknowledges that\nthe prompt and inlined context leave the local machine, and the third\nacknowledges that provider output is material, not verification evidence.\n\nEvery spawned fanout task appends redacted start and finish events to\n`.mythify/provider-audit.jsonl`. The audit rows record the fanout surface,\nprovider class (`host_cli`, `api_provider`, or `custom_command`), engine,\nmodel, role, billing posture, cost metadata fields, timeout metadata, prompt\nhash and byte count, output byte count, and the verification boundary. They do\nnot store raw prompts or worker output, and they explicitly mark worker output\nas material rather than verification evidence.\n\nThe engine is set by `MYTHIFY_FANOUT_ENGINE`, or auto-detected in this order:\n`claude-cli` if a claude binary resolves, else `codex-cli` if a codex binary\nresolves, else `cursor-agent` if Cursor Agent resolves, else `anthropic` if\n`ANTHROPIC_API_KEY` is set, else `command` if `MYTHIFY_FANOUT_COMMAND` is set,\nelse `fanout_start` refuses with a message listing all six options. `openai`\nis available when selected explicitly with `MYTHIFY_FANOUT_ENGINE=openai`.\n\n### Model selection\n\nThree levels, most specific wins: per-task `model` overrides per-job `model`\noverrides `MYTHIFY_FANOUT_MODEL` overrides the engine default (`haiku` for\n`claude-cli`, `claude-haiku-4-5` for `anthropic`, and your local CLI default\nfor `codex-cli` and `cursor-agent`). The same precedence applies to `engine`,\nso one job can mix models and engines across tasks. A typical mix is cheap\nhaiku drafters plus a sonnet reviewer; the reviewer is still an independent\ntask that reviews material supplied in its own prompt, not the other tasks'\noutputs:\n\n```json\n{\n  \"model\": \"haiku\",\n  \"tasks\": [\n    {\"title\": \"Draft install section\", \"prompt\": \"Write the install section of the user guide. Use only the outline below.\", \"context_paths\": [\"docs/outline.md\"]},\n    {\"title\": \"Draft config section\", \"prompt\": \"Write the configuration section of the user guide. Use only the outline below.\", \"context_paths\": [\"docs/outline.md\"]},\n    {\"title\": \"Review outline for gaps\", \"prompt\": \"List every topic the outline below misses that a user guide must cover, ranked by importance.\", \"model\": \"sonnet\", \"context_paths\": [\"docs/outline.md\"]}\n  ]\n}\n```\n\n### Spawn ceiling\n\nFanout also accepts `session_model` and `spawn_ceiling`. The session model can\ncome from the tool call, `MYTHIFY_SESSION_MODEL`, or the recorded\n`.mythify/host-model.json` target; the ceiling can come from the tool call or\n`MYTHIFY_SPAWN_CEILING`. The default ceiling is `same_or_lower`.\n\nWhen Mythify can classify both the initiating model and the spawned model into\ntiers, `fanout_start` refuses a stronger spawned model unless the ceiling is\n`allow_stronger`. A narrower path exists for review tasks: a task with\n`role: \"reviewer\"` may exceed the session under `same_or_lower` only when the\njob also sets `reviewer_allow_stronger: true`. This keeps cheap triage and\nmechanical fanout from accidentally exceeding the orchestrating model. Unknown\nlocal CLI defaults are recorded as `uncheckable`; Mythify does not guess what\nCodex Desktop, Claude, or Cursor currently maps a blank model setting to.\n\n```json\n{\n  \"session_model\": \"haiku\",\n  \"spawn_ceiling\": \"same_or_lower\",\n  \"tasks\": [\n    {\"title\": \"Scan docs\", \"prompt\": \"Find missing sections.\", \"model\": \"haiku\"}\n  ]\n}\n```\n\nTo deliberately use a stronger reviewer:\n\n```json\n{\n  \"session_model\": \"haiku\",\n  \"reviewer_allow_stronger\": true,\n  \"tasks\": [\n    {\"title\": \"High-risk review\", \"role\": \"reviewer\", \"prompt\": \"Review this patch for bugs.\", \"model\": \"sonnet\"}\n  ]\n}\n```\n\nThat reviewer-scoped opt-in applies only to tasks with `role: \"reviewer\"` and\ndoes not weaken the same-or-lower default for ordinary worker tasks.\n\n### Effort selection\n\nEffort is tracked separately from model. Per-task `effort` overrides per-job\n`effort`, which overrides `MYTHIFY_FANOUT_EFFORT`, which falls back to a\nmodel-derived default (`low` for small or fast model names, `high` for large\nor heavy model names, otherwise `medium`). The resolved effort and its source\nare stored in `job.json`, shown in `fanout_status`, and inserted into each\nworker prompt as `Requested effort: \u003clevel\u003e`.\n\nThis is intentionally platform-aware but conservative. Codex, Claude, and\nCursor expose model and reasoning controls differently, so Mythify records the\npolicy and passes effort through the worker prompt. Platform-specific flags can\nstill be supplied through `MYTHIFY_FANOUT_CODEX_ARGS`,\n`MYTHIFY_FANOUT_CLAUDE_ARGS`, or `MYTHIFY_FANOUT_CURSOR_ARGS`.\n\n### Speed selection\n\nSpeed is tracked separately from effort. Per-task `speed` overrides per-job\n`speed`, which overrides `MYTHIFY_FANOUT_SPEED`, which otherwise stays `auto`.\n`auto` preserves the platform default.\n\nPlatform mapping:\n\n- `codex-cli`: `speed: \"fast\"` adds `service_tier = \"fast\"` and\n  `features.fast_mode = true`; `speed: \"standard\"` adds\n  `features.fast_mode = false`.\n- `claude-cli`: `effort` is passed as `--effort`; `speed` is recorded and\n  included in the worker prompt because Claude Code does not expose a separate\n  speed flag.\n- `cursor-agent`: Mythify resolves encoded model ids from the local\n  `cursor-agent models` list. For example, `model: \"gpt-5.3-codex\"`,\n  `effort: \"high\"`, and `speed: \"fast\"` resolves to\n  `gpt-5.3-codex-high-fast` when that model is available.\n\n### Cost and timeout metadata\n\nFanout records the resolved timeout and cost posture in `job.json` and each\ntask. `timeout_source` is `explicit`, `env:MYTHIFY_FANOUT_TIMEOUT_SECONDS`,\n`default`, or `default_invalid_env_ignored`.\n\nCost fields are descriptive, not estimates. Each job and task records\n`billing`, `pricing_url`, `cost_tracking: \"metadata_only_no_estimate\"`,\n`cost_estimate_status: \"not_estimated\"`, and `cost_estimate_cents: null`.\nCLI subscription workers, hosted API workers, and user commands therefore stay\nauditable without Mythify inventing token or dollar math.\n\n### Configuration\n\n| Env | Default | Meaning |\n| :--- | :--- | :--- |\n| `MYTHIFY_DISABLE_FANOUT` | unset | `1` disables all three tools (they refuse with an explanation). |\n| `MYTHIFY_FANOUT_ENGINE` | auto | `claude-cli`, `codex-cli`, `cursor-agent`, `anthropic`, `openai`, `command`. |\n| `MYTHIFY_FANOUT_MODEL` | engine default | Default worker model. |\n| `MYTHIFY_SESSION_MODEL` | recorded host model or unknown | Current host session model used for spawn ceiling checks. Beats `.mythify/host-model.json` when set. |\n| `MYTHIFY_SPAWN_CEILING` | `same_or_lower` | Spawn ceiling: `auto`, `lower_only`, `same_or_lower`, or `allow_stronger`. |\n| `MYTHIFY_REVIEWER_STRENGTH` | `same_or_lower` | Reviewer strength policy: `auto`, `same_or_lower`, or `allow_stronger`. |\n| `MYTHIFY_OLLAMA_BASE_URL` | `http://localhost:11434/v1` | Local Ollama OpenAI-compatible `/v1` endpoint for `provider: \"ollama\"`. |\n| `MYTHIFY_OLLAMA_MODEL` | unset | Ollama model id for probe chat checks and local reader or triage runs. |\n| `MYTHIFY_LM_STUDIO_BASE_URL` | `http://localhost:1234/v1` | Local LM Studio OpenAI-compatible `/v1` endpoint for `provider: \"lm-studio\"`. |\n| `MYTHIFY_LM_STUDIO_MODEL` | unset | LM Studio model id for probe chat checks and local reader or triage runs. |\n| `MYTHIFY_LLAMA_CPP_BASE_URL` | `http://localhost:8080/v1` | Local llama.cpp OpenAI-compatible `/v1` endpoint for `provider: \"llama-cpp\"`. |\n| `MYTHIFY_LLAMA_CPP_MODEL` | unset | llama.cpp model id for probe chat checks and local reader or triage runs. |\n| `MYTHIFY_VLLM_BASE_URL` | `http://localhost:8000/v1` | Local vLLM OpenAI-compatible `/v1` endpoint for `provider: \"vllm\"`. |\n| `MYTHIFY_VLLM_MODEL` | unset | vLLM model id for probe chat checks and local reader or triage runs. |\n| `OPENAI_API_KEY` | unset | OpenAI API key env name recorded in hosted provider metadata. Fanout's OpenAI-compatible engine uses `MYTHIFY_FANOUT_API_KEY` instead. |\n| `MYTHIFY_OPENAI_API_MODEL` | unset | OpenAI API model id env name recorded in hosted provider metadata. |\n| `ANTHROPIC_API_KEY` | unset | Anthropic API key env name recorded in hosted provider metadata and used by the guarded `anthropic` fanout engine after hosted provider acknowledgements. |\n| `MYTHIFY_ANTHROPIC_API_MODEL` | unset | Anthropic API model id env name recorded in hosted provider metadata. |\n| `MYTHIFY_HOSTED_OPENAI_COMPAT_BASE_URL` | unset | Hosted OpenAI-compatible `/v1` endpoint env name recorded in provider metadata. |\n| `MYTHIFY_HOSTED_OPENAI_COMPAT_API_KEY` | unset | Hosted OpenAI-compatible API key env name recorded in provider metadata. |\n| `MYTHIFY_HOSTED_OPENAI_COMPAT_MODEL` | unset | Hosted OpenAI-compatible model id env name recorded in provider metadata. |\n| `MYTHIFY_HOSTED_OPENAI_COMPAT_PROVIDER` | unset | Optional hosted OpenAI-compatible provider label env name recorded in provider metadata. |\n| `MYTHIFY_HOSTED_OPENAI_COMPAT_PRICING_URL` | unset | Optional hosted OpenAI-compatible pricing URL env name recorded in provider metadata. |\n| `MYTHIFY_HOST_FAST_MODEL` | platform default | Host recommendation model for direct, trivial, or focused low-risk prompts. |\n| `MYTHIFY_HOST_STANDARD_MODEL` | platform default | Host recommendation model for balanced implementation, debugging, review, and docs prompts. |\n| `MYTHIFY_HOST_STRONG_MODEL` | platform default | Host recommendation model for research, benchmarks, design, release, migration, and security prompts. |\n| `MYTHIFY_ROLE_SESSION_PROVIDER` | `host` | Advisory provider default for the session role. Invalid values are ignored. |\n| `MYTHIFY_ROLE_TRIAGE_PROVIDER` | `host_cli` | Advisory provider default for the triage role. Invalid values are ignored. |\n| `MYTHIFY_ROLE_READER_PROVIDER` | `local_openai_compatible` | Advisory provider default for the reader role. Invalid values are ignored. |\n| `MYTHIFY_ROLE_WORKER_PROVIDER` | `host_cli` | Advisory provider default for the fanout worker role. Invalid values are ignored. |\n| `MYTHIFY_ROLE_REVIEWER_PROVIDER` | `host_cli` | Advisory provider default for the reviewer role. Invalid values are ignored. |\n| `MYTHIFY_ROLE_VERIFIER_PROVIDER` | `local_command` | Advisory provider default for the verifier role. Invalid values are ignored. |\n| `MYTHIFY_FANOUT_EFFORT` | model-derived | Default worker effort: `auto`, `low`, `medium`, or `high`. |\n| `MYTHIFY_FANOUT_SPEED` | auto | Default worker speed: `auto`, `standard`, or `fast`. Auto preserves platform defaults; fast enables Codex fast mode where supported. |\n| `MYTHIFY_FANOUT_VISIBILITY` | auto | Worker visibility mode: `auto`, `quiet`, `summary`, `verbose`, or `threaded`. Auto infers from `purpose` and task prompts, then defaults to summary. |\n| `MYTHIFY_FANOUT_CONCURRENCY` | 3 | Parallel workers per job. |\n| `MYTHIFY_FANOUT_MAX_TASKS` | 16 | Max tasks per job. |\n| `MYTHIFY_FANOUT_MAX_TOKENS` | 8000 | API engines' max_tokens. |\n| `MYTHIFY_FANOUT_MAX_TURNS` | 25 | claude-cli `--max-turns`. |\n| `MYTHIFY_FANOUT_TIMEOUT_SECONDS` | 600 | Per-worker timeout; on expiry the worker is killed and the task fails with a timeout error. |\n| `MYTHIFY_FANOUT_PRICING_URL` | unset | Optional pricing reference recorded for `openai` fanout engine cost metadata. No estimates are computed. |\n| `MYTHIFY_FANOUT_CONTEXT_BYTES` | 200000 | Total inlined context per task. |\n| `MYTHIFY_FANOUT_CLAUDE_BIN` | resolved | Path to the claude binary. |\n| `MYTHIFY_FANOUT_CLAUDE_ARGS` | empty | Extra claude args, for example `--allowedTools \"Bash\"`. |\n| `MYTHIFY_FANOUT_CODEX_BIN` | resolved | Path to the codex binary. |\n| `MYTHIFY_FANOUT_CODEX_SANDBOX` | `read-only` | Codex sandbox mode for workers. Set `workspace-write` only when workers may edit. |\n| `MYTHIFY_FANOUT_CODEX_ARGS` | empty | Extra codex exec args. |\n| `MYTHIFY_FANOUT_CURSOR_BIN` | resolved | Path to `cursor-agent` or `cursor`; if it points at `cursor`, Mythify runs `cursor agent`. |\n| `MYTHIFY_FANOUT_CURSOR_AGENT_BIN` | resolved | Path to `cursor-agent`, used only when `MYTHIFY_FANOUT_CURSOR_BIN` is not set. |\n| `MYTHIFY_FANOUT_CURSOR_MODELS` | auto-list | Optional whitespace or comma-separated Cursor model id list. When unset, Mythify runs `cursor-agent models` or `cursor agent models` to resolve encoded model ids. |\n| `MYTHIFY_FANOUT_CURSOR_MODE` | `ask` | Cursor Agent mode for workers. Empty string omits `--mode`. |\n| `MYTHIFY_FANOUT_CURSOR_FORCE` | unset | `1` adds `--force` for Cursor Agent workers. |\n| `MYTHIFY_FANOUT_CURSOR_ARGS` | empty | Extra Cursor Agent args. |\n| `MYTHIFY_FANOUT_BASE_URL`, `MYTHIFY_FANOUT_API_KEY` | unset | openai engine endpoint and key. |\n| `MYTHIFY_FANOUT_COMMAND` | unset | command engine shell template. |\n\n### Subscription auth for local CLI workers\n\nWorkers spawned by the server need credentials the same way your terminal\ndoes. API keys are not required for the local engines.\n\nFor Claude workers, either:\n\n- run `claude /login` once in a terminal (workers inherit the stored\n  credential through `HOME`), or\n- run `claude setup-token` and set `CLAUDE_CODE_OAUTH_TOKEN` in the MCP\n  client's `env` block.\n\nA worker failure whose output contains `Not logged in` or `401` is reported\nwith exactly that remediation.\n\nFor Codex workers, run:\n\n```bash\ncodex login\n```\n\nMythify then runs `codex exec` with `HOME` and `CODEX_HOME` (when set), so the\nworker uses your existing local Codex authentication. The default worker\nsandbox is `read-only`; set `MYTHIFY_FANOUT_CODEX_SANDBOX=workspace-write` if\nyou intentionally want Codex workers to edit files.\n\nFor Cursor workers, run:\n\n```bash\ncursor-agent login\n```\n\nor, if your install exposes only the `cursor` binary:\n\n```bash\ncursor agent login\n```\n\nMythify runs Cursor Agent in print mode with `--trust --workspace \u003cproject\u003e`.\nBy default it uses `--mode ask`, which is read-only and fits fanout's \"return\nmaterial, then merge and verify\" workflow. Set `MYTHIFY_FANOUT_CURSOR_MODE=`\nto omit the mode, or `MYTHIFY_FANOUT_CURSOR_FORCE=1` when you deliberately\nwant force-approved commands.\n\n### Caveats\n\n- Workers on the API engines (`anthropic`, `openai`) are text-only: one prompt\n  in, one completion out. They cannot run tools or read files beyond the\n  context inlined into their prompt.\n- `claude-cli` workers run Claude Code non-interactively and get its default\n  tool sandbox; grant more with `MYTHIFY_FANOUT_CLAUDE_ARGS`, for example\n  `--allowedTools \"Bash\"`.\n- `codex-cli` workers default to a read-only Codex sandbox. Raise that only\n  when isolated worker edits are acceptable.\n- `cursor-agent` workers default to ask mode. Remove that mode only when you\n  want the full agent behavior.\n- Background workers live in the MCP server process. If the client disconnects\n  or the server dies, running tasks die with it, and `fanout_status` reports\n  them as interrupted afterward.\n- Depth limit of one: workers are spawned with `MYTHIFY_FANOUT_DEPTH=1` and\n  `MYTHIFY_DISABLE_FANOUT=1` in their environment, so a worker cannot fan out\n  again.\n\n## Compatibility\n\n| Environment | Integration |\n| :--- | :--- |\n| Claude Code | Copy `CLAUDE.md` to the project root, or register the MCP server. |\n| Codex CLI | Copy `AGENTS.md` to the project root, or register the MCP server and select `codex-cli` fanout workers. |\n| Cursor | Copy `.cursorrules` to the project root. |\n| Windsurf | Copy `AGENTS.md` to the project root. |\n| VS Code Copilot | Copy `AGENTS.md` to the project root. |\n| Claude Desktop | Register the MCP server via `mcp-server/mcp-config.example.json`. |\n| Manus | Import `dist/mythify.skill` (see quick start C). |\n| Any CLI agent | Use `scripts/mythify.py` directly, paired with any protocol variant. |\n| Custom MCP clients | Connect to `mcp-server/src/index.js` over stdio. |\n\nFor step-by-step Claude Desktop and Claude Code setup, including running Mythify\non smaller models like Haiku, see\n[docs/claude-integrations.md](docs/claude-integrations.md).\n\n## Local comparison harness\n\n`scripts/local_model_eval.py` runs a local before/after comparison with no API\nkeys. It creates two temporary workspaces for each selected Python bug-fix\ntask:\n\n- `bare`: the model gets only the task prompt.\n- `mythify`: the model gets `AGENTS.md`, `scripts/mythify.py`,\n  `protocol/operation-registry.json`, `protocol/classification-rules.json`, and\n  an initialized `.mythify/` workspace, then is told to use the selected\n  Mythify profile and record `verify run` evidence.\n\nThe harness verifies both workspaces with `python3 -m unittest` and reports\npass rate, Mythify evidence rate, average duration, and per-run output tails.\nIt also emits evidence blocks that answer the core comparisons directly from\nexit codes: `verified_task_success` for verifier pass-rate delta, and\n`false_completion_claims` for completion signals contradicted by failing\nverifiers. `profile_overhead` reports measured Mythify profile duration\noverhead from local subprocess wall-clock timings. `local_model_benefit`\nreports scenario categories that fit local reader and triage roles, plus the\nobserved harness outcomes for those categories. `fanout_value` reports where\nfanout is policy-fit versus waste-prone, pairing the built-in scenarios with\nverifier-backed single-worker sufficiency signals. `role_strength` reports\nwhich roles require, allow, or reject stronger models under Mythify policy. The\nfalse-completion signal is bounded to model process exit code 0; output text is\nretained for audit but not tone-scored.\nThe default `--mythify-profile auto` uses the fast profile for the built-in\nfocused bugfix scenarios. Use `--mythify-profile standard` when you want the\nolder plan-plus-verify benchmark behavior.\n\nRun it with an existing local subscription login:\n\n```bash\npython3 scripts/local_model_eval.py --engine codex-cli --model gpt-5 --require-pass\npython3 scripts/local_model_eval.py --engine claude-cli --model haiku --require-pass\npython3 scripts/local_model_eval.py --engine cursor-agent --model gpt-5 --require-pass\npython3 scripts/local_model_eval.py --engine codex-cli --mythify-profile standard --require-pass\n```\n\nRun the built-in mini benchmark set:\n\n```bash\npython3 scripts/local_model_eval.py --engine codex-cli --scenario all --json-output .mythify/local-codex-benchmark.json\n```\n\nCompare Codex speed modes:\n\n```bash\npython3 scripts/local_model_eval.py --engine codex-cli --scenario all --speed fast --json-output .mythify/local-codex-fast-mode-benchmark.json\npython3 scripts/local_model_eval.py --engine codex-cli --scenario all --speed standard --json-output .mythify/local-codex-standard-mode-benchmark.json\n```\n\nIn fast profile runs, Mythify evidence means at least one executed verification\nrecord. In standard profile runs, evidence requires both a plan record and an\nexecuted verification.\n\nList the built-in scenarios:\n\n```bash\npython3 scripts/local_model_eval.py --list-scenarios\n```\n\nFor deterministic offline testing, set `MYTHIFY_LOCAL_EVAL_COMMAND` and use\nthe `command` engine. The unit test in `tests/test_local_model_eval.py` does\nexactly that, so CI never needs real model accounts.\n\nFor Codex Desktop and Codex CLI setup, see\n[docs/codex-integrations.md](docs/codex-integrations.md).\n\nFor one Mythify MCP server across Codex Desktop, Claude Desktop, and Cursor\nDesktop, see [docs/desktop-tool-calls.md](docs/desktop-tool-calls.md). Example\nclient configs live in [mcp-server/client-configs](mcp-server/client-configs).\n\n## Development\n\nRun the Python test suite (stdlib unittest, no dependencies):\n\n```bash\npython3 -m unittest discover -s tests -v\n```\n\nRun the MCP server smoke test:\n\n```bash\ncd mcp-server \u0026\u0026 npm ci \u0026\u0026 npm test\n```\n\n`tests/test_interop.py` exercises the CLI and the MCP server against the same\nstate directory across host-model state, memory, lessons, plans and steps,\noutcomes, verification records, and reflections. It skips automatically when\n`node` is not on PATH or `mcp-server/node_modules` is missing.\n\nWhole-state no-mutation tests snapshot every file under `.mythify` before and\nafter representative refusal paths, proving guarded failures do not create,\ndelete, or rewrite unrelated state.\n\nOperation registry tests compare the memory CLI and MCP behavior with\n`protocol/operation-registry.json` so duplicated operation contracts cannot\nquietly drift.\n\nClassification keyword rules live in `protocol/classification-rules.json` so\nthe CLI and MCP server share deterministic task-type matching data without\nduplicating the table.\n\nThe MCP npm package also carries package-local runtime manifest mirrors under\n`mcp-server/protocol/`; run\n`node scripts/check_classification_rules_manifest.mjs` and\n`node scripts/check_surface_manifest.mjs` to check that they match the root\nmanifests before release.\n\n`protocol/surface-manifest.json` owns duplicated public surface metadata such\nas top-level CLI commands and MCP tool names. Run\n`node scripts/check_surface_manifest.mjs` to compare the manifest with runtime\nregistrations, public docs, and CLI help output.\n\n`docs/adapter-candidates.md` is generated from\n`mcp-server/src/capability-registry.js` by `node scripts/build_registry_docs.mjs`.\nThe Node suite and CI hygiene job compare the committed file with fresh\nregistry output, so adapter docs cannot quietly drift from the registry.\nEvery generated row includes the stable adapter interface version, locality,\nprobe and run support, execution boundary, state-write posture, evidence\nstatus, roles, and guardrails.\nSome candidates are metadata-only: Kimi Work and OpenCode Desktop are tracked\nas `desktop_agent` entries, but Mythify does not run or automate them until a\ndocumented or locally probeable automation contract exists.\n\n## Limitations\n\n- No npm registry package yet. The supported install path is a local checkout\n  with `scripts/install_user.sh`, plus GitHub release assets for the skill and\n  MCP package. MCP clients still use a local absolute path; there are no `npx`\n  instructions because no package is published to npm.\n- No large benchmark eval has been run yet. The `verified_task_success`,\n  `false_completion_claims`, `profile_overhead`, `local_model_benefit`, and\n  `fanout_value` report blocks, plus the `role_strength` policy report, are\n  rerunnable smoke signals for the Mythify effect, not statistically\n  meaningful evidence by themselves.\n- Protocol adherence varies by model strength. Weaker models follow the discipline\n  less reliably, and the gains shrink accordingly.\n\n## Contributing\n\nContributions are welcome. Read [CONTRIBUTING.md](CONTRIBUTING.md) for the\ndevelopment workflow, [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for community\nexpectations, and [SECURITY.md](SECURITY.md) for how to report vulnerabilities. Two\nrepository rules are non-negotiable:\n\n1. [docs/design.md](docs/design.md) is the contract for all CLI, MCP, and on-disk\n   interfaces. Behavior changes start there.\n2. Generated files are never edited by hand. Edit `protocol/PROTOCOL.md` and\n   regenerate protocol variants with `scripts/build_variants.py`; edit\n   `mcp-server/src/capability-registry.js` and regenerate\n   `docs/adapter-candidates.md` with `node scripts/build_registry_docs.mjs`.\n\n## License\n\nMIT. See [LICENSE](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faihxp%2Fmythify","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faihxp%2Fmythify","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faihxp%2Fmythify/lists"}