wizz-method 2.7.1 → 2.8.0

package/package.json

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

package/skills-registry.yaml

@@ -477,13 +477,15 @@ areas:
       # que é exatamente a trava que a 2.7.0 tinha acabado de pôr nela).
       - id: wizz-lowticket-guia
         module: lowticket
-        when: "Porta de entrada low ticket para quem não sabe o que pedir: 'quero vender um produto barato', 'por onde começo', 'ninguém compra', 'não estou vendendo', 'anúncio não funciona'. Situa na jornada de 7 etapas e despacha. NÃO usar quando o pedido já nomeia uma tarefa concreta com seus insumos (escrever uma copy, diagnosticar uma página, ler um print de campanha): aí vá direto na skill daquela etapa."
+        when: "Porta de entrada low ticket para quem não sabe o que pedir: 'quero vender um produto barato', 'por onde começo', 'ninguém compra', 'não estou vendendo', 'anúncio não funciona'. Situa na jornada de 7 etapas e despacha."
+        not_when:
+          - "O pedido já nomeia uma tarefa concreta com seus insumos (escrever uma copy, diagnosticar uma página, ler um print de campanha): vá direto na skill daquela etapa."
         rel:
           before:
             [wizz-lowticket-funil, wizz-lowticket-metodologia, wizz-lowticket-minerador, wizz-lowticket-pagina, wizz-lowticket-trafego]
       - id: wizz-lowticket-metodologia
         module: lowticket
-        when: "Roteador da base low ticket BR/PT: gatilho → um shard (diagnóstico de funil, bid cap, criativo, oferta, página, Instagram, player de VSL, upsell, copy, rastreamento, mineração). Régua de preço, garantia, copy e rastreamento que tem precedência sobre a skill genérica — inclusive a copy de low ticket (página, VSL, roteiro de criativo, headline): ler o shard ANTES de escrever. Carrega guardrails junto."
+        when: "Roteador da base low ticket BR/PT: gatilho → um shard (diagnóstico de funil, bid cap, criativo, oferta, página, Instagram, player de VSL, upsell, copy, rastreamento, mineração). Régua de preço, garantia, copy e rastreamento que tem precedência sobre a skill genérica — inclusive a copy de low ticket (página, VSL, roteiro de criativo, headline): ler o shard ANTES de escrever. Carrega guardrails junto. A precedência vale QUANDO o contexto do projeto ou o próprio pedido estabelecer que a operação é low ticket (faixa de preço, produto barato, tráfego direto). Se nenhum dos dois disser, a skill genérica vence: não presuma low ticket por a página ser de vendas, o produto ser um curso ou haver campanha rodando."
         not_when:
           - "SaaS, B2B, site de cliente, high ticket ou mentoria: os números não transferem."
         rel:
@@ -534,7 +536,8 @@ areas:
     summary: "Social e roteiros virais: Reels/Shorts, hooks, calendário de conteúdo. Persona Rafa, aplica o Blueprint de Roteiro Viral e roteia para as CLIs de vídeo quando o roteiro vira vídeo."
     skills:
       - id: wizz-social-content
-        when: "Criar/agendar conteúdo de social (LinkedIn, X, TikTok, IG...)."
+        when: "Criar/agendar conteúdo de social (LinkedIn, X, TikTok, IG...), o que inclui ESCREVER o texto: post, story, carrossel, legenda, thread. Gatilhos: 'escreve copy pra story', 'post pro LinkedIn', 'legenda do carrossel', 'thread pro X'."
+        not_when: "Editar/revisar texto de social já escrito: aí é wizz-copy-editing."
         rel:
           before: [get-brolls, postiz]
           pairs_with: [wizz-canvas-design, wizz-content-strategy, wizz-copy-editing, wizz-launch-strategy]

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.
 
+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)
 
 Written as bare labels, the 3 factors above were true of almost any request, and the measured result was escalating nearly everything to the maestro: in the eval's first trustworthy measurement (sonnet, 3 samples), 26% of the cases answered differently between samples and most failures were over-escalation. A factor without an objective test is not a rule, it is an impression. What follows is the test. **When in doubt, the factor does NOT count.**
