nexus-core-v3 3.0.0

package/tasks/po-sync-story.md

@@ -0,0 +1,59 @@
+---
+id: po-sync-story
+agent: po
+title: Sincronizar uma story com a ferramenta de PM (push de metadados)
+inputs: [story, ferramenta (clickup|github|jira|local)]
+outputs: [story refletida na ferramenta de PM, mapa de IDs atualizado]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Sincronizar uma story com a ferramenta de PM (push de metadados)
+
+**Objetivo:** refletir o estado de uma story de `docs/stories/` na ferramenta de gestão de projeto
+configurada (ClickUp / GitHub Issues / Jira / local), mantendo título, status, ACs e File List
+consistentes nos dois lados.
+
+**Pré-condições:**
+- A story existe em `docs/stories/` e a ferramenta de PM alvo está configurada em `.nexus/`. Se não
+  houver provider configurado, **pare** e reporte — não invento integração.
+- A operação é de **metadados de story** (título, status, descrição, ACs, checklist). Operações de
+  git remoto e gestão de repositório **não** entram aqui.
+
+## Passos
+
+1. **Leia a story** em `docs/stories/` e extraia os campos sincronizáveis: título, status, ACs,
+   File List, prioridade, epic de origem.
+2. **Identifique o provider** alvo (`clickup` | `github` | `jira` | `local`) a partir da config em
+   `.nexus/`. Recupere o ID externo da story, se já sincronizada antes.
+3. **Detecte divergências** entre a story local e o item remoto: o que mudou de cada lado desde a
+   última sincronização (status, ACs, descrição).
+4. **Aplique a sincronização local→remoto** (esta task é push de metadados): crie o item se não
+   existir, ou atualize os campos divergentes no item existente. Marque os ACs como checklist na
+   ferramenta quando suportado.
+5. **Persista o mapa de IDs** (story local ↔ ID externo) em `.nexus/` para que o próximo
+   `*sync-story` / `*pull-story` saiba a correspondência.
+6. **Registre no Change Log da story** a data da sincronização e o destino.
+7. **Não opere git remoto.** Mesmo aqui, eu sincronizo **metadados de story** — não faço `git push`,
+   não abro PR, não mexo em MCP. Qualquer subida de código ou integração de repositório é
+   **exclusiva do `@devops`**, sem exceção.
+
+## Critério de pronto (DoD)
+
+- [ ] Campos sincronizáveis extraídos da story
+- [ ] Provider identificado e ID externo recuperado (ou item criado)
+- [ ] Divergências detectadas antes de aplicar
+- [ ] Metadados refletidos local→remoto (campos + checklist de ACs quando suportado)
+- [ ] Mapa de IDs (local ↔ externo) persistido em `.nexus/`
+- [ ] Change Log da story atualizado com data e destino da sync
+- [ ] Nenhuma operação de git remoto / PR / MCP executada (delegada ao @devops)
+
+## Falha / recuperação
+
+- **Provider de PM não configurado** → paro e reporto; não invento credenciais nem integração.
+- **Conflito de edição** (story e item remoto mudaram o mesmo campo) → não sobrescrevo cegamente;
+  sinalizo o conflito e peço a decisão antes de aplicar.
+- **A operação exigiu push de código / PR / configuração de MCP** → fora do meu escopo; delego ao
+  @devops.
+- **Falha de autenticação na ferramenta** → reporto o erro com contexto; gestão de credenciais/MCP é
+  do @devops.

package/tasks/pr-automation.md

@@ -0,0 +1,50 @@
+---
+id: pr-automation
+agent: devops
+title: Abrir Pull Request com descrição gerada
+inputs: [story, branch atual, veredito do pre-push-quality-gate]
+outputs: [PR aberto, URL do PR, status checks verificados]
+elicit: true
+modes: [interactive]
+---
+
+# Abrir Pull Request com descrição gerada
+
+**Objetivo:** abrir um PR da branch atual com descrição gerada a partir da story, após o gate verde e a
+confirmação humana — e verificar os status checks. Criação e merge de PR são exclusivos do @devops.
+
+**Pré-condições:**
+- O `pre-push-quality-gate` deu **PASS** e a branch já está no remoto (via `*push`). Se não está
+  publicada, **pare** e rode `*push` antes.
+- A branch atual NÃO é `main`/`master` — PR sai de feature branch. Se estou na branch base, **pare**.
+
+## Passos
+
+1. **Detecte o contexto do repositório** — remoto, branch base (default do repo) e branch atual. Nunca
+   assuma repo fixo.
+2. **Gere a descrição do PR a partir da story** — título no padrão conventional com o id da story;
+   corpo com resumo, ACs atendidos e File List. Sem invenção: tudo rastreia à story/spec.
+3. **Revele o PR proposto.** Mostre título, branch base ← branch atual e o corpo gerado ao usuário.
+4. **[ELICITAÇÃO] Peça o "ok" explícito** para abrir o PR. Criar PR é operação de remoto — exige
+   confirmação humana.
+5. **Abra o PR** (`gh pr create`) contra a branch base detectada, com o título e corpo aprovados.
+6. **Verifique os status checks** (`gh pr view --json statusCheckRollup`). Se algum check vermelho,
+   sinalize — o PR fica aberto mas não recomendo merge sobre check falho.
+7. **Reporte.** Devolvo a URL do PR e o estado dos checks. Merge é operação separada e só com nova
+   confirmação humana — eu nunca faço merge automático.
+
+## Critério de pronto (DoD)
+
+- [ ] Branch publicada no remoto antes de abrir o PR
+- [ ] Descrição gerada a partir da story (título conventional + corpo rastreável)
+- [ ] Confirmação humana obtida antes de `gh pr create`
+- [ ] PR aberto contra a branch base detectada dinamicamente
+- [ ] Status checks verificados e reportados; URL do PR devolvida
+
+## Falha / recuperação
+
+- **Gate não está PASS ou branch não publicada** → não abro PR; volto ao gate/`*push`.
+- **Usuário não confirma** → não crio o PR.
+- **Status check vermelho** → reporto, não recomendo merge; devolvo ao @dev se o check é de qualidade.
+- **PR já existe para a branch** → não duplico; reporto o PR existente e seu estado.
+- **Pedido de merge sem confirmação humana** → recuso; merge é irreversível e pede "ok" explícito.

