feat: capability first routing, judgment authorship, failure kind telemetry (0.0.40)

.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
     "email": "hi@okis.dev"
   },
   "description": "Multi-model orchestration marketplace for Claude Code.",
-  "version": "0.0.39",
+  "version": "0.0.40",
   "plugins": [
     {
       "name": "grok",
       "source": "./plugins/grok",
       "displayName": "Grok Companion",
       "description": "Local Grok CLI delegation: task, review, resumable history, best-of-n tournaments, background jobs, stats, and setup health checks.",
-      "version": "0.0.39",
+      "version": "0.0.40",
       "author": {
         "name": "Harry Yep"
       },
@@ -34,7 +34,7 @@
       "source": "./plugins/codex",
       "displayName": "Codex Companion",
       "description": "First party local Codex CLI delegation for tasks, reviews, resumable threads, and durable background jobs.",
-      "version": "0.0.39",
+      "version": "0.0.40",
       "author": {
         "name": "Harry Yep"
       },
@@ -55,7 +55,7 @@
       "source": "./plugins/fusion",
       "displayName": "Fusion Orchestrator",
       "description": "Multi-model orchestration: tier agents, routing rules, blind panel, ultra fleet, model config, and drift doctor.",
-      "version": "0.0.39",
+      "version": "0.0.40",
       "author": {
         "name": "Harry Yep"
       },

CHANGELOG.md

@@ -1,5 +1,13 @@
 # changelog
 
+## 0.0.40
+
+- routing becomes capability first: a package routes by its load bearing capability instead of its surface task type, capability monopolies hard route ahead of every task type default (X and live platform reads to grok `live-web` even when digest shaped, Claude tool surface and privacy to Claude workers, judgment dense authorship to the main session), and lane defaults are named as cached capability observations that fresh observations override per package; grounded in a same day controlled probe where grok `web_fetch` returned a full x.com post body while the codex web surface returned empty HTML for the same URL
+- the orchestration policy gains a judgment dense authorship section: a deliverable whose faithful brief would have to contain the deliverable itself (public naming, API shape, UX copy, rules text, a design's first exemplar) is authored in the main session as control plane work, the judgment density to volume ratio decides the split, design intent travels to peers as contract (exemplar files, MUST NOT gates, signatures, snapshots) rather than prose aspiration, and lane acceptance rates are never evidence of taste; the interactive design carve out generalizes to this rule, codex briefs gain a lean and gate shaped requirement (the vendor system card documents intent overreach through permissive instruction reading, worse under persistence emphasis), the grok design gate now points at the authorship rule instead of a taste score threshold no code reads, and readme, contributing, and troubleshooting restate the new invariants
+- judgment shaped rejections become measurable: `/fusion:stats --record` accepts `--failure-kind` and per pair `--failure-kind-for` (raw args transport, rejected pairs only, one of `intent_override`, `scope_rewrite`, `wrong_approach`, `style_mismatch`), the engine acceptance bridge forwards the kind to both companions, `record-acceptance` on both engines validates it and now requires `--reason` for every rejected verdict (previously optional at the engine layer, which left 41 of 63 ledger rejections reasonless), worker records persist `acceptanceFailureKind` through queued verdicts, and the brief envelope accepts `package-type: design`
+- the bench suite gains T09-style-fidelity, the first task measuring adherence to an externally imposed style contract as distinct from output quality under a model's own defaults: six machine checkable gates that deliberately conflict with model default habits (snake_case exports, promise chains with async and await forbidden, no classes, errors only through `app_error`, zero comments, named exports only), a style checker independent of the hidden behavior tests, and a mutant that passes every behavior test while violating only the contract, so the verifier isolates style fidelity; methodology and readme drop the stale single task claims and the capability table rows stop citing the nonexistent "bench B2" for taste
+- `docs/grok-contract.md` documents X content access: x.com reads work today through consult `web_fetch` and are treated as a grok lane monopoly in routing, while the first party `x_search` backend tool rides the agent profile surface rather than the `--tools` allowlist and stays unwired until upstream documents headless enablement
+
 ## 0.0.39
 
 - the over budget stop gate settles instead of looping when the harness has already reaped a worker's runtime task: a `cancel_requested` record whose runtime id is absent from a provided `background_tasks` array settles as `task_reaped` through the same `settleReapedWorker` helper the no task found escape hatch uses, because that hatch never fires for this class; `TaskStop` on a reaped id returns a tool_use_error, which emits neither PostToolUse nor PostToolUseFailure, so the demand was unsatisfiable (observed live: two user interrupted workers held eight consecutive blocking stop rounds while twelve errored `TaskStop` and `TaskOutput` calls delivered zero hook events, and only SessionEnd closed the records)

CONTRIBUTING.md

@@ -13,6 +13,7 @@ Any change to `plugins/fusion/rules/orchestration.md` or `plugins/fusion/rules/t
    - The main Claude session is the only control plane and final judge. It owns ambiguity resolution, decomposition, integration, semantic acceptance, and user communication, while work packages execute in delegated lanes.
    - Codex owns ordinary implementation by default. Grok remains implementation capable only through its four protected roles (`burst`, `independence`, `live-web`, `large-context`) or an explicit user choice; it is not a generic alternative merely because it is idle.
    - Codex admission order is the current workspace, an isolated worktree for an independent eligible package, then Grok under `burst`, then the matching Claude fallback. Packages with overlapping files, shared generated state, or ordering dependencies are consolidated or sequenced instead of parallel overflow.
+   - Routing stays capability first: capability monopolies (X and live platform reads on Grok `live-web`, Claude tool surface and privacy on Claude workers, judgment dense authorship in the main session) hard route ahead of every task type default, and the judgment dense authorship rule keeps policy text, public naming, API shape, and UX copy authored in the main session with only the mechanical spread dispatched.
    - Claude worker and Grok dispatches are background Agents. Codex is the foreground Agent exception: its rescue Agent and companion Bash call stay foreground regardless of complexity or expected duration unless the incoming user request already contains `--background`.
    - A Codex package that cannot fit the foreground cap is split or routed elsewhere. Complexity and duration never silently detach it.
    - Independent packages fan out in a single message rather than being queued one at a time. Dependence is never removed by switching engines.

README.md

@@ -4,13 +4,15 @@ Multi-model orchestration for Claude Code. Your chosen Claude session model is t
 
 | Layer | Who | Job |
 |---|---|---|
-| Orchestrator | the user's chosen main session model; `best[1m]` is recommended but never set by the plugin | sole control plane: resolve ambiguity, decompose, integrate, verify, record semantic acceptance, make the final judgment, and communicate with the user; it does not execute work packages |
+| Orchestrator | the user's chosen main session model; `best[1m]` is recommended but never set by the plugin | sole control plane: resolve ambiguity, decompose, integrate, verify, record semantic acceptance, make the final judgment, and communicate with the user; it does not execute work packages; it authors judgment dense cores (naming, API shape, UX copy, policy text) itself under the authorship rule and dispatches their mechanical spread |
 | Claude workers | `fusion:deep-reasoner` (Fable), `fusion:fast-worker` (Sonnet), `fusion:trivial-worker` (Haiku) | native specialists rather than external diversity: read only high stakes advice, resolved work needing Claude Code tools or the Claude privacy boundary, and exact tiny fallback packages when no eligible peer lane fits |
 | Peer engines | Companion plugins implementing the shared contract. Current instances are the hosted Codex and Grok plugins in this marketplace | Codex is the primary implementation lane and default deep external reviewer. Grok is a complementary specialist and burst lane with four protected roles: `burst`, `independence`, `live-web`, and `large-context`. It remains implementation capable inside those roles, but idle capacity alone does not make it the ordinary default. Each lane runs whatever its own CLI is configured for; model names and scores live in the /fusion:config capability table, refreshed from each CLI's live listing. |
 | Panel mechanism | `/fusion:panel` | sends one blind brief to available peer engines in parallel and gives their attributed evidence to the main Claude session for final adjudication; it is not an independent role or authority |
 
 Codex first admission follows this order: use Codex in the current workspace, then an isolated Codex worktree for an independent eligible package, then Grok under `burst` for an independent package inside its safety and turn boundaries, then the matching Claude fallback. Overlapping files, shared generated state, and ordering dependencies are consolidated or sequenced instead of parallelized by changing engines.
 
+Routing is capability first: a package routes by its load bearing capability, not its surface task type. Capability monopolies hard route: X and live platform reads go to Grok `live-web` even for digest shaped work, Claude tool surface and privacy needs go to Claude workers, and judgment dense authorship stays in the main session. Lane defaults are cached capability observations; a fresh observation that disagrees wins for the package at hand.
+
 Direct `/codex:*` and `/grok:*` commands are user selected engine escape hatches. They return the selected engine's transport result directly and do not first pass through Fusion's automatic routing or main session adjudication.
 
 ## Quick start
@@ -59,7 +61,7 @@ Then, in a new session, run `/fusion:setup` once per machine (it writes the rout
 
 Companion text outcomes use the shared footer grammar for `state`, `failure`, `job`, `delivery`, `semantic`, and `<engine>-session` lines defined in [docs/companion-contract.md](docs/companion-contract.md), with delivery and semantic lines present when that adapter exposes those dimensions in text. The Codex runtime contract is [docs/codex-contract.md](docs/codex-contract.md), and the Grok runtime contract is [docs/grok-contract.md](docs/grok-contract.md). Each plugin names its own session line, for example Codex emits `codex-session: <thread-id>` and Grok emits `grok-session: <uuid>`.
 
-Every peer `state: done` and Claude worker `transportStatus: done` is a transport result, not proof that the work is acceptable; the main session verifies the result before relying on it. The orchestrator records Codex acceptance through `/fusion:stats --record-acceptance <job-id> <accepted|rejected> --source main-loop`. Claude workers and Grok jobs collected through Fusion record acceptance through `/fusion:stats --record-worker-acceptance <fusion-task-id> <accepted|rejected> --source main-loop`. Terminal work without that evidence remains `unverified`. A collector timeout, dead job, or status error reports the Fusion task id, peer job id, literal state `uncollected`, and the exact `/codex:result <job-id>` or `/grok:result <job-id>` command. Optional `--reason` text is caller supplied and retained in private local state after limited credential shape redaction, so keep it short and free of sensitive data.
+Every peer `state: done` and Claude worker `transportStatus: done` is a transport result, not proof that the work is acceptable; the main session verifies the result before relying on it. Terminal work without a verified verdict remains `unverified`. A collector timeout, dead job, or status error reports the Fusion task id, peer job id, literal state `uncollected`, and the exact `/codex:result <job-id>` or `/grok:result <job-id>` command. `/fusion:stats --record <id>=<verdict>` settles collected results; a rejected verdict requires `--reason` through the raw args transport, and a judgment shaped rejection may add `--failure-kind` with one of `intent_override`, `scope_rewrite`, `wrong_approach`, or `style_mismatch`.
 
 ## Safety model
 
@@ -87,7 +89,7 @@ Roles bind to alias tiers, not to specific models, so a same tier release (Sonne
 
 The plugin's effectiveness claims are benchmarked, not asserted. The claims and the full protocol live in [bench/METHODOLOGY.md](bench/METHODOLOGY.md): C1 quota displacement (routing bills fewer tokens to the Claude subscription than a vanilla session at equal task success, split into a Claude tiers only arm, a peer offload arm, and an advisor profile arm where the main session runs on Sonnet and consults stronger tiers on demand), C2 wall clock compression on plan shaped tasks versus a protocol enforced sequential baseline, and C3 typed failure surfacing, scoped to the shared companion outcome contract the test suite already covers. The harness ships in [bench/](bench/): a runner that isolates each condition in its own Claude configuration directory and keeps verifiers outside the model visible worktree, a strict JSONL record schema, a summary script that refuses to compare snapshots from different task manifests, a redaction step for published transcripts, and a manifest tool that content hashes every task before any results exist.
 
-No results are published yet. The task suite currently holds one of the planned 8 to 12 tasks, so no snapshot would meet the methodology's own publication gate; the first dated reference snapshot ships once the pool is complete, with raw per run data committed alongside the summary table. Until then the status is plain: the procedure is public and runnable, the numbers do not exist. Readers can run the harness themselves with `node bench/run.mjs --task <id> --condition <A|B1|B2|B3> --repetition <n> --results <dir> --claude-config <dir>` after building condition profiles per [bench/conditions/README.md](bench/conditions/README.md).
+No results are published yet. The task suite currently holds nine tasks (T01 to T09) of the planned 8 to 12. The first dated reference snapshot ships once the pool is complete, with raw per run data committed alongside the summary table. Until then the status is plain: the procedure is public and runnable, the numbers do not exist. Readers can run the harness themselves with `node bench/run.mjs --task <id> --condition <A|B1|B2|B3> --repetition <n> --results <dir> --claude-config <dir>` after building condition profiles per [bench/conditions/README.md](bench/conditions/README.md).
 
 ## Data and uninstall
 

bench/METHODOLOGY.md

@@ -29,7 +29,7 @@ This benchmark does not isolate model coding quality from orchestration quality.
 
 ## Task suite
 
-Tasks live under bench/tasks/T01-slug/ (and similarly numbered directories) with three parts: brief.md, the task statement handed to the session verbatim; verify.sh, a binary pass or fail command whose exit code is the only success criterion, with no human scoring anywhere in the suite; and either a fixtures/ directory local to the task or a pointer to a shared fixture project under bench/fixtures/. The suite grows to 8 to 12 tasks before the first published snapshot and is expected to cover the plugin's routing surface: a multi file implementation task from a written spec, a seeded bug fix, a research question whose answer is machine checkable, a mechanical codemod across many files, at least three plan shaped tasks with three or more independent work packages each, which serve as the C2 probes, and at least one negative control task where the plugin is expected to provide no advantage, a small single file task where delegation is pure overhead; that task's purpose, to check that the harness does not manufacture an advantage where none exists, is stated openly in its brief. The current branch ships the first task only, T01-seeded-bug, with the remaining tasks landing before any snapshot is published.
+Tasks live under bench/tasks/T01-slug/ (and similarly numbered directories) with three parts: brief.md, the task statement handed to the session verbatim; verify.sh, a binary pass or fail command whose exit code is the only success criterion, with no human scoring anywhere in the suite; and either a fixtures/ directory local to the task or a pointer to a shared fixture project under bench/fixtures/. The suite grows to 8 to 12 tasks before the first published snapshot and is expected to cover the plugin's routing surface: a multi file implementation task from a written spec, a seeded bug fix, a research question whose answer is machine checkable, a mechanical codemod across many files, at least three plan shaped tasks with three or more independent work packages each, which serve as the C2 probes, and at least one negative control task where the plugin is expected to provide no advantage, a small single file task where delegation is pure overhead; that task's purpose, to check that the harness does not manufacture an advantage where none exists, is stated openly in its brief; and a style constraint task that imposes an explicit style contract conflicting with model defaults and verifies constraint compliance separately from behavior; its purpose, measuring externally imposed style fidelity as distinct from output quality under a model's own defaults, is stated openly in its brief. The suite currently ships nine tasks, T01 through T09.
 
 Anti gaming controls on the manifest: the full task manifest, task ids together with a deterministic hash list for every file under each task directory, is committed and tagged before the first results run against it. The manifest hash is computed from sorted task ids, sorted relative file paths, and each file's SHA-256 content hash, so changes to fixtures, mutants, solutions, hidden tests, briefs, and verifiers all change the manifest. New tasks enter from a pre registered pool. Any change to a task after results exist against it requires minting a new task id rather than editing the existing one in place. External task contributions via pull request are welcome, and any externally contributed verifier requires review and sign off by a second maintainer before it is trusted to gate a task.