nexus-core-v3 3.0.0

package/tasks/qa-review-story.md

@@ -0,0 +1,56 @@
+---
+id: qa-review-story
+agent: qa
+title: Review completo de uma story com decisão de gate
+inputs: [story]
+outputs: [seção "QA Results" da story, decisão de gate, fix-request (se FAIL/CONCERNS)]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Review completo de uma story com decisão de gate
+
+**Objetivo:** auditar uma story marcada `Ready for Review` em todos os eixos de risco e emitir uma
+decisão de gate fundamentada — escrevendo SOMENTE a seção "QA Results" da story.
+
+**Pré-condições:**
+- A story existe e está em `Ready for Review`. Se estiver em `Draft`/`InProgress`, **pare** e
+  reporte — não reviso o que o @dev ainda não declarou pronto.
+- A story tem ACs e seção de Testing. Sem o contrato, não há barra a julgar: devolvo ao @sm/@po.
+
+## Passos
+
+1. **Entendo o contrato.** Leio a story COMPLETA — ACs, escopo, Dev Notes, Testing, File List. Defino
+   o que "pronto" significa AQUI antes de julgar qualquer linha.
+2. **Perfilo o risco** (`qa-risk-profile`). Mapeio probabilidade × impacto por área para decidir onde
+   mergulho fundo e onde sou concisa. Profundidade segue o sinal de risco, não o humor.
+3. **Scan automatizado PRIMEIRO** (`*code-review`, CodeRabbit). Roda antes da análise manual,
+   self-healing de no máximo 2 iterações para CRITICAL/HIGH. Não começo o manual antes do scan fechar.
+4. **Caço o que falha em produção**, com profundidade proporcional ao risco: segurança
+   (`qa-security-checklist`), NFRs (`qa-nfr-assess`), migrations (`qa-migration-validation`), console
+   do browser (`qa-browser-console-check`).
+5. **Rastreio requisito → teste** (`qa-trace-requirements`). Toda AC ganha seu Given-When-Then. AC
+   órfã vira gap registrado, com severidade.
+6. **Verifico evidência e falso-positivo** (`qa-evidence-requirements`, `qa-false-positive-detection`).
+   "Corrigido" sem teste de regressão é hipótese, não fato.
+7. **Emito o gate** (`qa-gate`): PASS / CONCERNS / FAIL / WAIVED, com fundamentação rastreável a AC,
+   NFR ou CON. Escrevo a decisão na seção "QA Results" da story — nada mais.
+8. **Roteio a saída.** FAIL/CONCERNS → gero o fix-request (`qa-create-fix-request`) e devolvo ao @dev
+   com o defeito preciso. PASS e pronto pra subir → @devops. Nunca subo nada eu mesma.
+
+## Critério de pronto (DoD)
+
+- [ ] Story lida por inteiro e contrato ("pronto") definido antes do julgamento
+- [ ] Scan automatizado rodado e fechado antes da análise manual
+- [ ] Todos os eixos de risco cobertos com profundidade proporcional ao risco
+- [ ] Toda AC rastreada a teste; gaps registrados com severidade
+- [ ] Decisão de gate emitida com fundamentação rastreável
+- [ ] Apenas a seção "QA Results" foi escrita — nenhuma outra seção tocada
+- [ ] Saída roteada: @dev (fix-request) ou @devops (subida)
+
+## Falha / recuperação
+
+- **Scan automatizado mantém CRITICAL após 2 iterações** → registro e o gate não pode ser PASS.
+- **Story sem ACs ou sem Testing** → HALT, devolvo ao @sm/@po; não invento o contrato.
+- **Evidência ausente para um "funciona"** → CONCERNS no mínimo; não aprovo no escuro.
+- **Achado exige correção de código** → gero fix-request e delego ao @dev; não conserto eu mesma.

package/tasks/qa-risk-profile.md

