nexus-core-v3 3.0.0

package/tasks/shard-doc.md

@@ -0,0 +1,60 @@
+---
+id: shard-doc
+agent: pm
+title: Shardear um documento grande em partes consumíveis
+inputs: [documento (PRD, arquitetura ou spec), destino do shard]
+outputs: [pasta de shards por seção, index.md com links, documento-fonte preservado]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Shardear um documento grande em partes consumíveis
+
+**Objetivo:** quebrar um documento grande (PRD, arquitetura, spec) em arquivos menores por seção,
+com um índice navegável — para que @sm, @dev e @qa consumam só o pedaço que precisam, sem carregar
+o documento inteiro.
+
+**Pré-condições:**
+- O documento-fonte existe e está em Markdown com headings de nível 2 (`##`) bem definidos. Se não
+  tiver estrutura de seções clara, **pare** e reporte — shardear um documento sem fronteiras gera
+  pedaços sem sentido.
+- O destino do shard é uma pasta sob `docs/` (ex.: `docs/prd/`, `docs/architecture/`). Se não foi
+  dado, derivo do tipo de documento; se ambíguo, elicito — não invento o destino.
+
+## Passos
+
+1. **Leia o documento-fonte completo** e mapeie as seções de nível 2 (`##`). Cada `##` vira um shard.
+   Subseções (`###`) ficam dentro do shard do seu pai — não viram arquivo próprio.
+2. **Defina a pasta de destino** sob `docs/` (ex.: `docs/prd/`, `docs/architecture/`). Crie-a se não
+   existir. O documento-fonte original **permanece intacto** — shardear copia, não move nem apaga.
+3. **Gere um arquivo por seção.** Para cada heading `##`:
+   a. crie `docs/{destino}/{slug-da-seção}.md` (slug em kebab-case derivado do título);
+   b. copie o conteúdo da seção (incluindo subseções `###`) sem alterar o texto — fidelidade ao
+      fonte é a regra (No invention, Art. IV: não reescrevo o requisito ao shardear);
+   c. promova o heading da seção a `#` (nível 1) no topo do shard, para o arquivo ler bem isolado.
+4. **Crie o `index.md`** na pasta de destino: um sumário com link para cada shard, na ordem original
+   do documento, mais uma linha apontando para o documento-fonte. É o ponto de entrada da navegação.
+5. **Verifique a fidelidade:** a soma do conteúdo dos shards cobre todas as seções do fonte, sem
+   perda e sem duplicação. Nenhum link do `index.md` aponta para arquivo inexistente.
+6. **Reporte o resultado:** liste os shards gerados e o caminho do `index.md`. O documento-fonte segue
+   como a fonte da verdade; os shards são a projeção consumível.
+7. **Não subo nada.** Se os shards precisam ir pro repositório remoto, eu delego ao @devops — `git
+   push` / PR são EXCLUSIVOS dele. Eu deixo os arquivos prontos no working tree.
+
+## Critério de pronto (DoD)
+
+- [ ] Um shard por seção de nível 2 do documento-fonte, em `docs/{destino}/`
+- [ ] `index.md` criado com links na ordem original + link para o documento-fonte
+- [ ] Conteúdo dos shards fiel ao fonte (sem perda, sem reescrita, sem duplicação)
+- [ ] Documento-fonte preservado intacto
+- [ ] Todos os links do `index.md` resolvem para arquivos existentes
+- [ ] Nada de `git push` (delegado ao @devops)
+
+## Falha / recuperação
+
+- **Documento sem headings `##` claros** → HALT, reporto que o fonte não tem estrutura shardeável e
+  devolvo para o autor estruturar antes.
+- **Destino ambíguo ou inexistente** → elicito a pasta de destino em vez de adivinhar.
+- **Conteúdo se perderia ou duplicaria na divisão** (seções aninhadas mal formadas) → paro, reporto a
+  ambiguidade estrutural e não gero shards inconsistentes.
+- **Os shards precisam ir ao remoto** → delego a subida ao @devops; não rodo `git push`.

package/tasks/spec-assess-complexity.md

