wizz-method 2.5.0 → 2.6.0

package/package.json

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

package/src/bmm-skills/4-implementation/wizz-code-review/references/review-economy.md

@@ -62,7 +62,7 @@ When the brief names a `review-prompts/` file, that file owns the method and the
 The Forte tier is defined in `_shared/model-ladder.md`.
 
 - **Session runs on the Forte tier:** the session triages, as the triage instructions say. It already holds the context, so a subagent would only re-read it.
-- **Any session model other than the Forte tier:** write the collected findings, each with its originating layer `id`, to a uniquely-named temp file and launch one `wizz-exec-opus` subagent. Its brief is: the triage instructions (the path of the step file that holds them), the findings file, `{diff_file}`, `{spec_file}` when present, the paths of any loaded context docs, `{tier}`, `{failed_layers}`, `{layer_status}` (the active/dropped layer ids with drop reasons, so the triager knows which layers actually ran), and — only in workflows that set it (`wizz-code-review`) — `{review_mode}`. The subagent runs the whole pipeline itself: verdicts, the acceptance audit, grouping, and routing into categories. It returns every entry with severity, category and evidence, plus every dismissal with its reason — it never writes to any file; the session writes every log. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, not a new prompt to the user — and carries on per each workflow's own step. In `wizz-code-review`, `decision_needed` entries still get a genuine human confirmation before continuing, exactly as the presentation step already does; a confirmed entry the user rejects there is logged as dismissed with the user's own reason, never forced through. In `wizz-quick-dev`, `intent_gap` still loops back to the human as part of resolving it, and `bad_spec` still loops back automatically — the session's re-check adds no new user prompt for either.
+- **Any session model other than the Forte tier:** write the collected findings, each with its originating layer `id`, to a uniquely-named temp file and launch one `wizz-exec-strong` subagent. Its brief is: the triage instructions (the path of the step file that holds them), the findings file, `{diff_file}`, `{spec_file}` when present, the paths of any loaded context docs, `{tier}`, `{failed_layers}`, `{layer_status}` (the active/dropped layer ids with drop reasons, so the triager knows which layers actually ran), and — only in workflows that set it (`wizz-code-review`) — `{review_mode}`. The subagent runs the whole pipeline itself: verdicts, the acceptance audit, grouping, and routing into categories. It returns every entry with severity, category and evidence, plus every dismissal with its reason — it never writes to any file; the session writes every log. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, not a new prompt to the user — and carries on per each workflow's own step. In `wizz-code-review`, `decision_needed` entries still get a genuine human confirmation before continuing, exactly as the presentation step already does; a confirmed entry the user rejects there is logged as dismissed with the user's own reason, never forced through. In `wizz-quick-dev`, `intent_gap` still loops back to the human as part of resolving it, and `bad_spec` still loops back automatically — the session's re-check adds no new user prompt for either.
 
 `{failed_layers}` stores layer `id`s (append ` (partial)` for a partial layer); every check against it compares ids, not names.
 

package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-03-triage.md

@@ -9,7 +9,7 @@
 
 ## INSTRUCTIONS
 
-0. **Decide who triages**, per `references/review-economy.md` section 4. When a `wizz-exec-opus` subagent triages, its brief includes `{layer_status}` so it can tell which layers ran; it runs every instruction of this step through routing (instructions 1-5 below) and returns the result. The session then re-checks the subagent's verdicts and routing against the evidence, confirms `decision_needed` entries with the user, and continues with instruction 6.
+0. **Decide who triages**, per `references/review-economy.md` section 4. When a `wizz-exec-strong` subagent triages, its brief includes `{layer_status}` so it can tell which layers ran; it runs every instruction of this step through routing (instructions 1-5 below) and returns the result. The session then re-checks the subagent's verdicts and routing against the evidence, confirms `decision_needed` entries with the user, and continues with instruction 6.
 
 1. **Normalize** findings from all layers into a unified list where each finding has:
    - `id` -- sequential integer

package/src/bmm-skills/4-implementation/wizz-quick-dev/references/review-economy.md

@@ -62,7 +62,7 @@ When the brief names a `review-prompts/` file, that file owns the method and the
 The Forte tier is defined in `_shared/model-ladder.md`.
 
 - **Session runs on the Forte tier:** the session triages, as the triage instructions say. It already holds the context, so a subagent would only re-read it.