@@ -0,0 +1,45 @@
+---
+id: qa-risk-profile
+agent: qa
+title: Gerar a matriz de risco da story
+inputs: [story]
+outputs: [matriz de risco (probabilidade × impacto), áreas priorizadas para review]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Gerar a matriz de risco da story
+
+**Objetivo:** mapear onde a story pode falhar em produção — por probabilidade × impacto — para que o
+review mergulhe fundo onde o risco aponta e seja conciso onde não aponta.
+
+**Pré-condições:**
+- A story existe e tem ACs e escopo legíveis. Sem escopo, **pare**: não há área a perfilar.
+
+## Passos
+
+1. **Decomponho a story em áreas de mudança** (módulos, fluxos, dados, integrações). Cada área é uma
+   linha da matriz.
+2. **Pontuo probabilidade** de cada área (1=raro … 5=quase certo) com base em sinais concretos:
+   complexidade, novidade da tecnologia, acoplamento, histórico de bugs na área.
+3. **Pontuo impacto** de cada área (1=cosmético … 5=catastrófico): dado sensível, caminho crítico,
+   irreversibilidade, alcance de usuários afetados.
+4. **Calculo o score** (probabilidade × impacto) e classifico: ALTO (>=12), MÉDIO (6–11), BAIXO (<6).
+5. **Priorizo o escrutínio.** Áreas ALTO recebem review profundo (segurança, NFR, regressão); BAIXO
+   recebe checagem proporcional. Caminho crítico e dado sensível nunca caem para checagem trivial.
+6. **Registro a matriz** como insumo para `qa-review-story` e `qa-gate`. Cada score rastreia à AC/área
+   correspondente — sem inventar risco fora do escopo da story.
+
+## Critério de pronto (DoD)
+
+- [ ] Toda área de mudança da story tem uma linha na matriz
+- [ ] Probabilidade e impacto pontuados com sinal concreto, não palpite
+- [ ] Score calculado e classificado (ALTO/MÉDIO/BAIXO)
+- [ ] Áreas priorizadas para a profundidade do review
+- [ ] Cada risco rastreia a uma AC/área da story
+
+## Falha / recuperação
+
+- **Escopo da story ambíguo demais para perfilar** → registro a lacuna e devolvo ao @sm/@po.
+- **Área de alto risco sem AC que a cubra** → registro como gap de cobertura para o gate, não invento
+  o requisito.

package/tasks/qa-security-checklist.md

@@ -0,0 +1,64 @@
+---
+id: qa-security-checklist
+agent: qa
+title: Scan de segurança de 8 pontos
+inputs: [story, diff]
+outputs: [achados de segurança rastreados, entrada na seção QA Results]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Scan de segurança de 8 pontos
+
+**Objetivo:** varrer a mudança da story contra as 8 classes de vulnerabilidade mais comuns e
+registrar cada achado com severidade rastreável a uma AC/NFR — antes que vire incidente em produção.
+
+**Pré-condições:**
+- A story existe e tem ACs. Se não houver contrato a rastrear, **pare** — eu não invento critério de
+  segurança fora da story/spec.
+- O `diff` da mudança está disponível (commit local do @dev). Sem código para inspecionar, não há scan.
+- O scan automatizado (`*code-review`) já rodou. Eu não refaço à mão o que a máquina pega de graça.
+
+## Passos
+
+1. **Defina o perímetro de risco.** Liste o que a story toca: entrada de usuário, autenticação,
+   dados sensíveis, chamadas externas. O eixo de maior risco recebe o mergulho mais profundo.
+2. **Percorra os 8 pontos**, marcando cada um PASS / CONCERNS / FAIL com evidência (linha/arquivo):
+   a. **Injeção** — SQL/NoSQL/command: toda query usa parâmetro/prepared statement? Nenhuma
+      concatenação de input cru.
+   b. **XSS** — todo dado renderizado é escapado/sanitizado? Nenhum `dangerouslySetInnerHTML` sem
+      sanitização.
+   c. **Secrets hardcoded** — nenhuma chave/token/senha no código ou em log. Tudo via env/cofre.
+   d. **AuthN/AuthZ** — o endpoint verifica identidade E permissão? Nenhuma rota sensível sem guarda.
+   e. **Validação de input** — todo input é validado em tipo/tamanho/range no servidor (não só no
+      cliente).
+   f. **Exposição de dado sensível** — nenhum PII/credencial em resposta, log ou mensagem de erro.
+   g. **Dependências** — nenhuma lib com CVE conhecida introduzida pela mudança.
+   h. **Configuração insegura** — CORS, headers, defaults permissivos, debug ligado em prod.
+3. **Rastreie cada achado** a uma AC ou NFR. Achado sem âncora no contrato vira nota, não bloqueio —
+   mas exposição de secret/PII é FAIL independentemente, por ser risco real.
+4. **Atribua severidade** por probabilidade × impacto: CRITICAL/HIGH bloqueiam; MEDIUM/LOW viram
+   CONCERNS documentado.
+5. **Escreva o resultado** SOMENTE na seção "QA Results" da story: pontos avaliados, achados, severidade
+   e evidência. Não toco em mais nada da story.
+6. **Roteie a saída.** Achado CRITICAL/HIGH → `*create-fix-request` para o @dev com o defeito preciso.
+   Limpo → alimenta o `*gate`.
+
+## Critério de pronto (DoD)
+
+- [ ] Os 8 pontos avaliados, cada um com veredito e evidência
+- [ ] Cada achado rastreia a uma AC/NFR ou é risco real autoevidente (secret/PII)
+- [ ] Severidade atribuída por probabilidade × impacto
+- [ ] Resultado escrito só na seção QA Results
+- [ ] CRITICAL/HIGH roteado ao @dev via fix-request
+
+## Falha / recuperação
+
+- **Diff indisponível ou parcial** → HALT, reporto que não posso assegurar segurança sem ver o código
+  completo. Não aprovo no escuro.
+- **Achado CRITICAL (secret/injeção)** → FAIL imediato, fix-request ao @dev. Não dou PASS por pressão
+  de prazo.
+- **A correção exige tocar infra/config externa** (CORS, secret store) → delego ao @devops; eu aponto,
+  ele opera o ambiente.
+- **A mudança não tem teste de segurança para o caminho corrigido** → registro como gap no gate; risco
+  sem regressão é hipótese, não fato.

