Escape an agent error loop

Stop repeated failed fixes and give Superapp a clean diagnostic problem.

An error loop happens when the agent repeatedly changes code without removing the same underlying failure. More retries usually add noise. Stop, reduce the problem, and ask for evidence before another edit.

Recognize the loop

• The same compiler or runtime error appears after two attempted fixes.
• The agent alternates between two approaches and reintroduces the previous problem.
• Unrelated files keep changing while the original feature remains broken.
• The explanation says the issue is fixed, but the latest build still fails.

1. Stop adding instructions

Let the current run finish. Do not stack new requests while Superapp is still changing files, because each follow-up may start from an incomplete state.

2. Name the last known-good state

State which version worked, what single change followed it, and whether the failure is in compilation, launch, behavior, data, or an external service.

3. Ask for diagnosis only

Ask Superapp to inspect the first error, trace its cause, and explain the smallest proposed fix before changing code.

4. Approve one bounded fix

Protect working screens and project settings explicitly. Build immediately afterward and compare the error with the previous one.

A recovery prompt

Stop making broad changes. The last working version was [identify it]. After [single change], the build began failing with [first exact error]. Diagnose the root cause first. Then make the smallest fix without redesigning screens, changing dependencies, signing, entitlements, bundle identity, or unrelated files. Build again and report whether the original error is gone.

Know when to revert

Revert when two focused attempts leave the same error, the fix changes unrelated architecture, or a previously working core flow is now damaged. Returning to a clean base is often faster than repairing several speculative edits.