Ledger de Regressão de Módulos

Quando Ativar

• O repositório tem pelo menos três módulos interdependentes, ou uma alteração anterior em A quebrou B.
• Uma alteração modifica o comportamento observável externamente de um módulo e deve provar que tanto esse módulo quanto os consumidores downstream ainda funcionam.
• O projeto já possui testes executáveis ou comandos de reconciliação que devem ser organizados por dependência.

Anti-Padrões

• Criar um ledger de regressão para um repositório pequeno sem dependências entre módulos.
• Adivinhar dependências manualmente ou tratar uma varredura como verdade permanente.
• Substituir códigos de saída de comandos de aceitação executáveis por revisão de modelo.

Habilidades Relacionadas

• test-collaboration: IDs de TESTE, ativos de teste e evidências de regressão de defeitos.
• ai-regression-testing: testes de regressão executáveis derivados de defeitos importantes.
• contract-first: verificação de contrato entre serviços ou entre clientes.
• change-impact: análise de raio de explosão pré e pós-implementação.

Problema

Em projetos grandes, os módulos dependem uns dos outros. Pessoas e agentes frequentemente verificam apenas o módulo alterado, enquanto os consumidores downstream falham silenciosamente. O defeito aparece dias depois, quando um agregado, exportação ou comportamento externo está incorreto.

O remédio é um ledger de regressão (REGRESSION.md) mais uma auditoria determinística: após qualquer alteração relevante, execute o módulo alterado e todos os consumidores downstream afetados. A entrega exige que todos os comandos passem.

Três Campos Obrigatórios por Módulo

## Module 03 — Shop Data Cleaning
Downstream consumers: 05-aggregation, 07-final-export
Dependency evidence: `<repository dependency graph or reproducible scan command>`
Regression acceptance command: `pytest tests/test_03.py && python scripts/reconcile.py --module 03`
Propagation rule: external behavior change → run 05 and 07; internal-only change with a green module check → downstream may be exempted

1. Consumidores downstream — derive-os do grafo de dependência do repositório, ferramentas de build ou uma varredura de importação/chamada reproduzível, e registre o comando ou ferramenta. A extração difere por ecossistema; esta habilidade não finge que um scanner universal pode analisar todas as linguagens. Marque as arestas unverified quando elas não puderem ser estabelecidas mecanicamente. Uma aresta não verificada afetada bloqueia um veredicto "tudo verde" até que um humano confirme seu escopo ou o módulo relacionado seja incluído na execução.
2. Comando de aceitação de regressão — o ativo principal do ledger. Cada módulo precisa de um comando executável que prove que ainda funciona: testes, scripts de reconciliação ou amostras de referência (golden samples). Sem ele, a auditoria se resume a "o modelo olhou e não encontrou problemas".
3. Regra de propagação — declare quais módulos downstream devem ser executados após uma alteração e quando uma isenção é justificada.

Conexão com TESTS.md

REGRESSION.md não mantém regras de negócios ou lacunas de teste. Ele referencia IDs de TESTE estáveis do artefato de registro de testes:

Related test points: TEST-ORDER-001, TEST-REFUND-003

• Quais regras devem ser protegidas, seu estado de cobertura e a localização das evidências pertencem a test-collaboration e ao registro de testes.
• Quais módulos e comandos devem ser reexecutados após uma alteração pertencem a esta habilidade e ao ledger de regressão.
• A sessão atual planeja os comandos do ledger. Uma vez autorizado pelo usuário ou escopo de tarefa existente, o host confiável os executa e retorna códigos de saída. Esta habilidade não adiciona um agente dedicado ou comando de barra.

Disciplina do Ledger

• Prefira comandos de aceitação do estilo de reconciliação em vez de verificações apenas de asserção. Fatos externos, como amostras de referência, totais upstream e relacionamentos contábeis, são mais difíceis de enfraquecer acidentalmente do que mocks ou asserções soltas.
• Atualize as listas downstream apenas a partir de evidências reproduzíveis. Quando as dependências mudarem, reexecute a ferramenta ou varredura do repositório registrada; não edite manualmente uma aresta sem evidências.
• Mantenha o ledger na raiz do repositório ou sob docs/, e vincule-o do artefato de instruções/mapa do projeto para que ele não se torne um órfão.

Fluxo de Auditoria

Invoque module-regression através do ponto de entrada de habilidade do host, como $module-regression no Codex. A sessão atual planeja e relata a auditoria. Comandos de repositório são executados através do host confiável dentro da autorização de usuário existente; peça apenas quando um comando precisar de nova autoridade. Códigos de saída bem-sucedidos são evidências de regressão, nunca autoridade canônica de conclusão ou integração do ECC.

…