package/tasks/qa-test-design.md

@@ -0,0 +1,47 @@
+---
+id: qa-test-design
+agent: qa
+title: Desenhar os cenários de teste da story
+inputs: [story]
+outputs: [conjunto de cenários de teste em Given-When-Then, por nível e prioridade]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Desenhar os cenários de teste da story
+
+**Objetivo:** produzir o conjunto de cenários que prova cada AC e cobre os caminhos de falha — em
+Given-When-Then, priorizados por risco e distribuídos pelo nível certo (unit/integração/e2e).
+
+**Pré-condições:**
+- A story existe, com ACs e seção de Testing. Sem ACs, **pare**: não há o que provar.
+- O risco já foi perfilado (`qa-risk-profile`), para priorizar onde a cobertura precisa ser densa.
+
+## Passos
+
+1. **Mapeio um cenário por AC**, no mínimo, em Given-When-Then. Caminho feliz é o piso, não o teto.
+2. **Adiciono cenários de borda e falha** onde o risco aponta: input inválido, limite, concorrência,
+   estado parcial, erro de dependência. Áreas ALTO recebem mais cenários; BAIXO recebe o proporcional.
+3. **Escolho o nível certo** para cada cenário (REUSE > ADAPT > CREATE de fixtures): unit para lógica
+   pura, integração para contratos entre módulos, e2e só onde o fluxo do usuário exige. Não testo no
+   nível caro o que o barato cobre.
+4. **Priorizo** cada cenário (P0 bloqueador, P1 importante, P2 desejável) pelo score de risco da área.
+5. **Verifico cobertura:** toda AC tem ao menos um cenário; nenhum cenário inventa requisito fora da
+   story. Lacunas viram gap registrado para o gate.
+6. **Entrego o desenho** como insumo para `create-suite` (implementação da suíte) e para
+   `qa-trace-requirements` (rastreabilidade).
+
+## Critério de pronto (DoD)
+
+- [ ] Cada AC coberta por pelo menos um cenário em Given-When-Then
+- [ ] Cenários de borda/falha presentes onde o risco aponta
+- [ ] Cada cenário no nível certo (unit/integração/e2e), sem redundância cara
+- [ ] Cenários priorizados (P0/P1/P2) pelo risco
+- [ ] Nenhum cenário inventa requisito fora da story; gaps registrados
+
+## Falha / recuperação
+
+- **AC ambígua/intestável** → registro a lacuna e devolvo ao @sm/@po; não desenho teste para um
+  requisito que não existe.
+- **Cobertura impossível no nível disponível** → registro como CONCERNS e proponho o nível necessário
+  ao gate.

package/tasks/qa-trace-requirements.md

@@ -0,0 +1,48 @@
+---
+id: qa-trace-requirements
+agent: qa
+title: Mapear cada AC para teste (rastreabilidade)
+inputs: [story]
+outputs: [matriz de rastreabilidade AC→teste, lista de gaps com severidade]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Mapear cada AC para teste (rastreabilidade)
+
+**Objetivo:** provar que toda AC da story tem teste que a verifica em Given-When-Then — e nomear cada
+buraco (AC sem teste) com severidade, em vez de fechar os olhos.
+
+**Pré-condições:**
+- A story existe, com ACs explícitas. Sem ACs, **pare**: não há requisito a rastrear.
+- Existem testes (na File List / suíte) a mapear. Se não há suíte, o resultado é uma matriz cheia de
+  gaps — e isso já é o achado.
+
+## Passos
+
+1. **Listo cada AC** da story como linha da matriz de rastreabilidade.
+2. **Para cada AC, localizo o(s) teste(s)** que a verificam e descrevo o vínculo em Given-When-Then
+   (dado o estado, quando a ação, então o resultado esperado que prova a AC).
+3. **Marco a cobertura** por AC: COBERTA (teste verde rastreado), PARCIAL (só caminho feliz, falta
+   borda/falha), ÓRFÃ (nenhum teste).
+4. **Registro cada gap** (PARCIAL/ÓRFÃ) com severidade derivada do risco da AC: ÓRFÃ em área ALTO é
+   bloqueador; PARCIAL em área BAIXO é dívida.
+5. **Confirmo o inverso:** todo teste rastreia a alguma AC. Teste que não prova nada da story é ruído
+   — registro, mas não inflo a cobertura com ele.
+6. **Entrego a matriz** como insumo direto para `qa-gate` — a rastreabilidade é o que separa "achei
+   bonito" de "provei que atende".
+
+## Critério de pronto (DoD)
+
+- [ ] Toda AC é uma linha da matriz com status de cobertura
+- [ ] Cada vínculo AC→teste descrito em Given-When-Then
+- [ ] Todo gap (PARCIAL/ÓRFÃ) registrado com severidade derivada do risco
+- [ ] Inverso confirmado: testes sem AC identificados
+- [ ] Matriz entregue como insumo para o gate
+
+## Falha / recuperação
+
+- **AC intestável como escrita** → registro a lacuna e devolvo ao @sm/@po; não invento o teste de um
+  requisito ambíguo.
+- **AC órfã em área de alto risco** → marco como bloqueador para o gate (não pode ser PASS) e roteio
+  fix-request ao @dev para criar o teste faltante.

