The signal
A patching spiral starts when each fix changes the shape of the failure without reducing the amount of uncertainty or partial state around it. The system may move from one error to another, but the recovery path does not become clearer.
That pattern is different from ordinary iteration. Iteration narrows the problem. A patching spiral keeps adding exceptions while the desired state remains unclear.
Questions to ask
- Has the total failure surface become smaller, or has the latest error only replaced the previous one?
- Can the current state be explained from a known configuration, migration, or artifact?
- Is each fix making the next failure easier to diagnose, or harder?
- Would rebuilding from a known-good source be safe and faster than preserving the current partial state?
These questions move the investigation from the latest symptom to the consistency model of the whole system.
When to rebuild
Rebuilding is worth considering when the desired state is well defined, the current state is difficult to explain, and the data or artifact can be recreated safely. The rebuild should have an explicit checkpoint, validation step, and recovery path rather than becoming another opaque intervention.
If the state cannot be recreated safely, preserve it and improve the evidence first. Capture what changed, which assumptions still hold, and which boundary is producing the next failure before making another mutation.
A practical boundary
The goal is not to prefer deletion or rebuilding by default. It is to recognize when local patches are preserving an invalid state instead of moving the system toward a verified one. Once that boundary is visible, the next action can be chosen from evidence rather than from the pressure of the latest error.