@@ -0,0 +1,55 @@
+---
+id: spec-assess-complexity
+agent: architect
+title: Avaliar complexidade de uma story nas 5 dimensões
+inputs: [story]
+outputs: [complexity.json, classe (SIMPLE/STANDARD/COMPLEX), estimativa de esforço]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Avaliar complexidade de uma story nas 5 dimensões
+
+**Objetivo:** classificar uma story em SIMPLE / STANDARD / COMPLEX pontuando 5 dimensões objetivas,
+para que a profundidade do plano e do contexto seja ganha — não presumida.
+
+**Pré-condições:**
+- A story existe e tem ACs. Sem critérios de aceite não há o que dimensionar — **pare** e devolva ao @sm.
+- A story rastreia a um FR/NFR/CON ou achado de pesquisa. Sem rastro, eu não pontuo o que não existe.
+
+## Passos
+
+1. **Leia a story COMPLETA** — ACs, notas técnicas, dependências declaradas. O escopo real está nos
+   critérios de aceite, não no título.
+2. **Pontue cada dimensão de 1 (trivial) a 5 (crítico)**, registrando o porquê de cada nota — nota sem
+   justificativa rastreável não entra:
+   - **Escopo** — quantos arquivos/módulos a story toca.
+   - **Integração** — APIs externas, contratos entre serviços, pontos de costura cross-stack.
+   - **Infraestrutura** — mudanças de infra/deploy necessárias (fila, cache, schema, env).
+   - **Conhecimento** — familiaridade do time com a tecnologia/padrão envolvido.
+   - **Risco** — criticidade: o que quebra ao escalar, blast radius de uma falha (teste do 10×).
+3. **Some as notas** e atribua a classe:
+   - `<= 8` → **SIMPLE** (plano enxuto, 3 fases)
+   - `9–15` → **STANDARD** (plano completo)
+   - `>= 16` → **COMPLEX** (plano completo + ciclo de revisão; considere `*research` antes)
+4. **Estime o esforço** em faixa (horas/dias) coerente com a classe — faixa, não número mágico.
+5. **Grave `complexity.json`** em `docs/specs/{storyId}/complexity.json` com: as 5 notas, a
+   justificativa de cada uma, o total, a classe e a estimativa.
+6. **Roteie pela classe.** SIMPLE/STANDARD → sigo direto para `*create-plan`. COMPLEX → sinalizo que
+   pesquisa (`*research`) e/ou ciclo de revisão são recomendados antes de planejar.
+
+## Critério de pronto (DoD)
+
+- [ ] As 5 dimensões pontuadas (1–5), cada uma com justificativa rastreável à story
+- [ ] Total somado e classe (SIMPLE/STANDARD/COMPLEX) atribuída
+- [ ] Estimativa de esforço em faixa registrada
+- [ ] `docs/specs/{storyId}/complexity.json` gravado e válido
+- [ ] Roteamento pela classe explícito (planejar direto vs. pesquisar antes)
+
+## Falha / recuperação
+
+- **Story sem ACs ou sem rastro a FR/NFR/CON** → HALT, devolvo ao @sm/@po. Não invento o escopo que falta.
+- **Dimensão impossível de pontuar por falta de informação** (ex.: integração externa não definida) →
+  registro a lacuna como bloqueio e devolvo, em vez de chutar uma nota.
+- **A story esconde várias stories** (escopo estoura 5 em múltiplas dimensões) → recomendo ao @sm
+  quebrá-la antes de planejar; uma story que não dá para dimensionar não dá para implementar.

package/tasks/spec-critique.md

@@ -0,0 +1,64 @@
+---
+id: spec-critique
+agent: qa
+title: Criticar a spec quanto a completude e clareza
+inputs: [spec]
+outputs: [critique.json com veredito e scores, lista de gaps rastreáveis]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Criticar a spec quanto a completude e clareza
+
+**Objetivo:** auditar uma spec antes da implementação — apontar o que está incompleto, ambíguo ou
+inventado — e emitir um veredito rastreável (APPROVED / NEEDS_REVISION / BLOCKED) que decide se a spec
+avança para o plano ou volta para revisão.
+
+**Pré-condições:**
+- A spec existe e referencia suas fontes (FR-*, NFR-*, CON-* ou achados de pesquisa). Sem fontes
+  rastreáveis, a crítica já começa em risco — toda afirmação precisa ancorar em algo.
+- Tenho o contexto do objetivo que originou a spec (pedido/story). Se não tenho, elicito — eu critico
+  contra um contrato, não contra o ar.
+
+## Passos
+
+1. **Leio a spec inteira** e listo cada afirmação material. Defino o que "completo e claro" significa
+   para ESTE escopo antes de julgar.
+2. **Gate constitucional — No Invention (Art. IV).** Verifico que TODA afirmação rastreia a um FR-*,
+   NFR-*, CON-* ou achado de pesquisa. Qualquer feature inventada (sem fonte) é gap CRÍTICO e por si
+   só leva a BLOCKED. Juiz não inventa requisito; também não deixa a spec inventar.
+3. **Avalio as dimensões** (score 1-5 cada), profundidade proporcional ao risco:
+   - **Completude:** todos os ACs/cenários cobertos? casos de erro e borda previstos?
+   - **Clareza:** linguagem inequívoca? cada termo definido? nada de "etc." escondendo escopo?
+   - **Testabilidade:** cada requisito vira teste em Given-When-Then? há critério objetivo de pronto?
+   - **Rastreabilidade:** cada afirmação ancora numa fonte declarada?
+   - **Risco/NFR:** segurança, performance e confiabilidade endereçadas onde o caminho é crítico?
+4. **Registro cada gap** com severidade (CRITICAL/HIGH/MEDIUM/LOW) e a fonte que prova o buraco —
+   nunca opinião estética avulsa. Advisory, não arbitrário: bloqueio só com motivo rastreável.
+5. **Calculo o veredito** pela média dos scores:
+   - média **≥ 4.0** → **APPROVED** (segue para o plano).
+   - média **3.0–3.9** → **NEEDS_REVISION** (volto com a lista de correções obrigatórias).
+   - média **< 3.0** ou qualquer gap CRÍTICO de invenção → **BLOCKED** (escalo ao @architect).
+6. **Emito `critique.json`** com veredito, scores por dimensão e a lista de gaps. Esse é o artefato
+   que o pipeline lê para decidir o próximo passo.
+7. **Roteio.** APPROVED → @architect planeja. NEEDS_REVISION → @pm revisa a spec. BLOCKED → escalo ao
+   @architect. Eu critico; eu **não reescrevo** a spec — corrigir é de quem a escreveu.
+
+## Critério de pronto (DoD)
+
+- [ ] Toda afirmação da spec checada contra fonte (FR/NFR/CON/pesquisa) — gate No Invention aplicado
+- [ ] As 5 dimensões pontuadas (1-5) com justificativa rastreável
+- [ ] Cada gap registrado com severidade e fonte (zero achado por preferência estética)
+- [ ] Veredito calculado pela regra (APPROVED / NEEDS_REVISION / BLOCKED) e coerente com os scores
+- [ ] `critique.json` emitido e roteado ao destino correto
+- [ ] Não reescrevi a spec nem inventei critério fora do contrato
+
+## Falha / recuperação
+
+- **Spec sem fontes rastreáveis** → não consigo aplicar o gate de invenção: marco BLOCKED e devolvo
+  ao @pm para amarrar as fontes antes de eu recriticar.
+- **Veredito BLOCKED ou gap CRÍTICO** → escalo ao @architect imediatamente; não deixo a spec avançar
+  para implementação no escuro.
+- **Falta o contexto do objetivo que originou a spec** → paro e elicito; não critico contra o ar.
+- **Preciso subir o artefato (push/PR)** → delego ao @devops, sempre. Eu não faço `git push` nem abro
+  PR; git para mim é read-only.

