zehuichan/vibe-harness

Revisando uma alteração

Este skill é orientação, não uma checklist completa. Verifique e obtenha a base ao vivo exata e o head da alteração, depois liste os caminhos alterados com o commands.change-scope do perfil antes de ler o diff e código circundante suficiente para entender o design. Reestabeleça a base após um retarget ou merge. Priorize correção, ciclo de vida, segurança e comportamento obrigatório quebrado sobre estilo; uma revisão curta com um bloqueador fundamentado é melhor que uma lista de minúcias.

Leia os requisitos antes de julgar o diff. Mapeie os caminhos alterados para as fontes abaixo, abra cada página proprietária e só então leia o diff em relação a esses requisitos. Julgar um diff de memória contra as regras é como uma violação passa pela revisão.

Fontes de verdade

• AGENTS.md na raiz e em cada subárvore tocada: ordens permanentes.
• .agents/project-profile.md: comandos, superfícies habilitadas, evidências por superfície e regras específicas do projeto.
• docs/defensive-patterns/: regras aplicadas na revisão, uma página por família de artefatos; leia cada página que o diff tocar.
• docs/AGENTS.md e docs-standard: posicionamento e disciplina da documentação.
• prose-standard: cobertura necessária e julgamento editorial para comentários, documentação, prompts e strings visíveis.
• error-handling: classificação de falhas, propriedade, contenção, garantias e relatórios.
• lifecycle-review: estado singleton, efeitos não revertidos e ordenação de limpeza em plugins, serviços e componentes.
• test-reliability: isolamento e prova de regressão para testes que gerenciam recursos, assíncronos ou instáveis.
• .agents/notes/: justificativa de design. Trate discordância com uma Nota do Agente como uma discussão de design, não um veto automático.
• Quando o perfil habilita surfaces.ui, os skills ui-ux-review e responsive-ui.

Requisitos bloqueantes

1. Novo texto recebe revisão semântica. Use prose-standard em cada passagem Markdown adicionada ou alterada, doc de API, comentário, prompt, descrição, diagnóstico e string visível. Verificações automatizadas não estabelecem precisão, posicionamento ou cobertura.
2. Docs correspondem ao código. Configuração, padrões, erros, campos de fiação, eventos e comportamento público atualizam o README proprietário e os docs de API no mesmo diff. Sinalize narração de implementação, walkthroughs de teste, histórico de revisão e justificativa duplicada.
3. Propriedade e limpeza. Para código de plugin, serviço ou componente com ciclo de vida, aplique lifecycle-review ao comportamento alterado e aos consumidores afetados. Cada novo registro prova seu descarte.
4. Evidência necessária existe. Verifique se o autor executou as verificações relevantes para o diff (veja pre-push-checks) e que o CI cobre o restante; revise as lacunas semânticas que nenhum dos dois pode detectar.
5. Texto de UI localizado. Quando o perfil habilita surfaces.localized-ui, rejeite texto do produto embutido em marcação, templates, retornos de helper, atributos de acessibilidade ou padrões de componente; exija o mecanismo de localidade e evidência em cada localidade afetada. Dados de usuário, modelo e fiação permanecem verbatim.
6. Mudanças que quebram compatibilidade são registradas. Quando o perfil habilita surfaces.public-api, uma quebra externamente perceptível carrega um guia de atualização no mesmo diff (veja upgrade-guide).

Verificações manuais

• Contratos de intenção e interface: rastreie ambos os lados de cada interface alterada. Confirme que a implementação corresponde à descrição e qualquer Nota do Agente, incluindo erros, cancelamento, propriedade e descarte.
• Tratamento de erros: rejeite catch-and-continue a menos que o proprietário do estado estabeleça que as pré-condições do trabalho posterior são válidas.
• Ciclo de vida e concorrência: para configuração assíncrona, callbacks, processos ou desmontagem, verifique condições de corrida antes da publicação, cancelamento durante awaits, relato de erro independente, contenção de callback, propriedade antes de reentrada, limpeza completa de desanexação e descarte quiescente.
• Adequação de capacidade e consumidor: rastreie cada consumidor atual, depois sinalize comportamento específico do consumidor vazando para uma interface compartilhada. Sinalize também o inverso: um novo método público em um serviço genérico cujo único chamador é um consumidor interno; prefira uma capacidade privada entregue a esse consumidor na construção.
• Escopo, propriedade e necessidade: mapeie cada abstração, máquina de estados, opção, cópia defensiva e caminho de compatibilidade para seu contrato atual, consumidor de produção e módulo proprietário. Desafie funcionalidades não relacionadas e generalidade especulativa.
• Configuração e escolhas públicas: pergunte qual evidência de consumidor atual ou arte anterior suporta cada padrão, conjunto de operações públicas, formato ou conceito externo importado. Exija uma escolha explícita ou adiamento quando essa evidência estiver ausente.
• Perspectiva do modelo: quando o projeto envia prompts, esquemas de ferramenta ou resultados para um modelo, inspecione o texto exato que o modelo recebe. Sinalize conceitos fora da tarefa do modelo e verifique texto estável verbatim e comportamento dinâmico através de testes ou snapshots.
• Imposição: siga cada caminho de negação até a operação que o executa; exercite chamadores diretos e alternativos que podem contornar esquemas, prompts, fachadas, wrappers ou ordenação de listeners.
• Estado emprestado e derivado: determine se cada valor retido é emprestado ou próprio, depois rastreie notificações e cada cache, prompt, eco de UI, replay e visão de consulta até o ponto de sucesso documentado e a fonte autoritativa.
• Limites cobrem a operação final: localize o proprietário do resultado completo emitido ou retido, incluindo wrappers e metadados. Teste limites minúsculos e exatos, chunks únicos superdimensionados e texto multibyte para limites de bytes.
• Caminho de entrada real: testes exercitam o carregador, binário, worker ou subprocesso enviado quando relevante. Uma configuração de teste montada manualmente não detecta exportações inválidas.
• Força do teste: asserções falham na regressão pretendida e verificam estado externo, logs, eventos ou descarte em vez de reenunciar a implementação. Cobertura é necessária mas não é evidência de que o cenário está correto.
• Controles negativos: verifique que um caso deliberadamente inválido falha através do runner real para cada regra de aceitação alterada.
• Notas do Agente implementadas correspondem à realidade enviada: quando uma alteração implementa uma nota proposta, mova e reescreva como estado enviado no tempo presente no mesmo diff.
• Traduções: compare significado e terminologia em ambos os lados; estrutura correspondente não prova qualidade da tradução.

Relatando descobertas

Declare o defeito, localização, impacto e evidência. Coloque um defeito localizado inline no intervalo de diff relevante mais restrito; use um comentário de nível superior para arquitetura transversal, escopo ou síntese. Separe bloqueadores de sugestões e omita questões já aplicadas por uma verificação que passa. Ao receber revisão, verifique cada afirmação e corrija ou refute com base técnica.