wizz-method 2.24.0 → 2.25.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "2.24.0",
+  "version": "2.25.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/customize.toml

@@ -83,6 +83,25 @@ review_critical_paths = [
   "secrets, keys and .env files",
   "cryptography",
   "CI and deploy workflows",
+  "deletion of user or production data",
+  "external sends and publishing (e-mail, webhooks, posts, public pages)",
+  "personal data (PII) and user data handling",
+  "infrastructure and DNS",
+  "new or replaced dependencies",
+]
+
+# Fixed floor for the `critical` tier: git pathspec globs. Any changed file
+# matching one forces `critical` before the session judges anything; the
+# session's judgment can only raise from there, never lower. Model
+# confidence never lowers it either. See references/review-economy.md § 2.
+
+review_critical_globs = [
+  "**/migrations/**",
+  "**/*.sql",
+  ".github/workflows/**",
+  "**/.env*",
+  "**/middleware.*",
+  "**/Dockerfile*",
 ]
 
 # Review layers for the review step. `instruction` is the layer's whole

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

@@ -37,7 +37,11 @@ The session reads the file list (`git diff --name-status`) and, when unsure, the
 
 **Provided or pasted diffs, and no VCS.** There is no `git --numstat` to read. Count `files` from the diff's own `diff --git` (or, lacking that, `+++`) headers, and `changed_lines` from the `+`/`-` body lines (the `+++`/`---` header lines themselves don't count). The table above applies without exception in both workflows — `small` included.
 
-`{workflow.review_critical_paths}` is a plain-language list of sensitive areas, not a pattern list. Default: authentication, sessions, passwords and credentials, authorization, permissions and RLS, payments, billing and checkout, database migrations, schema and SQL, secrets, keys and `.env` files, cryptography, CI and deploy workflows. Judge by meaning, not by substring: a security check added inside an otherwise generic file counts as `critical`; a document that merely talks about auth does not.
+**Fixed floor first.** Before any judgment, match the changed file list against `{workflow.review_critical_globs}` (git pathspec globs; default: `**/migrations/**`, `**/*.sql`, `.github/workflows/**`, `**/.env*`, `**/middleware.*`, `**/Dockerfile*`). Any match sets the tier to `critical`, and nothing below can lower it. CI files sit on the floor because a change there can weaken the very checks that review relies on.
+
+`{workflow.review_critical_paths}` is a plain-language list of sensitive areas, not a pattern list. Default: authentication, sessions, passwords and credentials, authorization, permissions and RLS, payments, billing and checkout, database migrations, schema and SQL, secrets, keys and `.env` files, cryptography, CI and deploy workflows, deletion of user or production data, external sends and publishing (e-mail, webhooks, posts, public pages), personal data (PII) and user data handling, infrastructure and DNS, new or replaced dependencies. Judge by meaning, not by substring: a security check added inside an otherwise generic file counts as `critical`; a document that merely talks about auth does not.
+
+**Model confidence does not count.** A confidence the executor or a reviewer states about its own output never lowers the tier, never drops a layer, and never skips review: self-reported LLM confidence is poorly calibrated and runs high.
 
 Raise the tier when in doubt, never lower it — a change that clearly touches something the list above doesn't name (e.g. a data migration done in application code) still earns `critical`. State the tier, the reason and the resulting layer count to the user before launching any layer.
 

package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-01-gather-context.md

@@ -79,7 +79,7 @@ story_key: '' # set at runtime when discovered from sprint status
    - **Otherwise:** build `{clean_diff_file}` per § 1 — the identical git command that wrote `{diff_file}` for the chosen source, plus one `:(top,exclude,glob)<pattern>` pathspec per entry in `{workflow.review_exclude}`, appended after the positive pathspecs. For **uncommitted changes**, also append untracked files to `{clean_diff_file}` the same way they were appended to `{diff_file}`, but listed with the positive-plus-exclude pathspecs from § 1 so any excluded file is skipped. Get `files` and `changed_lines` from `git -C "$TOP" diff --no-ext-diff --no-color --no-textconv --numstat` with the same source args and pathspecs, plus per-file `git -C "$TOP" diff --no-index --numstat -- /dev/null <path>` for the untracked ones (§ 1).
    - If a git command in this instruction fails: delete any partially written `{clean_diff_file}` temp file, then set `{clean_diff_file}` = `{diff_file}` and `{tier}` = `critical`, say so, and continue.
    - If nothing is left after exclusions (`{clean_diff_file}` is empty, untracked files included, even though `{diff_file}` is non-empty): HALT, list the exclusions, and ask the user whether to review the raw diff anyway. If they do, set `{clean_diff_file}` = `{diff_file}` and pick the tier per § 2 from the raw diff. If they decline, delete `{diff_file}` (when `{diff_file_owned}` is true) and `{clean_diff_file}` per § 5 and end the workflow.
