wizz-method 2.12.0 → 2.14.0

package/src/bmm-skills/3-solutioning/wizz-create-epics-and-stories/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches Step 4 (Final Validation) and the
 # user confirms [C] Complete — after the epics.md is saved and wizz-help is invoked.

package/src/bmm-skills/3-solutioning/wizz-generate-project-context/steps/step-03-complete.md

@@ -207,6 +207,13 @@ stage: '{{project_stage}}' # prototype|mvp|production|maintenance
 **Add Usage Section:**
 Append the usage guidelines from step 3 to complete the document.
 
+**Wire it into the Wizz block:** agents no longer load this file on every skill activation; the Wizz block in `CLAUDE.md` / `AGENTS.md` loads it once per session. For each of those files at `{project-root}` that has the `<!-- wizz:begin -->` block and does not yet mention this file, add a line right before `<!-- wizz:end -->`, using the path relative to `{project-root}`:
+
+- `CLAUDE.md`: `@<relative path>` on its own line (Claude Code imports it).
+- `AGENTS.md`: ``- Contexto do projeto: leia `<relative path>` antes de implementar (regras de stack e padrões).``
+
+The next `wizz install` rewrites the block with the same line, so the edit is stable. If neither file has the block, tell the user to run `npx wizz-method install` to add it.
+
 ### 6. Completion Validation
 
 Final checks before completion:

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

@@ -35,8 +35,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
 persistent_facts = [
-  "file:{project-root}/**/project-context.md",
   "FEATURE: the SessionStart hook already resolves the active feature from the git branch and injects 'FEATURE ATIVA: <slug>'. If it exists, save EVERY planning and implementation artifact in the subfolder with that name ({planning_artifacts}/{active_feature}/, {implementation_artifacts}/{active_feature}/) and write the slug to active_feature in {project-root}/_wizz/bmm/config.yaml on first write, announcing it in ONE line. Memory saved in this session carries the same slug as its theme. With no feature resolved, write to the root folders. NEVER ask the user for the feature: invoke wizz-set-feature only if they ask to switch, or if there are two open features and the request does not decide between them.",
   "When implementing against a library or framework, consult Context7 for current docs, APIs, and version-specific syntax before relying on training data or web search: call resolve-library-id with the library name, then query-docs with the returned /org/project id and a specific question. If Context7 is unavailable, tell the user once that they can enable it with `npx ctx7 setup`, then fall back to web research.",
 ]

package/src/bmm-skills/4-implementation/wizz-checkpoint-preview/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after the review decision (approve/rework/discuss) is made. Override wins.

package/src/bmm-skills/4-implementation/wizz-code-review/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after review findings are presented and sprint status is synced. Override wins.

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

@@ -20,21 +20,30 @@
 
 2. Run the acceptance audit from `references/review-economy.md` section 4 and add its findings with source `triage-acceptance` to the unified list, before verdicts, when `{review_mode}` = `"full"` and the `acceptance-auditor` layer did not run to completion for any reason: `{layer_status}` marks it `dropped` (tier, disabled by override, or its `when` condition), or it failed or ended `PARTIAL:` (its id appears in `{failed_layers}`) — a `critical` tier where that layer actually ran to completion does not also get this audit. They get a verdict like any other finding, per instruction 3 below.
 
