Verificar prontidão
Invoque como $check-readiness diff, $check-readiness pr <URL>, $check-readiness release ou $check-readiness full.
Apenas leitura por padrão. Relate problemas e resoluções concretas. Edite apenas quando o usuário explicitamente solicitar corrigir ou aplicar descobertas; então, verifique o comportamento afetado.
1. Escolher alvo
| Modo | Alvo | Critério de conclusão |
|---|---|---|
diff | Mudanças staged, unstaged e untracked relevantes do repositório atual, além de chamadores e testes afetados. Padrão quando mudanças são o alvo. | Cada comportamento alterado e limite afetado contabilizado. |
pr <URL> | Diff da PR vinculada, base, conversa, verificações e contexto afetado. | Cada comportamento alterado contabilizado; evidências locais ou remotas faltantes nomeadas. |
release | Repositório atual e destino de deployment nomeado, ou o destino encontrado na configuração do repositório. | Cada fluxo crítico e dependência de release tem um estado. |
full | Repositório atual em todas as superfícies de backend e frontend aplicáveis. | Cada rota principal, operação, limite de confiança, armazenamento de dados e caminho de ciclo de vida inventariado e avaliado. |
Use o modo que o usuário nomear. Se nenhum for nomeado, infira a partir de uma URL de PR, mudanças atuais ou um release declarado; caso contrário, use full. Registre o alvo exato, revisão ou diff, ambiente e caminhos de validação disponíveis antes de verificar. Se uma URL de PR não puder ser acessada, relate o que está bloqueado; não substitua por um diff local não relacionado.
Severidade
Cada FALHA é bloqueante ou consultiva. Bloqueante: segurança, authn/authz, perda ou corrupção de dados, fluxo crítico quebrado, manipulação de pagamento ou webhook não verificada, segredos vazados, build ou testes falhando. Todo o resto é consultivo e não impede por si só PRONTO. Cada skill de prontidão lista suas próprias áreas bloqueantes.
Profundidade por modo
diff e pr: verifique apenas o comportamento que a mudança toca; marque o resto como N/A (não tocado) em uma linha, não por verificação. Verificações de gate de release (Lighthouse, testes de smoke em ambiente deployed, previews de compartilhamento) se aplicam apenas a release e full, a menos que a mudança os afete.
2. Coletar evidências
Para diff, inspecione git status --short --branch, diffs staged e unstaged, e arquivos untracked relevantes. Para pr, leia a PR vinculada e seu diff, verificações e discussão; use um checkout local correspondente para testes apenas quando sua revisão for verificada. Para release e full, mapeie a aplicação no escopo antes de testar. Rastreie chamadores, efeitos de dados, configuração, testes e dependências de deployment para cada área afetada.
Execute backend-readiness quando código ou comportamento de backend estiver no escopo. Execute frontend-readiness quando código ou comportamento de frontend estiver no escopo. Passe o modo e alvo selecionados para cada um; se ambos se aplicarem, combine suas descobertas. Para uma revisão de mudança, aplique verificações ao comportamento afetado. Para um release, aplique verificações nos fluxos críticos e no ambiente alvo. Para full, avalie todas as verificações aplicáveis no repositório. Marque cada verificação aplicável como PASS, FAIL, BLOCKED ou N/A; anexe evidência atual para cada PASS e um motivo para cada N/A.
Use fonte, testes automatizados, runtime local, sandbox do provedor e ambiente deployed como camadas de evidência distintas. Um build prova um build. Registre credenciais, infraestrutura ou ambientes indisponíveis como BLOCKED, com a prova exata ainda necessária. Execute verificações focadas que possam verificar o alvo; não reivindique comportamento de runtime ou release apenas a partir da fonte.
Complete quando as verificações aplicáveis tiverem estados, falhas tiverem causa e resolução, e cada afirmação de prontidão corresponder à sua camada de evidência.
3. Relatar e agir
Relate modo e alvo, depois descobertas ordenadas por segurança, perda de dados, correção e impacto no usuário. Cada descoberta nomeia localização ou fluxo, evidência, consequência e a menor resolução concreta. Inclua verificações executadas com resultados exatos, mais itens bloqueados ou não verificados. Termine com PRONTO, NÃO PRONTO ou NÃO VERIFICADO para o alvo escolhido: PRONTO requer nenhuma falha bloqueante conhecida e evidência para seu gate aplicável; NÃO VERIFICADO significa que evidência faltante impede essa afirmação.
Use este template:
Modo / alvo: <modo, revisão ou diff, ambiente>
Descobertas
| Severidade | Localização ou fluxo | Evidência | Consequência | Resolução |
Verificações executadas
| Comando ou teste | Resultado |
Bloqueado / não verificado
- <item>: <prova ainda necessária>
Veredito: PRONTO | NÃO PRONTO | NÃO VERIFICADO
Mantenha execuções de revisão somente leitura. Se o usuário solicitar corrigir descobertas, aplique as correções solicitadas no código afetado, execute verificação focada e relate riscos restantes. Não infira autorização de edição a partir de uma solicitação para verificar prontidão.
Complete quando o relatório distinguir comportamento verificado de lacunas, ou correções solicitadas tiverem sido aplicadas e verificadas.