package/tasks/release-management.md

@@ -0,0 +1,53 @@
+---
+id: release-management
+agent: devops
+title: Criar release versionada
+inputs: [versão alvo, diff desde a última tag]
+outputs: [changelog, tag, GitHub release, caminho de rollback]
+elicit: true
+modes: [interactive]
+---
+
+# Criar release versionada
+
+**Objetivo:** publicar uma release versionada — changelog gerado, tag semântica e GitHub release —
+após confirmação humana, com o caminho de reversão claro. Release é exclusiva do @devops.
+
+**Pré-condições:**
+- A branch base (`main`/`master`) está verde: gate de qualidade passou e está sincronizada com o
+  remoto. Se há trabalho não auditado, **pare** e rode o `pre-push-quality-gate`.
+- A versão alvo respeita SemVer e foi confirmada via `*version-check` (ver `version-management`). Sem
+  bump confirmado, **pare**.
+
+## Passos
+
+1. **Detecte o contexto do repositório** — remoto, branch base e a última tag (`git describe --tags`).
+   Nunca assuma repo fixo.
+2. **Reúna o diff desde a última tag** (`git log {ultima-tag}..HEAD`) — a fonte do changelog. Tudo
+   rastreia a commits/stories reais; sem invenção de itens de release.
+3. **Gere o changelog** agrupando por tipo (feat, fix, breaking) a partir dos conventional commits.
+4. **Confirme o bump semântico.** MAJOR se há breaking change no diff; MINOR para feature compatível;
+   PATCH para fix. Se a versão alvo não bate com o diff, sinalize a divergência.
+5. **Revele a release proposta.** Mostre versão, changelog e a tag a criar.
+6. **[ELICITAÇÃO] Peça o "ok" explícito.** Release é irreversível na prática — exige confirmação humana.
+7. **Crie a tag** (`git tag -a v{versão}`) e a **GitHub release** (`gh release create`) com o changelog
+   como corpo. Empurre a tag para o remoto.
+8. **Reporte e deixe o rollback claro.** Devolvo a URL da release e o caminho de reversão (deletar tag
+   local/remota e a release pelo `gh` caso publicada por engano).
+
+## Critério de pronto (DoD)
+
+- [ ] Última tag detectada e diff coletado dinamicamente
+- [ ] Changelog gerado a partir dos commits reais (sem invenção)
+- [ ] Bump semântico coerente com o diff e confirmado
+- [ ] Confirmação humana obtida antes de tagear/publicar
+- [ ] Tag criada, release publicada e URL reportada com caminho de rollback
+
+## Falha / recuperação
+
+- **Bump diverge do diff** (ex.: PATCH com breaking change) → paro e re-confirmo a versão; SemVer é lei.
+- **Branch base não está verde** → não faço release; volto ao gate.
+- **Usuário não confirma** → não crio tag nem release.
+- **Tag já existe** → não sobrescrevo; reporto o conflito e proponho a próxima versão.
+- **Release publicada por engano** → executo o rollback documentado (deletar tag remota + release),
+  com novo "ok" do usuário.

package/tasks/repository-cleanup.md

