[os-support-ai]

Fixes #18590

Clause-②: no

Rerun Safety (workflow 323746634) has been red on main and the card's
finding was that it dies in Test suite — pass 1, so the rerun property it
exists to measure has never been measured. The card marked two premises NOT
ESTABLISHED and asked for them to be measured first. Both were. One of them is
refuted, and that is what decided where the fix goes.

Premise 1 — "do all ten failures share one cause?" — REFUTED

The card read only the newest run's log. Reading the whole streak back through
the workflow-scoped runs API and each job's check-run annotations:

The streak is 17 nights, not 10. Last success was 33355711750,
2026-08-31. And the failures do not share a cause — not the failing package, not
even the failing step:

nights	dates	step that died	failing turbo task	kind
4	09-14 .. 09-17	pass 1	@objectstack/cli#test	Test timed out in 5000ms
6	09-08 .. 09-13	pass 1	@objectstack/verify#test	AssertionError
1	09-05	pass 1	@objectstack/plugin-auth#test
2	09-02 .. 09-03	pass 1	@objectstack/cli#test
4	09-01, 09-04, 09-06, 09-07	pass 2	@objectstack/core#test, @objectstack/objectql#test

Two consequences the card could not see from one log:

1. Four of the seventeen nights did reach pass 2. Those are the only rerun
   readings the streak contains — the property is not merely unmeasured, it is
   intermittently measured, which is worse, because nothing said which nights
   were which.
2. The pass-1 killer MOVED. verify's harness.host-resolution.test.ts was
   the killer for six nights and is green on today's main (verified
   locally: Test Files 1 passed (11 tests)). It was fixed, and cli inherited
   the job.

So "get pass 1 green" is not a reachable end state on a trunk that goes red like
any other trunk — it was reached, repeatedly, and the instrument went dark again
each time. That is why the fix is not a fix to whichever test is red tonight.

Premise 2 — "does that file time out outside this workflow?" — the control fired

Run locally on an idle box holding the shared verify lock, --project integration:

✓ NODE_ENV=development                          3300ms
✓ NODE_ENV=test                                 2990ms
✓ NODE_ENV=production (the never-broken leg)    3073ms
× CONTROL: neutralising the declaration         5710ms   Test timed out in 5000ms
✓ CONTROL: neutralised under production         3039ms

Green outside the workflow — but a different leg failed, and it failed the
same way. Re-run with the budget lifted (--testTimeout=120000), all five pass
and the true costs are 3000 / 2526 / 2742 / 3599 / 2467 ms.

⭐ This refines the card's lead rather than confirming it. The card read
"all three legs time out regardless of NODE_ENV" as the signature of the spawn
harness. The sharper reading: all FIVE legs cost 2.5–3.6s against a 5000ms
budget nobody chose, so which legs redden is decided by machine load. In the
workflow the three non-neutralised legs died and both CONTROL legs lived;
locally the reverse happened. Same file, same commit, disjoint casualties — the
casualty list is a function of the runner, not of anything under test.

(The card's own reasoning that this is not about NODE_ENV stands, and is
strengthened: NODE_ENV does not correlate with the casualties in either run.)

What this changes

1. The instrument — pass 2 no longer depends on pass 1 being green

.github/workflows/rerun-safety-nightly.yml: pass 1 now records its exit
code instead of ending the job with it, pass 2 runs if: always(), and a new
verdict step owns the job's exit status.

scripts/rerun-safety-verdict.mjs compares the two passes' failing task sets and
reports, in one line, whether the rerun property was MEASURED and what it
said:

pass 1	pass 2	verdict	measured	job
green	green	RERUN_SAFE	yes	pass
green	red	RERUN_UNSAFE	yes	fail
red	green	BASELINE_FLAKY	yes	fail
red	red, same set	BASELINE_BROKEN — rerun property CLEAN	yes	fail
red	red, pass 2 worse	RERUN_UNSAFE_ON_BROKEN_BASELINE	yes	fail
stall (75)	any	STALL	no	fail

⛔ Nothing is weakened and nothing is skipped. A red pass 1 still fails the
job, exactly as the workflow header intends. What changed is that a broken trunk
now costs the instrument its baseline instead of its reading — and a
stall is the only remaining state that reports NOT MEASURED, which is the honest
answer for a stall.

The task-set parser reads three spellings because no one of them is sufficient:
turbo's Failed: footer under-reports (measured on the 2026-09-08 run, it
named verify alone while plugin-auth, runtime and client had each printed
ELIFECYCLE in the same run), so the footer, the per-task ERROR command line and
the streaming ELIFECYCLE prefix are unioned.

2. The proximate cause — the shadow budget on the named file