package/tasks/spec-gather-requirements.md

@@ -0,0 +1,48 @@
+---
+id: spec-gather-requirements
+agent: pm
+title: Elicitar e documentar requisitos (spec pipeline — fase 1)
+inputs: [pedido informal do stakeholder]
+outputs: ['docs/specs/{slug}/requirements.md com FR-*/NFR-*/CON-* rastreáveis']
+elicit: true
+modes: [interactive]
+---
+
+# Elicitar e documentar requisitos (spec pipeline — fase 1)
+
+**Objetivo:** transformar um pedido informal em requisitos estruturados e rastreáveis (FR-*, NFR-*,
+CON-*) — a fundação da spec pipeline, antes de qualquer spec formal.
+
+**Pré-condições:**
+- Existe um pedido/intenção do stakeholder, ainda que informal. Sem isso, não há o que elicitar.
+- O stakeholder está disponível para responder. A elicitação exige interação real — não se pula.
+
+## Passos
+
+1. **Leia o pedido informal e identifique as lacunas.** O que está implícito? O que falta para virar
+   requisito testável?
+2. **[ELICITAÇÃO] Conduza a entrevista de requisitos.** Pergunte sobre: usuário e dor, comportamento
+   esperado, critérios de sucesso, restrições (técnicas, de negócio, de prazo) e o que está **fora** do
+   escopo. Pare e espere as respostas reais — não preencha lacuna com suposição.
+3. **Estruture cada item com ID rastreável:** `FR-*` (requisitos funcionais), `NFR-*` (não-funcionais:
+   performance, segurança, acessibilidade), `CON-*` (restrições). Cada um com enunciado verificável e a
+   fonte (quem pediu / por quê).
+4. **Marque ambiguidades e premissas em aberto** explicitamente — elas viram pergunta na próxima rodada,
+   não viram requisito inventado (No invention, Art. IV).
+5. **Salve em `docs/specs/{slug}/requirements.md`.** Este artefato alimenta `spec-write-spec` (fase
+   seguinte) e a avaliação de complexidade do @architect.
+
+## Critério de pronto (DoD)
+
+- [ ] Todo requisito tem ID (`FR-*`/`NFR-*`/`CON-*`), enunciado verificável e fonte rastreável
+- [ ] Escopo e não-escopo explícitos
+- [ ] Ambiguidades/premissas registradas como abertas, não inventadas
+- [ ] Elicitação real conduzida com o stakeholder (não presumida)
+- [ ] Salvo em `docs/specs/{slug}/requirements.md`
+
+## Falha / recuperação
+
+- **Stakeholder indisponível para a elicitação** → seguro a task; requirements.md com lacunas inventadas
+  é pior que adiar. Registro o que falta e aguardo.
+- **Pedido exige pesquisa de mercado/viabilidade** → delego ao @analyst antes de fechar os requisitos.
+- **Requisito sem fonte clara** → não vira FR; vira pergunta aberta na lista de ambiguidades.

