nexus-core-v3 3.0.0

package/bin/nexus.mjs

@@ -0,0 +1,37 @@
+#!/usr/bin/env node
+// Launcher do CLI `nexus` — o que o npm liga no PATH do usuário.
+//
+// Por que existe: o bin real (packages/cli/src/bin.ts) é TypeScript executado via tsx. Um shebang
+// `node --import tsx` resolveria o tsx a partir do CWD DO USUÁRIO (quebra fora do repo). Aqui o
+// tsx é resolvido a partir DESTE arquivo (node_modules do próprio nexus), com o cwd preservado —
+// o nexus opera no projeto do usuário, mas roda com as dependências do próprio pacote.
+import { createRequire } from 'node:module'
+import { spawn } from 'node:child_process'
+import { existsSync } from 'node:fs'
+import { fileURLToPath } from 'node:url'
+import { join, dirname } from 'node:path'
+
+const here = dirname(fileURLToPath(import.meta.url))
+const packageRoot = join(here, '..')
+
+// Caminho PUBLICADO: um bundle .mjs auto-contido (dist/bin/nexus.mjs, gerado por `npm run build:bundle`
+// no prepublish). Roda direto com node — sem tsx, sem os symlinks @nexus/* do workspace.
+const bundle = join(packageRoot, 'dist', 'bin', 'nexus.mjs')
+if (existsSync(bundle)) {
+  const child = spawn(process.execPath, [bundle, ...process.argv.slice(2)], { stdio: 'inherit' })
+  child.on('exit', (code, signal) => process.exit(signal ? 1 : (code ?? 1)))
+} else {
+  // Caminho DEV (rodando do repo, sem bundle): executa o fonte TypeScript via tsx, resolvido a partir
+  // do node_modules do próprio pacote (não do cwd do usuário).
+  const require = createRequire(import.meta.url)
+  let tsxCli
+  try {
+    tsxCli = require.resolve('tsx/cli')
+  } catch {
+    console.error('[nexus] nem o bundle (dist/) nem o `tsx` foram encontrados — rode `npm install` (dev) ou `npm run build:bundle`.')
+    process.exit(1)
+  }
+  const binTs = join(packageRoot, 'packages', 'cli', 'src', 'bin.ts')
+  const child = spawn(process.execPath, [tsxCli, binTs, ...process.argv.slice(2)], { stdio: 'inherit' })
+  child.on('exit', (code, signal) => process.exit(signal ? 1 : (code ?? 1)))
+}

package/checklists/README.md

@@ -0,0 +1,49 @@
+# NEXUS Checklists — os critérios de validação
+
+Um checklist é um conjunto de **critérios objetivos** que um gate roda item a item para emitir um
+veredito. É o que separa "feito" de "feito direito". Tasks de gate (`validate-next-story`, `qa-gate`,
+`pre-push-quality-gate`) consomem checklists; a task `execute-checklist` roda um checklist arbitrário.
+
+## Formato canônico
+
+Frontmatter YAML + corpo com itens verificáveis + regra de decisão.
+
+```markdown
+---
+id: story-draft-checklist
+kind: checklist
+agent: po                     # agente que tipicamente roda
+gate: Definition of Ready     # o portão que este checklist guarda
+decision: ">=7/10 GO, senão NO-GO com correções"   # como o veredito é decidido
+---
+
+# {título} ({gate})
+
+> {regra de decisão em uma linha}
+
+## Critérios
+- [ ] 1. {critério objetivo e verificável}
+- [ ] 2. ...
+
+## Decisão
+{veredito} + justificativa + (se NO-GO/CONCERNS) lista de correções obrigatórias.
+```
+
+## Regras
+
+- **Critérios são objetivos** — verificáveis com sim/não, não opinião vaga. "Os ACs são testáveis"
+  vale; "a story está boa" não.
+- **A decisão é explícita** — todo checklist diz como o veredito sai dos itens (ex.: pontuação,
+  qualquer-crítico-reprova, maioria).
+- **NEXUS-nativo.** Referencia agentes do roster e paths `docs/`. Nada de frameworks externos.
+- **Casa com o que valida.** O `story-draft-checklist` valida o `story-tmpl`; o `architect-checklist`
+  valida a saída do `create-architecture`.
+
+## Vereditos por tipo de gate
+
+| Gate | Vereditos |
+|---|---|
+| Definition of Ready (story) | GO / NO-GO |
+| QA Gate | PASS / CONCERNS / FAIL / WAIVED |
+| Pre-push | APROVADO / BLOQUEADO |
+| Spec Critique | APPROVED / NEEDS_REVISION / BLOCKED |

package/checklists/architect-checklist.md