-   - Otherwise, pick the tier per § 2: read `git diff --name-status` for the same source (and the relevant hunks when unsure) and judge it against `{workflow.review_critical_paths}`.
+   - Otherwise, pick the tier per § 2: read `git diff --name-status` for the same source; if any changed path matches `{workflow.review_critical_globs}`, the tier is `critical` (fixed floor). Otherwise read the relevant hunks when unsure and judge it against `{workflow.review_critical_paths}`.
    - State the tier, the reason, and the resulting Forte subagent count to the user before launching any layer.
 
 5. **Stage the claims file.** Collect the change's own narrative: for a branch diff or commit range, the commit messages it covers (`git log <base>..<head>`); for other sources, whatever description of the change the user or conversation supplied. Write it verbatim to a uniquely-named file in the system temp directory and set `{claims_file}` to its path. If there is no narrative, set `{claims_file}` = `''`. Do not analyze or summarize the narrative — it is input for one review layer, staged as a file precisely so the other layers never see it.

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

@@ -83,6 +83,25 @@ review_critical_paths = [
   "secrets, keys and .env files",
   "cryptography",
   "CI and deploy workflows",
+  "deletion of user or production data",
+  "external sends and publishing (e-mail, webhooks, posts, public pages)",
+  "personal data (PII) and user data handling",
+  "infrastructure and DNS",
+  "new or replaced dependencies",
+]
+
+# Fixed floor for the `critical` tier: git pathspec globs. Any changed file
+# matching one forces `critical` before the session judges anything; the
+# session's judgment can only raise from there, never lower. Model
+# confidence never lowers it either. See references/review-economy.md § 2.
+
+review_critical_globs = [
+  "**/migrations/**",
+  "**/*.sql",
+  ".github/workflows/**",
+  "**/.env*",
+  "**/middleware.*",
+  "**/Dockerfile*",
 ]
 
 # Review layers for the review step. `instruction` is the layer's whole

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

@@ -37,7 +37,11 @@ The session reads the file list (`git diff --name-status`) and, when unsure, the
 
 **Provided or pasted diffs, and no VCS.** There is no `git --numstat` to read. Count `files` from the diff's own `diff --git` (or, lacking that, `+++`) headers, and `changed_lines` from the `+`/`-` body lines (the `+++`/`---` header lines themselves don't count). The table above applies without exception in both workflows — `small` included.
 
-`{workflow.review_critical_paths}` is a plain-language list of sensitive areas, not a pattern list. Default: authentication, sessions, passwords and credentials, authorization, permissions and RLS, payments, billing and checkout, database migrations, schema and SQL, secrets, keys and `.env` files, cryptography, CI and deploy workflows. Judge by meaning, not by substring: a security check added inside an otherwise generic file counts as `critical`; a document that merely talks about auth does not.
+**Fixed floor first.** Before any judgment, match the changed file list against `{workflow.review_critical_globs}` (git pathspec globs; default: `**/migrations/**`, `**/*.sql`, `.github/workflows/**`, `**/.env*`, `**/middleware.*`, `**/Dockerfile*`). Any match sets the tier to `critical`, and nothing below can lower it. CI files sit on the floor because a change there can weaken the very checks that review relies on.
+
+`{workflow.review_critical_paths}` is a plain-language list of sensitive areas, not a pattern list. Default: authentication, sessions, passwords and credentials, authorization, permissions and RLS, payments, billing and checkout, database migrations, schema and SQL, secrets, keys and `.env` files, cryptography, CI and deploy workflows, deletion of user or production data, external sends and publishing (e-mail, webhooks, posts, public pages), personal data (PII) and user data handling, infrastructure and DNS, new or replaced dependencies. Judge by meaning, not by substring: a security check added inside an otherwise generic file counts as `critical`; a document that merely talks about auth does not.
+
+**Model confidence does not count.** A confidence the executor or a reviewer states about its own output never lowers the tier, never drops a layer, and never skips review: self-reported LLM confidence is poorly calibrated and runs high.
 
 Raise the tier when in doubt, never lower it — a change that clearly touches something the list above doesn't name (e.g. a data migration done in application code) still earns `critical`. State the tier, the reason and the resulting layer count to the user before launching any layer.
 

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