package/tasks/pre-push-quality-gate.md

@@ -0,0 +1,54 @@
+---
+id: pre-push-quality-gate
+agent: devops
+title: Gate de qualidade pré-push
+inputs: [story, branch atual]
+outputs: [veredito do gate (PASS/FAIL), relatório de gate]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Gate de qualidade pré-push
+
+**Objetivo:** rodar todos os gates de qualidade (lint, typecheck, test, build, revisão automatizada) e
+emitir um veredito objetivo — PASS libera a subida; FAIL devolve ao dono do conserto. Nada vermelho
+chega à porta de saída.
+
+**Pré-condições:**
+- Existe trabalho a subir: branch com commits locais à frente do remoto. Se não há nada novo, **pare**
+  e reporte "nada a subir".
+- A story está em `Ready for Review`/`Done` com gate de QA aprovado. Se a story não passou pelo
+  quality gate do @qa, **pare** e devolva ao @qa antes de tocar nos gates de push.
+
+## Passos
+
+1. **Detecte o contexto do repositório** — remoto, modo (framework-dev vs project-dev) e branch atual.
+   Nunca assuma um repo fixo. Se for greenfield (sem git), **pare** e recomende `*environment-bootstrap`.
+2. **Varra por segredos** no diff a subir (`git diff origin/{branch}...HEAD`): credencial, token, chave
+   ou `.env`. Qualquer match → FAIL imediato, antes de qualquer outro gate. O que vaza pra `main` não volta.
+3. **Rode lint.** Vermelho → registre os erros e marque o gate como FAIL.
+4. **Rode typecheck.** Qualquer erro de tipo → FAIL.
+5. **Rode a suíte de testes.** Um teste falho → FAIL. Suíte verde é pré-requisito da subida.
+6. **Rode build.** Falha de build → FAIL.
+7. **Rode a revisão automatizada de código** na mudança a subir. Classifique os achados:
+   CRITICAL → bloqueia (FAIL); HIGH → sinalizo e recomendo correção; MEDIUM/LOW → documento, não bloqueio.
+8. **Emita o veredito.** PASS somente se: sem segredos, lint limpo, typecheck 0, suíte verde, build ok e
+   sem CRITICAL. Caso contrário FAIL, com o relatório do que reprovou.
+9. **Roteie.** PASS → libera para `*push`/`*create-pr` (com confirmação humana). FAIL → devolvo ao @dev
+   o relatório de correção; se o que falta é o gate de story, devolvo ao @qa. Eu não corrijo o código.
+
+## Critério de pronto (DoD)
+
+- [ ] Varredura de segredos executada — diff limpo de credenciais/`.env`
+- [ ] lint, typecheck, test e build executados, todos verdes
+- [ ] Revisão automatizada rodada e achados classificados (sem CRITICAL aberto)
+- [ ] Veredito explícito emitido (PASS ou FAIL) com relatório
+- [ ] Em FAIL, story devolvida ao dono do conserto (@dev ou @qa) — não subi nada
+
+## Falha / recuperação
+
+- **Qualquer gate vermelho** → veredito FAIL, push bloqueado, relatório devolvido a @dev. Pressa não fura gate.
+- **CRITICAL da revisão** → FAIL; devolvo a @dev e não libero a subida.
+- **Segredo no diff** → FAIL imediato; oriento a remover do histórico antes de qualquer push.
+- **Ferramenta de gate indisponível** (lint/build não configurado) → registro a lacuna e escalo; não
+  declaro PASS sobre um gate que não rodou.

package/tasks/push.md