@@ -0,0 +1,47 @@
+---
+id: architect-checklist
+kind: checklist
+agent: architect
+gate: Architecture Review
+decision: ">=8/10 E nenhum item crítico (1, 4, 7, 8) reprovado → APROVADO; senão BLOQUEADO com correções"
+---
+
+# Architect Checklist (Architecture Review)
+
+> A Aria roda isto sobre a saída do `*create-architecture` antes de a arquitetura virar plano e ir ao
+> @dev. Veredito: **APROVADO** (≥8/10 e todos os críticos passam) ou **BLOQUEADO** (lista de correções).
+> Itens **críticos** (1, 4, 7, 8) reprovam o gate sozinhos — arquitetura sem eles é meio design.
+
+## Critérios (10 pontos)
+
+- [ ] 1. **NFRs declarados com números** *(crítico)* — escala, latência, disponibilidade, segurança e
+      orçamento têm alvos quantificados; nenhum NFR relevante ficou implícito.
+- [ ] 2. **Contexto e objetivo presentes** — problema, jornada do usuário e restrições de negócio estão
+      escritos; o desenho parte do usuário pra trás.
+- [ ] 3. **Espinha estrutural completa** — componentes, fronteiras, fluxo de dados e pontos de integração
+      estão definidos (não só o caminho feliz).
+- [ ] 4. **No Invention — tudo rastreia** *(crítico)* — cada decisão, NFR e componente liga a um
+      FR/NFR/CON ou achado de pesquisa; nada inventado fora do que o projeto pede.
+- [ ] 5. **Stack justificado** — cada tecnologia tem o porquê; o exótico (não-chato) está explicitamente
+      justificado por um requisito real, não por hype.
+- [ ] 6. **Trade-offs documentados** — cada decisão de arquitetura registra alternativas descartadas e o
+      custo/risco pago; nenhuma decisão sem rastro do porquê.
+- [ ] 7. **Failure modes ao escalar declarados** *(crítico)* — cada fronteira passou pelo teste do 10×
+      (N+1, hot path, ponto único de falha) com mitigação; o "o que quebra" está escrito.
+- [ ] 8. **Lanes respeitadas** *(crítico)* — schema/DDL/RLS delegado ao @data-engineer (só a tecnologia é
+      decidida aqui); UI ao @ux-design-expert; código ao @dev; push/PR/CI ao @devops. Nada invade lane alheia.
+- [ ] 9. **Segurança e custo como camadas** — defesa em profundidade por camada e modelo de custo de infra
+      estão no design, não como apêndice.
+- [ ] 10. **Complexidade ganha, não presumida** — a classe (SIMPLE/STANDARD/COMPLEX) casa com a
+      profundidade entregue; nenhum microsserviço/cache/fila/sharding sem requisito que o justifique.
+
+## Decisão
+
+**Veredito:** APROVADO (≥8/10 e críticos 1, 4, 7, 8 todos ✓) / BLOQUEADO (caso contrário)
+**Pontuação:** {x}/10
+**Críticos:** 1 {✓/✗} · 4 {✓/✗} · 7 {✓/✗} · 8 {✓/✗}
+**Correções obrigatórias (se BLOQUEADO):**
+- {item — o que falta para virar APROVADO}
+
+> BLOQUEADO não é reprovação do trabalho: é a lista exata do que ajustar para a arquitetura sustentar o
+> que vem depois. Consertar arquitetura depois da produção é o conserto mais caro que existe.

package/checklists/change-checklist.md