@@ -0,0 +1,61 @@
+---
+id: repository-cleanup
+agent: devops
+title: Limpar o repositório — branches e artefatos obsoletos
+inputs: [repositório, objetivo de limpeza]
+outputs: [branches removidas, artefatos removidos, relatório de limpeza]
+elicit: true
+modes: [interactive]
+---
+
+# Limpar o repositório — branches e artefatos obsoletos
+
+**Objetivo:** identificar branches já mergeadas, branches velhas e artefatos obsoletos, apresentá-los
+ao usuário e remover apenas o que ele aprovar — mantendo o repositório limpo sem nunca apagar trabalho
+vivo.
+
+**Pré-condições:**
+- O diretório é um repositório git com remoto detectável. Se for greenfield (sem git), **pare** e
+  recomende `*environment-bootstrap` antes de qualquer limpeza.
+- A árvore de trabalho está limpa (sem mudanças não-commitadas que possam se perder). Se houver
+  pendências, **pare** e peça para o @dev commitar ou stashar antes.
+
+## Passos
+
+1. **Detecto o contexto do repositório.** Remoto, branch atual e branch protegida (`main`/`master`).
+   Nunca assumo um repo fixo — detecto dinamicamente.
+2. **Atualizo o estado remoto** com `git fetch --all --prune`, para que branches já deletadas no
+   remoto não apareçam como vivas localmente.
+3. **Classifico os candidatos** em três grupos, sem apagar nada ainda:
+   a. **branches locais já mergeadas** na protegida (`git branch --merged`), exceto a protegida e a atual;
+   b. **branches stale** (sem commits há um limite que confirmo com o usuário, ex.: 30 dias);
+   c. **artefatos obsoletos** (build, caches, logs) que rastreiam a uma story/objetivo de limpeza —
+      nunca arquivos de escopo desconhecido.
+4. **PONTO DE ELICITAÇÃO — apresento a lista e espero o "ok".** Mostro cada candidato com o motivo
+   (mergeada / stale / artefato) e o destino (local, remoto ou ambos). **Não removo nada sem a
+   aprovação explícita do usuário** — delete é destrutivo e pede confirmação humana.
+5. **Removo só o aprovado.** Branch local: `git branch -d` (nunca `-D` sem aprovação extra, pois `-d`
+   recusa branch não-mergeada como salvaguarda). Branch remota: `git push origin --delete {branch}` —
+   essa é operação de remoto, **exclusiva minha** (@devops). Artefatos: removo do disco e, se
+   versionados por engano, do índice.
+6. **NUNCA toco na protegida.** `main`/`master` jamais entra na lista de delete — nem local, nem remota.
+7. **Reporto e deixo o rollback claro.** Listo o que foi removido. Branch local recém-deletada é
+   recuperável pelo `reflog`; informo o SHA de cada branch removida para que o usuário possa
+   restaurá-la (`git branch {nome} {sha}`) se precisar.
+
+## Critério de pronto (DoD)
+
+- [ ] `git fetch --prune` executado; estado remoto sincronizado
+- [ ] Candidatos classificados (mergeadas / stale / artefatos) e apresentados ao usuário
+- [ ] Apenas itens explicitamente aprovados foram removidos
+- [ ] Branch protegida (`main`/`master`) intocada
+- [ ] Relatório de limpeza entregue com os SHAs para rollback
+
+## Falha / recuperação
+
+- **Usuário não aprova nenhum item** → encerro sem remover nada; limpeza é opcional, não obrigatória.
+- **Branch parece mergeada mas o `-d` recusa** → respeito a salvaguarda, sinalizo ao usuário e só uso
+  `-D` com aprovação explícita extra — não forço delete de trabalho não-integrado.
+- **Delete de branch remota falha** (permissão/branch protegida no GitHub) → reporto o erro, não
+  insisto, e deixo a branch como estava.
+- **Item removido por engano** → recupero via `reflog`/SHA registrado no relatório antes de encerrar.

package/tasks/route.md

@@ -0,0 +1,44 @@
+---
+id: route
+agent: nexus-master
+title: Rotear — despachar uma tarefa de dono único
+inputs: [tarefa]
+outputs: [tarefa despachada ao agente dono]
+elicit: false
+modes: [yolo]
+---
+
+# Rotear — despachar uma tarefa de dono único
+
+**Objetivo:** entregar uma tarefa de dono único ao agente certo, sem decompor nem deliberar — quando
+o trabalho é claramente de uma lane só.
+
+**Pré-condições:**
+- A tarefa tem **um dono óbvio** (ex.: "valida essa story" → @po; "desenha o schema" →
+  @data-engineer). Se precisa de várias frentes, use `orchestrate`; se é decisão, use `deliberate`.
+
+## Passos
+
+1. **Identifico o dono** pela matriz de autoridade: implementação→@dev, teste/gate→@qa,
+   arquitetura→@architect, PRD/epic→@pm, criar story→@sm, validar story→@po, banco→@data-engineer,
+   UX→@ux-design-expert, pesquisa→@analyst, git push/PR/release/MCP→@devops (exclusivo).
+2. **Verifico a autoridade.** Operação exclusiva (subida, PR, MCP) **sempre** vai pro @devops — nem eu
+   nem ninguém fura isso.
+3. **Despacho com contexto mínimo suficiente:** o quê, o critério de pronto, e os links que o dono
+   precisa. Não despejo contexto irrelevante.
+4. **Acompanho o handoff.** Quando o dono entrega, roteio o próximo passo da cadeia (ex.: @sm cria →
+   @po valida → @dev implementa → @qa gate → @devops sobe).
+
+## Critério de pronto (DoD)
+
+- [ ] Dono correto identificado pela matriz de autoridade
+- [ ] Operação exclusiva roteada ao @devops (nunca contornada)
+- [ ] Tarefa despachada com critério de pronto e contexto mínimo
+- [ ] Próximo passo da cadeia roteado no handoff
+
+## Falha / recuperação
+
+- **A tarefa não tem dono único** → não é roteamento; troco para `orchestrate` (várias frentes) ou
+  `deliberate` (decisão).
+- **Dois agentes parecem donos** → eu medeio: defino a fronteira (ex.: @architect decide a tecnologia
+  de banco, @data-engineer implementa o schema) e roteio cada parte ao seu dono.

