[Decision] `Lint & Repo Gates` aborts at the first failing gate — 120 sequential steps, no continue-on-error, so one red hides an unmeasured tail

[yinlianghui]

Split out of #12173 by the domain:devx @ objectstack seat (#6023). That card carried two independent findings; its ① is dead (already fixed by #11934, verified at source — see #12173). This is ②, which is untouched and real. ⛔ This seat picks among none of the options.

Dispatch ruling on #12173 put ② out of the dev's scope precisely because it changes the repo's CI contract, so it was re-measured and reported, never acted on.

The finding

Lint & Repo Gates runs its gates sequentially in one job and aborts at the first non-zero exit. A single red is therefore not "one gate to fix" — it is one gate to fix plus an unknown number that never ran.

Re-derived on origin/main at b000ab59bb (the filing-day numbers were stale):

	filing day	measured now
named steps in the job	—	120 (lint.yml:111-3111)
real continue-on-error keys inside the job	—	0 (the single textual hit at :2451 is a comment)
gate steps after the specimen's failure point	46	10

The specimen: check:where-matcher now sits at :2768 and the ObjectQL double limit gate — the step that failed on the incident this was filed from — immediately follows at :2789.

⚠️ The 46 → 10 correction matters for pricing this, and it cuts against urgency: on that specific failure the unmeasured tail was 10 gates, not 46. The general shape stands; the worst case is bounded by where in the 120 the failure lands.

四维分析

① 实际业务需求. 拉力是真实但间歇的:每次红都留下一条未测量的尾巴,而 PR 作者读到的是「一个门禁要修」。⚠️ 但重新测出的 10(而非 46)说明单次事故的代价比立卡时以为的小,而代价随失败位置变化 —— 落在第 5 步和落在第 115 步完全是两回事。没有人测过失败位置的分布。

② 平台长远合理性. 这一维指向「一次运行报告全部失败」:一个门禁农场的价值在于它告诉你全部欠什么,而不是最先撞上的那一件。⚠️ 反方向也真实:continue-on-error 会让 job 在有真实失败时仍然报绿,除非另加一个汇总步骤 —— 那本身就是新机制,而且是削弱门禁方向的改动,按协议属人工地板。

③ 避免 AI 写代码犯错. 强烈指向拆分或全量报告:当前形状下,dev 修好第一个红、推送、再撞第二个红,一次事故要烧掉多个 CI 往返 —— 而每一轮都让人以为自己已经完整了。这正是本车道反复定价高于「缺一个检查」的失效模式。

④ 创业阶段不扩散需求. 拆成并行 job 会增加 runner 用量与维护面(120 步如何分组、谁维护分组、合并队列的必需检查名单要跟着改)。⚠️ 动的是维护者的预算,并且改的是合并队列的 required contexts —— 这两条都在人工地板上。

⭐ 四维不同向:②③ 指向改,①④ 指向先测分布再说。且无论走哪条,都触及「门禁削弱」与「合并队列必需检查」两个人工地板项。

Options

• A. continue-on-error + 汇总步骤 —— 让全部 120 步都跑完,末尾一步汇总并在有任一失败时退出非零。⚠️ 中途每一步都显示绿,只有汇总步是真判据 —— 这本身就是一个「聚合读数」,而本仓的既有纪律是放行认门禁 job 的结论、不认聚合。要落地必须先解决这个矛盾。
• B. 拆成 N 个并行 job —— 每个 job 内部仍 fail-fast,但彼此独立,一次运行能报出 N 条独立的红。成本:runner 用量、分组维护、以及合并队列 required contexts 名单要同步改。
• C. 什么都不改,先测失败位置分布 —— 用历史运行统计「失败步在 120 中的位次」,得出未测量尾巴的真实期望值,再决定 A/B 是否值得。最便宜,且是唯一能把①的问号变成数字的选项。
• D. 维持现状 —— 记录代价,接受它。10 步的尾巴不足以支付 A 或 B 的复杂度。

⛔ 本座位不背书任何一个。dev 的建议是把 ② 单独立卡带上今天的数字,已照办。

Not this card

⛔ 不是 #12211(合并队列快照状态);分诊评论已裁定两者分开。⛔ 不是 #12173 的 ①,那半已由 #11934 修复。

Refs: #12173(来源卡,其 ① 已死)· #11934 / a187fe612b(修掉 ① 的提交)· #12211(相邻但不同)

[os-steve]

Maintainer ruling recorded — Option C adopted: measure the failure-position distribution first

Provenance: maintainer, 2026-08-26, live PM chat (decision-inbox batch 4, skills seat session session_01JANH3y7qe3MD8aLaLXci8N), verbatim: 「决策箱第 4 批 同意」 — accepting this card's presented batch-4 recommendation, which was C.

What this rules:

1. No change to the Lint & Repo Gates job now — no continue-on-error, no job split. Both A and B touch manual-floor territory (gate-weakening shape / merge-queue required-contexts churn / runner budget) and neither is paid for until the cost is a number instead of a question mark.
2. The work is a measurement: over historical runs of the job, derive the distribution of the first-failing step's position among the ~120 sequential steps, and from it the expected size of the unmeasured tail per red run (the card's own 46 → 10 correction showed the single-incident estimate can be off by 4×). Deliverable = the numbers on this card, plus the re-derived step count at measurement time.
3. After the numbers land, the card returns to the decision box for the A / B / D choice with ① priced — the measurement itself changes no CI contract and needs no maintainer floor.

State: needs-user-decision → pm:queue in the same stroke (domain:devx lane dispatches; the measurement reads workflow run history only — no gate edits are in scope for that dispatch).

---

Generated by Claude Code

[claude]

Claim + Dispatch — R34 · ⚠️ measurement-only, no code change is in scope

domain:devx PM seat (seat post #6023), session session_01Pk26oZ12t5N1hwGW1m1MgC.
Branch: claude/issue-12413-gate-failure-position-measurement — create it only if you end up with files to commit. The primary deliverable of this dispatch is numbers posted on this card, not a PR.

---

Zone 1 — RULING (⛔ not re-litigable, quoted verbatim, not translated)

维护者,2026-08-26,decision-inbox batch 4,verbatim「决策箱第 4 批 同意」 — Option C adopted:

1. No change to the Lint & Repo Gates job now — no continue-on-error, no job split. Both A and B touch manual-floor territory (gate-weakening shape / merge-queue required-contexts churn / runner budget) and neither is paid for until the cost is a number instead of a question mark.
2. The work is a measurement: over historical runs of the job, derive the distribution of the first-failing step's position among the ~120 sequential steps, and from it the expected size of the unmeasured tail per red run (the card's own 46 → 10 correction showed the single-incident estimate can be off by 4×). Deliverable = the numbers on this card, plus the re-derived step count at measurement time.
3. After the numbers land, the card returns to the decision box for the A / B / D choice with ① priced.

(domain:devx lane dispatches; the measurement reads workflow run history only — no gate edits are in scope for that dispatch.)

Binding consequences:

1. ⛔ Do not edit .github/workflows/lint.yml. Not to add continue-on-error, not to split the job, not "while I'm here". The whole point of this ruling is that the change is unpriced.
2. The deliverable is a comment on this card carrying the distribution, the derived expected tail size, and the step count re-derived at measurement time.
3. This card goes back to the decision box afterwards — so write the numbers for a reader who will choose among A/B/D, not for a reader who already agrees.

Zone 2 — PM mechanism assumptions (⚠️ measure them; falsifying one is a good outcome)

• A2.1 — I assume the first-failing step's position is recoverable from workflow run history at useful scale. It may not be: job logs age out, and this seat has measured that the job-log tail window truncates the failing assertion. If the history you can actually reach is too thin to support a distribution, say so with the number of runs you could read — "we cannot price this from history" is a real and reportable answer that changes the decision, and it is much better than a distribution built on six runs presented as if it were solid.
• A2.2 — I assume step position is stable enough across the window that positions from older runs are comparable to today's ~120. The card already shows this moving (the specimen slid, and the tail estimate went 46 → 10). Report the step count at both ends of your window, and if positions are not comparable, say what you normalized and why.
• A2.3 — I assume "first failing step" is unambiguous in the logs. If a run has several failures, or the abort point is not the first red, define your rule explicitly in the writeup.

Zone 3 — suggested route (optional; your judgment governs)

1. Enumerate historical runs of the Lint & Repo Gates job over as long a window as the API will actually give you; record how many you got and how many you could not read.
2. For each red run, locate the first failing step and its ordinal position; derive the distribution and the expected number of steps that never ran.
3. Re-derive the current step count (the card's 120, from lint.yml) at measurement time.
4. Post it here as a table with the window, N, and the readings — including the ones you could not obtain.

⛔ Boundaries

• ⛔ No gate edits. No lint.yml changes.
• ⛔ Do not touch content/docs/releases/.
• ⛔ Never git stash — refs/stash is shared across every worktree of this repo.
• If you do produce committed artifacts (a script, a dataset), use a dedicated worktree and a draft PR; the numbers still go on this card.

---

Generated by Claude Code