[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C87CC1JHSVPZ2EVACDPAB":3,"skill-same:01M71C87CC1JHSVPZ2EVACDPAB":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M71C87CC1JHSVPZ2EVACDPAB","mure-role-variant-matrix",null,"MURE role × model variant matrix. One role, several tuned variants. Seeded from audit; MLP re-ranks. Cheap auto, heavy surfaced.","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fmure-role-variant-matrix\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"mure role variant matrix","matrix","variant","role","model","re","variants","auto","workflow","audit","harness","one","2026-11-10 10:12:30",false,"---\nname: \"mure-role-variant-matrix\"\ndescription: \"MURE role × model variant matrix. One role, several tuned variants. Seeded from audit; MLP re-ranks. Cheap auto, heavy surfaced.\"\nscope: harness\ninvocation: workflow\n---\n\n# MURE Role × Model Variant Matrix\n\n## Purpose\n\nOne MURE role, several model variants — each variant tuned to a specific model's profile (tools \u002F thinking \u002F max_tokens \u002F system sections) without changing the role's core function. Lets the orchestrator pick the right model for the right job while staying inside the role's contract.\n\n## Schema\n\nThe authoritative source is `.openclaw\u002Fmure-agent-catalog.json` — every role entry and its `variants:` list lives there. `.openclaw\u002Fagents\u002F` is a catalog-generated projection for OpenClaw-native config consumption. Repo-local `.omp\u002Fagents\u002F` is a deterministic generated projection for OMP discovery, never hand-edited. Each variant:\n\n```yaml\nvariants:\n  - id: \"\u003Crole>-sonnet5\"\n    model: anthropic\u002Fclaude-sonnet-5\n    thinkingLevel: medium\n    tools: [read, grep, glob, edit, write, bash]\n    max_tokens: 16384\n    systemSections: [\"coding-excellence\", \"agentic-clean-tool-use\"]\n    eligibilityFlags: [\"default-prime\"]\n    costTier: medium\n\n  - id: \"\u003Crole>-opus48\"\n    model: anthropic\u002Fclaude-opus-4-8\n    thinkingLevel: high\n    tools: [read, grep, glob, edit, write, bash]\n    max_tokens: 32768\n    systemSections: [\"apex-judgment\", \"narrow-prompt-reserved\"]\n    eligibilityFlags: [\"heavy\", \"require-explicit-call\"]\n    costTier: heavy\n\n  - id: \"\u003Crole>-haiku\"\n    model: anthropic\u002Fclaude-haiku-4-5\n    thinkingLevel: low\n    tools: [read, grep, glob]\n    max_tokens: 4096\n    systemSections: [\"minimalist\"]\n    eligibilityFlags: [\"cheap\", \"auto-eligible\", \"recon-eligible\", \"cheap-research-only\"]\n    costTier: cheap\n```\n\nThe role's top-level `model:`, `thinkingLevel:`, `tools:` fields remain for backwards compatibility and act as the role baseline; `variants[]` overrides take precedence when populated.\n\n### Backwards compatibility\n\nIf `variants` is absent, MURE falls back to the legacy single-binding (`model:` + `thinkingLevel:` + `tools:`). Existing single-model roles keep working without modification.\n\n### Variant frontmatter (schema preservation)\n\nA variant's ID, model binding, thinking level, tools, and token budget are core control fields — these appear in variant frontmatter (`id`, `model`, `thinkingLevel`, `tools`, `max_tokens`, `systemSections`, `eligibilityFlags`, `costTier`, `quota`). The role's top-level `description` is preserved across all variants; it captures the role's invariant mission and appears inherited in each variant. The explanatory tuning note — why this variant exists, what model behavior it optimizes for, how it differs from the base role — lives in body documentation, not in frontmatter. Never rewrite a role's description to document a single variant's tuning; that belongs in the body and the variant's field choices.\n\n## Per-variant fields (full set)\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `id` | string | yes | unique within the role; `\u003Crole>-\u003Cmodel-shortname>` convention |\n| `model` | string | yes | exact provider\u002Fmodel string |\n| `thinkingLevel` | enum | yes | `off` \u002F `low` \u002F `medium` \u002F `high` \u002F `xhigh` (model-specific meaning). `max` is not an OpenClaw value. |\n| `tools` | string[] | yes | subset of the role's allowed tools |\n| `max_tokens` | int | yes | maximum output tokens for this variant |\n| `systemSections` | string[] | yes | which role-body sections apply to this variant |\n| `eligibilityFlags` | string[] | no | `cheap`, `default-prime`, `medium`, `heavy`, `require-explicit-call`, `security-only`, `auto-eligible`, `recon-eligible`, `cheap-research-only`, etc. |\n| `costTier` | enum | yes | `cheap` \u002F `medium` \u002F `heavy` \u002F `apex` — used by selector |\n| `quota` | enum | no | subscription-quota binding (e.g. `claude-pro-x5`, `z-ai-coding-plan`, `minimax-ultra`, `direct-deepseek-capped`) |\n\n`reasoningDefault` is **not** a second effort field in OpenClaw. It controls\nreasoning visibility (`on` \u002F `off` \u002F `stream`); effort belongs in\n`thinkingLevel` and projects to `agents.list[].thinkingDefault`.\n\n## Projections\n\n### OpenClaw native\n\nThe catalog is the role × variant authority; OpenClaw supplies execution primitives:\n\n- `agents.list[]` projects stable role identities and their baseline model\u002Ffallbacks.\n- `sessions_spawn({agentId, model, thinking})` selects a configured role and an\n  explicit variant model for one run.\n- `subagents.allowAgents` controls which configured role identities can be targeted.\n- Each target `agentId` resolves auth from its own `agentDir`; static API-key\u002Ftoken\n  profiles may be seeded, but OAuth refresh credentials must not be copied between\n  role stores. OpenAI OAuth model overrides run under the authenticated\n  Yuri agent scope unless that target role has completed its own OAuth login.\n- **OpenClaw-specific:** nested `variants[]` are routing metadata, not automatically\n  separate native agents. Do not multiply OpenClaw dashboard agents merely to\n  represent every model binding. OpenClaw is one projection surface, not the only\n  runtime.\n\n### OMP projection\n\nOMP projects each variant to an explicit agent card. `.omp\u002Fagents\u002F` is generated\ndeterministically from the catalog — every catalog variant produces a projected\nOMP agent card for discovery. This is the opposite of the OpenClaw model: OMP\nvariants ARE separate agent cards because OMP's dispatch model requires\none-card-per-binding. Being projected is not the same as being executable;\nonly `canary-proven` cards with passing latest canary are dispatch-eligible (see Provider route eligibility\nbelow). Never edit `.omp\u002Fagents\u002F` by hand; regenerate from the catalog on seed.\n\nMURE task\u002Fsession-level sparse expert routing remains catalog-driven. It does\n**not** turn any runtime into a token-level neural MoE. Candidate scoring, policy\ngates, quota features, calibration, and the MLP remain MURE logic; the runtime\nperforms the selected dispatch and lifecycle management.\n## Provider route eligibility\n\nThe MURE agent catalog is the sole authority for role-variant bindings.\nCatalog presence alone is insufficient for dispatch eligibility. Every variant's\nmodel binding must satisfy both conditions:\n\n1. **Admission history**: Resolvable to a `canary-proven` entry in\n   `_SYSTEM\u002Fconfig\u002Fprovider-route-registry.json`.\n2. **Live gate**: The variant's latest canary must have passed; no later failed canary\n   exists. A failed canary (quota exhaustion, provider drift, API change) blocks that\n   route immediately until re-canary succeeds.\n\nAcceptable evidence is exactly one of:\n- Exact source-route match (e.g. `zai\u002Fglm-5.2`) in the registry with `canary-proven`\n  status and passing latest canary.\n- Normalized selector match (provider-scoped shorthand like `minimax-code` →\n  `minimax-code\u002FMiniMax-M3`) backed by `canary-proven` registry evidence and passing\n  latest canary.\n\nMissing admission history OR latest canary failure → route fails closed.\n\nRoutes with `blocked-schema`, `unresolved`, or `owner-excluded` status are known\ndisqualifications — they fail closed regardless of catalog or model-list appearance.\n\n### Discoverability vs. executability\n\nAll catalog cards are projected — every variant and role binding appears in generated\n`.omp\u002Fagents\u002F` for discovery. But being projected is not the same as being executable.\nUnproven, blocked, and excluded cards are listed in the generated project config's\n`task.disabledAgents` and must never inherit the parent or default model binding.\nOnly cards meeting Provider route eligibility criteria (canary-proven admission history and passing latest canary) are dispatch-eligible.\n\n### Card-level stale-session backstop\n\n`task.disabledAgents` is the primary steady-state gate after session startup.\n`disabled\u002Fmure-route-unavailable` is the card-level stale-session backstop\nthat blocks parent\u002Fdefault model inheritance. Project-config changes require a\nfresh OMP session — there is no hot reload; do not rely on settings-layer\nenforcement until the session has restarted.\n\nThe MLP and fallback chain skip ineligible variants automatically.\n\n## Provider status and pilot rollout\n\n**Sol (`openai\u002Fgpt-5.6-sol`)** is catalogued but currently unproven — no successful exact OMP canary exists. It was Yuri's experimental variant and carried `sol-pilot` flag; later hardening tasks targeted different routes. Sol remains blocked until a fresh canary succeeds and meets dispatch eligibility criteria.\n\n**Terra (`openai\u002Fgpt-5.6-terra`)** is a normalization example only. Currently quota-blocked after provider drift; routes configured for Terra dispatch will fail closed. Terra re-proves only when liveness is confirmed by passing canary.\n\n**Fallback defaults** are seeded from routes with `canary-proven` admission history, subject to dispatch eligibility criteria (see Provider route eligibility), depending on role and cost tier. No role is currently promoted to Sol or Terra dispatch until their latest canaries pass.\n\n## Cost tier semantics (binding)\n\nEach `costTier` maps to an explicit placement rule:\n\n- **`cheap`** — eligible for auto-selection on cheap sub-tasks. Fallback chain advance lands here first. Examples: `haiku`, `deepseek-v4-flash`, `glm-5-turbo`, `m2.7-highspeed`.\n- **`medium`** — eligible for auto-prime or surfaced-default depending on role. Examples: `sonnet-5`, `glm-5.1`, `m2.7`.\n- **`heavy`** — surfaced-default with operator override. Examples: `opus-4-8`, `dvp-pro-think-max`, `glm-5.2`, `m3`.\n- **`apex`** — `require-explicit-call` only; not auto-prime. Examples: `fable-5` (when accessible).\n\n### Haiku's lane (clarification, 2026-07-09)\n\nPer owner: **Haiku's role is recon + cheap-research only.** Eligible contexts for Haiku variants:\n- `mure-scout` (research \u002F census)\n- `mure-envoy` (ops \u002F brain-dump decode)\n- `mure-chronicler` cheap-tier (technical writing where fine-tuning not needed)\n- `mure-advisor` watcher Tier 1 fallback\n\nNOT eligible for heavy-advisor fallback. NOT eligible for sentinel \u002F adjudicator \u002F architect. The heavy-tier fallback chain for any role is role-dependent but **never falls through to Haiku**.\n\n## System sections (harness diff)\n\nThe role body's section names are indexed and referencable per-variant. Convention (composable, reusable):\n- `minimalist` — bare essentials; for cheap \u002F fast models\n- `coding-excellence` — code-quality emphasis (type hints, tests, edge cases)\n- `agentic-clean-tool-use` — strict tool-call discipline (no spurious calls, return clean JSON)\n- `apex-judgment` — adversarial-ally contract, weight caveats, refutation default\n- `narrow-prompt-reserved` — short context, narrow scope; used by heavy-tiers when scope is bounded\n- `security-strict` — protected-path emphasis, no exceptions; used by sentinel \u002F adjudicator\n- `vision-cross-modal` — instructions for image \u002F video understanding\n- `recon-breadth` — read-heavy, scan-friendly; used by cheap recon roles\n- `cheap-research` — minimal-but-complete; used by cheap research-tier\n- `orchestrator-peer` — full fleet doctrine + dispatch rules + 6-gate charter; used by helmsman \u002F architect \u002F helmsman-glm\n- `governance-strict` — protected paths + autonomy-class + finalize-never; used by owner-gated lanes\n\nA variant's `systemSections` chooses which named sections apply. The role body must explicitly mark each section heading so a tool can extract + concat.\n\n## Seeding (must be deterministic cold-start)\n\nVariants MUST seed from the model-audit relevance cells:\n\n- **★ = PRIMARY** — eligible for auto-selection as the default-prime variant.\n- **● = SECONDARY** — eligible for surfaced-default with manual override; not auto-prime.\n- **— = DO NOT INCLUDE** — model is unfit for the role; do not add as a variant.\n- **? = UNVERIFIED** — verification needed before inclusion.\n\nThe MLP cannot introduce NEW variants. Its job is to **re-rank within the seeded set** using prediction-ledger features.\n\nThis prevents the MLP from cold-pruning out a great model the owner invested quota in.\n\n## Selection (cheap auto + heavy surfaced)\n\n### Cheap variants (costTier: cheap \u002F medium)\n\nAUTO. The dispatcher picks the cheapest reachable variant matching the role + task shape, with predicted-success from the MLP. Operator-visible via the GUI afterwards + override-next-round via slash command (`\u002Fuse sonnet-5 next`).\n\n### Heavy variants (costTier: heavy \u002F apex)\n\nSurfaced-default + operator override. The dispatcher proposes a default (ranked #1 by MLP score); the operator sees the choice in the GUI + can override next round. Per-dispatch prompts are NOT used (would wear thin over a long session).\n\n### Security rule (hard)\n\nFor security-relevant turns (sentinel, adjudicator, parts of architect), the variant picked MUST be Opus 4.8 (or equivalent apex-tier if Opus is gated). The dispatcher enforces; deepseek-v4-pro may be added when audit confirms capability parity.\n\n## Harness diff (binding rule)\n\nA variant's diff from the role baseline MAY include:\n- `model` (binding)\n- `thinkingLevel`\n- `tools` (subset)\n- `max_tokens`\n- `systemSections` (which sections apply)\n- `quota` (which subscription)\n\nA variant MUST NOT change:\n- Role `mission` \u002F `description` \u002F `capabilities`\n- Role `autonomy` class (`self-governable` \u002F `owner-gated`)\n- Role `independence` set (structural independence between roles)\n- The RESULT_LABEL grammar at turn-end\n\nIf a role's function needs to change, that's a NEW role — not a variant.\n\n## Telemetry (feeds back into MLP)\n\nPer-dispatch logs to `_SYSTEM\u002Fstate\u002Frole-variant-ledger.jsonl`:\n- role ID\n- variant ID picked\n- selection mechanism (auto \u002F surfaced-default \u002F override)\n- tokens in \u002F out (precise, for cost accounting)\n- success criterion outcome (success \u002F partial \u002F fail, from role's RESULT_LABEL)\n- time-to-first-token (latency)\n- escalation count if heavy advisor was triggered\n\nFeeds:\n- `mure-calibrator` for Brier scoring\n- Role-variant MLP for re-ranking within the seeded set\n- Operator dashboard for cost \u002F latency dashboards\n\n## Fallback chain\n\nPer role, an ordered fallback chain: cheapest eligible variant first; on quota \u002F failure, advance. MLP learns the chain ordering over time.\n\nStatic defaults at first, MLP-updated post-warmup (role-dependent but never includes Haiku at heavy tier):\n1. costTier cheap variants (auto-prime if eligible)\n2. medium costTier (auto-prime)\n3. heavy costTier (surface default)\n4. apex costTier (explicit-call only)\n\nHaiku placement reminder: cheap tier (recon + cheap-research lanes only). At heavy tier, the chain is role-defined but never includes Haiku.\n\n## Operator command surface\n\n- `mure.mjs --list` — every role + every variant + current ranking + last 24h outcome histogram.\n- `mure.mjs --variants \u003Crole>` — role + variants + current ranking + per-tier cost.\n- `mure.mjs --pick \u003Crole> \u003Cvariant>` — next-round override for the role.\n- `mure.mjs --seed-from-audit` — re-seed the variants[] from current `_SYSTEM\u002Fresearch\u002Fmodel-audit*.md` cells (manual \u002F scheduled).\n- GUI equivalent for visibility + intervention.\n\n## Anti-patterns\n\n- A variant that CHANGES the role's mission (that's a new role).\n- The MLP pruning outside its seeded set (cold-prune of expensive-but-critical).\n- Operator getting prompted per heavy-dispatch (chatter burns focus).\n- Variants without telemetry (silent untested variants rot the routing).\n- Variants missing `max_tokens` (silently expensive \u002F short on long outputs).\n- Haiku appearing in a heavy-tier role's fallback chain.\n- Adding a variant from an audit `—` cell without a verification pass.\n\n## Related\n\n- Source audit: `_SYSTEM\u002Fresearch\u002Fmodel-audit-2026-07-09.md` (★\u002F● cells are seed source).\n- Rene recon: `_SYSTEM\u002Fresearch\u002Frene-branch-patterns-2026-07-09.md` (compose-with-MURE-YAML recommendation).\n- mure-advisor (the tiered per-turn advisor consumes role×variant telemetry + emits watchdog notes).\n- Cloud fleet roster: `_SYSTEM\u002Fconfig\u002Fcloud-fleet-models.json` (provider mapping; needs an update pass).\n- Substrate dispatch: `_SYSTEM\u002FScripts\u002F{glm,ollama}-fleet.mjs` + Opus fleet substrate.\n\n## Versioned authority\n\nv1.0.0 — created 2026-07-09. Revision incorporated: Haiku lane clarification. Pending Skill Workshop approval.\n\n## Change log\n\n- 2026-07-09 — initial draft per grill round + Opus 4.8 adversarial review (HV03).\n- 2026-07-09 (rev 1) — clarified Haiku's lane (recon + cheap-research only, never heavy-tier fallback); added `recon-eligible`, `cheap-research-only`, `orchestrator-peer`, `governance-strict` to the systemSections vocabulary.\n","# MURE Role × Model Variant Matrix\n\n## Purpose\n\nOne MURE role, several model variants — each variant tuned to a specific model's profile (tools \u002F thinking \u002F max_tokens \u002F system sections) without changing the role's core function. Lets the orchestrator pick the right model for the right job while staying inside the role's contract.\n\n## Schema\n\nThe authoritative source is `.openclaw\u002Fmure-agent-catalog.json` — every role entry and its `variants:` list lives there. `.openclaw\u002Fagents\u002F` is a catalog-generated projection for OpenClaw-native config consumption. Repo-local `.omp\u002Fagents\u002F` is a deterministic generated projection for OMP discovery, never hand-edited. Each variant:\n\n```yaml\nvariants:\n  - id: \"\u003Crole>-sonnet5\"\n    model: anthropic\u002Fclaude-sonnet-5\n    thinkingLevel: medium\n    tools: [read, grep, glob, edit, write, bash]\n    max_tokens: 16384\n    systemSections: [\"coding-excellence\", \"agentic-clean-tool-use\"]\n    eligibilityFlags: [\"default-prime\"]\n    costTier: medium\n\n  - id: \"\u003Crole>-opus48\"\n    model: anthropic\u002Fclaude-opus-4-8\n    thinkingLevel: high\n    tools: [read, grep, glob, edit, write, bash]\n    max_tokens: 32768\n    systemSections: [\"apex-judgment\", \"narrow-prompt-reserved\"]\n    eligibilityFlags: [\"heavy\", \"require-explicit-call\"]\n    costTier: heavy\n\n  - id: \"\u003Crole>-haiku\"\n    model: anthropic\u002Fclaude-haiku-4-5\n    thinkingLevel: low\n    tools: [read, grep, glob]\n    max_tokens: 4096\n    systemSections: [\"minimalist\"]\n    eligibilityFlags: [\"cheap\", \"auto-eligible\", \"recon-eligible\", \"cheap-research-only\"]\n    costTier: cheap\n```\n\nThe role's top-level `model:`, `thinkingLevel:`, `tools:` fields remain for backwards compatibility and act as the role baseline; `variants[]` overrides take precedence when populated.\n\n### Backwards compatibility\n\nIf `variants` is absent, MURE falls back to the legacy single-binding (`model:` + `thinkingLevel:` + `tools:`). Existing single-model roles keep working without modification.\n\n### Variant frontmatter (schema preservation)\n\nA variant's ID, model binding, thinking level, tools, and token budget are core control fields — these appear in variant frontmatter (`id`, `model`, `thinkingLevel`, `tools`, `max_tokens`, `systemSections`, `eligibilityFlags`, `costTier`, `quota`). The role's top-level `description` is preserved across all variants; it captures the role's invariant mission and appears inherited in each variant. The explanatory tuning note — why this variant exists, what model behavior it optimizes for, how it differs from the base role — lives in body documentation, not in frontmatter. Never rewrite a role's description to document a single variant's tuning; that belongs in the body and the variant's field choices.\n\n## Per-variant fields (full set)\n\n| Field | Type | Required | Notes |\n|---|---|---|---|\n| `id` | string | yes | unique within the role; `\u003Crole>-\u003Cmodel-shortname>` convention |\n| `model` | string | yes | exact provider\u002Fmodel string |\n| `thinkingLevel` | enum | yes | `off` \u002F `low` \u002F `medium` \u002F `high` \u002F `xhigh` (model-specific meaning). `max` is not an OpenClaw value. |\n| `tools` | string[] | yes | subset of the role's allowed tools |\n| `max_tokens` | int | yes | maximum output tokens for this variant |\n| `systemSections` | string[] | yes | which role-body sections apply to this variant |\n| `eligibilityFlags` | string[] | no | `cheap`, `default-prime`, `medium`, `heavy`, `require-explicit-call`, `security-only`, `auto-eligible`, `recon-eligible`, `cheap-research-only`, etc. |\n| `costTier` | enum | yes | `cheap` \u002F `medium` \u002F `heavy` \u002F `apex` — used by selector |\n| `quota` | enum | no | subscription-quota binding (e.g. `claude-pro-x5`, `z-ai-coding-plan`, `minimax-ultra`, `direct-deepseek-capped`) |\n\n`reasoningDefault` is **not** a second effort field in OpenClaw. It controls\nreasoning visibility (`on` \u002F `off` \u002F `stream`); effort belongs in\n`thinkingLevel` and projects to `agents.list[].thinkingDefault`.\n\n## Projections\n\n### OpenClaw native\n\nThe catalog is the role × variant authority; OpenClaw supplies execution primitives:\n\n- `agents.list[]` projects stable role identities and their baseline model\u002Ffallbacks.\n- `sessions_spawn({agentId, model, thinking})` selects a configured role and an\n  explicit variant model for one run.\n- `subagents.allowAgents` controls which configured role identities can be targeted.\n- Each target `agentId` resolves auth from its own `agentDir`; static API-key\u002Ftoken\n  profiles may be seeded, but OAuth refresh credentials must not be copied between\n  role stores. OpenAI OAuth model overrides run under the authenticated\n  Yuri agent scope unless that target role has completed its own OAuth login.\n- **OpenClaw-specific:** nested `variants[]` are routing metadata, not automatically\n  separate native agents. Do not multiply OpenClaw dashboard agents merely to\n  represent every model binding. OpenClaw is one projection surface, not the only\n  runtime.\n\n### OMP projection\n\nOMP projects each variant to an explicit agent card. `.omp\u002Fagents\u002F` is generated\ndeterministically from the catalog — every catalog variant produces a projected\nOMP agent card for discovery. This is the opposite of the OpenClaw model: OMP\nvariants ARE separate agent cards because OMP's dispatch model requires\none-card-per-binding. Being projected is not the same as being executable;\nonly `canary-proven` cards with passing latest canary are dispatch-eligible (see Provider route eligibility\nbelow). Never edit `.omp\u002Fagents\u002F` by hand; regenerate from the catalog on seed.\n\nMURE task\u002Fsession-level sparse expert routing remains catalog-driven. It does\n**not** turn any runtime into a token-level neural MoE. Candidate scoring, policy\ngates, quota features, calibration, and the MLP remain MURE logic; the runtime\nperforms the selected dispatch and lifecycle management.\n## Provider route eligibility\n\nThe MURE agent catalog is the sole authority for role-variant bindings.\nCatalog presence alone is insufficient for dispatch eligibility. Every variant's\nmodel binding must satisfy both conditions:\n\n1. **Admission history**: Resolvable to a `canary-proven` entry in\n   `_SYSTEM\u002Fconfig\u002Fprovider-route-registry.json`.\n2. **Live gate**: The variant's latest canary must have passed; no later failed canary\n   exists. A failed canary (quota exhaustion, provider drift, API change) blocks that\n   route immediately until re-canary succeeds.\n\nAcceptable evidence is exactly one of:\n- Exact source-route match (e.g. `zai\u002Fglm-5.2`) in the registry with `canary-proven`\n  status and passing latest canary.\n- Normalized selector match (provider-scoped shorthand like `minimax-code` →\n  `minimax-code\u002FMiniMax-M3`) backed by `canary-proven` registry evidence and passing\n  latest canary.\n\nMissing admission history OR latest canary failure → route fails closed.\n\nRoutes with `blocked-schema`, `unresolved`, or `owner-excluded` status are known\ndisqualifications — they fail closed regardless of catalog or model-list appearance.\n\n### Discoverability vs. executability\n\nAll catalog cards are projected — every variant and role binding appears in generated\n`.omp\u002Fagents\u002F` for discovery. But being projected is not the same as being executable.\nUnproven, blocked, and excluded cards are listed in the generated project config's\n`task.disabledAgents` and must never inherit the parent or default model binding.\nOnly cards meeting Provider route eligibility criteria (canary-proven admission history and passing latest canary) are dispatch-eligible.\n\n### Card-level stale-session backstop\n\n`task.disabledAgents` is the primary steady-state gate after session startup.\n`disabled\u002Fmure-route-unavailable` is the card-level stale-session backstop\nthat blocks parent\u002Fdefault model inheritance. Project-config changes require a\nfresh OMP session — there is no hot reload; do not rely on settings-layer\nenforcement until the session has restarted.\n\nThe MLP and fallback chain skip ineligible variants automatically.\n\n## Provider status and pilot rollout\n\n**Sol (`openai\u002Fgpt-5.6-sol`)** is catalogued but currently unproven — no successful exact OMP canary exists. It was Yuri's experimental variant and carried `sol-pilot` flag; later hardening tasks targeted different routes. Sol remains blocked until a fresh canary succeeds and meets dispatch eligibility criteria.\n\n**Terra (`openai\u002Fgpt-5.6-terra`)** is a normalization example only. Currently quota-blocked after provider drift; routes configured for Terra dispatch will fail closed. Terra re-proves only when liveness is confirmed by passing canary.\n\n**Fallback defaults** are seeded from routes with `canary-proven` admission history, subject to dispatch eligibility criteria (see Provider route eligibility), depending on role and cost tier. No role is currently promoted to Sol or Terra dispatch until their latest canaries pass.\n\n## Cost tier semantics (binding)\n\nEach `costTier` maps to an explicit placement rule:\n\n- **`cheap`** — eligible for auto-selection on cheap sub-tasks. Fallback chain advance lands here first. Examples: `haiku`, `deepseek-v4-flash`, `glm-5-turbo`, `m2.7-highspeed`.\n- **`medium`** — eligible for auto-prime or surfaced-default depending on role. Examples: `sonnet-5`, `glm-5.1`, `m2.7`.\n- **`heavy`** — surfaced-default with operator override. Examples: `opus-4-8`, `dvp-pro-think-max`, `glm-5.2`, `m3`.\n- **`apex`** — `require-explicit-call` only; not auto-prime. Examples: `fable-5` (when accessible).\n\n### Haiku's lane (clarification, 2026-07-09)\n\nPer owner: **Haiku's role is recon + cheap-research only.** Eligible contexts for Haiku variants:\n- `mure-scout` (research \u002F census)\n- `mure-envoy` (ops \u002F brain-dump decode)\n- `mure-chronicler` cheap-tier (technical writing where fine-tuning not needed)\n- `mure-advisor` watcher Tier 1 fallback\n\nNOT eligible for heavy-advisor fallback. NOT eligible for sentinel \u002F adjudicator \u002F architect. The heavy-tier fallback chain for any role is role-dependent but **never falls through to Haiku**.\n\n## System sections (harness diff)\n\nThe role body's section names are indexed and referencable per-variant. Convention (composable, reusable):\n- `minimalist` — bare essentials; for cheap \u002F fast models\n- `coding-excellence` — code-quality emphasis (type hints, tests, edge cases)\n- `agentic-clean-tool-use` — strict tool-call discipline (no spurious calls, return clean JSON)\n- `apex-judgment` — adversarial-ally contract, weight caveats, refutation default\n- `narrow-prompt-reserved` — short context, narrow scope; used by heavy-tiers when scope is bounded\n- `security-strict` — protected-path emphasis, no exceptions; used by sentinel \u002F adjudicator\n- `vision-cross-modal` — instructions for image \u002F video understanding\n- `recon-breadth` — read-heavy, scan-friendly; used by cheap recon roles\n- `cheap-research` — minimal-but-complete; used by cheap research-tier\n- `orchestrator-peer` — full fleet doctrine + dispatch rules + 6-gate charter; used by helmsman \u002F architect \u002F helmsman-glm\n- `governance-strict` — protected paths + autonomy-class + finalize-never; used by owner-gated lanes\n\nA variant's `systemSections` chooses which named sections apply. The role body must explicitly mark each section heading so a tool can extract + concat.\n\n## Seeding (must be deterministic cold-start)\n\nVariants MUST seed from the model-audit relevance cells:\n\n- **★ = PRIMARY** — eligible for auto-selection as the default-prime variant.\n- **● = SECONDARY** — eligible for surfaced-default with manual override; not auto-prime.\n- **— = DO NOT INCLUDE** — model is unfit for the role; do not add as a variant.\n- **? = UNVERIFIED** — verification needed before inclusion.\n\nThe MLP cannot introduce NEW variants. Its job is to **re-rank within the seeded set** using prediction-ledger features.\n\nThis prevents the MLP from cold-pruning out a great model the owner invested quota in.\n\n## Selection (cheap auto + heavy surfaced)\n\n### Cheap variants (costTier: cheap \u002F medium)\n\nAUTO. The dispatcher picks the cheapest reachable variant matching the role + task shape, with predicted-success from the MLP. Operator-visible via the GUI afterwards + override-next-round via slash command (`\u002Fuse sonnet-5 next`).\n\n### Heavy variants (costTier: heavy \u002F apex)\n\nSurfaced-default + operator override. The dispatcher proposes a default (ranked #1 by MLP score); the operator sees the choice in the GUI + can override next round. Per-dispatch prompts are NOT used (would wear thin over a long session).\n\n### Security rule (hard)\n\nFor security-relevant turns (sentinel, adjudicator, parts of architect), the variant picked MUST be Opus 4.8 (or equivalent apex-tier if Opus is gated). The dispatcher enforces; deepseek-v4-pro may be added when audit confirms capability parity.\n\n## Harness diff (binding rule)\n\nA variant's diff from the role baseline MAY include:\n- `model` (binding)\n- `thinkingLevel`\n- `tools` (subset)\n- `max_tokens`\n- `systemSections` (which sections apply)\n- `quota` (which subscription)\n\nA variant MUST NOT change:\n- Role `mission` \u002F `description` \u002F `capabilities`\n- Role `autonomy` class (`self-governable` \u002F `owner-gated`)\n- Role `independence` set (structural independence between roles)\n- The RESULT_LABEL grammar at turn-end\n\nIf a role's function needs to change, that's a NEW role — not a variant.\n\n## Telemetry (feeds back into MLP)\n\nPer-dispatch logs to `_SYSTEM\u002Fstate\u002Frole-variant-ledger.jsonl`:\n- role ID\n- variant ID picked\n- selection mechanism (auto \u002F surfaced-default \u002F override)\n- tokens in \u002F out (precise, for cost accounting)\n- success criterion outcome (success \u002F partial \u002F fail, from role's RESULT_LABEL)\n- time-to-first-token (latency)\n- escalation count if heavy advisor was triggered\n\nFeeds:\n- `mure-calibrator` for Brier scoring\n- Role-variant MLP for re-ranking within the seeded set\n- Operator dashboard for cost \u002F latency dashboards\n\n## Fallback chain\n\nPer role, an ordered fallback chain: cheapest eligible variant first; on quota \u002F failure, advance. MLP learns the chain ordering over time.\n\nStatic defaults at first, MLP-updated post-warmup (role-dependent but never includes Haiku at heavy tier):\n1. costTier cheap variants (auto-prime if eligible)\n2. medium costTier (auto-prime)\n3. heavy costTier (surface default)\n4. apex costTier (explicit-call only)\n\nHaiku placement reminder: cheap tier (recon + cheap-research lanes only). At heavy tier, the chain is role-defined but never includes Haiku.\n\n## Operator command surface\n\n- `mure.mjs --list` — every role + every variant + current ranking + last 24h outcome histogram.\n- `mure.mjs --variants \u003Crole>` — role + variants + current ranking + per-tier cost.\n- `mure.mjs --pick \u003Crole> \u003Cvariant>` — next-round override for the role.\n- `mure.mjs --seed-from-audit` — re-seed the variants[] from current `_SYSTEM\u002Fresearch\u002Fmodel-audit*.md` cells (manual \u002F scheduled).\n- GUI equivalent for visibility + intervention.\n\n## Anti-patterns\n\n- A variant that CHANGES the role's mission (that's a new role).\n- The MLP pruning outside its seeded set (cold-prune of expensive-but-critical).\n- Operator getting prompted per heavy-dispatch (chatter burns focus).\n- Variants without telemetry (silent untested variants rot the routing).\n- Variants missing `max_tokens` (silently expensive \u002F short on long outputs).\n- Haiku appearing in a heavy-tier role's fallback chain.\n- Adding a variant from an audit `—` cell without a verification pass.\n\n## Related\n\n- Source audit: `_SYSTEM\u002Fresearch\u002Fmodel-audit-2026-07-09.md` (★\u002F● cells are seed source).\n- Rene recon: `_SYSTEM\u002Fresearch\u002Frene-branch-patterns-2026-07-09.md` (compose-with-MURE-YAML recommendation).\n- mure-advisor (the tiered per-turn advisor consumes role×variant telemetry + emits watchdog notes).\n- Cloud fleet roster: `_SYSTEM\u002Fconfig\u002Fcloud-fleet-models.json` (provider mapping; needs an update pass).\n- Substrate dispatch: `_SYSTEM\u002FScripts\u002F{glm,ollama}-fleet.mjs` + Opus fleet substrate.\n\n## Versioned authority\n\nv1.0.0 — created 2026-07-09. Revision incorporated: Haiku lane clarification. Pending Skill Workshop approval.\n\n## Change log\n\n- 2026-07-09 — initial draft per grill round + Opus 4.8 adversarial review (HV03).\n- 2026-07-09 (rev 1) — clarified Haiku's lane (recon + cheap-research only, never heavy-tier fallback); added `recon-eligible`, `cheap-research-only`, `orchestrator-peer`, `governance-strict` to the systemSections vocabulary.\n",{"name":5,"scope":29,"invocation":27,"description":7},"main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794","skills\u002Fmure-role-variant-matrix",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-10-27 02:18:29",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill mure-role-variant-matrix",{"tool":50,"command":51},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill mure-role-variant-matrix",{"tool":53,"command":54},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill mure-role-variant-matrix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fmure-role-variant-matrix\u002FSKILL.md",true,[],[59,80,103,133,162,181],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":31},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[66,67,68,29,69,70,24,71,72,73,74,75,76,77,78,79],"zoom out","zoom","with","how","section","true","understand","use","perspective","when","you","code","it","context",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":31},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[87,88,29,89,90,91,92,93,94,95,96,73,97,75,27,98,99,100,101,102],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","decisions","architecture","review","perspectives","adversarial",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":114,"publishedAt":31},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[109],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[115,116,117,118,119,120,121,122,123,75,124,125,126,127,128,129,130,91,131,132],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":147,"publishedAt":31},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[139,142],{"categoryNo":140,"categoryName":141,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[148,77,149,115,29,150,151,152,91,153,154,155,156,157,158,159,160,161,73,75],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":31},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[169,170,171,172,173,174,175,176,177,75,178,27,179,180],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":199,"publishedAt":31},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[187,190,193,196],{"categoryNo":188,"categoryName":189,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":191,"categoryName":192,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":194,"categoryName":195,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":197,"categoryName":198,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000036","内容创作者",[200,201,202,75,27,203,29,204,92,73,205],"writing","writing skills","new","work","editing","Existing"]