package/tasks/run-tests.md

@@ -0,0 +1,50 @@
+---
+id: run-tests
+agent: dev
+title: Rodar lint + toda a suíte de testes
+inputs: [projeto/escopo opcional]
+outputs: [resultado de lint, resultado da suíte, veredito verde/vermelho]
+elicit: false
+modes: [yolo, interactive]
+---
+
+# Rodar lint + toda a suíte de testes
+
+**Objetivo:** executar a validação completa do projeto — lint e a suíte inteira de testes — e emitir
+um veredito honesto de verde/vermelho, sem pular nada "por eficiência".
+
+**Pré-condições:**
+- As dependências do projeto estão instaladas e os scripts de lint/teste estão definidos. Se um
+  script não existe, **pare** e reporto — não invento comando de teste.
+
+## Passos
+
+1. **Identifico os comandos do projeto** (lint, typecheck, testes) a partir da configuração do
+   projeto. Não presumo o runner: leio o que o projeto declara.
+2. **Rodo o lint.** Registro o resultado. Limpo → sigo. Com erros → registro cada erro (eles contam
+   no veredito final).
+3. **Rodo o typecheck** (se o projeto tem). 0 erros → sigo. Caso contrário, registro.
+4. **Rodo TODA a suíte de testes** — sem `--bail` preguiçoso, sem filtrar só a área que mexi. Regressão
+   se pega rodando o conjunto inteiro. Capturo aprovados, falhos e pulados.
+5. **Emito o veredito:**
+   - **Verde:** lint limpo, typecheck 0, suíte 100% passando (sem pulados silenciosos).
+   - **Vermelho:** qualquer lint/typecheck com erro ou qualquer teste falhando — listo exatamente o
+     que quebrou, com o arquivo e a mensagem.
+6. **Reporto o resultado** de forma rastreável. Se vermelho e estou num loop de implementação, volto
+   ao código; não marco nada `[x]` com a suíte vermelha.
+
+## Critério de pronto (DoD)
+
+- [ ] Lint executado, resultado registrado
+- [ ] Typecheck executado (quando existe), resultado registrado
+- [ ] Suíte COMPLETA executada — não um subconjunto
+- [ ] Veredito verde/vermelho emitido, com a lista exata do que quebrou (se vermelho)
+
+## Falha / recuperação
+
+- **Um script de teste/lint não existe** → HALT e reporto; não improviso o comando.
+- **A suíte trava/pendura** → reporto o teste que pendura; não dou por verde uma suíte que não
+  terminou.
+- **Testes pulados silenciosamente** → trato como sinal amarelo: reporto os pulados; suíte com pulados
+  não declarados não é "verde de verdade".
+- **Vermelho** → reporto o que quebrou e devolvo ao loop de implementação; não marco pronto.

package/tasks/security-audit.md