packages/cli/test/published-entry-node-env-source-reroute.test.ts now states
CHILD_BUDGET_MS = 120_000 once and hands it to both its own spawnSync and
each of its five legs.

⛔ This is not "raise the timeout until it passes", and the card is owed the
argument:

(a) Why it cannot mask a real rerun failure. It raises no bound. The
spawnSync in this file already declared 120s — chosen, and the same number the
other spawning suites in packages/cli/test/ pin (27 of 48 integration-tier
files here carry an explicit per-test timeout; this one was in the minority that
does not). The child is still killed at exactly 120s. What is removed is a
second, lower, unchosen bound — vitest's 5000ms default — that was shadowing
the chosen one, and that could never have bounded a spawnSync anyway, because a
synchronous spawn blocks the worker's event loop and vitest cannot interrupt it.
The 5000ms number never bounded anything; it only relabelled a completed slow
spawn as a failure after the fact.

(b) The reading that still discriminates the two. Previously a hung child and
a slow child arrived as the same information-free line — Error: Test timed out in 5000ms, attributed to the it() and naming nothing about the child. They are
now separated: runPublishedEntry raises a named error when the child was
killed by its own bound (error.code === 'ETIMEDOUT' / signal === 'SIGTERM'),
carrying the env, the neutralise flag and the elapsed ms, and saying in the
message that this is a hung child rather than a slow one. A slow child stays a
pass whose duration vitest prints, against the five measured costs recorded in
the file's header.

3. The job backstop — a second latent way this instrument goes dark

timeout-minutes: 120 → 170. The last four green two-pass runs took 74,
89, 103 and 115 minutes, so a healthy run was within five minutes of being
killed by its own backstop — and this PR makes pass 2 run on the nights pass 1 is
red, which is exactly when a 115-minute run is likely. ⛔ This is not a stall
budget: run-with-stall-guard still declares a stall after 15 minutes of frozen
output on either pass, so a genuine hang is still caught in 15 minutes and never
at this number.

4. The self-test is wired at PR time, not in the nightly

check:pm-dispatch-gates refuses a SCHEDULED-ONLY gate family: every
discovered family must reach a workflow declaring a PR-time event. Invoking
--self-test from rerun-safety-nightly.yml (schedule + workflow_dispatch
only) made it this tree's first — the gate caught it, by name. It is wired as
pnpm check:rerun-safety-verdict in lint.yml instead.

Reverse verification (ablation)

Through scripts/ablation-replace.mjs, so the mutation's landing and the
restore's byte-identity are the tool's own verdict:

anchor "matchAll(ELIFECYCLE_RE)"  x1 -> x0
blob   6275d799aaa8 -> 18fce43f6bda    [mutation proven on disk]
  FAIL parse: streaming ELIFECYCLE prefix
  FAIL parse: union under-reporting footer (2026-09-08 shape) -- got @objectstack/verify#test
rerun-safety-verdict --self-test: 2 FAILED   [exit 1]
blob after restore 6275d799aaa8 == blob at HEAD 6275d799aaa8, `git diff HEAD` empty

Direction as predicted (turns red), and the ablated union falls back to exactly
the under-report the union exists to close.

Verification

Measured at 24f5253ca.

• pnpm lint repo-wide — eslint . --no-inline-config, full population, no
  narrowing: exit 0.
• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack
  derived 92 commands at this HEAD; all run, exit codes recorded and
  reconciled with --ran.
• node scripts/rerun-safety-verdict.mjs --self-test — 15 batteries, 15
  registered, exit 0.
• packages/cli suite, plus packages/verify's harness.host-resolution.test.ts
  as the premise-1 control.

NOT MEASURED, declared:

• ⛔ This workflow runs only on main, so no PR can make it red or green.
  The change is proven by local reproduction and by the ablation above; it is
  not verified by the instrument itself and must not be read as if it were.
  The first real reading arrives on the first nightly after this lands.
• pnpm check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: it reads
  built output and this tree has no full pnpm build. Not a pass and not a red.
  This diff adds no published bytes, so it cannot move that gate.

Cross-face declaration

The claim comment warned that touching vitest tiering configuration would be
a repo-wide shared predicate and therefore a cross-face effect. ⛔ It is not
touched. packages/cli/vitest-tiers.ts and packages/cli/vitest.config.ts are
both unmodified. The edited test file keeps both signals that place it
(node:child_process + the run.js entry basename), so it stays in the
integration tier and no file moves between tiers.

Changeset

skip-changeset, measured rather than assumed: @objectstack/cli ships
["dist", "README.md", "CHANGELOG.md"] — test/ is not published; the root
package is private, so scripts/ and .github/ are not published either. Grep
of the built packages/cli/dist for the symbols this PR introduces
(CHILD_BUDGET_MS, killedByOwnBound, rerun-safety-verdict) returns zero
hits, with a positive control (enableAutoTranspile) hitting three files in
the same grep. No published bytes move.

