Rewrite code modules with controlled erasure and verification

A 6-phase controlled erasure-and-rebuild protocol for when a file, module, or component needs to be deleted and rewritten from scratch, built around the risk that rewrites silently erase working, expected behavior that was never documented. Phase 1 (Justify) requires the AI to answer three questions before proceeding - what specifically is broken or unsalvageable, why targeted edits would make things worse rather than better, and what the concrete cost of keeping the current implementation is - falling back to targeted edits if it can't answer all three, since "this code is ugly" doesn't clear the bar but "the architecture assumes X but the system now requires Y and every patch worsens the mismatch" does. Phase 2 (Read) requires reading the entire target in full - even if read before - to catalog public interfaces, implicit contracts other files rely on, working behaviors that must continue working, non-obvious guard logic, and the full blast radius of every dependent file, building what becomes the Preservation List. Phase 3 (Declare) outputs a fixed-format erasure plan - target, justification, the full Preservation List with what depends on each item, the blast radius, the new implementation plan, and what will intentionally not be preserved - and waits for explicit user confirmation ("yes"/"confirmed"/"do it" counts, silence does not) before touching anything. Phase 4 (Erase) deletes the target cleanly once confirmed - not commented out, renamed to _old, or archived - touching only the declared scope and pausing to report if deletion reveals undeclared dependencies. Phase 5 (Rebuild) treats every Preservation List item as an obligation, tracked explicitly checked-off as implemented; dependent files must be able to use the new implementation unchanged unless changes were declared upfront; no bonus features, extra functionality, or adjacent cleanup is allowed beyond what was declared; and the new code must follow existing codebase conventions rather than the AI's own preferences. Phase 6 (Verify) re-reads every blast-radius file to confirm it's still compatible with the rebuild, verifies the specific function signatures/exports/behaviors it relied on are present, and flags and proposes a fix for any mismatch before declaring the work done - producing a final report with the Preservation List status, per-file compatibility check, and a CLEAN or NEEDS FOLLOW-UP status. Six hard rules are never violated: no deletion before user confirmation, no deletion before the Preservation List is complete, no cleanup-while-I'm-at-it scope creep during rebuild, no undeclared blast-radius expansion, no skipping Phase 6 verification, and no rewrite disguised as a refactor - if more than 80% of a file changes, this protocol applies rather than being treated as a normal edit.

Use it when a file, module, or component needs complete deletion and rewrite, when structural rot is deep enough that individual fixes would make things worse, or when accumulated technical debt makes code unmaintainable and beyond saving. Do NOT use it for partial refactors, single-function fixes, or targeted edits - Phase 1's justification bar exists specifically to reject those cases and fall back to surgical changes instead.

Input is a target file, module, or component proposed for a full rewrite. Output is an erasure plan requiring explicit user confirmation, then (once confirmed) a clean deletion, a rebuild matching every item on the Preservation List with no bonus scope, and a final verification report covering every blast-radius file.

A process protocol layered over normal code editing - it doesn't call external tools, but gates deletion and rewrite work behind explicit phases and required user confirmation before any destructive action.

Developers and AI agents facing a genuinely rot-beyond-patching file or module who need a disciplined way to rewrite it without silently dropping undocumented working behavior or breaking every file that depended on the old implementation.