-3. Once every layer has reported -- and not before -- render a verdict on each finding on its own, ahead of any deduplication or grouping. For each finding:
-   - **Verify its own claimed consequence** at the location it names. Read past the diff hunk -- into the callers, the guards upstream, whatever else the site depends on -- far enough to tell whether that consequence actually occurs. Another finding's outcome, however adjacent, never settles this one.
-   - **Assign severity** from the verified consequence for the artifact's main consumer (software user, document reader, etc). Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.
-     - `low` -- none or cosmetic
-     - `medium` -- tolerable
-     - `high` -- intolerable
-   - **Keep or dismiss.** Keep a finding only where verification confirmed its consequence. Dismiss noise, claims the verification refuted, and claims it could not substantiate -- no path to the claimed consequence at the named site is a valid disposal. Whatever the reason, it must dispose of the finding's own claim: a true fact about neighboring code that leaves the claim standing is not a dismissal, and the finding stays kept. Record each dismissal with its reason for the summary; never drop a finding silently.
-   - A finding whose fix edits the spec under review: dismiss. A finding whose fix edits an agent-context document (e.g. CLAUDE.md, AGENTS.md, rules files, other specs): defer, never patch.
-
-4. **Group the survivors by shared root cause** -- two findings belong in one entry only when the same underlying defect produced both. Same location alone is not a shared root cause, and neither is a shared fix. An entry carries every member's verified consequence in `detail` and the highest severity among them; set `source` to the contributing layers joined with `+` (e.g., `blind-hunter+edge-case-hunter`).
-
-5. **Route** each entry into exactly one triage bucket:
+3. Once every layer has reported -- and not before -- render a verdict on each finding, ahead of any deduplication or grouping. Disregard any severity a reviewing subagent assigned -- they lack the context to grade.
+
+   For each finding:
+   - **Verify the finding's claim.** At the cited file and line, does the bad outcome the reviewer describes actually occur? Read beyond the changed lines -- follow callers, guards upstream, etc -- until you can answer yes or no. A different finding about nearby code does not settle this one. Judge whether the problem is real, not whether the proposed fix is plausible. Code that loudly fails on a situation you never showed the program can reach is correct behavior, not a defect.
+   - **Render exactly one verdict** from what verification established -- the verdict is the whole triage decision; there is no separate keep-or-dismiss.
+     - `high` (intolerable), `medium` (tolerable), `low` (cosmetic or negligible) -- the bad outcome is real. Assign severity by how much it hurts end users or developers. For developer-only problems (inconsistent design, eroded invariants, duplicated sources of truth), name where it will cause trouble -- which caller will diverge, which rule will break. A vague "this is messy" with no named harm is not a severity grade; use `false` or `maybe-false` instead. When the harm is real but you cannot tell how bad, pick the higher grade.
+     - `false` -- you checked, and the bad outcome does not happen at the cited location. Write what disproves this specific claim. A true fact about nearby code that does not disprove the claim does not count.
+     - `maybe-false` -- you could not tell whether the bad outcome happens. Write what you would need to check to find out. Use this only when the diff and surrounding code leave the question open; when they are enough to decide, pick `high`, `medium`, `low`, or `false`.
+   - Every finding keeps its verdict and evidence (a sentence or two) for the summary; never drop, merge, or silently skip one.
+
+   Dismiss `false` findings on their refutation.
+
+   Dismiss `low` findings when it is unlikely that users or developers would meet the defect in everyday use (judged plainly -- no proof needed) and the fix is more than a direct correction or deletion -- adding guards, branches, parameters, or other complexity.
+
+   Dismiss any finding whose fix is to edit the spec under review.
+
+   All remaining findings continue to grouping.
+
+4. **Group the survivors by shared root cause** -- two findings belong in one entry only when the same defect produced both. Same location alone is not a shared root cause, and neither is a shared fix. An entry carries every member's verified bad outcome in `detail` and the highest verdict among them (`high` > `medium` > `low` > `maybe-false`); set `source` to the contributing layers joined with `+` (e.g., `blind-hunter+edge-case-hunter`).
+
+5. **Route** each entry into exactly one triage bucket. A group that includes verified `high`, `medium`, or `low` members routes by its highest such verdict -- not to defer just because a member is `maybe-false`.
    - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