@@ -0,0 +1,53 @@
+---
+id: push
+agent: devops
+title: Subir ao remoto (git push)
+inputs: [story, branch atual, veredito do pre-push-quality-gate]
+outputs: [commits no remoto, confirmação de push, caminho de rollback]
+elicit: true
+modes: [interactive]
+---
+
+# Subir ao remoto (git push)
+
+**Objetivo:** executar `git push` para o remoto detectado, somente após o gate verde e a confirmação
+humana explícita — com o caminho de reversão claro. Eu sou o único guardião da porta de saída.
+
+**Pré-condições:**
+- O `pre-push-quality-gate` deu **PASS**. Sem PASS, **pare** e rode o gate antes — não subo sobre gate
+  não verificado.
+- Existe branch com commits locais à frente do remoto. Se não há diferença, **pare** e reporte.
+
+## Passos
+
+1. **Detecte o contexto do repositório** — URL do remoto, branch atual e tracking. Nunca assuma repo
+   fixo. Se for greenfield (sem git), **pare** e recomende `*environment-bootstrap`.
+2. **Confirme o gate.** O `pre-push-quality-gate` foi PASS para este HEAD? Se o HEAD mudou desde o gate,
+   re-rode o gate — não subo um estado não auditado.
+3. **Revele o destino.** Mostre ao usuário: branch local → remoto/branch alvo, número de commits, e o
+   resumo do diff (`git log --oneline origin/{branch}..HEAD`).
+4. **[ELICITAÇÃO] Peça o "ok" explícito.** Apresento o resumo do gate (o que passou, o que avisou) e o
+   destino. Só avanço com a confirmação humana — push é irreversível na prática.
+5. **Bloqueie force na branch protegida.** Se o pedido for `--force` sobre `main`/`master`, **recuse**:
+   histórico de branch protegida não se reescreve.
+6. **Execute o push.** `git push` para o remoto/branch confirmado (com `-u` se a branch ainda não tem
+   upstream). Para feature branch sem PR, sinalize que `*create-pr` é o próximo passo.
+7. **Reporte e deixe o rollback claro.** Devolvo o resultado (branch atualizada, hash subido) e o
+   caminho de reversão (ex.: o hash anterior do remoto para um eventual revert). Operação registrada.
+
+## Critério de pronto (DoD)
+
+- [ ] Gate pre-push confirmado como PASS para o HEAD subido
+- [ ] Destino do push revelado (branch, nº de commits, resumo do diff)
+- [ ] Confirmação humana explícita obtida antes de empurrar
+- [ ] Push executado para o remoto detectado dinamicamente
+- [ ] Resultado reportado com caminho de rollback explícito
+
+## Falha / recuperação
+
+- **Gate não está PASS** → não subo; devolvo ao `pre-push-quality-gate`.
+- **Usuário não confirma** → cancelo o push, nada vai ao remoto.
+- **Push rejeitado (non-fast-forward)** → reporto, oriento sincronizar (`git pull --rebase`) e
+  re-rodar o gate; nunca resolvo com `--force` em branch protegida.
+- **Segredo descoberto após o push** → escalo imediato: oriento revogar a credencial e limpar o
+  histórico; segredo vazado não se desfaz só com revert.

package/tasks/qa-browser-console-check.md

@@ -0,0 +1,52 @@
+---
+id: qa-browser-console-check
+agent: qa
+title: Checagem do console do browser
+inputs: [story, app rodando]
+outputs: [evidência de console limpo, entrada na seção QA Results]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Checagem do console do browser
+
+**Objetivo:** confirmar com evidência que a mudança de UI da story não introduz erros, warnings ou
+falhas de rede no console do browser — "funciona na minha tela" não é evidência; console limpo é.
+
+**Pré-condições:**
+- A story tem componente de UI/front. Se a mudança é puramente backend, esta task não se aplica.
+- O app sobe localmente (URL conhecida). Sem app rodando, não há console para inspecionar.
+
+## Passos
+
+1. **Suba e navegue.** Abra o app na rota afetada pela story usando automação de browser. Reproduza o
+   fluxo descrito nas ACs — não só a tela inicial, o caminho inteiro da feature.
+2. **Capture o console.** Colete as mensagens do console durante o fluxo: erros, warnings, exceptions
+   não tratadas. Console limpo significa zero erro e zero warning novo introduzido pela mudança.
+3. **Inspecione a rede.** Verifique as requisições: nenhuma 4xx/5xx inesperada, nenhuma chamada
+   pendente travada, nenhum recurso 404. Falha de rede silenciosa é defeito.
+4. **Tire a evidência.** Screenshot do estado final + o log de console capturado. Sem o artefato, o
+   "limpo" é palavra, não prova — e palavra não passa no meu gate.
+5. **Triagem dos achados.** Erro/exception → FAIL. Warning novo relevante → CONCERNS. Ruído de
+   terceiros pré-existente e não relacionado → registro mas não bloqueio.
+6. **Escreva o resultado** SOMENTE na seção "QA Results": fluxo testado, console (limpo/sujo),
+   achados de rede, com a evidência anexada.
+7. **Roteie.** Erro de console rastreável à mudança → `*create-fix-request` ao @dev com o stack/linha.
+
+## Critério de pronto (DoD)
+
+- [ ] Fluxo das ACs reproduzido no browser, não só a tela inicial
+- [ ] Console capturado: zero erro/warning novo introduzido
+- [ ] Rede inspecionada: sem 4xx/5xx/404 inesperados
+- [ ] Evidência anexada (screenshot + log de console)
+- [ ] Resultado escrito só na seção QA Results e roteado
+
+## Falha / recuperação
+
+- **App não sobe localmente** → HALT, reporto o bloqueio de ambiente; não aprovo UI que não consigo
+  rodar.
+- **Erro de console rastreável à mudança** → FAIL; fix-request ao @dev com stack trace e passo de
+  reprodução.
+- **Falha de rede (5xx) em chamada da feature** → FAIL; aponto o endpoint e devolvo ao @dev.
+- **A causa está em infra/ambiente, não no código** → registro e delego ao @devops; eu aponto, ele
+  opera o ambiente.

