Convergence Gate Issues
The Convergence Gate stops automatically when it can no longer make progress. When it stops, it persists the result and creates a pending human-merge card. The stop reason tells you what happened.
Understanding stop conditions
Section titled “Understanding stop conditions”The gate records a reason alongside every bound_hit result. There are three:
no_progress — the reviewer’s findings in this iteration are fingerprint-identical to the previous iteration. The fix ran, a rebuild happened, the reviewer re-ran, and the same issues came back with no reduction. The gate stops rather than looping forever on the same failure set.
oscillation — a finding that was resolved in a previous iteration has reappeared. This means the fix in iteration N caused a regression that undid work from iteration N-1. The gate cannot converge because fixing one area breaks another.
max_iterations — the loop reached the configured maximum without clearing all findings. The default is 3 iterations. The gate stops even if progress was being made.
The gate stopped with no_progress
Section titled “The gate stopped with no_progress”The fix prompt ran and the rebuild completed, but the reviewer sees exactly the same issues it saw before. Possible causes:
- The fix prompt was too vague to change the specific failing element the reviewer is checking.
- The fix was applied in a file that the rebuild doesn’t pick up (e.g., an asset or generated file that is cached).
- The reviewer’s check targets a runtime condition the sandbox can’t reproduce.
Start from the iteration diff in the pending human-merge card. Verify the fix actually changed the file and line the reviewer is flagging. If the reviewer’s check is not appropriate for an automated loop, dismiss the card and address the finding manually.
The gate stopped with oscillation
Section titled “The gate stopped with oscillation”Oscillation means the loop is chasing its own tail. The fix fingerprint set from earlier iterations is being compared against the current findings — when a previously-resolved fingerprint reappears, the gate stops immediately.
To resolve: open the pending human-merge card, review the full iteration history including the diff from each pass, and write a targeted manual fix that addresses both the original finding and the regression simultaneously. Queue it as a normal prompt rather than restarting the gate.
The gate stopped with max_iterations
Section titled “The gate stopped with max_iterations”The default maximum is 3. If the gate is hitting this limit on every run for a complex target, you can raise it in Settings → Sweep → Convergence (the sweepConvergence settings key). Raise it conservatively — each additional iteration queues another sandbox run and rebuild.
If the gate consistently needs more than 3 iterations, the underlying reviewer findings are likely too broad for automated resolution. Consider splitting the target into smaller, more focused sweep runs.
The pending human-merge card is stuck
Section titled “The pending human-merge card is stuck”A pending human-merge card appears in the Pipeline or Queue panel after every completed gate run, regardless of stop reason. It stays there until you act on it — nothing merges automatically.
If the card doesn’t appear after a gate run:
- Check that the gate actually completed. A gate that is still running does not create the merge card until it stops. Look for an active Convergence Gate entry in the queue.
- If the gate is showing as
runningbut has not produced any output in an unusually long time, check the coordinator’s active children. If the coordinator already has an active child (another iteration still in the queue), the gate pauses until that child finishes. The queue enforces this — you’ll see the child prompt in queue status.
If the card exists but the Merge action is not available:
- The merge card is a manual action — Orbit never merges automatically. Click the card to open the diff, review it, and confirm the merge yourself.
Mode A cards require your approval before any fix runs
Section titled “Mode A cards require your approval before any fix runs”In Mode A, the gate prepares one sandboxed fix prompt but does not execute it. You see a pending-approval card rather than a merge card. If that card is not appearing after a Mode A gate run, check that the gate was triggered in Mode A and not Mode B — the mode is set at trigger time and not changeable after the fact.