package/tasks/spec-research-dependencies.md

@@ -0,0 +1,42 @@
+---
+id: spec-research-dependencies
+agent: analyst
+title: Pesquisar dependências e constraints técnicos de uma spec
+inputs: [story ou spec]
+outputs: ['docs/research/spec-deps-{slug}.md (dependências, constraints, riscos — cada um rastreável a FR/NFR/CON ou fonte)']
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Pesquisar dependências e constraints técnicos de uma spec
+
+**Objetivo:** levantar as dependências, restrições e riscos técnicos de uma story/spec, com cada achado rastreando a um FR/NFR/CON da spec ou a uma fonte real — munição para o @architect e o @dev, sem inventar requisito (Constituição Art. IV).
+
+**Pré-condições:**
+- Existe uma story ou spec com requisitos identificáveis (FR-*, NFR-*, CON-*). Se não houver requisitos rastreáveis, **pare** e devolva ao @pm/@sm — não pesquiso dependências de um alvo inexistente.
+- Esta é pesquisa, não decisão de arquitetura. A escolha de tecnologia é do @architect; eu levanto as constraints, ele decide.
+
+## Passos
+
+1. **Leio a spec/story completa** e extraio cada FR/NFR/CON. Listo-os — todo achado desta task vai amarrar a um deles.
+2. **Mapeio as dependências** que cada requisito implica: bibliotecas, serviços externos, APIs, dados, infraestrutura, versões. Para cada uma, anoto o requisito de origem.
+3. **DIVIRJO — levanto constraints e alternativas.** Para cada dependência: versões suportadas, limites conhecidos, custos, licenças, maturidade. Crédito a fonte (docs oficiais, changelogs, advisories) ou marco como hipótese.
+4. **CONVIRJO — filtro e ranqueio riscos.** Mantenho o que tem fonte forte; classifico cada dependência por risco (bloqueante / atenção / ok) e por acoplamento.
+5. **Registro os constraints técnicos rastreáveis.** Cada constraint amarra a um NFR/CON da spec ou a uma fonte verificável — nada de palpite apresentado como fato.
+6. **Sintetizo em "portanto".** Lista numerada: dependências críticas, riscos abertos e perguntas de arquitetura — cada uma com a fonte e o requisito de origem.
+7. **Salvo** em `docs/research/spec-deps-{slug}.md` com a matriz requisito → dependência → fonte → risco, e roteio: decisões de tecnologia → @architect; impacto em DB → @data-engineer.
+
+## Critério de pronto (DoD)
+
+- [ ] Todos os FR/NFR/CON da spec extraídos e listados
+- [ ] Cada dependência amarra a um requisito de origem
+- [ ] Cada constraint rastreia a um FR/NFR/CON ou a uma fonte verificável (sem invenção)
+- [ ] Dependências ranqueadas por risco e acoplamento
+- [ ] "Portanto" em lista numerada com perguntas de arquitetura roteadas ao @architect
+- [ ] Documento salvo com a matriz requisito → dependência → fonte → risco
+
+## Falha / recuperação
+
+- **Um achado não amarra a nenhum FR/NFR/CON** → ou é escopo invisível (devolvo ao @pm para virar requisito), ou eu o corto — não inflo a spec inventando justificativa.
+- **Fonte da dependência indisponível/desatualizada** → marco como hipótese e listo em "a validar"; não cravo versão/limite sem evidência.
+- **A pesquisa exige uma decisão de tecnologia** → paro na constraint, formulo a pergunta e delego ao @architect; eu municio, ele escolhe.

package/tasks/spec-write-spec.md