Acceptance notes

Noted, not filed — none of these is in this card's scope, and each is recorded
here rather than acted on:

• The four pass-2 deaths in the streak (@objectstack/core#test ×3,
  @objectstack/objectql#test ×1, on 09-01/04/06/07) are real rerun-safety
  readings that were taken and never acted on. Triage ruled explicitly that
  the rerun-unsafe tests are not this card's business while the instrument is
  mute. With the instrument repaired they will re-report themselves on the next
  nightly, attributed, which is the right time to pick them up. Carrier: the
  first nightly run after this lands.
• packages/cli/test/published-entry-stderr-error-listener.test.ts is the other
  spawning file in this directory with no explicit per-test timeout, so it is the
  next candidate to redden the same way under load. Not measured here, and not
  changed — naming it so the next occurrence is recognised rather than
  rediscovered. Carrier: whoever picks up the next cli#test nightly red.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 30bac2880151704965a0d8c2099f8d9e9e78c761 → packageMentionDocs.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 35259161595 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (6/6) — 失败步骤: Run this shard's tests

  @objectstack/client:test:  FAIL  src/organization-invite-role-default.test.ts > #16582 organizations.invite defaults role to member > ① the two-argument form is accepted and lands a pending member inv
    ↳ 失败原因: @objectstack/client:test: Error: Test timed out in 5000ms.
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• src/organization-invite-role-default.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 0 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-support-ai]

Standing down on the queue red — it is not this PR's, and the one allowed re-queue follows

domain:cli execution PM seat. ⛔ Recorded before re-queueing, not after.

The failing check, and why it is not this PR's

Test Core (6/6) in queue build 35259161595, step Run this shard's tests. The repo's own merge-queue-triage extracted the body (comment 5719488003):

@objectstack/client:test:  FAIL  src/organization-invite-role-default.test.ts
  > #16582 organizations.invite defaults role to member
  > ① the two-argument form is accepted and lands a pending member inv
  ↳ 失败原因: Error: Test timed out in 5000ms.

Three readings, each one measured rather than argued:

1. The package is not in this diff. This PR touches .github/workflows/rerun-safety-nightly.yml, .github/workflows/lint.yml, package.json, packages/cli/test/published-entry-node-env-source-reroute.test.ts and scripts/rerun-safety-verdict.mjs. ⛔ Nothing under packages/client.
2. It is a TIMEOUT, not an assertion. Per the triage comment's own criterion — 「超时多半是负载/时序,不是本 PR 的回归;断言才指向真实的行为改变」, and the two FAIL lines are indistinguishable without the ↳ 失败原因 line. Its one documented exception (an assertion whose subject is the experiment's own validity premise — a duration, a timestamp, an elapsed count) does not even need to be reached: this is a bare timeout.
3. This shard is GREEN on the PR's own head. 24f5253ca was read per check NAME before the flip: every name success or a rostered skip. The queue runs the full suite where PR-side CI runs the affected subset, so this test never ran on this PR's own CI at all.

⇒ ⛔ Not this PR's regression. ⛔ And not called a flake either — see below, it has a named class and a card.

⛔ No fix exists to port yet — and the class is already filed

This is not an unexplained red. It is the sixth measured site of one class: a default timeout budget nobody chose is silently made the judge of a real load/boot cost.

card	site	budget	state
#5421	runtime-lazy-deps.test.ts	5s	closed
#9311	types/src/node.test.ts · semantic-roles.dogfood.test.ts	5s · 10s hookTimeout	closed
#18590 (this card)	published-entry-node-env-source-reroute.test.ts	5s → fixed here, per-site	this PR
#18748	envelope-unwrap.test.ts	10s hookTimeout	open
this red	packages/client/src/organization-invite-role-default.test.ts	5s	—

⇒ the remedy for this site has not landed anywhere, so there is nothing to port into this PR. ⭐ Filed onto #18748, which already carries the recurrence and the four prior per-site closures. ⛔ Widening this PR to fix a packages/client test would be exactly the widening the rules forbid.

What happens next

The one re-queue the rules allow, spent now and recorded here, so it is not spent twice. ⛔ No empty commit, ⛔ no close-and-reopen, ⛔ no test skipped, disabled or quarantined. If the same signature reddens this PR a second time, that second failure is real and gets root-caused rather than re-queued.

⚠️ One bound the triage comment declares about itself, carried forward rather than dropped: its 24h cross-PR ledger did not finish reading (over 5 pages without reaching the window's end), so its 「only this PR hit it」 is a lower bound, ⛔ not a census.

_{Read by the domain:cli execution PM seat, 2026-09-17T18:47Z.}

---

Generated by Claude Code