@@ -0,0 +1,54 @@
+---
+id: security-audit
+agent: data-engineer
+title: Auditoria de segurança e qualidade do banco
+inputs: [scope, story]
+outputs: [relatório de achados por severidade, lista de remediações]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Auditoria de segurança e qualidade do banco
+
+**Objetivo:** auditar o banco no escopo pedido (`rls`, `schema` ou `full`) e emitir achados por
+severidade — cobertura de RLS, integridade do schema e exposição de segredos — com remediação clara.
+
+**Pré-condições:**
+- O `scope` é `rls`, `schema` ou `full`. Se ambíguo, default para `full`.
+- Acesso de leitura ao catálogo do banco (`pg_catalog`/`information_schema`). Esta é uma auditoria de
+  leitura — não altera nada.
+
+## Passos
+
+1. **Cobertura de RLS** (escopo `rls`/`full`): liste tabelas em schemas expostos sem `rowsecurity`
+   habilitado, e tabelas com RLS ligada mas sem política (negam tudo silenciosamente). Cada tabela
+   pública sem RLS é achado CRÍTICO.
+2. **Integridade do schema** (escopo `schema`/`full`): toda tabela tem PK? FKs declaradas têm índice
+   de suporte? Baseline presente (`id`/`created_at`/`updated_at`)? Colunas que deveriam ser `NOT NULL`
+   estão? CHECK constraints onde a regra de domínio exige?
+3. **Exposição de privilégio:** funções `SECURITY DEFINER` sem `search_path` fixo, GRANTs amplos a
+   `public`/`anon`, uso de service role onde RLS bastaria. Redijo qualquer segredo que apareça —
+   nunca ecoo token/senha completo.
+4. **Classifique cada achado** por severidade: CRÍTICO (tabela pública sem RLS, vazamento de
+   privilégio), ALTO (FK sem índice, baseline ausente em tabela quente), MÉDIO/BAIXO (convenção,
+   débito menor).
+5. **Proponha remediação por achado** rastreável: o quê, por quê, e o comando/migration sugerido —
+   sem aplicar nada nesta task (auditoria observa; correção é outra task).
+6. **Emita o relatório** ordenado por severidade, com contagem por nível e o veredito geral.
+
+## Critério de pronto (DoD)
+
+- [ ] Cobertura de RLS verificada em todas as tabelas do escopo
+- [ ] Integridade do schema checada (PK, FK+índice, baseline, NOT NULL, CHECK)
+- [ ] Exposição de privilégio avaliada; segredos redigidos
+- [ ] Cada achado tem severidade e remediação rastreável
+- [ ] Relatório emitido; nada alterado no banco
+
+## Falha / recuperação
+
+- **Achado CRÍTICO (tabela pública sem RLS / vazamento)** → marco como bloqueador e roteio a
+  remediação (`db-policy-apply` / migration) antes de qualquer subida.
+- **Sem acesso ao catálogo** → **pare** e reporte a lacuna de permissão; auditoria parcial não vale
+  como veredito.
+- **Remediação exige migration** → entrego o plano; a aplicação segue o fluxo snapshot → dry-run →
+  apply, e o push é do @devops.

package/tasks/setup-database.md

@@ -0,0 +1,60 @@
+---
+id: setup-database
+agent: data-engineer
+title: Configurar o projeto de banco de dados
+inputs: [tipo de banco (supabase/postgresql/mysql…), variáveis de ambiente]
+outputs: [estrutura do projeto de banco, .env validado, conexão verificada]
+elicit: true
+modes: [interactive]
+---
+
+# Configurar o projeto de banco de dados
+
+**Objetivo:** deixar o projeto de banco pronto para receber schema e migrations — estrutura de
+diretórios, ambiente validado e conexão verificada — com segurança desde a configuração.
+
+**Pré-condições:**
+- O tipo de banco está definido ou será elicitado (PostgreSQL/Supabase por padrão). A escolha de
+  tecnologia, se ainda em aberto, é do @architect — eu configuro o que foi decidido.
+- Há acesso às credenciais de conexão (ou ao cofre/`.env` onde elas vivem).
+
+## Passos
+
+1. **Confirme o tipo de banco e o ambiente alvo** (PONTO DE ELICITAÇÃO — exige confirmação do
+   usuário): qual engine? qual ambiente (local/staging/produção)? Eu não presumo produção nem
+   sobrescrevo ambiente sem o usuário dizer.
+2. **Crie a estrutura do projeto de banco** sob `docs/data-models/` (config) e `docs/data/` (docs):
+   diretórios para migrations, seeds, snapshots e políticas. Estrutura previsível é o que as tasks
+   `db-*` esperam.
+3. **Valide as variáveis de ambiente** (equivalente a `db-env-check`): host, porta, database, user,
+   credencial, modo SSL. Em produção, exijo Pooler com `sslmode=require`. Variável faltando = pare.
+4. **Verifique a conexão** com um teste leve (ping/`SELECT 1`). Sem conexão verificada, não declaro o
+   setup pronto.
+5. **Garanta o tratamento de segredo:** confirme que credenciais estão em `.env`/cofre e nunca em
+   código versionado; redijo qualquer segredo em logs. Service role, se presente, fica marcado como
+   sensível.
+6. **Crie um snapshot baseline inicial** (via `db-snapshot`) se já houver schema existente — ponto de
+   rollback antes de qualquer trabalho futuro.
+7. **Documente o setup** em `docs/data/setup.md`: tipo de banco, ambiente, estrutura criada e
+   pré-requisitos para as próximas tasks (`create-schema`, `create-migration-plan`).
+
+## Critério de pronto (DoD)
+
+- [ ] Tipo de banco e ambiente confirmados pelo usuário no ponto de elicitação
+- [ ] Estrutura de diretórios criada (migrations, seeds, snapshots, políticas)
+- [ ] Variáveis de ambiente validadas; produção com Pooler + `sslmode=require`
+- [ ] Conexão verificada (`SELECT 1` ou equivalente)
+- [ ] Segredos fora do versionamento e redigidos em logs
+- [ ] Snapshot baseline criado se havia schema preexistente
+- [ ] `docs/data/setup.md` escrito
+
+## Falha / recuperação
+
+- **Variável de ambiente ou credencial faltando** → paro e reporto exatamente qual; não invento valor
+  nem assumo default de produção.
+- **Conexão falha** → não declaro pronto; reporto o erro (com segredo redigido) e escalo a infra ao
+  @devops se for caso de rede/provisionamento.
+- **Provisionamento de infra/MCP/secrets remotos** → delego ao @devops; configuração de
+  infraestrutura e MCP é exclusiva dele, eu não toco.
+- **Escolha de engine ainda em aberto** → escalo ao @architect antes de configurar; não decido
+  tecnologia de sistema.