-   - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
-   - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
+   - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous, adds no public surface, and guards no state you did not demonstrate; otherwise `decision_needed`.
+   - **defer** -- Pre-existing issue not caused by the current change, real but not actionable now; or an entry whose members are all `maybe-false` and the claim, if true, would be `medium` or `high` -- record that severity marked unverified, plus what would settle it (if it would only be `low`, dismiss it with the same note); or any entry whose fix edits an agent-context document (e.g. CLAUDE.md, AGENTS.md, rules files, other specs) -- defer, never patch.
 
    If `{review_mode}` = `"no-spec"` and an entry would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
 

package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-04-present.md

@@ -27,7 +27,7 @@ If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Rev
    `- [ ] [Review][Patch] <Title> [<file>:<line>]`
 
 3. **`defer`** findings (checked off, marked deferred):
-   `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing`
+   `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred: <pre-existing, or for maybe-false the evidence that would settle it>`
 
 Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description.
 
@@ -37,7 +37,7 @@ Announce what was written:
 
 > **Code review complete.** <D> `decision-needed`, <P> `patch`, <W> `defer`, <R> dismissed.
 
-The findings report ends with a `Dismissed` appendix — one line per dismissed finding: the finding and the reason that disposed of its claim — in the story file's `### Review Findings` section when `{spec_file}` is set, at the tail of the chat listing otherwise.
+The findings report ends with a `Dismissed` appendix — one line per dismissed finding: the finding, its verdict and the reason (`false` with its refutation, `low` with why it was not worth fixing, a fix that would edit the spec under review) — in the story file's `### Review Findings` section when `{spec_file}` is set, at the tail of the chat listing otherwise.
 
 If `{spec_file}` is set, add: `Findings written to the review findings section in {spec_file}.`
 Otherwise add: `Findings are listed above. No story file was provided, so nothing was persisted.`

package/src/bmm-skills/4-implementation/wizz-correct-course/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches Step 6 (Workflow Completion),
 # after the Sprint Change Proposal is finalized and handoff is confirmed. Override wins.

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

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches Step 6 (Update sprint status and finalize),
 # after the story file is saved and sprint-status.yaml is updated. Override wins.

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

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after the story implementation is complete and status is updated. Override wins.

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

@@ -33,9 +33,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: path to the case-file template, resolved from the skill root.
 # Override to point at an org-shaped template (compliance sections,

package/src/bmm-skills/4-implementation/wizz-qa-generate-e2e-tests/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches Step 5 (Create Summary),
 # after all tests pass and the summary document is saved. Override wins.

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

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after implementation is complete and explanations are provided. Override wins.

package/src/bmm-skills/4-implementation/wizz-quick-dev/spec-template.md

@@ -69,6 +69,12 @@ context: [] # optional: `{project-root}/`-prefixed paths to project-wide standar
      the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation).
      Empty until the first bad_spec loopback. -->
 
+## Review Triage Log
+
+<!-- Append-only. Populated by step-04 on every review pass: one row per reviewer finding —
+     verdict (high/medium/low/false/maybe-false) with its evidence: the refutation for
+     false, what would settle it for maybe-false. Empty until the first review pass. -->
+
 ## Design Notes
 
 <!-- If the approach is straightforward, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->

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

@@ -62,34 +62,45 @@ 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-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.
+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 current `## Review Triage Log` rows of `{spec_file}` (for the carry-forward check in Classify item 2), 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 finding with its verdict and evidence, every entry with its category, and 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.
 