@@ -0,0 +1,61 @@
+---
+id: change-checklist
+kind: checklist
+agent: po
+gate: Correção de Curso (Change Management)
+decision: "impacto avaliado, caminho escolhido e artefatos rastreáveis → PROSSEGUIR; senão ESCALAR a @nexus-master"
+---
+
+# Change Checklist (Correção de Curso)
+
+> O @po roda isto quando surge uma mudança significativa no meio da execução — requisito novo,
+> descoberta técnica que invalida uma premissa, dependência que caiu, ou conflito de escopo achado
+> no `po-master-checklist`. O objetivo não é decidir o escopo (isso é do @pm) — é **medir o impacto**,
+> escolher um caminho rastreável e garantir que PRD/epic/stories voltem a contar a mesma história.
+> Veredito: **PROSSEGUIR** (caminho claro e dono definido) ou **ESCALAR** a @nexus-master.
+
+## Critérios
+
+### 1. Gatilho & contexto da mudança
+- [ ] 1.1 **[CRÍTICO]** O gatilho da mudança está descrito objetivamente: o que mudou, quando foi detectado e por quê (requisito novo / falha técnica / dependência perdida / conflito de documentos).
+- [ ] 1.2 A story/epic atualmente em execução e seu status estão identificados (qual trabalho está em voo).
+- [ ] 1.3 A premissa original que a mudança quebra está nomeada — qual FR/NFR/decisão de arquitetura deixou de valer.
+
+### 2. Avaliação de impacto
+- [ ] 2.1 **[CRÍTICO]** Stories impactadas estão listadas — quais precisam mudar, ser refeitas, descartadas ou criadas.
+- [ ] 2.2 Impacto em artefatos a montante avaliado: o PRD (`docs/prd/`), specs (`docs/specs/`) e/ou arquitetura (`docs/architecture/`) precisam mudar? Sim/não, e onde.
+- [ ] 2.3 Impacto em dependências avaliado: a mudança quebra a sequência do backlog ou cria/remove pré-requisito.
+- [ ] 2.4 Trabalho já concluído avaliado: o que já foi entregue continua válido, precisa de rework ou vira tech-debt.
+- [ ] 2.5 Impacto em prazo/escopo da release quantificado em ordem de grandeza (cabe na release atual ou empurra para a próxima).
+
+### 3. Caminhos de correção (escolha rastreável)
+- [ ] 3.1 Os caminhos viáveis foram enumerados (ex.: ajustar story, refazer story, replanejar epic, reduzir escopo da release, rollback).
+- [ ] 3.2 **[CRÍTICO]** Um caminho foi recomendado com justificativa — por que ele tem o melhor custo/risco/valor frente às alternativas.
+- [ ] 3.3 O caminho escolhido NÃO inventa requisito: toda mudança proposta rastreia a uma fonte (novo input do @pm, achado de pesquisa, decisão de arquitetura). (Art. IV — No Invention)
+- [ ] 3.4 O caminho respeita as lanes: edição de escopo/PRD vai para @pm, reescrita de story para @sm, schema para @data-engineer, subida para @devops.
+
+### 4. Plano de execução & artefatos
+- [ ] 4.1 Cada artefato a atualizar tem dono e ação nomeados (quem mexe no PRD, quem refaz a story, quem reordena o backlog).
+- [ ] 4.2 As stories afetadas têm ação de backlog definida (atualizar / re-priorizar / agendar / arquivar) via `*backlog-*`.
+- [ ] 4.3 Após a mudança, PRD/epic/stories voltam a ser coerentes — há plano para re-rodar o `po-master-checklist` e confirmar a coesão.
+- [ ] 4.4 A decisão de mudança está registrada de forma rastreável (gatilho → impacto → caminho → ações), não em decisão verbal não documentada.
+
+### 5. Gate de escalonamento
+- [ ] 5.1 **[CRÍTICO]** Se a mudança altera escopo/objetivo do produto, ela foi escalada a @nexus-master/@pm — o @po não decide escopo sozinho.
+- [ ] 5.2 Se há conflito de escopo entre PRD/epic/story, ele foi sinalizado em voz alta — nada de "deixa passar e a gente vê depois".
+
+## Decisão
+
+**Veredito:** PROSSEGUIR / ESCALAR
+**Itens críticos:** {todos aprovados? sim/não}
+**Caminho recomendado:** {qual + justificativa em uma linha}
+
+**Regra:**
+- **PROSSEGUIR** — todos os itens [CRÍTICO] aprovados, caminho escolhido com fonte rastreável e cada artefato com dono e ação definidos.
+- **ESCALAR a @nexus-master** — qualquer item [CRÍTICO] falho, OU a mudança altera escopo/objetivo do produto (5.1), OU há conflito de documentos não resolvível na lane do @po.
+
+**Ações da correção de curso:**
+- {artefato — ação — dono (@pm / @sm / @data-engineer / @devops)}
+
+> Correção de curso não é falha de planejamento: é o ecossistema de documentos se reajustando à
+> realidade sem perder a rastreabilidade. Mudança sem impacto medido é caos agendado.

package/checklists/db-predeploy-checklist.md

@@ -0,0 +1,57 @@
+---
+id: db-predeploy-checklist
+kind: checklist
+agent: data-engineer
+gate: Database Pre-Deploy
+decision: "qualquer CRÍTICO falho → BLOQUEADO; senão APROVADO (ALTO falho exige mitigação registrada)"
+---
+
+# Database Pre-Deploy Checklist (Database Pre-Deploy)
+
+> A Dara roda isto antes de qualquer migration tocar o banco-alvo. Valida o `migration-plan-tmpl`, o
+> `schema-design-tmpl` e o `rls-policies-tmpl` que alimentam o deploy. Veredito: **APROVADO** ou
+> **BLOQUEADO**. Migration que entra sem passar aqui é incidente esperando para acontecer.
+
+## Critérios
+
+### Reversibilidade (CRÍTICO — qualquer falha bloqueia)
+
+- [ ] 1. **Snapshot baseline criado** — ponto de rollback existe antes de aplicar (`*snapshot {label}`).
+- [ ] 2. **Rollback script pronto** — cada passo forward tem reverso idempotente; restauração de snapshot documentada. Se não sei desfazer, não aplico.
+- [ ] 3. **Ponto de não-retorno identificado** — perdas irreversíveis (DROP com dados) estão explícitas e autorizadas.
+
+### Integridade (CRÍTICO — qualquer falha bloqueia)
+
+- [ ] 4. **Baseline em toda tabela nova** — `id` (PK), `created_at`, `updated_at` presentes; `deleted_at` onde há auditoria.
+- [ ] 5. **FKs explícitas com ON DELETE definido** — toda relação tem foreign key e ação de delete declarada.
+- [ ] 6. **Constraints de negócio no banco** — CHECK/UNIQUE/NOT NULL fazem cumprir as regras; integridade não delegada só à aplicação.
+
+### Segurança RLS (CRÍTICO — qualquer falha bloqueia)
+
+- [ ] 7. **RLS habilitada em toda tabela pública** — nenhuma tabela exposta sem Row Level Security.
+- [ ] 8. **Testes RLS positivos E negativos passam** — quem pode acessa, quem não pode é barrado (`*test-as-user`).
+- [ ] 9. **service_role justificado** — todo bypass de RLS tem motivo registrado; nenhum segredo vaza em log.
+
+### Procedimento (ALTO — falha exige mitigação registrada)
+
+- [ ] 10. **Ordem do DDL validada** — dependências primeiro; dry-run sem erro (`*verify-order` + `*dry-run`).
+- [ ] 11. **Idempotência verificada** — `IF NOT EXISTS`/`IF EXISTS`/merges; rodar duas vezes é seguro.
+- [ ] 12. **Aplicação em transação** — migration roda atômica; falha no meio não deixa schema parcial.
+- [ ] 13. **Revisão CodeRabbit limpa** — sem achado CRÍTICO aberto; ALTO mitigado ou com rollback comprovado.
+
+### Performance (ALTO — falha exige mitigação registrada)
+
+- [ ] 14. **Índices justificados por query real** — cada índice serve a um padrão de acesso; nenhuma FK quente sem índice.
+- [ ] 15. **Impacto de lock/downtime avaliado** — locks de tabela e janela de aplicação dimensionados por evidência, não palpite.
+
+## Decisão
+
+**Veredito:** APROVADO / BLOQUEADO
+**Críticos falhos:** {lista — itens 1-9 reprovados}
+**Altos falhos (com mitigação):** {lista — itens 10-15 reprovados e como serão mitigados}
+**Correções obrigatórias (se BLOQUEADO):**
+- {item — o que falta para liberar o deploy}
+
+> Regra: **qualquer CRÍTICO falho → BLOQUEADO**, sem exceção. ALTO falho não bloqueia por si só, mas
+> exige mitigação ou rollback script comprovado registrado acima. BLOQUEADO não é reprovação — é a
+> lista exata do que a Dara ajusta antes de a migration tocar produção.

