CI policy: 30-minute job timeout (workflow-layer policy over the modeled GitHub default)

[gunbai-bot]

Operator directive (2026-07-02): CI jobs now time out at 30 minutes instead of inheriting GitHub's 360-minute platform default.

Why: a healthy floor is ~9 min solo. Observed today: floor jobs grinding 6+ hours single-threaded (one claim_executor at 8h57m wall / 8h07m CPU on one core), each squatting a runner slot until the 6h platform ceiling — a self-sustaining queue deadlock across all 25 fleet runners while the boxes sat ~87% idle. A >30-min job is pathological, not legitimately slow; it must fail fast and release its slot, surfacing the pathology instead of hiding it.

Layering (§3): extdeps/github/actions.dag's default_job_timeout_minutes = 360 is deliberately unchanged — it faithfully models GitHub's real platform default. The new gunbc_ci_job_timeout_policy_minutes = 30 is the workflow-layer policy on top, with a Terminal disposition carrying the rationale.

Receipts: ci.yml regenerated via generated_artifact_gate main_wet (diff is exactly 360→30 on the three jobs); run_generated_artifact_drift_gate_body PASS wet.

Companion work this wave: single-threaded resolver pathology (the actual reason jobs exceed 9 min) is being dispatched separately.

🤖 Generated with Claude Code

[gunbai-bot]

Thanks — noted on the Duration nit. Agreed a modeled Duration measure would be the more principled long-term shape; keeping it as a bare Int here matches the upstream field it feeds (GitHub's timeout-minutes) and the existing default_job_timeout_minutes: Int, so no §3 fork is introduced. If/when the measure/units tower grows a Duration, both this policy value and the upstream default migrate together as one change. No code change this PR. — sent from sunny-newt-884

[gunbai-bot]

Re-scoped to the full CI emergency response (adds a second commit — re-review expected).

Root cause found (not what we thought): the 8h57m jobs are not hardware contention — srv1 is 87% idle (128 cores, load 11, 45/125GB, 0 swap/OOM). They're an acute #6127 regression: shard-b sharded compile-clean into ~1,605 per-module gunbc compile subprocesses, each re-resolving its full import closure (~30.9× the monolith's CPU), scheduled at width 1 because the width fold priced each single-module shard against a stale whole-corpus 4.24 GiB RSS sample against the 8 GiB cap (real worst shard: 0.70 GiB).

This PR now does two things:

1. gunbc_ci_job_timeout_policy_minutes = 30 (workflow-layer policy; GitHub's 360 default stays modeled) — the fail-fast smoke alarm.
2. GUNBC_CI_COMPILE_CLEAN_WHOLE_TREE=1 on the ci job — rolls back the width-1 sharding to the whole-tree monolith.

Honest expectation: pre-regression monolith green runs were 28–96 min, so 30 min will still red most runs until the resolver single-thread pathology fix lands (separate lane, verified locally). This PR stops the fleet from burning 8-hour jobs and makes failure fast + honest; it does not by itself turn CI green. Receipts: ci.yml regenerated via generated_artifact_gate main_wet, drift gate PASS.

— sent from sunny-newt-884

[gunbai-bot]

Backed the rollback valve-flip out of this PR — it now delivers only the 30-min timeout policy. @cursor your finding 1 was right, and pursuing it surfaced something worse.

Finding 1 confirmed and deeper. I made the two flagged witnesses rollback-aware, then verified by execution (claim_batch --wet under GUNBC_CI_COMPILE_CLEAN_WHOLE_TREE=1) — and the valve does not cleanly restore a green monolith floor:

• compile_clean_sharding_enabled() → false ✓
• witness_floor_batch_one_uses_compile_clean_shards() → false ✓
• witness_floor_batch_one_has_no_compile_gate_monolith() → true (batch-0 carries no monolith gate label)
• gunbc_ci_floor_schedule_lens_holds() → false

So under the valve, batch-0 has neither shards nor the monolith gate, and the schedule lens fails. The GUNBC_CI_COMPILE_CLEAN_WHOLE_TREE valve looks like a half-exercised scaffold from #6127. Patching witnesses to match an unverified plan path would violate §5 (ship only what runs green), so I reverted the valve-flip and the witness edits.

This PR now = the clean, approved change only: gunbc_ci_job_timeout_policy_minutes = 30 (workflow layer; extdeps 360 default untouched). Net diff is ci.yml (360→30 ×3) + ci_workflow.dag (policy data + disposition + sites). Drift gate PASS; both shard-b floor witnesses PASS at their original state. Disposition text reconciled with the 28–96min receipt @cursor flagged in finding 2.

Finding 2 addressed: the '~9min' text is gone; the disposition now states plainly that 30min is deliberately below today's 28–96min floor — a fail-fast smoke alarm until the resolver fix lands, verification local meanwhile.

The #6127 regression itself is now routed to the operator with a concrete recommendation (a clean git revert of #6127 is viable — 17 files, one trivial docs conflict — vs. properly fixing the plan's rollback branch).

— sent from sunny-newt-884