@@ -0,0 +1,50 @@
+---
+id: spec-write-spec
+agent: pm
+title: Escrever a spec formal (spec pipeline — fase 4)
+inputs: ['docs/specs/{slug}/requirements.md', complexity.json e research.md (se existirem)]
+outputs: ['docs/specs/{slug}/spec.md formal', cada afirmação rastreada a FR-*/NFR-*/CON-*/achado]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Escrever a spec formal (spec pipeline — fase 4)
+
+**Objetivo:** gerar a spec formal a partir dos requisitos elicitados — um documento onde **toda
+afirmação rastreia** a um FR-*/NFR-*/CON-* ou achado de pesquisa, pronto para a crítica do @qa.
+
+**Pré-condições:**
+- `requirements.md` existe e está completo (saída de `spec-gather-requirements`). Se há requisito órfão
+  ou ambiguidade não resolvida, **pare** e volte à fase de gather.
+- Se o @architect classificou a complexidade (`complexity.json`), respeito o conjunto de fases dele
+  (SIMPLE pula pesquisa). Se houver `research.md`, ele é fonte válida de rastro.
+
+## Passos
+
+1. **Carregue os requisitos** (`requirements.md`) e, se existirem, a avaliação de complexidade e a
+   pesquisa. Estes são as **únicas** fontes válidas de conteúdo da spec.
+2. **Escreva a spec** a partir de `templates/spec-tmpl.md`: contexto/problema, comportamento esperado,
+   critérios de aceite, requisitos cobertos, não-escopo, riscos.
+3. **Gate Constitucional (Art. IV — No Invention):** para CADA afirmação da spec, anote o rastro ao
+   `FR-*`/`NFR-*`/`CON-*` ou ao achado de pesquisa que a origina. **Afirmação sem rastro não entra** —
+   ou viro pergunta, ou removo. Nada de feature "porque seria legal".
+4. **Verifique cobertura:** todo FR/NFR/CON do requirements.md está endereçado na spec (coberto ou
+   explicitamente diferido). Lacuna vira nota, não invenção.
+5. **Salve em `docs/specs/{slug}/spec.md`** e roteie para a **crítica do @qa** (fase de critique). A
+   crítica e o plano de implementação **não são meus** — sigo o fluxo (@qa critica, @architect planeja).
+
+## Critério de pronto (DoD)
+
+- [ ] Toda afirmação da spec rastreia a um `FR-*`/`NFR-*`/`CON-*` ou achado (Gate Art. IV cumprido)
+- [ ] Todo requisito do `requirements.md` está coberto ou explicitamente diferido
+- [ ] Critérios de aceite verificáveis e não-escopo explícito
+- [ ] Spec salva em `docs/specs/{slug}/spec.md` e roteada ao @qa para crítica
+
+## Falha / recuperação
+
+- **Quero afirmar algo sem rastro** → o Gate Art. IV bloqueia; removo a afirmação ou viro pergunta ao
+  stakeholder/@analyst.
+- **requirements.md tem ambiguidade não resolvida** → volto à fase `spec-gather-requirements`; não
+  resolvo a ambiguidade inventando.
+- **A crítica do @qa reprova (NEEDS_REVISION)** → reviso a spec conforme o feedback e devolvo; não pulo
+  a crítica nem decido a aprovação por conta própria.

package/tasks/test-as-user.md

@@ -0,0 +1,52 @@
+---
+id: test-as-user
+agent: data-engineer
+title: Emular usuário para validar RLS
+inputs: [user_id, table, story]
+outputs: [resultado positivo/negativo, veredito de cobertura RLS]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Emular usuário para validar RLS
+
+**Objetivo:** comprovar que uma política RLS faz o que diz — assumindo a identidade de um usuário e
+verificando que ele vê/altera só o que é dele (positivo) e é bloqueado no que não é (negativo).
+
+**Pré-condições:**
+- RLS está habilitada na tabela e há ao menos uma política instalada (via `db-policy-apply`). Sem
+  política, este teste não tem o que validar.
+- Existem dados de teste de pelo menos dois donos distintos (o `user_id` alvo e um terceiro). Se não
+  houver, semeio com `*seed` antes — sem comparar donos não existe teste negativo.
+
+## Passos
+
+1. **Defina o cenário:** o `user_id` alvo, as linhas que ele DEVE ver e as linhas de um terceiro que
+   ele NÃO pode ver/alterar. O cenário rastreia à regra de acesso da story.
+2. **Assuma a identidade** numa transação, sem service role (service role bypassa RLS e invalida o
+   teste): `BEGIN; SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claim.sub = '{user_id}';`.
+3. **Teste positivo (SELECT):** o usuário lê suas linhas. Conta esperada confere? Se não, política
+   restritiva demais.
+4. **Teste positivo (escrita):** o usuário faz INSERT/UPDATE/DELETE no que é dele e a operação passa.
+5. **Teste negativo (SELECT):** consulta as linhas do terceiro — resultado DEVE ser vazio.
+6. **Teste negativo (escrita):** tenta UPDATE/DELETE na linha do terceiro — DEVE afetar 0 linhas ou
+   ser negado. Linha de outro dono alterada = vazamento.
+7. **`ROLLBACK`** sempre ao final: este é um teste, não pode deixar rastro nem mutação no banco.
+8. **Emita o veredito:** PASS (positivos passam, negativos bloqueiam) ou FAIL (com a brecha exata).
+
+## Critério de pronto (DoD)
+
+- [ ] Identidade assumida sem service role (RLS realmente em vigor no teste)
+- [ ] Positivos passam: o dono lê e escreve o que é dele
+- [ ] Negativos bloqueiam: terceiro não lê nem altera o que não é dele (0 linhas)
+- [ ] Transação revertida ao final (sem efeito colateral no banco)
+- [ ] Veredito registrado no rastro da story
+
+## Falha / recuperação
+
+- **Teste negativo falha (vazamento)** → FAIL; devolvo à `db-policy-apply` com o predicado a corrigir.
+  Não declaro a política pronta.
+- **`auth.uid()`/claim NULL** → o ambiente não tem auth ou o claim não foi setado; corrijo o `SET
+  LOCAL` ou sinalizo a falta de auth e suspendo o teste.
+- **Faltam dados de dois donos** → semeio com `*seed` e repito; comparar um dono só não comprova RLS.
+- **Esqueci o `ROLLBACK` e mutei o banco** → restauro via `*rollback` do snapshot mais recente.

