Plano de reescrita

Especificação §20.3 / §21.3.2: o cenário 4 (design → produção de código entregável) exige um plano de reescrita com formato de contrato antes que o agente comece a editar arquivos. O plano é o registro de auditoria ao qual cada estágio subsequente se refere; sem ele, o caminho do patch desliza para "refatorar tudo o que parece errado" e a compilação quebra de maneiras não revisáveis.

Entradas

• code/index.json de code-import.
• token-map/*.json de token-map.
• O sistema de design ativo DESIGN.md (já no prompt).
• A intenção de ajuste do usuário (geralmente um breve resumo).

Saída

project-cwd/
└── plan/
    ├── plan.md           # human-readable narrative
    ├── ownership.json    # { file: '...', layer: 'leaf' | 'shared' | 'route' | 'shell' }
    ├── steps.json        # ordered { id, files[], rationale, risk: 'low' | 'medium' | 'high' }[]
    └── meta.json         # { generatedAt, atomDigest, tokenMapDigest }

steps.json é a entrada que patch-edit lê uma entrada por iteração. ownership.json é a fonte da verdade para "quais arquivos pertencem a um único componente versus infraestrutura compartilhada"; patch-edit se recusa a tocar em um arquivo de nível shell a menos que a etapa correspondente tenha risk: 'high' e o usuário tenha confirmado explicitamente.

Convergência

O átomo é concluído quando plan.md não está vazio E steps.json contém pelo menos uma etapa.

Antí-padrões que o fragmento do prompt proíbe

• Planos que incluem "reescrever toda a biblioteca de componentes" como uma única etapa. Divida em etapas por componente.
• Planos que não classificam a propriedade.
• Planos que não listam uma etapa de build-test no final.

Status

Implementado pelo daemon runner em apps/daemon/src/plugins/atoms/rewrite-plan.ts. Ele classifica a propriedade e escreve plan.md, steps.json e ownership.json.