wizz-method 2.5.0 → 2.7.0

package/package.json

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

package/skills-registry.yaml

@@ -164,6 +164,43 @@ areas:
         # Pin de supply chain (2026-08-23): clone temporário + checkout do SHA
         # + `skills add` local. Atualizar conscientemente.
         install: 'd="$(mktemp -d)" && git clone https://github.com/bradautomates/claude-video.git "$d" && git -C "$d" checkout 83da59fa78c3eee9e20f515fe75c438bb5166efd && npx skills add "$d" -g -y --copy && printf "%s\\n" 83da59fa78c3eee9e20f515fe75c438bb5166efd > "$HOME/.claude/skills/watch/.wizz-pin" && rm -rf "$d"'
+      - id: get-brolls
+        # Versão que o SKILL.md do upstream declara no SHA pinado abaixo. A
+        # última tag publicada lá é a v2.3.7; o 2.3.8 só existe como HEAD.
+        metadata:
+          version: "2.3.8"
+        when: "CAPTAR B-roll/insert: acha a fonte LITERAL do que a narração cita (o fato, a pessoa, o produto, a notícia, a tela) em YouTube (yt-dlp, sem API key), Instagram/TikTok (navegador/Playwright, sessão do usuário), Pexels/Pixabay/Wikimedia Commons/NASA ou arquivo local; gera prévia (poster, contact sheet numerado, GIF), monta um Storyboard HTML para REVISÃO HUMANA e entrega o corte com origem/autor/condições de uso registrados. Etapa de CAPTAÇÃO do pipeline de vídeo: enche a timeline de material real antes do corte fino e da montagem. Stock só quando o usuário pedir stock explicitamente — nunca como preenchimento de um beat sem fonte literal."
+        not_when:
+          - "Analisar/resumir um vídeo que já se tem em mãos: é claude-video."
+          - "Cortar/montar footage já captado: é buttercut (corte fino) ou wizz-remotion-best-practices (montagem final)."
+          - "Gerar imagem/vídeo por IA: é fal-video. O get-brolls busca material REAL, não sintético."
+          - "Desenhar uma tela/cena em HTML: é hyperframes."
+          - "Minerar/estudar criativo ou oferta de concorrente (Biblioteca de Anúncios, 'baixa esse anúncio pra eu ver'): é wizz-lowticket-minerador na área ads. O get-brolls capta insert para a SUA edição, com procedência registrada — não é ferramenta de inteligência competitiva, e o fato de saber baixar um Reel não o torna uma."
+        rel:
+          before: [buttercut, wizz-remotion-best-practices]
+          pairs_with: [claude-video]
+        # macOS apenas: o upstream declara macOS/Windows (Linux não é testado lá)
+        # e o `install` daqui é POSIX. Windows fica fora porque o installer do
+        # Wizz não roda nele — quem estiver no Windows segue o README do upstream.
+        platform: [darwin]
+        # O check confere o SHA fixado, não só a existência da pasta: o bundle é
+        # copiado (não clonado), então o pin é gravado num marcador no install.
+        check: 'grep -qx 3d2313b0b856594617371697875ccfd59861c693 "$HOME/.claude/skills/get-brolls/.wizz-pin" 2>/dev/null'
+        # Pin de supply chain (2026-09-17): clone temporário + checkout do SHA
+        # + `skills add` global + o `install.sh` do próprio upstream (cria .venv
+        # e .tools DENTRO da skill: yt-dlp fixado, EJS e Playwright CLI). O
+        # upstream documenta 2.3.8 mas a última tag publicada é v2.3.7, então o
+        # pin é o SHA do HEAD de 2026-09-17 (mesmo caso do apple-design).
+        # Atualizar conscientemente. O install.sh aborta sozinho se faltar
+        # python3/ffmpeg/node 22+; sem pin gravado, o installer volta a oferecer.
+        # Escopo GLOBAL (-g) de propósito: a skill guarda .venv/.tools/.env na
+        # própria raiz e recebe o projeto por `--project`, então é instalar uma
+        # vez e usar em todos — igual hyperframes e claude-video.
+        install: 'd="$(mktemp -d)" && git clone https://github.com/engenheirodevideo/get-brolls.git "$d" && git -C "$d" checkout 3d2313b0b856594617371697875ccfd59861c693 && npx skills add "$d" -g -y --copy && bash "$HOME/.claude/skills/get-brolls/scripts/install.sh" && printf "%s\\n" 3d2313b0b856594617371697875ccfd59861c693 > "$HOME/.claude/skills/get-brolls/.wizz-pin" && rm -rf "$d"'
+        # Sem drawtext (libfreetype) o contact sheet sai sem número e timecode e
+        # o Storyboard degrada EM SILÊNCIO — por isso o probe olha o filtro, não
+        # só o binário do ffmpeg. A venv prova que o install.sh chegou ao fim.
+        verify: 'command -v ffmpeg >/dev/null 2>&1 && ffmpeg -hide_banner -filters 2>/dev/null | grep -q " drawtext " && test -x "$HOME/.claude/skills/get-brolls/.venv/bin/python"'
       - id: buttercut
         when: "EDITAR vídeo por IA: cortes, selects, cenas, roughcut via XML/FFmpeg. Sugerir quando o pedido for editar/cortar vídeo. Clone-and-run no PROJETO (não é skill add), pesado: Ruby + Python + FFmpeg + WhisperX. AVISOS: ~GB de modelos (WhisperX), build demorado, só Apple Silicon."
         platform: darwin-arm64

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/_shared/video-pipeline.md

