Retrospectiva Brownfield

Execute o processo de engenharia do ECC retroativamente em um projeto que foi construído sem ele. Escolha qualquer fatia de uma base de código existente, audite o que existe, reconstrua como chegou lá, extraia um registro de lacunas de quatro eixos e, em seguida, execute as correções para frente através do pipeline padrão do ECC.

O fluxo de trabalho é "fatia primeiro": nenhum onboarding de repositório inteiro é necessário antes que seja útil, e cada fase pode ser reingressada a partir de um artefato durável em disco. Comece no meio, trabalhe para trás e depois avance.

Quando Ativar

• Adoção do ECC em um repositório que já existe e já está moldado
• O usuário pede para "auditar meu projeto existente", "fazer retrospectiva desta base de código" ou "o que perdemos?"
• Assumir, herdar ou retornar a uma base de código após um longo período
• O usuário pergunta "por que é assim?" seguido por "deve continuar assim?"
• Um módulo, recurso ou serviço precisa de uma repensada antes que o próximo recurso seja implementado sobre ele
• Decidir se uma área legada deve ser corrigida para frente, reescrita ou deixada documentada como está

Quando Não Usar

• Trabalho Greenfield sem código existente — use planner e tdd-workflow diretamente
• Onboarding para desenvolvimento orientado por especificações sem o loop de redesenho — o agente spec-miner faz isso por conta própria
• Uma verificação de prontidão de produção para aprovação de lançamento (go/no-go) — use production-audit
• Varreduras apenas de segurança — use security-review
• Retrospectivas de processo de equipe (cerimônias de sprint) — isso audita uma base de código, não pessoas

O Conjunto de Trabalho

Todos os artefatos são escritos dentro do projeto auditado, sob docs/retro/<slice>/:

Decisões retroativas vão para docs/adr/ por meio da habilidade architecture-decision-records. Se o projeto usa OpenSpec, reconstructed-spec.md pode em vez disso ser produzido por openspec/specs/<capability>/spec.md por spec-miner.

Como Funciona

Fase 0 — Escolha o Ponto de Entrada

Comece pelo que o usuário se importa hoje. Não mapeie o repositório inteiro primeiro.

Qualquer um destes é uma fatia válida:

Registre o perímetro no topo de gap-register.md antes de qualquer outra coisa: caminhos no escopo, pontos de entrada, chamadores, raio de explosão. Orce a fatia em aproximadamente 15 arquivos ou 2.000 linhas; se a escolha do usuário for maior, divida-a em sub-fatias nomeadas e registre cada uma como sua própria linha de trabalho. Uma fatia grande demais para auditar em uma sessão é uma fatia que nunca termina. Mantenha um marcador Current phase: ao lado do perímetro e avance-o cada vez que uma fase for concluída.

Fase 1 — Auditoria do Estado Atual

Estabeleça o que existe agora, com evidências. Não corrija nada ainda.

1. Reconheça a fatia: manifesto e impressão digital do framework, pontos de entrada, layout de testes, verificações de CI (pegue os passos de reconhecimento de codebase-onboarding, com escopo para o perímetro).
2. Execute os revisores que correspondem à pilha, em paralelo onde possível. Cada achado deve carregar um ponteiro file:line:
   • O revisor de linguagem para a pilha (typescript-reviewer, python-reviewer, go-reviewer, ...)
   • security-reviewer
   • silent-failure-hunter para erros engolidos
   • type-design-analyzer onde invariantes são codificados em tipos
   • performance-optimizer apenas se a fatia estiver em um caminho quente
3. Tire um snapshot do estado atual: contagem de testes e cobertura, status de lint/CI, inventário de TODO/FIXME/HACK dentro do perímetro.

Escreva tudo em baseline-audit.md. Achados que são corrigidos durante esta fase corrompem a linha de base — guarde-os para o registro.

Fase 2 — Reconstrução para Trás

Trabalhe para trás a partir do estado atual até as decisões que o produziram.

…