package/checklists/design-quality-checklist.md

@@ -0,0 +1,57 @@
+---
+id: design-quality-checklist
+kind: checklist
+agent: qa
+gate: Visual Quality
+decision: "default REPROVADO; APROVADO só com evidência VISUAL (screenshot da UI renderizada) E: nenhum tell crítico (T1,T3,T5,T6) presente E no máximo 2 tells no total E os 4 itens de acabamento crítico (A1,A4,A6,A9) passam — senão FAIL com os tells nomeados e a correção"
+---
+
+# Design Quality Checklist (Visual Quality)
+
+> A Quinn roda isto no **endurecer**, sobre a UI RENDERIZADA (não sobre o diff), quando a story
+> entrega interface. É o dente HARD da rota design-first (Onda 9.2): mesmo que o coordenador tenha
+> pulado o UX, o acabamento não passa daqui sem qualidade. **Default é REPROVADO** — o ônus da prova
+> é da tela, não da dúvida. Sem screenshot da UI, não há avaliação: o gate não atesta o que não viu.
+>
+> Régua derivada dos packs `web-craft/anti-ai-look` (os tells) e `web-craft/visual-polish-review` (as
+> lentes de acabamento). FAIL vira `QaVerdict` com `evidence` (o screenshot) e a lista de tells.
+
+## Parte 1 — "Isto parece feito por IA?" (tells — presença REPROVA)
+
+Marque cada tell PRESENTE. **Críticos (T1, T3, T5, T6) reprovam sozinhos.** 3+ tells no total = FAIL.
+
+- [ ] **T1 (crítico) — Estética de component-library default:** shadcn/Material sem customização, mesmos cantos e sombras de todo template.
+- [ ] **T2 — Tipografia Inter/system em tudo**, um ou dois pesos, sem par de caráter nem hierarquia real.
+- [ ] **T3 (crítico) — Gradiente índigo→violeta / roxo→rosa** no hero, botões ou blobs de fundo.
+- [ ] **T4 — Glassmorphism/blur** aplicado sem motivo em todo card.
+- [ ] **T5 (crítico) — Tudo centralizado** num eixo vertical único do topo ao fim.
+- [ ] **T6 (crítico) — Grid de 3 cards iguais** (ícone + título de 2 palavras + parágrafo genérico).
+- [ ] **T7 — Espaçamento uniforme** em múltiplos de 8 sem ritmo; nenhuma seção respira diferente.
+- [ ] **T8 — Ilustrações blob 3D / stock / gradient mesh** sem relação com a marca.
+- [ ] **T9 — Estrutura previsível** hero→logos→features→depoimento→CTA sem nenhuma surpresa.
+- [ ] **T10 — Motion uniforme:** tudo faz o mesmo fade-up, mesma duração, mesmo easing.
+- [ ] **T11 — Copy vaga de "empoderamento"** ("Empower your workflow"), sem dizer o que faz e pra quem.
+- [ ] **T12 — Detalhes esquecidos:** seleção de texto default, foco azul do browser, favicon genérico.
+
+## Parte 2 — Acabamento (lentes de visual-polish — ausência REPROVA)
+
+**Críticos (A1, A4, A6, A9) reprovam sozinhos** se falharem.
+
+- [ ] **A1 (crítico) — Hierarquia por peso e cor,** não só por tamanho: há um ponto focal claro por tela.
+- [ ] **A2 — Escala tipográfica modular** e line-height inverso (corpo ~1.5, títulos ~1.1–1.2).
+- [ ] **A3 — Medida (line length)** controlada (~45–75 caracteres) no corpo de texto.
+- [ ] **A4 (crítico) — Cor como sistema:** 8–10 tons de cinza (com temperatura) + primárias com shades, não 3 cores soltas.
+- [ ] **A5 — Cinza nunca sobre fundo colorido** (usar o tom colorido escurecido, não cinza opaco).
+- [ ] **A6 (crítico) — Espaçamento com ritmo** (escala não-linear, extremos usados), não tudo uniforme.
+- [ ] **A7 — Elevação em camadas** (sombra de luz suave, não cinza opaco chapado).
+- [ ] **A8 — Separação sem borda** onde couber (espaço/fundo em vez de linha em tudo).
+- [ ] **A9 (crítico) — Estados de botão completos:** hover, active, **focus desenhado** (não o anel azul default), disabled; hierarquia primária/secundária clara.
+- [ ] **A10 — Empty states e estados de erro desenhados** (não "sem dados" cru).
+
+## Como reprovar (fail-closed)
+
+REPROVADO quando: falta o screenshot da UI renderizada · **qualquer** tell crítico (T1/T3/T5/T6) presente ·
+**qualquer** item de acabamento crítico (A1/A4/A6/A9) falho · **3+ tells** no total. FAIL emite
+`QaVerdict` (severidade P1/P2 conforme o item), `evidence` = o screenshot e a lista dos tells/lentes
+que reprovaram, e `fixInstructions` apontando o princípio de craft correspondente. Reprovar aqui 2–3
+vezes é o processo funcionando — cada ciclo tira uma camada da "cara de IA".

