The rescue checklist for AI-built projects
The rescue work across many cases has consistent shape. The same diagnostic moves apply. The same decision branches surface. The same artifacts produce reliable outcomes. The variance is in the specifics of each project; the structure is stable.
This post is the cluster-closer that consolidates the rescue framework into a single reusable checklist. Each phase references the cluster post that covers it in depth. The checklist itself is the artifact you can copy and run against your own situation, with the depth-posts available when you need more than the checklist provides.
The framework has five phases: stabilize the immediate damage, diagnose the underlying state, decide between fix and rebuild, write the rescue spec, execute against gates. Each phase has specific moves. Together they produce reliable rescue outcomes that don't depend on the rescuer's mood or attention on the day.
Phase one: stabilize
The first move when an AI tool has broken something is to stop the damage from compounding. Continued AI prompting against a broken state usually makes things worse, not better.
The stabilization moves:
Stop the AI session. No more prompts until the state is understood.
Capture the current state. Git status, recent commits, error messages, what's visibly wrong. The capture becomes the baseline everything else operates against.
Isolate production. If the breakage might reach production, take whatever immediate action prevents that (rollback, maintenance page, traffic redirect).
The depth coverage of this phase is in ai-coding-agent-broke-my-app. The summary version is: the first move is always to stop generating, then to capture state, then to think.
Stabilization is fast. Usually 15 to 30 minutes from "something is wrong" to "I have a captured baseline of what's wrong." The discipline is to not skip directly from "something is wrong" to "let me try to fix it," which is the common failure mode.
Phase two: diagnose
With stabilization done, the diagnostic phase identifies what's actually broken. The common pattern is that the visible symptoms only hint at the underlying cause, and fixing visible symptoms without addressing the cause produces the false-fix loop.
The diagnostic moves:
Run the stale-server check. The most common cause of "the AI says it's fixed but it's still broken" is that the runtime is serving stale code. Verify the runtime is actually current before drawing other conclusions.
Run the surface-vs-semantic check. The visible behavior might look right while the underlying state is wrong. Verify both layers for everything the rescue claims to address. Coverage in why passing tests does not mean the app is fixed.
Identify the failure category. Is this stale-state breakage, surface-vs-semantic mismatch, structural drift, or fundamental mismatch? The category determines the right fix path. Coverage in fix the AI-generated app before you rebuild it.
Diagnosis usually takes longer than stabilization. The investment is worth it because the rest of the rescue is bounded by how accurate the diagnosis is. A wrong diagnosis produces a fix that doesn't address the actual problem.
Phase three: decide
With diagnosis complete, the decision phase chooses between fix-in-place and rebuild. Most rescues should fix in place; some genuinely need to rebuild. The decision matters because the path forward is very different.
The decision moves:
Run the four-axis diagnostic for fix-versus-rebuild. State clarity, dependency integrity, drift severity, business risk. Each axis points toward fix or rebuild; the combination is the recommendation. Coverage in when to rebuild instead of fix an AI-built app.
Honestly estimate both costs. Operators usually underestimate rebuild cost because they think of it as "build the same thing cleanly." Realistic rebuild is often 70-100% of original build cost. Fix is usually cheaper than expected once the diagnosis is accurate.
Commit to the path. Don't try to half-fix and half-rebuild. The decision is which path; the execution is against that path.
The decision phase usually takes hours to a day. Rushing it produces wrong choices that cost weeks downstream. The investment in the right decision pays back continuously.
Phase four: spec
With the path chosen, the spec phase captures what the work is going to be. Without a spec, the work is improvised; improvised work has variable quality.
The spec moves:
Write the rescue spec. Six required sections: current broken state, protected scope, success criteria, evidence requirements, deadline and priority, repair boundary. Coverage in how to write a rescue spec for a broken AI project.
Review the spec for completeness. Are the success criteria verifiable? Is the protected scope specific? Are the constraints named?
Hand the spec to the executor. Whether that's a human consultant, an AI agent, or future-you, the spec is the contract for what the work is.
The spec phase takes hours. The investment is small relative to the prevention it provides. Most rescues that go wrong went wrong because the spec was implicit rather than explicit; the executor was operating against guesses about what mattered.
Phase five: execute
With the spec in hand, execution does the actual repair work. The execution discipline isn't optional; it's what makes the spec produce the intended outcome.
The execution moves:
Work against the spec. Each action either advances the success criteria or doesn't. Actions that don't shouldn't happen.
Verify continuously. Use the four-leg acceptance pattern (tests, surface check, semantic check, integration check) on every change. The verification catches false-fix cases before they compound.
Audit before declaring done. Run the five-dimension audit (correctness, security, dependencies, performance, accessibility) before any change ships. Coverage in how to audit AI-generated code before you ship.
Document what was done. The repair becomes part of the project's history; the next rescuer (or next AI session) needs to know what happened.
Execution is usually the longest phase by clock time and the shortest by decision count. The decisions were front-loaded into stabilize, diagnose, decide, and spec. Execution is following the plan that those phases produced.
The reusable checklist
The five-phase framework consolidated as an executable checklist:
RESCUE CHECKLIST
PHASE 1: STABILIZE
[ ] AI session stopped
[ ] Current state captured (git status, error messages, visible symptoms)
[ ] Production isolated if at risk
PHASE 2: DIAGNOSE
[ ] Stale-server check completed (runtime is actually current)
[ ] Surface-vs-semantic check completed on visible failures
[ ] Failure category identified (stale-state, surface-vs-semantic, drift, fundamental)
PHASE 3: DECIDE
[ ] Four-axis diagnostic run (state, dependencies, drift, business risk)
[ ] Both paths cost-estimated honestly
[ ] Path committed (fix in place OR rebuild from scratch)
PHASE 4: SPEC
[ ] Rescue spec written (6 sections: broken state, protected scope, success criteria, evidence, deadline, repair boundary)
[ ] Spec reviewed for completeness
[ ] Spec handed to executor
PHASE 5: EXECUTE
[ ] Work done against spec only
[ ] Four-leg acceptance pattern applied on each change
[ ] Five-dimension audit run before shipping
[ ] Changes documented in project history
This checklist is the artifact. Copy it. Use it. The cluster posts referenced above provide depth when you need more than the checklist line offers.
What this gives you over improvised rescue
An improvised rescue has variable quality. Sometimes the rescuer happens to catch what matters. Often they don't. The outcomes range from "fully fixed" to "patched but unstable" to "broken in new ways."
A checklist-driven rescue has bounded quality. Each phase is run. Each move within each phase is run. The outcomes cluster around "fixed and documented" because the discipline prevents the failure modes that produce the worse outcomes.
The checklist isn't a substitute for skill. Skilled rescuers using the checklist produce better outcomes than skilled rescuers without it, and dramatically better outcomes than unskilled rescuers without it. The checklist is multiplicative with skill, not replacement for it.
The pattern is the same shape as the gate that caught us and three catches at the surface vs semantic boundary describe at the per-incident level: codified discipline produces consistent outcomes where improvised discipline produces variable ones.
What this content engine itself demonstrates
This site is the proof-of-work for the discipline this post describes. The content engine runs the same five-phase pattern in miniature for every piece of content: stabilize the current state, diagnose what's needed, decide the path, write the spec, execute against gates.
The result is what you're reading right now: a multi-cluster knowledge graph built with the discipline that this cluster's posts describe. The codified template I run has now run through dozens of consecutive applications without a missed gate. The four-layer enforcement framework catches what individual layers miss. The audit pattern verifies before promotion.
If the discipline didn't produce reliable outcomes, the content engine couldn't have built this way. The fact that it did is the proof that the framework works at scale.
The same framework applies to your own AI-built projects. The discipline is portable. The checklist is reusable. The outcomes are predictable once the discipline is in place.
Where to go from here
If you're facing a broken AI project right now, the checklist above is the path forward. Start with Phase 1. Don't skip to fixing.
If your situation is too complex for self-rescue, the packet from what to send when asking for help with a broken AI app is what to gather before reaching out. A well-formed help request produces fast, useful triage.
If you want to install the discipline preventively (so the next AI session doesn't produce a rescue case), the framework in how to stop AI from breaking your project covers the upstream prevention work that makes rescues rare in the first place.
The rescue work has shape. The shape is codified. The discipline is available. Use it.
If you've got a broken AI project and want a structured rescue diagnostic that runs the framework above against your specific situation, send the packet. VibeKoded can scope a rescue diagnostic, stabilization sprint, or rebuild plan. → Work with VibeKoded