wizz-method 2.27.0 → 2.28.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "2.27.0",
+  "version": "2.28.0",
   "description": "Wizz Method: método de agência orientado por IA em PT-BR",
   "keywords": [
     "agile",

package/src/modules/wizz/_shared/despacho-barato.md

@@ -6,4 +6,4 @@
 # once. Don't copy this text into another toml: reference it via `include`.
 # ---
 
-Mechanical work (scanning, lookup, repetitive diff, an already-specified change): don't run it in the session when it's large (more than 3 files, or a scan across a directory; a tiny mechanical change stays in the session); dispatch wizz-exec-mechanical/wizz-exec-standard subagents, partitioned one per file/module, up to 4 concurrent. The session's model is the boss: on the Standard tier it does common work itself; above Standard (Opus, Fable) it delegates execution below its tier, sending common work to wizz-exec-standard and keeping only work that fits in 1 file and a few lines; it dispatches and decides with the user. Hard work escalates to wizz-exec-strong when the session's own tier isn't enough (same error twice, cause unclear, or architecture/schema/auth/payments/3+ modules); strong never dispatches, it returns ESCALAR to the session, which then dispatches wizz-exec-ultra with strong's findings. Before any dispatch, measure the size, not just the difficulty: more than one layer (database, backend/worker, app/UI, external automation) or ~8 files means one executor per layer, each brief with max_calls at about 2/3 of the tier's turn cap; a cross-layer story never goes whole to one executor, and a partial return gets split, not "continue". Diff review always goes to wizz-exec-review (pinned to the Strong tier, never inherits the session). Tell the user the tier and quantity of each dispatch. Full ladder in `_shared/model-ladder.md` and the rule in `_shared/token-economy.md` of the wizz module.
+Mechanical work (scanning, lookup, repetitive diff, an already-specified change): don't run it in the session when it's large (more than 3 files, or a scan across a directory; a tiny mechanical change stays in the session); dispatch wizz-exec-mechanical/wizz-exec-standard subagents, partitioned one per file/module, up to 4 concurrent. The session's model is the boss: on the Standard tier it does common work itself; above Standard (Opus, Fable) it delegates execution below its tier, sending common work to wizz-exec-standard and keeping only work that fits in 1 file and a few lines; it dispatches and decides with the user. Hard work escalates to wizz-exec-strong when the session's own tier isn't enough (same error twice, cause unclear, or architecture/schema/auth/payments/3+ modules); strong never dispatches, it returns ESCALAR to the session, which then dispatches wizz-exec-ultra with strong's findings. Before any dispatch, measure the size, not just the difficulty: more than one layer (database, backend/worker, app/UI, external automation) or ~8 files means one executor per layer, each brief with max_calls at about 2/3 of the tier's turn cap; a cross-layer story never goes whole to one executor, and a partial return gets split, not "continue". Diff review always goes to wizz-exec-review (pinned to the Strong tier, never inherits the session). Before the first dispatch of a session, run `_shared/despacho-checklist.md` (whole story, tier, layers, discovery, announcement); with `/orchestration` in the request, every worker goes through `orca orchestration worker-start`, never `Agent`. Tell the user the tier and quantity of each dispatch. Full ladder in `_shared/model-ladder.md` and the rule in `_shared/token-economy.md` of the wizz module.

package/src/modules/wizz/_shared/despacho-checklist.md

@@ -0,0 +1,11 @@
+# Dispatch checklist (single source)
+
+Run these five steps before the FIRST dispatch of a session, whatever the vehicle (subagent `Agent` or Orca worker). Without all five, do not dispatch. The router, the maestro and `wizz-quick-dev` point here instead of repeating it.
+
+1. **Read the whole story** (or brief). Look for the tier, order and merge notes between stories. Never decide from a summary, a title or an epics header.
+2. **Tier by the ladder** (`_shared/model-ladder.md`). A "sensitive" guess needs the story to say so; do not assume it.
+3. **Layers and files.** More than one layer (database, backend/worker, app/UI, external automation, docs) or about 8 files means one executor per layer, each brief with `max_calls`. Check the fan-out cap in the ladder.
+4. **Discovery** (only when the request carries `/orchestration`): `orca account list`, `which claude codex agy`, the Codex default in `~/.codex/config.toml`, `agy models`. Dispatch only to an agent with an active account.
+5. **Announce** agent, model, effort and quantity to the user before dispatching ("2 × Codex gpt-6.1-sol medium: UI layer; 1 × Claude Sonnet: migration").
+
+**Vehicle.** If the request carries `/orchestration`, every worker, starting with the first, goes through `orca orchestration worker-start` with `--agent`, `--model` and `--effort`. A native `Agent` subagent is allowed only when the request does not mention orchestration. Every brief ends with a mandatory `worker_done`; acceptance is the session's own verification (type check and tests run by the session), never only the worker's report.

package/src/modules/wizz/_shared/model-ladder.md

@@ -4,7 +4,7 @@ The names `wizz-exec-mechanical`/`wizz-exec-standard`/`wizz-exec-strong`/`wizz-e
 
 ## The recommended session (the boss)
 
-The recommended session model is the Standard tier (Sonnet / gpt-6-sol / claude-sonnet-5-5 / gemini-3.5-flash). The boss does common work itself — commands, questions, implementation with a spec — dispatches subagents for isolation or parallel work, arbitrates conflict between executor and reviewer, and takes architecture/product decisions WITH the user.
+The recommended session model is the Standard tier (Sonnet / gpt-6.1-sol / claude-sonnet-5-5 / gemini-3.5-flash). The boss does common work itself — commands, questions, implementation with a spec — dispatches subagents for isolation or parallel work, arbitrates conflict between executor and reviewer, and takes architecture/product decisions WITH the user.
 
 A session running above Standard (Opus, Fable, Mythos...) thinks, decides and reviews, and delegates execution below its tier: common work (implementation with a spec, a bug with a known cause, tests) goes to `wizz-exec-standard`, mechanical work to `wizz-exec-mechanical`. It only does by hand what costs less than a subagent's fixed context: work that fits in 1 file and a few lines, commands, questions. Work at its own tier stays with it: an Opus session does Strong work itself and dispatches `wizz-exec-ultra` only after that attempt returns `ESCALAR` per the escalation signals below; a session on the Ultra model (Fable) takes strong's `ESCALAR` itself and never dispatches `wizz-exec-ultra`. Review is the exception — it never stays with the boss: it always runs on `wizz-exec-review`, pinned to the Strong tier, so in a Fable session review moves off the boss and onto Opus. (Owner's decision, 2026-11-04: an Opus session used to absorb every tier below it and nothing was ever dispatched.)
 
@@ -14,13 +14,13 @@ How to know who the boss is in Claude Code: the system prompt states the session
 
 | Tier | Subagent | Use | Claude Code | Codex | OpenCode | Gemini CLI | Antigravity (Orca worker) |
 |---|---|---|---|---|---|---|---|
-| Mechanical | `wizz-exec-mechanical` | scanning, rename, repetitive diff, 100% specified change | haiku (maxTurns 50, no effort field) | gpt-6-luna, effort low | anthropic/claude-haiku-4-5 | gemini-3.1-flash-lite (max_turns 50, no effort field) | gemini-3.8-flash-low |
-| Standard | `wizz-exec-standard` | small/medium defined feature, bug with known cause, tests | sonnet, effort medium (maxTurns 80) | gpt-6-sol, effort medium | anthropic/claude-sonnet-5-5 | gemini-3.5-flash (max_turns 80) | gemini-3.8-flash-medium |
-| Strong | `wizz-exec-strong` | bug with unclear cause after one investigation cycle, refactor spanning modules, schema/auth/payment changes, local technical decision | opus, effort high (maxTurns 120) | gpt-6-sol, effort high | anthropic/claude-opus-5-5 | gemini-3.1-pro-preview (max_turns 120) | gemini-4-argon-high |
-| Ultra | `wizz-exec-ultra` | ultra-hard work the Strong tier returned `ESCALAR` on, plus its findings | fable, effort xhigh (maxTurns 150) | gpt-6-astra, effort xhigh | anthropic/claude-fable-5-1 | no ultra tier on this platform | no ultra tier: goes to Claude Fable |
-| Review | `wizz-exec-review` | review of a diff produced by any tier; pinned to Strong, never inherits the session | opus, effort high (maxTurns 60) | gpt-6-sol, effort high | anthropic/claude-opus-5-5 | gemini-3.1-pro-preview (max_turns 60) | not used: review stays on Claude (see Orca workers) |
+| Mechanical | `wizz-exec-mechanical` | scanning, rename, repetitive diff, 100% specified change | haiku (maxTurns 50, no effort field) | gpt-6-luna, effort low | anthropic/claude-haiku-4-5 | gemini-3.1-flash-lite (max_turns 50, no effort field) | gemini-3.8-flash-high |
+| Standard | `wizz-exec-standard` | small/medium defined feature, bug with known cause, tests | sonnet, effort medium (maxTurns 80) | gpt-6.1-sol, effort medium | anthropic/claude-sonnet-5-5 | gemini-3.5-flash (max_turns 80) | gemini-4-hydrogen-high |
+| Strong | `wizz-exec-strong` | bug with unclear cause after one investigation cycle, refactor spanning modules, schema/auth/payment changes, local technical decision | opus, effort high (maxTurns 120) | gpt-6.1-sol, effort high | anthropic/claude-opus-5-5 | gemini-3.1-pro-preview (max_turns 120) | gemini-4-hydrogen-xhigh |
+| Ultra | `wizz-exec-ultra` | ultra-hard work the Strong tier returned `ESCALAR` on, plus its findings | fable, effort high (maxTurns 150) | gpt-6-astra, effort xhigh | anthropic/claude-fable-5-1 | no ultra tier on this platform | no ultra tier: goes to Claude Fable |
+| Review | `wizz-exec-review` | review of a diff produced by any tier; pinned to Strong, never inherits the session | opus, effort high (maxTurns 60) | gpt-6.1-sol, effort high | anthropic/claude-opus-5-5 | gemini-3.1-pro-preview (max_turns 60) | not used: review stays on Claude (see Orca workers) |
 
-Staying current: Claude Code tiers are aliases that Claude Code points at the newest model, so they never need a bump. Codex has no such alias: on install and on every `wizz update`, the installer reads the machine's Codex models cache (`~/.codex/models_cache.json`) and swaps each pinned Codex model for the newest current model of the same class (fast, workhorse, frontier). The table's Codex column is the fallback, used when the cache is missing, older than the spec, or the newer model lacks the tier's effort. OpenCode and Gemini CLI stay pinned to the table. The Antigravity column is not installed as subagents: it is the fallback for Orca workers (`--agent antigravity`), and the session confirms it against `agy models` before each dispatch (checked on 2026-11-04).
+Staying current: Claude Code tiers are aliases that Claude Code points at the newest model, so they never need a bump. Codex has no such alias: on install and on every `wizz update`, the installer reads the machine's Codex models cache (`~/.codex/models_cache.json`) and swaps each pinned Codex model for the newest current model of the same class (fast, workhorse, frontier). The table's Codex column is the fallback, used when the cache is missing, older than the spec, or the newer model lacks the tier's effort. OpenCode and Gemini CLI stay pinned to the table. The Antigravity column is not installed as subagents: it is the fallback for Orca workers (`--agent antigravity`), and the session confirms it against `agy models` before each dispatch (checked on 2026-11-14).
 
 OpenCode gets the model only: its per-agent effort field isn't documented, and it has no per-agent turn cap field either. Claude Code and Gemini CLI enforce turn caps natively (`maxTurns` / `max_turns`); Codex and OpenCode have no per-agent turn cap field, so briefs to them should always carry `max_calls`.
 
@@ -81,13 +81,28 @@ The tier answers "how hard"; it does not answer "how big". Work that is easy per
 
 Applies only when the session runs `/orchestration` (Orca workers); without it, nothing above changes. Orca workers let the session spread work across vendors (Claude, Codex, Antigravity), each with its own quota. The boss is still the Claude session.
 
+0. **Checklist first.** Run `_shared/despacho-checklist.md` before the first worker. With `/orchestration` in the request, the first dispatch is already a worker (`orca orchestration worker-start`), never `Agent`; the `wizz-router-enforce.js` hook injects this reminder when the prompt carries the command.
 1. **Discover before dispatching.** `orca account list` (which Claude/Codex accounts are active), `which claude codex agy`, the Codex default in `~/.codex/config.toml`, and `agy models` for Antigravity. Dispatch only to an agent with an active account; never assume the list.
 2. **Tier first, agent second.** Classify each worker with this ladder (mechanical, standard, strong, ultra) exactly as for subagents, then pick, among the available agents, the cheapest model that covers the tier (the table above maps tier to model per vendor).
 3. **Sensitive areas stay on Claude.** Work touching database schema or migrations, auth, payments, permissions, or deletion of data goes to a Claude worker (or a `wizz-exec-*` subagent), whatever the tier.
 4. **A failure escalates to Claude.** If a non-Claude worker fails once (gives up, returns broken work, or `ESCALAR`), the retry goes to Claude at the same tier or above, never to the same vendor again for that unit.
 5. **Explicit agent and model.** Every `orca orchestration worker-start` carries `--agent` and `--model` (and `--effort` when the agent accepts it). A worker on the agent's default model breaks the ladder, like a subagent without `model`. Briefs to Codex and Antigravity always carry `max_calls`.
 6. **Review is always Claude.** Every worker's output, from any vendor, is reviewed by `wizz-exec-review` (Claude, Strong tier), never in another vendor. Other vendors build; Claude reviews and the boss gives the final verdict. (Owner's decision, 2026-11-04.)
-7. **Transparency.** Each dispatch states agent, model, quantity and why ("2 × Codex gpt-6-sol medium: UI layer; 1 × Claude Sonnet: migration, sensitive area").
+7. **Transparency.** Each dispatch states agent, model, quantity and why ("2 × Codex gpt-6.1-sol medium: UI layer; 1 × Claude Sonnet: migration, sensitive area").
+
+## Benchmark basis (researched 2026-11-14)
+
+Why the table looks like this. Official = vendor docs; independent = Vals.ai Terminal-Bench 4.0 (same harness for all, updated 2026-11-11). Vendor-reported SWE-bench Pro is not comparable with the Scale leaderboard, so it is not used to rank.
+
+- **Claude:** Sonnet 5.5 64.1% vs Opus 5.5 65.2% vs Fable 5.2 65.2% (independent), at US$10.75 / 12.04 / 14.56 per task. Sonnet is the standard tier; Opus earns its place on long, multi-module work; Fable pays off only on very long tasks, so `max` effort is not worth it. Haiku 5.5 scores 36.4% and its price jumps 5x above 100k prompt tokens: mechanical only, with short context.
+- **Codex:** gpt-6.1-sol has the best cost per task in the ranking (55.1% at US$1.72); gpt-6-astra adds a few points for about 5x the price. gpt-6-luna scores 13.6% on long terminal work: never beyond mechanical. gpt-6-sol is no longer recommended by Codex; the pinned Codex column now names gpt-6.1-sol (bumped 2026-11-14).
+- **Antigravity (owner has the Pro plan, 2026-11-14):** mechanical is gemini-3.8-flash at high effort (cheapest; 80% SWE-bench and 89.5% LiveCodeBench in short tasks, but 18.2% on long terminal work, so scoped edits only). Claude Opus/Sonnet via agy spend Google quota, not Anthropic's, and are available on Pro. gemini-4-hydrogen is the only Gemini 4 on every plan (54.0% at US$7.56 per task). gemini-4-argon has the worst cost per result (57.6% at US$17.64). gemini-4-carbon needs the Ultra plan.
+- **Effort before model:** raise effort one step on the same model before moving up a tier. A cheaper model with a lower effort can match a pricier one.
+- **Delegate only independent pieces** or work larger than one context window. A chain of dependent steps stays on one model.
+- **Cross-vendor review is asymmetric** (arXiv 2607.21656): Claude reviewing Codex improved results, Codex reviewing Claude made them worse. This backs "review is always Claude".
+- **Quota is opaque:** no vendor publishes how much quota each effort level consumes. Using Claude through `agy` spends Google's quota, not Anthropic's.
+
+Review this section when: a model is retired, a promo ends (Argon and Carbon double on 2026-12-01, Gemini 3.8 Flash on 2027-01-01, the Claude 4.6 models and GPT-OSS leave Antigravity on 2026-11-18), a new model ships, or the user asks to update the repos.
 
 ## Transparency
 

package/src/modules/wizz/agents/wizz-maestro/SKILL.md

@@ -125,7 +125,7 @@ Handoff rule:
 
 **Invocation contract:** `areas.<area>.agent` and the menu destinations are **persona skill** names, not native subagent types. In the current session, invoke `Skill(skill="wizz-growth", args="<CRO brief>")` (or the chosen area's skill). Never pass `wizz-growth`, `wizz-designer`, `wizz-qa`, or `wizz-maestro` as `subagent_type` just because the registry calls them agents.
 
-Before any `wizz-exec-*` dispatch, measure and partition: count layers (database, backend/worker, app/UI, external automation, docs) and files; more than one layer or ~8 files means one executor per layer, each brief with `max_calls`, and you join the parts (rule in "Size before dispatch", `_shared/model-ladder.md`). For isolated/parallel work, pick a `wizz-exec-*` that's on the list of available agents and pass in the brief the area skill to load, the shard, and the scope. The executor must load the full entry skill before the relevant references; it doesn't inherit the skills the maestro already loaded. If no suitable executor is available, run the skill in the current session. If the skill is also missing, report the missing install, without inventing an agent type or repeating the call that failed. When the session runs `/orchestration` (Orca workers), each worker follows "Orca workers" in `_shared/model-ladder.md`: tier first, then the cheapest available agent that covers it, explicit `--agent`/`--model`, sensitive areas on Claude, and review always on Claude.
+Before the first dispatch of a session, run `_shared/despacho-checklist.md` (whole story, tier, layers, discovery, announcement). When the request carries `/orchestration`, dispatch with `orca orchestration worker-start --agent --model --effort` from the first worker, never with `Agent` (section "Orca workers" in `_shared/model-ladder.md`). Before any `wizz-exec-*` dispatch, measure and partition: count layers (database, backend/worker, app/UI, external automation, docs) and files; more than one layer or ~8 files means one executor per layer, each brief with `max_calls`, and you join the parts (rule in "Size before dispatch", `_shared/model-ladder.md`). For isolated/parallel work, pick a `wizz-exec-*` that's on the list of available agents and pass in the brief the area skill to load, the shard, and the scope. The executor must load the full entry skill before the relevant references; it doesn't inherit the skills the maestro already loaded. If no suitable executor is available, run the skill in the current session. If the skill is also missing, report the missing install, without inventing an agent type or repeating the call that failed. When the session runs `/orchestration` (Orca workers), each worker follows "Orca workers" in `_shared/model-ladder.md`: tier first, then the cheapest available agent that covers it, explicit `--agent`/`--model`, sensitive areas on Claude, and review always on Claude.
 
 When invoking the area agent, declare the brief in the format of the [shared handoff protocol](../../../../core-skills/_shared/handoff-protocol.md): `feature` (the slug resolved above, or `nenhuma`), `origem` (you, for the anti-loop — the agent never hands the same request back to you), `cérebro já consultado` (the up-to-3-line summary you already pulled in Step 2, cutting the agent's duplicate lookup), decisions already made in the chain, the entry skill **by name** (when the registry `when:` matches the request, write it: "entry skill: wizz-vsl", not just the area) and the relevant references (without loading references unrelated to the task), optional `model_hint`, and optional `max_calls` (cap on the executor's tool calls). The area agent that receives this summary skips its own `/wizz-cerebro ver` step.
 

package/src/modules/wizz/subagents/codex/wizz-exec-review.toml

@@ -1,9 +1,9 @@
 # Gerado por tools/generate-subagents.mjs a partir de src/modules/wizz/subagents/spec.yaml. Não edite este arquivo direto: edite o spec.yaml e rode `npm run generate:subagents`.
 name = "wizz-exec-review"
 description = """
-Wizz Method reviewer pinned to the Strong tier (gpt-6-sol, effort high), never to the session's model. Receives a diff or an executor's result and reviews correctness, security, regressions, and scope adherence. Inside wizz-code-review it runs ONE layer; it never replaces that skill, which orchestrates the layers from the main session. Doesn't implement: returns a verdict and a list of issues with file:line.
+Wizz Method reviewer pinned to the Strong tier (gpt-6.1-sol, effort high), never to the session's model. Receives a diff or an executor's result and reviews correctness, security, regressions, and scope adherence. Inside wizz-code-review it runs ONE layer; it never replaces that skill, which orchestrates the layers from the main session. Doesn't implement: returns a verdict and a list of issues with file:line.
 """
-model = "gpt-6-sol"
+model = "gpt-6.1-sol"
 model_reasoning_effort = "high"
 sandbox_mode = "read-only"
 developer_instructions = """

package/src/modules/wizz/subagents/codex/wizz-exec-standard.toml

@@ -1,9 +1,9 @@
 # Gerado por tools/generate-subagents.mjs a partir de src/modules/wizz/subagents/spec.yaml. Não edite este arquivo direto: edite o spec.yaml e rode `npm run generate:subagents`.
 name = "wizz-exec-standard"
 description = """
-Standard Wizz Method executor for day-to-day implementation. Well-defined small/medium features, bug fixes with a known cause, multi-file edits, tests. Same tier as the recommended session model: dispatch it for isolation or parallel work (1 per file/module, up to 4 at once), not to escalate. Size, not just difficulty: work crossing more than one layer (database, backend/worker, app/UI, external automation) or ~8 files is split, one dispatch per layer, each brief with max_calls. Model on this platform: gpt-6-sol, effort medium.
+Standard Wizz Method executor for day-to-day implementation. Well-defined small/medium features, bug fixes with a known cause, multi-file edits, tests. Same tier as the recommended session model: dispatch it for isolation or parallel work (1 per file/module, up to 4 at once), not to escalate. Size, not just difficulty: work crossing more than one layer (database, backend/worker, app/UI, external automation) or ~8 files is split, one dispatch per layer, each brief with max_calls. Model on this platform: gpt-6.1-sol, effort medium.
 """
-model = "gpt-6-sol"
+model = "gpt-6.1-sol"
 model_reasoning_effort = "medium"
 developer_instructions = """
 You are an implementation executor for the Wizz Method. You receive a brief with a goal and context, and you implement it.

package/src/modules/wizz/subagents/codex/wizz-exec-strong.toml

@@ -1,9 +1,9 @@
 # Gerado por tools/generate-subagents.mjs a partir de src/modules/wizz/subagents/spec.yaml. Não edite este arquivo direto: edite o spec.yaml e rode `npm run generate:subagents`.
 name = "wizz-exec-strong"
 description = """
-Strong Wizz Method executor for hard work. Bugs with no known cause after one investigation cycle, cross-module refactors, schema/auth/payment changes, local technical decisions. Size, not just difficulty: work crossing more than one layer (database, backend/worker, app/UI, external automation) or ~8 files is split, one dispatch per layer, each brief with max_calls. The session dispatches it when the work is too hard for the session's own tier. If the work turns out to be ultra hard, it returns ESCALAR with its findings; it never dispatches anything itself. Model on this platform: gpt-6-sol, effort high.
+Strong Wizz Method executor for hard work. Bugs with no known cause after one investigation cycle, cross-module refactors, schema/auth/payment changes, local technical decisions. Size, not just difficulty: work crossing more than one layer (database, backend/worker, app/UI, external automation) or ~8 files is split, one dispatch per layer, each brief with max_calls. The session dispatches it when the work is too hard for the session's own tier. If the work turns out to be ultra hard, it returns ESCALAR with its findings; it never dispatches anything itself. Model on this platform: gpt-6.1-sol, effort high.
 """
-model = "gpt-6-sol"
+model = "gpt-6.1-sol"
 model_reasoning_effort = "high"
 developer_instructions = """
 You are a senior executor for the Wizz Method. You receive a brief with a goal and context for hard work, where the root cause or the path forward isn't clear yet.

package/src/modules/wizz/subagents/spec.yaml

@@ -175,10 +175,10 @@ models:
   # reuse sol at higher effort; ultra stays on astra.
   codex:
     mechanical: gpt-6-luna
-    standard: gpt-6-sol
-    strong: gpt-6-sol
+    standard: gpt-6.1-sol
+    strong: gpt-6.1-sol
     ultra: gpt-6-astra
-    review: gpt-6-sol
+    review: gpt-6.1-sol
 
 # Codex `model_reasoning_effort`.
 codex_effort:
@@ -194,7 +194,7 @@ claude_effort:
   mechanical: null
   standard: medium
   strong: high
-  ultra: xhigh
+  ultra: high
   review: high
 
 # Turn cap: Claude Code `maxTurns`, Gemini CLI `max_turns`. Sized a little

package/src/modules/wizz/subagents/wizz-exec-ultra.md

@@ -4,7 +4,7 @@ name: wizz-exec-ultra
 description: >-
   Ultra Wizz Method executor, the top tier, for ultra-hard work only. The session dispatches it after wizz-exec-strong returned ESCALAR, passing along the strong executor's findings. Never the first dispatch for routine or merely hard work. If it fails too, the work goes back to the user.
 model: fable
-effort: xhigh
+effort: high
 maxTurns: 150
 ---
 

package/src/skills-lib/wizz-cerebro/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Persistent memory system across AI sessions. Use this skill whenever the user types
   /iniciar, /salvar, /ver, /dia, /dump, /decisao, /conteudo, /prospect or /memoria. Also activate when the
   user mentions "cerebro", "atualizar o cerebro", "salvar sessão", "resumo do projeto",
-  "estado atual", "registrar decisão", "ideia de conteúdo", "pesquisar prospect" or "ler a auto-memória".
+  "estado atual", "salva/anota/guarda no cérebro", "registrar decisão", "ideia de conteúdo", "pesquisar prospect" or "ler a auto-memória".
   This skill maintains CEREBRO.md as the central index plus one file per project — it's the user's
   memory across Claude Code, Codex and any other agent.
   The agent's auto-memory is the other layer, and `/memoria` is the read bridge to it from
@@ -15,6 +15,8 @@ description: >
 
 # Cérebro — Persistent Memory System
 
+**Any "save/note this in the Cérebro" request lands in the vault (`/salvar`, `/decisao`, `/dump`), never in `CLAUDE.md` or `AGENTS.md`: those files load on every session and cost tokens each time.**
+
 ## Command groups
 
 ```

package/src/skills-lib/wizz-router/SKILL.md

@@ -23,7 +23,7 @@ You are the **Director / entry point** — not the orchestrator (that's `wizz-ma
 
 **Token economy:** the `rtk-rewrite.sh` hook already handles RTK automatically (don't run `rtk --version` on every routing). Before reading raw files, prefer `/wizz-cerebro ver` or a specific `grep`.
 
-**With `/orchestration` (Orca):** workers follow the same ladder; before starting any Orca worker, apply "Orca workers" in the wizz module's `_shared/model-ladder.md` (discover agents, tier first, explicit `--agent`/`--model`, sensitive areas on Claude, review always on Claude).
+**With `/orchestration` (Orca):** the first dispatch is already an Orca worker (`orca orchestration worker-start`), never `Agent`; run `_shared/despacho-checklist.md` first. Workers follow the same ladder; before starting any Orca worker, apply "Orca workers" in the wizz module's `_shared/model-ladder.md` (discover agents, tier first, explicit `--agent`/`--model`, sensitive areas on Claude, review always on Claude).
 
 ## Triage and delegation (the Director's core job)
 

package/tools/hooks/wizz-router-enforce.js

@@ -126,6 +126,16 @@ function findWizzRoot(startDir) {
 const WIZZ_PROJECT_HINT =
   '🎛️ Wizz: NÃO invoque wizz-router. Capacidades → rel necessário à entrega → áreas → atalhos. 2+ áreas → `wizz-maestro`. 1 área: 2+ fatores (multi-passo, planejar, artefato memorável) → `wizz-maestro`; senão → Skill da área. Auth/pagamento/permissão/migração → maestro. Personas são skills, não subagent_type; Agent usa tipos disponíveis wizz-exec-*; difícil → wizz-exec-strong (ESCALAR → ultra).';
 
+// /orchestration no pedido: o despacho vai por worker do Orca, nunca por Agent
+// (adendo 2026-11-12). Conferência por código: a regra não depende de lembrar.
+const ORCHESTRATION_RE = /(^|\s)\/orchestration(?=\s|$|[.,;:!?])/i;
+const ORCHESTRATION_HINT =
+  ' 🛰️ /orchestration: despache com `orca orchestration worker-start --agent --model --effort`, nunca com Agent; antes do 1º despacho cumpra `_shared/despacho-checklist.md`.';
+
+function orchestrationLine(prompt) {
+  return ORCHESTRATION_RE.test(String(prompt || '')) ? ORCHESTRATION_HINT : '';
+}
+
 function buildContext(isWizzProject) {
   if (isWizzProject) return WIZZ_PROJECT_HINT;
   return (
@@ -245,14 +255,29 @@ function runHook() {
       const prompt = data.prompt || '';
       const trivial = !prompt || isTrivial(prompt);
       if (trivial) {
-        traceLine({ ts: new Date().toISOString(), isTrivial: true, mode: null });
+        // Prompt que começa com "/" é trivial para o roteamento, mas /orchestration
+        // ainda precisa do aviso de despacho (caso real de 2026-11-12).
+        const orchestrationOnly = orchestrationLine(prompt).trim();
+        traceLine({
+          ts: new Date().toISOString(),
+          isTrivial: true,
+          mode: null,
+          ...(orchestrationOnly ? { contextInjected: orchestrationOnly } : {}),
+        });
+        if (orchestrationOnly) {
+          process.stdout.write(
+            JSON.stringify({
+              hookSpecificOutput: { hookEventName: 'UserPromptSubmit', additionalContext: orchestrationOnly },
+            }),
+          );
+        }
         process.exit(0);
       }
 
       const cwd = data.cwd || process.cwd();
       const wizzRoot = findWizzRoot(cwd);
       const isWizzProject = Boolean(wizzRoot);
-      const context = buildContext(isWizzProject) + featureLine(wizzRoot);
+      const context = buildContext(isWizzProject) + featureLine(wizzRoot) + orchestrationLine(prompt);
 
       const warnings = checkFallbackWarnings(isWizzProject, wizzRoot);
       if (warnings.length > 0) emitFallbackWarnings(warnings);
@@ -285,6 +310,7 @@ if (require.main === module) {
   module.exports = {
     isTrivial,
     buildContext,
+    orchestrationLine,
     featureLine,
     findWizzRoot,
     isTraceEnabled,