-2. Once every layer has reported — and not before — render a verdict on each finding on its own, ahead of any deduplication or grouping. For each finding:
-   - **Verify its own claimed consequence** at the location it names. Read past the diff hunk — into the callers, the guards upstream, whatever else the site depends on — far enough to tell whether that consequence actually occurs. Another finding's outcome, however adjacent, never settles this one.
-   - **Assign severity** from the verified consequence for the artifact's main consumer (software user, document reader, etc). Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.
-     - `low`: none or cosmetic
-     - `medium`: tolerable
-     - `high`: intolerable
-   - **Keep or dismiss.** Keep a finding only where verification confirmed its consequence. Dismiss noise, claims the verification refuted, and claims it could not substantiate — no path to the claimed consequence at the named site is a valid disposal. Whatever the reason, it must dispose of the finding's own claim: a true fact about neighboring code that leaves the claim standing is not a dismissal, and the finding stays kept. Record each dismissal with its reason; never drop a finding silently. The session (never the subagent) writes it to the `## Review Triage Log` section of `{spec_file}`.
-   - A finding whose fix edits the spec this run is implementing: dismiss. A finding whose fix edits an agent-context document (e.g. CLAUDE.md, AGENTS.md, rules files, other specs): defer, never patch.
-
-3. Group the survivors by shared root cause — two findings belong in one entry only when the same underlying defect produced both. Same location alone is not a shared root cause, and neither is a shared fix. An entry carries every member's verified consequence and the highest severity among them.
-4. Route each entry into exactly one triage category. The first three are **this story's problem** — caused or exposed by the current change. The last is **not this story's problem**.
+2. Once every layer has reported — and not before — render a verdict on each finding, ahead of any deduplication or grouping. Disregard any severity a reviewing subagent assigned — they lack the context to grade.
+
+   If `## Review Triage Log` already has rows — a loopback or a resumed review — check each finding against them first. Same location and same claim as a logged row, and the code there still reads as the row describes: keep the row's verdict and route, write the row again with `carried` in front of the evidence, skip verification, and never patch or defer it again. Verify everything else as below.
+
+   For each finding:
+   - **Verify the finding's claim.** At the cited file and line, does the bad outcome the reviewer describes actually occur? Read beyond the changed lines — follow callers, guards upstream, etc — until you can answer yes or no. A different finding about nearby code does not settle this one. Judge whether the problem is real, not whether the proposed fix is plausible. Code that loudly fails on a situation you never showed the program can reach is correct behavior, not a defect.
+   - **Render exactly one verdict** from what verification established — the verdict is the whole triage decision; there is no separate keep-or-dismiss.
+     - `high` (intolerable), `medium` (tolerable), `low` (cosmetic or negligible) — the bad outcome is real. Assign severity by how much it hurts end users or developers. For developer-only problems (inconsistent design, eroded invariants, duplicated sources of truth), name where it will cause trouble — which caller will diverge, which rule will break. A vague "this is messy" with no named harm is not a severity grade; use `false` or `maybe-false` instead. When the harm is real but you cannot tell how bad, pick the higher grade.
+     - `false` — you checked, and the bad outcome does not happen at the cited location. Write what disproves this specific claim. A true fact about nearby code that does not disprove the claim does not count.
+     - `maybe-false` — you could not tell whether the bad outcome happens. Write what you would need to check to find out. Use this only when the diff and surrounding code leave the question open; when they are enough to decide, pick `high`, `medium`, `low`, or `false`.
+   - Every finding gets one row in the `## Review Triage Log` section of `{spec_file}` — verdict plus its evidence in a sentence or two; never drop, merge, or silently skip one. The session (never the subagent) writes the rows.
+
+   Dismiss `false` findings on their refutation.
+
+   Dismiss `low` findings when it is unlikely that users or developers would meet the defect in everyday use (judged plainly — no proof needed) and the fix is more than a direct correction or deletion — adding guards, branches, parameters, or other complexity.
+
+   Dismiss any finding whose fix is to edit the spec this run is implementing.
+
+   All remaining findings continue to grouping.
+
+3. Group the survivors by shared root cause — two findings belong in one entry only when the same defect produced both. Same location alone is not a shared root cause, and neither is a shared fix. An entry carries every member's verified bad outcome and the highest verdict among them (`high` > `medium` > `low` > `maybe-false`).
+4. Route each entry into exactly one triage category. A group that includes verified `high`, `medium`, or `low` members routes by its highest such verdict — not to defer just because a member is `maybe-false`. The first three are **this story's problem** — caused or exposed by the current change. The last is **not this story's problem**.
    - **intent_gap** — caused by the change; cannot be resolved from the spec because the captured intent is incomplete. Do not infer intent unless there is exactly one possible reading.
    - **bad_spec** — caused by the change, including direct deviations from spec. The spec should have been clear enough to prevent it. When in doubt between bad_spec and patch, prefer bad_spec — a spec-level fix is more likely to produce coherent code.
