Observed healthy slow-runner days where 90 s was insufficient:
the verifier returned ``pending`` and let bad pushes through to
the next dispatcher cycle. 180 s catches the fast-failing checks
(lint/format/push-validation typically fail in 30-60 s) AND gives
headroom for a backlogged runner where those checks may queue for
a minute or two before they actually run.
- Per-call budget: 90 → 180 s (doubles polls-per-window from 9 to
18; 10 s poll interval unchanged).
- Worst-case cycle math updated in the cycle-budget block comment:
5 PRs × 180 s = 15 min (was 7.5 min) of polling per cycle in the
uncapped case. The per-cycle budget (commit 2c43179e7) still
caps total polling at IMPLEMENTER_POST_PUSH_CI_CYCLE_BUDGET_S
(default 300 s), so the practical worst case is unchanged.
- Existing TestPostPushCIVerify docstrings update to reference the
new number.
Escalation integration tests get an autouse fixture that disables
the verifier flag: ``test_implementer_escalation_integration.py``
scripts many ``outcome=resolved`` + head-advanced scenarios but
doesn't stub ``fetch_ci_status``, so without the disable the
verifier would poll the FakeReviewAPI default for the full 180 s
on a real ``time.sleep``. The verifier itself has dedicated
coverage in ``TestPostPushCIVerify`` / ``TestPostPushCIVerifyCycleBudget``.
uv.lock change for the new ``mcp-servers`` optional dep stays
unstaged — it's missing its matching ``pyproject.toml`` entry.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
drew
e28b41f7ec