package/tasks/setup-design-system.md

@@ -0,0 +1,60 @@
+---
+id: setup-design-system
+agent: ux-design-expert
+title: Inicializar a estrutura do design system
+inputs: [design tokens, story/spec de design system]
+outputs: [estrutura Atomic Design inicializada, docs/design-system/]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Inicializar a estrutura do design system
+
+**Objetivo:** criar o esqueleto do design system seguindo Atomic Design (átomo → molécula →
+organismo → template → página), já cabeado aos design tokens, para que cada componente novo nasça
+consistente e sem valor hardcoded.
+
+**Pré-condições:**
+- Os design tokens já existem (`extract-tokens` rodou) em `docs/design-system/tokens/`. Sem
+  tokens, **pare**: estrutura sem fonte de verdade vira hardcode disfarçado.
+- Existe story/spec que pede o design system. Sem rastro, elicito — não invento arquitetura.
+- A decisão de stack de frontend (framework/bibliotecas) já é da Aria (@architect). Se ainda não
+  houver, **delego a decisão técnica** antes de cabear a estrutura a um framework.
+
+## Passos
+
+1. **Confirmo a stack** decidida pelo @architect (ex.: framework de componente, formato de estilo).
+   Eu não escolho stack sozinha — trago a lente de UX e uso a decisão dele.
+2. **Crio a árvore Atomic Design** em `docs/design-system/`:
+   - `tokens/` (já existente, da extração)
+   - `atoms/` (componentes atômicos)
+   - `molecules/` (composições de átomos)
+   - `organisms/` (composições de moléculas)
+   - `templates/` e `pages/` (estrutura de layout)
+   - `docs/` (pattern library gerada depois)
+3. **Cabeio os tokens** ao ponto de entrada do design system (import/registro dos tokens como fonte
+   de cor/espaçamento/tipografia), de forma que nenhum componente futuro precise de hex solto.
+4. **Defino as convenções mínimas**: padrão de nomenclatura, estrutura de cada componente
+   (componente + teste + tokens + a11y), e o índice de exportação. Documento isso num `README` da
+   pasta para quem construir depois seguir.
+5. **Crio o checklist de qualidade do componente** como referência (passa em WCAG AA, usa só tokens,
+   tem teste) apontando para `accessibility-wcag-checklist` — todo átomo nasce contra esse critério.
+6. **Registro os arquivos criados** na File List da story.
+7. **Roteio.** Estrutura pronta habilita `build-component` e `compose-molecule`. Integração na
+   aplicação além do design system é do @dev; subida é do @devops.
+
+## Critério de pronto (DoD)
+
+- [ ] Árvore Atomic Design criada em `docs/design-system/` (atoms → pages + docs)
+- [ ] Tokens cabeados como fonte única; nenhum ponto exige valor hardcoded
+- [ ] Convenções de nomenclatura/estrutura e índice de exportação documentados no README
+- [ ] Checklist de qualidade do componente referenciado (a11y + tokens + teste)
+- [ ] Stack confirmada com o @architect (não decidida por mim); File List atualizada
+
+## Falha / recuperação
+
+- **Tokens ausentes** → HALT; volto à `extract-tokens` antes de montar a estrutura.
+- **Stack de frontend indefinida** → delego a decisão à Aria (@architect) e pauso o setup até ter a
+  resposta — não escolho framework sozinha.
+- **Estrutura já existe parcialmente** → não sobrescrevo; reconcilio com o que há e registro o que
+  foi adicionado, sem destruir trabalho anterior.