@@ -22,6 +22,7 @@
 | Assemble the film: sequence of scenes + narration + SFX + captions + frame timing | **Remotion** (skill `wizz-remotion-best-practices`) |
 | Word-by-word timestamps of the TTS narration (sync captions/cuts/animation) | `ctc-align` |
 | Narration / voice / TTS / voice cloning | `voicebox` |
+| **Source B-roll / inserts: find real footage of what the script names** | `get-brolls` (darwin) |
 | Edit/cut recorded footage (cuts, selects, roughcut) | `buttercut` (darwin-arm64 only) |
 | Analyze an existing reference video (frames + transcription) | `claude-video` |
 | AI-generated video ad (Sora/Veo/Kling) + publish to Meta | `arcads` (ads area) |
@@ -34,10 +35,22 @@
    (single source of timing; replaces Whisper and manual estimation).
 4. **Screens** — `hyperframes` draws each visual scene, SILENT, isolated
    (one composition per scene avoids CSS leaking between screens).
-5. **Assembly** — **Remotion** joins the exported scenes, adds audio, SFX, and
-   captions at the ctc-align timestamps, with frame precision.
-6. **Fine cut** (if there's recorded footage) — `buttercut`.
-7. **Publishing/distribution** — social/ads area.
+5. **B-roll / inserts** — `get-brolls` sources the REAL footage the script names
+   (the fact, the person, the product, the news item, the screen), builds previews
+   and a Storyboard, waits for the human to approve, and only then delivers the cut
+   with its provenance recorded. Runs in parallel with steps 2–4: it depends on the
+   script, not on the voice. **This step has a human gate — the agent never
+   self-approves.**
+6. **Assembly** — **Remotion** joins the exported scenes and the approved B-roll,
+   adds audio, SFX, and captions at the ctc-align timestamps, with frame precision.
+7. **Fine cut** (if there's recorded footage) — `buttercut`.
+8. **Publishing/distribution** — social/ads area.
+
+**Screens vs. B-roll — they are not interchangeable.** `hyperframes` invents a
+visual (a mockup, a chart, a title); `get-brolls` finds the real thing that the
+narration cites. A script that says "Nvidia's CEO announced" wants the actual
+footage, not a drawn card with his name on it. Reach for `hyperframes` when
+there is nothing real to show; reach for `get-brolls` when there is.
 
 ## Anti-patterns (don't do this)
 
@@ -46,3 +59,15 @@
   isolation between them.
 - Don't migrate a working Remotion composition to HyperFrames "to standardize":
   the pipeline direction is screens in HyperFrames, film in Remotion.
+- Don't fill a beat with generic stock just to hit a clip count. `get-brolls`
+  searches for the literal source first; stock (Pexels/Pixabay) only enters when
+  the user explicitly asks for stock.
+- Don't approve your own B-roll. `get-brolls approve` records a decision a human
+  already made; the agent serves the Storyboard and waits. Changing the clip's
+  in/out range or its context invalidates an approval that was already given.
+- Don't describe frames you didn't look at. The contact sheet exists to be opened
+  and read before the clip goes into the cut.
+- Don't publish signed URLs or the private `_video.conf`/`_audio.conf` pairs that
+  the Instagram route writes, and don't invent a licence: `permit --evidence`
+  records the real terms. Responsibility for the terms of use sits with whoever
+  produces the video; the skill answers for fidelity and for the provenance record.

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

@@ -25,7 +25,7 @@ You are Wizz's Designer. It creates high-level interfaces and landing pages, sho
 
 ## How I work (bridge to global skills)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`designer`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/designer.yaml` (already comes as the full `areas.designer` block — skills/mcps/clis/references); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.designer` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), also read `{project-root}/_wizz/_config/registry/_shared.yaml`. Route by the `when:` field — `skills:` (invoke via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:` — e.g. `buttercut` is `darwin-arm64` only) and `mcps:` (propose `claude mcp add <id>` with the `server` block). **Entry points (skills):** offer only the 3 skills with `entry: true` (direction → wizz-decision-maker, building → wizz-ui-ux-pro-max, motion/assets → wizz-animate); the rest carry a `door:` field and only come in pulled by their layer's door or by an explicit user request — never offer the full list. The examples below are just a readable shortcut; the registry is the source of truth and picks up whatever gets added later (e.g. video tools: hyperframes, claude-video, buttercut, voicebox, ctc-align). **Video:** before choosing a tool, apply `_shared/video-pipeline.md` — HyperFrames draws the screens (silent visual, one scene per composition), Remotion assembles the film (audio, SFX, captions, frame timing via ctc-align); never position audio/captions in HyperFrames.
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`designer`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/designer.yaml` (already comes as the full `areas.designer` block — skills/mcps/clis/references); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.designer` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), also read `{project-root}/_wizz/_config/registry/_shared.yaml`. Route by the `when:` field — `skills:` (invoke via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:` — e.g. `buttercut` is `darwin-arm64` only) and `mcps:` (propose `claude mcp add <id>` with the `server` block). **Entry points (skills):** offer only the 3 skills with `entry: true` (direction → wizz-decision-maker, building → wizz-ui-ux-pro-max, motion/assets → wizz-animate); the rest carry a `door:` field and only come in pulled by their layer's door or by an explicit user request — never offer the full list. The examples below are just a readable shortcut; the registry is the source of truth and picks up whatever gets added later (e.g. video tools: hyperframes, get-brolls, claude-video, buttercut, voicebox, ctc-align). **Video:** before choosing a tool, apply `_shared/video-pipeline.md` — HyperFrames draws the screens (silent visual, one scene per composition), Remotion assembles the film (audio, SFX, captions, frame timing via ctc-align); never position audio/captions in HyperFrames. **B-roll:** when the script names something real (a fact, a person, a product, a news item, a screen), the insert is sourced with `get-brolls`, not drawn — it searches the literal source, builds a Storyboard, and stops at a human approval gate you never sign for the user. Stock only enters if the user asks for stock.
 
 For every task, **go through the right door via the `Skill` tool** and bring the result in plain language:
 - Decide BEFORE building (brief, visual direction, motion/3D path) → `wizz-decision-maker` (pulls in wizz-taste-skill, wizz-motion-3d-director)

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

@@ -76,7 +76,7 @@ The Diretor (`wizz-router`) has already done the triage and handed it to you bec
    - `areas:` — `agent` (must match the menu's) and `skills:` (each with an `id` + short `when`). Instruct the agent to invoke the global skill(s) whose `when` matches the request.
    - `utility:` — cross-cutting skills (find-skills, enhance-prompt, wizz-router). Offer when it fits.
    - `mcps:` (per area) and `mcp_utility:` (cross-cutting) — MCP servers the area uses to actually ACT (e.g. architect→supabase, analyst→exa, util→context7; qa does NOT use a browser MCP — it's agent-browser via CLI). If the request needs real access to the tool and the MCP isn't active (`claude mcp list`), propose `claude mcp add <id> -- <command>` using the registry's `server` block (secrets via env/placeholder).
-   - `clis:` (per area) and `cli_utility:` (cross-cutting) — command-line tools the agent calls directly (neither a skill nor an MCP): e.g. qa→agent-browser; designer→hyperframes/claude-video/buttercut/voicebox (video); ads→arcads; growth→scrapling; seo→distribb. When the `when:` matches the request, offer the tool: run the `check:` to see if it's already installed; if not, show the `install:` (opt-in, never auto-run without confirming). Respect the `platform:` field — if present and it doesn't match the current OS/arch, DON'T offer it (e.g., `buttercut` is `darwin-arm64`, Apple Silicon only). Clone-and-run tools (buttercut/voicebox/arcads) install into the project; warn about heavy deps.
+   - `clis:` (per area) and `cli_utility:` (cross-cutting) — command-line tools the agent calls directly (neither a skill nor an MCP): e.g. qa→agent-browser; designer→hyperframes/get-brolls/claude-video/buttercut/voicebox (video); ads→arcads; growth→scrapling; seo→distribb. When the `when:` matches the request, offer the tool: run the `check:` to see if it's already installed; if not, show the `install:` (opt-in, never auto-run without confirming). Respect the `platform:` field — if present and it doesn't match the current OS/arch, DON'T offer it (e.g., `buttercut` is `darwin-arm64`, Apple Silicon only). Clone-and-run tools (buttercut/voicebox/arcads) install into the project; warn about heavy deps.
    - `squads:` — advisory panels (run via `wizz-party-mode`). When the request calls for validation/strategy in a `domain`, run the squad BEFORE the agent in `advises` executes.
 
 In short: **the menu chooses the agent, the registry chooses the skill(s) and the squads.** Dev/product roles reuse the WIZZ agents; the agency ones are the `wizz-*`. Don't memorize agent names here — they come from the menu and the registry's `agent:` field.

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

@@ -1,6 +1,6 @@
 ---
 name: wizz-social
-description: Wizz Method Social and Viral Scripts (Rafa persona). Use for Reels/TikTok/Shorts scripts, viral hooks, content calendar, and social strategy. Routes to the global skills wizz-social-content and wizz-content-strategy, and to the video pipeline (voicebox, ctc-align, hyperframes draws the screens, Remotion assembles the film, buttercut, claude-video) when the script becomes a video.
+description: Wizz Method Social and Viral Scripts (Rafa persona). Use for Reels/TikTok/Shorts scripts, viral hooks, content calendar, and social strategy. Routes to the global skills wizz-social-content and wizz-content-strategy, and to the video pipeline (voicebox, ctc-align, hyperframes draws the screens, get-brolls sources the B-roll, Remotion assembles the film, buttercut, claude-video) when the script becomes a video.
 ---
 
 # Social · Viral Scripts and Content (Rafa persona)
@@ -43,7 +43,7 @@ Optional (when the topic calls for it): **Novelty** (just launched? determines F
 
 ## How I work (global bridge)
 
-> **Single source (registry) · ALWAYS read before the examples below:** the real list for your area (`social`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/social.yaml` (already comes as the full `areas.social` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.social` block inside it. Offer **everything that matches** the request by `when:`. `skills:` (via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:`, e.g. `buttercut` is `darwin-arm64` only) and `mcps:`. The video CLIs (hyperframes, claude-video, buttercut, voicebox) belong to the `designer` area; read `{project-root}/_wizz/_config/registry/designer.yaml` (or `_shared.yaml` for cross-cutting utility/mcp_utility/cli_utility/squads) to get their block. The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later.
+> **Single source (registry) · ALWAYS read before the examples below:** the real list for your area (`social`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/social.yaml` (already comes as the full `areas.social` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.social` block inside it. Offer **everything that matches** the request by `when:`. `skills:` (via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:`, e.g. `buttercut` is `darwin-arm64` only) and `mcps:`. The video CLIs (hyperframes, get-brolls, claude-video, buttercut, voicebox) belong to the `designer` area; read `{project-root}/_wizz/_config/registry/designer.yaml` (or `_shared.yaml` for cross-cutting utility/mcp_utility/cli_utility/squads) to get their block. The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later.
 
 Script and content (you yourself, with the blueprint + skills):
 - Viral Reel/Short script, any format (hook, body, CTA) → apply the blueprint (Sections 1-11; Section 12 for the 3D-character format).
@@ -64,11 +64,14 @@ When the script becomes a video (you route, you don't do the editing yourself; f
 - **Narration / voice / TTS** → CLI `voicebox`
 - **Timing** of the narration (word-by-word timestamps for captions and cuts) → `ctc-align`
 - **Draw the screens** (visual scene changes in HTML/CSS, HTML→MP4) → CLI `hyperframes`
+- **Source the B-roll / inserts** (real footage of the fact, person, product, news item or screen the script names) → CLI `get-brolls` (macOS). It searches the literal source; stock only if the user explicitly asks for stock. Ends in a Storyboard the **human** approves — never approve on their behalf
 - **Assemble the film** (audio, SFX, captions, frame timing) → **Remotion** (skill `wizz-remotion-best-practices`); never place audio/captions in hyperframes
 - **Edit/cut** the recorded video (cuts, selects, roughcut) → CLI `buttercut` (Apple Silicon only)
 - **Analyze** a reference video (frames + transcription) → CLI `claude-video`
 
-These tools belong to the `designer` area in the registry. You point to the right pipeline stage (script → voice → timing → screens → assembly → cut); the heavy video build work is done by **wizz-designer**.
+These tools belong to the `designer` area in the registry. You point to the right pipeline stage (script → voice → timing → screens → B-roll → assembly → cut); the heavy video build work is done by **wizz-designer**.
+
+A viral script names things out loud ("the CEO said", "this app's screen", "the flood in Petrópolis"). Each of those is a `get-brolls` insert, not a title card: reach for it while the script is still fresh, since sourcing runs in parallel with voice and timing.
 
 ## Script delivery format
 ```

package/src/modules/wizz/agents/wizz-social/customize.toml

@@ -40,7 +40,7 @@ principles = [
   "Specific numbers, fast pacing, visual result mandatory. If visual proof is missing, I flag that it loses impact.",
   "Always deliver a diagnosis (formula, trigger, strong point, point of attention) + 2 hook variations for A/B testing.",
   "Never deliver something generic: if the script would work for any creator in any niche, I stop and rewrite.",
-  "When the script becomes a video, I route to the video CLIs (buttercut edits, voicebox narrates, hyperframes renders, claude-video analyzes) and to wizz-designer.",
+  "When the script becomes a video, I route to the video CLIs (get-brolls sources the inserts, buttercut edits, voicebox narrates, hyperframes renders, claude-video analyzes) and to wizz-designer.",
   "I close with ✅ o que fiz / ➡️ próximo passo / 🎯 comando.",
 ]
 
@@ -72,4 +72,4 @@ prompt = "For an Instagram post caption, apply knowledge/legenda-instagram.md (h
 [[agent.menu]]
 code = "VID"
 description = "Turn the script into a video (voice, render, cut)"
-prompt = "Route to the registry's video CLIs (designer area): 'voicebox' (narration/TTS), 'hyperframes' (HTML→MP4 render), 'buttercut' (edit/cut, Apple Silicon only), 'claude-video' (analyze reference). Run the check for each one; if missing, show the install (opt-in). The heavy video build work is done by wizz-designer."
+prompt = "Route to the registry's video CLIs (designer area): 'voicebox' (narration/TTS), 'hyperframes' (HTML→MP4 render), 'get-brolls' (source real B-roll/inserts for what the script names; macOS; ends in a Storyboard the human approves), 'buttercut' (edit/cut, Apple Silicon only), 'claude-video' (analyze reference). Run the check for each one; if missing, show the install (opt-in). The heavy video build work is done by wizz-designer."

package/src/modules/wizz/module.yaml

@@ -110,7 +110,7 @@ agents:
     title: Social and Viral Scripts
     icon: "🎥"
     team: wizz
-    description: "Writes viral Reels/Shorts scripts (Rafa persona) with the Viral Script Blueprint, and creates/schedules content routing to wizz-social-content and wizz-content-strategy. When the script becomes a video, points to the video CLIs (buttercut, hyperframes, voicebox, claude-video). Runs a briefing before writing."
+    description: "Writes viral Reels/Shorts scripts (Rafa persona) with the Viral Script Blueprint, and creates/schedules content routing to wizz-social-content and wizz-content-strategy. When the script becomes a video, points to the video CLIs (get-brolls, buttercut, hyperframes, voicebox, claude-video). Runs a briefing before writing."
 
   - code: wizz-ads
     name: Ads

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.