review-scope

Habilidade de Revisão de Escopo

Propósito

Verificar se as alterações de código fazem exatamente o que deveriam fazer — nem mais, nem menos. Esta é uma validação do tipo aprovado/reprovado, não uma sessão de feedback.

Quando Usar

• Fase de verificação TDD
• Revisão de PR para conformidade de escopo
• Qualquer revisão de código que exija validação de escopo

Entradas Necessárias

context_files

• Plano de implementação ou documento de requisitos
• Documento de design (se disponível)
• Arquivos alterados a serem revisados

context_data

• commit_details: O que esta alteração deve fazer
• requirements: Lista de REQ-* sendo abordados
• constraints: Lista de restrições CC-* que devem ser satisfeitas
• allowed_files: Arquivos que podem ser modificados (limite do escopo)

Procedimento

1. Estabelecer Limites do Escopo

A partir das entradas, identifique:

• O que DEVE ser feito (requisitos)
• o que NÃO DEVE ser feito (restrições)
• Quais arquivos PODEM ser alterados
• Qual comportamento é esperado

2. Revisar Alterações

Para cada arquivo alterado:

1. Este arquivo está no conjunto permitido?
2. As alterações atendem aos requisitos declarados?
3. Há alterações não relacionadas aos requisitos?
4. As alterações violam alguma restrição?

3. Relatar Resultado

Se todas as verificações passarem:

ACCEPT

Se alguma verificação falhar, liste as violações:

VIOLATIONS:
- <arquivo>:<linha> - <descrição em suas próprias palavras>
- <arquivo> - <descrição>

[Opcional] THEMES: <padrão digno de nota>

Formato de Violação

Descreva as violações naturalmente com localização e explicação clara:

- src/parser.rs:45 - Infraestrutura de logging adicionada não estava no escopo do commit
- src/config.rs - Arquivo modificado fora do conjunto permitido

Se notar padrões entre as violações, destaque-os:

THEMES: Múltiplas alterações vão além dos requisitos declarados, entrando em refatoração de tratamento de erros

Verificação de Viés de Mudança Mínima

O agente implementador tem tendência a fazer a menor alteração possível para atingir seu objetivo. Após identificar violações, considere:

As violações apontam para alguma refatoração potencial que tornaria o código mais sustentável? O implementador resistiu a uma solução estrutural melhor em favor de uma correção rápida?

Se sim, anote isso em uma seção REFACTORING:

REFACTORING: <descrição da melhoria estrutural que o implementador evitou>

Isso não é uma violação — é um sinalizador para o orquestrador considerar.

O Que Esta Habilidade NÃO Faz

• Sugerir melhorias não relacionadas a violações
• Fornecer feedback construtivo geral
• Revisar estilo de código (use review-style para isso)

Esta é uma porta binária: ACCEPT ou VIOLATIONS. Anotações de refatoração são sinalizadores opcionais, não bloqueadores.