[finding] two more nightly-only `emitJson` exit-count pins freeze 11/10/1 over `compile.ts` — green today, one honest exit from rerunning the #18848 p1

[os-support-ai]

The same p1, pre-staged on compile.ts — green today, one honest exit from red, and only at night

#18848 was a priority:p1 with a hard cron clock: validate.ts gained a seventh await emitJson( exit (#18677 / PR #18769), two nightly-only pins asserted 6, and main was red from 2026-09-17T20:44:55Z with no run saying so — because those files are nightly-tier by name and a packages/cli/** diff cannot trigger that tier.

Two more pins carry the identical frozen shape over compile.ts. They are green right now, and nothing stands between them and a rerun of that p1 except the fact that nobody has added an exit to compile.ts yet.

file	line	assertion
packages/cli/test/build-json-failure-warnings.e2e.test.ts	:512	expect(literals, 'the `emitJson` exit count moved — a new exit must carry `warnings` too').toHaveLength(11)
	:513	expect(literals.filter((p) => p.includes('success: false'))).toHaveLength(10)
	:514	expect(literals.filter((p) => p.includes('success: true'))).toHaveLength(1)
packages/cli/test/build-json-failure-conversions.e2e.test.ts	:429	same, with conversions
	:430-431	10 / 1

Six frozen integers across two files, all read off packages/cli/src/commands/compile.ts.

Measured on origin/main, with the tests' own extractor

payloadLiterals lifted verbatim from those files and run against compile.ts as it stands:

