test(lint): pin the four unprovisionedAnchors threading sites that the lint suite could not see

[os-project-manager]

Fixes#8943

checkFieldRefs takes the anchor index as an optional trailing parameter, so a call site that stops passing it keeps compiling and silently downgrades to the pre-#8340 behaviour: existence still answered, provenance never asked. #8943 measured all six in-repo threading sites — the two module seams are pinned, and four calls inside checkBlockFieldProps were threaded by convention only.

This adds one behaviour test per uncovered site, through validateReactPageProps, asserting page-field-unprovisioned on an ADR-0015 external object — mirroring the existing FILTER-position test, with the #8404 pin's comment style so the next reader knows what each test is for.

Test-only. No production file is touched — validate-react-page-props.ts is byte-identical to origin/main (blob a560d360b on both, verified after the last ablation).

Ablation evidence — each test observed RED at its own site

Every test was written ablation-first: drop the unprovisionedAnchors argument at that site, run, restore. Each leg was then re-run against the full 2051-test suite — not a filtered subset — because the claim being pinned is that nothing else catches the drop.

site	call site	full-suite result with the index dropped
R1	own refs, the skipped bucket of REACT_FIELD_SPECS	1 failed, 2050 passed — only the R1 test
R3	ObjectForm subform CHILD refs (resolved against childObject)	1 failed, 2050 passed — only the R3 test
R4	subform totalField rollup (resolved against the FORM object)	1 failed, 2050 passed — only the R4 test
R5	the COMPONENT_FIELD_SPECS path reached by Block type	1 failed, 2050 passed — only the R5 test

Exactly one red per leg carries both halves of the claim: no pre-existing test covers any of the four sites (a second failure would have shown one), and each new test pins exactly one call site rather than the group. Restored between every leg, with the blob hash checked back against origin/main at the end.

The branches are disjoint by tag and prop, which is what makes that attribution possible: own refs reach ListView columns; the subform pair needs ObjectForm subforms; and COMPONENT_FIELD_SPECS is reachable only through Block type, since no react tag's own schemaType (list-view, object-form, object-chart) is a key in that table.

Why no other instrument sees this: measured under the R5 ablation, pnpm --filter @objectstack/lint typecheck exits 0. The parameter is optional, so there is no type error, and the local unprovisionedAnchors binding stays read by the sibling calls, so there is no TS6133 either. Only a behaviour test can see it.

Verification

Gate union run after the final commit, at dcecc68ec:

• pnpm --filter @objectstack/lint test — 73 files, 2051 passed (2047 on main + the 4 new)
• pnpm --filter @objectstack/lint typecheck — clean
• pnpm check:cross-package-test-inputs and node scripts/check-cross-package-test-inputs.mjs — OK, 12 packages read outside themselves, all declared
• pnpm check:nul-bytes — OK, 5938 files scanned
• Re-derived against the actual changed path with scripts/pm/dispatch-gates.mjs, which added three convention-triggered gates the dispatch list did not name; all run and green:
  • pnpm check:query-options-erasure — ratchet holds, test surface unchanged at the ceiling
  • pnpm check:type-check-coverage — OK
  • pnpm check:type-check-debt — OK, 33 ledger entries re-measured, none above its recorded number. Run with the full workspace closure built, as the gate requires. @objectstack/lint measures 19 against its recorded 20, so the new test file adds zero type errors. (Its tsconfig.json excludes *.test.ts, so this ratchet — not the package typecheck — is what actually reads the new file.)

skip-changeset: test-only, nothing user-visible to release.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 16, 2026 4:19am

[github-actions]

📓 Docs Drift Check

No hand-written docs reference the 0 changed package(s). ✅

[github-actions]

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

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

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

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

  �[90mstdout�[2m | src/webhook-secret-at-rest.test.ts�[2m > �[22m�[2mfail-closed and re-arm, extended to headers (#7986 × #7799/#8022)�[2m > �[22m�[2mdrops the subscription rather than delivering it wi
  �[90mstdout�[2m | src/webhook-secret-at-rest.test.ts�[2m > �[22m�[2mfail-closed and re-arm, extended to headers (#7986 × #7799/#8022)�[2m > �[22m�[2mdrops the subscription rather than delivering it wi
  �[90mstdout�[2m | src/webhook-secret-at-rest.test.ts�[2m > �[22m�[2mfail-closed and re-arm, extended to headers (#7986 × #7799/#8022)�[2m > �[22m�[2mre-arms with its headers when the CryptoProvider re
  �[90mstdout�[2m | src/webhook-secret-at-rest.test.ts�[2m > �[22m�[2mfail-closed and re-arm, extended to headers (#7986 × #7799/#8022)�[2m > �[22m�[2mre-arms with its headers when the CryptoProvider re
  �[41m�[1m FAIL �[22m�[49m test/cloud-login-json-ndjson.e2e.test.ts�[2m > �[22mthe exception stays declared, not just implemented (#6730 ruling)�[2m > �[22mdocuments the exception where the cloud login
  

历史信号：

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

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 在其他 PR 的同类评论里搜同名测试；出现过 ⇒ flaky 实锤，开 issue 修/隔离那条测试。修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

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

[os-project-manager]

分诊:同批次连带,与本 PR 无关 —— ⛔ 不重排,⛔ 不是 flaky

队列构建 31927041196 红在 packages/cli/test/cloud-login-json-ndjson.e2e.test.ts。这是本轮第三个被同一来源连带的 PR(前两个是 #8983 本身与 #8987)。

实测

判据	结果
本 PR 改动面	恰 1 个文件:packages/lint/src/validate-react-page-props.test.ts,无任何 docs
origin/main 的 index.mdx 是否满足该测试三条正则	NDJSON ✅ · one per line ✅ · anchor ✅ —— main 是干净的

⇒ main 绿、本 PR 不碰那个文件 ⇒ 红只可能来自同批次里改了 content/docs/deployment/index.mdx 的那张 PR,也就是 #8983。

来源已修复,时间线对得上

• 04:39:37Z docs(deployment): rewrite the section index around the two lifecycles and re-order meta.json (#8913) #8983 因该回归出队
• 队列自动重排,持的是修复前的 shaf28588af3
• 04:44:56Z dev 推送修复 b40e5fefb
• ~04:45 本次构建开始,批次里仍是旧 sha ⇒ 红
• 04:51:04Z 我用修复后的 head 重新武装

现在 #8983 的 head 实测为 b40e5fefb1fcf91391aa962a8909bd6cad17f5f6(修复版),已在队列中。⇒ 下一次为本 PR 构建的候选不会再含坏内容。

处置:等,不动手

⛔ 不重排 —— 盲排会让排在后面的每个 PR 再重建一轮,而污染源已经不在了,重排除了烧一轮什么都不改变。
⛔ 不开 flaky issue —— 详细理由写在 #8987 的同类评论里:「同名测试在别处出现过」不足以判 flaky,还要问它在那里是真红还是同样连带。这条测试非但不 flaky,它恰恰抓到了一个 PR 侧 affected 子集 CI 结构上看不见的真回归。

根因(CLI 测试读 docs 却对门禁与 turbo affected 集双双隐形)已单独立卡:#8995。

---

Generated by Claude Code