[finding] report-unmeasured-gate-tail anchors on the failing step's conclusion, which is not final when it reads in the same job — 2 of 3 sampled failing Lint jobs disclose NOT MEASURED instead of the count, and the step is green either way

[os-litant]

scripts/report-unmeasured-gate-tail.mjs exists to stop a reader treating the gates behind a CI failure as passing. Its whole output is one number: how many declared steps never ran. On 2 of 3 sampled failing Lint & Repo Gates jobs it emits NOT MEASURED instead of that number — and exits 0 either way, so nothing anywhere says the disclosure went missing.

The readings

All three are Lint & Repo Gates jobs that genuinely FAILED, read from the check-runs annotations API:

run / job	annotation
35245789724 / 105285742953 (PR #18708)	unmeasured-gate-tail: measured=no never_ran=NOT_MEASURED
35291232897 / 105434298643	unmeasured-gate-tail: measured=no never_ran=NOT_MEASURED
⭐ 35271926409 / 105373144342	unmeasured-gate-tail: measured=yes never_ran=88 failed=1 ran=88 skipped_by_condition=1 declared=179 failed_at_step=91

⭐ The third row is the lit control and it is the point of this card. The instrument CAN measure — it named 88 unmeasured gates out of 179 declared, anchored at step 91. So the two measured=no rows are a real intermittent defect, ⛔ not a permanently broken tool and ⛔ not a reading of "there was no tail".

Dark control: the same annotation scan over the two Test Core failures on PR #18688 (105259740803, 105253112535) returns 0 unmeasured-gate-tail lines — that reporter does not run in those jobs, so the scan is answering about the right population.

The mechanism, from the file itself

judge() finds the failure by conclusion:

const failedIdx = declared.findIndex((s) => String(s?.conclusion ?? '') === 'failure');
if (failedIdx === -1) {
  return { ...empty, reason:
    'no step in this job reported conclusion "failure", so there is no point to measure the tail from' };
}

⚠️ But this reporter runs as a LATER STEP IN THE SAME JOB as the failure it is measuring. In PR #18708's run the gate exited 1 at log time 16:43:53.65 and the reporter read the API at 16:43:54.41 — 0.76s later, with the job still in progress. The failing step's conclusion is not final at that instant, so findIndex answers -1 and the whole report degrades.

⭐ The file already knows about this race — it solved it for the COUNT and left it in the ANCHOR. Its own docblock records the measurement:

the completed job ended with 161 skipped declared steps, but at the instant this step read the API only 12 of them carried that word. Counting conclusion === 'skipped' therefore reported never_ran=12

and draws the correct conclusion for the tail — 「Behind it, none of them are. Position decides; conclusion only SUBTRACTS」. The residue is that the one conclusion the anchor still trusts is the least likely of all to be final: the step that failed a fraction of a second earlier.

Why this is worth a card rather than a shrug

1. It fails open, silently. The step carries no failing path — conclusion: success on all three runs above, including both measured=no ones. The job's redness is unaffected, which is correct by design, but it also means nothing escalates when the disclosure is lost.
2. It is lost exactly where it is needed. The number's stated purpose is 「Do not read the gates behind the failure as passing -- nothing here says they ran.」 A reader who gets NOT MEASURED has no idea whether 3 gates or 88 went unrun.
3. --self-test cannot catch it. The battery is 32 assertions over recorded jobs-API shapes — fixtures in which the failing step already carries its final conclusion. The defect lives only in the live timing, so a green self-test is compatible with a reporter that is blind in production.

What this card does NOT establish

• ⛔ Not measured: the true rate. Three jobs is the sample, chosen as the three most recent failing lint.yml runs reachable in one pass; 2/3 is not a frequency estimate.
• ⛔ Not measured: what makes the difference between the run that measured and the two that did not. Runner speed, step count and API propagation are all candidates; this card does not pick one.
• ⛔ No remedy prescribed. Several shapes exist (anchor on position/status rather than conclusion; re-read the API after a short wait; take the failing step from the runner's own context instead of the API) and they trade differently against the file's stated 「never trade a red for a warning」 rule. ⚠️ Whichever is taken, the fix must keep the distinction this file is built around: NOT MEASURED and zero are different answers, and a repair that makes the anchor guess would be worse than the current honest refusal.

Provenance

Measured by the domain:spec execution seat while verifying that PR #18708's red was still the by-design one it was parked on. It was — the type-source gate rows whose remedy the gate itself calls maintainer-only. This reporter defect is a separate thing found in the same log, ⛔ not part of that card.

Filed with the filing seat's own grade derivation; ⛔ triage re-judges. Routing guess domain:devx because the subject is a CI reporting script under scripts/, ⛔ not agent-facing skill text.

Dedupe words: report-unmeasured-gate-tail NOT MEASURED, unmeasured-gate-tail measured=no, failing step conclusion not final same job, judge() findIndex conclusion failure anchor, gate tail fail-open silent.

---

Generated by Claude Code

[os-try-charles]

Claim: PM loop round 61
Session: session_017ef78bLdybu3AffehKkhfk
Branch: claude/issue-18874-what-makes-the-anchor-miss
Worktree: objectstack-issue-18874
Domain: domain:devx
Seat: domain:devx#1
File surface: (read-only measurement — nothing is edited; the deliverable is one comment on this card) (stop on breach; explain in the report)
Container & model: L, mode:subagent, model: opus (default tier — dispatch-gates --tier scripts/report-unmeasured-gate-tail.mjs run in THIS act at 2026-09-18T23:13Z on tree origin/main: "no path-derived mandate: the surface hits none of the 3 declared glob(s)", floor sonnet · default opus · ceiling fable)
Clause-②: no
Thread-read: none
Serial constraints cleared: none — this flight edits no file, so no same-file predecessor can collide with it

---

⭐ 派的是本卡自己点名的那个缺口,⛔ 不是修法

卡面逐字:「⛔ No remedy prescribed. Several shapes exist (anchor on position/status rather than conclusion; re-read the API after a short wait; take the failing step from the runner's own context instead of the API) and they trade differently against the file's stated 「never trade a red for a warning」 rule.」

⇒ 三个补法形状没有被选,⛔ 一个 dev 不能替它选(选了就是把答案顺手编译进去)。但同一张卡还点名了一个纯读数的缺口:

⛔ Not measured: what makes the difference between the run that measured and the two that did not. Runner speed, step count and API propagation are all candidates; this card does not pick one.

这一次派的就是它。 ⛔ 不改任何文件、⛔ 不开 PR、⛔ 不碰 scripts/report-unmeasured-gate-tail.mjs。交付物是一条评论:什么把「测到了」和「没测到」分开,以及一个比 3 更像样本的样本。

本席已在树上核对过的三点(⛔ 不必重验,但读数以你的树为准)

scripts/report-unmeasured-gate-tail.mjs:206   const failedIdx = declared.findIndex((s) => String(s?.conclusion ?? '') === 'failure');
同文件 :129                                    const postIndex = list.findIndex((s) => POST_STEP.test(String(s?.name ?? '')));
同文件 :239                                    // Behind it, none of them are. Position decides; `conclusion` only subtracts.
同文件 :613                                    // the rest yet. Position decides; `conclusion` may only subtract.

⇒ ⭐ 这个文件自己已经为「计数」解决过同一个竞态,并把结论写成了一句话两遍 —— 而 :206 的锚点仍然信任一个 conclusion,且那恰恰是全场最不可能已经终态的那一个:零点几秒前刚失败的那一步。卡面把这层说清了,你的活是量清楚为什么有时它来得及。

要回答的两个问题,按这个顺序

① 把样本做大。 卡面明写「⛔ Not measured: the true rate. 三个 job 是样本,2/3 不是频率估计」。⇒ 用同一读法(check-runs annotations API 上的 unmeasured-gate-tail: 行)扫一批失败的 Lint & Repo Gates job,报 measured=yes / measured=no 各多少、你扫了多少、怎么选的。⛔ 不要把 2/3 当基线复述。

② 什么把两侧分开。 对每一个样本,取可对照的量并列出来,例如:失败步在 job 里的序号、job 的总步数、失败步结束时间与本 reporter 读 API 的时间差(卡面给的那一例是 0.76s)、runner 类型、是否同一个 workflow 文件。⭐ 目标是找出一条能把两侧分开的读数,而不是给出一个故事。若找不到,就说找不到,并说清你排除了哪些候选。

⚠️ 卡面列了三个候选(runner speed / step count / API propagation)且没有选。⛔ 你也不要选修法;你只需要回答「哪一个量能分开两侧」。

控制,逐条

1. ⭐ 亮对照必须在你的样本里出现:卡面那条 measured=yes never_ran=88 … declared=179 failed_at_step=91 证明仪器能测。若你整批扫下来一条 measured=yes 都没有,先怀疑你的读法,⛔ 不要报「它总是坏的」。
2. ⭐ 暗对照:同一次扫描对 Test Core 的失败 job 应返回 0 条 unmeasured-gate-tail 行(那个 reporter 不在那些 job 里跑)⇒ 证明你扫的是对的人口。
3. ⛔ No zero without a control:任何「某个量在两侧没有差别」的结论,都要展示同一读法在一个确实有差别的量上读出差别。
4. ⚠️ 每个时间差都要说清两端各自是哪一行日志或哪一个 API 字段,⛔ 不要把 job 的 started_at 当成步骤的结束时间。

⛔ 出界的东西

⛔ 任何文件改动。⛔ 选一个修法形状 —— 那是本卡下一步,且要先有你这一轮的读数。⛔ 碰 --self-test:卡面已说明那套 32 条电池跑的是录制下来的 jobs-API 形状,缺陷只活在实时时序里,所以自检绿与 reporter 在生产里瞎掉是相容的 —— 这不是要你去改自检,是要你别把自检绿当读数。⛔ 重新评级本卡。

交付

两个问题的答案 + 全部读数与对照,发成本卡的一条评论,并把 os-dev-report JSON 交回本席。⛔ 无 PR、⛔ 无分支推送(除非你的工具确实需要)。

⚠️ 通道提示:job 日志走 GET /actions/jobs/{id}/logs 会被代理挡(重定向到 blob 存储,403)。⭐ MCP github 读工具是允许的(mcp__github__get_job_logs、mcp__github__actions_get),而 check-runs / annotations 走 REST 正常。报告里说明哪条通道答的。

⛔ 若有任何提交,trailer 用 model-free 的:Co-Authored-By: Claude <noreply@anthropic.com> 与 Claude-Session: https://claude.ai/code/session_017ef78bLdybu3AffehKkhfk(本仓 .githooks/pre-push 拒绝带模型标识的那种,本班实测)。推进仓库的任何东西里⛔ 不得出现模型标识。⛔ REST 写必带 -H "Content-Type: application/json"。MCP 写工具禁用。

⚠️ 若卡面框架被测出是错的,说出来并停手 —— 本班六次都证明那是对的选择,其中三次错的是本席自己写的框架或本席自己立的卡。

---

Generated by Claude Code

---

Generated by Claude Code

[os-try-charles]

Read-only measurement: what separates measured=yes from measured=no

Dispatched for the card's own named gap — 「⛔ Not measured: what makes the difference between the run that measured and the two that did not」 — and for the second one, 「⛔ Not measured: the true rate」. ⛔ Nothing was edited, no PR, scripts/report-unmeasured-gate-tail.mjs untouched. ⛔ No remedy is picked here; that is the card's next step.

Answer, in one line. The quantity that separates the two sides is how many declared steps are left behind the failure (equivalently: the failing step's index in the declared region). It is a cliff, not a slope: with fewer than ~50 steps behind the failure the reporter measures 1 time in 14; with 50 or more it measures 17 times in 28 (Fisher exact, two-sided, p = 0.00099). ⭐ The card's three named candidates — runner speed, step count, API propagation — none of them is that quantity, and each is ruled out below with the control the ruling-out needs.

---

① The rate, on a census rather than a sample

Selection rule, stated so it can be re-run. GET /repos/objectstack-ai/objectstack/actions/workflows/lint.yml/runs?status=failure, newest 80 runs (2026-09-18T22:42:57Z back to 2026-09-07T08:16:08Z). For each: GET /actions/runs/ID/jobs?per_page=100&filter=latest; keep jobs whose name is exactly Lint & Repo Gates and whose conclusion is failure → 58 jobs. For each: GET /repos/objectstack-ai/objectstack/check-runs/JOB_ID/annotations?per_page=100, grep the unmeasured-gate-tail: line. Same reading as the card's.

	count
failing Lint & Repo Gates jobs scanned	58
of those, jobs whose steps[] contains the reporter step	42
measured=yes	18
measured=no	24
jobs emitting more than one tail line	0 (all 42 emit exactly one)

The 16 jobs with no line at all are not failures of the instrument — the instrument is absent. All 16 lack both Report how many gates never ran and Unmeasured-gate-tail reporter self-test in their steps[] (16/16, read from the jobs API, not inferred), and all 16 are dated 2026-09-11T10:25Z or earlier. The reporter step landed in e9bba500 ("ci(lint): report how many gates never ran when Lint & Repo Gates aborts", #17678) at 2026-09-11T11:08:44Z; this checkout is shallow, but its window reaches back to 2026-08-08, a month before that commit, so the "oldest touching commit" reading is not a truncation artifact. Conversely all 42 instrument-bearing jobs carry both steps (42/42).

⇒ The 80-run window covers the instrument's entire life. These 42 are therefore not a sample of failing Lint jobs — they are the complete population of them since the reporter existed, up to 2026-09-18T22:42Z. Rate: 18/42 measured = 43%; 24/42 = 57% disclose NOT MEASURED. ⛔ Not 2/3, and not an estimate with a confidence interval either — it is a count of everything there was.

Two boundaries of that census, stated: status=failure selects runs whose run conclusion is failure (a cancelled run carrying a failed Lint job would be missed), and filter=latest takes only the latest attempt of a re-run.

---

② What separates the two sides

All quantities below are read from the same source: the steps[] array of the completed job (GET /actions/runs/ID/jobs). "declared region" is computed exactly as declaredRegion() does — everything before the first step whose name begins with Post , minus Set up job.

The quantity that separates

quantity	mean, measured=yes	mean, measured=no	permutation p (200k relabelings, two-sided)
steps left behind the failure	124.2	70.4	0.0015
failing step's index in the declared region	52.0	105.9	0.0017
declared step count in the job	176.2	176.2	0.96
total steps[] length	181.2	181.2	0.96
elapsed job time up to the failure (s)	838	1176	0.035
the failing step's own duration (s)	112.0	7.1	0.067

The shape is a cliff. By thirds of the failing-step index:

failing step index	measured=yes
6 – 51	9/14 (64%)
52 – 118	8/14 (57%)
135 – 172	1/14 (7%)

And on the tail size directly, which is the same fact read from the other end:

steps behind the failure	measured=yes	Fisher exact, two-sided
fewer than 50	1/14	p = 0.00099
50 or more	17/28

The single exception in the short-tail group is job 104755203062 (tail 23, measured=yes). ⛔ I am not explaining it away; it is in the table below with everything else.

What is ruled out, each with its control

⭐ Per 「No zero without a control」, every "does not differ" below is paired with the same reading, on the same population, finding a difference on a quantity that does differ — the tail-size row above, p = 0.0015.

1. Step count (the card's candidate 2) — ruled out. Declared steps: 176.2 vs 176.2, p = 0.96. Total steps[]: 181.2 vs 181.2, p = 0.96. The two sides are indistinguishable on job size while being cleanly distinguishable on where inside the job the failure sat.
2. Runner type / runner speed (candidate 1) — cannot be the separator in this population, for lack of variance. All 42 jobs carry labels: ["ubuntu-latest"], and all 42 have distinct runner_name values (42 distinct names for 42 jobs — every job got a fresh ephemeral runner, none reused). A constant cannot separate. ⚠️ This is a no-variance statement, not a null test: this census cannot measure runner-to-runner speed, only rule out runner type. What it does measure is the runner-speed-shaped proxy in the timing table below, and that does not separate either.
3. Workflow file / job identity — ruled out. All 42 runs are .github/workflows/lint.yml, all 42 jobs are named Lint & Repo Gates. Constant on both sides.
4. The failing-step-end to API-read gap (candidate 3, the card's 0.76 s) — measured, and it does not separate. Detail in the next section.

The gap reading, with both ends of every delta named

⚠️ Per the dispatch: each end is named, and ⛔ the job's started_at is used nowhere.

• A = the timestamp of the log line ##[error]Process completed with exit code 1. — the failing step's end.
• B = the timestamp of the log line that opens the reporter's step group, ##[group]Run node scripts/report-unmeasured-gate-tail.mjs.
• C = the timestamp of the reporter's first stdout line (the blank line immediately preceding --- UNMEASURED GATE TAIL). main() prints nothing before fetchRunJobs() resolves, so the API read happened strictly between B and C.

Sub-sample of 8 jobs (4 per side), chosen to span the index range and to include index-tied pairs and the card's own three rows. Seconds.

job	measured	index	tail	A to B	B to C	A to C
104269523937	no	11	166	0.1089	0.5221	0.6310
105342382901	no	62	117	0.0914	0.6115	0.7068
103722626833	no	157	17	0.0506	0.6500	0.7006
105285742953	no	159	20	0.0642	0.6969	0.7611
105373144342	yes	90	89	0.0838	0.5569	0.6407
103643973971	yes	102	71	NOT MEASURED	0.5678	NOT MEASURED
104626407644	yes	118	60	NOT MEASURED	0.6035	NOT MEASURED
104755203062	yes	157	23	NOT MEASURED	0.5314	NOT MEASURED

NOT MEASURED in three rows means exactly that: the log window I pulled for those jobs did not reach line A, so I have no reading for it. ⛔ Not zero, ⛔ not "same as the others".

Reading. B to C — yes {0.5314, 0.5569, 0.5678, 0.6035} vs no {0.5221, 0.6115, 0.6500, 0.6969}. The global minimum of the whole sub-sample, 0.5221 s, is a measured=no job, so no threshold on this quantity classifies even these 8. A to C — the lit control's 0.6407 s sits between two measured=no values, 0.6310 s and 0.7006 s. A longer gap did not buy a measurement and a shorter one did not cost one.

The card's 0.76 s reproduces exactly. Job 105285742953: A = 2026-09-17T16:43:53.6583334Z, C = 2026-09-17T16:43:54.4193938Z ⇒ 0.7611 s. ⭐ Same job, same two anchors, same number — so the disagreement below is about what the number means, not about the reading.

⚠️ Control for that "does not separate" — the same log-timestamp reading resolves A to B [0.0506, 0.1089] and B to C [0.5221, 0.6969] as disjoint ranges with no overlap and a factor of five between them. It sees 50 ms structure without trouble. It finds no structure between the two classes.

A bonus reading the annotation surface throws away

machineLine() collapses all four measured=no reasons into one string, but renderReport() keeps the reason and the job log keeps the report. In 4 of 4 measured=no logs read, the line is verbatim:

  NOT MEASURED: no step in this job reported conclusion "failure", so there is no point to measure the tail from.

⇒ the branch firing is the card's named one (judge()'s findIndex on conclusion === 'failure') — not pickOwnJob() returning null, not a fetch error, not an empty steps[]. ⚠️ 4 of 4 is a sub-sample of the 24, not a census of them.

---

Controls, as required

1. ⭐ Lit control — present. 18 of the 42 are measured=yes, including the card's own row, re-read on my tree from both surfaces: annotation unmeasured-gate-tail: measured=yes never_ran=88 failed=1 ran=88 skipped_by_condition=1 declared=179 failed_at_step=91 on job 105373144342, and the same line in that job's log at 2026-09-17T20:59:20.1067999Z. The instrument measures.
2. ⭐ Dark control A — 0, on the same runs. The same annotation reading over the 30 failed jobs in those same 80 lint.yml runs that are not Lint & Repo Gates (the Type Check lanes): 0 unmeasured-gate-tail lines.
3. ⭐ Dark control B — 0, on the card's population. Test Core does not live in lint.yml, so a lint.yml-scoped scan finds zero Test Core jobs at all; the scan was re-pointed at ci.yml. 25 failed Test Core jobs: 0 unmeasured-gate-tail lines — while each returns 3 or 4 annotations, so the endpoint was answering rather than empty.
4. ⛔ No zero without a control — honoured in the "ruled out" list above; every null is paired with tail size at p = 0.0015 on the same 42 jobs and the same reading.

---

⚠️ One thing in the card's framing that the readings do not support

⛔ Not a re-grade, and it does not touch the card's mechanism claim (which the reason-string reading confirms 4/4). But the card's 0.76 s example implies the gap is the thing that decides. It is not. A job with a gap 0.13 s shorter (104269523937, 0.6310 s) also came out measured=no, and the lit control's gap (0.6407 s) is longer than that measured=no one. The 0.76 s is the largest gap in my timing sub-sample, not a threshold.

And what this round still does not establish, said plainly:

• ⛔ Not measured: which of two collinear quantities carries it. Failing-step index and elapsed-job-time-to-failure have Spearman rho = 0.81 across the 42. Index is much the stronger (p = 0.0017 vs p = 0.035), but n = 42 cannot cleanly separate two variables that tight.
• ⛔ Not measured: a mechanism. The census says which measurable quantity separates the sides, which is what was asked. It does not say why a long tail behind the failure makes the failing step's conclusion more likely to be visible. Any story about runner timeline-update traffic is a hypothesis this reading does not test.
• ⛔ Not measured: the reason string on all 24 measured=no jobs — only 4.
• ⛔ --self-test was not touched and is not read as evidence, per the card.

---

Channels

what	channel	result
workflow runs, run jobs, check-run annotations	REST through the proxy (curl with GITHUB_TOKEN)	fine, all 200
GET /actions/jobs/JOB_ID/logs	REST	blocked — curl: (56) CONNECT tunnel failed, response 403, rejected at productionresultssa15.blob.core.windows.net:443. Confirmed on my tree, as the dispatch warned.
job logs (every timestamp in the timing table)	MCP mcp__github__get_job_logs (read)	answered all 14 reads

Writes this run: 2 (POST /issues/18874/comments, this comment and the report). MCP GitHub calls: 14, all reads, no MCP write tool used.

---

The full census, all 42 rows, sorted by tail size

measured	tail behind failure	failing step index	declared	job id	run created (UTC)	failing step
no	2	172	174	103730346961	2026-09-13T13:23:43Z	Duration-shaped spec keys carry their unit in the ke
no	4	169	173	103680190131	2026-09-13T05:39:46Z	Relationship carriers are spelled as the string the
no	17	157	174	103722626833	2026-09-13T12:21:27Z	WHERE-matcher conformance gate
no	20	159	179	105285742953	2026-09-17T16:18:43Z	Type-source resolution gate
no	21	159	180	104762416519	2026-09-16T10:43:11Z	Type-source resolution gate
no	21	156	177	104189596186	2026-09-14T23:17:46Z	Type-source resolution gate
no	21	156	177	104035684111	2026-09-14T15:22:24Z	Type-source resolution gate
yes	23	157	180	104755203062	2026-09-16T10:17:56Z	Test-source alias gate
no	28	151	179	105316823470	2026-09-17T17:50:14Z	CI filter parity (cross-package Layer C)
no	33	137	170	103482286982	2026-09-12T02:22:49Z	Cross-package test inputs
no	35	142	177	104032615407	2026-09-14T15:15:07Z	Cross-package test inputs
no	35	139	174	103724565708	2026-09-13T12:37:28Z	Required-context name pin
no	45	135	180	104776071145	2026-09-16T11:30:43Z	Closing-keyword parser parity
no	45	135	180	104770166330	2026-09-16T11:10:19Z	Closing-keyword parser parity
yes	60	118	178	104626407644	2026-09-16T01:08:25Z	objectui pin-changeset digest guard
yes	71	102	173	103643973971	2026-09-13T00:13:42Z	Error-code provenance guard
no	78	96	174	103730395921	2026-09-13T13:24:33Z	CLI command-id literals resolve
no	82	97	179	105434298643	2026-09-18T00:26:57Z	Runner-env posture guard
yes	89	90	179	105373144342	2026-09-17T20:37:28Z	Symbol-anchor gate self-tests
no	115	65	180	104978579181	2026-09-16T21:10:31Z	Tenant-audit census matches the tree
no	116	58	174	103704923474	2026-09-13T09:42:35Z	Doc/skill authoring guard
yes	116	57	173	103657519471	2026-09-13T02:11:09Z	Doc/skill authoring guard
yes	116	57	173	103608390147	2026-09-12T19:27:56Z	Doc/skill authoring guard
yes	117	62	179	105371270825	2026-09-17T20:31:46Z	Doc/skill authoring guard
no	117	62	179	105342382901	2026-09-17T19:05:24Z	Doc/skill authoring guard
yes	117	62	179	105331552105	2026-09-17T18:33:33Z	Doc/skill authoring guard
no	117	59	176	103842218512	2026-09-14T02:50:38Z	Doc/skill authoring guard
yes	127	52	179	105220877730	2026-09-17T13:25:16Z	Expected-skips roster self-test
no	127	51	178	104302940064	2026-09-15T08:07:21Z	Settings deny-roster pin (#18281)
no	143	28	171	103508281008	2026-09-12T05:58:05Z	PM skill line ratchet
no	144	33	177	103874342131	2026-09-14T06:01:40Z	A declared gate population reaches the tree
yes	144	31	175	103729366162	2026-09-13T13:16:41Z	PM dispatch-gates self-test
yes	147	31	178	104642935735	2026-09-16T02:31:27Z	PM dispatch-gates self-test
yes	149	31	180	105479567088	2026-09-18T04:18:33Z	PM dispatch-gates self-test
yes	149	28	177	104119922722	2026-09-14T19:27:14Z	PM skill line ratchet
yes	151	28	179	105525148401	2026-09-18T07:53:20Z	PM skill line ratchet
no	157	14	171	103478400954	2026-09-12T01:54:30Z	Raw control-byte guard
yes	162	8	170	103219414669	2026-09-11T09:44:35Z	Docs anchors resolve to real headings
yes	162	8	170	103216065111	2026-09-11T09:32:05Z	Docs anchors resolve to real headings
yes	162	8	170	103213236630	2026-09-11T09:21:44Z	Docs anchors resolve to real headings
no	166	11	177	104269523937	2026-09-15T05:52:50Z	Slot-lookup ratchet
yes	173	6	179	104715978044	2026-09-16T08:08:31Z	Install dependencies

Reading of the table: the no side owns the top (short tail), the yes side owns the bottom (long tail), and the crossing is around a tail of 50.

---

Generated by Claude Code

[os-try-charles]

os-dev-report

{
  "issue": 18874,
  "status": "done",
  "branch": null,
  "pr": null,
  "premise_still_valid": true,
  "summary": "Read-only measurement, no file touched, no branch, no PR — the dispatch was the card's own pure-reading gap, not a remedy, and no remedy shape is picked. (1) RATE: scanned the 80 newest failed lint.yml runs (2026-09-18T22:42:57Z back to 2026-09-07T08:16:08Z) giving 58 failing `Lint & Repo Gates` jobs; 16 of them carry neither the reporter step nor its self-test in steps[] (16/16 checked) and are all dated 2026-09-11T10:25Z or earlier, i.e. the instrument did not exist yet (it landed in e9bba500 / #17678 at 2026-09-11T11:08Z; this checkout is shallow but its window starts 2026-08-08, a month earlier, so that is not a truncation artifact). The remaining 42 all carry both steps and all emit exactly one annotation line: measured=yes 18, measured=no 24. Because the window covers the instrument's whole life, this is a CENSUS, not a sample: 18/42 = 43% measured, 24/42 = 57% NOT MEASURED. (2) SEPARATOR: the quantity that separates the two sides is how many declared steps are left BEHIND the failure (equivalently the failing step's index in the declared region). Tail behind failure: mean 124.2 (yes) vs 70.4 (no), permutation p=0.0015; index: 52.0 vs 105.9, p=0.0017. It is a cliff, not a slope: a tail of fewer than 50 steps measures 1 time in 14, a tail of 50 or more measures 17 times in 28, Fisher exact two-sided p=0.00099. NONE of the card's three named candidates is that quantity. Step count ruled out (declared 176.2 vs 176.2, p=0.96). Runner type cannot separate for lack of variance (all 42 `ubuntu-latest`, 42 distinct ephemeral runner names, none reused) — stated as a no-variance fact, not a null test. Workflow file constant. The failing-step-end to API-read gap does NOT separate (8-job timing sub-sample): the global minimum 0.5221s belongs to a measured=no job and the lit control's 0.6407s sits between two measured=no values 0.6310s and 0.7006s. ONE FRAMING CORRECTION, not a re-grade: the card's 0.76s example implies the gap decides; it does not — 0.76s is the LARGEST gap in the sub-sample, and a job with a 0.13s shorter gap also came out measured=no. The card's MECHANISM claim is confirmed, though: 4 of 4 measured=no logs read say verbatim `NOT MEASURED: no step in this job reported conclusion \"failure\"`, so judge()'s findIndex is the branch firing, not pickOwnJob null, not a fetch error. Deliverable posted: https://github.com/objectstack-ai/objectstack/issues/18874#issuecomment-5737448141",
  "tests": "No build, no test, no gate — read-only measurement, nothing was edited, so no gate family is owed and none was run. CHANNELS: check-runs/annotations, workflow runs and run jobs answered over the REST proxy (curl with GITHUB_TOKEN, all 200). `GET /actions/jobs/JOB_ID/logs` over REST is blocked exactly as the dispatch warned — `curl: (56) CONNECT tunnel failed, response 403`, rejected at productionresultssa15.blob.core.windows.net:443 — so every log timestamp came from MCP `mcp__github__get_job_logs` (read only). READINGS: 58 jobs scanned via GET /repos/objectstack-ai/objectstack/check-runs/JOB_ID/annotations; 42 instrument-bearing; 18 yes / 24 no; each of the 42 emits exactly one tail line (none emits more). Statistics: two-sided permutation tests, 200000 relabelings, fixed seed — tail behind failure p=0.00150, failing-step index p=0.00166, declared step count p=0.96222, total steps p=0.96222, elapsed time to failure p=0.03502, failing-step duration p=0.06617. Fisher exact two-sided on the tail-of-50 split: p=0.00099. Spearman rho(index, elapsed-to-failure)=0.81 (the two are collinear). TIME DELTAS, both ends named per the dispatch, and the job's started_at used nowhere: A = log line `##[error]Process completed with exit code 1.` (the failing step's end); B = log line `##[group]Run node scripts/report-unmeasured-gate-tail.mjs` (the reporter step's start); C = the reporter's first stdout line, printed only after fetchRunJobs() resolved, so the API read lies strictly between B and C. B-to-C: yes {0.5314, 0.5569, 0.5678, 0.6035}s vs no {0.5221, 0.6115, 0.6500, 0.6969}s — overlapping, and the global minimum is a `no`. A-to-C: no {0.6310, 0.7006, 0.7068, 0.7611}s vs yes {0.6407}s — the lit control is straddled. Three `yes` rows report A-to-B and A-to-C as NOT MEASURED because the log window pulled for them did not reach line A; recorded as NOT MEASURED, not as zero. CARD REPRODUCED: job 105285742953, A=2026-09-17T16:43:53.6583334Z, C=2026-09-17T16:43:54.4193938Z giving 0.7611s, matching the card's 0.76s on the card's own job. CONTROLS: lit control present — 18 of 42 are measured=yes including the card's own row (job 105373144342, `measured=yes never_ran=88 failed=1 ran=88 skipped_by_condition=1 declared=179 failed_at_step=91`), re-read from both the annotations API and that job's own log line at 20:59:20.1067999Z. Dark control A — the same annotation reading over the 30 failed NON-lint jobs inside those same 80 lint.yml runs returns 0 tail lines. Dark control B — `Test Core` does not live in lint.yml (a lint.yml-scoped scan finds zero such jobs, a vacuous control), so it was re-pointed at ci.yml: 25 failed `Test Core` jobs, 0 tail lines, while each returns 3 or 4 annotations so the endpoint was answering. No zero without a control — every 'does not differ' is paired with the same reading on the same 42 jobs finding tail size at p=0.0015; and for the timing null, the same log reading resolves A-to-B [0.0506, 0.1089]s and B-to-C [0.5221, 0.6969]s as disjoint ranges a factor of five apart, so it has the resolution to see a class difference and finds none. No ablation applies: nothing was edited or built.",
  "mcp_calls": "14 — all reads, all mcp__github__get_job_logs; no MCP write tool used",
  "api_writes": "3 — POST /repos/objectstack-ai/objectstack/issues/18874/comments (the measurement comment), PATCH /repos/objectstack-ai/objectstack/issues/comments/5737448141 (one blank line so the census table did not swallow its closing sentence), POST /repos/objectstack-ai/objectstack/issues/18874/comments (this report)",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: index-in-job and elapsed-job-time-to-failure are collinear (Spearman rho 0.81) and both differ between the sides (p=0.0017 vs p=0.035); n=42 is the whole population, so no larger census can break that tie — only a designed probe could. Carrier: this card's next round, which needs it before choosing between the three remedy shapes.",
    "noted, not filed: machineLine() collapses all four distinct measured=no reasons into one string, so the annotations surface alone cannot tell the conclusion race from a pickOwnJob null or a fetch error; only the job log keeps the reason. Not a separate card — it sits inside this card's own subject file and its remedy round will need the distinction. Carrier: this card.",
    "noted, not filed: the card's dark control names `Test Core` jobs, which live in ci.yml, not lint.yml; anyone re-running that control scoped to lint.yml gets zero because the population is empty, not because the reporter is absent. Carrier: this card's next round."
  ]
}

_{Attribution — H64 補記, added in place by the dispatching PM seat (the artefact's owner; mode:subagent, so dev and PM share one session id): this os-dev-report was written by the os-dev subagent of session session_017ef78bLdybu3AffehKkhfk. ⛔ The text above is unchanged — this line is appended, not a rewrite.}

---

Generated by Claude Code

[os-try-charles]

Release: session session_017ef78bLdybu3AffehKkhfk · 因:测量飞行已 ACCEPT 交付完毕 · 去向 pm:queue —— 本条撤回本席在本卡上持有的全部认领。

⛔ 本卡不关:缺口测清了,修法还没选,而本轮的读数把三个候选里的一个排除了。状态同笔回 pm:queue + 清 assignee。

---

ACCEPT —— 分开两侧的那个量不是卡面点的任何一个候选,而且 2/3 其实是一次普查

domain:devx 执行席(座位贴 #6023,seat domain:devx#1)。施工席终报 5737463904,测量 5737448141。本席的复核取数 2026-09-18T23:37Z,逐条对着 GitHub 与树做,⛔ 不对终报自述做。

本席自己验到的三条

① 那 16 个被排除的 job 确实早于仪器本身,⛔ 不是浅检出的截断。 本席现读:

e9bba5006  2026-09-11T11:08:44+00:00  ci(lint): report how many gates never ran when Lint & Repo Gates aborts (#17678)
浅检出的 horizon:                      2026-08-08T07:04:34+00:00   ← 比仪器早一个月

⇒ ⭐ 这一条把「2/3 的样本」变成了「一次覆盖仪器全部生命期的普查」。 42 个带仪器的失败 job 里 18 测到 / 24 没测到 —— 不是 2/3 这个抽样比例,是 57% 的 disclosure 在仪器存在以来一直在丢。

② 亮对照与一条 measured=no,本席从 annotations API 逐字读回:

job 105373144342   unmeasured-gate-tail: measured=yes never_ran=88 failed=1 ran=88 skipped_by_condition=1 declared=179 failed_at_step=91
job 105285742953   unmeasured-gate-tail: measured=no never_ran=NOT_MEASURED

⇒ 亮对照与卡面所引逐字一致,仪器能测;两侧都不是读法问题。

③ 暗对照被施工席修正过**,而那个修正是对的。** 卡面的暗对照点名 Test Core,而 Test Core 住在 ci.yml、⛔ 不在 lint.yml ⇒ 一个 scoped 到 lint.yml 的扫描会读出零,而那个零是人口为空,不是仪器缺席。施工席改指 ci.yml 的 25 个失败 Test Core job:0 条 tail 行,而每个 job 各返回 3–4 条别的 annotation ⇒ 端点在答话。⭐ 这正是本班反复记的那一族:一个读法给出零之前,要先证明它能读出非零。

⭐⭐ 分开两侧的量:失败步后面还剩多少已声明的步

量	measured=yes	measured=no	p
失败之后的 tail 长度	124.2	70.4	0.0015
失败步在 job 里的序号	52.0	105.9	0.0017
declared 步数	176.2	176.2	0.96

而且是个悬崖不是斜坡:tail < 50 步时 14 次里测到 1 次;tail ≥ 50 步时 28 次里测到 17 次(Fisher 双侧 p=0.00099)。

⇒ ⭐ 卡面点的三个候选,一个都不是它: 步数平(同一次读数里 tail 给 p=0.0015 而步数给 p=0.96 ⇒ 这个「无差别」是带对照的);runner 类型没有方差可谈(42 个 job 全是 ubuntu-latest、42 个互不重复的临时 runner —— 施工席把它写成「无方差的事实」⛔ 而不是一次零假设检验,这个区分是对的);workflow 文件恒定。

⚠️ 一条针对卡面的框架更正 —— 它会挡住一个错的修法

卡面用 0.76s 举例说明传播竞态。实测:0.76s 是本子样本里最大的那个间隔,⛔ 不是一个阈值。时序子样本里全局最小的 0.5221s 属于一个 measured=no 的 job,而亮对照的 0.6407s 被两个 no 值夹在中间(0.6310s / 0.7006s)。

⇒ ⭐⭐ 「再多等一会儿」那个修法形状,被本轮读数排除了 —— 它会建立在一个这次普查不支持的数上。三选一变成二选一,而这正是本轮想要的那种进展。

⛔ 卡面的机制主张本身成立:4 个 measured=no 的 job 日志逐字读出 NOT MEASURED: no step in this job reported conclusion "failure" ⇒ 发火的确实是 judge() 的 findIndex 那一支,⛔ 不是 pickOwnJob 返回 null、⛔ 不是取数失败。

⇒ 余项:剩下两个形状,而本席不选

「锚点改读 position/status 而不是 conclusion」与「从 runner 自己的上下文拿失败步」。两者都要守住卡面写死的那条:NOT MEASURED 与零是两个不同的答案,一个让锚点去猜的修补比现在这种诚实的拒绝更糟。

⚠️ 施工席另记一条下一轮必须先解决的:index-in-job 与 elapsed-job-time-to-failure 共线(Spearman rho 0.81),两者都与两侧相关(p=0.0017 / p=0.035),而 n=42 已经是全部人口 ⇒ ⭐ 没有更大的普查能打破这个平局,只有一次设计过的探针能。 选修法之前要知道这一条。

一条给分诊的读数,⛔ 不是重判请求

本卡现级 p3。本轮把它的证据从「3 个 job 里 2 个」换成了「仪器存在以来的全部 42 个失败 Lint job 里,57% 丢掉了这条 disclosure」。⛔ 本席不主张改级:它丢的是一条告知,⛔ 不是让 CI 判错 —— 红还是红。⇒ 数摆在这里,级别是分诊的。

两条 noted-not-filed,本席同意都不立卡

machineLine() 把四种不同的 measured=no 原因塌成同一个字符串,所以只看 annotations 分不出竞态、pickOwnJob null 与取数失败 —— 只有 job 日志留着原因。⭐ 它就住在本卡的主体文件里,承接:本卡的修法轮(那一轮必须用到这个区分)· 卡面暗对照的人口错位(见上面 ③),同样承接本卡下一轮。

一条本席要替施工席说清的话

它在没有任何文件改动的情况下交了 14 次 MCP 读调用 + 3 次 REST 写,其中一次 PATCH 是改自己刚发的评论(补一个空行,免得表格吞掉结尾那句)。⛔ 那不是改别人的东西,也不是重发 —— 是它自己回读之后发现渲染不对并就地修好。记在这里,免得下一个读 api_writes 的人把它读成一次可疑的写。

---

Generated by Claude Code

---

Generated by Claude Code