re-create — Protocolo de Apagamento e Reconstrução Controlados

Visão Geral

Roxo Oco é a técnica mais destrutiva de Gojo — azul e vermelho combinados em apagamento total do alvo. Mas Gojo não a usa descuidadamente. Ele sabe exatamente o que está apagando e por quê. O mesmo aqui: esta habilidade é a opção nuclear, invocada apenas quando a correção é a abordagem errada, executada com controle total sobre o que é apagado e o que deve sobreviver.

Reescritas são perigosas não porque a reconstrução é difícil, mas porque é fácil apagar silenciosamente um comportamento que estava funcionando e era esperado. Esta habilidade impõe um inventário completo do que deve sobreviver antes que uma única linha seja deletada, e uma verificação completa de que tudo sobreviveu após a reconstrução.

Quando Usar Esta Habilidade

• Use quando um arquivo, módulo ou componente precisa ser completamente deletado e reescrito do zero
• Use quando a deterioração estrutural é tão profunda que correções individuais só a piorariam
• Use quando a dívida técnica acumulada torna o código incontrolável
• Use quando o alvo está fundamentalmente quebrado e além de conserto
• NÃO USE para refatorações parciais, correções de função única ou edições direcionadas

Como Funciona

FASE 1 — Justificar o Apagamento

A IA deve provar que uma reescrita completa é necessária. Ela deve responder a todas as seguintes perguntas:

1. O que especificamente está quebrado ou insalvable?
   • Não "está bagunçado" — problemas estruturais específicos que tornam correções direcionadas impossíveis ou contraproducentes
2. Por que edições direcionadas piorariam as coisas, em vez de melhorar?
   • Correções em cima de deterioração, complexidade crescente, incompatibilidade arquitetural
3. Qual é o custo concreto de manter a implementação atual?
   • Carga de manutenção, superfície de bugs, desempenho, velocidade do desenvolvedor

Se a IA não conseguir responder claramente a todas as três perguntas, ela deve recorrer a edições direcionadas em vez de uma reescrita. Uma reescrita não é uma recompensa por código bagunçado — é um último recurso.

A exigência é alta. "Este código é feio" não justifica o roxo oco. "A arquitetura assume X, mas o sistema agora requer Y e cada correção piora a incompatibilidade" sim.

FASE 2 — Ler o Alvo Completamente

Antes de propor a exclusão, a IA deve ler o alvo inteiro (arquivo, módulo ou componente) por completo.

A IA deve identificar e catalogar:

1. Interfaces públicas — funções, classes, tipos ou exportações que outras partes da base de código chamam
2. Contratos implícitos — comportamentos dos quais outros arquivos dependem, mesmo que não sejam formalmente tipados
3. Comportamentos que funcionam — coisas que a implementação atual faz corretamente e que devem continuar funcionando
4. Lógica não óbvia — casos extremos, salvaguardas ou tratamentos especiais que parecem incidentais, mas são intencionais
5. Raio de explosão — todos os arquivos na base de código que importam ou dependem do alvo

A IA não pode pular esta fase, mesmo que já tenha lido o arquivo antes. O propósito não é familiaridade — é construir a Lista de Preservação.

FASE 3 — Declaração de Apagamento (Usuário Deve Confirmar)

A IA gera um plano de apagamento completo e espera pela confirmação do usuário antes de deletar ou escrever qualquer coisa.

HOLLOW PURPLE — ERASURE PLAN
─────────────────────────────────────────
TARGET FOR ERASURE:
  [file path or module name]

WHY TARGETED FIXES ARE WRONG:
  [specific justification — architectural rot, fundamental mismatch, etc.]

PRESERVATION LIST (must survive the rewrite):
  - [public interface / export 1] → [what it does, who depends on it]
  - [public interface / export 2] → [what it does, who depends on it]
  - [working behavior 1]          → [what it does, why it must be kept]
  - [non-obvious logic 1]         → [what it guards against]

BLAST RADIUS (files that depend on the target):
  - [file path] → depends on [what specifically]
  - [file path] → depends on [what specifically]

NEW IMPLEMENTATION PLAN:
  [Description of what the rebuild will look like — structure, approach, key decisions]

WHAT WILL NOT BE PRESERVED:
  [Anything intentionally dropped and why — dead code, deprecated behavior, etc.]
─────────────────────────────────────────
Confirm to proceed with erasure and rebuild.

Nada é deletado até que o usuário confirme explicitamente. Uma resposta como "sim", "confirmado", "faça isso" ou equivalente conta. Silêncio não conta.

FASE 4 — Apagamento Controlado

Usuário confirma → o alvo é deletado. Regras para esta fase:

• Deletar de forma limpa. Não comentado, não renomeado para _old, não arquivado no local — deletado.

…