package/checklists/discovery-checklist.md

@@ -0,0 +1,36 @@
+---
+id: discovery-checklist
+kind: checklist
+agent: analyst
+gate: Discovery
+decision: ">=6/8 E os críticos (1, 2, 5) passam → PRONTO PARA ESTRATÉGIA; senão VOLTA À DESCOBERTA"
+---
+
+# Discovery Checklist (Descobrir)
+
+> O Alex roda isto ao fim da fase **Descobrir**, antes de a ideia virar estratégia. Descoberta rasa
+> vira produto errado construído com perfeição. Itens **críticos** (1, 2, 5) reprovam sozinhos: sem
+> problema real, usuário real e evidência, não há o que estrategizar.
+
+## Critérios (8 pontos)
+
+- [ ] 1. **Problema real, não solução disfarçada** *(crítico)* — o que dói está escrito como problema
+      do usuário, não como "quero a feature X". A dor precede a solução.
+- [ ] 2. **Usuário/segmento nomeado** *(crítico)* — quem sente a dor está identificado (papel, contexto),
+      não um "usuário genérico".
+- [ ] 3. **Evidência da dor** — a dor tem prova (entrevista, dado, ticket, observação), não suposição.
+- [ ] 4. **Concorrência/alternativas mapeadas** — como isso é resolvido hoje (inclusive "na mão" ou
+      "não é resolvido") está registrado.
+- [ ] 5. **Valor articulado** *(crítico)* — por que resolver isso importa (impacto, frequência, alcance)
+      está claro; vale o esforço.
+- [ ] 6. **Restrições conhecidas** — orçamento, prazo, técnicas, legais/compliance levantadas.
+- [ ] 7. **Riscos e incógnitas listados** — o que ainda não se sabe está nomeado (não varrido para baixo
+      do tapete).
+- [ ] 8. **Pergunta de decisão clara** — a próxima decisão (seguir/pivotar/parar) e o que a responde
+      estão definidos.
+
+## Veredito
+
+- **PRONTO PARA ESTRATÉGIA:** ≥6/8 e críticos 1, 2, 5 passam. A dor é real e vale a pena.
+- **VOLTA À DESCOBERTA:** crítico reprovado ou <6/8. Falta problema, usuário ou evidência — pesquisar
+  mais antes de investir em estratégia.

package/checklists/foundation-checklist.md

@@ -0,0 +1,39 @@
+---
+id: foundation-checklist
+kind: checklist
+agent: architect
+gate: Foundation
+decision: ">=7/9 E os críticos (1, 3, 6, 9) passam → FUNDAÇÃO SÓLIDA; senão RE-ESTRUTURAR"
+---
+
+# Foundation Checklist (Estruturar)
+
+> A Aria roda isto ao fim da fase **Estruturar**, antes de o time começar a construir. Fundação torta
+> vira retrabalho caro no dia 30. Itens **críticos** (1, 3, 6, 9) reprovam sozinhos: sem NFRs, sem
+> fronteiras e sem rastreabilidade, "construir" é apostar.
+
+## Critérios (9 pontos)
+
+- [ ] 1. **NFRs quantificados** *(crítico)* — escala, latência, disponibilidade, segurança e custo têm
+      números-alvo; nenhum NFR relevante ficou implícito.
+- [ ] 2. **Espinha estrutural completa** — componentes, fronteiras, fluxo de dados e integrações
+      definidos (não só o caminho feliz).
+- [ ] 3. **No Invention — tudo rastreia** *(crítico)* — cada decisão/componente liga a um FR/NFR/CON ou
+      achado de pesquisa; nada inventado fora do que o projeto pede.
+- [ ] 4. **Stack justificado** — cada tecnologia tem o porquê; o exótico é justificado por requisito
+      real, não por hype.
+- [ ] 5. **Dados modelados** — entidades, relações e propriedade de dados definidas; migração/estado
+      inicial pensados.
+- [ ] 6. **Segurança na fundação** *(crítico)* — authz por fronteira, dados sensíveis, superfície de
+      ataque considerados no desenho, não deixados para depois.
+- [ ] 7. **Estratégia de teste declarada** — como cada camada será testada (unidade/integração/e2e)
+      está definida antes de codar.
+- [ ] 8. **Observabilidade prevista** — logs, métricas e trilhas de auditoria fazem parte do desenho.
+- [ ] 9. **Decisões registradas (ADRs)** *(crítico)* — as escolhas estruturais e suas alternativas
+      rejeitadas estão documentadas; o "porquê" sobrevive à memória.
+
+## Veredito
+
+- **FUNDAÇÃO SÓLIDA:** ≥7/9 e críticos 1, 3, 6, 9 passam. Pode construir sobre isto.
+- **RE-ESTRUTURAR:** crítico reprovado ou <7/9. Consertar a fundação agora custa uma conversa; depois,
+  um refactor.

