feat(wizard): v0.5.0 PR 2 — estágio 2.9, artefato Pitch e a pergunta do BP online

.aios-self

@@ -1,6 +1,6 @@
 This file marks the AI Dev Operating System repository itself.
 
-Its presence tells `scripts/detach-os.{sh,ps1}` and the WIZARD Stage 0.5 to SKIP detach actions, because we ARE the OS repo (not a derived project).
+Its presence tells `scripts/detach-os.{sh,ps1}` and WIZARD stage 1.2 (Phase 1 — Largada) to SKIP detach actions, because we ARE the OS repo (not a derived project).
 
 DO NOT delete this file from the AI Dev OS repo.
 DO NOT copy this file to a derived project — if you used "Use this template" or cloned this repo, the marker should NOT travel with you (template copy excludes it via `.gitattributes` export-ignore).

.claude/commands/registry-pick.md

@@ -26,7 +26,8 @@ If arguments are omitted, the skill will read project signals from `docs/busines
 
 ## When to use
 
-- Right after `WIZARD.md` Stage 11.5 (between Technical Plan and Sprint roadmap).
+- At `WIZARD.md` **stage 3.1** — design-scoped pass, before the Prototype Lab. Output: `docs/technical/registry-pick-design.md`.
+- At `WIZARD.md` **stage 4.3** — full stack pass, after the Technical Plan. Output: `docs/technical/registry-pick.md`.
 - When a new domain need surfaces mid-build.
 - After a new pack is added to `docs/registry/`.
 

.claude/rules/documentation-layers.md

@@ -3,7 +3,9 @@
 Each document has one responsibility:
 
 - `BUSINESS-PLAN.md`: business narrative.
-- `PRODUCT-BRIEF.md`: operational product understanding.
+- `PITCH.md`: the business narrative compressed to ten sections, derived from the BP — plus the record of what was approved for public publication. Never adds a claim the BP does not make.
+- `DESIGN-DIRECTION.md`: the approved prototype direction — tokens, screens, flow. Written in Phase 3, read by Phase 4.
+- `PRODUCT-BRIEF.md`: operational product understanding, reverse-engineered from the prototype.
 - `TECHNICAL-PLAN.md`: architecture, stack, security, tests.
 - `SPRINTS.md`: roadmap and execution plan.
 - `CHANGELOG.md`: what changed.

.claude/rules/privacy-audit.md

@@ -13,3 +13,15 @@ Any feature that collects, stores, processes, exports, or displays personal data
 9. Does this change require documentation, policy, or consent updates?
 
 Do not merge personal-data changes without a privacy review.
+
+## Publishing documents counts as processing
+
+WIZARD stage 2.9 lets a project put its Business Plan and Pitch on a public URL. That is a personal-data decision, not only an editorial one. Before anything is published, answer:
+
+1. **Are any personas traceable to a real person?** "Marina, 34, gerente de clínica em Porto Alegre" is personal data when Marina is someone you actually interviewed. Generalize, or get documented consent.
+2. **Did the interviewees agree to be described publicly?** Consent to be interviewed is not consent to be published.
+3. **Does the team section expose more than those people agreed to?** Names, photos, and roles are personal data too.
+4. **Will the page have analytics?** Visitor tracking on a public page is personal-data collection and re-triggers all nine questions above.
+5. **Can it be unpublished?** Not in practice — search engines, archives, and screenshots outlive the page. Treat publication as permanent.
+
+The full redaction gate lives in `.claude/skills/pitch/SKILL.md` and the `PITCH.md` template.

.claude/rules/wizard-flow.md

@@ -2,4 +2,24 @@
 
 The Project Genesis Wizard must not be simplified.
 
-New projects must go through ideation, ten questions, research plan approval, research waves, red team, consolidation, BP v0.0.1, human review, BP v0.0.2, product brief, technical plan, sprint roadmap, prototype lab, and first coding sprint.
+The canonical flow is [`WIZARD.md`](../../WIZARD.md). It runs in **5 phases**, and none may be skipped:
+
+| Phase | Must include |
+|---|---|
+| **1 — Largada** | repository comprehension, detach from OS-origin, friendly opening |
+| **2 — Ideação** | raw ideation, ten strategic questions, research plan approval, Wave 1 (market + competitors), Wave 2 (red team), Wave 3 (consolidation), BP v0.0.1, human review, BP v0.0.2 with impact review |
+| **3 — Protótipo** | design pack pick, Prototype Lab with three distinct directions, direction approval, design tokens extracted to `docs/product/DESIGN-DIRECTION.md` |
+| **4 — Documentação** | Product Brief, Technical Plan, stack pack pick, sprint roadmap |
+| **5 — Chegada** | Sprint 0 / Sprint 1 |
+
+## Ordering rules that are not negotiable
+
+1. **Phase 3 runs before Phase 4.** The prototype is built from BP v0.0.2 and the research — never from a Product Brief, which does not exist yet.
+2. **Phase 4 is reverse engineering, not invention.** The Product Brief and Technical Plan must be derived from the approved prototype and `DESIGN-DIRECTION.md`. Anything the prototype implies but does not show must be recorded as a gap, not filled in silently.
+3. **Coding waits for Phase 5.** No production code before BP v0.0.2, the prototype direction, the Product Brief, the Technical Plan, and the sprint roadmap are all approved.
+
+## Referring to stages
+
+Use the phase as the handle: "Phase 3", "we're in Phase 4". Stage numbers (`3.2`, `4.1`) order steps inside a phase and may shift when a step is inserted. Phase names do not shift.
+
+Do not reintroduce fractional stages. If a new step is needed, add it as an integer stage inside the phase it belongs to.

.claude/rules/wizard-stage-tags.md

@@ -1,40 +1,58 @@
 # Wizard stage tags (opt-in)
 
-Convenção opcional para marcar em qual estágio do WIZARD um commit pertence. Útil pra rastreamento automático de progresso (ex.: dashboards, métricas, relatórios). Quem não usa **não perde nada**.
+Convenção opcional para marcar em qual fase do WIZARD um commit pertence. Útil pra rastreamento automático de progresso (ex.: dashboards, métricas, relatórios). Quem não usa **não perde nada**.
 
 ## Como usar
 
-Adicione `[STAGE:X]` no fim da mensagem de commit. Os 5 estágios reconhecidos são:
+Adicione `[STAGE:X]` no fim da mensagem de commit. As 5 tags correspondem **1:1 às 5 fases** do [`WIZARD.md`](../../WIZARD.md) — não existe tabela de tradução: um commit `[STAGE:PROTOTIPO]` *é* um commit da Fase 3.
 
-| Tag | Significado | Quando aparece |
-|---|---|---|
-| `[STAGE:LARGADA]` | Repositório criado, primeiro commit feito. | Logo após "Use this template" + `git init` ou primeiro commit. |
-| `[STAGE:IDEACAO]` | WIZARD Stages 1–4 (ideação, 10 perguntas, plano de pesquisa). | Commits de ideação raw, brainstorming, BP rascunho. |
-| `[STAGE:DOCUMENTACAO]` | WIZARD Stages 5–12 (research, BP, Brief, Technical Plan, sprint roadmap). | Commits que adicionam ou revisam BP, Brief, TP, registry picks, sprint plan. |
-| `[STAGE:PROTOTIPO]` | WIZARD Stage 13 (Prototype Lab). | Primeiro código no `prototype-lab/`. |
-| `[STAGE:CHEGADA]` | Stage 14 — Sprint 1 começou ou primeiro deploy/run local. | Ambiente rodando, fluxo principal funcional. |
+| Tag | Fase | Significado | Quando aparece |
+|---|---|---|---|
+| `[STAGE:LARGADA]` | **Fase 1** | Repositório é seu, desacoplado e seguro pra commitar. | Logo após "Use this template" + `git init` ou primeiro commit. |
+| `[STAGE:IDEACAO]` | **Fase 2** | O pensamento: ideação, 10 perguntas, pesquisa, red team, BP v0.0.1 → v0.0.2. | Commits de ideação raw, brainstorming, pesquisa em `knowledge-base/`, BP e suas revisões. |
+| `[STAGE:PROTOTIPO]` | **Fase 3** | O produto fica visível: marca, cores, UI, UX. | Primeiro código no `prototype-lab/`, as 3 direções, e o `DESIGN-DIRECTION.md`. |
+| `[STAGE:DOCUMENTACAO]` | **Fase 4** | Engenharia reversa do protótipo aprovado + plano de execução. | Product Brief, Technical Plan, registry picks, sprint roadmap. |
+| `[STAGE:CHEGADA]` | **Fase 5** | Sprint 1 começou ou primeiro deploy/run local. | Ambiente rodando, fluxo principal funcional. |
 
 ## Exemplos
 
 ```
 feat: setup inicial e estrutura canônica [STAGE:LARGADA]
 docs: 10 perguntas estratégicas respondidas [STAGE:IDEACAO]
