You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto-mode's PR review-remediation loop caps at 2 review cycles, then escalates costexceeded — Review remediation budget exhausted: 2/2 review cycles used to the operator.
A genuinely valuable PR (the DispatchDropEscalator — escalates silent dispatch drops) escalated as stuck after 2/2 cycles. The actual bug was trivial and pinpointed by its own failing test: expect(escalations).toHaveLength(1) → got 0, at a specific line, because _onDrop returned before push-ing the drop. An operator fixed it in minutes by reading the test assertion.
So the loop burned both cycles without fixing a bug the test named exactly.
Two improvements
Feed the failing-test output to the fixing agent. The remediation dispatch should include the concrete CI failure — the failing test name + assertion (expected 1, received 0 at file:line) + the relevant log lines — not just kind=ci_failure. An agent that sees the assertion can usually fix it directly; one that only sees "CI failed" re-guesses.
Revisit the 2-cycle cap / make it configurable. Two cycles is tight for a multi-test fix. Consider: a higher cap when each cycle is making measurable progress (fewer failing tests), or an env-configurable budget. Pair with fix: signal intake dedupe blocks all repeat UI submissions #852-style origin-truth guards so a cap-exhaustion on already-passing/merged work doesn't false-page.
Theme
Part of the session-wide pattern: give the agent the evidence (test assertions, origin truth) at decision time instead of a terse status. See protoWorkstacean #852 (escalate-only-if-not-shipped), #853 (triage verify the diff).
Context
Auto-mode's PR review-remediation loop caps at 2 review cycles, then escalates
costexceeded — Review remediation budget exhausted: 2/2 review cycles usedto the operator.Observed (2026-06-06, protoWorkstacean #848)
A genuinely valuable PR (the DispatchDropEscalator — escalates silent dispatch drops) escalated as stuck after 2/2 cycles. The actual bug was trivial and pinpointed by its own failing test:
expect(escalations).toHaveLength(1)→ got 0, at a specific line, because_onDropreturned beforepush-ing the drop. An operator fixed it in minutes by reading the test assertion.So the loop burned both cycles without fixing a bug the test named exactly.
Two improvements
expected 1, received 0at file:line) + the relevant log lines — not justkind=ci_failure. An agent that sees the assertion can usually fix it directly; one that only sees "CI failed" re-guesses.Theme
Part of the session-wide pattern: give the agent the evidence (test assertions, origin truth) at decision time instead of a terse status. See protoWorkstacean #852 (escalate-only-if-not-shipped), #853 (triage verify the diff).