package/checklists/launch-checklist.md

@@ -0,0 +1,39 @@
+---
+id: launch-checklist
+kind: checklist
+agent: devops
+gate: Launch
+decision: ">=8/9 E TODOS os críticos (1, 2, 4, 7, 9) passam → PODE LANÇAR; senão SEGURA O LANÇAMENTO"
+---
+
+# Launch Checklist (Lançar)
+
+> O Gage roda isto antes de qualquer release ir para produção. Lançar é irreversível na prática (o
+> usuário já viu). Itens **críticos** (1, 2, 4, 7, 9) reprovam sozinhos e SEGURAM o lançamento — sem
+> gate verde, sem rollback e sem observabilidade, "lançar" é apostar com o usuário.
+
+## Critérios (9 pontos)
+
+- [ ] 1. **Gate de qualidade verde** *(crítico)* — o Endurecer passou: `npm run check` verde, QA com
+      PASS e evidência. Não se lança sobre vermelho.
+- [ ] 2. **Rollback testado** *(crítico)* — existe caminho de volta EXERCITADO (não só documentado);
+      sei desfazer em minutos se der errado.
+- [ ] 3. **Migrações reversíveis e ensaiadas** — schema mudou? A migração foi ensaiada e tem volta (ou
+      o plano de contingência está escrito).
+- [ ] 4. **Segredos e config de produção corretos** *(crítico)* — nenhuma credencial de dev/staging
+      vaza para prod; variáveis de ambiente conferidas; nada hardcoded.
+- [ ] 5. **Feature flag / rollout gradual** — mudança arriscada sobe atrás de flag ou canário, não de
+      uma vez para 100%.
+- [ ] 6. **Comunicação pronta** — changelog/aviso ao usuário e ao time preparados; suporte sabe o que
+      muda.
+- [ ] 7. **Observabilidade e alertas ativos** *(crítico)* — métricas, logs e alertas do caminho novo
+      estão de pé ANTES do tráfego; saberei se quebrar.
+- [ ] 8. **Plano de incidente** — quem responde, como escala e onde está o runbook estão definidos.
+- [ ] 9. **Assinatura de release verificada** *(crítico)* — o artefato distribuído está assinado e a
+      assinatura confere (fail-closed); nada não-assinado vai para o usuário.
+
+## Veredito
+
+- **PODE LANÇAR:** ≥8/9 e todos os críticos passam. Rede de segurança montada, volta garantida.
+- **SEGURA O LANÇAMENTO:** qualquer crítico reprovado ou <8/9. Um dia a mais de preparo custa menos que
+  um incidente em produção.

package/checklists/pm-checklist.md

@@ -0,0 +1,48 @@
+---
+id: pm-checklist
+kind: checklist
+agent: pm
+gate: PRD/Epic/Spec Ready
+decision: ">=8/10 → APROVADO; <8 → REVISÃO com correções obrigatórias; qualquer item crítico (1, 4, 6) reprovado → REVISÃO independentemente da nota"
+---
+
+# PM Checklist (PRD / Epic / Spec Ready)
+
+> O @pm roda isto sobre o PRD (`prd-tmpl`), o epic (`epic-tmpl`) ou a spec (`spec-tmpl`) antes de
+> entregar a downstream (@sm / @architect / @qa). Veredito: **APROVADO** (≥8 dos 10, nenhum crítico
+> reprovado) ou **REVISÃO** (lista de correções). Documento que sai daqui é contrato executável — quem
+> recebe não precisa perguntar o que foi quis dizer.
+
+## Critérios (10 pontos)
+
+- [ ] 1. **(CRÍTICO) "Por quê" na raiz** — o problema está rastreado a uma dor real do usuário ou achado
+      de pesquisa, não a uma solução disfarçada de problema.
+- [ ] 2. **Usuário-alvo identificado** — persona/segmento que sente a dor está nomeado, não genérico.
+- [ ] 3. **Objetivos com métrica** — cada objetivo tem métrica mensurável, baseline e alvo; nada de
+      objetivo sem número que o comprove.
+- [ ] 4. **(CRÍTICO) Escopo MVP recortado** — só o "Must" entra; o que foi adiado está explicitamente no
+      roadmap/fora de escopo. Nenhuma feature entrou sem provar seu lugar.
+- [ ] 5. **FR/NFR com critério de aceite verificável** — cada requisito tem aceite testável sim/não;
+      nada de "funciona bem" ou critério vago.
+- [ ] 6. **(CRÍTICO) Rastreabilidade total (No Invention, Art. IV)** — cada FR/NFR/CON aponta para um
+      objetivo, requisito de origem, achado ou restrição. Zero linha inventada.
+- [ ] 7. **Restrições e premissas explícitas** — CONs externos e premissas de risco estão listados; o
+      que muda o plano se for falso está sinalizado.
+- [ ] 8. **Dependências e riscos mapeados** — itens de que a entrega depende e riscos com mitigação estão
+      identificados.
+- [ ] 9. **Fronteiras de epic limpas** (para epics) — entrega coesa em uma frase, "dentro/fora" definido,
+      e a criação de stories está delegada ao @sm (Gate 1), não feita pelo @pm. *(N/A para PRD/spec puro.)*
+- [ ] 10. **Quality gates previstos** — os portões que a entrega atravessa (@po, @qa, @devops) estão
+      antecipados no documento; qualidade é design, não remendo.
+
+## Decisão
+
+**Veredito:** APROVADO (≥8 e nenhum crítico reprovado) / REVISÃO (caso contrário)
+**Pontuação:** {x}/10
+**Itens críticos (1, 4, 6):** {OK / reprovado — qual}
+**Correções obrigatórias (se REVISÃO):**
+- {item — o que falta para virar APROVADO}
+
+> REVISÃO não é reprovação: é a lista exata do que ajustar para o documento virar contrato executável.
+> Item crítico reprovado bloqueia a aprovação independentemente da nota — sem "por quê", sem recorte ou
+> com invenção, o documento volta.

