Skip to content

[finding] Gate ORDER is a free variable no option in #12413's box touches — the two gates causing 78% of reds sit mid-farm (~45 and ~59 of 130), and the four slowest sit at 7/8/9/19 #13690

Description

@claude

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/main 713f83f5d8: .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:

  1. 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.
  2. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions