wizz-method 2.25.0 → 2.25.2

package/package.json

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

package/src/bmm-skills/4-implementation/wizz-dev-story/customize.toml

@@ -20,6 +20,11 @@ activation_steps_prepend = []
 
 activation_steps_append = []
 
+# Cheap dispatch rule (single source in the wizz module's _shared/). Lives here
+# too because the router can hand a code request straight to this workflow,
+# skipping the area persona that normally carries it.
+include = ["../../_shared/despacho-barato.md"]
+
 # Persistent facts the workflow keeps in mind for the whole run
 # (standards, compliance constraints, stylistic guardrails).
 # Distinct from the runtime memory sidecar — these are static context

package/src/bmm-skills/4-implementation/wizz-quick-dev/customize.toml

@@ -20,6 +20,11 @@ activation_steps_prepend = []
 
 activation_steps_append = []
 
+# Cheap dispatch rule (single source in the wizz module's _shared/). Lives here
+# too because the router hands one-off code requests straight to this workflow,
+# skipping the area persona that normally carries it.
+include = ["../../_shared/despacho-barato.md"]
+
 # Persistent facts the workflow keeps in mind for the whole run
 # (standards, compliance constraints, stylistic guardrails).
 # Distinct from the runtime memory sidecar — these are static context

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; dispatch wizz-exec-mechanical/wizz-exec-standard subagents, partitioned one per file/module, up to 4 concurrent. The session's model is the boss: it does common work itself, 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). 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/model-ladder.md

@@ -6,21 +6,21 @@ The names `wizz-exec-mechanical`/`wizz-exec-standard`/`wizz-exec-strong`/`wizz-e
 
 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.
 
-A session running above Standard (Opus, Fable, Mythos...) absorbs every tier at or below its own model: 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) absorbs Ultra too: it takes strong's `ESCALAR` itself and never dispatches `wizz-exec-ultra`. Review is the exception — it's NEVER absorbed: 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.
+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.)
 
 How to know who the boss is in Claude Code: the system prompt states the session's model ("You are powered by the model named ..."). Fable and Mythos sit above Opus. The same logic applies on every platform, swapping in the names from the table below.
 
 ## Tier table
 
-| Tier | Subagent | Use | Claude Code | Codex | OpenCode | Gemini CLI |
-|---|---|---|---|---|---|---|
-| 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) |
-| 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) |
-| 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) |
-| 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 |
-| 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) |
+| 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) |
 
-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.
+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).
 
 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`.
 
@@ -54,7 +54,7 @@ Difficulty picks the executor's tier; size and sensitive area pick the review la
 2. **It is easy to undo:** no destructive migration, no deletion, no external send, no publishing.
 3. **Nobody acts on it before another step sees it.**
 
-If any one fails, the output goes through review on the Strong tier (in another vendor when one is available) and the boss gives the final verdict. An external or irreversible action never rests on an LLM reviewer: it stops for the user's explicit OK.
+If any one fails, the output goes through review on the Strong tier (`wizz-exec-review`; with Orca workers, see the review rule there) and the boss gives the final verdict. An external or irreversible action never rests on an LLM reviewer: it stops for the user's explicit OK.
 
 Model confidence does not count: a confidence the executor or reviewer states about its own output never skips review, never drops a layer, and never lowers the tier. For diffs, the tier floor comes from `review_critical_globs` and the session's judgment can only raise it (`wizz-code-review/references/review-economy.md` § 2).
 
@@ -75,6 +75,18 @@ The tier answers "how hard"; it does not answer "how big". Work that is easy per
 4. **A whole story never goes to a single executor** when it crosses layers. The session (the boss) joins the parts, runs the suite, and makes the single commit.
 5. **A resume is not a plan.** If an executor comes back partial because of a limit, the session splits what is left into new briefs instead of sending "continue" to the same agent.
 
+## Orca workers
+
+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.
+
+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").
+
 ## Transparency
 
 Every dispatch states the tier and quantity in the text to the user ("1 × strong", "3 × mechanical"). Never just "executors".

package/src/modules/wizz/_shared/token-economy.md

@@ -44,7 +44,7 @@ Mechanical work NEVER runs in the main session when it's large (more than 3 file
 
 Every dispatch can carry `max_calls` (see handoff-protocol.md): an executor that hits the cap returns partial work, never escalates on its own.
 
-No nesting: a subagent never dispatches another subagent; all dispatch goes through the session. Architecture and product decisions never go to strong or ultra: they return options with a recommendation, the user decides. The session's model is the boss: it orchestrates, arbitrates, and decides; a session above Standard absorbs every tier at or below its own model (review excepted — always pinned to Strong). Every dispatch tells the user the tier and quantity. Full detail, per-platform table, and rules: `_shared/model-ladder.md`.
+No nesting: a subagent never dispatches another subagent; all dispatch goes through the session. Architecture and product decisions never go to strong or ultra: they return options with a recommendation, the user decides. The session's model is the boss: it orchestrates, arbitrates, and decides; a session above Standard delegates execution below its tier (common work to `wizz-exec-standard`, mechanical to `wizz-exec-mechanical`; only work that fits in 1 file and a few lines stays in it) and keeps work at its own tier (review excepted — always pinned to Strong). Every dispatch tells the user the tier and quantity. Full detail, per-platform table, and rules: `_shared/model-ladder.md`.
 
 Diff review can go to `wizz-exec-review`; architecture and product decisions stay with the main session's model (this is already in the review rules of wizz-quick-dev and wizz-code-review; it doesn't change).
 

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.
+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 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/skills-lib/wizz-router/SKILL.md

@@ -23,6 +23,8 @@ 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).
+
 ## Triage and delegation (the Director's core job)
 
 **Skill ≠ native subagent:** the registry's `agent:` field identifies a persona skill. Invoke it via `Skill` (e.g. `Skill(skill="wizz-growth", args="<brief>")`), never as `Agent(subagent_type="wizz-growth")`. For isolated execution, use only a type announced by the runtime, such as `wizz-exec-standard`, with the area skill and the brief in the prompt. With no executor available, use the skill in the current session; without the skill, report the missing installation. Don't invent agent types.