package/checklists/po-master-checklist.md

@@ -0,0 +1,64 @@
+---
+id: po-master-checklist
+kind: checklist
+agent: po
+gate: Coesão & Rastreabilidade do Ecossistema de Documentos
+decision: ">=90% dos itens aplicáveis aprovados E nenhum item crítico falho → GO; senão NO-GO com correções"
+---
+
+# PO Master Checklist (Coesão & Rastreabilidade)
+
+> O @po roda isto sobre o conjunto de artefatos de produto — PRD, epic(s), specs, arquitetura e
+> backlog de stories — antes de o trabalho entrar no ciclo de desenvolvimento. Não valida UMA story
+> (isso é o `story-draft-checklist`); valida se PRD, epic, spec e stories contam a **mesma história**,
+> em sequência lógica, sem requisito inventado. Item marcado **[CRÍTICO]** reprova o gate sozinho.
+
+## Critérios
+
+### 1. Coesão dos documentos
+- [ ] 1.1 **[CRÍTICO]** PRD, epic(s) e stories contam a mesma história — nenhum conflito silencioso de escopo, objetivo ou comportamento entre os documentos.
+- [ ] 1.2 Cada epic em `docs/prd/` mapeia para objetivos declarados do PRD; nenhum epic órfão sem objetivo de origem.
+- [ ] 1.3 Toda story planejada pertence a um epic existente; nenhuma story solta fora da estrutura de epics.
+- [ ] 1.4 Terminologia consistente entre documentos — a mesma entidade/conceito tem o mesmo nome em PRD, spec, arquitetura e stories.
+
+### 2. Rastreabilidade (Constituição Art. IV — No Invention)
+- [ ] 2.1 **[CRÍTICO]** Cada story rastreia a um FR/NFR/CON do PRD, a um item de spec (`docs/specs/...`) ou a um achado de pesquisa (`docs/research/...`); nenhuma story inventada sem fonte.
+- [ ] 2.2 Cada FR/NFR do PRD está coberto por ao menos uma story ou está explicitamente marcado como fora de escopo desta release.
+- [ ] 2.3 Afirmações técnicas em specs/stories citam a fonte (`docs/architecture/...`, `docs/data-models/...`); nada de decisão técnica sem origem.
+- [ ] 2.4 Não há requisito presente nas stories que esteja ausente do PRD/spec (invenção a jusante).
+
+### 3. Sequência & dependências
+- [ ] 3.1 **[CRÍTICO]** Nenhuma story está agendada antes de sua dependência (schema, serviço, story-base) — sequência respeita a cadeia de pré-requisitos.
+- [ ] 3.2 Dependências entre stories estão explicitamente declaradas (story X precisa de Y) e mapeadas no backlog.
+- [ ] 3.3 Dependências externas (APIs, dados, integrações de terceiros) estão identificadas e seu status (pronto/pendente) é conhecido.
+- [ ] 3.4 A ordem do backlog é tecnicamente executável — não há ciclo de dependência nem item bloqueado por algo ainda não planejado.
+
+### 4. Prontidão das stories (amostra do conjunto)
+- [ ] 4.1 Toda story marcada como pronta para o sprint passou no `story-draft-checklist` (GO individual).
+- [ ] 4.2 ACs de stories que compartilham comportamento são consistentes entre si — não há critérios que se contradizem entre stories.
+- [ ] 4.3 Gate de qualidade (CodeRabbit/QA) está previsto para o fluxo; nenhuma story planeja entrar em Done sem QA gate.
+
+### 5. Cobertura & escopo da release
+- [ ] 5.1 O escopo do conjunto cabe na release/sprint planejada — não há excesso de stories HIGH simultâneas sem ordem.
+- [ ] 5.2 Prioridades (HIGH/MEDIUM/LOW) estão atribuídas e justificadas por valor/risco, não por urgência percebida.
+- [ ] 5.3 Itens de follow-up, tech-debt e enhancement estão no backlog (`*backlog-add`), não misturados como ACs de stories de release.
+
+### 6. Donos & lanes
+- [ ] 6.1 Cada bloco de trabalho está na lane do agente certo; o que sai da lane (schema → @data-engineer, UI → @ux-design-expert, subida → @devops) está delegado ao dono.
+- [ ] 6.2 Nenhum item exige que o @po reescreva título/AC/escopo — correções pendentes têm dono nomeado (@sm para story, @pm para escopo).
+
+## Decisão
+
+**Veredito:** GO / NO-GO
+**Cobertura:** {itens aprovados}/{itens aplicáveis} ({percentual}%)
+**Itens críticos:** {todos aprovados? sim/não}
+
+**Regra:**
+- **GO** — ≥90% dos itens aplicáveis aprovados **E** todos os itens [CRÍTICO] aprovados.
+- **NO-GO** — abaixo de 90% **OU** qualquer item [CRÍTICO] falho.
+
+**Correções obrigatórias (se NO-GO):**
+- {item — o que falta + dono (@sm story / @pm escopo / @analyst pesquisa)}
+
+> Conflito de escopo entre PRD/epic/story (item 1.1 falho) eu não resolvo em silêncio: sinalizo e
+> escalo a correção de curso para @nexus-master usando o `change-checklist`.

