Developer Quality

1) Objetivo e Escopo

Garantir que mudanças em MCP server, indexer, infra e docs técnicas passem por validação proporcional ao risco com feedback rápido e reproduzível.

Trigger policy

• •Disparar quando o pedido mencionar testes, cobertura, regressão, lint, typecheck, pre-commit, qualidade de PR, estabilidade de pipeline ou contrato entre módulos.
• •Disparar quando houver suspeita de quebra silenciosa ou necessidade de ampliar matriz de validação.
• •Não disparar para implementar lógica de negócio principal sem foco de validação (delegar para skill de domínio: developer-mcp-server, developer-indexer, developer-vector-db, developer-infra, developer-docs).

2) Entradas esperadas

• •Escopo da mudança e risco esperado (baixo/médio/alto).
• •Componentes afetados (MCP server, indexer, Qdrant schema, infra).
• •Estado atual de testes/lint/typecheck e lacunas conhecidas.
• •Critério de aceite mínimo (ex.: sem regressão, contrato preservado, cobertura mínima).

3) Workflow (Discovery -> Plan -> Implement -> Validate -> Deliver)

1. •Discovery
   • •Mapear tipos de teste existentes e pontos sem cobertura.
   • •Identificar contratos críticos que devem ser protegidos.
   • •Consultar references/checklist.md para matriz mínima por risco.
2. •Plan
   • •Definir plano de validação incremental (rápido -> profundo).
   • •Priorizar testes próximos da mudança antes de suites globais custosas.
3. •Implement
   • •Criar/ajustar testes unitários, integração, e2e e de contrato quando necessário.
   • •Ajustar lint/typecheck/pre-commit de forma objetiva e sem ruído.
4. •Validate
   • •Executar comandos planejados e registrar resultado de cada etapa.
   • •Confirmar ausência de regressão funcional e de compatibilidade.
5. •Deliver
   • •Entregar plano executado, artefatos de validação e próximos passos para cobertura remanescente.

4) DoD

• •Mudança crítica tem teste automatizado cobrindo caminho feliz e falhas relevantes.
• •Contratos entre módulos sensíveis têm validação explícita.
• •Lint e typecheck passam sem ignorar erros novos.
• •Regressões conhecidas estão bloqueadas por teste ou documentadas com plano de mitigação.
• •Comandos de validação são reproduzíveis no ambiente local/CI.

5) Guardrails

• •Não mascarar falhas com skips indiscriminados ou mocks irreais.
• •Não inflar cobertura com testes sem assert relevante.
• •Não quebrar suites existentes para aprovar mudança pontual.
• •Não misturar refatoração ampla com correção de teste sem necessidade.
• •Não criar scripts/ nesta skill sem necessidade determinística comprovada.

6) Convenções de saída

• •Sempre devolver: (1) plano de validação, (2) mudanças de teste/lint/typecheck, (3) comandos e resultados, (4) risco residual.
• •Sempre indicar o que foi validado localmente e o que depende de CI.

7) Exemplos de uso (prompts)

• •"Crie uma matriz mínima de testes para a nova tool MCP e evite regressões de contrato."
• •"Ajuste lint e typecheck do módulo alterado sem mexer em áreas não relacionadas."
• •"Adicione testes de integração para indexação incremental e operação no Qdrant."
• •"Defina gates de qualidade para PR com foco em feedback rápido e confiável."
• •"Padronize critérios globais de qualidade do CI e explicite quando acionar developer-tester para bugfix e regressão localizada."

8) Anti-exemplos (quando não usar)

• •"Implementar endpoint/tool nova no NestJS" -> usar developer-mcp-server.
• •"Refatorar algoritmo de chunking" -> usar developer-indexer.
• •"Mudar configuração da collection Qdrant" -> usar developer-vector-db.
• •"Escrever guia de onboarding técnico" -> usar developer-docs.
• •"Reproduzir bug específico e criar teste antes/depois" -> usar developer-tester.
• •"Executar smoke e2e de uma mudança pontual" -> usar developer-tester.