-   - **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
-   - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
+   - **patch** — caused by the change; its smallest fix is trivial, adds no public surface, and guards no state you did not demonstrate. Just part of the diff. A finding whose smallest fix fails any of those conditions routes to intent_gap when the spec does not settle that fix, otherwise to bad_spec.
+   - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review; or an entry whose members are all `maybe-false` and the claim, if true, would be `medium` or `high` — record that severity marked unverified, plus what would settle it (if it would only be `low`, dismiss it with the same note); or any entry whose fix edits an agent-context document (e.g. CLAUDE.md, AGENTS.md, rules files, other specs) — defer, never patch.
 5. Process findings in cascading order. If any `intent_gap` or `bad_spec` entries remain, they trigger a loopback — lower findings are moot since code will be re-derived. If neither remains, process patch and defer normally. Before each loopback, read `{spec_file}` frontmatter `review_loop_iteration` (missing means `0`), increment it by 1, and write it back. If it exceeds 5, delete `{diff_file}`, `{clean_diff_file}` and any findings temp files per `./references/review-economy.md` § 5, then HALT and escalate to the human.
    - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve — this is where the human sees the finding and its evidence; nothing upstream of this bullet asks them to confirm it first. If the human says the finding is not real, log it as dismissed with their reason (added to the `## Review Triage Log`) and drop it from the cascade instead of proceeding. Otherwise, once resolved, read fully and follow `./step-02-plan.md` to re-run steps 2–4.
    - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./step-03-implement.md` to re-derive the code, then this step will run again.
-   - **patch** — Auto-fix. These are the only findings that survive loopbacks. If the step-03 implementation subagent can be re-engaged with its context intact, send it all patch findings in one synchronous message — for each: the file, what is wrong, and what the fix must do. If it cannot be re-engaged, apply the patches yourself. Then re-run the checks in `{spec_file}`'s `## Verification` section, if present; if verification fails and the failure cannot be fixed, delete `{diff_file}`, `{clean_diff_file}` and any findings temp files per `./references/review-economy.md` § 5, then HALT and escalate to the human.
+   - **patch** — Auto-fix. These are the only findings that survive loopbacks. If the step-03 implementation subagent can be re-engaged with its context intact, send it all patch findings in one synchronous message — for each: the file, what is wrong, and what the smallest fix must do. If it cannot be re-engaged, apply the patches yourself. Then re-run the checks in `{spec_file}`'s `## Verification` section, if present; if verification fails and the failure cannot be fixed, delete `{diff_file}`, `{clean_diff_file}` and any findings temp files per `./references/review-economy.md` § 5, then HALT and escalate to the human.
    - **defer** — Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
      ```markdown
      - source_spec: `{spec_file}`
        summary: <one sentence>
-       evidence: <why this is real>
+       evidence: <why this is real; for a maybe-false finding, what evidence would settle it>
      ```
 
 ## NEXT

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

@@ -34,13 +34,33 @@ Implement the clarified intent directly.
 
 ### Classify
 
-Deduplicate all review findings. Three categories only:
+Once every layer has reported — and not before — render a verdict on each finding, ahead of any deduplication or grouping. Disregard any severity a reviewing subagent assigned — they lack the context to grade.
 
-- **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append to `{deferred_work_file}`.
-- **reject** — noise. Drop silently.
+For each finding:
 