-- **Any session model other than the Forte tier:** write the collected findings, each with its originating layer `id`, to a uniquely-named temp file and launch one `wizz-exec-opus` subagent. Its brief is: the triage instructions (the path of the step file that holds them), the findings file, `{diff_file}`, `{spec_file}` when present, the paths of any loaded context docs, `{tier}`, `{failed_layers}`, `{layer_status}` (the active/dropped layer ids with drop reasons, so the triager knows which layers actually ran), and — only in workflows that set it (`wizz-code-review`) — `{review_mode}`. The subagent runs the whole pipeline itself: verdicts, the acceptance audit, grouping, and routing into categories. It returns every entry with severity, category and evidence, plus every dismissal with its reason — it never writes to any file; the session writes every log. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, not a new prompt to the user — and carries on per each workflow's own step. In `wizz-code-review`, `decision_needed` entries still get a genuine human confirmation before continuing, exactly as the presentation step already does; a confirmed entry the user rejects there is logged as dismissed with the user's own reason, never forced through. In `wizz-quick-dev`, `intent_gap` still loops back to the human as part of resolving it, and `bad_spec` still loops back automatically — the session's re-check adds no new user prompt for either.
+- **Any session model other than the Forte tier:** write the collected findings, each with its originating layer `id`, to a uniquely-named temp file and launch one `wizz-exec-strong` subagent. Its brief is: the triage instructions (the path of the step file that holds them), the findings file, `{diff_file}`, `{spec_file}` when present, the paths of any loaded context docs, `{tier}`, `{failed_layers}`, `{layer_status}` (the active/dropped layer ids with drop reasons, so the triager knows which layers actually ran), and — only in workflows that set it (`wizz-code-review`) — `{review_mode}`. The subagent runs the whole pipeline itself: verdicts, the acceptance audit, grouping, and routing into categories. It returns every entry with severity, category and evidence, plus every dismissal with its reason — it never writes to any file; the session writes every log. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, not a new prompt to the user — and carries on per each workflow's own step. In `wizz-code-review`, `decision_needed` entries still get a genuine human confirmation before continuing, exactly as the presentation step already does; a confirmed entry the user rejects there is logged as dismissed with the user's own reason, never forced through. In `wizz-quick-dev`, `intent_gap` still loops back to the human as part of resolving it, and `bad_spec` still loops back automatically — the session's re-check adds no new user prompt for either.
 
 `{failed_layers}` stores layer `id`s (append ` (partial)` for a partial layer); every check against it compares ids, not names.
 

package/src/bmm-skills/4-implementation/wizz-quick-dev/step-04-review.md

@@ -62,7 +62,7 @@ This section's only file changes are temp diff files (`{diff_file}` and `{clean_
 
 ### Classify
 
-Decide who triages, per `./references/review-economy.md` § 4. When the session runs on the Forte tier, it triages directly, following the instructions below. Otherwise, write the collected findings — each tagged with its originating layer `id` — to a uniquely-named temp file and launch one `wizz-exec-opus` subagent. Its brief is: these Classify instructions (Classify items 1–4 below — the acceptance audit, verdicts, grouping, and routing into intent_gap/bad_spec/patch/defer, including the dismissal reasons), the findings file, `{diff_file}`, `{spec_file}` (when present), the paths of any context docs loaded from `{spec_file}`'s `context:` frontmatter list in step-03, `{tier}`, `{failed_layers}`, and `{layer_status}` (so the triager can tell which layers actually ran) — quick-dev never sets `{review_mode}`, so the brief never carries it. The subagent never writes to any file, including `{spec_file}` — it returns every entry with severity, category and evidence, plus every dismissal with its reason. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, it adds no new prompt to the user — writes the `## Review Triage Log`, and runs Classify item 5 (loopbacks, patches, defers) itself exactly as when the session triages directly.
+Decide who triages, per `./references/review-economy.md` § 4. When the session runs on the Forte tier, it triages directly, following the instructions below. Otherwise, write the collected findings — each tagged with its originating layer `id` — to a uniquely-named temp file and launch one `wizz-exec-strong` subagent. Its brief is: these Classify instructions (Classify items 1–4 below — the acceptance audit, verdicts, grouping, and routing into intent_gap/bad_spec/patch/defer, including the dismissal reasons), the findings file, `{diff_file}`, `{spec_file}` (when present), the paths of any context docs loaded from `{spec_file}`'s `context:` frontmatter list in step-03, `{tier}`, `{failed_layers}`, and `{layer_status}` (so the triager can tell which layers actually ran) — quick-dev never sets `{review_mode}`, so the brief never carries it. The subagent never writes to any file, including `{spec_file}` — it returns every entry with severity, category and evidence, plus every dismissal with its reason. The session then re-checks the subagent's own verdicts and routing against the evidence it returned — this is the session validating a delegated triager's work, it adds no new prompt to the user — writes the `## Review Triage Log`, and runs Classify item 5 (loopbacks, patches, defers) itself exactly as when the session triages directly.
 
 1. On every tier — this workflow has no `acceptance-auditor` layer — run the acceptance audit from `./references/review-economy.md` § 4 against `{spec_file}`: check the diff against the spec's acceptance criteria and constraints, and add a finding for each violation, deviation or missing behavior, with source `triage-acceptance`, to the unified list, before verdicts. It gets a verdict like any other finding, per Classify item 2.
 

package/src/core-skills/_shared/handoff-protocol.md

@@ -23,20 +23,25 @@ and pass along only the skill's entrypoint and the references actually needed
   The receiver first loads the full SKILL.md by invoking the skill;
   then reads only the references the task requires. Skills loaded
   by the lead are not automatically inherited by a subagent.
