wizz-method 2.8.0 → 2.8.1

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "2.8.0",
+  "version": "2.8.1",
   "description": "Wizz Method: método de agência orientado por IA em PT-BR",
   "keywords": [
     "agile",
@@ -59,7 +59,8 @@
     "lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
     "lint:md": "markdownlint-cli2 \"**/*.md\"",
     "prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
-    "quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:install && npm run test:urls && npm run validate:refs && npm run validate:registry-schema && npm run validate:method-refs && npm run validate:skills && npm run docs:validate-sidebar && npm run validate:generated",
+    "quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run quality:validate",
+    "quality:validate": "npm test && npm run validate:refs && npm run validate:registry-schema && npm run validate:method-refs && npm run validate:skills && npm run docs:validate-sidebar && npm run validate:generated && npm run eval:routing && npm run eval:output",
     "rebundle": "node tools/bundle-web-bundles.js",
     "sync:check": "node tools/sync-check.mjs",
     "sync:global": "node tools/sync-global.mjs",
@@ -136,29 +137,24 @@
       "markdownlint-cli2"
     ]
   },
-  "overrides": {
-    "markdownlint-cli2": {
-      "js-yaml": "^4.3.0",
-      "markdown-it": "^14.2.0"
-    }
-  },
   "dependencies": {
     "@clack/core": "^1.3.1",
     "@clack/prompts": "^1.4.0",
     "@kayvan/markdown-tree-parser": "^1.6.1",
     "chalk": "^4.1.2",
     "commander": "^14.0.0",
-    "csv-parse": "^6.1.0",
+    "csv-parse": "^7.0.2",
     "picocolors": "^1.1.1",
     "semver": "^7.6.3",
     "smol-toml": "^1.8.0",
     "yaml": "^2.7.0"
   },
   "devDependencies": {
+    "@astrojs/markdown-remark": "^7.3.1",
     "@astrojs/sitemap": "^3.6.0",
-    "@astrojs/starlight": "^0.37.5",
+    "@astrojs/starlight": "^0.42.2",
     "@eslint/js": "^9.33.0",
-    "astro": "^5.16.0",
+    "astro": "^7.3.3",
     "eslint": "^9.33.0",
     "eslint-config-prettier": "^10.1.8",
     "eslint-plugin-n": "^17.21.3",
@@ -166,13 +162,12 @@
     "eslint-plugin-yml": "^1.18.0",
     "husky": "^9.1.7",
     "lint-staged": "^16.1.1",
-    "markdownlint-cli2": "^0.19.1",
+    "markdownlint-cli2": "^0.23.3",
     "prettier": "^3.7.4",
     "prettier-plugin-packagejson": "^2.5.19",
-    "sharp": "^0.33.5",
+    "sharp": "^0.35.4",
     "unist-util-visit": "^5.1.0",
-    "yaml-eslint-parser": "^1.2.3",
-    "yaml-lint": "^1.7.0"
+    "yaml-eslint-parser": "^1.2.3"
   },
   "engines": {
     "node": ">=20.12.0"

package/skills-registry.yaml

@@ -302,7 +302,7 @@ areas:
       # eval mostrava o custo: "qual prazo de garantia?" respondia copy,
       # growth ou ads em amostras diferentes, porque as três estavam certas.
       - id: wizz-copywriting
-        when: "Escrever copy de venda/página/headline do zero ou reescrever."
+        when: "Escrever copy de venda/página/headline do zero ou reescrever. Na página de vendas completa, incluir wizz-offer-forge se faltar oferta aprovada e wizz-page-cro se faltar estrutura de conversão aprovada; headline/CTA isolado ou texto sobre oferta e estrutura já aprovadas não exige refazê-las."
         rel:
           after: [pesquisa-de-publico-do-piva, wizz-offer-forge]
           before: [wizz-copy-editing]
@@ -415,7 +415,7 @@ areas:
         rel:
           pairs_with: [wizz-churn-prevention]
       - id: wizz-page-cro
-        when: "Otimizar conversão de página (home, landing, pricing, feature)."
+        when: "Estruturar ou otimizar conversão de página (home, landing, página de vendas, pricing, feature): hierarquia, CTA, prova e objeções. Inclui página nova/pré-lançamento junto da copy, sem exigir métricas existentes; não é apenas otimização pós-lançamento."
         rel:
           after: [wizz-tracking-audit]
           pairs_with: [wizz-copywriting, wizz-form-cro, wizz-popup-cro]
@@ -440,7 +440,7 @@ areas:
         rel:
           pairs_with: [scrapling, wizz-sales-enablement]
       - id: wizz-referral-program
-        when: "Programa de indicação/afiliados."
+        when: "Desenhar ou otimizar programa de indicação/afiliados: um plano de mecânica, incentivos, regras e atribuição. Suas etapas internas não são entregas de outras áreas. Produzir uma campanha de emails, uma nova página ou código de integração são entregas adicionais, somente quando solicitadas; não são implícitas em montar o programa."
         rel:
           pairs_with: [wizz-analytics-tracking, wizz-email-sequence]
       - id: wizz-free-tool-strategy
@@ -468,7 +468,7 @@ areas:
         rel:
           after: [pesquisa-de-publico-do-piva, wizz-lowticket-minerador]
           before: [wizz-copywriting]
-          pairs_with: [wizz-pricing-strategy]
+          pairs_with: [wizz-pricing-strategy, wizz-lowticket-metodologia]
       # Módulo lowticket (src/modules/lowticket) — ver nota em ads.skills. Desde
       # 2026-09-18 o módulo inteiro mora aqui (um dono por skill): copy e ads
       # chegam nele pelo `rel`. Isto é comentário de propósito — escrever "vale
@@ -490,7 +490,7 @@ areas:
           - "SaaS, B2B, site de cliente, high ticket ou mentoria: os números não transferem."
         rel:
           after: [wizz-lowticket-guia]
-          pairs_with: [wizz-copywriting, wizz-lowticket-pagina, wizz-lowticket-trafego]
+          pairs_with: [wizz-copywriting, wizz-lowticket-pagina, wizz-lowticket-trafego, wizz-offer-forge]
       - id: wizz-lowticket-funil
         module: lowticket
         when: "Escada pós-checkout de low ticket: upsell 1, upsell 2, downsell, oferta final, régua de preço por degrau e copy das páginas."

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

@@ -1,6 +1,6 @@
 # Review Economy
 
-Shared rules that keep the review layers on the Forte tier (`opus` in Claude Code) while cutting what they read and how many of them run. Two byte-identical copies live in `wizz-code-review/references/review-economy.md` and `wizz-quick-dev/references/review-economy.md`. Diffs are built with plain git commands; the tier is picked by session judgment.
+Shared rules that keep the review layers on the Strong tier (`opus` in Claude Code) while cutting what they read and how many of them run. Two byte-identical copies live in `wizz-code-review/references/review-economy.md` and `wizz-quick-dev/references/review-economy.md`. Diffs are built with plain git commands; the tier is picked by session judgment.
 
 ## 1. Build the diff
 
@@ -27,7 +27,7 @@ Every diff command here runs against the repository root, never a bare `.`: comp
 
 ## 2. Pick the tier (session judgment)
 
-| Tier | Rule | Active layers | Forte subagents |
+| Tier | Rule | Active layers | Strong subagents |
 |---|---|---|---|
 | `small` | at most 3 files and 80 changed lines (after exclusion), no critical hit | `blind-verification` | 1 |
 | `normal` | anything above `small`, no critical hit | `blind-verification`, `edge-case-hunter` | 2 |
@@ -59,10 +59,10 @@ When the brief names a `review-prompts/` file, that file owns the method and the
 
 ## 4. Decide who triages
 
-The Forte tier is defined in `_shared/model-ladder.md`.
+The Strong 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-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.
+- **Session runs on the Strong 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 Strong 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/SKILL.md

@@ -39,6 +39,8 @@ You are the leaf: the maestro demotes here for pointed work (bug, tweak, single-
 
 **Dispatch rule:** IF 2+ areas → `wizz-maestro`, always. ELSE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → `wizz-maestro`. The area clause decides on its own, without summing with anything else.
 
+**Decision order — capabilities → required relations → areas → shortcuts.** Match the catalogue entries, inspect their `rel`, and include only capabilities needed for the requested deliverable and not already supplied in the context. Resolve their owning areas before applying ANY one-area shortcut. One artifact can require multiple areas; the word "copy" does not prove that only copy is needed. For full sales-page copy, if either the offer or the conversion structure is missing from the supplied context, include the missing capability: `wizz-offer-forge` for the offer and/or `wizz-page-cro` for conversion structure (growth), alongside `wizz-copywriting` (copy); route to maestro. Do not assume those inputs are ready merely because the user did not mention them. If both are already approved and the request is limited to text, keep copy-only work in copy. An isolated headline or CTA does not require redesigning the whole page. Optional neighbours and separate deliverables do not add areas; `pairs_with` alone never escalates.
+
 - If clarification reveals the request is actually **multi-goal / multi-area** (2+ top-level shippable deliverables, or it spans several areas), do not silently absorb it. That is clause 1: escalate regardless of how light each individual part looks. Surface it and propose escalating to `wizz-maestro` to orchestrate the sequence. Proceed solo only if the user confirms a narrowed single goal.
 - If it is genuinely single-area but hits 2+ of the remaining factors (multi-step, needs planning, produces a memorable artifact), also escalate. Do not silently absorb heavy single-area work either.
 - **Count those factors with the objective test** (canonical source: `_shared/complexity-signal.md`; same test the Diretor and the maestro apply). **When in doubt, the factor does NOT count.** *Multi-step* = the delivery is 2+ artifacts of different kinds (a batch of the same kind is ONE delivery). *Needs planning* = a scope or ordering decision is missing that the user has not made; "work that has internal steps" does not count, every task has internal steps. *Memorable artifact* = a reference document someone reopens later (PRD, story, spec, written plan or audit); a fix, a component or a refactor of one module is not. A **single delivery** and the **diagnosis of one specific mechanism** stay with you, however important they look; what escalates is the request of **open scope that the request itself does not delimit** ("how do I improve / reduce X" is that, a question with a single definable answer is not), and what escalates regardless of size is a **sensitive subsystem**: changing auth/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery, because getting it wrong breaks something other than the delivery itself (people locked out, money charged twice, data lost). Running a test against one of those is not changing it. **Changing the product's code is yours even when the subject is visual** — a button colour, mobile spacing: the delivery is a commit, and `designer` decides the look without shipping the change.

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

@@ -1,6 +1,6 @@
 # Review Economy
 
-Shared rules that keep the review layers on the Forte tier (`opus` in Claude Code) while cutting what they read and how many of them run. Two byte-identical copies live in `wizz-code-review/references/review-economy.md` and `wizz-quick-dev/references/review-economy.md`. Diffs are built with plain git commands; the tier is picked by session judgment.
+Shared rules that keep the review layers on the Strong tier (`opus` in Claude Code) while cutting what they read and how many of them run. Two byte-identical copies live in `wizz-code-review/references/review-economy.md` and `wizz-quick-dev/references/review-economy.md`. Diffs are built with plain git commands; the tier is picked by session judgment.
 
 ## 1. Build the diff
 
@@ -27,7 +27,7 @@ Every diff command here runs against the repository root, never a bare `.`: comp
 
 ## 2. Pick the tier (session judgment)
 
-| Tier | Rule | Active layers | Forte subagents |
+| Tier | Rule | Active layers | Strong subagents |
 |---|---|---|---|
 | `small` | at most 3 files and 80 changed lines (after exclusion), no critical hit | `blind-verification` | 1 |
 | `normal` | anything above `small`, no critical hit | `blind-verification`, `edge-case-hunter` | 2 |
@@ -59,10 +59,10 @@ When the brief names a `review-prompts/` file, that file owns the method and the
 
 ## 4. Decide who triages
 
-The Forte tier is defined in `_shared/model-ladder.md`.
+The Strong 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-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.
+- **Session runs on the Strong 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 Strong 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/modules/wizz/agents/wizz-maestro/SKILL.md

@@ -86,6 +86,8 @@ In short: **the menu chooses the agent, the registry chooses the skill(s) and th
 
 **Dispatch rule:** IF 2+ areas → maestro (you), always. OTHERWISE count the 3 remaining factors (multi-step, needs planning, generates a memorable artifact); 2+ factors → maestro (you). The area clause decides on its own, without adding up with anything else.
 
+**Decision order — capabilities → required relations → areas → shortcuts.** Match the catalogue entries, inspect their `rel`, and include only capabilities needed for the requested deliverable and not already supplied in the context. Resolve their owning areas before applying ANY one-area shortcut. One artifact can require multiple areas; the word "copy" does not prove that only copy is needed. For full sales-page copy, if either the offer or the conversion structure is missing from the supplied context, include the missing capability: `wizz-offer-forge` for the offer and/or `wizz-page-cro` for conversion structure (growth), alongside `wizz-copywriting` (copy); route to maestro. Do not assume those inputs are ready merely because the user did not mention them. If both are already approved and the request is limited to text, keep copy-only work in copy. An isolated headline or CTA does not require redesigning the whole page. Optional neighbours and separate deliverables do not add areas; `pairs_with` alone never escalates.
+
 1. **Areas**: just 1, or several? (clause 1: 2+ decides on its own, without adding up with anything else)
 2. **Steps** — a one-off tweak, or multi-step?
 3. **Planning** — can it go straight ahead, or does it need planning first?

package/src/skills-lib/_shared/complexity-signal.md

@@ -12,6 +12,8 @@
 
 Dispatch rule: IF 2+ areas → maestro, always. OTHERWISE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → maestro. The area clause decides on its own, without summing with anything else.
 
+**Decision order — capabilities → required relations → areas → shortcuts.** Match the catalogue entries, inspect their `rel`, and include only capabilities needed for the requested deliverable and not already supplied in the context. Resolve their owning areas before applying ANY one-area shortcut. One artifact can require multiple areas; the word "copy" does not prove that only copy is needed. For full sales-page copy, if either the offer or the conversion structure is missing from the supplied context, include the missing capability: `wizz-offer-forge` for the offer and/or `wizz-page-cro` for conversion structure (growth), alongside `wizz-copywriting` (copy); route to maestro. Do not assume those inputs are ready merely because the user did not mention them. If both are already approved and the request is limited to text, keep copy-only work in copy. An isolated headline or CTA does not require redesigning the whole page. Optional neighbours and separate deliverables do not add areas; `pairs_with` alone never escalates.
+
 What you count are the areas of the catalogue ENTRIES the request matches — never the topics named in the sentence. "Full audit of the site: performance, SEO, security, accessibility" names four topics and matches one entry (`wizz-launch-readiness`, qa), whose four legs are that single audit's own scope, not four deliverables: one area, so `agent:qa`. Counting nouns instead of entries is the most common way to over-escalate. (Owner's decision, 2026-09-19.)
 
 ## How to count (added 2026-09-18)

package/src/skills-lib/wizz-ad-creative/SKILL.md

@@ -15,7 +15,9 @@ You are an expert performance creative strategist. Your goal is to generate high
 If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
 
 **Check for the low ticket base:**
-If the `wizz-lowticket-metodologia` skill is installed in this project, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `04` (creative structure and rules), `04c` (video creative script) and `04b` (formats and swipe file). Where that shard contradicts this skill, **the shard wins**, and say so in your reply. Without that skill installed, nothing changes.
+The low ticket base applies only when BOTH are true: the `wizz-lowticket-metodologia` skill is installed in this project, AND the project context or the request itself (including what the user answers while you gather context) establishes that the operation is low ticket (price range, cheap product, direct traffic). When both hold, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `04` (creative structure and rules), `04c` (video creative script) and `04b` (formats and swipe file). Where that shard contradicts this skill, **the shard wins**, and say so in your reply.
+
+If neither the project context nor the request says so, this skill's defaults win: do not presume low ticket because the page is a sales page, the product is a course, or a campaign is running. SaaS, B2B, client sites, high ticket and mentorship are outside the base: do not load it, its numbers do not transfer. Without that skill installed, nothing changes.
 
 Gather this context (ask if not provided):
 

package/src/skills-lib/wizz-copywriting/SKILL.md

@@ -11,11 +11,15 @@ You are an expert conversion copywriter. Your goal is to write marketing copy th
 
 ## Before Writing
 
+**Check the scope of a full sales page.** Reuse an approved offer and conversion structure when supplied. If either is missing, invoke the `wizz-offer-forge` skill for the offer and the `wizz-page-cro` skill for conversion structure as needed; inside a Wizz project the maestro coordinates this copy + growth work. CRO structure also applies before launch, not only after metrics exist. A single headline/CTA or text-only work within an approved structure stays a copy task; do not reopen decisions the user has already made.
+
 **Check for product marketing context first:**
 If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
 
 **Check for the low ticket base:**
-If the `wizz-lowticket-metodologia` skill is installed in this project, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `12c` (anatomy of the low ticket page), `18` (copy from desire to offer, the 7 blocks) and, for a VSL, `04b` §4.7 and §4.7-A. Where that shard contradicts this skill, **the shard wins**, and say so in your reply. Without that skill installed, nothing changes.
+The low ticket base applies only when BOTH are true: the `wizz-lowticket-metodologia` skill is installed in this project, AND the project context or the request itself (including what the user answers while you gather context) establishes that the operation is low ticket (price range, cheap product, direct traffic). When both hold, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `12c` (anatomy of the low ticket page), `18` (copy from desire to offer, the 7 blocks) and, for a VSL, `04b` §4.7 and §4.7-A. Where that shard contradicts this skill, **the shard wins**, and say so in your reply.
+
+If neither the project context nor the request says so, this skill's defaults win: do not presume low ticket because the page is a sales page, the product is a course, or a campaign is running. SaaS, B2B, client sites, high ticket and mentorship are outside the base: do not load it, its numbers do not transfer. Without that skill installed, nothing changes.
 
 Gather this context (ask if not provided):
 

package/src/skills-lib/wizz-offer-forge/SKILL.md

@@ -40,7 +40,9 @@ Then, consult existing context or ask the user:
 
 ### Step 0.5 — The Local Ruler Takes Precedence
 
-If the `wizz-lowticket-metodologia` skill is installed in this project, read its INDEX entries for **offer, price, and guarantee** and use those values as the ruler above this skill's defaults (price ranges, upsell multiplier, guarantee period). State in your reply which ruler is in effect. Where the local ruler contradicts this skill, **the local ruler wins**.
+The low ticket base applies only when BOTH are true: the `wizz-lowticket-metodologia` skill is installed in this project, AND the project context or the request itself (including what the user answers while you gather context) establishes that the operation is low ticket (price range, cheap product, direct traffic). The business model answered in Step 0 counts: Low-ticket establishes it, High-ticket / Mentorship rules it out. When both hold, read its INDEX entries for **offer, price, and guarantee** and use those values as the ruler above this skill's defaults (price ranges, upsell multiplier, guarantee period). State in your reply which ruler is in effect. Where the local ruler contradicts this skill, **the local ruler wins**.
+
+If neither the project context nor the request says so, this skill's defaults win: do not presume low ticket because the page is a sales page, the product is a course, or a campaign is running. SaaS, B2B, client sites, high ticket and mentorship are outside the base: do not load it, its numbers do not transfer.
 
 Without that skill installed, follow this skill's defaults. Nothing changes.
 

package/src/skills-lib/wizz-page-cro/SKILL.md

@@ -11,11 +11,15 @@ You are a conversion rate optimization expert. Your goal is to analyze marketing
 
 ## Initial Assessment
 
+**New pages and drafts are in scope.** Use this framework to define or review conversion structure before launch as well as to optimize an existing page. For a new sales page, work with the copy on hierarchy, CTA placement, proof and objections; existing traffic or conversion metrics are not prerequisites. If metrics do not exist, state that limitation and propose testable hypotheses, not measured uplift. An isolated text edit with an approved structure does not require a new CRO engagement. Invoke the `wizz-copywriting` skill for the copy itself.
+
 **Check for product marketing context first:**
 If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
 
 **Check for the low ticket base:**
-If the `wizz-lowticket-metodologia` skill is installed in this project, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `12c` (anatomy of the low ticket page), `06` (sales page) and `02` (funnel diagnosis: which transition is leaking). Where that shard contradicts this skill, **the shard wins**, and say so in your reply. Without that skill installed, nothing changes.
+The low ticket base applies only when BOTH are true: the `wizz-lowticket-metodologia` skill is installed in this project, AND the project context or the request itself (including what the user answers while you gather context) establishes that the operation is low ticket (price range, cheap product, direct traffic). When both hold, read its `knowledge/INDEX.md` and `knowledge/guardrails.md` first and load the one shard the INDEX names for this task; the usual ones here are `12c` (anatomy of the low ticket page), `06` (sales page) and `02` (funnel diagnosis: which transition is leaking). Where that shard contradicts this skill, **the shard wins**, and say so in your reply.
+
+If neither the project context nor the request says so, this skill's defaults win: do not presume low ticket because the page is a sales page, the product is a course, or a campaign is running. SaaS, B2B, client sites, high ticket and mentorship are outside the base: do not load it, its numbers do not transfer. Without that skill installed, nothing changes.
 
 Before providing recommendations, identify:
 

package/src/skills-lib/wizz-referral-program/SKILL.md

@@ -11,6 +11,8 @@ You are an expert in viral growth and referral marketing. Your goal is to help d
 
 ## Before Starting
 
+**Bound the requested deliverable.** A request to set up a referral program starts with one program plan: mechanics, incentives, rules and attribution. The design steps and launch checklist below are parts of that plan, not permission to implement every listed item. Consider related email and tracking capabilities, but do not turn example invitations into a separate production campaign. Writing and sending a campaign, building a new page, or changing integration/payment code are additional deliverables only when requested; use the normal multi-area and sensitive-subsystem rules for those requests. For a program plan alone, stay with its growth owner.
+
 **Check for product marketing context first:**
 If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
 

package/src/skills-lib/wizz-router/SKILL.md

@@ -40,6 +40,8 @@ Assess the **Area**: how many areas does the request touch? The canonical area l
 
 **Dispatch rule:** IF 2+ areas → `wizz-maestro`, always. OTHERWISE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → `wizz-maestro`. The area clause decides on its own, without combining with anything else.
 
+**Decision order — capabilities → required relations → areas → shortcuts.** Match the catalogue entries, inspect their `rel`, and include only capabilities needed for the requested deliverable and not already supplied in the context. Resolve their owning areas before applying ANY one-area shortcut. One artifact can require multiple areas; the word "copy" does not prove that only copy is needed. For full sales-page copy, if either the offer or the conversion structure is missing from the supplied context, include the missing capability: `wizz-offer-forge` for the offer and/or `wizz-page-cro` for conversion structure (growth), alongside `wizz-copywriting` (copy); route to maestro. Do not assume those inputs are ready merely because the user did not mention them. If both are already approved and the request is limited to text, keep copy-only work in copy. An isolated headline or CTA does not require redesigning the whole page. Optional neighbours and separate deliverables do not add areas; `pairs_with` alone never escalates.
+
 **What you count are the areas of the catalogue ENTRIES the request matches — never the topics named in the sentence.** A request can name four subjects and still match one entry, and then it is one area. "Full audit of the site: performance, SEO, security, accessibility" names four topics and matches `wizz-launch-readiness` (qa), whose `when:` already spans build, security, SEO, analytics, content, legal and infra: those four legs are that single audit's own scope, not four deliverables, so the answer is `agent:qa`. Counting nouns instead of entries is the most common way to over-escalate. (Owner's decision, 2026-09-19.)
 
 - **2+ areas → `wizz-maestro`, always.** It's the Manager: coordinates agents across areas, sets up the sequence, upholds the memory duty. Invoke via `Skill` and **stop here**.

