chore(seidroid): take the uci review workflow with deadline headroom

[bdchatham]

Re-pins the seidroid review workflow to uci b01c2dd.

What moves

	before	after
driver run deadline	1200s	1800s, and settable via a new run-deadline-seconds input
job cap	45 min	60 min
sei-agent-driver	v0.18.0	v0.19.0

No caller input changes here. The 1800s default applies, so this is a pin bump only.

Why

Reviews were reaching the old ceiling rather than exceeding it exceptionally. Measured on sei-protocol/platform: ordinary reviews landed at 943s and 1029s — 79% and 86% of 1200s — and two runs (PRs 1670 and 1671) crossed it and published no verdict at all. Not a failing check: no findings, and a pull request that reads as unreviewed rather than as broken.

A caller could not raise it before. seidroid-review.yml named SEIDROID_RUN_DEADLINE_S only in prose and never set it, and a caller using uses: cannot inject env.

The job cap moves with it. A review costs more wall-clock than its own deadline — the scout pass, both sandbox launches, the driver install and the publish steps sit outside it — so a cap at the deadline turns the driver's own timeout report into a runner cancellation, whose annotation says only that the job was cancelled.

v0.19.0 also carries the scouts-settle path: when every dispatched scout reads the diff, finds nothing and reports it inert, the review publishes an approve verdict without spending a review turn. Any finding, a failed or unread scout, or a scout that omits inert still runs the full review.

Provenance

PLT-1263. Driver change: sei-internal-skills#440, released as v0.19.0 in #442. Workflow change: uci b01c2dd, with test/seidroid-review/deadline.py holding both limits against each other and against the measurement.

Pin verified from an empty module cache: go install github.com/sei-protocol/sei-internal-skills/sei-agent-driver/cmd/sei-agent-driver@v0.19.0 resolves.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Only updates reusable workflow SHAs; behavior changes come from the pinned uci/driver release, not local logic edits.

Overview
Re-pins all three seidroid jobs in .github/workflows/seidroid.yml (seidroid-review, seidroid-review-close, seidroid-review-reclaim) from uci commit 92f74c9 to b01c2dd. No with: inputs, secrets, or triggers change in this repo.

That upstream workflow bump is what picks up a longer default review run deadline (1200s → 1800s), a higher job time cap (45 → 60 min), sei-agent-driver v0.19.0, and the scouts-settle fast path that can publish an approve when every scout reports inert.

^{Reviewed by Cursor Bugbot for commit eba2899. Bugbot is set up for automated code reviews on this repo. Configure here.}

[seidroid]

review found nothing blocking.

[seidroid]

1. Blocking

None.

2. Non-blocking

• The pin bump takes driver v0.19.0, whose scouts-settle path publishes an approve verdict without a review turn when every dispatched scout reports the diff inert. This repo wires approve-on-success: true, so on a docs/comment-only pull request that becomes a real GitHub approval, and today the reusable workflow's default is exactly one scout (codex=xreview-scout-codex) — "every scout" is one model. The gate itself is narrow (any finding, failed scout, or missing inert runs the full review, and a diff with executable surface does not qualify), but this caller is where it converts into a review-requirement clearance, so it is worth a deliberate decision rather than inheriting it with the pin.
• The job cap moving 45 → 60 min applies to the pull_request-triggered path as well, which this caller wires on synchronize; worst-case runner and managed-sandbox hold per pull request rises accordingly. cancel-in-progress on the upstream concurrency group bounds it to one live run per pull request per mode, so this is cost, not a leak.
• run-deadline-seconds is taken as a default rather than set explicitly here, so the 1800s value is owned upstream and a later upstream default change moves this repo's review deadline at the next pin bump. That is the intended layering (the workflow pin is the unit of change), but it means the value the PR body cites is not visible in this repository.

3. Summary

Three uses: pins in .github/workflows/seidroid.yml move from uci 92f74c9 to b01c2dd, in lockstep, with no stale reference left anywhere in the tree. I verified the target commit exists and that its message matches the stated change, and diffed the reusable workflow between the two pins: the input surface is purely additive — one new optional run-deadline-seconds (default 1800) — the secrets contract is unchanged, and every input this caller passes (mode, approve-on-success, allowed-team, guidelines-file) still exists with the same meaning, so the "no caller input changes" claim holds. The job cap (60 min) sits above the driver deadline (30 min) as the upstream notes require, MIN_DRIVER_VERSION and the driver-version default both move to v0.19.0 together so the install-time floor stays consistent, and the caller's permissions blocks still cover exactly what the reusable job declares. Both jobs omit scouts, so the review and close paths derive the same scout name and close reclaims it. The codex scout's reading — diff read, nothing found — held on my own check of the diff and I carry it as concurrence on the blocking question; it contributed no findings to drop, and the three notes above are mine and non-blocking. The merge ref was absent, so the tree I read alongside the diff is the pull request head.

_{seidroid review · decision approve · session 1cdacd6ce9d349c4bbede2f0d9654ad6 · turn resp_claude_b93c619e2151c64e14560f4a47fef0ba · item 48dd8c01a6e554b7b0dea4f8baec0a58}

Findings: 0 blocking | 4 non-blocking | 0 posted inline