-docs(business): BP v0.0.2 com correções do red team [STAGE:DOCUMENTACAO]
-feat(prototype): primeiro fluxo de login com mock data [STAGE:PROTOTIPO]
+docs(business): BP v0.0.2 com correções do red team [STAGE:IDEACAO]
+feat(prototype): três direções visuais com mock data compartilhado [STAGE:PROTOTIPO]
+docs(product): Product Brief derivado do protótipo aprovado [STAGE:DOCUMENTACAO]
 feat: app rodando no localhost com fluxo principal [STAGE:CHEGADA]
 ```
 
+## Por que as tags agora são cronológicas
+
+Até a v0.4.5 o WIZARD colocava o Prototype Lab **depois** do Product Brief, do Technical Plan e do roadmap. Isso deixava `PROTOTIPO` cronologicamente *depois* de `DOCUMENTACAO` — as tags saíam fora de ordem, e qualquer sistema que inferisse progresso pela sequência das tags via o projeto "andar pra trás".
+
+A reordenação da v0.5.0 (protótipo antes da documentação) conserta isso. As 5 tags agora aparecem na ordem em que estão listadas acima, sempre.
+
+**Os 5 valores de tag não mudaram.** Commits antigos continuam válidos; só a ordem esperada mudou.
+
 ## Por que existe
 
 Sistemas externos (ex.: o "Grand Prix do Trilho" do `course/systems/grand-prix/`) podem ler os commits via GitHub API e inferir progresso automaticamente — sem precisar que o usuário marque manualmente. Isto torna possível dashboards de turma, métricas de adoção, relatórios de uso.
 
 ## Detecção como fallback
 
-Se você esquecer a tag, ferramentas que dependem dela podem inferir o estágio a partir dos arquivos modificados (ex.: criação de `docs/business/BUSINESS-PLAN.md` → `DOCUMENTACAO`). Tags explícitas são preferidas porque eliminam ambiguidade.
+Se você esquecer a tag, ferramentas que dependem dela podem inferir a fase a partir dos arquivos modificados:
+
+| Arquivos tocados | Fase inferida |
+|---|---|
+| `knowledge-base/`, `docs/business/BUSINESS-PLAN.md` | `IDEACAO` |
+| `prototype-lab/`, `docs/product/DESIGN-DIRECTION.md` | `PROTOTIPO` |
+| `docs/product/PRODUCT-BRIEF.md`, `docs/technical/`, `docs/SPRINTS.md` | `DOCUMENTACAO` |
+| `src/`, `app/` | `CHEGADA` |
+
+Tags explícitas são preferidas porque eliminam ambiguidade.
 
 ## Quando NÃO usar
 
-- Em commits que não correspondem a um estágio do WIZARD (ex.: ajuste de typo, fix de CI). Apenas omita a tag.
+- Em commits que não correspondem a uma fase do WIZARD (ex.: ajuste de typo, fix de CI). Apenas omita a tag.
 - Em projetos que não seguem o WIZARD do AI Dev OS.
 
 ## Convenção é opt-in

.claude/skills/business-plan-impact-review/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: business-plan-impact-review
+description: Check every Business Plan change for downstream impact before accepting it — price moves projections, ARPU, LTV and positioning; persona moves GTM, UX and MVP scope; stack moves costs, roadmap and risks. Runs at WIZARD stage 2.8 when turning BP v0.0.1 into v0.0.2, and any time the BP is edited after approval. Use when the user says "mudei o preço", "troquei a persona", "cortei o escopo", "e se eu cobrar por assento?", or when `grow-sustainably` / `multi-ai-review` flag a pricing or packaging change.
+---
+
 # Business Plan Impact Review Skill
 
 Use when revising BP v0.0.1 into v0.0.2 after user feedback.

.claude/skills/cost-watchdog/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cost-watchdog
-description: Flag potentially expensive technical choices BEFORE they are committed. Watch for AI model selection, hosting tier upgrades, third-party services with metered pricing, and DB patterns that explode with scale.
+description: Flag potentially expensive technical choices BEFORE they are committed — AI model selection, hosting tier upgrades, third-party services with metered pricing, and DB patterns that explode with scale. Preventive counterpart to `usage-monitor`, which tracks real spend after launch. Triggers when the user says "posso usar o Opus pra isso?", "qual plano eu contrato?", "isso vai ficar caro?", "quanto custa rodar isso?", or whenever a paid tier or metered API is about to enter the stack.
 ---
 
 # Cost Watchdog

.claude/skills/decision-log/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: decision-log
-description: Create session logs or ADRs to preserve why important decisions were made.
+description: Record WHY a decision was made — including the alternatives rejected — as a session-log entry or an ADR. Use after any decision touching architecture, product scope, pricing, compliance, security, or release strategy, when `multi-ai-review` reconciles a disagreement, and when the user says "anota isso", "registra essa decisão", "por que a gente escolheu isso mesmo?", "não lembro por que fizemos assim".
 ---
 
 # Decision Log

.claude/skills/feature-scaffold/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: feature-scaffold
-description: Create a feature-based folder structure and initial implementation plan.
+description: Create a feature-based folder structure (components, actions, api, db, hooks, schemas, tests) plus an initial implementation plan, following `.claude/rules/feature-based-architecture.md`. Use when starting a new product feature during a coding sprint, and when the user says "vamos criar a tela de X", "quero adicionar tal funcionalidade", "onde eu coloco esse arquivo?", "como organizo isso?".
 ---
 
 # Feature Scaffold

.claude/skills/first-100-users/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: first-100-users
-description: Get the first 100 real users for a vibe-coder SaaS without spending on ads. Hand-curated outreach, founder communities, niche-specific channels, retention check-ins. Activated after launch when the user asks "como pego os primeiros usuários", "ninguém tá usando", or after `launch-agent` Track A.
+description: Get the first 100 real users for a vibe-coder SaaS without spending on ads. Hand-curated outreach, founder communities, niche-specific channels, retention check-ins. Activated after launch when the user asks "como pego os primeiros usuários", "ninguém tá usando", "como divulgo isso?", or after `launch-agent` Track A. Hand off to `grow-sustainably` once the project passes ~100 active users — this skill is conversation-driven and does not scale past that.
 ---
 
 # First 100 Users

.claude/skills/os-self-test/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: os-self-test
-description: Verify the AI Dev Operating System is in a coherent state inside a project. Detects missing canonical files, broken cross-references, version drift, gitignore gaps, stale paths after a migration, and orphaned artifacts. Run after major edits to the OS or before opening a new sprint.
+description: Verify the AI Dev Operating System is in a coherent state inside a project. Detects missing canonical files, broken cross-references, version drift, gitignore gaps, stale paths after a migration, and orphaned artifacts. Run after major edits to the OS, after renaming or moving canonical files, before opening a new sprint, before a release, and when the user says "tá tudo certo aqui?", "quebrou alguma coisa na estrutura?", "faz um check geral", "os links estão funcionando?".
 ---
 
 # OS Self-Test