package/tasks/qa-create-fix-request.md

@@ -0,0 +1,58 @@
+---
+id: qa-create-fix-request
+agent: qa
+title: Gerar o QA_FIX_REQUEST para o @dev
+inputs: [story, achados do gate]
+outputs: [QA_FIX_REQUEST rastreável, roteamento ao @dev]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Gerar o QA_FIX_REQUEST para o @dev
+
+**Objetivo:** converter os achados de um gate FAIL/CONCERNS num pedido de correção preciso e acionável
+para o @dev — defeito por defeito, com causa, evidência e critério de aceite da correção. Eu aponto;
+o conserto é dele.
+
+**Pré-condições:**
+- Existe um veredito de gate (`*review`/`*gate`) com pelo menos um achado FAIL ou CONCERNS. Sem
+  achado, não há fix-request — não invento defeito.
+- Cada achado já rastreia a uma AC/NFR/CON ou risco real autoevidente. Achado sem âncora não vira
+  pedido de correção.
+
+## Passos
+
+1. **Selecione os achados acionáveis.** Pegue do gate os FAIL e os CONCERNS que pedem correção.
+   Ordene por severidade (CRITICAL → HIGH → MEDIUM → LOW) — o @dev ataca o que mais pesa primeiro.
+2. **Descreva cada defeito com precisão.** Para cada achado: o quê (sintoma), onde (arquivo/linha),
+   por quê (causa-raiz, não sintoma) e a evidência (log/teste/screenshot/stack). Defeito vago é
+   retrabalho garantido.
+3. **Defina o critério de aceite da correção.** Diga o que torna o defeito resolvido: qual teste de
+   regressão precisa existir e passar, qual comportamento deve mudar. O @dev sabe exatamente quando
+   parou.
+4. **Anexe a rastreabilidade.** Ligue cada defeito à AC/NFR/CON que ele viola. Isso prova que não é
+   preferência minha — é o contrato sendo cobrado.
+5. **Escreva o QA_FIX_REQUEST** como artefato da story (na seção QA Results / fix-request), sem tocar
+   em ACs, escopo, status ou Dev Record — esses são intocáveis para mim.
+6. **Roteie ao @dev.** Entrego o fix-request e devolvo a story ao @dev para correção. Eu **não**
+   escrevo o código que conserta — juiz não é réu. Quando ele devolver, eu re-reviso.
+
+## Critério de pronto (DoD)
+
+- [ ] Cada achado acionável virou um item de defeito ordenado por severidade
+- [ ] Cada defeito tem: sintoma, local, causa-raiz e evidência
+- [ ] Cada defeito tem critério de aceite (teste de regressão exigido)
+- [ ] Cada defeito rastreia a uma AC/NFR/CON ou risco real
+- [ ] Escrito só na seção QA Results; story devolvida ao @dev
+- [ ] Eu não escrevi nenhum código de produção
+
+## Falha / recuperação
+
+- **Um achado não rastreia a contrato nem risco real** → não entra no fix-request; eu não bloqueio por
+  preferência estética.
+- **O @dev devolve a correção** → re-reviso (encadeio `*false-positive-check` e `*evidence-check`)
+  antes de reabrir o gate. Não dou PASS sem verificar a correção.
+- **A correção exige escopo fora do @dev** (schema, infra, UI) → roteio o item ao dono certo
+  (@data-engineer, @devops, @ux-design-expert) em vez de empilhar tudo no @dev.
+- **Tentei reverter ao @dev mais de uma vez sem convergir** → escalo ao @nexus-master em vez de
+  iterar no escuro indefinidamente.

package/tasks/qa-evidence-requirements.md

@@ -0,0 +1,55 @@
+---
+id: qa-evidence-requirements
+agent: qa
+title: Verificação de QA baseada em evidência
+inputs: [story]
+outputs: [veredito de suficiência de evidência, entrada na seção QA Results]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Verificação de QA baseada em evidência
+
+**Objetivo:** confirmar que toda afirmação de "pronto/funciona" na story está sustentada por evidência
+verificável — teste verde, log, screenshot, console limpo — e não por palavra. Sem evidência, não
+aconteceu.
+
+**Pré-condições:**
+- A story está em review (status pós-implementação). Se ainda está em Draft/InProgress, não há o que
+  auditar.
+- A story tem ACs e seção de Testing. Sem contrato, não há padrão de evidência a exigir.
+
+## Passos
+
+1. **Liste as afirmações.** Extraia da story tudo que se declara feito: cada AC marcada, cada item de
+   Completion Notes, cada "corrigido/validado". Cada uma é uma alegação que precisa de prova.
+2. **Case alegação ↔ evidência.** Para cada afirmação, localize a prova: o teste que a cobre (e está
+   verde), o log, o screenshot, a saída de console. Alegação sem prova é buraco nomeado, não fechado.
+3. **Verifique a qualidade da prova.** O teste de fato exercita o AC (não é asserção vazia)? O
+   screenshot mostra o estado certo? O log é da execução real, não copiado? Prova fraca = sem prova.
+4. **Confirme a rastreabilidade.** Toda AC mapeia a pelo menos um teste em Given-When-Then. AC órfã
+   entra como gap com severidade — não fecho os olhos para o que não foi coberto.
+5. **Pontue a suficiência.** Cobertura completa com prova forte → PASS. Lacunas em área de baixo risco
+   → CONCERNS documentado. Lacuna em caminho crítico/dado sensível → FAIL.
+6. **Escreva o resultado** SOMENTE na seção "QA Results": tabela alegação→evidência, gaps com
+   severidade, e o veredito de suficiência.
+7. **Roteie.** Gaps que bloqueiam → `*create-fix-request` ao @dev pedindo a evidência ausente
+   (teste, log, screenshot).
+
+## Critério de pronto (DoD)
+
+- [ ] Todas as afirmações de "pronto/funciona" listadas
+- [ ] Cada alegação casada com evidência verificável (ou marcada como gap)
+- [ ] Qualidade da prova verificada (teste real, não asserção vazia)
+- [ ] Cada AC rastreada a teste Given-When-Then; órfãs registradas
+- [ ] Veredito de suficiência escrito só na seção QA Results e roteado
+
+## Falha / recuperação
+
+- **Afirmação de "funciona" sem nenhuma evidência** → CONCERNS no mínimo; FAIL se for caminho crítico.
+  Devolvo pedindo a prova.
+- **Teste existe mas é asserção vazia / não exercita o AC** → trato como sem prova; fix-request ao @dev.
+- **AC marcada feita mas sem teste** → gap de rastreabilidade registrado no gate, severidade conforme
+  risco.
+- **A evidência exige rodar o app/browser** → encadeio `*console-check` ou peço ao @dev o artefato;
+  não infiro o resultado.

package/tasks/qa-false-positive-detection.md

@@ -0,0 +1,55 @@
+---
+id: qa-false-positive-detection
+agent: qa
+title: Detecção de falso-positivo em correções
+inputs: [story, diff, teste de regressão]
+outputs: [veredito de autenticidade da correção, entrada na seção QA Results]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Detecção de falso-positivo em correções
+
+**Objetivo:** verificar que um "bug corrigido" foi de fato corrigido na causa-raiz — com um teste que
+reproduzia o bug original e agora guarda a porta — e não apenas mascarado no sintoma.
+
+**Pré-condições:**
+- A story/fix declara um defeito como corrigido. Sem afirmação de correção, esta task não se aplica.
+- Existe um `diff` da correção e (idealmente) o teste de regressão. Se o teste não existe, esse já é o
+  primeiro sinal de falso-positivo.
+
+## Passos
+
+1. **Reconstrua o bug original.** A partir da story/fix-request, identifique o sintoma, o input que o
+   dispara e o comportamento esperado. Se não dá para reconstruir, o defeito nunca foi entendido —
+   suspeito.
+2. **Exija o teste que reproduz.** Confirme que existe um teste que **falharia** no código antigo e
+   **passa** no novo. Sem esse teste, a correção é hipótese, não fato → CONCERNS no mínimo.
+3. **Verifique causa, não sintoma.** Leia o diff: a mudança ataca a raiz (validação, lógica, estado) ou
+   só silencia o efeito (try/catch vazio, guarda no ponto errado, valor mágico)? Mascaramento → FAIL.
+4. **Cace o efeito colateral.** A correção quebra algum consumidor ou abre um caminho de erro novo?
+   Caminho feliz consertado mas borda quebrada continua sendo defeito.
+5. **Confirme a regressão na suíte.** Rode os testes da área: o de regressão verde E os antigos
+   continuam verdes. Verde no novo + vermelho no antigo = correção que quebrou outra coisa.
+6. **Emita o veredito** SOMENTE na seção "QA Results": correção autêntica (PASS), suspeita
+   (CONCERNS, com o que falta) ou falso-positivo (FAIL, com a evidência do mascaramento).
+7. **Roteie.** FAIL/CONCERNS → `*create-fix-request` ao @dev, nomeando o teste de regressão ausente ou
+   a causa não atacada.
+
+## Critério de pronto (DoD)
+
+- [ ] Bug original reconstruído (sintoma + input + esperado)
+- [ ] Teste de regressão confirmado: falha no antigo, passa no novo
+- [ ] Diff ataca a causa-raiz, não o sintoma
+- [ ] Suíte da área inteira verde (sem regressão colateral)
+- [ ] Veredito escrito só na seção QA Results e roteado
+
+## Falha / recuperação
+
+- **Não existe teste que reproduza o bug** → CONCERNS/FAIL: devolvo ao @dev pedindo o teste de
+  regressão. Sem ele, não há prova de correção.
+- **A correção mascara o sintoma** (catch vazio, flag, valor mágico) → FAIL com a linha apontada;
+  fix-request ao @dev.
+- **A correção introduziu regressão em outro teste** → FAIL; aponto o teste quebrado e devolvo.
+- **Não consigo reconstruir o bug a partir da story** → registro a lacuna e devolvo ao @sm/@po; não
+  invento o defeito que faltou descrever.

package/tasks/qa-fix-issues.md

@@ -0,0 +1,55 @@
+---
+id: qa-fix-issues
+agent: dev
+title: Corrigir issues do QA_FIX_REQUEST.md (workflow de 8 fases)
+inputs: [QA_FIX_REQUEST.md, story]
+outputs: [código corrigido, testes, QA_FIX_RESPONSE.md, File List atualizada]
+elicit: false
+modes: [yolo, interactive]
+---
+
+# Corrigir issues do QA_FIX_REQUEST.md (workflow de 8 fases)
+
+**Objetivo:** executar o ciclo estruturado de correção de um `QA_FIX_REQUEST.md` — da triagem à
+resposta — fechando cada issue listada com correção testada e rastreável.
+
+**Pré-condições:**
+- Existe um `QA_FIX_REQUEST.md` com issues numeradas, cada uma com severidade e AC/local afetado.
+  Sem esse arquivo, **pare** — esta task opera sobre ele.
+- A story de origem está acessível (para rastrear cada issue ao seu AC). Se faltar, devolvo ao @qa.
+
+## Passos
+
+1. **Fase 1 — Triagem.** Leio todas as issues do `QA_FIX_REQUEST.md`, classifico por severidade
+   (CRITICAL/HIGH/MEDIUM/LOW) e separo o que é minha lane (código/teste) do que é AC/escopo (devolvo
+   ao @sm/@po, não corrijo).
+2. **Fase 2 — Plano de ataque.** Ordeno as issues: bloqueadores primeiro; agrupo as que tocam os
+   mesmos arquivos para evitar idas e vindas. Sem super-engenharia: o plano é uma lista, não um doc.
+3. **Fase 3 — Reprodução.** Para cada issue, reproduzo o problema (teste que falha / passo que
+   quebra) antes de corrigir. Não corrijo o que não consigo reproduzir — peço evidência ao @qa.
+4. **Fase 4 — Correção.** Aplico a correção mínima por issue, reusando o que já existe antes de criar.
+5. **Fase 5 — Teste.** Escrevo/ajusto o teste que prova que a issue foi fechada (inclui o caso de
+   borda que a quebrou). Issue sem teste verde não está fechada.
+6. **Fase 6 — Regressão.** Rodo lint + typecheck + toda a suíte. Corrigir uma issue não pode abrir
+   outra. Vermelho não fecha o ciclo.
+7. **Fase 7 — Resposta.** Escrevo `QA_FIX_RESPONSE.md` mapeando cada issue → correção aplicada →
+   teste que a prova → arquivos tocados. Atualizo a File List da story.
+8. **Fase 8 — Roteamento.** Commit local (conventional commit citando o id da story). **Não** dou
+   `git push` — delego ao @devops. Roteio o `QA_FIX_RESPONSE.md` de volta ao @qa para re-review.
+
+## Critério de pronto (DoD)
+
+- [ ] Toda issue da minha lane no `QA_FIX_REQUEST.md` foi reproduzida, corrigida e coberta por teste
+- [ ] Issues de AC/escopo foram devolvidas ao @sm/@po, não "consertadas" por mim
+- [ ] Regressão completa verde: lint limpo, typecheck 0, suíte passando
+- [ ] `QA_FIX_RESPONSE.md` escrito com o mapa issue → fix → teste → arquivos
+- [ ] File List atualizada; commit local feito, sem `git push` (delegado ao @devops)
+
+## Falha / recuperação
+
+- **Uma issue não reproduz** → não corrijo às cegas; peço ao @qa o passo/evidência de reprodução.
+- **Uma issue é de AC/escopo, não de código** → devolvo ao @sm/@po; registro no `QA_FIX_RESPONSE.md`
+  como fora de escopo de correção de código.
+- **A correção abre regressão** → paro, registro e resolvo antes de fechar o ciclo.
+- **3 tentativas falhas na mesma issue** → HALT, marco a issue como bloqueada no `QA_FIX_RESPONSE.md`
+  e reporto; não empurro com gambiarra.

package/tasks/qa-gate.md

@@ -0,0 +1,53 @@
+---
+id: qa-gate
+agent: qa
+title: Emitir a decisão de quality gate
+inputs: [story, achados do review]
+outputs: [decisão PASS/CONCERNS/FAIL/WAIVED na seção "QA Results", roteamento]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Emitir a decisão de quality gate
+
+**Objetivo:** consolidar os achados do review numa decisão de gate única e fundamentada —
+PASS / CONCERNS / FAIL / WAIVED — rastreável a risco real, escrita só na seção "QA Results".
+
+**Pré-condições:**
+- O review já produziu achados (risco, scan, segurança, NFR, rastreabilidade, evidência). Sem
+  achados, **pare**: gate sem análise é carimbo, não veredito.
+- A story está em `Ready for Review` ou `InReview`. Não emito gate sobre story em `Draft`.
+
+## Passos
+
+1. **Reúno os achados** de cada eixo do review e classifico por severidade (CRITICAL/HIGH/MEDIUM/LOW),
+   cada um rastreado a uma AC, NFR ou CON. Achado sem rastro não entra na decisão.
+2. **Aplico a régua de decisão:**
+   - **FAIL** — há CRITICAL/HIGH aberto, AC não atendida, ou ausência de evidência em ponto de risco.
+   - **CONCERNS** — sem bloqueador, mas há dívida registrada (MEDIUM/LOW, gap não-crítico) que o time
+     deve conhecer; progresso não é barrado por preferência estética.
+   - **PASS** — todas as ACs atendidas com teste verde, sem CRITICAL/HIGH, evidência presente.
+   - **WAIVED** — risco conhecido e explicitamente aceito pelo dono (@pm/@po), com justificativa
+     registrada. Eu não dou waiver sozinha — registro o aceite.
+3. **Fundamento a decisão.** Para cada item que pesa no veredito, escrevo o porquê e o rastro à AC/
+   NFR/CON. Advisory, nunca arbitrário: bloqueio só com motivo rastreável.
+4. **Escrevo a seção "QA Results"** da story com o veredito, os achados e a fundamentação. NÃO toco em
+   Status, ACs, Tasks, Dev Notes ou Change Log — alterar o contrato que julgo é conflito de interesse.
+5. **Roteio.** FAIL/CONCERNS → fix-request (`qa-create-fix-request`) ao @dev. PASS e pronto pra subir
+   → @devops. Eu nunca subo nada eu mesma.
+
+## Critério de pronto (DoD)
+
+- [ ] Cada achado rastreado a AC/NFR/CON e classificado por severidade
+- [ ] Veredito único emitido pela régua (PASS/CONCERNS/FAIL/WAIVED)
+- [ ] Fundamentação escrita para cada item que pesou na decisão
+- [ ] Apenas a seção "QA Results" foi escrita
+- [ ] WAIVED, se houver, registra aceite explícito do dono — não decisão minha
+- [ ] Saída roteada (@dev ou @devops)
+
+## Falha / recuperação
+
+- **Achado sem rastro a AC/NFR/CON** → descarto do veredito; não invento critério avulso.
+- **Pressão para PASS sem evidência** → recuso; CONCERNS no mínimo. Nunca aprovo no escuro.
+- **Pedido de WAIVED sem dono identificado** → HALT até o aceite explícito do @pm/@po.
+- **Veredito exige correção** → delego ao @dev via fix-request; não comito nem corrijo código.

package/tasks/qa-migration-validation.md