-If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
+- **Verify the finding's claim.** At the cited file and line, does the bad outcome the reviewer describes actually occur? Read beyond the changed lines — follow callers, guards upstream, etc — until you can answer yes or no. A different finding about nearby code does not settle this one. Judge whether the problem is real, not whether the proposed fix is plausible. Code that loudly fails on a situation you never showed the program can reach is correct behavior, not a defect.
+- **Render exactly one verdict** from what verification established — the verdict is the whole triage decision; there is no separate keep-or-dismiss.
+  - `high` (intolerable), `medium` (tolerable), `low` (cosmetic or negligible) — the bad outcome is real. Assign severity by how much it hurts end users or developers. For developer-only problems, name where it will cause trouble; a vague "this is messy" with no named harm is not a severity grade — use `false` or `maybe-false` instead. When the harm is real but you cannot tell how bad, pick the higher grade.
+  - `false` — you checked, and the bad outcome does not happen at the cited location. Write what disproves this specific claim. A true fact about nearby code that does not disprove the claim does not count.
+  - `maybe-false` — you could not tell whether the bad outcome happens. Write what you would need to check to find out. Use this only when the diff and surrounding code leave the question open; when they are enough to decide, pick `high`, `medium`, `low`, or `false`.
+- Record every finding with its verdict and evidence; never drop one silently.
+
+Dismiss `false` findings on their refutation.
+
+Dismiss `low` findings when it is unlikely that users or developers would meet the defect in everyday use (judged plainly — no proof needed) and the fix is more than a direct correction or deletion — adding guards, branches, parameters, or other complexity.
+
+All remaining findings continue to grouping.
+
+Group the survivors by shared root cause — two findings belong in one entry only when the same defect produced both. Same location alone is not a shared root cause, and neither is a shared fix. An entry carries every member's verified bad outcome and the highest verdict among them (`high` > `medium` > `low` > `maybe-false`). A group that includes verified `high`, `medium`, or `low` members routes by its highest such verdict — not to defer just because a member is `maybe-false`. Route each entry in this order:
+
+- **patch** — Patch every entry caused or exposed by this change that shows a defect that actually occurs, missing coverage for a specific case, or a broken gate or convention — not a state nothing reaches — and whose smallest fix is trivial, adds no public surface, and guards no state the finding did not demonstrate. Apply that smallest fix immediately.
+- **HALT** — HALT on every entry caused or exposed by this change that shows the same evidence but whose smallest fix fails any of those conditions. Present it to the human for decision before proceeding.
+- **defer** — Defer every other entry: pre-existing issues, improvement ideas, entries whose members are all `maybe-false` and would be `medium` or `high` if true (record that severity marked unverified, plus what would settle it; if it would only be `low`, dismiss it with the same note), and any entry whose fix edits an agent-context document (e.g. CLAUDE.md, AGENTS.md, rules files, specs). Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
+  ```markdown
+  - source_spec: `{spec_file}`
+    summary: <one sentence>
+    evidence: <why this is real; for a maybe-false finding, what evidence would settle it>
+  ```
 
 ### Generate Spec Trace
 
@@ -51,6 +71,7 @@ Write `{spec_file}` using `./spec-template.md`. Fill only these sections — del
 1. **Frontmatter** — set `title: '{title}'`, `type`, `created`, `status: 'done'`. Add `route: 'one-shot'`.
 2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
 3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
+4. **Review Triage Log** — only when the review produced findings: add the section with one line per finding with its verdict and evidence — the refutation for `false`, what would settle it for `maybe-false`, why a dismissed `low` was not worth fixing.
 
 Follow `./sync-sprint-status.md` with `{target_status}` = `review`.
 
@@ -66,7 +87,7 @@ If version control is available and the tree is dirty, create a local commit wit
 2. Display a summary in conversation output, including:
    - The commit hash (if one was created).
    - List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
