Quality Gate é o critério obrigatório para concluir e fechar qualquer task no Nébula. Nenhuma task finaliza com "check" sem atestar evidências verídicas nestes domínios de validação.
Fase: 7 — Governança Contínua (Check)
Pré-requisito: Docs/tasks.md ativa precisando de aprovação.
Template oficial: Quality/gate.md
Artefato alvo da edição diária: Docs/tasks.md (no bloco "Quality Gate" respectivo da task).
Quando aplicar
- Ao finalizar uma sub-tarefa importante de código.
- Imediatamente antes de marcar a Task como
(x) concluídano painel. - Antes da geração do Hash Commit declarativo de final de ciclo.
Estrutura — Gate Oficial
O template raiz do Quality/gate.md exige formalmente as seguintes 3 seções. Abaixo o seu mapeamento exato.
1. Critérios obrigatórios
O checklist inalienável para permitir fechar uma task:
1. Lint aprovado.
2. Typecheck aprovado (quando aplicável).
3. Build aprovado (quando aplicável).
4. Testes realistas executados conforme Quality/realistic-tests.md.
5. Sem uso de mock/stub/placeholder (fora de exceção formal registrada no control.md).
6. Impacto de API validado com Curl e scripts reproduzíveis (quando aplicável).
7. Impacto de interface validado com e2e (quando aplicável).
8. Impacto mobile validado em BrowserStack (ou alternativa) e hardware físico (fluxo crítico).
9. Dependências e lockfile consistentes.
10. Evidências obrigatoriamente registradas dentro do bloco de metadados da Task.2. Evidências mínimas na task
As evidências tangíveis que Dev/AIs copiam e colam em "Docs/tasks.md":
- Resultado do lint/typecheck/build [ex: output do terminal verde].
- Resultado de testes explicitando o ambiente onde rodaram.
- Comandos Curl executados guardados.
- Relatório e2e se for uma modificação de UI.
- Identificador de dispositivo usado para validações físicas Mobile.
- O hash do commit que selou a validação técnica.
- A lista restrita de arquivos tocados.3. Regra de bloqueio
O vetor de decisão absoluto:
Se qualquer um dos 10 critérios obrigatórios aplicáveis ao contexto não puder ser provado, a task TEM DE PERMANECER ABERTA EM ANDAMENTO.
Não existe meia aprovação.Prompt para validar com agente
Atue como QualityAgent.
Objetivo: aplicar quality gate na [TASK-XXX].
Carregue contexto base:
- Docs/tasks.md (bloco respectivo da tarefa alvo)
- Quality/gate.md
- O código comitado
Retorne preenchidas as seções idênticas ao Gate oficial:
1) Dispare script de lint/typecheck. Informe os erros ou aprovação.
2) Acuse a ausência de Evidências Mínimas mapeadas (ex: se falta comando Curl pra API).
3) Ateste a Regra de Bloqueio (Passou fechada ou Manteve aberta falha).Definição de pronto
O ritual de Gate está formalmente cumprido diáriamente ao se verificar que:
- O Bloco
Quality Gate: [aprovado / reprovado]da tarefa corrente no arquivoDocs/tasks.mdfoi preenchido. - Nenhuma menção a "Mocks" subiu pra master na Seção 1, intem 5 sem autorização de exceção formal mapeada em Control.
- O Lockfile manteve integridade de versão nas Seções 1, item 9.
Sem Quality Gate preenchido estritamente, fecha-se task com falha não percebida de API ou quebra de Build. "Esquecer" o check do gate equivale a não documentar a task.
Erros comuns
| Erro | Correção |
|---|---|
| Aprovar Gate "no visual" da IDE | Gate exige Evidência mapeada no bloco da Tarefa (como um log ou resposta cURL guardado). Um test falso-positivo no olhômetro ignora infraestrutura real. |
| Colar evidência frágil (Mocks não declarados) | O framework abomina stubs disfarçados. Não aprovamos o Gate se o login usou "admin/admin" local hardcoded, ao invés da DB Real listada em Arquitetura. |
| Fundir PR (Commit final) estando o Gate aberto | Task sem hash oficial atestando as evidências e o "Lint Pass" ainda não está pronta pra pipeline, logo o Control bloqueia Sprints futuras. |