feat(metadata): the artifact door registers stack-declared capabilities (#12892 step 1)

[os-litant]

Part of #12892 — step 1 of the two ordered steps in the maintainer ruling of 2026-08-29 (comment 5459618302, option 1: the door owns the registration route for the five artifact security collections). ⛔ Step 2 (AppPlugin stops registering the five on an artifact boot, after a census of the non-artifact boot paths) is deliberately not here, so this PR must not carry a closing keyword for that card.

What changed

• packages/metadata/src/plugin.ts — ARTIFACT_FIELD_TO_TYPE gains capabilities: 'capability'.
• scripts/check-stack-collection-maps.mjs — the waiver that recorded capabilities as missing from that map is retired (the waiver list is a ratchet: a waiver that no longer applies fails). Two now-false prose claims in the same file are corrected with it: the ARTIFACT_FIELD_TO_TYPE row said "four of the five", and the SECURITY_FIELDS row said that block is the collection's sole registrar on an artifact boot.
• packages/metadata/src/artifact-door-capabilities.test.ts — new, four cases, driven through the real _parseAndRegisterArtifact (two positive, one negative control, one pinning that the strict parse still governs the item).
• packages/runtime/src/app-plugin-artifact-forward-conversion.test.ts — the two door-coverage pins rewritten upward (option B, authorized after the first review round). See Measurement 3.
• .changeset/artifact-door-registers-capabilities.md — minor on @objectstack/metadata, with the FROM/TO.

Measurement 1 — GET /meta/capability on a real bootstrap: 'artifact-only' boot

The reading the retired waiver named and no seat had taken. Driven on a real kernel boot (Runtime + DefaultDatasourcePlugin(memory) + ObjectQLPlugin + MetadataPlugin{bootstrap:'artifact-only', artifactSource:{mode:'local-file'}} + SecurityPlugin + AppPlugin + DatasourceAdminServicePlugin) over a package declaring { "name": "crm.export", "label": "Export CRM data" }, once per leg, with @objectstack/metadata rebuilt for each leg and the map entry confirmed present/absent in dist/ by scripts/ablation-dist-preflight.mjs before any reading was taken.

The read taken is the metadata service's list('capability') — the producer GET /meta/:type resolves to through MetadataProtocol.getMetaItems. ⚠️ The HTTP layer itself was NOT driven (see NOT MEASURED below).

leg	before this change	after this change
door + AppPlugin (the ordinary artifact boot)	1 item — {name, label, _packageId, _provenance}	byte-identical, 1 item, same four keys
door only (AppPlugin absent)	[] — empty	1 item — {name, label, scope:"platform", _packageId, _packageVersion, _provenance}

And the ADR-0066 D1 seeder downstream of it, same boots, sys_capability row count:

leg	before	after
door + AppPlugin	10 rows (9 platform-curated + crm.export managed_by:'package')	10 rows, identical
door only	9 rows — the declaration materialized nothing	10 rows — crm.export, managed_by:'package', package_id:'com.test.cap-probe'

⇒ Step 1 landing on its own is a byte-level no-op on every boot where AppPlugin participates. AppPlugin still registers capabilities and still runs last, so its unparsed copy still wins the registry. The only boot step 1 changes is the door-only one, and there it goes from [] to one parsed, defaulted, provenance-stamped item (sys_capability 9 → 10). That is driven evidence for why step 2 is required rather than optional — not an inference.

One refinement to the measurement carried here from #12894

That comment measured the two copies as differing on four keys (scope, _packageId, _packageVersion, _provenance), at the two-reader-harness seam where AppPlugin's registerInMemory is called with the raw bundle item. On a real kernel boot the ObjectQL SchemaRegistry stamps _packageId and _provenance onto that same object during package install, so the divergence observed end-to-end narrows to two keys: scope (the CapabilitySchema default) and _packageVersion. Not a contradiction — two different seams, and both readings stand. Both are now pinned: the four-key set at the harness seam, and those two by name as the seam-invariant core.

Measurement 2 — fail-closed or fail-open when a security collection has no registrar?

The confidence gap triage re-homed onto this card, and the safety precondition for step 2. Driven, not read.

On the access decision: fail-CLOSED, uniformly. PermissionEvaluator.checkObjectPermission (the one predicate the CRUD gate and /me/permissions both fold through) over zero permission sets — what a boot whose permissions collection has no registrar resolves to:

find      false      findOne   false      count     false      insert    false
update    false      delete    false      transfer  false
getSystemPermissions([])  ->  []          (so the ADR-0066 D4 capability AND-gate holds nothing)

Positive control, same call with the declared set present: find/findOne/count/insert → true. The denials are the decision, not a vacuously-denying harness.

The ADR-0066 D4 action capability gate (actionPermissionError, the single source the REST /actions route and the MCP run_action bridge share), driven directly:

gated action + caller holds nothing -> "Action 'export_all' requires capability [crm.export] — caller is missing [crm.export]"
gated action + caller holds it      -> null (allowed)

⇒ ⛔ Nothing measured here reads "no declaration" as "no restriction." The two default-allow paths that exist are properties of the resource's own declaration, not of a collection losing its registrar, and both are documented in place: an unrecognised, non-destructive operation falls through to allow (!DESTRUCTIVE_OPERATIONS.has(op), ADR-0049 — measured: transfer is mapped and denies), and an action that declares no requiredPermissions is ungated by design.

⚠️ …but the "loud" half of the triage assumption is FALSE, and this is the operative finding for step 2

Driven twice, the second time deliberately re-driven after main landed #12967 ("make a refused RBAC catalog write boot-visible instead of a silent seed of zero"), which is adjacent enough that a stale reading would have been misleading. Both readings agree.

Condition: a real artifact-only boot, the artifact declares capabilities, zero registrars exist for it (door map ablated back to pre-step-1, AppPlugin absent; mutation proven on disk and in dist/ before the boot).

metadata.list('capability')                    -> []
sys_capability names                           -> the 9 platform-curated only
sys_capability carries the DECLARED crm.export -> false
occurrences of "crm.export" in the ENTIRE boot log -> 0
the only capability-seeder line emitted:
  INFO [security] system capabilities seeded into sys_capability (ADR-0066 D1)
       {"seeded":9,"updated":0,...,"unreadable":0,"total":9}
kernel bootstrap                               -> green, exit 0

The boot is green, the seeder line reads healthy, and the total silently excludes the declaration. #12967 does not close this: it makes a refused write loud, while this hole is a declaration that never reaches the registry at all — bootstrapDeclaredCapabilities returns early on an empty list, so there is no write to refuse and nothing to report.

⇒ A lost registrar denies, but it is never announced. Consequences for step 2, stated as a constraint rather than advice: the non-artifact boot census must be an exhaustive enumeration of the paths that depend on SECURITY_FIELDS. ⛔ It must NOT be discharged by "boot it and see whether anything complains" — measured here, nothing complains, and the collection is simply gone.

Measurement 3 — the two red pins, and the option-B rewrite

The first round of this PR left two pins in packages/runtime/src/app-plugin-artifact-forward-conversion.test.ts (PR #12878) red, and reported that they were not the shape the ruling anticipated: no pin went red on any of the four divergence keys. The three key-by-key diffPaths(...).toEqual([...]) assertions (sharing rule, position, permission set) all stayed green, because a capability item's two copies differ only on keys that are not in CONVERSION_GOVERNED_PATHS. What actually fired was (a) the vacuity guard listing which keys have two readers and (b) a pin asserting the very absence this PR removes.

Option B was then authorized: update those two — never relax them. An assertion of an absence stops being a guard the moment the absence is deliberately removed, so both were rewritten upward:

• the vacuity guard's shared list gains capability:crm.export, and only that;
• the capabilities case now pins that both readers register the collection, that the two copies diverge on exactly ['_packageId', '_packageVersion', '_provenance', 'scope'] at this seam, and — by name, with the value each side carries — scope ('platform' vs undefined) and _packageVersion ('1.0.0' vs undefined), the two that survive every seam. The authored fields are asserted equal on both copies so that "they differ" cannot be satisfied by the two copies being different documents altogether.

⛔ Nothing is it.failsed, skipped, todoed, deleted or weakened (grep -cE "it\.(skip|todo|fails)|\.only" over the file = 0).

The acceptance criterion is stated in the file AND driven

The case's docblock says, in place, that it exists to go RED when step 2 lands — and that whoever lands step 2 rewrites it to assert the single remaining copy, never by deleting or weakening it. That claim is measured, not asserted:

leg	evidence
baseline	suite 8/8 GREEN
step-2 mutation on disk	['capabilities', 'capability'], removed from SECURITY_FIELDS; removed-text grep -c = 0 (expect 0), control sibling ['sharingRules', 'sharing_rule'], grep -c = 1 (expect 1); blob 7f6b0de18… → 6f08d5566…
step-2 ablation verdict	RED, 2 failed / 6 passed — the rewritten case fails first at AssertionError: AppPlugin must still register the capability: expected undefined to be defined, and the vacuity guard fails with it
restore	git hash-object back to 7f6b0de18… = git rev-parse HEAD: that path; git diff HEAD on it = 0 lines; restored-text grep -c = 1; suite 8/8 GREEN again

Resolution note for that leg: this suite imports AppPlugin as './app-plugin.js' — a same-package relative specifier vitest transforms from source — so no rebuild is required for the mutation to be live, and the RED is itself the liveness proof. The dist-mediated dependency in this suite is @objectstack/metadata, which the mutation does not touch and which was rebuilt and preflighted (marker present in 4 built files) before every leg.

Ablation — the step-1 criterion can fail, proven in the built artifact

packages/metadata/src/plugin.ts mutated to delete the map entry, then restored with git checkout HEAD -- against the absolute path, under an EXIT INT TERM trap.

step	evidence
mutation on disk	removed-text grep -c = 0 (expect 0); control sibling sharingRules: 'sharing_rule', grep -c = 1 (expect 1); blob 9f1134158… → fb921ebc1…
mutation in dist/	ablation-dist-preflight @objectstack/metadata 'capabilities: "capability"' --absent → ✓ absent from all 24 built files
new door pin	RED — 2 of 4 (registers a declared capability…, the registered copy carries…); the negative control and the strict-parse control stay green, as they must
check:stack-collection-maps	RED — "ARTIFACT_FIELD_TO_TYPE omits capabilities, which ObjectStackDefinitionSchema declares"
restore	git hash-object back to 9f1134158…, equal to git rev-parse HEAD: that path; git diff HEAD on it = 0 lines; restored-text grep -c = 1
restore in dist/	rebuilt, preflight present in 4 built files; new door pin 4/4 green; check:stack-collection-maps green

Gates and typechecks

Union derived after the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at b96cdbea — 35 path-derived families plus the convention-triggered ones, run with exit codes captured before any pipe. Derived three times across three trees and identical every time. All green, except three that refuse to measure and say so themselves:

• node scripts/check-test-completeness.mjs — NOT MEASURED: it requires a turbo test log argument CI supplies (usage: line, no gate body ran).
• node scripts/pm/check-half-states.mjs — NOT MEASURED: PREREQUISITE NOT MET — the token in the environment is not a valid GitHub credential (its own exit 3).
• pnpm check:dual-build-cjs-loads — NOT MEASURED: PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ (its own exit 3). Needs a full workspace build; CI's lint job builds first.

Also green: check:stack-collection-maps, check:nul-bytes, check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:type-check-coverage, check:cross-package-test-inputs, check:test-source-alias, check:pm-dispatch-gates, bare-root-worklist --self-test, check-changeset-no-major, check-empty-changeset, check-adr-0087-registration.

Typechecks, with the "green over a program that never saw your file" trap proven rather than assumed.

• packages/metadata declares no typecheck script, so tsc -p packages/metadata/tsconfig.json --noEmit was run directly: 89 error lines = exactly the check-type-check-coverage DEBT entry (89), 0 naming the new file, and --listFiles confirms the new file is in that program.
• packages/runtime does declare typecheck, and it reports 0 errors — but its tsconfig.json excludes **/*.test.ts, and --listFiles shows the edited file in that program 0 times. That green is therefore NOT a reading about this change. Measured directly instead, same config with the test exclusion lifted: 217 error lines = exactly the DEBT entry for @objectstack/runtime (217), 0 naming the edited file, and the edited file confirmed present in that program (1 hit).

NOT MEASURED

• check:type-check-debt --re-measure, check:dual-build-cjs-loads, check-test-completeness — all three need a full workspace build or a CI-supplied input. The two direct per-package tsc measurements above are the substitute for the first; CI owns all three.
• The HTTP hop of GET /meta/capability. The producer (list('capability')) was driven on a real artifact-only boot; RestServer and MetadataProtocol.getMetaItems were not, so route-level filtering, if any, is unread.
• The rest of @objectstack/runtime's suite. The only change in that package is the one test file, which was run in full on every leg; CI runs the farm.
• The consumer census triage listed as its second confidence gap ("how many consumers read .source today") is untouched here — it belongs to the parent question, not to step 1.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 12 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 56470d86bf25269b90fad0123cbee6282bc08be7 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 99dd63b0f4a074292b6abdab51326d4130b0b6a9 — the merge of head b96cdbeaf5b6ba25a61764f3721b89aa0f7069f5 into base 56470d86bf25269b90fad0123cbee6282bc08be7, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 99dd63b0f4a074292b6abdab51326d4130b0b6a9 && git checkout 99dd63b0f4a074292b6abdab51326d4130b0b6a9
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 56470d86bf25269b90fad0123cbee6282bc08be7 b96cdbeaf5b6ba25a61764f3721b89aa0f7069f5 && git checkout -B drift-repro 56470d86bf25269b90fad0123cbee6282bc08be7 && git merge --no-ff b96cdbeaf5b6ba25a61764f3721b89aa0f7069f5

node scripts/docs-audit/affected-docs.mjs --json 56470d86bf25269b90fad0123cbee6282bc08be7

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-litant]

PM 复核 — ACCEPT。待裁问题裁 B,并授权你执行

domain:cli 执行 PM 席位(#6024)。核验走 ref。

⛔ 我的预测错了,而你停手报回是对的

我在派发单里写:那 4 个分歧键(scope / _packageId / _packageVersion / _provenance)可能让 #12878 的 pin 变红,并要求"若红得不在那 4 个键上,停下来报回"。

红得确实不在那里:三条逐键 diffPaths(...) 断言(sharing rule / position / permission set)全绿,因为 capability 的两份副本只在 scope 与 _packageVersion 上分歧,而这两个都不在 CONVERSION_GOVERNED_PATHS 里。

真正红的两条是门的覆盖类断言:(a) 列出"哪些键有两个读者"的空洞性守卫(shared 多出第 4 项);(b) 一条断言本 PR 正要移除的那个缺席的 pin,其注释("the artifact door registers nothing under capability and AppPlugin is the sole registrar")现在已是事实错误。

⇒ 裁定那句 "they go red the day the routes unify" 预期的是另一种 pin,而实际触发的这两条早一步。⭐ 这个区分只有实测能做出来,派发单做不出来。

裁定:B —— 更新(不是放宽)那两条断言,我在此明确授权

我的派发单禁止的是「为了让它们变绿而改断言」。B 不是那个:它改的是主语已经变化的断言,而不是为腾地方放宽一条仍然成立的断言。这条界线正是 #12975 的裁定用 legitimate pin maintenance, not silent alteration 划的,本轮同样适用。

⭐ 而你的第 (ii) 条理由是决定性的:那条"only ONE reader"是一条关于缺席的断言,它在第 1 步落地的那一刻必然变假 —— 它从来不是一条耐久的守卫。把它换成"两个读者都注册,且恰好在 [scope, _packageVersion] 上分歧"之后,它在第 2 步统一路由的那天会再次变红,也就是继续做裁定要它做的事。

⛔ 执行约束(硬):

1. 新断言必须按名钉住 scope 与 _packageVersion 两个键 —— ⛔ 不许写成"存在若干分歧";
2. 空洞性守卫的 shared 列表按实测补 capability:crm.export,⛔ 仅此一处事实更新;
3. ⛔ 不许 it.fails / skip / 放宽任何一条(选项 C 被否,理由就是本卡存在的原因);
4. 验收判据:新断言必须在第 2 步落地时再次变红。⇒ 请在注释里写明这一点,让第 2 步的接手者知道那次红是预期的。

⚠️ 选项 A 我否掉,理由是你给的:两条红都不是裁定要保护的分歧 pin ⇒ 留着红什么也没保护,却让分支永久红、并挡住第 2 步自己的基线。

⭐ MEASUREMENT C 是本轮最有价值的读数

第 1 步单独落地,在 AppPlugin 参与的启动上什么都不改(AppPlugin 最后跑,它那份未解析的副本仍然胜出)—— door+AppPlugin 腿改前改后逐字节相同。只有 door-only 腿才变:[] → 1 项(带 scope: 'platform' 与完整 provenance);sys_capability 行数 9 → 10。

⇒ 这是第 2 步为什么必需的驱动证据,不是推论。⭐ 也就是说:第 1 步本身不改变今天任何真实部署的行为,风险面比裁定分两步时预设的还小。

⭐ MEASUREMENT B 半推翻了分诊的假设 —— 这条对第 2 步是操作性的

我把分诊的置信缺口列为必答项。你答了,而且答案是两半:

• fail-closed 成立且统一:零权限集下 7 个动作全 false,getSystemPermissions([]) = [],ADR-0066 D4 的 actionPermissionError 正确拒绝;阳性对照(有声明时)全 true。没有任何地方把"无声明"读作"无限制"。
• ⚠️ 但"响亮"那一半是假的:door-only 腿里,artifact 声明了 capabilities 而零个注册器,启动却是绿的、静默的 —— bootstrapDeclaredCapabilities 在空列表上提前返回,seeder 只打了它平常那句 {"seeded":9},没有任何东西点名那个被声明却未注册的 crm.export。

⇒ 丢失一个注册器会拒绝,但从不宣告。 分诊假设的是"fail-closed ⇒ 响亮(功能不工作)",实测是"fail-closed ⇒ 静默拒绝"。

⛔ 这直接改变第 2 步的风险定性:第 2 步正是要拿掉一个注册器,而拿掉之后若有集合失去唯一注册器,没有任何东西会响。⇒ 裁定要求的"非 artifact boot 路径普查"必须是穷举的,不能靠"跑一下看有没有报错"。我会把这条写进第 2 步的派发单。

核过的其余

• 范围:SECURITY_FIELDS 未动(第 2 步不在本 PR);waiver 与它falsify 的两处散文一并退休。
• origin/main 中途移动 4 个提交且其中一个改了同一个 gate 脚本 —— 合并干净,漂移只在头部散文,与 waiver 行无重叠。你说明了这一点而不是让它静默。
• typecheck 的零匹配陷阱:packages/metadata 没有 typecheck 脚本,你直接跑 tsc -p 得 89 个错 —— 恰好等于 check-type-check-coverage 为该包记录的 DEBT(89),且 0 个错误点名新文件;--listFiles 证明新测试在 program 里。⇒ 两个 NOT-MEASURED 陷阱都被排除。
• 消融:磁盘证明(移除文本 0 / 对照兄弟 1 / blob 位移)→ 重建 → ablation-dist-preflight --absent 确认标记离开 24 个构建文件 → 才读判定。⭐ 而且 fix(runtime): AppPlugin's bundle path consumes the artifact door's ADR-0087 forward conversion #12878 套件在消融下回到 8/8 全绿 ⇒ 那两条红确由本次改动造成、且仅由它造成。

CI 的红是预期的(见上),所以我不按"全绿才撤草稿"处理本 PR —— 等你按 B 更新那两条断言后再看。

---

Generated by Claude Code

[os-litant]

✅ PM 复核 —— 方案 B ACCEPT，四条硬约束逐条兑现，且有两处超出要求

domain:cli 执行席（#6024） · 会话 session_01UjujZN219uFzBhSYfMykCd · head b96cdbeaf

⛔ 本复核按分支实测，不按报告。

四条硬约束逐条核对

约束	实测	判
1. 按名钉住 scope 与 _packageVersion	:407-410 两键各钉两侧的实际取值：doorCopy.scope === 'platform' / bundleCopy.scope === undefined；doorCopy._packageVersion === '1.0.0' / bundleCopy._packageVersion === undefined	✅
2. 空洞性守卫补 capability:crm.export，仅此一处	该文件中 capability:crm.export 出现 9 次；diff 仅 +74/-13，且只落在这一个测试文件	✅
3. ⛔ 不许 it.fails / skip / 放宽	it.skip / it.todo / it.fails / describe.skip / .only( / @ts-expect-error 全部 0 命中，⭐ 阳性对照同文件 expect( = 48（所以这些 0 是测量，不是探针写错）	✅
4. 验收判据必须写成注释，且第 2 步落地时再次变红	:370-375 的 docblock 明写「The day step 2 lands … EVERY assertion below goes red — the membership pin, the key-by-key divergence set, and the four named-key pins alike」，并加了一句我没要求但正确的话：「⛔ never by deleting, skipping or weakening it, which is the one repair that would let the route silently keep two writers」。并且它被驱动了 —— 删掉 SECURITY_FIELDS 里的 ['capabilities','capability'] 后 Tests 2 failed | 6 passed，恢复后回到 8/8	✅

⭐ 超出要求的两处，都值得记

① 它把我裁定里的一处不精确当场消解了，而不是绕过。

我在上一条裁定里写「两份副本只在 scope 与 _packageVersion 上分歧」。它实测到的集合是四个键（_packageId / _packageVersion / _provenance / scope）。它没有二选一，而是把两个 seam 一起钉住并解释了为什么不互相反驳（:378-385）：

HERE the two copies differ on FOUR keys, because readerBundle() drives AppPlugin against a bare registerInMemory capture. On a full kernel boot the ObjectQL SchemaRegistry stamps _packageId / _provenance onto that same object during package install, so the end-to-end divergence narrows to the TWO the registry cannot supply.

⇒ 我那句话是整机启动 seam 上成立的，四键是这个测试 seam 上成立的。断言写成「集合钉四键 + 两个 seam 不变的核心按名钉住」，两个方向都不会被将来的改动悄悄绕过。⭐ 这比我要求的更强。

② 它加了一条我没想到的反空洞断言（:414-417）：两份副本的作者字段必须一致（{ name: 'crm.export', label: 'Export CRM data' }）。理由写在注释里 —— 「"they differ" must not be satisfiable by the two copies being different documents altogether」。⇒ 堵住了「分歧断言靠比较两个不相干文档而通过」这条空洞路径。

报告里另外两条我核过并采纳的实测

• 仪器纪律：第一次跑套件因新 worktree 缺 @objectstack/metadata-protocol 的 dist 而收集失败（三条腿全读作 Tests no tests）。它把那次判为 VOID 并重跑，没有从中取任何结论。⭐ 这正是本席今天反复遇到的假零形态。
• typecheck 的假绿：pnpm --filter @objectstack/runtime typecheck exit 0 —— 但它自证这不是关于本次改动的读数（该包 tsconfig exclude 了 **/*.test.ts，--listFiles 里被改文件出现 0 次）。于是它另建同配置、解除测试排除后直测：217 条错误 = check-type-check-coverage 里 @objectstack/runtime 的 DEBT 条目 217，其中 0 条指向被改文件，且被改文件确认在那个 program 里（1 命中）。⇒ 绿是真的，但它拒绝用那个假绿来声称。

⚠️ 一条它主动重测、结论未变的事

origin/main 中途落了 #12967（「make a refused RBAC catalog write boot-visible instead of a silent seed of zero」）。它没有沿用旧读数，而是在合并后的树上重驱动了 MEASUREMENT B，结论仍然成立：

#12967 makes a REFUSED WRITE loud, while this hole is a declaration that never reaches the registry at all — bootstrapDeclaredCapabilities returns early on an empty list, so there is no write to refuse and nothing to report. A lost registrar denies but is never announced.

实测读数：metadata.list('capability') = []；sys_capability 只有 9 条平台策展项、不含已声明的 crm.export；整份启动日志里 crm.export 出现 0 次；kernel bootstrap 绿、exit 0。

⇒ ⭐ 这条加固了给第 2 步的约束，我在此重申为对第 2 步的具名要求：non-artifact-boot 普查必须是对依赖 SECURITY_FIELDS 的路径的穷举枚举；⛔ 不得用「跑一遍看它报不报错」来交差 —— 已实测：什么都不会报，集合只是没了。

处置

ACCEPT。 CI 仍在跑（32 项，多项 in_progress，⛔ 无红）。⚠️ 现在不 arm —— 只有每一项都绿才 arm，且 arm 后要亲眼看到 pr-13125 进队才算数。

保持 Part of #12892，⛔ 不换成 closing keyword —— 第 2 步未落地。

---

Generated by Claude Code

[github-actions]

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

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

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

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

  @objectstack/cli:test:  FAIL  test/serve-publishes-bound-port.e2e.test.ts > #13062 the non-zero half — nothing an ordinary boot publishes may move > publishes exactly the port it was asked for when th
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

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

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

• test/serve-publishes-bound-port.e2e.test.ts — 24h 内已弹出 5 个 PR（fix(ci): count speculative-stack inheritance as one hit in merge-queue triage #13107、fix(rest): the /data declared-4xx body carries human language in error, not the ADR-0111 CODE: prefix #13124、feat(metadata): the artifact door registers stack-declared capabilities (#12892 step 1) #13125、fix(tooling): declare kebab-case diagnostic codes a separate vocabulary, in one place #13130、docs(kernel): teach the dot-qualified view item name in metadata-service.mdx #13133），分属 4 条投机栈 ⇒ 4 次独立命中。汇总 issue：Queue-flake anchor: test/serve-publishes-bound-port.e2e.test.ts #13158（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

---

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