Filed unassigned by the domain:devx @ objectstack execution seat (seat post #6023, session session_01Pk26oZ12t5N1hwGW1m1MgC), as the recorded side-observation of the #12413 measurement dispatch. ⛔ Ungraded, ⛔ unclaimed, ⛔ no domain:*.
⭐ Filed separately rather than folded into #12413's decision box, deliberately — see "Why this is not part of #12413" below. That separation is the point of the card.
The observation
Lint & Repo Gates runs 130 gate steps sequentially in one job and aborts at the first non-zero exit (re-derived at origin/main713f83f5d8: .github/workflows/lint.yml lines 111–3389, 130 declared steps, 0 real continue-on-error — the single textual hit at line 2674 is a comment — and 0 steps carrying an if:). So the unmeasured tail is exactly 130 − position.
Gate ORDER is a free variable, and no option currently in #12413's box touches it. Two measurements, over the workflow's entire life (23,475 runs, 2026-01-19 → 2026-08-31):
| reading | value |
|---|
| the two gates causing 78% of current-shape reds sit at positions | ~45 and ~59 of 130 |
| ⇒ which is precisely why the measured tail is | ~65 (mean 66.3 / median 61) |
| the four slowest gates sit at positions | 7, 8, 9, 19 |
| ⇒ the first 10% of gates burn | 36% of the job's wall clock |
⇒ Two independent, opposite-direction observations about the same ordering:
- For tail size: the dominant failure sources sit mid-farm. Moving them earlier would shrink the unmeasured tail on the majority of reds — without
continue-on-error, without splitting the job, and without touching the merge queue's required contexts. - For wall clock: the farm is heavily front-loaded with slow gates. A run that is going to go red pays the four most expensive gates first, on every run including the ~95% that are green.
These two pull in the same direction on failure-position and possibly opposite directions on cost — which is exactly why it needs pricing rather than a guess.
⛔ What is NOT established
- ⛔ Not established that the current order is arbitrary. It may encode real step dependencies (a gate that consumes a previous step's build output or written file). This was not verified, and it is the whole cost of the option.
- ⛔ Not established that reordering is cheap. If dependencies exist, the reorder is a real refactor of the farm, not a permutation of a list.
- ⛔ No recommendation is offered here. This card records a lever and its two measurements; ⛔ it does not argue for pulling it.
Why this is not part of #12413
#12413's ruling (maintainer, 2026-08-26, batch 4, 「决策箱第 4 批 同意」) adopted option C precisely because A and B were unpriced: "neither is paid for until the cost is a number instead of a question mark."
⭐ Ordering is a new option with its own unpriced cost (the dependency question above). Folding it into that box now would repeat exactly the mistake the ruling corrected — choosing before the cost is a number. The #12413 dev raised this as an open question and recommended keeping it out; this seat agrees and is recording it instead.
⇒ If ordering is ever taken up, it needs the same treatment C got: measure the dependency structure first, then price it.
Provenance
Every figure above comes from the #12413 measurement (deliverable comment on that card), whose method was validated four ways and which reports its own coverage gaps and undercounts. The 130-step count, the 0 continue-on-error, and the comment at line 2674 were re-verified independently by this seat against origin/main.
Refs: #12413 (the measurement and its box), #12173 (source card), #12211 (adjacent, deliberately separate).
Generated by Claude Code
Filed unassigned by the
domain:devx @ objectstackexecution seat (seat post #6023, sessionsession_01Pk26oZ12t5N1hwGW1m1MgC), as the recorded side-observation of the #12413 measurement dispatch. ⛔ Ungraded, ⛔ unclaimed, ⛔ nodomain:*.⭐ Filed separately rather than folded into #12413's decision box, deliberately — see "Why this is not part of #12413" below. That separation is the point of the card.
The observation
Lint & Repo Gatesruns 130 gate steps sequentially in one job and aborts at the first non-zero exit (re-derived atorigin/main713f83f5d8:.github/workflows/lint.ymllines 111–3389, 130 declared steps, 0 realcontinue-on-error— the single textual hit at line 2674 is a comment — and 0 steps carrying anif:). So the unmeasured tail is exactly130 − position.Gate ORDER is a free variable, and no option currently in #12413's box touches it. Two measurements, over the workflow's entire life (23,475 runs, 2026-01-19 → 2026-08-31):
⇒ Two independent, opposite-direction observations about the same ordering:
continue-on-error, without splitting the job, and without touching the merge queue's required contexts.These two pull in the same direction on failure-position and possibly opposite directions on cost — which is exactly why it needs pricing rather than a guess.
⛔ What is NOT established
Why this is not part of #12413
#12413's ruling (maintainer, 2026-08-26, batch 4, 「决策箱第 4 批 同意」) adopted option C precisely because A and B were unpriced: "neither is paid for until the cost is a number instead of a question mark."
⭐ Ordering is a new option with its own unpriced cost (the dependency question above). Folding it into that box now would repeat exactly the mistake the ruling corrected — choosing before the cost is a number. The #12413 dev raised this as an open question and recommended keeping it out; this seat agrees and is recording it instead.
⇒ If ordering is ever taken up, it needs the same treatment C got: measure the dependency structure first, then price it.
Provenance
Every figure above comes from the #12413 measurement (deliverable comment on that card), whose method was validated four ways and which reports its own coverage gaps and undercounts. The 130-step count, the 0
continue-on-error, and the comment at line 2674 were re-verified independently by this seat againstorigin/main.Refs: #12413 (the measurement and its box), #12173 (source card), #12211 (adjacent, deliberately separate).
Generated by Claude Code