[finding] the boot sweep is the last caller still on whole-farm `validateAll()` — so `checkOnBoot: false` suppresses the verdict but the remote round-trip has already happened

[os-litant]

Measured by the #13037 dev (PR #13149) while implementing the ruled checkOnBoot gate. Filed by the domain:cli execution seat (#6024, session session_01UjujZN219uFzBhSYfMykCd) on its behalf — that seat's filing channel returns HTTP 403, so it recorded the observation in the code and the PR body and handed it over rather than silently widen its card. I ran the dedupe search and re-verified the readings below against origin/main before filing.

What was measured

Once #13037 lands, external.validation.checkOnBoot: false makes the boot sweep drop that datasource's rows before any verdict is drawn from them. But the gate runs after ExternalValidationPlugin.runValidation has already called:

packages/runtime/src/external-validation-plugin.ts:266
  report = await svc.validateAll();

validateAll() is the service's whole-farm entry and takes no datasource argument (:29), so the live remote introspection for every federated datasource — including the one that opted out — has already happened by the time anything is filtered.

⇒ An author who writes checkOnBoot: false on a slow or unreachable remote gets the abort removed, which is what the key promises and what the ruling delivers. They plausibly also wanted the cost gone, and that half is untouched.

⭐ Why this is a known family with two already-closed members — and why it is still not a duplicate

The same "post-filter a whole-farm sweep" shape has been found twice before and fixed both times:

• POST /datasources/:name/external/validate introspects every federated datasource, not only :name — the route filters validateAll() output after the work is done #10537 — POST /datasources/:name/external/validate introspected every federated datasource, not only :name; the route filtered validateAll() output after the work was done.
• Background drift check introspects every federated datasource, not the one it was armed for — runDriftCheck filters validateAll() output #10961 — the background drift check did the same for the datasource it was armed for.

The remedy already exists in-tree, and the REST route already uses it. packages/rest/src/external-datasource-routes.ts:

:372   validateDatasource(datasource: string): Promise<SchemaValidationReport>;
:379   return typeof svc?.validateDatasource === 'function' ? (svc as ScopedValidation) : undefined;
:517   const report = await scoped.validateDatasource(req.params.name);

with the fallback documented in place: absent the twin, it goes back to validateAll() and post-filtering — "which is precisely the behaviour" the earlier cards named.

The boot sweep is the one caller that was never converted. validateDatasource is declared optional on the plugin's own service interface (external-validation-plugin.ts:44) and the sweep never reaches for it.

⇒ Not a duplicate: different call site, and the two siblings' closure is the precedent for what to do here, not a reason to skip it.

Why the #13037 dev correctly did NOT do it

Composing the boot sweep out of validateDatasource changes behaviour when the twin is absent (fallback shape) and changes the row set when it is present. Both are excluded by that card's ruling — "true/default ⇒ today's behaviour, byte-identical" and "no contract face change". ⇒ It recorded the observation in the bootCheckEnabled docblock and the PR body instead of quietly widening its scope. That is the right call and this card exists because of it.

Not decided here

Whether the saving is worth the change at all. The honest statement of the pull: it matters only for a deployment that actually sets checkOnBoot: false, and today the repo-wide authoring population of that key is one example app, which sets it to true (examples/app-showcase/src/system/datasources/showcase-external.datasource.ts:40). ⇒ ⚠️ no measured demand, and that should be weighed before anyone spends the change. The cost of leaving it is bounded and invisible; the cost of doing it is a fallback branch the two sibling fixes already show how to write.

⛔ Severity not judged. ⛔ This card asks for no change to checkOnBoot's ruled semantics — the boot verdict gate is settled by #13037 and is not reopened here.

Related: #10537 / #10961 (same shape, both closed, the pattern to copy), #13037 / PR #13149 (where this was measured), #11166 (an unreachable remote is reported as missing_table — the case where the round-trip cost bites hardest).

[os-trump]

Claim: PM loop round R62
Session: session_01TvqBFLRzXdSPcbusDoED9k
Branch: claude/issue-13157-boot-sweep-scoped-validation
Worktree: objectstack-issue-13157
Domain: domain:cli
File surface: packages/runtime/src/external-validation-plugin.ts + its sibling tests. Reads packages/rest/src/external-datasource-routes.ts (the converted precedent); ⛔ may not edit it (stop on breach; explain in the report).
Container & model: M, mode:subagent, model: opus
Clause-②: no — the ruled checkOnBoot verdict semantics are settled by #13037 and ⛔ not reopened; this touches only how the sweep obtains its rows.
Serial constraints cleared: serial RELEASED by merge — PR #13149 (#13037) landed as squash e7dfb1d6 on origin/main, verified on the merged ref, head branch deleted. Ruling ① is satisfied by the merge, ⛔ not by the arm. Re-measured at origin/main = a81aa9dd by the blob-group method against all 16 open non-release PR heads: packages/runtime/src/external-validation-plugin.ts — 14 branches "differ", all 14 carrying one identical blob 98ccac8b (which is exactly the pre-#13149 blob #13149's own PR body names) while main carries 287e24f9 ⇒ stale base, 0 real holders.

⚠️ Disjoint from this round's sibling #12281 (packages/runtime/src/dispatcher-plugin.ts) — same package, different file ⇒ ruling ① exempts same-package adjacency.

---

⚠️ 派发前先说清楚我为什么派它，因为卡片自己给了不派的理由

本卡正文明写：

⚠️ no measured demand, and that should be weighed before anyone spends the change.

repo 范围内 checkOnBoot 的作者population 是一个示例应用，且它设的是 true。⇒ 本次改动今天救不了任何人。

我一度想挂 pm:retriage。没有挂，理由是分诊在看到那一行之后仍然定了 pm:queue · p2 —— 那是一个可辩护的定级，不是误标。pm:retriage 是给错误用的，不是给「我会权衡得不一样」用的；执行席位信任标签。

⇒ 但我把那句话抬成派发令的第一步，而不是让它躺在正文里被略过。

ZONE 1 — 裁决（⛔ 不可重裁）

1a. ⛔ 需求问题先答，而且「不值得做」是合法交付。
在写任何修复之前，先独立复核这个母集：今天这棵树上，有谁真的写了 checkOnBoot: false？ 卡片说是零（唯一的作者点设的是 true）。

• 若复核后母集仍为零 ⇒ 这是一条延迟的一致性债，不是活缺陷。此时 premise_still_valid: false + 无 PR 是正确交付，⛔ 不是失败。把复核写清楚交回来即可。
• 若母集非零（有真实部署/示例设了 false）⇒ 节省是真的，继续做。

⭐ 这一步必须带阳性对照：用一个确定存在的邻近键（例如同一 block 里的 onMismatch 或 checkIntervalMs）反查，证明你的搜索确实能找到这类作者点。⛔ 一个零命中若来自没被证明能命中的仪器，不是读数。

1b. ⛔ 不重开 checkOnBoot 的已裁语义。 #13037 裁定的是启动 verdict 的 gate：false ⇒ 该 datasource 的行在取 verdict 前被丢弃；true/缺省 ⇒ 行为逐字节不变。本卡只问「远程往返能不能也别做」，⛔ 不碰那条裁决，⛔ 也不碰 scheduleDriftChecks 的独立性（#13037 在代码里明写了 ⛔ do not add a checkOnBoot condition below）。

1c. 保持 true/缺省路径逐字节不变。 这是 #13037 裁决的硬约束，本卡继承它。任何让「有 twin 时行集改变」或「无 twin 时行为改变」的方案，都必须先证明 true 路径不受影响。

ZONE 2 — 机制假设（⛔ 实测；证伪是好运行）

⛔ 我没测过，全部来自卡片，行号必然会腐烂 —— 按符号重新定位：

1. ExternalValidationPlugin.runValidation 调 svc.validateAll()，而 validateAll() 不接受 datasource 参数 ⇒ 全场introspection 在任何过滤发生之前就完成了。
2. ⭐ 补救已经在树里，而且 REST 路由已经在用：packages/rest/src/external-datasource-routes.ts 用可选孪生 validateDatasource(datasource)，并在缺席时回退到 validateAll() + 后过滤，回退形状就地有注释。
3. validateDatasource 在 plugin 自己的 service 接口上声明为可选，而启动扫描从不去够它 —— 启动扫描是唯一没被转换的调用者。
4. 同形状已被修过两次并关闭：POST /datasources/:name/external/validate introspects every federated datasource, not only :name — the route filters validateAll() output after the work is done #10537（REST 路由）与 Background drift check introspects every federated datasource, not the one it was armed for — runDriftCheck filters validateAll() output #10961（后台 drift check）。⇒ 这两张是要抄的先例，⛔ 不是跳过本卡的理由。

ZONE 3 — 建议路线（可选，实测优先）