-- model_hint (optional): a rung on the ladder, not a raw model. Values:
-  `haiku | sonnet | opus | review`. The receiver dispatches `wizz-exec-<hint>`
-  (native in Claude Code, Codex, OpenCode and Gemini CLI). Escalation: at
-  most 1 rung up if the executor returns ambiguity or tests
-  fail twice. `opus` is only a real rung when the delegating session runs
-  above Opus (Fable); in an Opus session the receiver jumps straight to `review`
-  (full detail in `_shared/model-ladder.md`, in the wizz module).
-  Optional field: the handoff works fine without it.
+- model_hint (optional): a tier on the ladder, not a raw model. Values:
+  `mechanical | standard | strong | ultra | review`. Legacy values `haiku`,
+  `sonnet`, `opus` map to `mechanical`, `standard`, `strong` respectively.
+  The receiver dispatches `wizz-exec-<hint>` (native in Claude Code, Codex
+  and OpenCode). Escalation: `strong` is dispatched when the delegating
+  session's own tier isn't enough; `ultra` is only valid after a Strong-tier
+  `ESCALAR` — from `wizz-exec-strong`, or from the session itself when it
+  absorbed strong's work and hit the same signal; strong never dispatches
+  anything itself. If `ultra` also returns `ESCALAR`, the work goes back to
+  the user (full detail in `_shared/model-ladder.md`, in the wizz module).
+  On Gemini CLI there is no `wizz-exec-ultra`: an `ultra` hint goes back to
+  the user instead of dispatching. Optional field: the handoff works fine
+  without it.
 - max_calls (optional): a cap on tool calls the executor can spend
   on this brief, as an integer. The receiver dispatches
   `wizz-exec-<hint>` with that cap declared in the brief. On hitting the cap,
   the executor STOPS, delivers the partial work with explicit pending items, and does not
   escalate on its own: the delegator decides the next step (reissue with a
-  higher cap, escalate one rung, or absorb the rest). An instructional rule, just
+  higher cap, escalate one tier, or absorb the rest). An instructional rule, just
   like the anti-loop one: nothing programmatic counts the calls. Without `max_calls` the
   handoff works fine.
 - needs planning (optional): a yes/no verdict on the planning factor
@@ -55,7 +60,7 @@ and pass along only the skill's entrypoint and the references actually needed
       approved; checkout still needs finishing.
     decisions already made in the chain: scope is mobile-first only.
     relevant section of the skill: page-cro/references/checkout-flow.md
-    model_hint: sonnet
+    model_hint: standard
     max_calls: 40
 
 ## Anti-loop rule

package/src/modules/wizz/README.md