package/tasks/ux-create-wireframe.md

@@ -0,0 +1,54 @@
+---
+id: ux-create-wireframe
+agent: ux-design-expert
+title: Criar wireframes e fluxos de interação
+inputs: [personas, mapa de necessidades, story/spec, fidelidade desejada]
+outputs: [wireframes, fluxo de interação, mapeamento tela→AC]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Criar wireframes e fluxos de interação
+
+**Objetivo:** materializar a pesquisa em estrutura e fluxo de baixa fidelidade — barato de mudar,
+fácil de testar — antes de qualquer polimento visual.
+
+**Pré-condições:**
+- Existe pesquisa de usuário (personas + necessidades) da task `ux-user-research`, OU as
+  necessidades estão explícitas na story. Se ninguém validou o usuário, **sinalize** que o wireframe
+  parte de hipótese.
+- A story/spec define as telas/fluxos no escopo. Sem isso, **pare** — não invento telas.
+
+## Passos
+
+1. **Liste as telas e os estados** que a story exige (vazio, carregando, erro, sucesso, sem
+   permissão). Estado não é detalhe — é metade da experiência.
+2. **Desenhe o fluxo de interação** ligando as telas: entrada, decisões do usuário, caminhos de erro
+   e de saída. Cada passo do fluxo resolve uma necessidade da persona.
+3. **Esboce cada tela na fidelidade pedida** (baixa = blocos e hierarquia; média = layout e
+   conteúdo real). Foque em estrutura, hierarquia e affordance — não em cor nem polimento.
+4. **Embuta a acessibilidade desde o esboço:** ordem de foco/tab, alvos de toque, hierarquia
+   semântica de cabeçalhos, alternativa textual para conteúdo visual. A11y não é camada posterior.
+5. **Mapeie cada tela/fluxo ao AC** da story que ele atende. Tela que não rastreia a um AC sai do
+   wireframe — é escopo inventado.
+6. **Registre os wireframes** em `docs/stories/{epic}/wireframes/` (ou link na seção de UX da story)
+   com legenda de estados e do fluxo.
+7. **Roteie para validação:** wireframe pronto vai para revisão com o usuário/stakeholder e alimenta
+   a `create-front-end-spec`. Itero com o feedback antes de detalhar.
+
+## Critério de pronto (DoD)
+
+- [ ] Todas as telas e estados (vazio/carregando/erro/sucesso) esboçados
+- [ ] Fluxo de interação completo, incluindo caminhos de erro
+- [ ] Considerações de acessibilidade marcadas em cada tela (foco, semântica, alvos)
+- [ ] Cada tela/fluxo mapeado a um AC da story
+- [ ] Wireframes registrados e prontos para validação/iteração
+
+## Falha / recuperação
+
+- **Falta pesquisa de usuário** → produzo wireframe marcado como hipótese e priorizo validação antes
+  de avançar para a spec.
+- **A story não cobre um fluxo necessário** (ex.: estado de erro não especificado) → paro, registro a
+  lacuna e devolvo ao @sm/@po; não invento o requisito.
+- **Decisão de stack/framework de frontend aparece** (SPA vs SSR, biblioteca) → delego à Aria
+  (@architect); eu trago só a lente de UX.

package/tasks/ux-user-research.md