@@ -0,0 +1,58 @@
+---
+id: qa-migration-validation
+agent: qa
+title: Validação de migrations de schema
+inputs: [story, arquivos de migration]
+outputs: [veredito de segurança da migration, entrada na seção QA Results]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Validação de migrations de schema
+
+**Objetivo:** assegurar que uma migration de schema é reversível, não-destrutiva por acidente e segura
+para rodar em produção — antes que ela corrompa dado ou trave a aplicação.
+
+**Pré-condições:**
+- A story toca o schema e existe pelo menos um arquivo de migration. Sem migration, esta task não se
+  aplica.
+- Eu valido a segurança do scan; o desenho fino de DDL e otimização de query é do @data-engineer —
+  delego o que passar do meu escopo de gate.
+
+## Passos
+
+1. **Identifique o tipo de mudança.** Aditiva (coluna/tabela nova) é baixo risco; destrutiva (drop,
+   rename, mudança de tipo, NOT NULL em coluna populada) é alto risco e recebe mergulho profundo.
+2. **Verifique a reversibilidade.** Existe `down`/rollback que desfaz a mudança sem perder dado? Drop
+   sem caminho de volta é FAIL salvo justificativa explícita na story.
+3. **Cace destruição implícita.** `DROP COLUMN`, `TRUNCATE`, mudança de tipo que trunca, `NOT NULL`
+   sem default em tabela com linhas — cada um é potencial perda de dado. Marque com evidência.
+4. **Avalie o impacto de lock/downtime.** A migration trava a tabela por quanto tempo? Em tabela grande,
+   `ALTER` síncrono pode derrubar a app. Sinalize para estratégia online se o risco apontar.
+5. **Confirme ordem e idempotência.** A migration roda limpa em base vazia E em base existente? É
+   idempotente ou falha se rodar duas vezes? Numeração/timestamp em ordem correta.
+6. **Rastreie ao contrato.** A mudança de schema corresponde a uma AC/spec? Schema inventado fora da
+   story viola No Invention → bloqueio.
+7. **Emita o veredito** SOMENTE na seção "QA Results": tipo, reversibilidade, riscos destrutivos,
+   impacto de lock, e PASS/CONCERNS/FAIL com evidência.
+8. **Roteie.** Risco destrutivo ou irreversível → `*create-fix-request` ao @dev e delego validação fina
+   ao @data-engineer. A subida (aplicar em prod) é sempre do @devops — eu nunca aplico migration.
+
+## Critério de pronto (DoD)
+
+- [ ] Tipo de mudança classificado (aditiva vs destrutiva)
+- [ ] Reversibilidade verificada (rollback existe e funciona)
+- [ ] Riscos destrutivos e de lock/downtime sinalizados com evidência
+- [ ] Idempotência e ordem confirmadas
+- [ ] Mudança rastreia a uma AC/spec
+- [ ] Veredito escrito só na seção QA Results e roteado
+
+## Falha / recuperação
+
+- **Migration destrutiva sem rollback** → FAIL; fix-request ao @dev e validação fina ao
+  @data-engineer.
+- **Risco de lock/downtime em tabela grande** → CONCERNS com recomendação de migration online; delego
+  a estratégia ao @data-engineer.
+- **Schema não rastreia a nenhuma AC/spec** → bloqueio por No Invention; devolvo ao @sm/@po.
+- **Preciso aplicar a migration para validar comportamento** → eu não aplico em prod; peço ambiente de
+  validação e delego a aplicação ao @devops.

package/tasks/qa-nfr-assess.md

@@ -0,0 +1,45 @@
+---
+id: qa-nfr-assess
+agent: qa
+title: Validar requisitos não-funcionais da story
+inputs: [story]
+outputs: [avaliação de NFRs (perf, segurança, confiabilidade, manutenibilidade) com veredito por eixo]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Validar requisitos não-funcionais da story
+
+**Objetivo:** verificar que a story atende os NFRs que importam para seu risco — performance,
+segurança, confiabilidade, manutenibilidade — com evidência por eixo, não com afirmação.
+
+**Pré-condições:**
+- A story existe e o risco já foi perfilado (`qa-risk-profile`), para calibrar profundidade.
+- Existem NFRs/CONs rastreáveis (na story, na spec ou no padrão do projeto). Sem alvo, registro a
+  ausência como gap — não invento o número.
+
+## Passos
+
+1. **Seleciono os eixos relevantes** pelo perfil de risco. Caminho crítico exige perf e
+   confiabilidade; dado sensível exige segurança. Não avalio eixo irrelevante só para encher.
+2. **Para cada eixo, defino o alvo** rastreável (ex.: latência p95 < X, sem secret em log, retry em
+   falha transitória). Alvo vem da story/spec/CON; se ausente, registro gap.
+3. **Coleto evidência** contra o alvo: resultado de teste de carga, scan de segurança, log de falha
+   injetada, métrica. Evidência ou não aconteceu — afirmação de "é rápido" não vale.
+4. **Emito veredito por eixo:** PASS (alvo atingido com evidência), CONCERNS (dívida sem bloqueio),
+   FAIL (alvo violado ou sem evidência em ponto de risco).
+5. **Consolido** os vereditos como insumo para `qa-gate`, cada um rastreado ao NFR/CON correspondente.
+
+## Critério de pronto (DoD)
+
+- [ ] Eixos de NFR selecionados pelo perfil de risco, não por checklist cego
+- [ ] Cada eixo tem alvo rastreável (story/spec/CON) ou gap registrado
+- [ ] Cada veredito sustentado por evidência concreta
+- [ ] Vereditos consolidados e rastreados para o gate
+
+## Falha / recuperação
+
+- **Eixo de risco sem alvo definido** → registro gap e levo ao gate como CONCERNS; não estipulo o
+  número eu mesma.
+- **Sem evidência para um eixo crítico** → FAIL nesse eixo; não presumo conformidade.
+- **Correção de NFR exige código/infra** → delego ao @dev (código) ou @devops (infra) via fix-request.