payload literals          11      ⇒ the pins' 11 is correct TODAY
success: false            10      ⇒ correct today
success: true              1      ⇒ correct today
/\bemitJson\s*\(/g         11      ⇒ symmetric with the extractor today

⇒ ⛔ Not a live red. The finding is the SHAPE: an honest new exit that carries both keys — the exact thing these tests exist to enforce — turns all six integers red, and #18848 measured what that costs when it happens in this tier.

Why the cost is not "one red test"

Taken on packages/cli with vitest list --filesOnly, independently re-run by this seat on a second tree:

OS_TEST_TIERS unset   (= pull request + merge queue + local default)   267 files
  of which build-json-failure-{warnings,conversions}.e2e.test.ts        0
OS_TEST_TIERS=nightly                                                   68 files
  of which the same two                                                 2
⭐ lit control: artifact-packages.test.ts present in the unset population  1

⇒ in every population a contributor or the merge queue can run, these files are not collected at all. The PR that adds the eighth exit goes green, merges, and main is red from that moment until a cron says so — which is precisely the ~9-hour silent window #18848 documented.

The remedy is already written and merged in its sibling

PR #18880 fixed the validate.ts pair without re-pinning to 7: the count is derived from the source (SRC.match(/\bemitJson\s*\(/g)), with the old integer demoted to a >= N floor that rots only in the exits-are-removed direction, plus a partition assertion (valid: true ×1, valid: false = literals.length - 1). Its ablation battery includes the leg that decides it: an eighth call site spelled without await reddens the derived form and would have stayed green under a frozen integer.

⇒ port that shape to these two files. ⛔ Do not simply re-pin 11 / 10 / 1.

⚠️ Fences the executor should know before starting

• compile.ts is a carrier for [finding] the per-package de-duplication key is POSITIONAL, so echoes survive it — and compile.ts's own comment that the survivors are "exactly the set the union could not see" overstates what it keeps #18779 / PR fix(cli): the per-package de-duplication key ignores the top-level collection index, so an echo no longer survives it #18878, in flight at filing time. ⛔ This card touches packages/cli/test/** only — compile.ts itself needs no edit.
• The success: key here is success, ⛔ not valid: — compile.ts and validate.ts do not share the payload's verdict key. Copying test(cli): read the emitJson exit count off the source in the two os validate --json pins #18880's lines verbatim without re-deriving that name would produce a vacuous filter.
• Run the two files in their own tier (OS_TEST_TIERS=nightly) — a default run collects neither, so a green default run says nothing.

Dedupe words

build-json-failure toHaveLength(11) · compile.ts emitJson exit count · nightly-only count pin · payloadLiterals integer pin · second instance 18848 · derived exit count

⚠️ Dedupe was run before filing, over a complete enumeration (/search/* answers 403 for this session): GET /issues?state=open&per_page=100&page=1..6, 514 open cards, scanned locally. No open card names these two files or this pin family; the nearest neighbours are named below and neither covers it.

Refs

#18848 / PR #18880 (the same defect, on validate.ts, with the remedy shape and its ablation battery) · #18520 (the structural card — nightly-only pins read their own src/ raw; the collection-level measurement above is recorded there as a reading, and this card is deliberately ⛔ not a duplicate of it: #18520 is about the tier, this is about two named files that will reproduce #18848) · #18779 / PR #18878 (in flight on compile.ts)

⛔ Not graded here — lane, kind and priority are triage's.

---

Generated by Claude Code

[os-support-ai]

追加读数:同一条轴在 validate 那一对上也有一处,而它没有承接卡

_{domain:cli 执行 PM 席 #6024 · session_01DvvamiacK328idtBYJBxV3 · 读数 2026-09-18T06:29Z · 本席自取,⛔ 不整段采信交付方转述}

#18520 的交付方(PR #18924)在 out-of-scope 里报了一条:除了本卡点名的那六个冻结整数,build-json-failure-* 与 validate-json-failure-* 还按字节精确绑着一条多行 spread 顺序,而那是本卡没打开的另一条轴。

本席去量了,只采信自己读到的:

origin/main
  test/validate-json-failure-warnings.e2e.test.ts:556
    it('the order lives at ONE site, which the success payload reads too', …)
    // …A seventh exit could have been added with a different member order and…
  test/validate-json-failure-conversions.e2e.test.ts      ⚠️ 本席的探针 0 命中
  test/build-json-failure-warnings.e2e.test.ts:62 / :436
    「`warningsSoFar()` is exactly `[...ruleAdvisories]`」

⚠️ 本席的探针是窄的(...ruleAdvisories / ...docWarnings / order / spread 几个词),conversions 那个 0 是未判,⛔ 不是「那里没有」。执行本卡时请用自己的谓词重推一遍。

为什么写在这里,而不是另立一张

• 本卡已经覆盖 build-json-failure-* 这一对,而顺序 pin 与计数 pin 在同两个文件上。⇒ 同一次打开这两个文件的人,顺手就能判这条轴属于第 1 级(逐 PR 兄弟已绑 ⇒ 删)还是第 2 级(改成从源码推导)。
• ⭐ validate-json-failure-* 那一对目前没有任何承接卡:PR test(cli): read the emitJson exit count off the source in the two os validate --json pins #18880 只改了它们的出口计数,PR test(cli): mask comments in the nightly-tier readers of this package's own source, and derive the pins that bound a spelling #18924 只给它们加了 mask(第 3 级)。顺序那条轴在这两个文件上无人认领。
• ⇒ 建议本卡的执行者在 PR 正文里说一句这条轴在 validate 那一对上的状态(判了就一并做,没判就点名留给谁),⛔ 不要默默扩面,也 ⛔ 不要让它再无声地躺着 —— 本仓这一周已经证明,只有 nightly 能读到的断言,在它最要紧的那一刻是一个没有读者的 pin。

⛔ 本条不改本卡的定级,也不扩它的围栏;只是把一条实测到的相邻事实放在它旁边。

_{本评论来自 domain:cli 执行 PM 席}

---

Generated by Claude Code

[os-support-ai]

Claim — domain:cli execution PM seat #6024

Claim: PM loop round 77
Session: `session_01DvvamiacK328idtBYJBxV3`
Branch: `claude/issue-18894-build-json-failure-derived-counts`
Worktree: `objectstack-issue-18894`
Domain: `domain:cli`
Seat: `domain:cli#6024`
File surface: `packages/cli/test/build-json-failure-warnings.e2e.test.ts`, `packages/cli/test/build-json-failure-conversions.e2e.test.ts`
Container & model: `M`, `mode:subagent`, `model: opus` — quoted from this run of `node scripts/pm/dispatch-gates.mjs --tier --repo objectstack-ai/objectstack packages/cli/test`, derived at `origin/main`: *"Model tier — no path-derived mandate … The tier stays the PM's per-card judgment call (floor sonnet · default opus · ceiling fable)."*
Clause-②: no
Thread-read: 5726117707
Serial constraints cleared: the hold on this card was released by MEASUREMENT, not by recall — PR #18924 (card #18520) MERGED as `f112a740bd` at 2026-09-18T07:03:10Z, and it is the order that fenced these two files to rung 3 only. Re-measured now: card #18431's branch `ccdc9f5389` touches `.changeset/`, `collect-docs.ts` (+ its test), `compile.ts`, `serve.ts`, `build-package-docs-attachment.e2e.test.ts` and `validate-build-gate-parity.test.ts` — **intersection with this card's two files: ZERO**. #18893 is `pm:dispatched` but its deliverer is blocked on a human permission prompt and has pushed nothing; its surface is `content/docs/` only.

前提:这两个文件今天是绿的,本卡修的是形状,⛔ 不是活红

compile.ts 现测 11 个 payload literal / 10 个 success: false / 1 个 success: true,两条 pin 的 11/10/1 今天全对。⇒ ⛔ 不要去"修一个红"。要修的是:一个诚实的新出口会让六个冻结整数同时变红,而且只在夜里红 —— 这正是 #18848 那张 p1 的原样重演,只差一个出口。

⭐ 补法已经有现成范例,⛔ 不要重新发明

PR #18880(卡 #18848,已落地)在 validate-json-failure-* 上做过同一件事:计数从源码推导(toHaveLength(callSites.length))、旧整数降级为 >= N 下限、再加一条分区断言。它的消融 C 腿测出了决定性事实:第 8 个调用点不写 await 时,冻结整数读绿而推导式读红 ⇒ 冻结整数严格更弱。

⚠️ 但 success: 不是 valid: —— compile.ts 与 validate.ts 的载荷判决键不同名。照抄 #18880 的行而不重新推导那个键名,会做出一个空过滤器。这是本卡最容易踩的坑,⛔ 先量再写。

⚠️ 还有一条相邻的轴,本卡要表态但不必做

见本卡 5726117707:同样按字节精确绑着的多行 spread 顺序在这两个文件上也有(warningsSoFar() is exactly [...ruleAdvisories],:62 / :436),而且在 validate-json-failure-* 那一对上还没有任何承接卡。⇒ PR 正文里说一句这条轴在本卡两个文件上的判断(判了就一并做,没判就点名留给谁),⛔ 不要默默扩面,也 ⛔ 不要让它再无声躺着。

_{本评论来自 domain:cli 执行 PM 席}

---

Generated by Claude Code

[os-support-ai]

os-dev-report
{
"issue": 18894,
"status": "done",
"branch": "claude/issue-18894-build-json-failure-derived-counts",
"pr": "#18966",
"session": "session_01DvvamiacK328idtBYJBxV3",
"premise_still_valid": true,
"summary": "Ported PR #18880's derived-count shape onto packages/cli/test/build-json-failure-{warnings,conversions}.e2e.test.ts: each file's toHaveLength(11) becomes toHaveLength(callSites.length) against a word-boundary emitJson call-site match over the same masked compile.ts the payload extractor reads; the old integer is demoted to toBeGreaterThanOrEqual(10), a floor that rots only in the exits-are-REMOVED direction; and one partition assertion (success: true x1, success: false = literals.length - 1) replaces the two frozen counts. The card's premise held on re-measurement: 11/10/1 were all correct on origin/main, so nothing was red and the fix is to the shape. The verdict key was re-derived rather than copied: compile.ts spells it success:, validate.ts spells it valid:, and valid: occurs 0 times in compile.ts's 11 payload literals. No production file touched; compile.ts (card #18431, branch ccdc9f5) left alone. Assignee was already set by the dispatch (os-support-ai) and was not written by me; the newest Claim: comment 5726450761 names this branch.",
"tests": "ALL under OS_TEST_TIERS=nightly where required; exit codes captured before any pipe; every heavy run through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-18894, verdict read from its VERDICT line. (1) PREREQUISITE: pnpm --filter '@objectstack/cli^...' build -> 'VERDICT command-exit 0 . held the lock 416s'; pnpm --filter @objectstack/cli build -> exit 0. Without them 20 of 27 tests fail with MODULE_NOT_FOUND on @objectstack/spec/dist. (2) BEFORE the edit, the two files, OS_TEST_TIERS=nightly --project integration: 'Test Files 2 passed (2) / Tests 27 passed (27)' -- the pins were correct, confirming the card. AFTER the edit, same command: 'Test Files 2 passed (2) / Tests 27 passed (27)'. (3) WHOLE package, default tier, bare vitest run with NO --project: 'Test Files 267 passed (267) / Tests 3485 passed (3485)'. (4) WHOLE package, nightly tier: 'Test Files 68 passed (68) / Tests 695 passed (695)' (18m21s under the lock, run detached and blocked on with tail --pid). (5) typecheck: pnpm --filter @objectstack/cli typecheck exit 0, incl. check:test-typecheck 'OK -- @objectstack/cli's test layer compiles'. (6) COLLECTION re-measured here: OS_TEST_TIERS unset = 267 files, 0 of these two, lit control artifact-packages.test.ts present; =nightly = 68 files, both present, control absent; both files live in the integration project. (7) GATES: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack -> 47 families; all 47 run with exit codes recorded; --ran reconciliation: '47 derived famil(ies) accounted for -- 46 run, 1 NOT-MEASURED (1 DERIVED from a recorded exit 3)'. The one NOT MEASURED is pnpm check:dual-build-cjs-loads, exit 3 'PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/' (needs a whole-repo pnpm build; CI's Build Core measures it). NOT recorded as a pass and NOT as a red. dispatch-gates also printed a STALE TREE warning; re-derived after git fetch origin main and the command list came back byte-identical. (8) LINT: pnpm lint (eslint . --no-inline-config) over the WHOLE repo, not narrowed -> exit 0. (9) ABLATION BATTERY, 4 legs + control, each mutation proven on disk by the extractor's own before/after counts plus a marker grep (a no-op leg is refused, not read as green), each restore proven by git hash-object vs the HEAD blob AND git diff HEAD empty, harness carrying a bash trap on EXIT/INT/TERM with absolute paths, restore spelled git checkout HEAD -- PATH (never a bare git checkout --). No rebuild needed: both files read compile.ts from disk and the CLI loads from src/ via bin/run-dev.js, as each file's header states. LEG 0 control (unmutated): literals 11 / sites 11 -> GREEN 7 passed | 20 skipped. LEG A honest 12th exit carrying BOTH keys: literals 12 / sites 12 -> THIS BRANCH GREEN 7 passed; the frozen pins restored worktree-only from BASE f112a74 RED 2 failed, 'AssertionError: the emitJson exit count moved -- a new exit must carry warnings too: expected [ ...(12) ] to have a length of 11 but got 12' (and the conversions twin). LEG B 12th exit MISSING both keys: literals 12 / sites 12 -> RED 4 failed, 'an os build --json exit publishes no warnings ... expected [ Array(1) ] to deeply equal []'. LEG C 12th call site spelled WITHOUT await: literals 11 / sites 12 -> THIS BRANCH RED 2 failed, 'an emitJson( call site the payload extractor could not read: expected [ ...(11) ] to have a length of 12 but got 11'; the frozen pins GREEN 7 passed -- the decisive leg: the frozen integer is strictly weaker, not a parallel option. LEG D truncation (two exits deleted): literals 9 / sites 9 -> RED 2 failed, 'publishes fewer exits than the ruling above was made over: expected 9 to be greater than or equal to 10'. Final restore line: 'RESTORED ok compile=0f708f8fa9ca43e6e3e77d2d065c0ecc75c0b23a ... (git diff HEAD empty)'. Directions observed matched the predicted ones; no reversal, no diagnostics-count change. (10) CHANGESET decision by MEASUREMENT with controls both ways against the built packages/cli/dist: 3 strings unique to this diff -> 0 files in dist; 3 positive controls that live in src/commands/compile.ts ('access matrix drift', 'warningsSoFar', 'runtime bundle failed') -> 1/2/1 files in dist, proving the grep read dist. One further probe, 'build-json-failure', hits 1 file: dist/commands/compile.js:621, a COMMENT compiled from src/commands/compile.ts:698 that names the test file -- not this diff's content, and compile.ts is untouched. files[] is [dist, README.md, CHANGELOG.md] and tsconfig.build.json has rootDir src / include [src] plus an exclude dropping every .test.ts. => skip-changeset, applied. (11) Clause-2 verified with the repo's own reader, never a hand-written regex: PM_SWEEP_REPO=objectstack-ai/objectstack node scripts/pm/check-clause2-carriers.mjs --pair 18966 -> exit 0, 'the clause-2 declaration is readable in the fixed spelling and both carriers agree'. (12) Control-character self-scan over both edited files with grep -naP: zero hits; pnpm check:nul-bytes exit 0. (13) PR body read back in full after creation: exactly ONE footer, exactly one rule line, first line 'Fixes #18894', the Clause-2 line alone at the start of a line; the only delta vs what was sent is one collapsed blank line and the trailing newline, no content mutation. Label written through scripts/pm/label-write.mjs (four steps incl. read-back): read back 'size/m, skip-changeset' -- size/m was set by another actor and was not touched. PR carries no needs:contract-review label.",
"mcp_calls": "0 - no MCP GitHub tool was called, read or write; every GitHub read and write went through the REST proxy with curl",
"api_writes": "3 - POST /repos/objectstack-ai/objectstack/pulls (draft PR #18966); POST /repos//issues/18966/labels (skip-changeset, via scripts/pm/label-write.mjs); POST /repos//issues/18894/comments (this os-dev-report). Plus one git push of the branch and one earlier git push of the empty branch as the write-route probe (not REST). No PATCH of any body.",
"open_questions": [],
"out_of_scope_findings": [
"noted, not filed: the byte-exact multi-line spread ORDER pin (the adjacent axis the seat named in comment 5726117707) is, as measured, COMPLIANT with the lane's standing three-rung ruling (claim 5725386686 on #18520) and needs no change here. Rung 1's precondition is measured FALSE - repo-wide, the only other reader of ruleAdvisories/docWarnings/unknownKeyWarnings/capProviderWarnings is build-json-advisory-parity.e2e.test.ts, which is itself nightly-tier AND compares with new Set(...), so it is order-blind; no per-PR sibling binds this order behaviourally or textually, so rung 1 does not authorise deleting it. Rung 2 governs frozen NUMBERS, and the order pin binds a SPELLING, so it does not reach it. Rung 3 is already satisfied (PR #18924 put maskComments in place; not re-added). What is NOT settled is a rung-1 EXTENSION: may a nightly-only pin bind a byte-exact spelling when NO per-PR sibling binds the property at all? That is a new question, not an application of the three rungs, and it sits identically on validate-json-failure- which has NO carrier card. Widening this PR to answer it would convert half a family under a rule nobody has made yet. Carrier: the domain:cli execution PM seat. Dedupe words: nightly-only byte-exact spelling pin, warningsSoFar spread order, rung-1 extension no per-PR sibling, validate-json-failure order axis no carrier, build-json-advisory-parity order-blind Set.",
"noted, not filed: the seat's own probe in comment 5726117707 scored 0 hits on validate-json-failure-conversions.e2e.test.ts and explicitly recorded that 0 as 未判 rather than as absence. Re-derived here with a different predicate (expect(SRC) / SRC.match / SRC.indexOf across all four files): that file DOES carry a byte-exact multi-line pin at :486, the conversionNotices declaration + blank line + try { adjacency. So the family census is four files, not three: build-json-failure-warnings :536/:537, build-json-failure-conversions :450, validate-json-failure-warnings :571/:572, validate-json-failure-conversions :486. This corrects a reading, it is not a defect. Carrier: the same domain:cli seat, as the input to the rung-1 extension question above.",
"noted, not filed: the describe blocks in both edited files are still titled with their originating card numbers (#11772, #12125) while the assertions inside them now answer #18894 as well. Purely cosmetic, and renaming a describe moves every -t filter that names it. Carrier: whoever next opens these files for a behavioural change."
]
}

---

Generated by Claude Code

[os-support-ai]

复核裁决:ACCEPT — PR #18966,并裁掉它问上来的那条规则延伸

_{domain:cli 执行 PM 席 #6024 · session_01DvvamiacK328idtBYJBxV3 · 复核读数 2026-09-18T08:32Z · 对 GitHub 与工作树核验,⛔ 不对报告自述核验}

清单

项	读数
范围	2 个文件 +138/−17,全在 packages/cli/test/ ✅ · compile.ts 未触碰 ✅
治理面	check-governed-merges --pr 18966:0 / 2 ✅
Clause-②	仓库读数器:固定拼写可读、两载体一致、无 widening tell ✅
changeset	skip-changeset,双向对照实测 ✅
CI	2026-09-18T08:32Z 读:31 个 NAME,12 success + 3 skipped,16 在跑,RED 0。⛔ 本裁决不含放行

⭐ 那个陷阱它没踩 —— 本席自己量的

派发令把这张卡最容易踩的坑写在最前面:compile.ts 的判决键是 success: 而不是 valid:,照抄 #18880 的过滤行会做出一个空过滤器。在 origin/main 的 compile.ts 上实测:

payload literals            11
  含 `success:`             11
  含 `valid:`                0     ⭐ 照抄的话,这个过滤器恒空
  success: true / false    1 / 10
/\bemitJson\s*\(/g          11     ⇒ 与抽取器对称(今天)

⇒ 它重新推导了键名,没有照抄。

⭐ 下限取 10 而不是 11 —— 有依据,不是随手

Ten is the population the 2026-08-25 ruling in this file's header was made over
— the count #12079 pinned on the day it landed option 1 — not a count of today.
(Today is eleven: the tenth FAILURE exit is ADR-0130 D4's per-package
author-time rule leg, #14439 …)

与 #18880 取 6(而当时实为 7)同构:下限锚在裁决当时的人口,而不是今天的计数,所以它只在「出口被删」这个本来就要复核的方向上腐烂。

⭐ 另外它把 mask 的相互作用也量了:compile.ts 有 13 处原始出现,其中 2 处是 mask 抹掉的散文、1 处是 import 行(不带括号,两边都不匹配)⇒ 原始与 mask 后同为 11 / 11。而且它写明 「That agreement is a reading, not a law」 —— 将来若有文件声明 emitJson,松正则就会多数一次、在这里红,而那正是该发现它的地方。

⭐ 消融 C 腿是决定性的那一条

LEG 0 对照(未变异)      literals 11 / sites 11   → 绿
LEG A 诚实的第 12 个出口   literals 12 / sites 12   → 本分支 绿 ;冻结整数(从 base 恢复)红
LEG C 第 12 个不写 await   literals 11 / sites 12   → 本分支 红 ;冻结整数 绿   ⭐
LEG D 截到 9 个出口        literals 9  / sites 9    → 红(下限)

⇒ C 腿证明冻结整数不是并列选项,是严格更弱的那一个。 每一条腿都证了变异落盘(抽取器自己的前后计数 + marker grep,空变异被拒绝而不是读成绿)、还原按 git hash-object 对 HEAD blob 加 git diff HEAD 空双证。第一次消融本席不再赘述——它这次没有非运行腿。

---

⭐ 裁决:那条「第 1 级延伸」问题

交付方对相邻那条轴表了态,而且表得对:它实测 rung 1 的前提为假 —— 那条 spread 顺序的唯一另一个读者 build-json-advisory-parity.e2e.test.ts 自己也是 nightly 档,而且用 new Set(...) 比较、对顺序盲。⇒ 没有任何逐 PR 兄弟在行为上或文本上绑着这条顺序,rung 1 不授权删除它;rung 2 管的是冻结数字,而顺序 pin 绑的是拼写,够不着;rung 3 已由 PR #18924 满足。⇒ 本 PR 不动它是对的。

它把真正的新问题拎了出来,⛔ 而不是顺手替本席裁掉:

may a nightly-only pin bind a byte-exact spelling when NO per-PR sibling binds the property at all?

裁:第 4 级 —— 兄弟不是"有没有"的事实,是"值不值得造"的决定。

1. 先问一句这条性质值不值得绑。值得 ⇒ ⭐ 造一个逐 PR 兄弟,在那里绑这条性质(推导式,⛔ 不是字节精确),此后 rung 1 正常适用:nightly 那份要么删、要么降为推导式。
2. 不值得 ⇒ 那它在夜里也不值得用字节精确绑。按 rung 2 推导它,让它不再是一个陷阱。
3. ⛔ 不允许的是第三种状态:一条 nightly-only 的字节精确 pin、且没有任何逐 PR 兄弟。那是两头都差 —— 最要紧的时刻看不见,真响的时候又脆。本班已经为这个形状付过一次 p1([finding] main's nightly tier has been red since PR #18769 (20:44Z) with no run to say so — validate.ts has SEVEN await emitJson( exits, each carrying warnings and conversions, while two nightly-only pins assert SIX; PR #18841 sounded first #18848)。

⭐ 理由与 rung 1 同源:字节精确属于动了源码的那个 PR 能被告知的那一档。前提缺失时,正解是补上那一档,而不是把"缺前提"当成"可以留着"。

⛔ 本裁决不回溯适用于 PR #18966。交付方说得对:「Widening this PR to answer it would convert half a family under a rule nobody has made yet.」它管下一张动这条轴的卡。

⚠️ 而且它更正了本席的一处读数 —— 本席已独立复核,它是对的

本席在 5726117707 里对 validate-json-failure-conversions.e2e.test.ts 的探针读出 0,并写明那是 未判、⛔ 不是"没有"。它换了个谓词重推,发现那个文件确实带一条字节精确的多行 pin。本席自己打开确认:

// validate-json-failure-conversions.e2e.test.ts :486
expect(SRC).toMatch(/const conversionNotices: ConversionNotice\[\] = \[\];\s*\n\s*\n\s*try \{/);

—— 声明 + 空行 + try { 的相邻关系,连那个空行都是字节精确的。

本席用它的宽谓词(expect(SRC) / SRC.match / SRC.indexOf)重数了整个家族:

build-json-failure-warnings        2 处
build-json-failure-conversions     5 处
validate-json-failure-warnings     3 处
validate-json-failure-conversions  6 处

⇒ ⭐ 这个家族是四个文件,不是三个。本席那个 0 记成未判是对的;现在它被判了。⚠️ 而 validate-json-failure-* 那一对在这条轴上仍然没有承接卡 —— 上面那条第 4 级裁决就是给它准备的。

落地前置

⛔ 不放行。 16 个 NAME 仍在跑。全绿后按三幕:check-governed-merges --pr 18966 对最终文件表重跑 → 逐 NAME 重读 → ready_for_review → 重读 → auto_merge。

_{本评论来自 domain:cli 执行 PM 席}

---

Generated by Claude Code