@@ -38,7 +38,7 @@ Compute the spec's repo-relative path first — `git -C "$TOP" ls-files --full-n
 - If a git command in this section fails: set `{clean_diff_file}` = `{diff_file}` and `{tier}` = `critical`, say so, and continue.
 - If `{clean_diff_file}` is empty (untracked files included) and excluding only the spec pathspec — with none of the `review_exclude` globs applied — already empties it too: the spec's own edit was the only change. There is nothing to review: skip the Review section entirely (no layer launches, `{failed_layers}` stays empty) and go straight to Classify, which finds nothing against the empty diff. Do not fall back to the raw diff in this case.
 - Else if nothing is left after exclusions for any other reason (a `review_exclude` glob, not the spec exclude, accounts for the emptiness): review the raw diff per § 1 — `{clean_diff_file}` = `{diff_file}`, tier picked from the raw diff.
-- Otherwise, pick the tier per § 2 (`small` included, on equal footing with `normal`/`critical`) by reading `git -C "$TOP" diff --name-status {baseline_commit} -- ':(top)' ':(top,exclude,literal)<repo-relative spec path>'` and judging it against `{workflow.review_critical_paths}`.
+- Otherwise, pick the tier per § 2 (`small` included, on equal footing with `normal`/`critical`) by reading `git -C "$TOP" diff --name-status {baseline_commit} -- ':(top)' ':(top,exclude,literal)<repo-relative spec path>'`: any changed path matching `{workflow.review_critical_globs}` makes it `critical` (fixed floor); otherwise judge it against `{workflow.review_critical_paths}`.
 
 Announce the exclusions once, from this run only. Tell the user the tier, the exclusions, and the resulting Forte subagent count before launching any layer.
 

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

@@ -46,6 +46,18 @@ A diff produced by mechanical, standard, strong, or ultra goes through `wizz-exe
 
 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`.
 
+## Consequence
+
+Difficulty picks the executor's tier; size and sensitive area pick the review layers; consequence decides whether an output may skip extra review at all. This applies to every output, not only diffs: copy, research, client reports, e-mails, and posts included. An output passes with the minimum (for a diff, the `small` tier; for anything else, the agent's own check) only when all three are true:
+
+1. **A machine checks it:** tests, schema, build, lint, or a validator are green.
+2. **It is easy to undo:** no destructive migration, no deletion, no external send, no publishing.
+3. **Nobody acts on it before another step sees it.**
+
+If any one fails, the output goes through review on the Strong tier (in another vendor when one is available) and the boss gives the final verdict. An external or irreversible action never rests on an LLM reviewer: it stops for the user's explicit OK.
+
+Model confidence does not count: a confidence the executor or reviewer states about its own output never skips review, never drops a layer, and never lowers the tier. For diffs, the tier floor comes from `review_critical_globs` and the session's judgment can only raise it (`wizz-code-review/references/review-economy.md` § 2).
+
 ## Fan-out cap
 
 - Work that fits in 3 files or fewer: 1 subagent, or the session itself.

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

@@ -29,4 +29,5 @@ You are Wizz's Ads. It plans campaigns, generates creative variations, and track
 Index of situation → skill/reference, in order of use: `{skill-root}/knowledge/playbook.md`. Read it only when the request is ambiguous about which skill comes first or the path spans several skills; a request that already names one clear skill goes straight to it. It never replaces the registry.
 
 ## Closing
+Before delivering or publishing, run the consequence gate in `_shared/model-ladder.md` ("Consequence"): output that someone will act on, send or publish without another step seeing it goes to review first, and anything external or irreversible waits for the user's OK.
 Close in the format of `_shared/encerramento.md` (wizz module root). If the campaign needs new text or visuals, next is usually wizz-copy or wizz-designer.

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

@@ -33,4 +33,5 @@ Always deliver 2-3 variations and say which one you recommend.
 Index of situation → skill/reference, in order of use: `{skill-root}/knowledge/playbook.md`. Read it only when the request is ambiguous about which skill comes first or the path spans several skills; a request that already names one clear skill goes straight to it. It never replaces the registry.
 
 ## Closing