package/checklists/reality-check-checklist.md

@@ -0,0 +1,49 @@
+---
+id: reality-check-checklist
+kind: checklist
+agent: qa
+gate: Reality Check
+decision: "default NEEDS WORK; READY só se TODOS os críticos (1,2,5,10) passam E >=8/10 — senão FAIL/CONCERNS com correções"
+---
+
+# Reality Check Checklist (Reality Check)
+
+> A Quinn roda isto antes de assinar qualquer PASS. O default do gate de realidade é **NEEDS WORK** —
+> o ônus da prova é do código, não da dúvida. READY (PASS) só quando a evidência é esmagadora. Itens
+> **críticos** (1, 2, 5, 10) reprovam sozinhos: sem eles, "passou" é teatro. Reprovar aqui 2–3 vezes é
+> o processo funcionando — cada ciclo aproxima do real.
+
+## Critérios (10 pontos)
+
+- [ ] 1. **Executei, não li** *(crítico)* — rodei a suíte completa e exercitei o fluxo alterado com meus
+      olhos. "Pareceu certo no diff" e "rodou na minha cabeça" não contam. Gate sem execução é fraude
+      assinada com meu nome.
+- [ ] 2. **Evidência anexada** *(crítico)* — cada afirmação de "pronto/funciona" tem prova verificável:
+      teste verde, log da execução real, screenshot, console limpo. Sem prova, não aconteceu — vira
+      issue com `evidence`, não PASS.
+- [ ] 3. **Grep antes de acreditar** — verifiquei as alegações olhando o artefato REAL (código, teste,
+      arquivo capturado), não a narração de quem implementou. Confiar no "feito" sem checar é como
+      confiar num `tool_use` que nunca virou `tool_result`.
+- [ ] 4. **`filesModified` confirmado (caso BUG A)** — os arquivos ditos "modificados" foram confirmados
+      por RESULTADO da escrita, não pela intenção de escrever. Intenção declarada não é mudança feita;
+      exijo a confirmação, não a promessa.
+- [ ] 5. **Regressão para todo bug "corrigido"** *(crítico)* — cada correção tem um teste que
+      reproduzia o bug original (red antes do green). "Corrigido" sem esse teste é hipótese, não fato.
+- [ ] 6. **Toda AC rastreia a teste** — cada AC mapeia a pelo menos um Given-When-Then; AC órfã é gap
+      nomeado com severidade. E o inverso: comportamento novo sem AC é escopo furado.
+- [ ] 7. **App sobe / evidência visual** — se a story tem UI, o app subiu e há captura por rota×viewport
+      (`collect-visual-evidence`). Se não sobe, o veredito é **BLOCKED** com o log — não um PASS no escuro.
+- [ ] 8. **Console limpo no fluxo** — sem erro/warning relevante no console durante a execução do fluxo
+      alterado. Erro de console é achado, não ruído.
+- [ ] 9. **Veredito estruturado emitido** — emiti exatamente um bloco `<verdict>` válido; se FAIL, com
+      ao menos uma issue com `evidence` (o contrato barra FAIL sem issue). O veredito é dado, não prosa.
+- [ ] 10. **Nenhum teste afrouxado para passar** *(crítico)* — nenhum teste foi skipado, comentado ou
+      relaxado para o gate fechar. Teste enfraquecido para o verde é achado CRÍTICO, não detalhe.
+
+## Veredito
+
+- **READY (PASS):** críticos 1, 2, 5, 10 passam **e** ≥8/10. Assino porque EU vi rodar, com prova.
+- **NEEDS WORK (FAIL/CONCERNS):** qualquer crítico reprovado, ou <8/10. Devolvo com `fixInstructions` e
+  o defeito preciso — o @dev conserta, eu re-reviso. Isso é o ciclo saudável, não uma falha.
+- **BLOCKED:** o app/fluxo não roda, ou a evidência necessária é impossível de obter agora. Escalo com o
+  log — não invento o resultado do que não consegui ver.