wizz-method 2.25.2 → 2.25.3

package/package.json

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

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

@@ -42,7 +42,7 @@ Strong and ultra never take architecture or product decisions: they return optio
 
 ## 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.
+A diff produced by mechanical, standard, strong, or ultra is reviewed before integrating. Reviewing a story, diff or PR means running `Skill(wizz-code-review)` in the main session, never a bare `wizz-exec-review` dispatch: `wizz-exec-review` is only the worker that runs ONE layer inside that skill, and a bare dispatch is a single pass that skips the layers. The reviewers run 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`.
 

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

@@ -40,7 +40,7 @@ Mechanical work NEVER runs in the main session when it's large (more than 3 file
 - **`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`.
+- **`wizz-exec-review`** (pinned to the Strong tier, `opus` in Claude Code): the worker that runs ONE layer of `wizz-code-review` (the entry point for reviewing any story, diff or PR: run `Skill(wizz-code-review)` in the main session, never dispatch this alone). 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.