+   - Review findings breakdown: patches applied, items deferred, and the dismissed count — reasons are recorded in the spec's `## Review Triage Log`. If every finding was dismissed, say so.
    - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
    - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
 3. Offer to push and/or create a pull request.

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

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed at the end of Phase 5 (Close), after the retrospective
 # document is saved and sprint-status is updated. Override wins.

package/src/bmm-skills/4-implementation/wizz-sprint-planning/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after sprint-status.yaml is generated and validated. Override wins.

package/src/bmm-skills/4-implementation/wizz-sprint-status/customize.toml

@@ -30,9 +30,10 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # Scalar: executed when the workflow reaches its final step,
 # after sprint status is summarized and risks are surfaced. Override wins.

package/src/bmm-skills/module.yaml

@@ -1,5 +1,5 @@
 code: bmm
-name: "Wizz Method"
+name: "Wizz Product & Code"
 description: "Full-lifecycle AI agile development: analysis, planning, architecture, implementation"
 default_selected: true # This module will be selected by default for new installations
 

package/src/core-skills/wizz-brainstorming/customize.toml

@@ -22,12 +22,11 @@ activation_steps_append = []
 # Persistent facts the facilitator keeps in mind for the whole session
 # (domain constraints, house rules, stylistic guardrails). Each entry is a
 # literal sentence, a skill prefixed with `skill:`, or a `file:`-prefixed
-# path/glob whose contents are loaded as facts. Default loads project-context.md
-# if wizz-generate-project-context has produced one, giving the facilitator
-# persistent awareness of the project's domain without re-asking.
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
+# path/glob whose contents are loaded as facts.
+# Empty of project-context by default: repo-wide context belongs in CLAUDE.md/AGENTS.md
+# (the Wizz block imports project-context.md there once per session). Add
+# `file:{project-root}/**/project-context.md` here only to load it on every activation.
+persistent_facts = []
 
 # The technique library loaded on demand during the session. Swap the path in
 # team/user TOML to ship a different or extended catalog of creative methods.

package/src/core-skills/wizz-brainstorming/scripts/brain.py

@@ -692,7 +692,26 @@ def html_doc(rows: list[dict]) -> str:
     )
 
 
+def pin_utf8(stream):
+    """Pin a console stream to UTF-8, keeping its own error handler.
+
+    `--extra` technique text and the technique names echoed to stderr are
+    arbitrary user input, so either stream can carry a character the platform
+    default cannot encode (cp1252 on Windows) and print() then raises.
+
+    errors= is passed through deliberately: reconfigure(encoding=...) alone
+    resets the handler to "strict", which would silently downgrade stderr's
+    POSIX default of "backslashreplace" and turn a diagnostic about an
+    undecodable path into a traceback.
+    """
+    reconfigure = getattr(stream, "reconfigure", None)
+    if reconfigure is not None:
+        reconfigure(encoding="utf-8", errors=getattr(stream, "errors", None) or "strict")
+
+
 def main(argv: list[str] | None = None) -> int:
+    pin_utf8(sys.stdout)
+    pin_utf8(sys.stderr)
     p = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
     p.add_argument("--file", type=Path, default=DEFAULT_FILE, help="technique CSV (default: sibling assets/brain-methods.csv)")
     p.add_argument("--extra", type=Path, help="JSON overlay of additional techniques (customize.toml additional_techniques), merged into every command")

package/src/core-skills/wizz-brainstorming/scripts/tests/test_brain.py

@@ -3,6 +3,7 @@
 # dependencies = ["pytest>=8.0"]
 # ///
 """Tests for brain.py. Run: uv run -m pytest scripts/tests/test_brain.py"""
+import io
 import json
 import sys
 from pathlib import Path
@@ -237,3 +238,35 @@ def test_shipped_selector_is_in_sync_with_catalog():
         "assets/brain-selector.html is stale; regenerate: "
         "uv run brain.py html --out assets/brain-selector.html"
     )