@@ -34,4 +36,6 @@ Written as bare labels, the 3 factors above were true of almost any request, and
 
 **Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
 
-**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas → maestro. A referral programme without the invitation and without attribution is the same case. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because the social content skill declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. The question to ask about each edge is "would the thing I am about to hand over be incomplete without this?", not "is this related?".
+**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas → maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because the social content skill declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. The question to ask about each edge is "would the thing I am about to hand over be incomplete without this?", not "is this related?".
+
+**The counter-example that looks like the sales page and is not:** "I want to set up a referral programme" is `agent:growth`. The invitation is another deliverable (an e-mail sequence ships on its own) and attribution cannot escalate at all, because `wizz-analytics-tracking` already lives in growth next to `wizz-referral-program`. So check where a dragged capability actually lives before counting it: **an id that also exists in the dragging entry's own area never adds an area**, even when it exists elsewhere too. It adds one only when it exists solely elsewhere. (Owner's decision, 2026-09-19.)

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.
 
+**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**.
 - **1 area and 0-1 of the 3 factors → the AGENT for that area.** Find the area in `skills-registry.yaml` and invoke the block's `agent:` (e.g.: `designer → wizz-designer`, `seo → wizz-seo`, one-off dev → `wizz-quick-dev`). **Stop here**: the agent pulls in the skills/clis/mcps. You do **not** fire standalone skills.
 - **1 area and 2+ of the 3 factors → `wizz-maestro` too.** Multi-step + needs planning + memorable artifact combined indicate that even within 1 area the work requires coordination.
@@ -66,7 +68,9 @@ Assess the **Area**: how many areas does the request touch? The canonical area l
 
 **Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
 
-**The area count includes what `rel` drags, when the related capability shapes the SAME deliverable.** Before deciding "1 area", look at the `rel` of the entry that matched, and ask of each edge: **would the thing I am about to hand over be incomplete without this?** — not "is this related?". Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas, hence maestro. A referral programme without the invitation and without attribution is the same case. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because `wizz-social-content` declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. Every edge is reciprocal by construction (the schema validator rejects one-way edges), so the relation shows up whichever side the user enters from. Resolve id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`; outside a Wizz project, via `skills-registry.yaml` itself.
+**The area count includes what `rel` drags, when the related capability shapes the SAME deliverable.** Before deciding "1 area", look at the `rel` of the entry that matched, and ask of each edge: **would the thing I am about to hand over be incomplete without this?** — not "is this related?". Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas, hence maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because `wizz-social-content` declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. Every edge is reciprocal by construction (the schema validator rejects one-way edges), so the relation shows up whichever side the user enters from. Resolve id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`; outside a Wizz project, via `skills-registry.yaml` itself.
+
+**A referral programme is the counter-example, and it earns its place here because it looks like the sales page and is not.** "I want to set up a referral programme" is `agent:growth`, not the maestro. The invitation is another deliverable — an e-mail sequence is written, reviewed and shipped on its own — and attribution cannot escalate at all, because `wizz-analytics-tracking` already lives in growth, alongside `wizz-referral-program`. So before counting a dragged capability as a second area, check where it actually lives: **an id that also exists in the dragging entry's own area never adds an area**, even when it exists in another one too (`wizz-analytics-tracking` is in growth AND in ads; dragged from growth it stays growth). It adds an area only when it exists solely elsewhere. (Owner's decision, 2026-09-19, after the measurement showed the model applying this correctly while the written example claimed the opposite.)
 
 **Capability discovery (index, not a delegation shortcut):** the [flat routing table](references/routing-table-flat.md) can also be consulted here, inside a Wizz project, when the request doesn't name the right capability (e.g. "I want a carousel" → the index points to `wizz-canvas-design`). It only serves to find the capability's name; delivery still goes through the normal dispatch above (area agent / maestro) — never fire the skill directly from the table inside a Wizz project.