@@ -0,0 +1,55 @@
+---
+id: ux-user-research
+agent: ux-design-expert
+title: Pesquisa de usuário e análise de necessidades
+inputs: [story, contexto do produto, evidências de usuário disponíveis]
+outputs: [personas, mapa de necessidades/dores, achados de pesquisa rastreáveis]
+elicit: true
+modes: [interactive]
+---
+
+# Pesquisa de usuário e análise de necessidades
+
+**Objetivo:** descobrir quem é o usuário real e qual é a dor concreta antes de desenhar um pixel,
+produzindo personas e necessidades que toda decisão de design subsequente vai rastrear.
+
+**Pré-condições:**
+- Existe uma story/spec ou objetivo de produto que delimita o escopo. Sem isso, **pare** e elicite —
+  pesquisa sem alvo vira opinião com aparência de método.
+- Há acesso a alguma evidência de usuário (entrevistas, analytics, suporte, tickets) OU o usuário
+  pode fornecê-la. Se não há nenhuma fonte real, sinalize que o resultado será **hipótese**, não
+  decisão validada.
+
+## Passos
+
+1. **Delimite a pergunta de pesquisa** a partir da story/spec: que usuário, que tarefa, que contexto
+   estou investigando? Escreva a pergunta antes de coletar dado.
+2. **Inventarie as fontes de evidência disponíveis** — entrevistas, analytics, tickets de suporte,
+   reviews, sessões gravadas. Liste o que existe e o que falta.
+3. **[ELICITAÇÃO] Confirme com o usuário as fontes e o público-alvo.** Apresente as fontes
+   encontradas e pergunte: este é o usuário certo? falta algum segmento? Não avance no escuro — esta
+   é a interação obrigatória.
+4. **Extraia padrões das evidências.** Agrupe dores, objetivos e contextos recorrentes. Para cada
+   padrão, registre a fonte (de onde veio o dado) — sem fonte, marque explicitamente como hipótese.
+5. **Construa as personas** a partir dos padrões: objetivos, dores, contexto de uso, restrições
+   (inclusive acessibilidade — quem navega por teclado, leitor de tela, conexão ruim).
+6. **Monte o mapa de necessidades**, cada necessidade ligada a (a) uma persona e (b) um FR/NFR/CON
+   da story ou um achado de pesquisa. Necessidade órfã não entra.
+7. **Registre os achados** em `docs/stories/{epic}/research/` (ou na seção de UX da story),
+   marcando claramente o que é evidência e o que é hipótese a validar.
+
+## Critério de pronto (DoD)
+
+- [ ] Pergunta de pesquisa explícita e ligada à story/spec
+- [ ] Ponto de elicitação cumprido (público-alvo e fontes confirmados com o usuário)
+- [ ] Personas com objetivos, dores, contexto e restrições de acessibilidade
+- [ ] Toda necessidade rastreia a uma persona e a um FR/NFR/CON ou achado
+- [ ] Evidência e hipótese claramente separadas — nada apresentado como validado sem fonte
+
+## Falha / recuperação
+
+- **Não há nenhuma evidência real de usuário** → não fabrique persona; declare o resultado como
+  hipótese e proponha o método mínimo de validação antes do design comprometer.
+- **A pesquisa em profundidade excede a lente de UX** (mercado, segmentação, concorrência) → delego
+  ao @analyst e incorporo o retorno.
+- **A story não delimita usuário nem tarefa** → paro e devolvo ao @sm/@po; não invento o público.

package/tasks/validate-next-story.md

@@ -0,0 +1,61 @@
+---
+id: validate-next-story
+agent: po
+title: Validar a prontidão de uma story (gate GO/NO-GO)
+inputs: [story]
+outputs: [veredito GO/NO-GO, lista de correções com dono, score do checklist]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Validar a prontidão de uma story (gate GO/NO-GO)
+
+**Objetivo:** decidir se uma story se sustenta sozinha — escopo claro, ACs testáveis,
+dependências mapeadas, rastreabilidade ao PRD — emitindo um veredito GO/NO-GO antes que alguém
+escreva uma linha de código.
+
+**Pré-condições:**
+- A story existe em `docs/stories/` e está em status `Draft` (foi criada pelo @sm). Se já estiver
+  validada ou em implementação, **pare** — não revalido o que já passou do portão.
+- O PRD/epic que originou a story existe e está acessível. Sem a fonte, eu não tenho contra o que
+  validar; **pare** e peça a referência.
+
+## Passos
+
+1. **Leia a fonte antes da story.** Abra o PRD/epic de origem em `docs/` e identifique os FR/NFR/CON
+   que a story deveria cumprir. Validar sem referência é chutar — a fonte é o gabarito.
+2. **Leia a story COMPLETA** — título, escopo, ACs, notas, seção de Testing, File List prevista.
+3. **Rode o checklist de 10 pontos** (`po-master-checklist`), marcando cada item PASS/FAIL:
+   escopo claro · ACs testáveis · dependências mapeadas · sequência lógica · rastreabilidade ao
+   PRD · gate de qualidade planejado (revisão/QA) · estimativa coerente · sem ambiguidade · sem
+   invenção (Art. IV) · File List preparada.
+4. **Teste cada AC como o @qa testaria.** Para cada critério pergunte: "que teste prova isto?". Se
+   você não consegue formular o teste, o AC FALHA — anote como correção obrigatória do @sm.
+5. **Verifique a cadeia de dependências.** O que esta story precisa que já exista? O que ela
+   destrava? Está na ordem certa no backlog? Dependência faltante é NO-GO automático.
+6. **Cheque rastreabilidade (Art. IV — No Invention).** Cada afirmação da story rastreia a um
+   FR/NFR/CON ou achado de pesquisa? Requisito inventado sem fonte = NO-GO até a origem aparecer.
+7. **Emita o veredito.** GO se score ≥ 7/10 **e** nenhum item crítico falhou (AC não-testável,
+   dependência faltante, invenção). Senão NO-GO, com a lista exata de correções e o dono de cada uma.
+8. **Roteie o próximo passo.** GO → segue para `@dev` implementar. NO-GO de story → volta ao `@sm`.
+   NO-GO de escopo → volta ao `@pm`. Conflito entre PRD/epic/story → escalo correção de curso ao
+   `@nexus-master`. **Eu não corrijo — devolvo com o mapa do conserto.**
+
+## Critério de pronto (DoD)
+
+- [ ] Fonte (PRD/epic) lida e os FR/NFR/CON relevantes identificados
+- [ ] Checklist de 10 pontos rodado, cada item com PASS/FAIL e score calculado
+- [ ] Cada AC testado mentalmente; os não-testáveis listados como correção obrigatória
+- [ ] Cadeia de dependências verificada; faltantes sinalizadas
+- [ ] Veredito GO/NO-GO emitido com justificativa
+- [ ] NO-GO acompanhado da lista de correções com dono explícito por item
+- [ ] Próximo passo roteado (@dev / @sm / @pm / @nexus-master)
+
+## Falha / recuperação
+
+- **Faltou o PRD/epic de origem** → não valido sem gabarito; sinalizo e peço a referência ao @pm.
+- **Conflito de escopo entre PRD, epic e story** → não escolho um lado em silêncio; sinalizo o
+  conflito e escalo a correção de curso ao @nexus-master.
+- **A story muda no meio da validação** (alguém editou) → reinicio do passo 2 sobre a versão atual.
+- **Tentação de "passar e a gente vê depois"** → bloqueio cedo e em voz alta. Defeito barato é o
+  que se pega no portão; defeito caro é o que vaza dele. Pressa de sprint não compra exceção.