package/tools/hooks/wizz-router-enforce.js

@@ -123,12 +123,12 @@ function findWizzRoot(startDir) {
 function buildContext(isWizzProject) {
   if (isWizzProject) {
     return (
-      '🎛️ Projeto Wizz: NÃO invoque wizz-router. 2+ áreas → `wizz-maestro`. ' +
+      '🎛️ Wizz: NÃO invoque wizz-router. Capacidades → rel necessário à entrega → áreas → atalhos. 2+ áreas → `wizz-maestro`. ' +
       '1 área: 2+ fatores (multi-passo, planejar, artefato memorável) → `wizz-maestro`; ' +
-      'senão → Skill da área (wizz-designer, wizz-quick-dev). ' +
+      'senão → Skill da área. ' +
       'Auth/pagamento/permissão/migração → maestro. ' +
       'Personas são skills, não subagent_type; Agent usa tipos disponíveis wizz-exec-*' +
-      '; difícil → wizz-exec-strong (ESCALAR → ultra). Trivial → direto.'
+      '; difícil → wizz-exec-strong (ESCALAR → ultra).'
     );
   }
   return (

package/tools/installer/core/installer.js

@@ -1502,6 +1502,7 @@ class Installer {
       '  Get started:',
       `    1. Launch your AI agent from your project folder`,
       `    2. Not sure what to do? Invoke the ${color.cyan('wizz-help')} skill and ask it what to do!`,
+      `    Recommended session: use the Standard tier; consult the model ladder for platform-specific mappings.`,
       '',
       `    Docs and Guides: ${color.blue('https://method.wizzcomms.com/')}`,
       `    Support: ${color.blue('support@wizzcomms.com')}`,

package/tools/installer/ide/_config-driven.js

@@ -1,4 +1,5 @@
 const path = require('node:path');
+const nativeFsp = require('node:fs/promises');
 const fs = require('../fs-native');
 const yaml = require('yaml');
 const prompts = require('../prompts');
@@ -58,6 +59,22 @@ function isSafeCanonicalId(value) {
 // OpenCode's native `@skills/<id>` skill-reference syntax.
 const DEFAULT_COMMANDS_BODY_TEMPLATE = '@skills/{canonicalId}';
 
+// Native Wizz execution tiers have a deliberately small, known vocabulary.
+// Do not infer ownership from the `wizz-exec-` prefix alone: users can (and do)
+// create their own agents with that prefix.
+const CURRENT_SUBAGENT_TIERS = new Set(['mechanical', 'standard', 'strong', 'ultra', 'review']);
+const LEGACY_SUBAGENT_TIERS = new Set(['haiku', 'sonnet', 'opus']);
+
+function subagentTierFromName(fileName) {
+  const match = fileName.match(/^wizz-exec-([a-z0-9][a-z0-9-]*)\.(?:md|toml)$/i);
+  return match ? match[1].toLowerCase() : null;
+}
+
+function isRecognizedSubagentName(fileName, sourceNames = new Set()) {
+  const tier = subagentTierFromName(fileName);
+  return tier && (CURRENT_SUBAGENT_TIERS.has(tier) || LEGACY_SUBAGENT_TIERS.has(tier) || sourceNames.has(fileName));
+}
+
 // Is this skill a persona agent (vs. a workflow/tool/standalone skill)?
 // Used by platforms that surface only persona agents (e.g. Copilot's Custom
 // Agents picker). Signal: the skill's source `customize.toml` has an
@@ -207,7 +224,9 @@ class ConfigDrivenIdeSetup {
         results.commands = await this.installCommandPointers(projectDir, wizzDir, this.installerConfig, options);
       }
       if (this.installerConfig.agents_target_dir) {
-        results.subagents = await this.installSubagents(projectDir, wizzDir, this.installerConfig);
+        results.subagents = await this.installSubagents(projectDir, wizzDir, this.installerConfig, options);
+        results.subagentReport = this.lastSubagentReport;
+        results.subagentCleanupReport = this.lastSubagentCleanupReport;
       }
       return { success: true, results };
     }
@@ -243,7 +262,9 @@ class ConfigDrivenIdeSetup {
     }
 
     if (config.agents_target_dir) {
-      results.subagents = await this.installSubagents(projectDir, wizzDir, config);
+      results.subagents = await this.installSubagents(projectDir, wizzDir, config, options);
+      results.subagentReport = this.lastSubagentReport;
+      results.subagentCleanupReport = this.lastSubagentCleanupReport;
     }
 
     await this.printSummary(results, target_dir, options);
@@ -466,21 +487,19 @@ class ConfigDrivenIdeSetup {
    * format that field means anything to. This mirrors how
    * `installVerbatimSkills` resolves module-relative source paths.
    *
-   * Ownership is scoped to the `wizz-exec-*` naming convention (`.md` or
-   * `.toml` extension) — only files matching that pattern are ever written
-   * here, so a user's own hand-authored subagents in the same directory are
-   * never touched. Directory entries (including the per-platform subdirs
-   * that live alongside Claude Code's root-level files) are skipped
-   * explicitly rather than relying on the extension filter to exclude them.
+   * Ownership is scoped to recognized Wizz tier names, not merely the
+   * `wizz-exec-*` naming convention (`.md` or `.toml` extension). A user's
+   * own hand-authored `wizz-exec-*` subagents are left untouched. Directory
+   * entries (including the per-platform subdirs that live alongside Claude
+   * Code's root-level files) are skipped explicitly.
    * Silently no-ops when the source directory doesn't exist (e.g. install
    * without the wizz module).
    *
    * Tier names in the target dir are current (mechanical, standard, strong,
-   * ultra, review); a legacy tier from ladder v1 (wizz-exec-haiku/sonnet/opus)
-   * or a stale tier a platform's source no longer provides (e.g. an ultra
-   * file on a platform without an ultra tier) never lingers here — setup()
-   * runs cleanup() before installSubagents, and cleanup()'s cleanupSubagents
-   * already removed every wizz-exec-*.{md,toml} file from the target dir.
+   * ultra, review); legacy ladder-v1 tiers are recognized for migration. A
+   * stale tier a platform's source no longer provides is removed only after
+   * being backed up, because its old source may no longer be available for
+   * comparison.
    *
    * @param {string} projectDir - Project directory
    * @param {string} wizzDir - WIZZ installation directory
@@ -488,7 +507,15 @@ class ConfigDrivenIdeSetup {
    *   and the optional agents_source_subdir
    * @returns {Promise<number>} Count of subagent files installed
    */
-  async installSubagents(projectDir, wizzDir, config) {
+  async installSubagents(projectDir, wizzDir, config, options = {}) {
+    const report = {
+      installed: 0,
+      preserved: 0,
+      backups: 0,
+      failures: [],
+    };
+    this.lastSubagentReport = report;
+
     const sourceDir = config.agents_source_subdir
       ? path.join(wizzDir, 'wizz', 'subagents', config.agents_source_subdir)
       : path.join(wizzDir, 'wizz', 'subagents');
@@ -497,7 +524,8 @@ class ConfigDrivenIdeSetup {
     let entries;
     try {
       entries = await fs.readdir(sourceDir, { withFileTypes: true });
-    } catch {
+    } catch (error) {
+      await this._reportSubagentFailure('read source directory', sourceDir, error, options, report);
       return 0;
     }
 
@@ -507,12 +535,53 @@ class ConfigDrivenIdeSetup {
     if (subagentFiles.length === 0) return 0;
 
     const targetPath = path.join(projectDir, config.agents_target_dir);
-    await fs.ensureDir(targetPath);
+    try {
+      await fs.ensureDir(targetPath);
+    } catch (error) {
+      await this._reportSubagentFailure('create target directory', targetPath, error, options, report);
+      return 0;
+    }
 
     let count = 0;
     for (const entry of subagentFiles) {
-      await fs.copy(path.join(sourceDir, entry.name), path.join(targetPath, entry.name), { overwrite: true });
-      count++;
+      const sourcePath = path.join(sourceDir, entry.name);
+      const targetFile = path.join(targetPath, entry.name);
+      try {
+        let targetStat;
+        try {
+          targetStat = await nativeFsp.lstat(targetFile);
+        } catch (error) {
+          if (error.code !== 'ENOENT') throw error;
+        }
+        if (targetStat) {
+          if (!targetStat.isFile()) {
+            report.preserved++;
+            await this._reportSubagentFailure(
+              'skip non-file target',
+              targetFile,
+              new Error('target is not a regular file'),
+              options,
+              report,
+            );
+            continue;
+          }
+          const existing = await fs.readFile(targetFile, 'utf8');
+          const source = await fs.readFile(sourcePath, 'utf8');
+          if (existing !== source) {
+            const backupPath = await this._backupSubagentFile(targetFile, options, report);
+            if (!backupPath) {
+              report.preserved++;
+              continue;
+            }
+            report.backups++;
+          }
+        }
+        await fs.copy(sourcePath, targetFile, { overwrite: true });
+        count++;
+        report.installed++;
+      } catch (error) {
+        await this._reportSubagentFailure('install', targetFile, error, options, report);
+      }
     }
 
     return count;
@@ -544,6 +613,15 @@ class ConfigDrivenIdeSetup {
     if (results.subagents > 0 && this.installerConfig?.agents_target_dir) {
       await prompts.log.success(`${this.name} subagents: ${results.subagents} → ${this.installerConfig.agents_target_dir}`);
     }
+    const subagentReport = results.subagentReport;
+    const cleanupReport = results.subagentCleanupReport;
+    const operationFailures = (subagentReport?.failures?.length || 0) + (cleanupReport?.failures?.length || 0);
+    if (operationFailures > 0) {
+      await prompts.log.warn(`  (${operationFailures} subagent file operation(s) failed — see warnings above)`);
+    }
+    if (subagentReport?.preserved > 0 && !options.silent) {
+      await prompts.log.message(`  (${subagentReport.preserved} custom subagent file(s) preserved)`);
+    }
   }
 
   /**
@@ -614,14 +692,12 @@ class ConfigDrivenIdeSetup {
       );
     }
 
-    // Clean stale wizz-exec-* subagent files (.md or .toml). Like command
+    // Clean recognized Wizz subagent files (.md or .toml). Like command
     // pointers, these live in a per-IDE directory (e.g. .claude/agents,
-    // .codex/agents) that isn't deduped across peers, so this runs
-    // regardless of skipTarget. installSubagents always overwrites with the
-    // current source content, so unconditional removal here is safe — a
-    // routine reinstall just recreates the files moments later.
+    // .codex/agents) that isn't deduped across peers, so this runs regardless
+    // of skipTarget. Customized files are backed up before replacement.
     if (this.installerConfig?.agents_target_dir) {
-      await this.cleanupSubagents(projectDir, this.installerConfig.agents_target_dir);
+      await this.cleanupSubagents(projectDir, this.installerConfig, options, resolvedWizzDir);
     }
 
     // Skip target_dir cleanup when a peer platform owns this directory
@@ -787,45 +863,147 @@ class ConfigDrivenIdeSetup {
   }
 
   /**
-   * Remove WIZZ-owned `wizz-exec-*` subagent files (`.md` or `.toml`) from
-   * the platform's subagent directory (e.g. .claude/agents, .codex/agents).
-   * Symmetric counterpart to installSubagents. Only touches files matching
-   * that naming convention — a user's own hand-authored subagents in the
-   * same directory are never removed. Removes the directory entirely if it
-   * ends up empty.
+   * Remove only recognized Wizz subagents. A matching filename is not enough
+   * to establish ownership: custom `wizz-exec-*` agents remain in place.
+   * When a recognized file is customized, move it to a recoverable backup
+   * before cleanup/replacement so an update never destroys user work.
+   *
+   * The second argument accepts the historical target-dir string as well as
+   * the installer config. Keeping the string form makes this method useful to
+   * callers and older integrations that invoke it directly.
+   *
    * @param {string} projectDir
-   * @param {string} agentsTargetDir - Relative dir (e.g. .claude/agents)
+   * @param {string|Object} agentsTargetOrConfig
+   * @param {Object} [options]
+   * @param {string|null} [wizzDir]
+   * @returns {Promise<Object>} cleanup report
    */
-  async cleanupSubagents(projectDir, agentsTargetDir) {
+  async cleanupSubagents(projectDir, agentsTargetOrConfig, options = {}, wizzDir = null) {
+    const config = typeof agentsTargetOrConfig === 'string' ? { agents_target_dir: agentsTargetOrConfig } : agentsTargetOrConfig || {};
+    const agentsTargetDir = config.agents_target_dir;
+    const report = { removed: 0, preserved: 0, backups: 0, failures: [] };
+    this.lastSubagentCleanupReport = report;
+    if (!agentsTargetDir) return report;
+
     const agentsPath = path.join(projectDir, agentsTargetDir);
-    if (!(await fs.pathExists(agentsPath))) return;
+    if (!(await fs.pathExists(agentsPath))) return report;
 
     let entries;
     try {
       entries = await fs.readdir(agentsPath, { withFileTypes: true });
-    } catch {
-      return;
+    } catch (error) {
+      await this._reportSubagentFailure('read target directory', agentsPath, error, options, report);
+      return report;
     }
 
+    const sourceNames = await this._subagentSourceNames(wizzDir, config, options, report);
     for (const entry of entries) {
-      if (!entry.isFile()) continue;
-      if (!entry.name.startsWith('wizz-exec-') || !(entry.name.endsWith('.md') || entry.name.endsWith('.toml'))) continue;
+      if (!subagentTierFromName(entry.name)) continue;
+      if (!entry.isFile()) {
+        report.preserved++;
+        continue;
+      }
+      if (!isRecognizedSubagentName(entry.name, sourceNames)) {
+        report.preserved++;
+        continue;
+      }
+
+      const filePath = path.join(agentsPath, entry.name);
+      let content;
       try {
-        await fs.remove(path.join(agentsPath, entry.name));
-      } catch {
-        // Skip files we can't remove.
+        content = await fs.readFile(filePath, 'utf8');
+      } catch (error) {
+        report.preserved++;
+        await this._reportSubagentFailure('read target file', filePath, error, options, report);
+        continue;
+      }
+
+      const sourcePath = sourceNames.get(entry.name);
+      let sourceContent;
+      if (sourcePath) {
+        try {
+          sourceContent = await fs.readFile(sourcePath, 'utf8');
+        } catch (error) {
+          await this._reportSubagentFailure('read source file', sourcePath, error, options, report);
+        }
+      }
+      // Exact source equality is the only proof that a source-backed file is
+      // unchanged. Without a matching source, both current and legacy tiers
+      // may contain customizations and must be backed up before removal.
+      const generated = sourceContent !== undefined && content === sourceContent;
+      if (!generated) {
+        const backupPath = await this._backupSubagentFile(filePath, options, report);
+        if (!backupPath) {
+          report.preserved++;
+          continue;
+        }
+        report.backups++;
+      }
+
+      try {
+        await fs.remove(filePath);
+        report.removed++;
+      } catch (error) {
+        await this._reportSubagentFailure('remove', filePath, error, options, report);
       }
     }
 
-    // Remove the agents directory if we emptied it.
     try {
       const remaining = await fs.readdir(agentsPath);
-      if (remaining.length === 0) {
-        await fs.remove(agentsPath);
+      if (remaining.length === 0) await fs.remove(agentsPath);
+    } catch (error) {
+      // A non-empty directory is normal when user-owned agents remain. A
+      // failure to inspect/remove it is still actionable and must be visible.
+      if (error.code !== 'ENOENT') await this._reportSubagentFailure('remove empty target directory', agentsPath, error, options, report);
+    }
+    return report;
+  }
+
+  async _subagentSourceNames(wizzDir, config, options = {}, report = null) {
+    const sourceNames = new Map();
+    if (!wizzDir) return sourceNames;
+    const sourceDir = config.agents_source_subdir
+      ? path.join(wizzDir, 'wizz', 'subagents', config.agents_source_subdir)
+      : path.join(wizzDir, 'wizz', 'subagents');
+    if (!(await fs.pathExists(sourceDir))) return sourceNames;
+    try {
+      const entries = await fs.readdir(sourceDir, { withFileTypes: true });
+      for (const entry of entries) {
+        if (entry.isFile() && subagentTierFromName(entry.name)) sourceNames.set(entry.name, path.join(sourceDir, entry.name));
       }
-    } catch {
-      // Directory may already be gone.
+    } catch (error) {
+      await this._reportSubagentFailure('read source directory', sourceDir, error, options, report);
     }
+    return sourceNames;
+  }
+
+  async _backupSubagentFile(filePath, options = {}, report = null) {
+    let backupPath = `${filePath}.wizz-backup`;
+    let suffix = 0;
+    try {
+      const sourceStat = await nativeFsp.lstat(filePath);
+      if (!sourceStat.isFile()) throw new Error('source is not a regular file');
+      while (true) {
+        try {
+          await nativeFsp.copyFile(filePath, backupPath, nativeFsp.constants.COPYFILE_EXCL);
+          if (!options.silent) await prompts.log.warn(`Preserved existing subagent at ${backupPath}`);
+          return backupPath;
+        } catch (error) {
+          if (error.code !== 'EEXIST') throw error;
+          suffix++;
+          backupPath = `${filePath}.wizz-backup.${suffix}`;
+        }
+      }
+    } catch (error) {
+      await this._reportSubagentFailure('backup', filePath, error, options, report);
+      return null;
+    }
+  }
+
+  async _reportSubagentFailure(action, filePath, error, options = {}, report = null) {
+    const failure = { action, file: filePath, error: error instanceof Error ? error.message : String(error) };
+    if (report) report.failures.push(failure);
+    if (!options.silent) await prompts.log.warn(`Subagent ${action} failed for ${filePath}: ${failure.error}`);
   }
 
   /**