+Before delivering or publishing, run the consequence gate in `_shared/model-ladder.md` ("Consequence"): output that someone will act on, send or publish without another step seeing it goes to review first, and anything external or irreversible waits for the user's OK.
 Close in the format of `_shared/encerramento.md` (wizz module root). Next is usually wizz-designer, to lay it out.

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

@@ -35,4 +35,5 @@ Always bring concrete actions and the expected impact of each one.
 Index of situation → skill/reference, in order of use: `{skill-root}/knowledge/playbook.md`. Read it only when the request is ambiguous about which skill comes first or the path spans several skills; a request that already names one clear skill goes straight to it. It never replaces the registry.
 
 ## Closing
+Before delivering or publishing, run the consequence gate in `_shared/model-ladder.md` ("Consequence"): output that someone will act on, send or publish without another step seeing it goes to review first, and anything external or irreversible waits for the user's OK.
 Close in the format of `_shared/encerramento.md` (wizz module root). If it turns into an ad, point to **wizz-ads**; if it turns into text, **wizz-copy**.

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

@@ -33,4 +33,5 @@ Always deliver the list of fixes **in order of impact** (what to tackle first).
 Index of situation → skill/reference, in order of use: `{skill-root}/knowledge/playbook.md`. Read it only when the request is ambiguous about which skill comes first or the path spans several skills; a request that already names one clear skill goes straight to it. It never replaces the registry.
 
 ## Closing
+Before delivering or publishing, run the consequence gate in `_shared/model-ladder.md` ("Consequence"): output that someone will act on, send or publish without another step seeing it goes to review first, and anything external or irreversible waits for the user's OK.
 Close in the format of `_shared/encerramento.md` (wizz module root). If it turns into text, next is usually wizz-copy.

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

@@ -95,4 +95,5 @@ A viral script names things out loud ("the CEO said", "this app's screen", "the
 The canonical rules live in `agent.principles` (briefing before anything, hook on the first word, right formula justified, specific numbers, diagnosis + 2 variations, never generic). Execution detail only for the 3D format: fast pacing in the tutorial (short sentences, action verbs), mandatory visual result (if missing, flag that it loses impact), Triple CTA in the right order.
 
 ## Closing
+Before delivering or publishing, run the consequence gate in `_shared/model-ladder.md` ("Consequence"): output that someone will act on, send or publish without another step seeing it goes to review first, and anything external or irreversible waits for the user's OK.
 Close in the format of `_shared/encerramento.md` (wizz module root). Next is usually wizz-designer (to turn it into a video) or saving to cerebro.

package/tools/installer/core/resolved-schema.js

@@ -79,9 +79,11 @@ const WORKFLOW_KEYS = new Set([
   // item keys are validated against REVIEW_LAYER_KEYS below.
   'review_layers',
   'oneshot_review_layers',
-  // review economy (review-economy.md): diff cleaning excludes/critical paths.
+  // review economy (review-economy.md): diff cleaning excludes, critical
+  // paths (plain-language guidance) and critical globs (fixed floor).
   'review_exclude',
   'review_critical_paths',
+  'review_critical_globs',
 ]);
 const PARTY_MEMBER_KEYS = new Set(['code', 'name', 'icon', 'title', 'persona', 'capabilities', 'model']);
 const PARTY_GROUP_KEYS = new Set(['id', 'name', 'scene', 'members', 'memory']);
@@ -104,7 +106,7 @@ function isArrayOfStrings(value) {
 
 /**
  * Collect unknown/invalid entries under `[workflow]`: unknown fields by
- * name, invalid values for the two review-economy string-array fields, and
+ * name, invalid values for the three review-economy string-array fields, and
  * — for the arrays-of-tables we own (party members/groups, review layers) —
  * the unknown keys and invalid values of each item.
  *
@@ -122,7 +124,7 @@ function findUnknownWorkflowKeys(workflow) {
       unknown.push({ path: wfPath, kind: 'unknown' });
       continue;
     }
-    if (k2 === 'review_exclude' || k2 === 'review_critical_paths') {
+    if (k2 === 'review_exclude' || k2 === 'review_critical_paths' || k2 === 'review_critical_globs') {
       if (!isArrayOfStrings(v2)) {
         unknown.push({ path: wfPath, kind: 'invalid', detail: `expected an array of strings, got ${JSON.stringify(v2)}` });
       }