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

The gate records a reason alongside every bound_hit result:

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.

reviewer_error — the Sweep reviewer itself failed to return a verdict, either on the initial pass or after a fix iteration. The gate stops rather than treating a reviewer failure as a clean result.

auto_approval_failed — in Mode B, the gate could not auto-approve the queued fix prompt. The gate stops instead of leaving an unapproved fix stuck mid-loop.

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

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 reviewer_error or auto_approval_failed

reviewer_error means the Sweep reviewer failed to return a verdict for the target — either before the first fix or after a rebuild. Check that the Sweep sidecar is reachable and the target surface actually loads; retry the gate once the reviewer is healthy.

auto_approval_failed is Mode B-specific: the gate could not auto-approve its own queued fix prompt. Check the queue for a fix prompt stuck in pending_approval and approve or requeue it manually; if this recurs, confirm the project’s automatic-approval setting is actually on.

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

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 running but 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

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.

Related

• Convergence Gate
• Use the Convergence Gate
• Sandbox Issues