+
+
+# --- console encoding (Windows cp1252) ----------------------------------
+
+def _cp1252_stream():
+    """A text stream that behaves like a Windows console: cp1252, strict."""
+    return io.TextIOWrapper(io.BytesIO(), encoding="cp1252", errors="strict", write_through=True)
+
+
+def test_extra_technique_prints_when_stdout_encoding_is_cp1252(lib, tmp_path, monkeypatch):
+    # --extra text is arbitrary user input; the shipped catalog happens to be
+    # cp1252-safe, an overlay is not. Unpinned stdout raises UnicodeEncodeError
+    # and the command exits having printed nothing.
+    overlay = tmp_path / "extra.json"
+    overlay.write_text(
+        json.dumps([{"category": "wild", "technique_name": "Fikir Fırtınası 🌪", "description": "Beyin fırtınası 日本語"}]),
+        encoding="utf-8",
+    )
+    fake = _cp1252_stream()
+    monkeypatch.setattr(sys, "stdout", fake)
+    assert brain.main(["--file", str(lib), "--extra", str(overlay), "list", "--all"]) == 0
+    out = fake.buffer.getvalue().decode("utf-8")
+    assert "Fikir Fırtınası 🌪" in out
+    assert "日本語" in out
+
+
+def test_missing_technique_name_reports_when_stderr_encoding_is_cp1252(lib, monkeypatch):
+    # `show` echoes the name it could not find; that name came from argv.
+    fake = _cp1252_stream()
+    monkeypatch.setattr(sys, "stderr", fake)
+    assert brain.main(["--file", str(lib), "show", "日本語"]) == 1
+    assert "日本語" in fake.buffer.getvalue().decode("utf-8")

package/src/core-skills/wizz-forge-idea/scripts/resolve_personas.py

@@ -126,7 +126,9 @@ def load_party_workflow(project_root: Path, party_skill: Path):
         except (OSError, json.JSONDecodeError):
             pass
     resolver = project_root / "_wizz" / "scripts" / "resolve_customization.py"
-    data = _run_json([sys.executable, str(resolver), "--skill", str(party_skill), "--key", "workflow"])
+    data = _run_json(
+        [sys.executable, str(resolver), "--skill", str(party_skill), "--project-root", str(project_root), "--key", "workflow"]
+    )
     if data is not None and isinstance(data.get("workflow"), dict):
         return data["workflow"]
     # Fallback: base customize.toml directly, no override merge.

package/src/core-skills/wizz-forge-idea/scripts/tests/test_resolve_personas.py

@@ -5,6 +5,7 @@
 """Unit tests for resolve_personas.py — pool merge, alias, party resolution."""
 
 import sys
+import tempfile
 import unittest
 from pathlib import Path
 
@@ -134,5 +135,25 @@ class TestOverrideMergeFallback(unittest.TestCase):
             self.assertEqual([m["code"] for m in wf["party_members"]], ["x", "y"])  # appended
 
 
+class TestPassesProjectRootToResolver(unittest.TestCase):
+    """Sem snapshot, o wrapper chama resolve_customization.py; a raiz vai explícita (BMAD 6.12, #2802)."""
+
+    def _captured_command(self, tmp):
+        captured = []
+        original = rp._run_json
+        rp._run_json = lambda cmd: captured.append(cmd) or {"workflow": {}}
+        try:
+            rp.load_party_workflow(Path(tmp) / "project", Path(tmp) / "skill")
+        finally:
+            rp._run_json = original
+        return captured[0]
+
+    def test_passes_project_root_to_the_customization_resolver(self):
+        with tempfile.TemporaryDirectory() as tmp:
+            cmd = self._captured_command(tmp)
+            self.assertIn("--project-root", cmd)
+            self.assertEqual(cmd[cmd.index("--project-root") + 1], str(Path(tmp) / "project"))
+
+
 if __name__ == "__main__":
     unittest.main()