[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BSRFD8R90C3RHBCYCFVHZ":3,"skill-same:01M71BSRFD8R90C3RHBCYCFVHZ":66},{"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},"01M71BSRFD8R90C3RHBCYCFVHZ","mure-native-dispatch-loop",null,"Run the pure-native MURE Sol MoE dispatch loop — plan\u002Fcompile a manifest, admit only allowlisted OMP TaskTool spawns from the parent session, adapt pushed \u003Ctask-result> completions (with transcript evidence), mirror the lifecycle into the shadow ledger, and extract terminal results. No polling, no subprocess\u002FCLI runtime, no fabricated telemetry. Use whenever you are wiring, debugging, or walking through _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs, sol-moe-native-dispatch.mjs, or native-dispatch-shadow.mjs.","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\u002F.claude\u002Fskills\u002Fmure-native-dispatch-loop\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"native","mure native dispatch loop","dispatch","loop","runtime","mirror","evidence","omp","sol","subprocess","terminal","run","result","cli","plan","transcript","wiring","you","debugging","only","2026-11-10 10:12:30",false,"---\nname: mure-native-dispatch-loop\ndescription: \"Run the pure-native MURE Sol MoE dispatch loop — plan\u002Fcompile a manifest, admit only allowlisted OMP TaskTool spawns from the parent session, adapt pushed \u003Ctask-result> completions (with transcript evidence), mirror the lifecycle into the shadow ledger, and extract terminal results. No polling, no subprocess\u002FCLI runtime, no fabricated telemetry. Use whenever you are wiring, debugging, or walking through _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs, sol-moe-native-dispatch.mjs, or native-dispatch-shadow.mjs.\"\n---\n\n# MURE Native Dispatch Loop\n\nPure-native MURE dispatch: a manifest is planned and compiled to whitelist-only OMP `task` payloads by `compileOmpSpawn`, the **parent OMP session** is the only actor that ever invokes the `task` tool, every spawn receipt and pushed completion is validated before it is trusted, and the reducer's lifecycle is mirrored into a shadow ledger for audit. Three pure modules own this — `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` (reducer + compiler), `_SYSTEM\u002Fmure\u002Fnative-dispatch-shadow.mjs` (shadow observer), `_SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs` (the glue the parent session calls, with `_SYSTEM\u002Fmure\u002Fomp-task-adapter.mjs` providing receipt\u002Fresult\u002Ftranscript parsing). None of the three calls the `task` tool, spawns a subprocess, or persists anything — see each file's `@does` header.\n\n## When this fires\n\nWiring a new caller onto `sol-moe-parent-adapter.mjs`; debugging a stuck\u002Fmisrouted OMP dispatch task; reviewing a PR that touches `sol-moe-native-dispatch.mjs`, `native-dispatch-shadow.mjs`, `omp-task-adapter.mjs`, or the parent adapter; explaining the loop to another lane before it dispatches live MURE work.\n\n## Before editing any of the four modules\n\n1. `node _SYSTEM\u002FScripts\u002Fcapability-recall.mjs \"omp task adapter parent adapter\"` — confirm you are extending this loop, not rebuilding it (`.claude\u002Frules\u002Fcapability_first.md`).\n2. `gitnexus_impact` on the symbol you intend to change (owner-warn on HIGH\u002FCRITICAL) — these modules are load-bearing for every live MURE producer\u002Fverifier cycle.\n3. Read the matching `*.test.mjs` next to the file you're touching (`sol-moe-native-dispatch.test.mjs`, `sol-moe-parent-adapter.test.mjs`, `sol-moe-native-boundary.test.mjs`, `omp-task-adapter.test.mjs`) before changing behavior — they encode the invariants below.\n\n## The loop, in order\n\n### 1. Plan \u002F compile\n\n`planSolMoeCompany` (`_SYSTEM\u002Fmure\u002Fsol-moe-company.mjs`) produces a governed manifest: `plan.routes` (one entry per taskId, each carrying `route.classification.riskClass` and verifier requirements) and `plan.queues` (`producers`, `verifiers`, `availabilityFallbacks`, `qualityEscalations`, optional `evidence`, `calibrationAlternatives`).\n\n`createNativeDispatchState(plan, options)` (`sol-moe-native-dispatch.mjs`) turns that manifest into serializable reducer state — one task record per route, `status: 'pending' | 'owner-held' | 'blocked'` to start, plus a `providerCalibration` window seeded from `options.providerHistory`.\n\n`compileOmpSpawn(entry, context)` is the pure compiler from one manifest entry to the **complete, whitelist-only** OMP TaskTool payload `{ i, context, agent, tasks: [{ id, assignment, description, role }] }`. `agent` is top-level and `tasks[]` always contains exactly one dispatched unit. It is called internally by the reducer's `spawn()` step — you never call it standalone in normal flow.\n\n### 2. OMP `task` only from the parent\n\nThe reducer never executes anything. `reduceNativeDispatch(state, event, options)` returns an **action** — `{type: 'omp-task-spawn', taskId, purpose, routeKind, attempt, entryId, args}`, `{type: 'fail-loud', taskId, code, message}`, or `{type: 'none', reason}` — and the parent OMP session is the only caller allowed to act on an `omp-task-spawn` action by actually invoking the OMP `task` tool with `action.args`. `entry.model` is checked against a hardcoded `WORKER_BINDINGS` allowlist (`sol-moe-native-dispatch.mjs`); an unlisted model or a mismatched `agentId` throws before compilation. Sol\u002FYuri (`agentId: 'mure-yuri'` or `model: 'openai\u002Fgpt-5.6-sol'`) is rejected everywhere — the parent control plane can never be compiled as a child worker (`SOL_PARENT_WORKER_FORBIDDEN`).\n\nCall `reduceNativeDispatch(state, null)` to get the next scheduling tick (first pending task, or the next queue entry for an in-flight task). Only branch on `action.type === 'omp-task-spawn'` to actually spawn; `'fail-loud'` and `'none'` are terminal-for-now — do not retry them yourself, the reducer already decided.\n\nEvery compiled unit requires its own TaskTool call, including consecutive units addressed to the same agent. The parent may run independent calls concurrently, but `compileOmpSpawn` never emits a multi-task batch. Nested orchestration follows `.omp\u002Fconfig.yml` `task.maxRecursionDepth: 2`; depth-2 workers are leaves, and this contract defines no `maxChildrenPerAgent` setting.\n\n### 3. Receipt validation \u002F admission\n\nOnce the parent's `task` call returns a receipt, validate it before trusting it anywhere:\n\n```js\nconst receipt = parseOmpSpawnReceipt(rawReceipt); \u002F\u002F throws on malformed receipt\n\u002F\u002F receipt = { jobId, agent }\n```\n\n`parseOmpSpawnReceipt` (in `omp-task-adapter.mjs`) enforces a non-empty `jobId` matching `^[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}$` and a `agent` drawn from the known card-id set (`VALID_AGENT_IDS`). Then admit it into **both** the reducer state and the shadow in lockstep with one call:\n\n```js\nshadow = mirrorOmpSpawnAction(shadow, scheduledAction);\nconst { state, action, shadow: admittedShadow, receipt } = admitOmpSpawn(state, shadow, scheduledAction, rawReceipt);\n```\n\nThe parent must mirror the scheduled action before admission. `admitOmpSpawn` then calls `recordNativeSpawnAccepted` (reducer) and `observeNativeAdmission` (shadow) together — there is no path where one is admitted and the other is not. Admission stores `{ jobId, agent }` against the awaiting task; the resolved model is checked later from the transcript's `model_change` line, not from the receipt. Drift between requested and resolved model fails the task loud (`MODEL_MISMATCH`) at completion time.\n\n### 4. Pushed-completion adaptation (never polled)\n\nOMP pushes a `\u003Ctask-result>` block. The parent never polls. The completion payload carries `{ id, agent, status, duration, output }`; `parseOmpTaskResult` validates the shape and produces the normalized terminal record. Correlation is by `jobId` plus the awaiting task's recorded `agent` and emitted `deterministicOmpTaskId` — never by guessed status. A successful completion additionally requires a transcript under `artifactsDir\u002F\u003CjobId>.jsonl` containing exactly one `session`, exactly one `model_change`, and at least one `thinking_level_change` event; `loadOmpTranscript` enforces the path-confinement guard.\n\n```js\nconst { state, action, event, shadow } = applyOmpCompletion(state, shadow, rawResult, jobId, transcriptJsonl, { evidence, cwd });\n\u002F\u002F or, loading transcript from disk:\nconst applied = applyOmpCompletionFromDisk(state, shadow, rawResult, jobId, artifactsDir, { evidence, cwd });\n```\n\n`applyOmpCompletion` is one pure step: parse the result, translate the completion against the awaiting admission (`translateOmpCompletion` inside the parent adapter — resolves `taskId`\u002F`entryId`\u002F`purpose` from the **one** task whose `awaiting.accepted.jobId` matches the result's `jobId`; a mismatch throws rather than silently rebinding), reduce through `reduceNativeDispatch`, and mirror into the shadow. State and shadow never drift apart.\n\n### 5. Shadow mirroring\n\n`native-dispatch-shadow.mjs` never selects routes, executes `task`, or alters reducer behavior — it is a shadow-only projection into the delegation ledger (`delegation-ledger.mjs`) for audit. `mirrorOmpSpawnAction(shadow, action)` forwards a reducer action into the shadow (tolerates non-`omp-task-spawn` actions without throwing). Every action is also passed through `validateDispatchGovernance` (`dispatch-governance.mjs`); a governance violation is **recorded as a warning observation**, not a block — the shadow is advisory, the reducer's allowlist checks are the real gate.\n\n### 6. Reducer action loop\n\nDrive the loop by re-entering `reduceNativeDispatch` \u002F `applyOmpCompletion` on every pushed event until the task reaches a terminal status. Internally the reducer already chains: producer success with `requiresVerifier(task)` true → spawns the verifier; verifier `reject` → spawns the next `qualityEscalation`; availability failure kind (`AVAILABILITY_FAILURES` set: `availability`, `transport`, `quota`, `rate-limit`, `timeout`, `auth`) → spawns the next `availabilityFallback`; anything else on failure → `fail-loud`. You do not re-implement any of this branching — you just keep feeding pushed events in.\n\n### 7. Verifier handling\n\nA task requires a verifier when `riskClass` is `R2`\u002F`R3`, or the route explicitly sets `classification.requiresVerifier` \u002F `verifier.required`. The verifier prompt (`buildTask` in `sol-moe-native-dispatch.mjs`) forces a strict contract: return exactly one JSON object, `{\"verdict\":\"pass\"}` or `{\"verdict\":\"reject\"}`, no markdown or prose. `reduceVerifierSuccess` rejects anything else as `SEMANTIC_FAILURE`. Independence is enforced at spawn time: a verifier sharing the producer's `agentId` or `model` is rejected (`VERIFIER_NOT_INDEPENDENT`); for `R3`, the verifier must additionally differ in provider family, and cheap-family models (`deepseek`\u002F`mimo`\u002F`ollama`\u002F`cline`\u002F`cursor`) can never be the verifier at all (`CHEAP_VERIFIER_FORBIDDEN`).\n\n### 8. Terminal extraction\n\n```js\nextractTerminalTaskResult(state, taskId)   \u002F\u002F null while in flight; throws on unknown taskId\nextractTerminalTaskResults(state)          \u002F\u002F only tasks currently in a terminal status\n```\n\nTerminal statuses: `passed`, `fail-loud`, `owner-held`, `blocked`. The extracted record carries `producer`, `evidence`, `priorVerifier`, and `failure` (null unless `fail-loud`) — this is what the parent session reports back, never the raw reducer task object.\n\n### Live canary floor\n\nUse an `R2` task for any live canary intended to prove both reducer completion and shadow-ledger acceptance: the shadow ledger accepts a producer only after an independent verifier passes. An `R1` producer can reach reducer `passed`, but it cannot prove a shadow `accepted` lifecycle. Pass proof to producer completion as exact evidence keys, e.g. `{ evidence: { result_label: '\u003Clabel>' } }` for an `evidenceRequirements: ['RESULT_LABEL']` ticket; `checked` is verifier-verdict metadata, not producer evidence.\n\n### No polling, no fake subprocess runtime, real-event-only telemetry\n\n- **No polling.** The only way state advances is a pushed `\u003Ctask-result>` plus its transcript, or an explicit scheduling tick (`reduceNativeDispatch(state, null)`). Never loop on `task` listing \u002F `await` \u002F sleeps to discover completion.\n- **No fake subprocess runtime.** `sol-moe-native-boundary.test.mjs` asserts every `sol-moe-*.mjs` and `omp-task-adapter.mjs` production module contains zero CLI\u002Fsubprocess agent-dispatch path — there is no `child_process`\u002F`exec` fallback anywhere in this loop. The only execution path is the parent's real OMP `task` tool call.\n- **Real-event-only telemetry.** `createProviderCalibrationReport` and `recordAcceptedProviderDispatch` summarize only **accepted OMP child dispatches** that actually happened (post-admission), never planned queue entries — see the `@does` header on `sol-moe-native-dispatch.mjs`. Do not synthesize calibration history from a plan; it must come from real `recordNativeSpawnAccepted` calls.\n\n## Dry fixture walkthrough (no live spawn)\n\nThis mirrors `sol-moe-parent-adapter.test.mjs` exactly — read-only reasoning over the pure functions, nothing dispatched.\n\n```js\nimport { createNativeDispatchState, reduceNativeDispatch, compileOmpSpawn } from '.\u002Fsol-moe-native-dispatch.mjs';\nimport { createNativeDispatchShadow } from '.\u002Fnative-dispatch-shadow.mjs';\nimport {\n  admitOmpSpawn, applyOmpCompletion, applyOmpCompletionFromDisk,\n  extractTerminalTaskResult, mirrorOmpSpawnAction,\n} from '.\u002Fsol-moe-parent-adapter.mjs';\n\n\u002F\u002F 1. plan\u002Fcompile — one R2 task requiring a verifier\nconst plan = {\n  routes: [{ taskId: 'task-a', held: false, route: {\n    selection: 'primary', classification: { riskClass: 'R2', requiresVerifier: true }, verifier: { required: true },\n  } }],\n  queues: {\n    producers: [{ id: 'task-a:producer', taskId: 'task-a', purpose: 'producer', agentId: 'mure-synthesist',\n      model: 'minimax-portal\u002FMiniMax-M3', thinking: 'high', prompt: 'Complete only task-a.' }],\n    verifiers: [{ id: 'task-a:verifier', taskId: 'task-a', purpose: 'verifier', agentId: 'mure-calibrator',\n      model: 'anthropic\u002Fclaude-sonnet-5', thinking: 'high', prompt: 'Complete only task-a.' }],\n    availabilityFallbacks: [], qualityEscalations: [], calibrationAlternatives: [],\n  },\n  blocked: [], providerCalibration: null,\n};\n\nlet state = createNativeDispatchState(plan);\nlet shadow = createNativeDispatchShadow({ id: 'task-a' });\n\n\u002F\u002F 2. schedule → action.type === 'omp-task-spawn', purpose 'producer'\nlet { state: s1, action: a1 } = reduceNativeDispatch(state, null);\nshadow = mirrorOmpSpawnAction(shadow, a1);                       \u002F\u002F 5. shadow mirrors the action\n\u002F\u002F a1.args === compileOmpSpawn(\u003Cproducer entry>, { cwd, attempt, taskId, upstream })\n\u002F\u002F a1.args.agent === 'mure-synthesist'; a1.args.tasks[0].id === \u003CdeterministicOmpTaskId>\n\u002F\u002F >>> parent session calls OMP task(a1.args) here — this walkthrough stops short of that \u003C\u003C\u003C\n\n\u002F\u002F 3. admit the (simulated) OMP receipt\nconst receipt1 = { jobId: 'run-a', agent: 'mure-synthesist' };\nlet { state: s2, shadow: sh2 } = admitOmpSpawn(s1, shadow, a1, receipt1);\n\n\u002F\u002F 4. pushed producer completion → reducer chains straight into the verifier spawn\nconst transcriptJsonl = [\n  JSON.stringify({ type: 'session', sessionId: 's-a' }),\n  JSON.stringify({ type: 'model_change', model: 'minimax-portal\u002FMiniMax-M3' }),\n  JSON.stringify({ type: 'thinking_level_change', level: 'high' }),\n  '',\n].join('\\n');\nconst result1 = { id: a1.args.tasks[0].id, agent: 'mure-synthesist', status: 'completed', duration: 1200, output: '{\"summary\":\"ok\"}' };\nlet producerApplied = applyOmpCompletion(s2, sh2, result1, receipt1.jobId, transcriptJsonl,\n  { evidence: { TERM_COUNT: '4', FILE_COUNT: '1' } });\n\u002F\u002F producerApplied.action.type === 'omp-task-spawn', purpose === 'verifier'\n\n\u002F\u002F 3'. admit the verifier receipt, 4'. push its strict verdict\nconst verifierShadow = mirrorOmpSpawnAction(producerApplied.shadow, producerApplied.action);\nconst receipt2 = { jobId: 'run-v', agent: producerApplied.action.args.agent };\nconst transcriptJsonl2 = [\n  JSON.stringify({ type: 'session', sessionId: 's-v' }),\n  JSON.stringify({ type: 'model_change', model: plan.queues.verifiers[0].model }),\n  JSON.stringify({ type: 'thinking_level_change', level: 'high' }),\n  '',\n].join('\\n');\nlet verifierAdmitted = admitOmpSpawn(producerApplied.state, verifierShadow, producerApplied.action, receipt2);\nconst verdictResult = { id: producerApplied.action.args.tasks[0].id, agent: receipt2.agent, status: 'completed', duration: 800, output: '{\"verdict\":\"pass\"}' };\nlet finalApplied = applyOmpCompletion(verifierAdmitted.state, verifierAdmitted.shadow, verdictResult, receipt2.jobId, transcriptJsonl2);\n\n\u002F\u002F 8. terminal extraction\nfinalApplied.state.tasks['task-a'].status; \u002F\u002F 'passed'\nextractTerminalTaskResult(finalApplied.state, 'task-a'); \u002F\u002F { status: 'passed', producer: {...}, ... }\n```\n\nRun the real version of this walkthrough with `node --test _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.test.mjs` — it is the executable form of the fixture above and requires no live dispatch.\n\n## Anti-patterns (never)\n\n- Calling the OMP `task` tool from anywhere other than the parent OMP session in response to a reducer `omp-task-spawn` action.\n- Hand-writing a `task` payload when `compileOmpSpawn` is available — the compiler is the only allowlisted source of TaskTool arguments.\n- Fabricating or guessing `taskId`\u002F`entryId`\u002F`purpose` for a pushed completion instead of letting `applyOmpCompletion` resolve it from state via `jobId`.\n- Treating a `\u003Ctask-result>` whose `status` is not `completed` as success, or trusting `output` without a transcript whose `model_change.model` matches the requested entry.\n- Polling for completion instead of waiting for the push.\n- Treating a governance warning from the shadow as a hard block, or treating the shadow's ledger as authoritative over the reducer's task status.\n- Seeding `providerCalibration` history from planned queue entries instead of actual accepted admissions.\n- Compiling `mure-yuri` \u002F `openai\u002Fgpt-5.6-sol` as a child worker, or letting a verifier share the producer's `agentId`\u002F`model`.\n- Batching tasks from different named agents into one `task` call — OMP `task` is single-agent per invocation.\n\n## Validation\n\n```bash\nnode --test _SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.test.mjs _SYSTEM\u002Fmure\u002Fnative-dispatch-shadow.test.mjs \\\n  _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.test.mjs _SYSTEM\u002Fmure\u002Fsol-moe-native-boundary.test.mjs \\\n  _SYSTEM\u002Fmure\u002Fomp-task-adapter.test.mjs\n```\n\nAll five suites are pure unit tests over frozen state objects — no live `task` tool, no network, no owner gate required to run them.\n","# MURE Native Dispatch Loop\n\nPure-native MURE dispatch: a manifest is planned and compiled to whitelist-only OMP `task` payloads by `compileOmpSpawn`, the **parent OMP session** is the only actor that ever invokes the `task` tool, every spawn receipt and pushed completion is validated before it is trusted, and the reducer's lifecycle is mirrored into a shadow ledger for audit. Three pure modules own this — `_SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.mjs` (reducer + compiler), `_SYSTEM\u002Fmure\u002Fnative-dispatch-shadow.mjs` (shadow observer), `_SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.mjs` (the glue the parent session calls, with `_SYSTEM\u002Fmure\u002Fomp-task-adapter.mjs` providing receipt\u002Fresult\u002Ftranscript parsing). None of the three calls the `task` tool, spawns a subprocess, or persists anything — see each file's `@does` header.\n\n## When this fires\n\nWiring a new caller onto `sol-moe-parent-adapter.mjs`; debugging a stuck\u002Fmisrouted OMP dispatch task; reviewing a PR that touches `sol-moe-native-dispatch.mjs`, `native-dispatch-shadow.mjs`, `omp-task-adapter.mjs`, or the parent adapter; explaining the loop to another lane before it dispatches live MURE work.\n\n## Before editing any of the four modules\n\n1. `node _SYSTEM\u002FScripts\u002Fcapability-recall.mjs \"omp task adapter parent adapter\"` — confirm you are extending this loop, not rebuilding it (`.claude\u002Frules\u002Fcapability_first.md`).\n2. `gitnexus_impact` on the symbol you intend to change (owner-warn on HIGH\u002FCRITICAL) — these modules are load-bearing for every live MURE producer\u002Fverifier cycle.\n3. Read the matching `*.test.mjs` next to the file you're touching (`sol-moe-native-dispatch.test.mjs`, `sol-moe-parent-adapter.test.mjs`, `sol-moe-native-boundary.test.mjs`, `omp-task-adapter.test.mjs`) before changing behavior — they encode the invariants below.\n\n## The loop, in order\n\n### 1. Plan \u002F compile\n\n`planSolMoeCompany` (`_SYSTEM\u002Fmure\u002Fsol-moe-company.mjs`) produces a governed manifest: `plan.routes` (one entry per taskId, each carrying `route.classification.riskClass` and verifier requirements) and `plan.queues` (`producers`, `verifiers`, `availabilityFallbacks`, `qualityEscalations`, optional `evidence`, `calibrationAlternatives`).\n\n`createNativeDispatchState(plan, options)` (`sol-moe-native-dispatch.mjs`) turns that manifest into serializable reducer state — one task record per route, `status: 'pending' | 'owner-held' | 'blocked'` to start, plus a `providerCalibration` window seeded from `options.providerHistory`.\n\n`compileOmpSpawn(entry, context)` is the pure compiler from one manifest entry to the **complete, whitelist-only** OMP TaskTool payload `{ i, context, agent, tasks: [{ id, assignment, description, role }] }`. `agent` is top-level and `tasks[]` always contains exactly one dispatched unit. It is called internally by the reducer's `spawn()` step — you never call it standalone in normal flow.\n\n### 2. OMP `task` only from the parent\n\nThe reducer never executes anything. `reduceNativeDispatch(state, event, options)` returns an **action** — `{type: 'omp-task-spawn', taskId, purpose, routeKind, attempt, entryId, args}`, `{type: 'fail-loud', taskId, code, message}`, or `{type: 'none', reason}` — and the parent OMP session is the only caller allowed to act on an `omp-task-spawn` action by actually invoking the OMP `task` tool with `action.args`. `entry.model` is checked against a hardcoded `WORKER_BINDINGS` allowlist (`sol-moe-native-dispatch.mjs`); an unlisted model or a mismatched `agentId` throws before compilation. Sol\u002FYuri (`agentId: 'mure-yuri'` or `model: 'openai\u002Fgpt-5.6-sol'`) is rejected everywhere — the parent control plane can never be compiled as a child worker (`SOL_PARENT_WORKER_FORBIDDEN`).\n\nCall `reduceNativeDispatch(state, null)` to get the next scheduling tick (first pending task, or the next queue entry for an in-flight task). Only branch on `action.type === 'omp-task-spawn'` to actually spawn; `'fail-loud'` and `'none'` are terminal-for-now — do not retry them yourself, the reducer already decided.\n\nEvery compiled unit requires its own TaskTool call, including consecutive units addressed to the same agent. The parent may run independent calls concurrently, but `compileOmpSpawn` never emits a multi-task batch. Nested orchestration follows `.omp\u002Fconfig.yml` `task.maxRecursionDepth: 2`; depth-2 workers are leaves, and this contract defines no `maxChildrenPerAgent` setting.\n\n### 3. Receipt validation \u002F admission\n\nOnce the parent's `task` call returns a receipt, validate it before trusting it anywhere:\n\n```js\nconst receipt = parseOmpSpawnReceipt(rawReceipt); \u002F\u002F throws on malformed receipt\n\u002F\u002F receipt = { jobId, agent }\n```\n\n`parseOmpSpawnReceipt` (in `omp-task-adapter.mjs`) enforces a non-empty `jobId` matching `^[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}$` and a `agent` drawn from the known card-id set (`VALID_AGENT_IDS`). Then admit it into **both** the reducer state and the shadow in lockstep with one call:\n\n```js\nshadow = mirrorOmpSpawnAction(shadow, scheduledAction);\nconst { state, action, shadow: admittedShadow, receipt } = admitOmpSpawn(state, shadow, scheduledAction, rawReceipt);\n```\n\nThe parent must mirror the scheduled action before admission. `admitOmpSpawn` then calls `recordNativeSpawnAccepted` (reducer) and `observeNativeAdmission` (shadow) together — there is no path where one is admitted and the other is not. Admission stores `{ jobId, agent }` against the awaiting task; the resolved model is checked later from the transcript's `model_change` line, not from the receipt. Drift between requested and resolved model fails the task loud (`MODEL_MISMATCH`) at completion time.\n\n### 4. Pushed-completion adaptation (never polled)\n\nOMP pushes a `\u003Ctask-result>` block. The parent never polls. The completion payload carries `{ id, agent, status, duration, output }`; `parseOmpTaskResult` validates the shape and produces the normalized terminal record. Correlation is by `jobId` plus the awaiting task's recorded `agent` and emitted `deterministicOmpTaskId` — never by guessed status. A successful completion additionally requires a transcript under `artifactsDir\u002F\u003CjobId>.jsonl` containing exactly one `session`, exactly one `model_change`, and at least one `thinking_level_change` event; `loadOmpTranscript` enforces the path-confinement guard.\n\n```js\nconst { state, action, event, shadow } = applyOmpCompletion(state, shadow, rawResult, jobId, transcriptJsonl, { evidence, cwd });\n\u002F\u002F or, loading transcript from disk:\nconst applied = applyOmpCompletionFromDisk(state, shadow, rawResult, jobId, artifactsDir, { evidence, cwd });\n```\n\n`applyOmpCompletion` is one pure step: parse the result, translate the completion against the awaiting admission (`translateOmpCompletion` inside the parent adapter — resolves `taskId`\u002F`entryId`\u002F`purpose` from the **one** task whose `awaiting.accepted.jobId` matches the result's `jobId`; a mismatch throws rather than silently rebinding), reduce through `reduceNativeDispatch`, and mirror into the shadow. State and shadow never drift apart.\n\n### 5. Shadow mirroring\n\n`native-dispatch-shadow.mjs` never selects routes, executes `task`, or alters reducer behavior — it is a shadow-only projection into the delegation ledger (`delegation-ledger.mjs`) for audit. `mirrorOmpSpawnAction(shadow, action)` forwards a reducer action into the shadow (tolerates non-`omp-task-spawn` actions without throwing). Every action is also passed through `validateDispatchGovernance` (`dispatch-governance.mjs`); a governance violation is **recorded as a warning observation**, not a block — the shadow is advisory, the reducer's allowlist checks are the real gate.\n\n### 6. Reducer action loop\n\nDrive the loop by re-entering `reduceNativeDispatch` \u002F `applyOmpCompletion` on every pushed event until the task reaches a terminal status. Internally the reducer already chains: producer success with `requiresVerifier(task)` true → spawns the verifier; verifier `reject` → spawns the next `qualityEscalation`; availability failure kind (`AVAILABILITY_FAILURES` set: `availability`, `transport`, `quota`, `rate-limit`, `timeout`, `auth`) → spawns the next `availabilityFallback`; anything else on failure → `fail-loud`. You do not re-implement any of this branching — you just keep feeding pushed events in.\n\n### 7. Verifier handling\n\nA task requires a verifier when `riskClass` is `R2`\u002F`R3`, or the route explicitly sets `classification.requiresVerifier` \u002F `verifier.required`. The verifier prompt (`buildTask` in `sol-moe-native-dispatch.mjs`) forces a strict contract: return exactly one JSON object, `{\"verdict\":\"pass\"}` or `{\"verdict\":\"reject\"}`, no markdown or prose. `reduceVerifierSuccess` rejects anything else as `SEMANTIC_FAILURE`. Independence is enforced at spawn time: a verifier sharing the producer's `agentId` or `model` is rejected (`VERIFIER_NOT_INDEPENDENT`); for `R3`, the verifier must additionally differ in provider family, and cheap-family models (`deepseek`\u002F`mimo`\u002F`ollama`\u002F`cline`\u002F`cursor`) can never be the verifier at all (`CHEAP_VERIFIER_FORBIDDEN`).\n\n### 8. Terminal extraction\n\n```js\nextractTerminalTaskResult(state, taskId)   \u002F\u002F null while in flight; throws on unknown taskId\nextractTerminalTaskResults(state)          \u002F\u002F only tasks currently in a terminal status\n```\n\nTerminal statuses: `passed`, `fail-loud`, `owner-held`, `blocked`. The extracted record carries `producer`, `evidence`, `priorVerifier`, and `failure` (null unless `fail-loud`) — this is what the parent session reports back, never the raw reducer task object.\n\n### Live canary floor\n\nUse an `R2` task for any live canary intended to prove both reducer completion and shadow-ledger acceptance: the shadow ledger accepts a producer only after an independent verifier passes. An `R1` producer can reach reducer `passed`, but it cannot prove a shadow `accepted` lifecycle. Pass proof to producer completion as exact evidence keys, e.g. `{ evidence: { result_label: '\u003Clabel>' } }` for an `evidenceRequirements: ['RESULT_LABEL']` ticket; `checked` is verifier-verdict metadata, not producer evidence.\n\n### No polling, no fake subprocess runtime, real-event-only telemetry\n\n- **No polling.** The only way state advances is a pushed `\u003Ctask-result>` plus its transcript, or an explicit scheduling tick (`reduceNativeDispatch(state, null)`). Never loop on `task` listing \u002F `await` \u002F sleeps to discover completion.\n- **No fake subprocess runtime.** `sol-moe-native-boundary.test.mjs` asserts every `sol-moe-*.mjs` and `omp-task-adapter.mjs` production module contains zero CLI\u002Fsubprocess agent-dispatch path — there is no `child_process`\u002F`exec` fallback anywhere in this loop. The only execution path is the parent's real OMP `task` tool call.\n- **Real-event-only telemetry.** `createProviderCalibrationReport` and `recordAcceptedProviderDispatch` summarize only **accepted OMP child dispatches** that actually happened (post-admission), never planned queue entries — see the `@does` header on `sol-moe-native-dispatch.mjs`. Do not synthesize calibration history from a plan; it must come from real `recordNativeSpawnAccepted` calls.\n\n## Dry fixture walkthrough (no live spawn)\n\nThis mirrors `sol-moe-parent-adapter.test.mjs` exactly — read-only reasoning over the pure functions, nothing dispatched.\n\n```js\nimport { createNativeDispatchState, reduceNativeDispatch, compileOmpSpawn } from '.\u002Fsol-moe-native-dispatch.mjs';\nimport { createNativeDispatchShadow } from '.\u002Fnative-dispatch-shadow.mjs';\nimport {\n  admitOmpSpawn, applyOmpCompletion, applyOmpCompletionFromDisk,\n  extractTerminalTaskResult, mirrorOmpSpawnAction,\n} from '.\u002Fsol-moe-parent-adapter.mjs';\n\n\u002F\u002F 1. plan\u002Fcompile — one R2 task requiring a verifier\nconst plan = {\n  routes: [{ taskId: 'task-a', held: false, route: {\n    selection: 'primary', classification: { riskClass: 'R2', requiresVerifier: true }, verifier: { required: true },\n  } }],\n  queues: {\n    producers: [{ id: 'task-a:producer', taskId: 'task-a', purpose: 'producer', agentId: 'mure-synthesist',\n      model: 'minimax-portal\u002FMiniMax-M3', thinking: 'high', prompt: 'Complete only task-a.' }],\n    verifiers: [{ id: 'task-a:verifier', taskId: 'task-a', purpose: 'verifier', agentId: 'mure-calibrator',\n      model: 'anthropic\u002Fclaude-sonnet-5', thinking: 'high', prompt: 'Complete only task-a.' }],\n    availabilityFallbacks: [], qualityEscalations: [], calibrationAlternatives: [],\n  },\n  blocked: [], providerCalibration: null,\n};\n\nlet state = createNativeDispatchState(plan);\nlet shadow = createNativeDispatchShadow({ id: 'task-a' });\n\n\u002F\u002F 2. schedule → action.type === 'omp-task-spawn', purpose 'producer'\nlet { state: s1, action: a1 } = reduceNativeDispatch(state, null);\nshadow = mirrorOmpSpawnAction(shadow, a1);                       \u002F\u002F 5. shadow mirrors the action\n\u002F\u002F a1.args === compileOmpSpawn(\u003Cproducer entry>, { cwd, attempt, taskId, upstream })\n\u002F\u002F a1.args.agent === 'mure-synthesist'; a1.args.tasks[0].id === \u003CdeterministicOmpTaskId>\n\u002F\u002F >>> parent session calls OMP task(a1.args) here — this walkthrough stops short of that \u003C\u003C\u003C\n\n\u002F\u002F 3. admit the (simulated) OMP receipt\nconst receipt1 = { jobId: 'run-a', agent: 'mure-synthesist' };\nlet { state: s2, shadow: sh2 } = admitOmpSpawn(s1, shadow, a1, receipt1);\n\n\u002F\u002F 4. pushed producer completion → reducer chains straight into the verifier spawn\nconst transcriptJsonl = [\n  JSON.stringify({ type: 'session', sessionId: 's-a' }),\n  JSON.stringify({ type: 'model_change', model: 'minimax-portal\u002FMiniMax-M3' }),\n  JSON.stringify({ type: 'thinking_level_change', level: 'high' }),\n  '',\n].join('\\n');\nconst result1 = { id: a1.args.tasks[0].id, agent: 'mure-synthesist', status: 'completed', duration: 1200, output: '{\"summary\":\"ok\"}' };\nlet producerApplied = applyOmpCompletion(s2, sh2, result1, receipt1.jobId, transcriptJsonl,\n  { evidence: { TERM_COUNT: '4', FILE_COUNT: '1' } });\n\u002F\u002F producerApplied.action.type === 'omp-task-spawn', purpose === 'verifier'\n\n\u002F\u002F 3'. admit the verifier receipt, 4'. push its strict verdict\nconst verifierShadow = mirrorOmpSpawnAction(producerApplied.shadow, producerApplied.action);\nconst receipt2 = { jobId: 'run-v', agent: producerApplied.action.args.agent };\nconst transcriptJsonl2 = [\n  JSON.stringify({ type: 'session', sessionId: 's-v' }),\n  JSON.stringify({ type: 'model_change', model: plan.queues.verifiers[0].model }),\n  JSON.stringify({ type: 'thinking_level_change', level: 'high' }),\n  '',\n].join('\\n');\nlet verifierAdmitted = admitOmpSpawn(producerApplied.state, verifierShadow, producerApplied.action, receipt2);\nconst verdictResult = { id: producerApplied.action.args.tasks[0].id, agent: receipt2.agent, status: 'completed', duration: 800, output: '{\"verdict\":\"pass\"}' };\nlet finalApplied = applyOmpCompletion(verifierAdmitted.state, verifierAdmitted.shadow, verdictResult, receipt2.jobId, transcriptJsonl2);\n\n\u002F\u002F 8. terminal extraction\nfinalApplied.state.tasks['task-a'].status; \u002F\u002F 'passed'\nextractTerminalTaskResult(finalApplied.state, 'task-a'); \u002F\u002F { status: 'passed', producer: {...}, ... }\n```\n\nRun the real version of this walkthrough with `node --test _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.test.mjs` — it is the executable form of the fixture above and requires no live dispatch.\n\n## Anti-patterns (never)\n\n- Calling the OMP `task` tool from anywhere other than the parent OMP session in response to a reducer `omp-task-spawn` action.\n- Hand-writing a `task` payload when `compileOmpSpawn` is available — the compiler is the only allowlisted source of TaskTool arguments.\n- Fabricating or guessing `taskId`\u002F`entryId`\u002F`purpose` for a pushed completion instead of letting `applyOmpCompletion` resolve it from state via `jobId`.\n- Treating a `\u003Ctask-result>` whose `status` is not `completed` as success, or trusting `output` without a transcript whose `model_change.model` matches the requested entry.\n- Polling for completion instead of waiting for the push.\n- Treating a governance warning from the shadow as a hard block, or treating the shadow's ledger as authoritative over the reducer's task status.\n- Seeding `providerCalibration` history from planned queue entries instead of actual accepted admissions.\n- Compiling `mure-yuri` \u002F `openai\u002Fgpt-5.6-sol` as a child worker, or letting a verifier share the producer's `agentId`\u002F`model`.\n- Batching tasks from different named agents into one `task` call — OMP `task` is single-agent per invocation.\n\n## Validation\n\n```bash\nnode --test _SYSTEM\u002Fmure\u002Fsol-moe-native-dispatch.test.mjs _SYSTEM\u002Fmure\u002Fnative-dispatch-shadow.test.mjs \\\n  _SYSTEM\u002Fmure\u002Fsol-moe-parent-adapter.test.mjs _SYSTEM\u002Fmure\u002Fsol-moe-native-boundary.test.mjs \\\n  _SYSTEM\u002Fmure\u002Fomp-task-adapter.test.mjs\n```\n\nAll five suites are pure unit tests over frozen state objects — no live `task` tool, no network, no owner gate required to run them.\n",{"name":5,"description":7},"main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794",".claude\u002Fskills\u002Fmure-native-dispatch-loop",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 mure-native-dispatch-loop",{"tool":58,"command":59},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill mure-native-dispatch-loop",{"tool":61,"command":62},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill mure-native-dispatch-loop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmure-native-dispatch-loop\u002FSKILL.md",true,[],[67,89,113,143,172,189],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"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",[],[74,75,76,77,78,79,80,81,82,83,84,85,36,86,87,88],"zoom out","zoom","with","harness","how","section","re","true","understand","use","perspective","when","code","it","context",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"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",[],[96,97,77,98,99,100,101,102,103,104,105,83,106,85,107,108,109,110,111,112],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":124,"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",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[125,126,127,128,129,130,131,132,133,85,134,135,136,137,138,139,140,100,141,142],"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":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":157,"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",[149,152],{"categoryNo":150,"categoryName":151,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[158,86,159,125,77,160,161,162,100,163,164,165,166,167,168,169,170,171,83,85],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"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",[],[179,30,180,181,182,183,184,22,185,85,186,107,187,188],"yuri adw","engineering loop","software factory","software","agentic engineering","factory","invoke","engineering","agentic","user",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":207,"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",[195,198,201,204],{"categoryNo":196,"categoryName":197,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":199,"categoryName":200,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":202,"categoryName":203,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":205,"categoryName":206,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000036","内容创作者",[208,209,210,85,107,211,77,212,101,83,213],"writing","writing skills","new","work","editing","Existing"]