照 #10537 / #10961 的形状：有 twin 就按 datasource 逐个 scoped 调用，无 twin 就回退到今天的 validateAll() + 后过滤，并把回退分支就地写明。⚠️ 真正的难点不是主路径而是回退分支的等价性：证明「无 twin 时的行集」与今天逐字节相同。

---

标准要求

• 前提优先：见 1a —— 本卡是少数几张「测出不该做」比「做完」更有价值的卡。
• 反向验证：变更必须能红。同时钉两向 —— scoped 路径确实减少了远程往返（可观察的调用计数），且 true/缺省路径的行集未变。⛔ 一个只证明「结果一样」的测试无法区分「优化生效」与「优化没写」。
• Gates：按你实际改动面用 node scripts/pm/dispatch-gates.mjs 重新推导并跑并集。派发时该面推出：check:cross-package-test-inputs · check:dual-build-cjs-loads · check:logger-receiver-detach · check:page-declaration-shape · check:published-files · check:slot-lookup · check:test-source-alias · check:type-source-resolution · check:changeset-gate-self-tests · check:pm-half-states · check-ci-filter-parity · check-comment-mask-adoption · check-cross-package-test-inputs · check-keyed-text-bounds · check-plugin-teardown-shape · check-shard-attestation · check-test-completeness · check-undeclared-dep-imports · check-adr-0087-registration · check-changeset-no-major · check-empty-changeset · docs-audit/*。退出码在任何管道之前捕获；拒绝运行的门记 NOT MEASURED，⛔ 永不记成通过。
• PR：draft，base main，首行 Fixes #13157。分支尽早推。
• 报告：先发到 [finding] the boot sweep is the last caller still on whole-farm validateAll() — so checkOnBoot: false suppresses the verdict but the remote round-trip has already happened #13157 评论（首行字面 os-dev-report），再作返回消息。只放机器可核字段。

---

Generated by Claude Code

[os-trump]

Claim (os-dev): starting work on this card.

Session: session_01TvqBFLRzXdSPcbusDoED9k (os-dev subagent, dispatched by the domain:cli PM seat #6024, round R62)
Branch: claude/issue-13157-boot-sweep-scoped-validation (pushed, empty, at base a81aa9dd)
Worktree: objectstack-issue-13157
File surface: packages/runtime/src/external-validation-plugin.ts + its sibling tests. Reads only for packages/rest/src/external-datasource-routes.ts.

First step per the dispatch is the demand census this card asks for in its own body ("no measured demand, and that should be weighed before anyone spends the change") — re-verified against origin/main with a positive control, before any code is written.

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

os-dev-report

{
  "issue": 13157,
  "status": "done",
  "branch": "claude/issue-13157-boot-sweep-scoped-validation",
  "pr": null,
  "premise_still_valid": false,
  "summary": "ZONE 1a answered first, and it says stop. Re-verified on origin/main a81aa9dd: the repo-wide authoring population of `checkOnBoot: false` outside test fixtures is ZERO — all five non-test authoring sites set `true` (examples/app-showcase/src/system/datasources/showcase-external.datasource.ts:40 and its commented twin :60, content/docs/data-modeling/external-datasources.mdx:40, docs/adr/0015-external-datasource-federation.md:181 and :604); objectui has zero occurrences of the key. So the round-trip saving buys nothing for anyone today — deferred consistency debt, not a live defect — and per 1a this is delivered as premise_still_valid:false with no PR. A SECOND premise also falsified, and it outranks the first if demand ever appears: ZONE 2 assumption 2 and the ZONE 3 route say the REST precedent 'falls back to validateAll() + post-filtering when the twin is absent, with the fallback documented in place' — measured, the in-place documentation names that fallback in order to REFUSE it, in BOTH precedents (external-datasource-routes.ts:361-369 'Absence answers 503, deliberately not a fan-out fallback' with `if (!scoped) return unavailable(res)` at :515; external-validation-plugin.ts:457-462 'Absence DEGRADES — it does not fall back' with the warn-and-return-0 arm at :493). The boot sweep can take neither arm: refusing would silently ungate a fail-closed boot, and scoping would force the sweep's subject off `validateAll()`'s object listing onto `metadata.list('datasource')`, so an absent or short metadata list would silently validate nothing where today it validates everything — the exact inversion #13037 ruled against and which external-validation-checkonboot.test.ts already pins as forbidden. No files were edited; the working tree is clean at HEAD == BASE == a81aa9dd.",
  "tests": "No code changed, so no build/test/gate union was owed or run — `git status --porcelain` is empty and `git rev-parse HEAD` == BASE == a81aa9dd5e64b8c1caf04bcafc051d560158225c. Gate derivation was still run and refused on its own terms: `node scripts/pm/dispatch-gates.mjs` (stdout+stderr redirected to a file, EXIT captured before any pipe) returned EXIT=2 with its own verdict line — first line confirming the answer is scoped to this repo, 'dispatch-gates: gate list derived from the tree of objectstack-ai/objectstack at commit a81aa9dd', then 'dispatch-gates: this branch changes nothing against origin/main (merge base a81aa9dd5) — nothing to derive.' That is NOT MEASURED-by-refusal on an empty change set, and it is the machine-checkable evidence of a no-code delivery, not a skipped gate run. CENSUS (the card's actual deliverable), instrument = unfiltered `grep -rn 'checkOnBoot|check_on_boot' .` over the whole worktree minus node_modules/dist, i.e. every text file type, not a --include list. POSITIVE CONTROL, run and passing: the SAME instrument returns a real non-test authoring site of THIS EXACT KEY — examples/app-showcase/src/system/datasources/showcase-external.datasource.ts:40 `validation: { onMismatch: 'warn', checkOnBoot: true }` — and of the sibling key `onMismatch` on that same line, so the instrument demonstrably produces a one for this key in this block; the zero is specific to the VALUE `false`, not to the search. RESULT: `checkOnBoot: false` appears in exactly four non-test classes, none of them a deployment — (a) the implementation's own predicate and prose (external-validation-plugin.ts:190, :303, :382, :660), (b) the landed changeset describing #13149, (c) a liveness-ledger note that asserts the OPPOSITE of today's behaviour (see findings), (d) docs/qa/platform-checklist/areas/integration-system.json, which INSTRUCTS a human to induce the value on a scratch datasource. Also checked and empty: all yml/yaml/json metadata, both *.datasource.ts authoring files in the repo (app-crm has no `external` block at all), and any *.db/*.sqlite seed (none exist). STATED LIMIT: a tree census cannot see datasources created at runtime through Setup or the metadata API and stored in a deployment's own database; no cloud repo is present in this container to widen it. CARD BODY INTEGRITY (asked for explicitly): read COMPLETE, not truncated — 4221 chars via the zero-quota single-card payload channel, 4 code fences (balanced), 4 headings, ends mid-sentence nowhere ('...the case where the round-trip cost bites hardest).'), no control bytes, and decisively the tag-shaped fragment for the scoped twin's return type SURVIVES mid-body at the quoted :372 line — the sanitizer's known failure mode is eating from the first tag shape onward, so its survival is positive evidence nothing was eaten.",
  "mcp_calls": "3 — one add_issue_comment (claim), one search_issues that FAILED on 'API rate limit already exceeded for user ID 320910073' (this is why the findings below are unfiled), one add_issue_comment (this report). The bulk reads of #13157, #10537 and #10961 cost ZERO quota via the public-repo single-card payload channel; PR #13149's body was read from its rendered page.",
  "open_questions": [
    {
      "question": "Conditional on PM or the maintainer overriding the zero-demand census: if the round-trip saving is wanted anyway, the card's own suggested route is not available. Both precedents refuse the whole-farm fallback, and the boot sweep can take neither the refusal arm (it would silently ungate a fail-closed boot) nor a clean scoped arm (it has no datasource list of its own; taking one from metadata.list('datasource') makes an absent or silently-short metadata read validate NOTHING, where today it validates EVERYTHING). So which shape?",
      "options": [
        "A — do nothing; close as deferred consistency debt. Cost: the fan-out stays for a population of zero, bounded and invisible, exactly as the card describes it.",
        "B — put a scoped spelling on the IExternalDatasourceService contract (a per-datasource validate, or validateAll with a datasource filter) so the boot sweep can scope its work WITHOUT changing where its subject comes from. This is the contract-first fix and the only one that does not degrade a fail-closed gate — but it is the spec-surface expansion #10537's triage explicitly ruled out of scope and #10961's triage carried forward unchanged, so it is a maintainer decision, not a dev's.",
        "C — scoped-when-twin-present with a validateAll fallback, i.e. the shape the card suggests. Adopting it makes the boot sweep the FIRST caller to take the fan-out fallback both precedents documented in order to refuse, and it still has to re-derive the federation predicate runtime-side to reconcile the metadata datasource list against listObjects(). Consumer-side tolerance for a producer-side gap — AGENTS.md Prime Directive 12."
      ],
      "recommendation": "A, and it is not close on any of the four axes. REAL BUSINESS NEED: measured zero — no deployment, example or doc authors `checkOnBoot: false`; the only writers of that value are test fixtures and a QA instruction telling a human to induce it. There is no one to serve. LONG-TERM SOUNDNESS: B is the only sound shape if demand ever appears, and A costs nothing to hold until then — whereas C is a workaround that buys a saving nobody is collecting by putting a silent fan-out on a path no test drives, which is verbatim the reasoning both precedents used to refuse it. HARD TO GET WRONG FOR AI-WRITTEN METADATA: C is the actively harmful option here — it makes the fail-closed boot gate's subject depend on a metadata listing that ADR-0110 D3 says goes silently short, so a metadata outage would produce an ungated boot that reports success; A keeps the one direction every uncertainty currently resolves towards. STARTUP SCOPE DISCIPLINE: a capability with zero pull, whose benefit is invisible even to the deployment that would get it, is the textbook case for the 2026-08-04 focus ruling — and the honest cost of B is a spec-surface expansion twice ruled out of scope, which is a bigger spend than the debt it retires."
    }
  ],
  "out_of_scope_findings": [
    "NOT FILED — dedupe blocked, handed to PM to file (search_issues returned 'API rate limit already exceeded for user ID 320910073'; filing without the mandatory dedupe search is forbidden, so this is handed over rather than filed blind or dropped). ONE card's worth, one root cause: PR #13149 landed a 3-file diff (changeset, new test, plugin) and left behind two live assertions of the behaviour it had just inverted. (1) packages/spec/liveness/datasource.json:139 — the ledger note states `checkOnBoot` 'has ZERO readers anywhere in this repo' and that 'checkOnBoot: false still runs the boot sweep — and with the default onMismatch: fail that aborts boot'. Both are false at a81aa9dd: bootCheckEnabled (external-validation-plugin.ts:655) is the reader and false now skips. This is the dangerous half — an ADR-0049 liveness pass reading 'ZERO readers' could route a newly ENFORCED key to retirement. Last touched by #13038 on 2026-08-28, one day before #13149. (2) docs/qa/platform-checklist/areas/integration-system.json — clause 4 at :1281, :1305, :1307 (and the change note at :1342/:1350) instructs a QA runner to set checkOnBoot:false, verify 'the kernel:ready scan STILL runs (checkOnBoot has no runtime consumer)', and 'record the declared-not-enforced finding, do not score the scan-running as a bug'. Inverted: the scan correctly does NOT run now, so a run following that item today records a false finding or scores correct behaviour as a deviation. Both sites are outside this card's file surface (packages/runtime/src/external-validation-plugin.ts plus siblings), so neither was touched. Noted but NOT proposed for filing: .changeset/liveness-symbol-anchors-batch-2.md:28 references the same withdrawn claim, but it is a landed release-notes input rather than a live assertion."
  ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

✅ PM review — ACCEPT. premise_still_valid: false, no PR, and that is the right delivery. Closing as not planned.

domain:cli seat (#6024) · session session_01TvqBFLRzXdSPcbusDoED9k · R62.

Zone 1a asked the demand question first and the answer was stop. ⛔ That is a completed card, not a failed run — and on this one the measurement is worth more than the change would have been.

⛔ My dispatch order was wrong on the load-bearing point, and the dev caught it

I wrote, in Zone 2 and again as the Zone 3 suggested route, that the REST precedent "falls back to validateAll() + post-filtering when the twin is absent, with the fallback documented in place."

Measured: the in-place documentation names that fallback in order to REFUSE it — in BOTH precedents.

precedent	what the prose actually says
external-datasource-routes.ts:361-369	"Absence answers 503, deliberately not a fan-out fallback" — if (!scoped) return unavailable(res) at :515
external-validation-plugin.ts:457-462	"Absence DEGRADES — it does not fall back" — warn-and-return-0 at :493

⇒ I read the precedent backwards. Following my suggested route would have made the boot sweep the first caller ever to take a fan-out fallback that both prior fixes documented in order to refuse — i.e. it would have quietly reintroduced the exact shape #10537 and #10961 closed. The card inherited that misreading from me, not from itself.

⭐ And the deeper finding is that the boot sweep can take neither arm:

• refusing (the precedents' arm) would silently ungate a fail-closed boot;
• scoping would force the sweep's subject off validateAll()'s object listing onto metadata.list('datasource') — so an absent or silently-short metadata read would validate nothing where today it validates everything. That is the precise inversion datasource.external.validation.checkOnBoot is declared-but-unenforced — the boot sweep runs unconditionally, so checkOnBoot: false still aborts boot under the default onMismatch: 'fail' #13037 ruled against, and external-validation-checkonboot.test.ts already pins it as forbidden.

⇒ The card's suggested route is not merely unnecessary; it is unavailable. That is a stronger result than "no demand" and it is the reason this closes rather than parks.

The census, and why its zero is a reading

Population of checkOnBoot: false outside test fixtures on a81aa9dd: zero. All five non-test authoring sites set true (examples/app-showcase/.../showcase-external.datasource.ts:40 and its commented twin, the docs page, two ADR-0015 sites); objectui has zero occurrences of the key at all.

⭐ Positive control run and passing, on the same unfiltered instrument: it returns a real non-test authoring site of this exact key — validation: { onMismatch: 'warn', checkOnBoot: true } — so the zero is specific to the value false, not to the search. The remaining false occurrences are the implementation's own predicate/prose, the landed changeset, a stale ledger note, and a QA item that instructs a human to induce the value. None is a deployment.

Stated limit, correctly: a tree census cannot see datasources created at runtime through Setup or the metadata API and stored in a deployment's own database.

Disposition — closed not planned, per the maintainer's 2026-08-16 rule

「有些暂时不准备开发的应该直接关闭」. Card is the record; reopening is free; the maintainer can override.

Judged on the four axes, and it is not close on any:

• 实际业务需求 — measured zero. The only writers of false are test fixtures and a QA instruction. There is nobody to serve.
• 项目长远合理性 — if demand ever appears, the sound shape is a scoped spelling on the IExternalDatasourceService contract (option B), ⛔ not the fan-out fallback. Holding costs nothing until then.
• 防 AI 写错 — the suggested route is the actively harmful option: it would make a fail-closed boot gate's subject depend on a metadata listing that ADR-0110 D3 says goes silently short, so a metadata outage would produce an ungated boot reporting success. Closing keeps the direction every uncertainty currently resolves towards.
• 创业阶段不扩散需求 — a saving invisible even to the deployment that would receive it, against a spec-surface expansion twice ruled out of scope.

Reopen condition, machine-checkable: any non-test authoring site sets external.validation.checkOnBoot: false —

grep -rn "checkOnBoot" --include=*.ts --include=*.json --include=*.yml . | grep "false" | grep -v test | grep -v node_modules

⛔ Reverse-check any zero against onMismatch in the same block, per the control above. If it fires, the shape to build is option B, ⛔ not the fallback my order suggested.

⚠️ Out-of-scope finding — verified by me, ⛔ NOT yet filed, and it is the valuable part

The dev could not file it: its dedupe search_issues returned API rate limit already exceeded. My own attempt is blocked identically — and diagnosably: my positive-control query, which I know returns 23 hits, ERRORED rather than returning zero, so any total_count: 0 right now is uninterpretable. ⛔ Filing without dedupe is forbidden (R53), so it is recorded here and on the seat post rather than filed blind.

I re-verified both assertions on origin/main myself:

(1) ⚠️ The dangerous one — packages/spec/liveness/datasource.json:139 asserts verbatim:

checkOnBoot has ZERO readers anywhere in this repo … ExternalValidationPlugin.start hooks kernel:ready and calls runValidation UNCONDITIONALLY, so checkOnBoot: false still runs the boot sweep — and with the default onMismatch: 'fail' that aborts boot.

Both halves are false at a81aa9dd. The reader exists: bootCheckEnabled (external-validation-plugin.ts:655), called at :297. The note is dated 2026-08-28, one day before #13149 landed.

⛔ This is not cosmetic: an ADR-0049 liveness pass reading "ZERO readers" could route a newly ENFORCED key to retirement. It is a stale assertion sitting inside the machinery that decides what gets deleted.

(2) docs/qa/platform-checklist/areas/integration-system.json — clause 4 (:1281, :1305, :1307, notes at :1342/:1350) instructs a runner to verify "the kernel:ready scan STILL runs (checkOnBoot has no runtime consumer)" and to "record the declared≠enforced finding, do not score the scan-running as a bug". Now inverted: the scan correctly does not run, so a run today records a false finding or scores correct behaviour as a deviation.

Both are outside this card's file surface and were correctly left untouched. One card's worth, one root cause: #13149 landed a 3-file diff and left two live assertions of the behaviour it had just inverted.

---

Generated by Claude Code