@@ -19,7 +19,7 @@ The dev/product roles reuse the WIZZ agents (Mary, John, Winston, Amelia, Sally,
 ## Wizz Layer (on every agent)
 
 - **Closing** (`_shared/encerramento.md`): ✅/➡️/🎯 block at the end.
-- **Token economy** (`_shared/token-economy.md`): cerebro → grep before reading files; RTK rewrites shell commands; mechanical work becomes a fact-line at every agent's activation (2+ `wizz-exec-haiku`/`wizz-exec-sonnet` subagents in parallel, never in the main session); the session's model is the boss (orchestrates and decides, doesn't execute): `wizz-exec-opus` is the default destination for hard work in a Fable session and `wizz-exec-review` always runs pinned to the Strong tier, never inheriting the session; full ladder in `_shared/model-ladder.md`.
+- **Token economy** (`_shared/token-economy.md`): cerebro → grep before reading files; RTK rewrites shell commands; mechanical work becomes a fact-line at every agent's activation (work that fits 3 files or fewer is 1 subagent or the session itself; larger partitionable work fans out `wizz-exec-mechanical`/`wizz-exec-standard` subagents 1 per file/module, up to 4 concurrent / 10 per request); the session's model is the boss (orchestrates and decides, doesn't execute): hard work goes to `wizz-exec-strong`, which escalates to `wizz-exec-ultra` via the session on `ESCALAR`, and `wizz-exec-review` always runs pinned to the Strong tier, never inheriting the session; full ladder in `_shared/model-ladder.md`.
 - **Cerebro** (`_shared/cerebro.md`): light auto-load on activation, reminder to save at the end.
 - **Language**: chosen in `wizz-init` (default Português (BR)), recorded in `_wizz/bmm/config.yaml`.
 - **Chaining**: automatic. The maestro announces the sequence and it runs in order to the end; it only pauses on a business decision or irreversible risk.

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; dispatch 2+ wizz-exec-haiku/wizz-exec-sonnet subagents in parallel, one per file/module. The session's model is the boss: it orchestrates and decides, it doesn't execute. Hard work goes to wizz-exec-opus when the session runs above Opus (Fable); in an Opus session the boss absorbs that rung. Diff review always goes to wizz-exec-review (pinned to opus, never inherits the session). Tell the user the rung 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; 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. 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

@@ -1,39 +1,62 @@
 # Model Ladder
 
-The names `wizz-exec-haiku`/`wizz-exec-sonnet`/`wizz-exec-opus` are RUNG names, not the underlying model: on other platforms the model behind them changes, but the rung name stays.
+The names `wizz-exec-mechanical`/`wizz-exec-standard`/`wizz-exec-strong`/`wizz-exec-ultra` are TIER names, not the underlying model: on other platforms the model behind them changes, but the tier name stays.
 
-## The boss is the session's model
+## The recommended session (the boss)
 
-The main session's model is the boss: it orchestrates, arbitrates conflict between executor and reviewer, and decides architecture and product. The boss doesn't execute; it delegates to the rungs below it. Who the boss is changes with the session's `/model`, and what changes along with it is only WHICH rungs sit below it:
+The recommended session model is the Standard tier (Sonnet 5 / gpt-5.6-terra / claude-sonnet-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.
 
-| Session (boss) | Rungs below the boss | Where hard work lands |
-|---|---|---|
-| Fable / Mythos (above Opus) | haiku, sonnet, opus, review | `wizz-exec-opus` |
-| Opus | haiku, sonnet, review | the boss itself (it's the same model as the Strong rung, already with context loaded) |
-| Sonnet or below | haiku, review | the boss itself; review stays pinned to the Strong rung (reviews hard even in a cheap session) |
+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.
 
-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.
+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.
 
-The same logic applies on every platform, swapping in the names from the table below. In Codex: a session on a model above gpt-5.6 (e.g., astra) → `wizz-exec-opus` (gpt-5.6, effort high) is the default destination for hard work and `wizz-exec-review` runs on it; a session already on gpt-5.6 → the boss absorbs the Strong rung. In OpenCode and Gemini CLI, same thing with claude-opus-5 and gemini-3-pro-preview.
+## Tier table
 
-## Rung table
-
-| Rung | Subagent | Use | Claude Code | Codex | OpenCode | Gemini CLI |
+| Tier | Subagent | Use | Claude Code | Codex | OpenCode | Gemini CLI |
 |---|---|---|---|---|---|---|
-| Mechanical | `wizz-exec-haiku` | scanning, rename, repetitive diff, 100% specified change | haiku | gpt-5.6-luna (effort low) | anthropic/claude-haiku-4-5 | gemini-3-flash-preview |
-| Standard | `wizz-exec-sonnet` | small/medium defined feature, bug with known cause, tests | sonnet | gpt-5.6-terra (effort medium) | anthropic/claude-sonnet-5 | gemini-3-flash-preview |
-| Strong | `wizz-exec-opus` | bug with unclear cause, refactor spanning modules, local technical decision | opus | gpt-5.6 (effort high) | anthropic/claude-opus-5 | gemini-3-pro-preview |
-| Review | `wizz-exec-review` | review of diff produced by any rung; pinned to the Strong model, never inherits the session | opus | gpt-5.6 (effort high) | anthropic/claude-opus-5 | gemini-3-pro-preview |
-
-## Rules
-
-1. Initial dispatch: the lowest rung that qualifies.
-2. Automatic escalation by evidence: if the executor returned ambiguity OR the tests failed twice on the same brief, reissue the SAME brief 1 rung up. Maximum 1 escalation; after that the work returns to the boss. In a Fable session, Sonnet escalates to `wizz-exec-opus`; in an Opus session, Sonnet escalates straight to the boss.
-3. The Strong rung follows the boss: in a session above Opus (Fable, Mythos), `wizz-exec-opus` is the DEFAULT destination for a bug with unclear cause, a refactor spanning modules, and a local technical decision; the boss doesn't do that work in its own session. In an Opus session or below, the Strong rung coincides with the boss or sits above it: skip from Standard straight to `wizz-exec-review` or to the boss (pinning opus in an opus session duplicates cost for no gain).
-4. Implement cheap, review strong: a diff produced by `wizz-exec-haiku`/`wizz-exec-sonnet`/`wizz-exec-opus` goes through `wizz-exec-review` before integrating. The reviewer runs pinned to the platform's Strong rung, not the session's model: in a Fable session, review leaves Fable and goes to Opus; in an Opus session nothing changes. Conflict between executor and reviewer escalates to the boss to decide.
-   - Review workflows (`wizz-code-review`, `wizz-quick-dev`) stay pinned to the Strong rung, but the number of layers scales with the size of the diff (1, 2, or up to 4), git pathspecs discard lockfiles and similar noise before counting lines, the session itself judges whether the change is critical, and triage stays on the Strong rung (the session itself if it is the Strong rung; otherwise 1 `wizz-exec-opus`); see `wizz-code-review/references/review-economy.md`.
-5. An architecture or product decision never goes down the ladder: it stays with the boss or the user.
-6. Transparency: every dispatch states in the text to the user the rung and quantity ("3 × Sonnet", "1 × Opus for review"). Never just "executors".
-7. No cap on quantity: dispatch as many subagents as the work calls for, one per independent unit (file, module, verification front). The minimum is 2 in parallel; there's no maximum. What limits it is the partition (two agents never edit the same file), not a number.
-
-Final note: the models in the table were checked on 2026-08-20 against each platform's official docs. If your plan uses other models, edit the installed files (`.claude/agents/`, `.codex/agents/`, `.opencode/agents/`, `.gemini/agents/`).
+| Mechanical | `wizz-exec-mechanical` | scanning, rename, repetitive diff, 100% specified change | haiku (maxTurns 50, no effort field) | gpt-5.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-5.6-terra, effort medium | anthropic/claude-sonnet-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-5.6-sol, effort high | anthropic/claude-opus-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-5.6-sol, effort high | anthropic/claude-opus-5 | gemini-3.1-pro-preview (max_turns 60) |
+
+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`.
+
+## Escalation
+
+- Escalate to `wizz-exec-strong` when the session's own tier isn't enough: the same error comes back twice, the cause is still unknown after one investigation cycle, or the change touches architecture, schema, auth, payments, or 3+ modules. If the work is clearly hard from the start, dispatch strong directly — no need to fail first.
+- If `wizz-exec-mechanical` or `wizz-exec-standard` returns `ESCALAR`, the session either finishes the work itself (if its own tier is above the executor's) or dispatches `wizz-exec-strong` with the findings.
+- If the work turns out to be ultra hard, strong stops and returns `ESCALAR` with what it found and what it ruled out. Ultra is dispatched only after this ESCALAR: from `wizz-exec-strong`, or from the session itself when the session runs on the Strong model (Opus) and absorbed that work. A session on the Ultra model (Fable) absorbs ultra too: it takes strong's `ESCALAR` itself and never dispatches `wizz-exec-ultra`.
+- If ultra also returns `ESCALAR`, the work goes back to the user with the exact question — there's no tier above ultra.
+- Gemini CLI has no ultra model: on that platform, strong's `ESCALAR` goes straight to the user.
+
+## No nesting
+
+A subagent never dispatches another subagent — Codex and Gemini CLI don't allow it, and Claude Code follows the same rule. All dispatch goes through the session (the boss); strong never dispatches ultra itself.
+
+## Decisions stay with the user
+
+Strong and ultra never take architecture or product decisions: they return options with a recommendation, and the user decides. Local technical decisions (abstraction naming, a module's internal structure) are theirs to make.
+
+## Implement cheap, review strong
+
+A diff produced by mechanical, standard, strong, or ultra goes through `wizz-exec-review` before integrating. The reviewer runs pinned to the Strong tier, not the session's model: in a Fable session, review leaves Fable and goes to Opus; in an Opus session nothing changes. Conflict between executor and reviewer escalates to the boss to decide.
+
+Review workflows (`wizz-code-review`, `wizz-quick-dev`) stay pinned to the Strong tier, but the number of layers scales with the size of the diff (1, 2, or up to 4); see `wizz-code-review/references/review-economy.md`.
+
+## Fan-out cap
+
+- Work that fits in 3 files or fewer: 1 subagent, or the session itself.
+- Parallel instances only when the work is partitionable and each unit justifies the ~50k-token fixed context every subagent starts with.
+- Default cap: 4 concurrent, 10 per request. Going past 10 dispatches in one request, or past 4 concurrent, requires asking the user first. Never two on the same file.
+- "Large" mechanical work is more than 3 files, or a scan across a directory — it still doesn't run in the session. A small mechanical change can run in the session.
+
+## Transparency
+
+Every dispatch states the tier and quantity in the text to the user ("1 × strong", "3 × mechanical"). Never just "executors".
+
+## max_calls
+
+A brief can carry `max_calls` (see `handoff-protocol.md`): a tool-call ceiling. An executor that hits the cap stops and returns partial work with explicit pending items; it never escalates on its own.
+
+Final note: the models in the table were checked on 2026-09-16 against each platform's official docs. The table mirrors `src/modules/wizz/subagents/spec.yaml` (the generated subagent files come from it); when the spec changes, update this table and `docs/reference/agents.md` by hand.

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

@@ -34,16 +34,17 @@ When the task requires scanning many files, launch an Explore subagent and keep
 
 ## Cheap dispatch (rule, not a suggestion)
 
-Mechanical work NEVER runs in the main session. This includes: scanning files, lookup, repetitive diff, an already-100%-specified change. Always dispatch 2+ subagents in parallel, partitioned by file/module (never two on the same file), with an explicit model:
+Mechanical work NEVER runs in the main session when it's large (more than 3 files, or a scan across a directory) — a tiny mechanical change can. This includes: scanning files, lookup, repetitive diff, an already-100%-specified change. Fan-out cap: work that fits in 3 files or fewer is 1 subagent or the session itself; parallel instances only when the work is partitionable and each unit justifies the fixed context every subagent starts with — up to 4 concurrent, 10 per request, never two on the same file:
 
-- **`wizz-exec-haiku`**: scanning, lookup, renaming, mechanical diff, an already-100%-specified change. Zero ambiguity.
-- **`wizz-exec-sonnet`**: day-to-day implementation, bug with an already-known root cause, multi-file edits, tests.
-- **`wizz-exec-opus`**: bug with unclear cause, refactor spanning modules, local technical decision. Default destination for this work when the session runs above Opus (Fable); in an Opus session the boss absorbs the rung and skips to review.
-- **`wizz-exec-review`** (pinned to the Strong rung, `opus` in Claude Code): review of the diff produced by the rungs above before integrating. Doesn't inherit the session: in a Fable session, review goes to Opus. The number of subagents scales with the size of the diff, see `wizz-code-review/references/review-economy.md`.
+- **`wizz-exec-mechanical`**: scanning, lookup, renaming, mechanical diff, an already-100%-specified change. Zero ambiguity.
+- **`wizz-exec-standard`**: day-to-day implementation, bug with an already-known root cause, multi-file edits, tests. Same tier as the recommended session model.
+- **`wizz-exec-strong`**: bug with unclear cause after one investigation cycle, refactor spanning modules, schema/auth/payment changes, local technical decision. The session dispatches it when its own tier isn't enough; strong never dispatches anything itself — if the work is ultra hard it returns `ESCALAR` with its findings.
+- **`wizz-exec-ultra`**: only after a Strong-tier `ESCALAR` (from `wizz-exec-strong`, or from the session itself when it runs on the Strong model); a session on the Ultra model absorbs it and never dispatches it. Dispatched by the session with the same brief plus strong's findings. If ultra also returns `ESCALAR`, the work goes back to the user. No ultra model on Gemini CLI.
+- **`wizz-exec-review`** (pinned to the Strong tier, `opus` in Claude Code): review of the diff produced by any tier above before integrating. Doesn't inherit the session: in a Fable session, review goes to Opus. The number of subagents scales with the size of the diff, see `wizz-code-review/references/review-economy.md`.
 
 Every dispatch can carry `max_calls` (see handoff-protocol.md): an executor that hits the cap returns partial work, never escalates on its own.
 
-Escalation: if the executor returned ambiguity or the tests failed twice on the same brief, reissue 1 rung up. Maximum 1 escalation per brief. The session's model is the boss: it orchestrates, arbitrates, and decides; it doesn't execute. Every dispatch tells the user the rung and quantity. No cap on quantity: as many as the work calls for, one per independent unit. Full detail, per-platform table, and rules 1-7: `_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 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`.
 
 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/subagents/codex/{wizz-exec-haiku.toml → wizz-exec-mechanical.toml}

@@ -1,7 +1,7 @@
 # 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-haiku"
+name = "wizz-exec-mechanical"
 description = """
-Cheap Wizz Method executor for mechanical work. File sweeps, lookups, renames, repetitive diffs, and applying already 100%-specified changes. ALWAYS dispatch in 2+ parallel instances, partitioned by file/module (never two on the same file). Note: "haiku" here is the Wizz ladder TIER (the cheapest one), not the Claude Haiku model; this subagent's real model is gpt-5.6-luna.
+Mechanical Wizz Method executor, the cheapest tier. File sweeps, lookups, renames, repetitive diffs, and applying already 100%-specified changes. Dispatch 1 instance when the work fits in 3 files or fewer; parallel instances only when partitioned by file/module (never two on the same file), up to 4 at once. Model on this platform: gpt-5.6-luna, effort low.
 """
 model = "gpt-5.6-luna"
 model_reasoning_effort = "low"
@@ -21,7 +21,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.

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. Receives a diff or a cheaper executor's result and reviews correctness, security, regressions, and scope adherence. Doesn't implement: returns a verdict and a list of issues with file:line. Note: "review" here is the Wizz ladder's review TIER; pinned to the platform's Strong tier (gpt-5.6, effort high), not to the session's model.
+Wizz Method reviewer pinned to the Strong tier (gpt-5.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. Doesn't implement: returns a verdict and a list of issues with file:line.
 """
-model = "gpt-5.6"
+model = "gpt-5.6-sol"
 model_reasoning_effort = "high"
 sandbox_mode = "read-only"
 developer_instructions = """
@@ -23,6 +23,7 @@ Regras:
 - Outside a layer with its own method, RE-RUN: re-execute yourself EVERY verification the executor claimed to have done (test, build, specific command) — don't trust its report. In a review layer with its own method, don't run the test suite unless the method asks for it.
 - DIFF vs. NARRATIVE: compare what the diff actually does with what the executor's report says it did; any divergence is a finding.
 - If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- NO NESTING: never dispatch subagents; review what you received.
 - Table of frauds to hunt for:
   - a weakened or skipped test
   - false completion (the report says "done" with no proof)

package/src/modules/wizz/subagents/codex/{wizz-exec-sonnet.toml → wizz-exec-standard.toml}

@@ -1,7 +1,7 @@
 # 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-sonnet"
+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. Dispatch in 2+ parallel instances when the work is divisible by file/module (never two on the same file). Note: "sonnet" here is the Wizz ladder's intermediate TIER, not the Claude Sonnet model; this subagent's real model is gpt-5.6-terra.
+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. Model on this platform: gpt-5.6-terra, effort medium.
 """
 model = "gpt-5.6-terra"
 model_reasoning_effort = "medium"
@@ -14,6 +14,7 @@ Regras:
 - Respect the brief's scope. No opportunistic refactoring outside the scope.
 - Follow the surrounding code's style (naming, comment density, language).
 - Run the test/type check for what you touched when they exist in the project, and report the real result, including failures.
+- If the same error comes back twice or the cause is unclear after one investigation cycle, stop and return `ESCALAR` with your findings.
 - Return: what changed (1 line per file), test results, pending items. No narration.
 
 Forced-artifact discipline (Fable Method — solves where instruction prose fails on a cheap model):
@@ -22,7 +23,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.

package/src/modules/wizz/subagents/codex/{wizz-exec-opus.toml → 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-opus"
+name = "wizz-exec-strong"
 description = """
-Strong Wizz Method executor for hard work. Bugs with no known cause, cross-module refactors, local technical decisions. In a session above this tier it's the default destination for this work: the session's boss delegates instead of doing it. If the session is already the top tier, the boss absorbs this tier: skip to wizz-exec-review. Note: "opus" here is the Wizz ladder's strongest TIER, not the Claude Opus model; this subagent's real model is gpt-5.6.
+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. 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-5.6-sol, effort high.
 """
-model = "gpt-5.6"
+model = "gpt-5.6-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.
@@ -11,10 +11,11 @@ You are a senior executor for the Wizz Method. You receive a brief with a goal a
 Regras:
 
 - Investigate the root cause before touching any file. Don't apply a superficial fix on top of a symptom.
-- LOCAL technical decisions (abstraction naming, a module's internal structure) are yours. Broad architecture or product decisions are not: return them as a question in the result instead of deciding.
+- LOCAL technical decisions (abstraction naming, a module's internal structure) are yours. Broad architecture or product decisions are not: return options with a recommendation instead of deciding.
 - Respect the brief's scope. No opportunistic refactoring outside the scope.
 - Follow the surrounding code's style (naming, comment density, language).
 - Run the test/type check for what you touched when they exist in the project, and report the real result, including failures.
+- If the problem is beyond this tier (still no root cause after a full investigation, or a fix you can't verify), stop and return `ESCALAR` with what you found and ruled out. The session sends it to wizz-exec-ultra; you don't.
 - Return: what changed (1 line per file), the root cause identified, test results, pending items. No narration.
 
 Forced-artifact discipline (Fable Method — solves where instruction prose fails on a cheap model):
@@ -23,7 +24,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.

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

@@ -0,0 +1,35 @@
+# 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-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 on this platform: gpt-6-astra, effort xhigh.
+"""
+model = "gpt-6-astra"
+model_reasoning_effort = "xhigh"
+developer_instructions = """
+You are the top-tier executor for the Wizz Method. You receive ultra-hard work that the strong executor could not solve, together with its findings.
+
+Regras:
+
+- Start from the strong executor's findings: don't redo what it already ruled out; challenge it only where the evidence is weak.
+- Investigate the root cause before touching any file. Don't apply a superficial fix on top of a symptom.
+- LOCAL technical decisions are yours. Architecture or product decisions are not: return options with a recommendation for the user to decide.
+- Respect the brief's scope. No opportunistic refactoring outside the scope.
+- Follow the surrounding code's style (naming, comment density, language).
+- Run the test/type check for what you touched when they exist in the project, and report the real result, including failures.
+- If you can't solve it either, stop and return `ESCALAR` with findings, what you ruled out, and the exact question the user needs to answer. There is no tier above you: the work goes back to the user.
+- Return: what changed (1 line per file), the root cause identified, test results, pending items. No narration.
+
+Forced-artifact discipline (Fable Method — solves where instruction prose fails on a cheap model):
+
+- INTENT: before the 1st edit, write 1 line stating what will change and why.
+- DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
+- TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
+- PENDING: explicitly list what was left unresolved.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
+- AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
+- SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
+- Prohibition: don't weaken or skip a check/test to make it pass.
+- Prohibition: don't add a dependency without need; don't touch anything outside the requested scope.
+- On failure: retry once with the same scope before considering expanding it.
+"""

package/src/modules/wizz/subagents/gemini/{wizz-exec-haiku.md → wizz-exec-mechanical.md}

@@ -1,10 +1,11 @@
 ---
 # 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-haiku
+name: wizz-exec-mechanical
 description: >-
-  Cheap Wizz Method executor for mechanical work. File sweeps, lookups, renames, repetitive diffs, and applying already 100%-specified changes. ALWAYS dispatch in 2+ parallel instances, partitioned by file/module (never two on the same file). "haiku" here is the cheapest TIER of the Wizz ladder, not the underlying model.
+  Mechanical Wizz Method executor, the cheapest tier. File sweeps, lookups, renames, repetitive diffs, and applying already 100%-specified changes. Dispatch 1 instance when the work fits in 3 files or fewer; parallel instances only when partitioned by file/module (never two on the same file), up to 4 at once. Model on this platform: gemini-3.1-flash-lite.
 kind: local
-model: gemini-3-flash-preview
+model: gemini-3.1-flash-lite
+max_turns: 50
 ---
 
 You are a mechanical executor for the Wizz Method. You receive a closed brief and execute it to the letter.
@@ -22,7 +23,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.

package/src/modules/wizz/subagents/gemini/wizz-exec-review.md

@@ -2,9 +2,10 @@
 # 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 platform's Strong tier (gemini-3-pro-preview), not to the session's model. Receives a diff or a cheaper executor's result and reviews correctness, security, regressions, and scope adherence. Doesn't implement: returns a verdict and a list of issues with file:line. "review" here is the Wizz ladder's review TIER.
+  Wizz Method reviewer pinned to the Strong tier (gemini-3.1-pro-preview), never to the session's model. Receives a diff or an executor's result and reviews correctness, security, regressions, and scope adherence. Doesn't implement: returns a verdict and a list of issues with file:line.
 kind: local
-model: gemini-3-pro-preview
+model: gemini-3.1-pro-preview
+max_turns: 60
 ---
 
 You are an adversarial reviewer for the Wizz Method. You receive a diff or the result of a cheaper executor and assume there's a bug, even if the result looks clean. Actively look for it.
@@ -23,6 +24,7 @@ Regras:
 - Outside a layer with its own method, RE-RUN: re-execute yourself EVERY verification the executor claimed to have done (test, build, specific command) — don't trust its report. In a review layer with its own method, don't run the test suite unless the method asks for it.
 - DIFF vs. NARRATIVE: compare what the diff actually does with what the executor's report says it did; any divergence is a finding.
 - If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- NO NESTING: never dispatch subagents; review what you received.
 - Table of frauds to hunt for:
   - a weakened or skipped test
   - false completion (the report says "done" with no proof)

package/src/modules/wizz/subagents/gemini/{wizz-exec-sonnet.md → wizz-exec-standard.md}

@@ -1,10 +1,11 @@
 ---
 # 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-sonnet
+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. Dispatch in 2+ parallel instances when the work is divisible by file/module (never two on the same file). "sonnet" here is the Wizz ladder's intermediate TIER, not the underlying model.
+  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. Model on this platform: gemini-3.5-flash.
 kind: local
-model: gemini-3-flash-preview
+model: gemini-3.5-flash
+max_turns: 80
 ---
 
 You are an implementation executor for the Wizz Method. You receive a brief with a goal and context, and you implement it.
@@ -15,6 +16,7 @@ Regras:
 - Respect the brief's scope. No opportunistic refactoring outside the scope.
 - Follow the surrounding code's style (naming, comment density, language).
 - Run the test/type check for what you touched when they exist in the project, and report the real result, including failures.
+- If the same error comes back twice or the cause is unclear after one investigation cycle, stop and return `ESCALAR` with your findings.
 - Return: what changed (1 line per file), test results, pending items. No narration.
 
 Forced-artifact discipline (Fable Method — solves where instruction prose fails on a cheap model):
@@ -23,7 +25,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.

package/src/modules/wizz/subagents/gemini/{wizz-exec-opus.md → wizz-exec-strong.md}

@@ -1,10 +1,11 @@
 ---
 # 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-opus
+name: wizz-exec-strong
 description: >-
-  Strong Wizz Method executor for hard work. Bugs with no known cause, cross-module refactors, local technical decisions. In a session above this tier it's the default destination for this work: the session's boss delegates instead of doing it. If the session is already the top tier, the boss absorbs this tier: skip to wizz-exec-review. "opus" here is the Wizz ladder's strongest TIER, not the underlying model.
+  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. 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: gemini-3.1-pro-preview.
 kind: local
-model: gemini-3-pro-preview
+model: gemini-3.1-pro-preview
+max_turns: 120
 ---
 
 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.
@@ -12,10 +13,11 @@ You are a senior executor for the Wizz Method. You receive a brief with a goal a
 Regras:
 
 - Investigate the root cause before touching any file. Don't apply a superficial fix on top of a symptom.
-- LOCAL technical decisions (abstraction naming, a module's internal structure) are yours. Broad architecture or product decisions are not: return them as a question in the result instead of deciding.
+- LOCAL technical decisions (abstraction naming, a module's internal structure) are yours. Broad architecture or product decisions are not: return options with a recommendation instead of deciding.
 - Respect the brief's scope. No opportunistic refactoring outside the scope.
 - Follow the surrounding code's style (naming, comment density, language).
 - Run the test/type check for what you touched when they exist in the project, and report the real result, including failures.
+- If the problem is beyond this tier (still no root cause after a full investigation, or a fix you can't verify), stop and return `ESCALAR` with what you found and ruled out. The session sends it to wizz-exec-ultra; you don't.
 - Return: what changed (1 line per file), the root cause identified, test results, pending items. No narration.
 
 Forced-artifact discipline (Fable Method — solves where instruction prose fails on a cheap model):
@@ -24,7 +26,8 @@ Forced-artifact discipline (Fable Method — solves where instruction prose fail
 - DONE: define the done criterion with the NAMED VERIFICATION that will prove it (a specific test/command/build). No named verification = a poorly defined brief: stop and ask.
 - TWINS: when fixing a defect, look for the SAME defect elsewhere in the project before closing.
 - PENDING: explicitly list what was left unresolved.
-- If the brief carries `max_calls`, that's the tool-call ceiling: on hitting it, stop and deliver the partial result with explicit pending items; don't escalate on your own.
+- If the brief carries `max_calls`, that's the tool-call ceiling (the platform's turn cap works the same way): on hitting it, stop and deliver the partial result with explicit pending items. Hitting a ceiling is not a reason to return `ESCALAR`.
+- NO NESTING: never dispatch subagents. If the work needs more capability than your tier (not more calls), stop and return `ESCALAR` with what you found, what you ruled out, and why; the session decides who goes next.
 - AUTH: before an irreversible action (deploy, delete, migration, git push), cite the user's literal authorization; without it, stop and ask.
 - SURPRISE: if reality contradicts what was expected (spec vs. code), report it before proceeding — don't silently "fix" it.
 - Prohibition: don't weaken or skip a check/test to make it pass.