[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C9AQ955ASCBZACPSQ570J":3,"skill-same:01M71C9AQ955ASCBZACPSQ570J":72},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M71C9AQ955ASCBZACPSQ570J","omp-moe-dispatch",null,"Route substantial YURI\u002FMURE work through the OMP TaskTool using allowlisted `compileOmpSpawn` payloads and explicit configured agent IDs with model overrides. Use for multi-step work, parallel research, implementation, architecture, verification, adjudication, or any request where Sol should orchestrate OMP-native workers. Never substitute CLI `task` subprocesses, Codex `spawn_agent`, or a runtime-bypass adapter for this workflow.","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\u002Fomp-moe-dispatch\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"moe","omp moe dispatch","dispatch","omp","with model","with","task","architecture","workflow","workers","use","adapter","payloads","runtime","for","model","ids","never","orchestrate","parallel","2026-11-10 10:12:30",false,"---\nname: omp-moe-dispatch\ndescription: Route substantial YURI\u002FMURE work through the OMP TaskTool using allowlisted `compileOmpSpawn` payloads and explicit configured agent IDs with model overrides. Use for multi-step work, parallel research, implementation, architecture, verification, adjudication, or any request where Sol should orchestrate OMP-native workers. Never substitute CLI `task` subprocesses, Codex `spawn_agent`, or a runtime-bypass adapter for this workflow.\n---\n\n# OMP MoE Dispatch\n\nUse Sol\u002FYuri as the parent control plane. Delegate worker leaves through the OMP `task` tool, dispatching the exact `compileOmpSpawn(...)` arguments produced by `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`.\n\n## Build the route\n\n1. Preserve the user's goal spine in the parent session.\n2. Decompose substantial work into independent subtasks. `compileOmpSpawn` compiles exactly one manifest entry and always emits exactly one `tasks[0]`; every dispatched unit therefore uses a separate TaskTool call, even when consecutive units use the same agent. Independent calls may run concurrently under the parent.\n3. Build the governed manifest with `_SYSTEM\u002Fmure\u002Fsol-moe-company.mjs` and `_SYSTEM\u002Fconfig\u002Fsol-moe-routing-policy.json`.\n4. Compile each ready manifest entry with `compileOmpSpawn(entry, context)` from `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`. The compiled action has no top-level `agent`; the dispatched card lives at `tasks[0].agent` and `tasks[]` contains exactly one dispatched unit. Execute only the returned whitelist-only payload — never hand-write TaskTool arguments.\n5. Apply runtime availability masks before spawning. Treat a provider quota\u002Ftimeout\u002Fauth failure as unavailable for the current run.\n6. Keep hard policy above learned ranking:\n   - R0 may use cheap semantic producers.\n   - R1 uses a frontier producer by default.\n   - R2 requires an independent frontier verifier.\n   - R3 requires Opus 4.8 verification and never uses Opus as its own producer.\n\n## Spawn native children via OMP TaskTool\n\nFor every immediate producer or selected evidence entry the reducer emits a `compileOmpSpawn` payload of the exact shape `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` produces — currently:\n\n```js\n{\n  i: `MURE ${purpose} ${taskId}`,           \u002F\u002F human-readable intent header\n  context: '# Goal\\nExecute one MURE \u003Cpurpose> task.\\n# Constraints\\n...', \u002F\u002F OMP context block\n  tasks: [                                 \u002F\u002F exactly one dispatched unit\n    {\n      task: '\u003Cbuilt task prompt>',         \u002F\u002F full task prompt (string)\n      name: '\u003CdeterministicOmpTaskId>',    \u002F\u002F CamelCase ≤32 chars, emitted as OMP task id\n      agent: '\u003Cmanifest agentId>',         \u002F\u002F card id; TaskTool binds this card\n    },\n  ],\n}\n```\n\nThe compiled action has NO top-level `agent` (the focused test at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.test.mjs` asserts the absence). The dispatched card lives at `tasks[0].agent`. Every `compileOmpSpawn` payload contains one task and produces one TaskTool call. Separate calls are required for all additional units, whether they target the same or different named agents; the parent may still dispatch independent calls concurrently. Never hand-write TaskTool arguments: the legacy shape `{id, assignment, description, role}` is not what `compileOmpSpawn` emits and is rejected by the focused test.\n\nTrack the `{jobId, agent}` receipt returned by the OMP `task` tool. Job\u002Ftranscript correlation is always by `jobId` plus task\u002Fagent\u002Fmodel evidence (`tasks[0].name`, `tasks[0].agent`, transcript `model_change.model`), never by guessed status.\n\nNested orchestration is bounded by `.omp\u002Fconfig.yml` `task.maxRecursionDepth: 2`. At depth 2, workers are leaves and must not spawn further children; OMP has no `maxChildrenPerAgent` setting in this contract.\n\nBefore native admission, replace `shadow` with `mirrorOmpSpawnAction(shadow, action)`, then call `admitOmpSpawn(state, shadow, action, rawReceipt)` from `_SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs` with the reducer's `omp-task-spawn` action and the OMP receipt. `admitOmpSpawn` calls `recordNativeSpawnAccepted` (reducer) and `observeNativeAdmission` (shadow) in lockstep — there is no path where one is admitted and the other is not. The reducer fails the task loud (`MODEL_MISMATCH`) if the resolved model from the transcript `model_change` line does not match the requested model; admission itself only records the requested model. Feed only pushed `\u003Ctask-result>` blocks (plus the path-confined JSONL transcript under `artifactsDir\u002F\u003CjobId>.jsonl`) into `applyOmpCompletion` (or `applyOmpCompletionFromDisk`). The parent OMP session owns execution and I\u002FO — no subprocesses, no Codex `spawn_agent`, no runtime-bypass adapters.\n\nDo not use:\n\nUse case 1 — the OMP CLI \u002F subprocess runtime pretending to be the TaskTool path is forbidden. Use case 2 — Codex `spawn_agent` is forbidden for MURE model\u002Frole dispatch. Use case 3 — a model override without an `agent` whose card id appears in `WORKER_BINDINGS` (`_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`) is forbidden. Use case 4 — hand-written TaskTool arguments when a `compileOmpSpawn` payload is available are forbidden. Use case 5 — any selector that matches `FORBIDDEN_SELECTOR_PREFIXES` (`_SYSTEM\u002Fmure\u002Fomp-model-resolver.mjs`: `openai\u002F`, `minimax-portal\u002F`, `cline-pass\u002F`, `cursor-cli\u002F`, `ollama\u002F`) is forbidden and must never be emitted; `resolveOmpModel` rejects them in the Step 4 forbidden-prefix gate (after the Step 2 registry gate at lines 602–656 and after Step 3 selector normalization). Use case 6 — any registry route whose status is not `canary-proven` (or the narrow `catalog-candidate` + `canary-bootstrap` exception) is forbidden; `blocked-schema`, `quota-blocked`, `unresolved`, `owner-excluded`, and any future unknown status all fail closed at the Step 2 registry gate before the forbidden-prefix gate runs. Use case 7 — legacy surfaces are forbidden: Fable (registry card `fable-synth-bootstrap` is marked `owner-excluded` on 2026-07-17 and must never be admitted as a worker; its registry row is retained only as historical provenance), OpenClaw, `context-router`, and `yuri-control-plane` (no longer present in `provider-route-registry.json`); any reference in user input must be rejected rather than silently routed. Use case 8 — the Cline provider (`cline-pass\u002F*`) is forbidden; it is categorically unavailable in OMP (`FAIL_CLASSES.CLINE_UNAVAILABLE`) with no fallback or substitute. Use case 9 — local Ollama producer bindings are forbidden; they fail closed via the `ollama\u002F` `FORBIDDEN_SELECTOR_PREFIXES` gate, and only `ollama-cloud\u002F*` routes are eligible when canary-proven in the registry.\n\n## Model roles\n\n| Work | Native child |\n|---|---|\n| Parent orchestration and final synthesis | Parent seat is registry-resolved (`provider-route-registry.json:roleTopology.orchestrator`: owner `sol`, `allowedModels: [\"openai\u002Fgpt-5.6-sol\"]`, `mayExecuteWorkerTasks: false`, `maySpawn: true`). The `mure-yuri` card family is parent-only and never compiled as a worker; the `mure-yuri-sol` variant sits at `disabled\u002Fmure-route-unavailable` and is excluded from worker inheritance. The earlier `mure-yuri · anthropic\u002Fclaude-opus-4-8` row is a card-only entry for the parent front-end persona and is not the runtime orchestrator selector — runtime Opus rebind is out of scope without direct owner authorization. |\n| Delegated orchestration and frontier-volume production | `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3` · thinking `adaptive` (registry canary-proven; bootstrap variants tombstoned). The legacy alias `minimax-portal\u002FMiniMax-M3` must never be emitted in user\u002Flane code or in newly written manifests — `normalizeSelector` at `_SYSTEM\u002Fmure\u002Fomp-model-resolver.mjs:378-386` translates it to the canonical `minimax-code\u002FMiniMax-M3`, and the forbidden-prefix gate at line 661 tests the normalized selector, so the legacy alias is accepted only through canonical normalization rather than fail-closed; the canonical selector remains `minimax-code\u002FMiniMax-M3`. |\n| Implementation and refactor | deterministic 85% `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3`; 15% specialist sample \u002F escalation `mure-engineer` · `openai\u002Fgpt-5.6-terra` — currently `quota-blocked` in the registry; route fails closed in `resolveOmpModel` (`FAIL_CLASSES.REGISTRY_BLOCKED`) until a fresh live canary lifts the block |\n| Adjudication and red-team | deterministic 65% `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3`; 35% cross-provider specialist `mure-adjudicator-luna` · `openai-codex\u002Fgpt-5.6-luna` (note: the legacy `mure-adjudicator` card bound to `openai\u002Fgpt-5.6-luna` is a different route; the `mure-adjudicator-luna` card is reserved for the `openai-codex\u002Fgpt-5.6-luna` source selector) |\n| Deterministic R2 gate | `mure-calibrator-sonnet5` · `anthropic\u002Fclaude-sonnet-5` |\n| Security\u002Fgovernance R3 gate | `mure-sentinel` · `anthropic\u002Fclaude-opus-4-8` (R3 requires Opus 4.8 verification; Opus never acts as its own producer) |\n| Mechanical breadth | Four distinct values to keep separate: source input key `deepseek-v4-flash:direct` (no provider prefix); normalized OMP selector `deepseek\u002Fdeepseek-v4-flash`; canary-evidence registry card `deepseek-flash-bootstrap` on the proven route `ollama-cloud\u002Fdeepseek-v4-flash` (evidence-only, never a producer\u002Fverifier\u002Ffallback\u002Fescalation); executable card `deepseek-flash` per `WORKER_BINDINGS` for the `deepseek-v4-flash:direct` source key. The direct `deepseek\u002Fdeepseek-v4-flash` route is `catalog-candidate` and not yet executable; the bootstrap identity is the evidence carrier, not the executable card — call this a documented evidence-ID drift between the canary registry row and the executable binding. |\n| Cheap overflow\u002Fevidence | `mure-artificer` · `opencode-go\u002Fmimo-v2.5`, only after a completed OMP canary; mimo family is in `CHEAP_PROVIDER_FAMILIES` so it may only run R0 evidence, never R1+ semantic work |\n| Long-context architecture | `mure-architect` · `zai\u002Fglm-5.2` (compile binding `WORKER_BINDINGS[\"zai\u002Fglm-5.2\"] = \"mure-architect\"`; the canary-evidence identity `mure-architect-glm52` in the registry is a documented evidence-ID drift — the executable card stays `mure-architect` until WORKER_BINDINGS is updated; selector remains in `AVAILABILITY_MASKED_MODELS` until a fresh OMP child completes) |\n\nWorker allocation excludes the Sol parent seat and is measured first by accepted OMP TaskTool dispatch count; token share is observed separately. While GLM (`zai\u002Fglm-5.2`) is runtime-masked in the compiler (`AVAILABILITY_MASKED_MODELS` in `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`), target a 50-task rolling mix of 40–60% MiniMax, 20–35% Anthropic (including verification), 12–25% DeepSeek, and no more than 12% OpenAI workers. MiMo (`opencode-go\u002Fmimo-v2.5`) is `canary-proven` in the registry and is NOT in `AVAILABILITY_MASKED_MODELS`; the `availabilityDefaults.opencode-go\u002Fmimo-v2.5: true` value in `_SYSTEM\u002Fconfig\u002Fsol-moe-routing-policy.json` is a planning-layer note that `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` does not read as an enforcement gate — `sol-moe-native-dispatch.mjs` does not import or consult that config file, so it is policy guidance, not a dispatch gate. The compiler's `plan.availabilityEvidence` gate at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs:524-527` fires only for models in `AVAILABILITY_MASKED_MODELS` (GLM only), so it is NOT a MiMo availability requirement — MiMo's availability gate is the resolver's `canary-proven` status (already satisfied). MiMo's admission is NOT generally eligible: the compiler also enforces other gates — `WORKER_BINDINGS` membership and entry validation, `CHEAP_PROVIDER_FAMILIES` semantics (`workerSafetyViolation` at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs:529-535`) which forbid verifier purpose (`CHEAP_VERIFIER_FORBIDDEN`) and forbid non-evidence R1+ work for any purpose (`CHEAP_SEMANTIC_WORK_FORBIDDEN`: producer, availability-fallback, and quality-escalation are all blocked at risk ≥ R1, while evidence-purpose bypasses the risk check and is separately policy-governed), plus R3 Anthropic reservation and `R3_OPUS_VERIFIER_REQUIRED`, and the provider-calibration ceiling — so MiMo is compiler-eligible for R0 non-verifier work (R0 producer, R0 availability-fallback, R0 quality-escalation, and evidence-purpose are all permitted; verifier purpose is forbidden). OpenAI worker models are selective specialists and quality escalations, not the volume default. When GLM recovers (live OMP canary), shift 10–20% to Z.ai without weakening the R2\u002FR3 floors. MiMo widening is constrained by the cheap-family semantics above: R0 non-verifier work passes the compiler predicate; only the policy and routing-policy layer may further restrict it, and they are advisory for the compiler.\n\nThe native reducer records every accepted child admission, including evidence, producer, availability fallback, quality escalation, and verifier attempts. Feed its prior `providerCalibration.history` into the next `createNativeDispatchState(..., { providerHistory })` call to preserve the rolling window. When a selected OpenAI worker would exceed the 12% ceiling, the reducer emits an eligible non-OpenAI peer with route kind `calibration-rebalance`; if none remains, it fails loud (`PROVIDER_CALIBRATION_CEILING`). Sol itself is never a worker candidate (`SOL_PARENT_WORKER_FORBIDDEN`).\n\n## Process completions\n\n1. Treat child output as advisory until verified.\n2. On transport, quota, timeout, or auth failure, spawn only the task's next availability fallback.\n3. On producer success for R2\u002FR3, the reducer itself spawns the declared verifier after the producer finishes. The verifier contract is strict: return exactly `{\"verdict\":\"pass\"}` or `{\"verdict\":\"reject\"}`, no markdown or prose.\n4. On verifier rejection, the reducer spawns only the quality-escalation candidate, then re-runs the verifier.\n5. On verifier transport\u002Fauth\u002Ftimeout failure, fail loud (`VERIFIER_EXECUTION_FAILURE`); changing the producer cannot repair a dead verifier.\n6. Fail loud when compliant candidates are exhausted. Never drop to a cheap semantic worker (`PRODUCER_MISSING` \u002F `AVAILABILITY_FALLBACK_EXHAUSTED` \u002F `QUALITY_ESCALATION_EXHAUSTED`).\n7. Keep final acceptance, owner gates, and user-facing synthesis in the Sol parent.\n\n## Current availability override\n\nWhen Marcel or a live failure establishes that GLM 5.2 is unavailable, mask `zai\u002Fglm-5.2` for the run and begin its declared fallback chain at MiniMax M3. Do not probe GLM repeatedly. Remove the mask only after a successful bounded OMP canary or explicit availability evidence.\n\nApply the same fail-closed rule to any child provider whose profile was just seeded but is not visible to the running runtime. Keep it masked until a fresh OMP child completes; admission alone is not sufficient.\n\nA boolean availability override cannot unmask a default-masked model. Supply proof sourced from the OMP transcript for that exact model with `source: 'omp-task-result'`, `status: 'completed-omp-canary'`, `ok: true`, an exact `model_change.model`, plus its `jobId`; otherwise the router keeps it unavailable (`MODEL_AVAILABILITY_UNPROVEN`).\n\n## Evidence contract\n\nRecord for each child: task ID, role, agent ID, requested model, resolved model (`model_change.model` from transcript), `jobId`, route kind, result status, verifier verdict, and whether fallback or escalation was used. Admission (`recordNativeSpawnAccepted` succeeded) is not execution proof; require a `\u003Ctask-result>` completion event from the resolved child model and a transcript whose `model_change.model` matches the requested entry.\n","# OMP MoE Dispatch\n\nUse Sol\u002FYuri as the parent control plane. Delegate worker leaves through the OMP `task` tool, dispatching the exact `compileOmpSpawn(...)` arguments produced by `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`.\n\n## Build the route\n\n1. Preserve the user's goal spine in the parent session.\n2. Decompose substantial work into independent subtasks. `compileOmpSpawn` compiles exactly one manifest entry and always emits exactly one `tasks[0]`; every dispatched unit therefore uses a separate TaskTool call, even when consecutive units use the same agent. Independent calls may run concurrently under the parent.\n3. Build the governed manifest with `_SYSTEM\u002Fmure\u002Fsol-moe-company.mjs` and `_SYSTEM\u002Fconfig\u002Fsol-moe-routing-policy.json`.\n4. Compile each ready manifest entry with `compileOmpSpawn(entry, context)` from `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`. The compiled action has no top-level `agent`; the dispatched card lives at `tasks[0].agent` and `tasks[]` contains exactly one dispatched unit. Execute only the returned whitelist-only payload — never hand-write TaskTool arguments.\n5. Apply runtime availability masks before spawning. Treat a provider quota\u002Ftimeout\u002Fauth failure as unavailable for the current run.\n6. Keep hard policy above learned ranking:\n   - R0 may use cheap semantic producers.\n   - R1 uses a frontier producer by default.\n   - R2 requires an independent frontier verifier.\n   - R3 requires Opus 4.8 verification and never uses Opus as its own producer.\n\n## Spawn native children via OMP TaskTool\n\nFor every immediate producer or selected evidence entry the reducer emits a `compileOmpSpawn` payload of the exact shape `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` produces — currently:\n\n```js\n{\n  i: `MURE ${purpose} ${taskId}`,           \u002F\u002F human-readable intent header\n  context: '# Goal\\nExecute one MURE \u003Cpurpose> task.\\n# Constraints\\n...', \u002F\u002F OMP context block\n  tasks: [                                 \u002F\u002F exactly one dispatched unit\n    {\n      task: '\u003Cbuilt task prompt>',         \u002F\u002F full task prompt (string)\n      name: '\u003CdeterministicOmpTaskId>',    \u002F\u002F CamelCase ≤32 chars, emitted as OMP task id\n      agent: '\u003Cmanifest agentId>',         \u002F\u002F card id; TaskTool binds this card\n    },\n  ],\n}\n```\n\nThe compiled action has NO top-level `agent` (the focused test at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.test.mjs` asserts the absence). The dispatched card lives at `tasks[0].agent`. Every `compileOmpSpawn` payload contains one task and produces one TaskTool call. Separate calls are required for all additional units, whether they target the same or different named agents; the parent may still dispatch independent calls concurrently. Never hand-write TaskTool arguments: the legacy shape `{id, assignment, description, role}` is not what `compileOmpSpawn` emits and is rejected by the focused test.\n\nTrack the `{jobId, agent}` receipt returned by the OMP `task` tool. Job\u002Ftranscript correlation is always by `jobId` plus task\u002Fagent\u002Fmodel evidence (`tasks[0].name`, `tasks[0].agent`, transcript `model_change.model`), never by guessed status.\n\nNested orchestration is bounded by `.omp\u002Fconfig.yml` `task.maxRecursionDepth: 2`. At depth 2, workers are leaves and must not spawn further children; OMP has no `maxChildrenPerAgent` setting in this contract.\n\nBefore native admission, replace `shadow` with `mirrorOmpSpawnAction(shadow, action)`, then call `admitOmpSpawn(state, shadow, action, rawReceipt)` from `_SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs` with the reducer's `omp-task-spawn` action and the OMP receipt. `admitOmpSpawn` calls `recordNativeSpawnAccepted` (reducer) and `observeNativeAdmission` (shadow) in lockstep — there is no path where one is admitted and the other is not. The reducer fails the task loud (`MODEL_MISMATCH`) if the resolved model from the transcript `model_change` line does not match the requested model; admission itself only records the requested model. Feed only pushed `\u003Ctask-result>` blocks (plus the path-confined JSONL transcript under `artifactsDir\u002F\u003CjobId>.jsonl`) into `applyOmpCompletion` (or `applyOmpCompletionFromDisk`). The parent OMP session owns execution and I\u002FO — no subprocesses, no Codex `spawn_agent`, no runtime-bypass adapters.\n\nDo not use:\n\nUse case 1 — the OMP CLI \u002F subprocess runtime pretending to be the TaskTool path is forbidden. Use case 2 — Codex `spawn_agent` is forbidden for MURE model\u002Frole dispatch. Use case 3 — a model override without an `agent` whose card id appears in `WORKER_BINDINGS` (`_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`) is forbidden. Use case 4 — hand-written TaskTool arguments when a `compileOmpSpawn` payload is available are forbidden. Use case 5 — any selector that matches `FORBIDDEN_SELECTOR_PREFIXES` (`_SYSTEM\u002Fmure\u002Fomp-model-resolver.mjs`: `openai\u002F`, `minimax-portal\u002F`, `cline-pass\u002F`, `cursor-cli\u002F`, `ollama\u002F`) is forbidden and must never be emitted; `resolveOmpModel` rejects them in the Step 4 forbidden-prefix gate (after the Step 2 registry gate at lines 602–656 and after Step 3 selector normalization). Use case 6 — any registry route whose status is not `canary-proven` (or the narrow `catalog-candidate` + `canary-bootstrap` exception) is forbidden; `blocked-schema`, `quota-blocked`, `unresolved`, `owner-excluded`, and any future unknown status all fail closed at the Step 2 registry gate before the forbidden-prefix gate runs. Use case 7 — legacy surfaces are forbidden: Fable (registry card `fable-synth-bootstrap` is marked `owner-excluded` on 2026-07-17 and must never be admitted as a worker; its registry row is retained only as historical provenance), OpenClaw, `context-router`, and `yuri-control-plane` (no longer present in `provider-route-registry.json`); any reference in user input must be rejected rather than silently routed. Use case 8 — the Cline provider (`cline-pass\u002F*`) is forbidden; it is categorically unavailable in OMP (`FAIL_CLASSES.CLINE_UNAVAILABLE`) with no fallback or substitute. Use case 9 — local Ollama producer bindings are forbidden; they fail closed via the `ollama\u002F` `FORBIDDEN_SELECTOR_PREFIXES` gate, and only `ollama-cloud\u002F*` routes are eligible when canary-proven in the registry.\n\n## Model roles\n\n| Work | Native child |\n|---|---|\n| Parent orchestration and final synthesis | Parent seat is registry-resolved (`provider-route-registry.json:roleTopology.orchestrator`: owner `sol`, `allowedModels: [\"openai\u002Fgpt-5.6-sol\"]`, `mayExecuteWorkerTasks: false`, `maySpawn: true`). The `mure-yuri` card family is parent-only and never compiled as a worker; the `mure-yuri-sol` variant sits at `disabled\u002Fmure-route-unavailable` and is excluded from worker inheritance. The earlier `mure-yuri · anthropic\u002Fclaude-opus-4-8` row is a card-only entry for the parent front-end persona and is not the runtime orchestrator selector — runtime Opus rebind is out of scope without direct owner authorization. |\n| Delegated orchestration and frontier-volume production | `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3` · thinking `adaptive` (registry canary-proven; bootstrap variants tombstoned). The legacy alias `minimax-portal\u002FMiniMax-M3` must never be emitted in user\u002Flane code or in newly written manifests — `normalizeSelector` at `_SYSTEM\u002Fmure\u002Fomp-model-resolver.mjs:378-386` translates it to the canonical `minimax-code\u002FMiniMax-M3`, and the forbidden-prefix gate at line 661 tests the normalized selector, so the legacy alias is accepted only through canonical normalization rather than fail-closed; the canonical selector remains `minimax-code\u002FMiniMax-M3`. |\n| Implementation and refactor | deterministic 85% `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3`; 15% specialist sample \u002F escalation `mure-engineer` · `openai\u002Fgpt-5.6-terra` — currently `quota-blocked` in the registry; route fails closed in `resolveOmpModel` (`FAIL_CLASSES.REGISTRY_BLOCKED`) until a fresh live canary lifts the block |\n| Adjudication and red-team | deterministic 65% `mure-synthesist-m3` · `minimax-code\u002FMiniMax-M3`; 35% cross-provider specialist `mure-adjudicator-luna` · `openai-codex\u002Fgpt-5.6-luna` (note: the legacy `mure-adjudicator` card bound to `openai\u002Fgpt-5.6-luna` is a different route; the `mure-adjudicator-luna` card is reserved for the `openai-codex\u002Fgpt-5.6-luna` source selector) |\n| Deterministic R2 gate | `mure-calibrator-sonnet5` · `anthropic\u002Fclaude-sonnet-5` |\n| Security\u002Fgovernance R3 gate | `mure-sentinel` · `anthropic\u002Fclaude-opus-4-8` (R3 requires Opus 4.8 verification; Opus never acts as its own producer) |\n| Mechanical breadth | Four distinct values to keep separate: source input key `deepseek-v4-flash:direct` (no provider prefix); normalized OMP selector `deepseek\u002Fdeepseek-v4-flash`; canary-evidence registry card `deepseek-flash-bootstrap` on the proven route `ollama-cloud\u002Fdeepseek-v4-flash` (evidence-only, never a producer\u002Fverifier\u002Ffallback\u002Fescalation); executable card `deepseek-flash` per `WORKER_BINDINGS` for the `deepseek-v4-flash:direct` source key. The direct `deepseek\u002Fdeepseek-v4-flash` route is `catalog-candidate` and not yet executable; the bootstrap identity is the evidence carrier, not the executable card — call this a documented evidence-ID drift between the canary registry row and the executable binding. |\n| Cheap overflow\u002Fevidence | `mure-artificer` · `opencode-go\u002Fmimo-v2.5`, only after a completed OMP canary; mimo family is in `CHEAP_PROVIDER_FAMILIES` so it may only run R0 evidence, never R1+ semantic work |\n| Long-context architecture | `mure-architect` · `zai\u002Fglm-5.2` (compile binding `WORKER_BINDINGS[\"zai\u002Fglm-5.2\"] = \"mure-architect\"`; the canary-evidence identity `mure-architect-glm52` in the registry is a documented evidence-ID drift — the executable card stays `mure-architect` until WORKER_BINDINGS is updated; selector remains in `AVAILABILITY_MASKED_MODELS` until a fresh OMP child completes) |\n\nWorker allocation excludes the Sol parent seat and is measured first by accepted OMP TaskTool dispatch count; token share is observed separately. While GLM (`zai\u002Fglm-5.2`) is runtime-masked in the compiler (`AVAILABILITY_MASKED_MODELS` in `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs`), target a 50-task rolling mix of 40–60% MiniMax, 20–35% Anthropic (including verification), 12–25% DeepSeek, and no more than 12% OpenAI workers. MiMo (`opencode-go\u002Fmimo-v2.5`) is `canary-proven` in the registry and is NOT in `AVAILABILITY_MASKED_MODELS`; the `availabilityDefaults.opencode-go\u002Fmimo-v2.5: true` value in `_SYSTEM\u002Fconfig\u002Fsol-moe-routing-policy.json` is a planning-layer note that `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` does not read as an enforcement gate — `sol-moe-native-dispatch.mjs` does not import or consult that config file, so it is policy guidance, not a dispatch gate. The compiler's `plan.availabilityEvidence` gate at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs:524-527` fires only for models in `AVAILABILITY_MASKED_MODELS` (GLM only), so it is NOT a MiMo availability requirement — MiMo's availability gate is the resolver's `canary-proven` status (already satisfied). MiMo's admission is NOT generally eligible: the compiler also enforces other gates — `WORKER_BINDINGS` membership and entry validation, `CHEAP_PROVIDER_FAMILIES` semantics (`workerSafetyViolation` at `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs:529-535`) which forbid verifier purpose (`CHEAP_VERIFIER_FORBIDDEN`) and forbid non-evidence R1+ work for any purpose (`CHEAP_SEMANTIC_WORK_FORBIDDEN`: producer, availability-fallback, and quality-escalation are all blocked at risk ≥ R1, while evidence-purpose bypasses the risk check and is separately policy-governed), plus R3 Anthropic reservation and `R3_OPUS_VERIFIER_REQUIRED`, and the provider-calibration ceiling — so MiMo is compiler-eligible for R0 non-verifier work (R0 producer, R0 availability-fallback, R0 quality-escalation, and evidence-purpose are all permitted; verifier purpose is forbidden). OpenAI worker models are selective specialists and quality escalations, not the volume default. When GLM recovers (live OMP canary), shift 10–20% to Z.ai without weakening the R2\u002FR3 floors. MiMo widening is constrained by the cheap-family semantics above: R0 non-verifier work passes the compiler predicate; only the policy and routing-policy layer may further restrict it, and they are advisory for the compiler.\n\nThe native reducer records every accepted child admission, including evidence, producer, availability fallback, quality escalation, and verifier attempts. Feed its prior `providerCalibration.history` into the next `createNativeDispatchState(..., { providerHistory })` call to preserve the rolling window. When a selected OpenAI worker would exceed the 12% ceiling, the reducer emits an eligible non-OpenAI peer with route kind `calibration-rebalance`; if none remains, it fails loud (`PROVIDER_CALIBRATION_CEILING`). Sol itself is never a worker candidate (`SOL_PARENT_WORKER_FORBIDDEN`).\n\n## Process completions\n\n1. Treat child output as advisory until verified.\n2. On transport, quota, timeout, or auth failure, spawn only the task's next availability fallback.\n3. On producer success for R2\u002FR3, the reducer itself spawns the declared verifier after the producer finishes. The verifier contract is strict: return exactly `{\"verdict\":\"pass\"}` or `{\"verdict\":\"reject\"}`, no markdown or prose.\n4. On verifier rejection, the reducer spawns only the quality-escalation candidate, then re-runs the verifier.\n5. On verifier transport\u002Fauth\u002Ftimeout failure, fail loud (`VERIFIER_EXECUTION_FAILURE`); changing the producer cannot repair a dead verifier.\n6. Fail loud when compliant candidates are exhausted. Never drop to a cheap semantic worker (`PRODUCER_MISSING` \u002F `AVAILABILITY_FALLBACK_EXHAUSTED` \u002F `QUALITY_ESCALATION_EXHAUSTED`).\n7. Keep final acceptance, owner gates, and user-facing synthesis in the Sol parent.\n\n## Current availability override\n\nWhen Marcel or a live failure establishes that GLM 5.2 is unavailable, mask `zai\u002Fglm-5.2` for the run and begin its declared fallback chain at MiniMax M3. Do not probe GLM repeatedly. Remove the mask only after a successful bounded OMP canary or explicit availability evidence.\n\nApply the same fail-closed rule to any child provider whose profile was just seeded but is not visible to the running runtime. Keep it masked until a fresh OMP child completes; admission alone is not sufficient.\n\nA boolean availability override cannot unmask a default-masked model. Supply proof sourced from the OMP transcript for that exact model with `source: 'omp-task-result'`, `status: 'completed-omp-canary'`, `ok: true`, an exact `model_change.model`, plus its `jobId`; otherwise the router keeps it unavailable (`MODEL_AVAILABILITY_UNPROVEN`).\n\n## Evidence contract\n\nRecord for each child: task ID, role, agent ID, requested model, resolved model (`model_change.model` from transcript), `jobId`, route kind, result status, verifier verdict, and whether fallback or escalation was used. Admission (`recordNativeSpawnAccepted` succeeded) is not execution proof; require a `\u003Ctask-result>` completion event from the resolved child model and a transcript whose `model_change.model` matches the requested entry.\n",{"name":5,"description":7},"main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794","skills\u002Fomp-moe-dispatch",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-11-11 16:42:59",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill omp-moe-dispatch",{"tool":58,"command":59},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill omp-moe-dispatch",{"tool":61,"command":62},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill omp-moe-dispatch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fomp-moe-dispatch\u002FSKILL.md",true,[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"agents\u002Fomp.yaml","REFERENCE","参考文档",218,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fomp-moe-dispatch\u002Fagents\u002Fomp.yaml",[73,94,114,144,173,192],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":39},"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",[],[80,81,24,82,83,84,85,86,87,29,88,89,90,91,92,93],"zoom out","zoom","harness","how","section","re","true","understand","perspective","when","you","code","it","context",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":39},"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",[],[101,38,82,102,103,33,104,105,106,107,108,29,109,89,27,110,26,111,112,113],"yuri shura","architecture review","planning","deployment","vector","strategic review","decision","strategic","ops","decisions","review","perspectives","adversarial",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":125,"publishedAt":39},"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",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[126,127,128,129,130,131,132,133,134,89,135,136,137,138,139,140,141,33,142,143],"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":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":158,"publishedAt":39},"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",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[159,91,160,126,82,161,162,163,33,164,165,166,167,168,169,170,171,172,29,89],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":39},"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",[],[180,181,182,183,184,185,186,187,188,89,189,27,190,191],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":210,"publishedAt":39},"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",[198,201,204,207],{"categoryNo":199,"categoryName":200,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":202,"categoryName":203,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":205,"categoryName":206,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":208,"categoryName":209,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000036","内容创作者",[211,212,213,89,27,214,82,215,104,29,216],"writing","writing skills","new","work","editing","Existing"]