package/tasks/validate-squad.md

@@ -0,0 +1,55 @@
+---
+id: validate-squad
+agent: squad-creator
+title: Validar a integridade de um squad
+inputs: ['id do squad (squads/{id}/)']
+outputs: [veredito PASS/FAIL com a lista de issues encontrados]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Validar a integridade de um squad
+
+**Objetivo:** emitir um veredito verificável (PASS/FAIL) sobre a integridade de um squad
+materializado — manifest, DNA dos membros, tasks e delegações — com cada issue nomeado e citável
+(arquivo:campo).
+
+**Pré-condições:**
+- `squads/{id}/` existe no disco. Diretório ausente → FAIL imediato com a causa ("squad não
+  materializado"), não silêncio.
+
+## Passos
+
+1. **Leia o manifest** (`squads/{id}/squad.yaml`) e verifique os campos obrigatórios: `id` (casa
+   com o nome do diretório), `name`, `mission`, `version`, `chief`, `origin`, `traceRef`, `guards`,
+   `authorities`. `traceRef` vazio ou não rastreável = issue (Art. IV).
+2. **Valide o DNA de cada membro** (`squads/{id}/agents/*.md`) contra o contrato `Agent`
+   (frontmatter parseia; archetype/model dentro dos enums). Verifique o formato canônico do corpo
+   (Identidade/Princípios/Método/Comandos/Guardas/Voz presentes).
+3. **Cheque a composição:** o `chief` do manifest existe em `agents/` e tem archetype
+   `Orchestrator`; o time tem entre chief+2 e chief+7 membros; ids únicos; nenhum membro duplica
+   um papel do time core (mesma lente/whenToUse de um agente de `agents/` do core = issue REUSE).
+4. **Cheque declarado = real na camada procedural:** todo slug em `owns:` de cada membro tem
+   `squads/{id}/tasks/{slug}.md` OU é referência explícita a uma task core existente em `tasks/`.
+   Task copiada do core para dentro do squad (mesmo id de uma task core) = issue.
+5. **Cheque as delegações:** todo `delegatesTo.agent` resolve para um membro do squad OU para um
+   agente do core. Verifique que nenhuma `authority` do manifest colide com operação exclusiva do
+   core (git push/PR/release/MCP → @devops).
+6. **Cheque o knowledge:** toda ref em `knowledge:` dos membros existe em
+   `squads/{id}/knowledge/` ou em `knowledge/` do core.
+7. **Emita o veredito:** PASS (zero issues) ou FAIL com a lista completa — cada issue com
+   arquivo:campo e o motivo. Veredito sem evidência citável não é veredito (Lei 2).
+
+## Critério de pronto (DoD)
+
+- [ ] Manifest, DNA, composição, tasks, delegações e knowledge verificados — nenhum check pulado
+- [ ] Cada issue reportado com arquivo:campo e motivo (evidência citável)
+- [ ] Veredito único e explícito: PASS ou FAIL — sem "quase passou"
+
+## Falha / recuperação
+
+- **O squad não existe no disco** → FAIL com causa "não materializado"; sugira `create-squad`.
+- **Um arquivo não parseia** (YAML/frontmatter quebrado) → o arquivo é issue, a validação CONTINUA
+  nos demais — o relatório é completo, não interrompido no primeiro erro.
+- **FAIL** → o conserto é do dono do blueprint: `extend-squad` corrige aditivamente; issue
+  estrutural (chief errado, duplicação do core) volta para `create-squad` re-emitir o blueprint.