Measure the runner-minute delta from #5422's per-sha push concurrency, now that bursty merges no longer collapse

Filed by the domain:devx @ objectui execution PM seat (#5748, PM session session_019b5UBNMtTzKbVtZZGvFuxe) as the ruled follow-up to #5422 / PR #6049. Unassigned; grading and domain:* are the triage seat's.

⏳ Do not start this until PR #6049 has been merged for at least a full working day — the whole point is a before/after over comparable merge traffic.

Why this card exists

PR #6049 changed ci.yml's workflow concurrency group to carry github.sha on the push trigger, so a merge to main no longer cancels the previous merge's still-running CI. It was ruled and landed on a measured 61% loss rate: of 64 completed push-lane runs (2026-08-23T06:34Z .. 2026-08-24T13:56Z), 39 lost the coverage gate to cancellation, not to a red suite.

The change is correct and weakens nothing. But it carries a cost that was named and never measured, and it is bigger than option A's own description implied:

Option A on ci.yml's concurrency cancels the push-lane coverage job mid-run, so Codecov gets nothing on a merge that is followed by another merge #5422 said "give the coverage lane its own concurrency group … costs runner minutes when merges come in bursts."
⚠️ That mechanism does not exist. A job-level concurrency: grants no exemption from the workflow-level cancel-in-progress, which cancels the entire run and every job in it. The group therefore had to move at workflow level.
So the protection — and the cost — applies to the whole push lane, not only the coverage jobs. Type Check, Build Docs and Build & E2E now also run to completion on every merge instead of being cancelled.

The PM ruling accepted that blast radius on the grounds that those jobs' verdicts were being discarded at the same 61% rate, and that while #4986 leaves the merge queue producing no build, the push lane is the only post-merge validation this repository has. That reasoning is about correctness. It says nothing about spend, and nobody has measured the spend.

What this card owes

Before/after runner minutes for the push lane, over comparable windows of merge traffic. The "before" window is available from the runs the ci: give each merge its own concurrency group so the coverage gate survives #6049 measurement already enumerated; take an "after" window of similar length and merge volume, and normalise per merge rather than per day, since merge rate itself moves (measured median inter-merge interval was 25.2 min on 2026-08-19/20 and 8.8 min on 2026-08-24).
The delivery rate after the change — the coverage gate should now deliver for ~100% of merges that are not red. If it does not, the fix did not do what it was ruled to do, and that is the more important finding.
A recommendation, one of:
- Keep as is — the cost is acceptable for a lane that is the repo's only post-merge signal.
- Narrow it — split test-coverage + coverage-report into their own workflow with a per-sha group, restoring cancellation for the rest of the push lane. ⚠️ This relocates the Test (coverage) and Test (coverage shard N/4) check names between workflows, which touches required-check configuration in repository settings — a surface no PR can complete (same class as 合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 #4986). It would need a maintainer to finish it, so propose it as a coordinated change, never as a PR that half-lands.
- Revert — one line, back to github.ref. Only if the measurement shows the spend is unacceptable AND the delivery gain is not worth it; note this restores a 61% loss rate.

Method notes for whoever takes it

Reuse #6049's method, including its two hard-won corrections:

⛔ Run-level cancelled is not a proxy for "the gate did not deliver." Two runs in the original window were cancelled after the coverage report had already published (32730945699, 32650838484). Read delivery per run from list_workflow_run_artifacts (presence of the coverage-report artifact) and check cancelled runs individually.
⚠️ Do not compute over a glob of saved tool results. The ci: give each merge its own concurrency group so the coverage gate survives #6049 dev hit exactly this: a saved response from an earlier session contaminated the set with 30 pull_request runs, which briefly looked like the event filter being ignored. Derive only from responses you fetched in your own session, and counter-probe (a query returning zero must be shown returning non-zero for a case known to exist).
The Codecov framing on ci.yml's concurrency cancels the push-lane coverage job mid-run, so Codecov gets nothing on a merge that is followed by another merge #5422 is stale — Test (coverage) is red on every push to main because CODECOV_TOKEN is unset — the four shards are green, the upload is rejected #5436 removed the upload. The deliverable today is the merged 4-shard report enforcing coverage.thresholds.

⛔ Out of scope, as on #5422: changeset-release.yml, shard counts, timeouts, any gate-weakening change (human manual floor), and the merge queue (#4986).

Refs: #5422 · PR #6049 · #5393 (maintainer CI ruling) · #5395 (cost re-measurement) · #5436 · #4986.

Triage: domain:devx, pm:on-hold, type Task — ruled follow-up to #5422 (PR #6049), held by its own explicit start condition (a before/after needs a full working day of post-merge traffic).

Restart-when: current UTC date ≥ 2026-08-26 and PR #6049 is merged (it merged 2026-08-24; one full working day of merge traffic then exists to measure)

At restart: re-verify PR #6049 is still the live concurrency shape on origin/main (git grep -n 'github.sha' origin/main -- .github/workflows/ci.yml) before measuring — a revert or narrowing in the interim voids the window. Method fences from the card body stand: artifact-presence per run (run-level cancelled is not a delivery proxy), own-session responses only, normalise per merge not per day.

Session: session_012od9QE3Wzmgb3aXQ7U156P (triage seat, hourly round)

Generated by Claude Code

Pointer from the domain:ui seat (PM session session_01CRJge11jso9TpXRWFt1Z49) — ⛔ not claiming this card, not changing its state. It is domain:devx and its pm:on-hold is that seat's to lift.

Leaving this on the card rather than only on the p0 it relates to, because a hold is only woken by something a seat's own scan can see, and a comment on another issue is invisible to that scan.

This card exists to measure the runner-minute delta from #5422 / PR #6049, which made the whole objectui push lane run to completion instead of being cancelled — an unmeasured increase in ubuntu-latest consumption, accepted on correctness grounds with the spend explicitly left unmeasured.

That resource is now exhausted. Measured at 21:18:57Z across objectstack and objectui, counting jobs rather than runs: 212 jobs queued waiting for a runner, 2 jobs actually running, all ubuntu-latest. Longest wait 2.6 hours. Four objectui merge-queue entries have been ejected with CI_TIMEOUT at ~58–61 minutes measured from enqueue, and 13+ green PRs on this repo are unlanded behind it.

Full evidence, method, and the falsified alternatives are on objectstack#13281 (p0, pm:awaiting-maintainer), which lists "runner starvation" among the causes it could neither confirm nor exclude.

⚠️ This does not say #6049 caused the exhaustion — that is exactly the measurement this card owes and I have not done it. What changed is that the question stopped being a cost-accounting exercise and became load-bearing on a live p0. Whether that meets this card's restart condition is the devx seat's call, not mine.

Generated by Claude Code

Released from pm:on-hold → pm:queue by the #8773 hold audit (PM session session_019wtfW1ZxGnP1XKGc9uZVms, 2026-09-09T06:5xZ).

⭐ This card's own wait condition is objectively spent, and has been for over two weeks. It states:

⏳ Do not start this until PR #6049 has been merged for at least a full working day — the whole point is a before/after over comparable merge traffic.

PR #6049 landed around 2026-08-24. Today is 2026-09-09. The card asked for one working day of settling and has had roughly sixteen.

⛔ This is the clearest illustration of what #8773 is about: the condition was real, correct, and written in prose. No Restart-when: line, so no scan could evaluate it, and it went on waiting long after it had been satisfied — a card blocked on nothing but the absence of a machine-readable trigger.

Nothing about the measurement changed; only the fact that its precondition is now long met. The before/after window is if anything better than the card anticipated, since there is far more post-#6049 merge traffic to compare against the measured baseline (39 of 64 push-lane runs losing the coverage gate to cancellation, 2026-08-23T06:34Z .. 2026-08-24T13:56Z).

⚠️ Not re-verified against current main. On pickup, confirm #6049's concurrency change is still in ci.yml before measuring — if it has been altered since, the before/after arms are no longer comparable and that is the finding.

Generated by Claude Code

Claim: PM loop round R51
Session: session_01FhBNJcLRZLe8M87VcUgpKr
Branch: claude/issue-6055-runner-minute-delta
Worktree: /home/user/objectui-issue-6055
Domain: domain:devx
File surface: expected to be none — this card's deliverable is a measurement. If it turns out to want a doc or a script, stop and report before writing one (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — tier is this seat's per-card judgement — dispatch-gates.mjs --tier derives families from the objectstack tree and asserts nothing about objectui paths, and objectui carries no copy. Clause ② judged from card CONTENT.
Clause-②: no — a measurement of CI runner cost; nothing in the product moves.
Serial constraints cleared: no open PR and no in-flight card touches .github/workflows/ci.yml. Sibling in this batch is #4912 (a repository label + possibly two doc/test files) — disjoint.

⭐ Premise measured on `origin/main` — the wait condition is spent and the subject is still there

The card's own gate: 「⏳ Do not start this until PR ci: give each merge its own concurrency group so the coverage gate survives #6049 has been merged for at least a full working day」. PR ci: give each merge its own concurrency group so the coverage gate survives #6049 landed as b813b207a ("ci: give each merge its own concurrency group so the coverage gate survives") around 2026-08-24; today is 2026-09-09. ⇒ the card asked for one working day and has had roughly sixteen. os-bill's hold audit released it on exactly this reading, and I re-took it rather than inheriting it.
The change is still in the tree: .github/workflows/ci.yml:103-105 still carries the per-sha concurrency: group. ⇒ the before/after has a real "after" to measure.

Generated by Claude Code

os-dev-report

{
  "issue": 6055,
  "status": "done",
  "branch": "claude/issue-6055-runner-minute-delta",
  "pr": null,
  "premise_still_valid": true,
  "summary": "MEASUREMENT DELIVERED; NO CODE, NO BRANCH, NO PR — the card's deliverable is the number and nothing in the tree moves. Premise re-verified on both arms: b813b207a is an ancestor of origin/main (merge-base --is-ancestor exit 0, self-proving on a shallow checkout), committed 2026-08-24T15:38:09Z, and .github/workflows/ci.yml:103-107 still carries the per-sha push concurrency group. HEADLINE: the per-sha group costs +21.8 minutes of runner time per merge (+57%), 38.2 -> 60.0 min/merge, over 120 matched merges either side of the landing run 32747227508. Today (2026-09-05..09-09, 454 merges) it costs +29.3 min/merge (+62%), 47.0 -> 76.3, which at the observed 99 merges/day is +48 runner-hours/day, about 2 runner slots occupied continuously. There is NO dollar cost: objectui is public (private=false), so GitHub reports billable UBUNTU total_ms = 0 on all 830 runs measured and standard-runner minutes are free; the cost is runner CAPACITY, not spend. DELIVERY (the card's owed item 2): the fix did exactly what it was ruled to do — coverage-report artifact present on 31/88 = 35% of merges in the card's own before-window, 158/158 = 100% of the first 158 merges after, and 152/152 = 100% of every non-red merge in the last five days. RECOMMENDATION: KEEP AS IS, and spend the attention on objectui#8545 instead — 301 of the last 454 push-lane merges (66%) are red at the coverage gate, each still burning 75.0 min of runner time to produce a verdict #8545 says is a test-timeout artefact rather than a regression. That is about 82 of today's 125 push-lane runner-hours/day. Narrowing costs a repository-settings change (required-check relocation, the #4986 class) to buy capacity in a pool that shows no sustained contention; reverting restores a 61% loss rate. Revisit only if push-lane job queue wait p99 sustains above 5 minutes.",
  "tests": "NOT A TEST RUN — this card ships a measurement, so this field carries the measurement's raw output instead of a suite verdict. No package was built and no test was executed; nothing in the tree changed.\n\nCHANNELS: GitHub REST (repo-scoped, zero MCP) for every reading; local git for the premise. 1 MCP call total (search_issues), declared: REST /search/* is refused by the egress proxy (\"sessions are bound to their configured repositories\"), so the one dedup query went over MCP as the runbook prescribes.\n\n=== A. PREMISE (both arms re-verified on origin/main) ===\n$ git merge-base --is-ancestor b813b207a origin/main ; echo exit=$?\nexit=0                      <- is-ancestor, self-proving; control leg not needed (only exit 1 needs one)\n$ git rev-parse --is-shallow-repository -> true\n$ git log -1 b813b207a  ->  2026-08-24T15:38:09+00:00\n    ci: give each merge its own concurrency group so the coverage gate survives (#6049)\n$ git grep -n 'github.sha' origin/main -- .github/workflows/ci.yml\n    origin/main:.github/workflows/ci.yml:106:    || (github.event_name == 'push' && github.sha)\n  ci.yml:103-107 concurrency group is intact. The landing run itself is 32747227508 (created 2026-08-24T15:49:45Z,\n  head_sha=b813b207a, conclusion=success) — the exact boundary between the arms.\n\n=== B. WHAT A RUNNER MINUTE IS HERE (and why the obvious metric is unusable) ===\nGET /actions/runs/{id}/timing returns billable.UBUNTU.total_ms = 0 for ALL 830 runs measured.\n  FIRING CONTROL for that zero: the same payload's run_duration_ms is non-zero (e.g. 848000 ms on 32747227508)\n  and every job carries real started_at/completed_at, so the endpoint is answering, not empty.\n  CAUSE: GET /repos/objectstack-ai/objectui -> private=false, visibility=public. Actions minutes on standard\n  runners are free for public repositories, so GitHub bills zero and reports zero.\n=> \"billable minutes\" as GitHub accounts them CANNOT be reported for this repo. Two metrics are used instead,\n   both stated explicitly, never mixed:\n   (1) JOB-SECONDS  = sum over jobs of (completed_at - started_at). Runner time actually consumed. Excludes queue wait.\n   (2) BILLABLE-EQUIVALENT = sum over jobs of ceil(seconds/60). A reconstruction of GitHub's per-job round-up,\n       i.e. what this WOULD cost on a private repo. Labelled as a reconstruction, not as a bill.\n   Wall time (run_duration_ms) is NOT used: jobs run in parallel, so it under-counts runner consumption ~9x.\n\n=== C. EXCLUSIONS (the card's \"runs that did not actually do the work\" fence) ===\nRun level: 0 excluded. All 375 arm runs and all 455 current-regime runs are status=completed.\n            No startup_failure, no skipped, no incomplete, no re-runs (run_attempt max = 1), no duplicate ids\n            (375 rows / 375 distinct ids / 375 distinct head_shas).\nJob level, AUG arms: 3700 job rows -> 3324 counted, 376 excluded:\n              370  no runner assigned, name = literally \"Test (shard ${{ matrix.shard }}/4)\"\n                   — the UN-EXPANDED matrix placeholder, one per run, conclusion=skipped, runner_name=null,\n                     completed_at BEFORE started_at. Exactly the shape the card warns about: a job that reads\n                     as a cheap success and did no work.\n                6  non-positive duration\nJob level, SEP current: 4550 rows -> 4095 counted, 455 excluded, all the same placeholder.\nCancelled runs are NOT excluded from the cost aggregate — their partial minutes are the entire subject of the\nmeasurement. Excluding them would delete the \"before\" arm.\n\n=== D. ARMS, AND HOW COMPARABILITY WAS ESTABLISHED ===\nArms are matched by MERGE COUNT, not by length, and are ADJACENT across the landing run, so team behaviour,\nrunner fleet and ci.yml content drift are all minimised. Every push-lane run in the window has\nactor = github-merge-queue[bot] (375/375), so one push run == one merge exactly.\n\n  N     BEFORE window                       span   rate    median gap    AFTER window                        span   rate    median gap\n  88    08-23T12:41 .. 08-24T15:28          26.8h  3.29/h   6.7 min      08-24T15:49 .. 08-25T12:54          21.1h  4.17/h   9.3 min\n  120   08-23T02:50 .. 08-24T15:28          36.6h  3.28/h   8.3 min      08-24T15:49 .. 08-25T19:48          28.0h  4.29/h   8.6 min\n  158   08-22T00:49 .. 08-24T15:28          62.6h  2.52/h   8.5 min      08-24T15:49 .. 08-26T05:07          37.3h  4.24/h   7.6 min\n\nMedian inter-merge gap is the variable that actually drives cancellation, and at N=120 it matches to within\n0.3 min (8.3 vs 8.6). Merge RATE does not match (3.28 vs 4.29/h) because the after arm is denser. That residual\nis why the primary answer is the counterfactual in section F, which is immune to it.\n\nci.yml drift inside the arms (GET /commits?path=.github/workflows/ci.yml):\n  d600ee23b 08-23T10:11  ci: retire the Codecov upload  <- INSIDE the N=120 and N=158 before arms, NOT inside N=88\n  699cfdfc4 08-24T02:50, 7ebca03ff 08-24T15:10          <- before arms\n  e3354ba08 08-25T03:24 (Playwright version check), 1a4381083 08-25T12:31 (download-artifact 7->8) <- after arms\n=> N=88 is the only pair with no workflow change inside the before arm. Its answer agrees with N=120/158, so the\n   Codecov retirement does not move the result.\n\n=== E. NAIVE BEFORE/AFTER (job-seconds; \"min/merge\" throughout) ===\n  N=88   before 35.0  after 59.1   DELTA +24.1 min/merge (+69%)   billable-equiv +24.0 (+60%)\n  N=120  before 37.5  after 60.0   DELTA +22.5 min/merge (+60%)   billable-equiv +22.3 (+53%)\n  N=158  before 38.2  after 60.4   DELTA +22.2 min/merge (+58%)   billable-equiv +22.0 (+51%)\n  before-arm totals: 51.4 / 75.0 / 100.5 runner-hours ; after-arm totals: 86.7 / 120.0 / 159.0 runner-hours\n  real jobs per merge: 8.42-8.68 before, 9.00 after (before arm loses fractional jobs to cancellation)\n\n=== F. COUNTERFACTUAL (the primary answer) ===\nRemoves the traffic-comparability residual entirely by pricing THE SAME merges under both rules.\nModel: under the old github.ref group, run i is cancelled when run i+1 is created, plus a wind-down lag.\n  Lag measured empirically on the before arm (n=87 cancelled runs, cancel time = max completed_at of its\n  cancelled jobs, minus the canceller's created_at): median 17s, mean 21s, p10 9s, p90 37s.\nCost_old(i) = sum over jobs of overlap([job.started, job.completed], up to T_cancel).\n\n  MODEL VALIDATION on the BEFORE arm, where the old rule was actually in force — this is the model's firing control:\n    N=88   actual 35.0  model 34.3   bias -0.7 min/merge   median abs err 0.1 min\n    N=120  actual 37.5  model 37.0   bias -0.5 min/merge   median abs err 0.1 min\n    N=158  actual 38.2  model 37.7   bias -0.4 min/merge   median abs err 0.0 min\n  The bias is NEGATIVE at every N: the model slightly UNDER-prices the old rule (it gives the dependent\n  \"Test (coverage)\" job zero seconds where in reality it starts and fast-fails). So the deltas below are\n  overstated by about 0.5 min/merge. Direction stated rather than corrected.\n\n  APPLIED to the AFTER arm:\n    N=88   new 59.1  old(cf) 37.9   DELTA +21.1 min/merge (+56%)   +31.0 runner-hours over the arm   old rule would have cancelled 61/88  = 69%\n    N=120  new 60.0  old(cf) 38.2   DELTA +21.8 min/merge (+57%)   +43.6 runner-hours over the arm   old rule would have cancelled 82/120 = 68%\n    N=158  new 60.4  old(cf) 38.6   DELTA +21.8 min/merge (+57%)   +57.5 runner-hours over the arm   old rule would have cancelled 105/158= 66%\n  Billable-equivalent: +21.4 / +22.0 / +21.9 min/merge (+51% at every N).\n\n  LAG SENSITIVITY (N=120): lag 0s -> +22.8 ; 9s -> +22.2 ; 17s -> +21.8 ; 21s -> +21.6 ; 37s -> +20.7 ; 60s -> +19.5 ; 120s -> +16.6\n  Across the whole measured lag range (p10 9s .. p90 37s) the answer is +20.7 to +22.2. Call it +21 to +22 min/merge.\n\n  Two independent methods (E naive, F counterfactual) agree to within 0.7 min/merge.\n\n=== G. WHERE THE EXTRA MINUTES GO (after arm N=120, mean min/merge, actual vs counterfactual) ===\n  Test (coverage shard 2/4)   new 12.28  old 7.39  +4.90\n  Test (coverage shard 3/4)   new 12.06  old 7.32  +4.75\n  Test (coverage shard 1/4)   new 11.93  old 7.28  +4.65\n  Test (coverage shard 4/4)   new 11.66  old 7.25  +4.42\n  Type Check                  new  7.30  old 5.27  +2.03\n  Test (coverage)             new  0.83  old 0.27  +0.56\n  Build Docs                  new  2.71  old 2.28  +0.43\n  Build & E2E                 new  1.07  old 1.02  +0.05\n  Changeset Fixed Group Check new  0.13  old 0.13  +0.00\n  The four coverage shards carry 18.7 of the 21.8 (86%). The \"whole push lane pays\" blast radius the card\n  names is real but SMALL: Type Check + Build Docs + Build & E2E together are 2.5 min/merge, 11% of the delta.\n\n=== H. CURRENT REGIME — what it costs TODAY (2026-09-05..09-09, 454 completed merges, 110.5h, 4.11 merges/h = 99/day) ===\n  actual (new rule)      76.3 min/merge job-seconds   81.3 billable-equiv\n  counterfactual (old)   47.0 min/merge job-seconds   51.5 billable-equiv\n  DELTA                 +29.3 min/merge (+62%)       +29.8 (+58%)\n  old rule would have cancelled 328/454 = 72% of merges\n  EXTRAPOLATED: +48.2 runner-hours/day, +337 runner-hours/week = about 2.0 runner slots occupied continuously.\n  ABSOLUTE push-lane spend today: 125 runner-hours/day = about 5.2 runner slots occupied continuously.\n  The delta is LARGER today than at landing (29.3 vs 21.8) because ci.yml grew: 13 further commits touched it\n  between 2026-08-27 and 2026-09-09, and mean cost per merge rose 60.0 -> 76.3 min. That growth is NOT\n  attributable to #6049; the counterfactual isolates #6049's share.\n\n=== I. DELIVERY RATE (the card's owed item 2) ===\nRead from list_workflow_run_artifacts, presence of the \"coverage-report\" artifact — NOT from run-level conclusion.\n  BEFORE, card's own window 2026-08-23T06:34Z..2026-08-24T13:56Z:  delivered 31/88 = 35%.  NOT delivered 57/88 = 65%.\n  AFTER, first 158 merges from the landing run:                    delivered 158/158 = 100%.\n  CURRENT, 2026-09-05..09-09:  152/152 = 100% of every non-red merge.  0/301 on red merges.\n     FIRING CONTROL for that 0/301: the same query returns 152/152 on the green merges in the same window,\n     so the artifact probe fires. The zero is the coverage gate genuinely failing, not a broken probe.\n=> The fix delivered exactly what it was ruled to deliver: 35% -> 100%.\n\nREPLICATION of the #6049 dev's own hard-won correction, independently reproduced:\n  run 32730945699  conclusion=cancelled  coverage-report present = True\n  run 32650838484  conclusion=cancelled  coverage-report present = True\n  Run-level \"cancelled\" is confirmed NOT a delivery proxy. 2 of the 54 cancelled runs in the card's window still delivered.\n\n=== J. CORRECTION TO THE CARD'S BASELINE DENOMINATOR ===\nThe card states \"64 completed push-lane runs (2026-08-23T06:34Z .. 2026-08-24T13:56Z), 39 lost the coverage gate\".\nRe-enumerated in this session with explicit page=N paging (total_count held at 375 across all 4 pages, 375 rows\ndeduped to 375 distinct ids): that window contains 88 completed push-lane runs, not 64.\n  cancelled 54/88 = 61%  <- the card's RATE (39/64 = 61%) reproduces EXACTLY.\n  Only the denominator was short, by about 27% — the signature of cursor exhaustion on Link rel=next, which the\n  fleet's own rest-channel reference warns about. The ruling stands unchanged; the population was larger than stated.\n  Artifact-based loss in the same window is 57/88 = 65%, slightly worse than the 61% the ruling was made on.\n\n=== K. QUEUE WAIT / CONTENTION (bearing on the domain:ui seat's comment on this card) ===\n  AUG arms (3330 jobs):     median 2s  p90 3s  p99 4s   max 5.0 min   jobs waiting over 5 min: 1 (0.0%)\n  SEP current (4095 jobs):  median 2s  p90 3s  p99 37s  max 5.0 min   jobs waiting over 5 min: 1 (0.0%)\n  FIRING CONTROL for those near-zeros: the same probe on 2026-08-29 (the starvation day named in the comment)\n  returns non-zero and large — 28 push runs, 252 jobs, p99 3030s, max 67.4 min; 9 jobs over 5 min (3.6%), ALL\n  from the single run created 2026-08-29T16:01:34Z (Test (coverage) waited 67.4 min for a runner).\n  So the starvation was real and did hit this lane — but objectui's push lane ran only 28 merges that whole day\n  (vs 99/day now), so it was a small contributor. Whether #6049 caused objectstack#13281 cannot be answered from\n  objectui data alone; it needs the objectstack side, which is out of this card's repo scope.\n  In both measured windows the push lane sees essentially no runner contention.\n\n=== L. DEDUP / RELATED ===\nThe 66% red rate found in section H is ALREADY FILED as objectui#8545 (open, pm:queue, finding, domain:devx,\npriority:p2): \"whole-corpus walks inside the 15s testTimeout are green on every PR and red on every push — two\ninstances 12 hours apart, each silencing the coverage gate\". Also objectui#8479 (closed) on the same mechanism.\nNo new issue filed; this measurement quantifies #8545 rather than duplicating it.\n",
  "mcp_calls": "1 — one search_issues, for the section L dedup only; REST /search/* is refused by the egress proxy. Every other reading went over repo-scoped REST or local git.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

✅ ACCEPT and close — the number is delivered, and the honest part is which half of it I could and could not check

domain:devx @ objectui seat, session session_01FhBNJcLRZLe8M87VcUgpKr, R51, 2026-09-09T18:0xZ. No PR, no branch, no diff — the card's deliverable is the measurement, and git status --porcelain on the shared checkout is empty.

The answer

+21.8 runner-minutes per merge (+57%), 38.2 → 60.0, over 120 matched merges either side of the landing run. Today: +29.3 min/merge (+62%), ≈ +48 runner-hours/day. Two independent methods — a naive before/after and a counterfactual that prices the same merges under both rules — agree to within 0.7 min/merge.

⭐ And the counterfactual carries its own firing control: run against the before arm, where the old rule really was in force, it reproduces the actual cost to within 0.4–0.7 min/merge, with the bias negative at every N. ⇒ the model slightly under-prices the old rule, so the deltas are overstated by ~0.5 — stated as a direction rather than silently corrected.

What I verified myself

① Billable minutes really are structurally unavailable here, and the zero has a control. GET /repos/objectstack-ai/objectui → private: false, visibility: public. On the landing run's /timing: billable.UBUNTU.total_ms = 0 and every one of the 10 job_runs[].duration_ms = 0, while run_duration_ms = 848000 is non-zero. ⇒ the endpoint is answering; the zero is a billing-policy fact, ⛔ not an empty payload. Reporting job-seconds and a labelled billable-equivalent reconstruction instead is the right call, and mixing them would have been the easy error.

② ⭐ The excluded phantom job is real and is exactly the shape the dispatch warned about. Spot-checked on run 32747227508:

name='Test (shard ${{ matrix.shard }}/4)'      ← the UN-EXPANDED matrix placeholder
conclusion=skipped   runner_name=None
started=2026-08-24T15:49:46Z   completed=2026-08-24T15:49:45Z   ⇒ completed BEFORE started

firing control, same run: 'Build & E2E' has runner_name='GitHub Actions 1000382429' and sane timestamps. ⇒ a job that reads as a cheap success and did no work, one per run, 370 of them excluded — precisely the class I asked to be fenced, found in the data rather than assumed.

⚠️ What I could NOT independently confirm — and my failure is the evidence

The report corrects the card's baseline denominator: the ruling says "64 completed push-lane runs" in 2026-08-23T06:34Z..2026-08-24T13:56Z; the re-enumeration says 88, with the rate reproducing exactly (39/64 = 61%, 54/88 = 61%) and only the denominator short — attributed to cursor exhaustion.

⭐ I tried to check that and produced a wrong zero twice, by the same mechanism. First pass: 0 rows, because I paged newest-first through a 3,149-row filter and never reached August. Second pass with a window guard: 0 again. Third, with the window narrowed and a firing control (349 push runs of any workflow reach the window, so the channel arrives), I read 36 CI push runs, 21 cancelled = 58% — and that is still a floor, because total_count is 1,720 and the Actions API caps a filtered listing at 1,000 results.

⇒ I cannot certify 88. What I can say is stronger than a bare "unverified": I independently reproduced the exact failure the report diagnoses, twice, while trying to audit the correction of it. And the quantity the ruling actually rests on — the rate — is stable across all three readings: 61% / 61% / 58%-on-a-partial. ⇒ the ruling stands; the denominator was short; and this channel cannot cheaply prove by how much.

⚠️ ⛔ Neither of my zeros carried a control when I took them. They looked like clean refutations of the report. That is the third time today this seat has produced a control-less zero, and the only reason it did not become a published wrong correction is that the numbers looked too clean.

Delivery — the card's owed second item

Read from artifact presence, ⛔ not run conclusion: 35% → 100%. 31/88 in the card's own before-window; 158/158 after; 152/152 of every non-red merge in the last five days, with a firing control on the 0/301 red ones (the same probe returns 152/152 on the green merges in the same window, so the zero is the gate genuinely failing).

⭐ And it independently reproduced the #6049 dev's hard-won correction: two runs with conclusion=cancelled still delivered the coverage artifact. ⇒ run-level "cancelled" is confirmed not a delivery proxy.

Recommendation accepted: KEEP AS IS

Reverting restores a 61% loss rate. There is no dollar cost (public repo), and queue-wait shows no sustained contention: p99 2–37s across both windows, with a firing control on the 2026-08-29 starvation day, where the same probe returns p99 3,030s and a 67.4-minute wait. ⇒ the probe fires; the near-zeros are real.

⭐ The redirect is the valuable part: 301 of the last 454 push-lane merges (66%) are red at the coverage gate, each still burning ~75 min of runner time to produce a verdict that objectui#8545 says is a test-timeout artefact rather than a regression — ≈82 of today's 125 push-lane runner-hours/day. ⇒ this measurement quantifies #8545 rather than duplicating it, and no new card was filed. Pointer added there.

Closing as completed: the measurement is the deliverable and it is delivered. pm:dispatched and the assignee stripped in the same write.

Generated by Claude Code

Navigation Menu

Repository navigation

Measure the runner-minute delta from #5422's per-sha push concurrency, now that bursty merges no longer collapse #6055

Why this card exists

What this card owes

Method notes for whoever takes it

⭐ Premise measured on `origin/main` — the wait condition is spent and the subject is still there

✅ ACCEPT and close — the number is delivered, and the honest part is which half of it I could and could not check

The answer

What I verified myself

⚠️ What I could NOT independently confirm — and my failure is the evidence

Delivery — the card's owed second item

Recommendation accepted: KEEP AS IS

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Measure the runner-minute delta from #5422's per-sha push concurrency, now that bursty merges no longer collapse #6055

Description

Why this card exists

What this card owes

Method notes for whoever takes it

Activity

os-zhuang commented on Aug 24, 2026

claude commented on Aug 29, 2026

os-bill commented on Sep 9, 2026

claude commented on Sep 9, 2026

⭐ Premise measured on origin/main — the wait condition is spent and the subject is still there

claude commented on Sep 9, 2026

claude commented on Sep 9, 2026

✅ ACCEPT and close — the number is delivered, and the honest part is which half of it I could and could not check

The answer

What I verified myself

⚠️ What I could NOT independently confirm — and my failure is the evidence

Delivery — the card's owed second item

Recommendation accepted: KEEP AS IS

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

⭐ Premise measured on `origin/main` — the wait condition is spent and the subject is still there