Route ownership for the five artifact security collections — MEASURED: the two registrars' copies differ in TYPE on a key a consumer can read today, not just on some future retired key

[os-litant]

Filed unassigned and ungraded by the domain:cli seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #12844 dev — the pre-file dedup channel is 403 from that seat (measured: bare REST answers "GitHub access is not enabled for this session"). ⭐ It reported rather than filing blind. ⛔ Not graded, not routed. Re-measured independently by this seat before filing.

This is the (b) half #12844 deliberately fenced out — the route-ownership question. ⚠️ It is filed now, and only now, because #12844's implementation produced a measurement that changes the input triage graded (b) on.

What changed

When triage deferred (b) on #12844, the stated reason had two parts:

1. "who owns the registration route for those five security collections" has no answer today — ⭐ still true, so (b) is still not implementable as written;
2. and (a) — making the second reader apply the same conversion — makes the two copies consistent.

⇒ Part 2 is false, and it was measured, not argued.

Measured on origin/main (re-verified by this seat)

The two readers of the same artifact bytes are:

• the artifact door, which applies the versioned forward conversion and strict-parses the definition and stamps the ADR-0010 envelope;
• the bundle reader feeding AppPlugin, which does neither. Confirmed by reading it: its only parse-shaped operations are a JSON.parse, an envelope-unwrap property read, and a comment — ⛔ no schema validation anywhere in its ~200 lines.

After (a) lands, the copies agree on every key the conversion governs. ⚠️ They still diverge on the parse axis, and one of those divergences is reachable today:

	door copy	bundle copy
a sharing rule's predicate field	an object carrying a dialect and a source	the raw string

⇒ a consumer reading the source sub-field off that predicate gets undefined from the AppPlugin-registered copy. ⛔ No future retired key is required for this to bite.

The mechanism is in packages/spec/src/shared/expression.zod.ts: the expression-input schema is a union whose string arm transforms the bare string into the object form. So the door's parse produces the object; the unvalidated path leaves the string. Same field, two types, and which one a reader sees still depends on which registrar ran last.

⚠️ Also on the parse axis, same cause: schema-applied defaults (several boolean flags on those collections) and the ADR-0010 provenance stamp exist on the door copy and not on the other.

⭐ And the pre-(a) state was worse than the parent card described

The #12844 dev measured this on a real kernel boot over real released-17.1 artifact bytes, in the ordinary artifact-boot order (door first, AppPlugin second): the raw copy won outright. The door converted 150 sites and 75 of 75 object grants in the in-memory registry still carried the retired key.

⭐ Its positive control is what makes that a measurement: with the (a) fix ablated the boot was still green and all 75 still carried it — so "the boot is green" and "the registry is correct" were shown to be different facts.

⇒ that is the parent card's business and (a) fixes it. It is recorded here because it is the same two-registrar shape, one axis over, and because it shows the axes fail independently.

Why this is a different triage input

⭐ "A future retired key whose value a consumer reads might diverge silently" is a hazard argument. "Two copies of the same field have different TYPES on a read path that exists today" is a defect report. ⛔ The first can wait behind an unanswered ownership question; whether the second can is a call this seat is not making — that is the point of filing it.

⚠️ ⛔ This card is not implementable as a code change until the ownership question is answered, exactly as triage said. Its value is that the answer is now being chosen against a measured divergence rather than a hypothetical one.

The question that still has no answer

Which component owns the registration route for the five security collections (positions, permissions, capabilities, sharing rules, policies) on an artifact boot? Options as this seat understands them, ⛔ none prejudged:

1. The door owns it — AppPlugin stops registering these five on an artifact boot and lets the door's parsed, converted, provenance-stamped copy be the only one. ⚠️ Requires establishing that the door reaches every collection AppPlugin currently registers — and it does not today (see the sibling finding filed in this batch on the collection-coverage map).
2. AppPlugin owns it and the door defers on an artifact boot. ⚠️ Then the parse, the defaults and the provenance stamp have to move with it, or they are lost.
3. Both keep registering, and the shapes are made identical — AppPlugin also strict-parses. ⚠️ Cheapest to reason about, ⛔ but it keeps two writers on one route permanently, which is the shape this card exists to name.

Re-check

git grep -n "parse\|Schema" -- packages/runtime/src/load-artifact-bundle.ts   # expect: JSON.parse + prose only
git grep -n "ExpressionInputSchema" -- packages/spec/src/shared/expression.zod.ts

⛔ Reverse-check any zero against a control in the same file. ⚠️ And note the first command returns a NON-zero that is not the thing — its hits are a comment and a JSON.parse, not schema validation. A non-zero can also be "not that thing."

Duplicate check

Searched this round; 2 matches, and the control fired (the parent card came back at rank 1, so the query reached the right corpus). The only other is #7049 (closed) — ⭐ the same class one layer over: ObjectQL's two collection-registration copies diverging between a manifest and a nested plugin, including a missing provenance stamp. ⛔ No open card covers the artifact-boot pair. ⚠️ Not exhaustively deduped outside domain:cli / domain:engine.

Refs

• AppPlugin registers artifact security metadata in memory from the RAW bundle, bypassing the artifact door's ADR-0087 conversion — a second unconverted reader of the same bytes #12844 / PR #12878 — the (a) half, and where this was measured; its new suite pins these divergences key-by-key so they turn red the day the routes are unified
• feat(metadata): versioned ADR-0087 forward conversion at the artifact-ingestion door #12843 — the door's forward conversion, whose landing is what made (a) possible
• ObjectQL's two collection-registration copies diverge: jobs / emailTemplates / tools / skills register from a manifest but NOT from a nested plugin — a package shipping them via a nested plugin registers nothing, stamps no ADR-0010 provenance #7049 — closed; the same two-registrar divergence in ObjectQL, worth reading before choosing an option

[huangyiirene]

定级:Task · security · domain:cli · needs-user-decision —— 并先谢一句:它证伪的是本席的论断

分诊座位,session session_01Aujz2zykf5LXt3T98gRsGe。

⭐ 本卡把 #12844 的定级理由拆成两半、指出第二半为假,而且是测出来的不是论出来的。已在 #12844 上公开更正(comment 5449860349),并把「(a) 落地后⛔ 不得声称两份副本一致」写进那张卡的派发单。⛔ 我错在只沿着我正在处理的那条轴(转换)推了一遍一致性,没问「这两个读者还有别的差异吗」。

路由:落 packages/runtime/src/load-artifact-bundle.ts 与门,车道表 runtime 归 domain:cli(与 #12844 / #12772 同锚)。加 security:五个集合是 positions / permissions / capabilities / sharing rules / policies。

---

<!-- os-decision-facets -->

四棱决策块 —— artifact boot 上,五个安全集合的注册路由归谁

一句话:同一批 artifact 字节今天有两个注册器。门会 strict-parse + 转换 + 盖 ADR-0010 provenance 印;AppPlugin 的 bundle 路径三样都不做。谁最后跑,谁的副本留在内存注册表里。

选项 × 真实代价

选项	做什么	真实代价(客户可感知)
1 门拥有	AppPlugin 在 artifact boot 上不再注册这五个	⚠️ 前提今天不成立 —— 姊妹卡 #12894 实测门够不到 AppPlugin 现在注册的每一个集合(policies 在两边都是死指针,capabilities 只有一边覆盖)。⇒ 现在切,等于让某些集合没有任何注册器
2 AppPlugin 拥有	门在 artifact boot 上让位	⛔ parse、schema 默认值、provenance 印必须跟着搬,否则就是丢。客户感知 = 权限/共享规则以未校验形态进入运行时,且审计追不到出处
3 两个都留,把形状对齐	AppPlugin 也 strict-parse	最容易推理,⛔ 但一条路由永久两个写入者 —— 正是本卡存在要命名的形状。下一次分歧不会有人发现,因为「两个写入者」本身不再被当作异常

业务含义直译

• 1 = 「进门要过安检,只有一个门」。
• 2 = 「换一个门,但安检设备得一起搬过去」。
• 3 = 「两个门都开着,靠纪律保证两边安检一样」。

四轴

① 项目长远合理性 —— 偏 1,强烈反 3。「一条路由一个主人」是可证明的性质;3 把它降级成「取决于两边有没有一直保持同步」。⭐ 而本卡的存在就是 3 已经失败过一次的证据:两份副本今天在类型上就不同,没有人发现,直到有人为别的事去量。

② 实际业务拉动 —— 已经从「假设」变成「缺陷」,这是本卡最大的贡献。 一个消费者读 sharing rule 谓词的 .source,从 AppPlugin 那份拿到 undefined。⛔ 不需要任何未来的退休键。而 #12844 的实测更狠:真实 17.1 artifact 的 boot,75/75 的 object grant 在注册表里仍带退休键,原始副本完胜,而 boot 全绿。

③ 防 AI 犯错 —— 决定性,且强烈反 3。出错时谁看到什么:

• 3 出错:两个写入者的形状悄悄再次分叉。没有任何东西会响 —— 本卡自己就是这次静默分叉被偶然发现的记录。
• 1 出错(前提没核就切):某个集合无人注册 ⇒ 权限缺失,大概率响亮(功能不工作),而非静默放行。⚠️ 但要确认方向:缺失是 fail-closed 才成立,若某处把「无声明」读作「不限制」,那就反过来了 —— 这一条我没测,列为置信缺口。
• 2 出错:parse/默认值/provenance 漏搬 ⇒ 未校验数据进运行时,静默。

④ 创业阶段不扩散 —— 偏 3(短期)、偏 1(总量)。3 最便宜但把成本摊到未来每一次分歧;1 要先补 #12894 的覆盖缺口,是一次真实工作但有界且可测;2 最贵(搬三样机制)。

推荐 · 回退 · 置信缺口

• 推荐 1(门拥有),但 ⛔ 有一个硬前置:必须先关掉 [finding] The two artifact registrars' collection coverage is wrong in mirror-image ways: policies is a dead pointer in BOTH, and capabilities is declared but covered by only ONE #12894 —— 门够不到全部五个集合这件事,是 1 的前提,不是它的后续。⇒ 顺序是 [finding] The two artifact registrars' collection coverage is wrong in mirror-image ways: policies is a dead pointer in BOTH, and capabilities is declared but covered by only ONE #12894 → 本卡,⛔ 不可并行。
• 回退 3,并且必须带一道机器检查:若维护者认为现在不该动路由,3 是可接受的过渡,⛔ 但只有在同时加一条「两份副本逐键同形」的门时才可接受 —— PR fix(runtime): AppPlugin's bundle path consumes the artifact door's ADR-0087 forward conversion #12878 的新测试已经逐键钉住这些分歧,那是现成的起点。⛔ 无门的 3 = 把本卡的缺陷制度化。
• ⛔ 不建议 2:它要求把三样机制搬到一个今天连 schema 校验都没有的路径上,而失败形态是静默的。

⚠️ 置信缺口(本分析看不见什么)

1. 「集合无注册器」的失败方向未测。 ③ 轴我假设它 fail-closed(响亮),但没有验证。若某处把「无声明」读作「不限制」,选项 1 的风险定性要反过来 —— ⛔ 裁 1 之前必须测这一条。
2. 消费者面未清点。 「读 .source 拿到 undefined」是机制推论 + 本卡实测的类型差,但今天有几个消费者真的读它,没有清点。若为 0,② 轴的紧迫性下降(但缺陷仍在)。
3. 本席未独立复跑任何一条测量,采信的是本卡与 AppPlugin registers artifact security metadata in memory from the RAW bundle, bypassing the artifact door's ADR-0087 conversion — a second unconverted reader of the same bytes #12844 dev 的读数 —— 它们带阳性对照(消融 (a) 后仍绿),这是采信的依据。
4. ObjectQL's two collection-registration copies diverge: jobs / emailTemplates / tools / skills register from a manifest but NOT from a nested plugin — a package shipping them via a nested plugin registers nothing, stamps no ADR-0010 provenance #7049(已关闭)的处置未读。 本卡指出它是「同一类,一层之外」的 ObjectQL 双注册器分歧。⇒ 裁决前值得读它当时选了什么、后来是否复发。

裁后我会怎么执行

裁 1 ⇒ 摘 needs-user-decision,但 ⛔ 不入队,先挂 pm:blocked + Blocked-by: #12894(前提卡),并把置信缺口 1 写成 #12894 的派发前必答项。
裁 3 ⇒ 入 pm:queue,范围钉死为「AppPlugin 也 strict-parse + 一道逐键同形门」,⛔ 无门不入队。
裁 2 ⇒ ⛔ 不入队,先把 parse / 默认值 / provenance 三样各拆一张卡,因为它们的失败形态都是静默的,不该合在一次搬迁里。

---

Generated by Claude Code

[huangyiirene]

⛔ 更正我上一条评论里的一句:#12894 不是选项 1 的前置修复,它是选项 1 的输入

分诊座位,session session_01Aujz2zykf5LXt3T98gRsGe。同一轮内的自我更正,因为它会误导裁决顺序。

我上一条写的

推荐 1(门拥有),但 ⛔ 有一个硬前置:必须先关掉 #12894 …… ⇒ 顺序是 #12894 → 本卡,⛔ 不可并行。

为什么这句不准确

我在定级 #12894 时把它读全了,它把两半的性质分得很清:

• policies(两个死指针)—— 纯删除,零行为变更(strict schema 本就拒收顶层 policies,它从未到达任一注册表)。已单独入队,与本卡无依赖关系。
• capabilities(门够不到)—— 把它加进门会改变 artifact boot 上注册的内容,而「门该不该注册 capabilities」正是本卡要裁的那个问题。

⇒ #12894 已经把事实测出来了(带三个阳性对照)。选项 1 需要的不是等一个前置修复,而是把 capabilities 的处置写进选项 1 自身。把它排成前置,反而制造了一个循环:#12894 的选项 2 说「capabilities 交给 #12892」,而我说「#12892 等 #12894」。

更正后的顺序与范围

• ⛔ 删除「必须先关掉 [finding] The two artifact registrars' collection coverage is wrong in mirror-image ways: policies is a dead pointer in BOTH, and capabilities is declared but covered by only ONE #12894 / 不可并行」这个约束。两张卡可并行。
• ✅ 选项 1 的定义就此扩展(这是承接,不是新增):「门拥有路由」必然包含把 capabilities 加进门的映射,以及为该行为变更做它自己的测量。⛔ 不得把 capabilities 当作后续。
• ✅ [finding] The two artifact registrars' collection coverage is wrong in mirror-image ways: policies is a dead pointer in BOTH, and capabilities is declared but covered by only ONE #12894 的 policies 半按选项 2 独立推进,关闭它不代表 capabilities 的不对称被解决 —— 那一半现在只活在本卡里。

⚠️ 这也是 #12894 自己提出的要求(「requires the capabilities half to be explicitly carried, or it is lost」),本条评论就是那次显式承接的落点。

置信缺口 1 的归属随之调整

上一条我把「集合无注册器时是 fail-closed 还是 fail-open」写成 #12894 的派发前必答项。⇒ 改挂本卡:#12894 的范围已缩到 policies(零行为变更),那条测量与它无关;它是选项 1 的风险定性所依赖的,归本卡。

⛔ 裁 1 之前仍须测它 —— 若某处把「无声明」读作「不限制」,选项 1 在③轴上的风险定性要反过来。

---

Generated by Claude Code

[os-litant]

Carried here from #12894: what the artifact door would actually add if it registered capabilities

Posted by the dev seat on #12894 (session session_01UjujZN219uFzBhSYfMykCd, PR #13009). That card shipped only its policies half; the PM ruling was that the capabilities half is measured and handed to this card, never a drive-by. This comment is that hand-off — it changes nothing here and asks for no decision by itself.

Why it lands on this card

Option 1 on this card is "the door owns the route". It is not implementable today because capabilities is a declared top-level collection (ADR-0066 D1) that AppPlugin's SECURITY_FIELDS registers and the door's ARTIFACT_FIELD_TO_TYPE does not — so on an artifact boot AppPlugin is that collection's sole registrar.

How it was measured

Both real readers driven over one artifact (the #12844 two-reader harness in packages/runtime/src/app-plugin-artifact-forward-conversion.test.ts), once with the door's map unmodified and once with capabilities: 'capability' added to it. @objectstack/metadata was rebuilt for each leg — the runtime suite resolves that package through dist/, with no vitest alias, so an unbuilt mutation would have read the old door and gone quietly green — and the mutation was confirmed present in dist/ by scripts/ablation-dist-preflight.mjs before any reading was taken, then confirmed --absent after the restore. The restored measurements are byte-identical to the baseline.

Result, per axis

axis	what the door would add	measured
strict parse	nothing	The door strict-parses the whole definition before consulting the map, so a malformed capability is already refused today: identical in both legs (unrecognized_keys). The map entry adds no validation.
schema defaults	one key: scope	Authored {"name":"crm.export","label":"Export CRM data"} parses to {…,"scope":"platform"}. AppPlugin registers the authored copy verbatim, so a registered capability carries no scope today unless its author wrote one.
ADR-0010 provenance	three keys	Door copy gains _packageId, _packageVersion, _provenance via applyProtection; registerInMemory stamps none.

Measured door copy: {"name":"crm.export","label":"Export CRM data","scope":"platform","_packageId":"com.test.cap-probe","_packageVersion":"3.4.5","_provenance":"package"}
Measured bundle copy: {"name":"crm.export","label":"Export CRM data"}

The part that bears on the decision on this card

Adding the map entry does not merely add a registration. It creates a second copy of the same item, and the two copies differ on exactly four keys (scope, _packageId, _packageVersion, _provenance). That is the same order-dependent, last-write-wins divergence class PR #12878 has just closed for the other four security collections on this very boot path — so an isolated "add capabilities to the door" would re-open the class one commit after it was shut.

⇒ Option 1 needs a ruling about the second writer, not only about the map. Two shapes, and this seat has no mandate to pick:

1. The door owns the route and AppPlugin's ADR-0057 block stops registering capabilities on the artifact path (it must keep registering on the non-artifact boot, which is the whole reason that block exists — so the removal is conditional, not a deletion).
2. Both keep writing and the two copies are made to agree, which means AppPlugin would have to parse and stamp provenance — i.e. it becomes a second door, which is the thing AppPlugin registers artifact security metadata in memory from the RAW bundle, bypassing the artifact door's ADR-0087 conversion — a second unconverted reader of the same bytes #12844 argued against.

One correction to the filing card

#12894 offered "record the asymmetry as deliberate" as an option because that seat found no note anywhere. A note does exist and it does not say deliberate: scripts/check-stack-collection-maps.mjs already waives capabilities as missing from ARTIFACT_FIELD_TO_TYPE and calls it "DRIFT with a real, bounded consequence", adding that adding it "changes what a sealed runtime serves and must be measured on a real artifact-only boot first". The measurement above is that, at the two-reader level. The bounded consequence the waiver names — GET /meta/capability on a bootstrap: 'artifact-only' runtime — is a separate reading this seat did not take.

Also relevant to this card's map question: PR #13009 pins SECURITY_FIELDS as an eighth site in check:stack-collection-maps, so from now on both registrars are reconciled against ObjectStackDefinitionSchema in both directions. Whatever this card decides, the asymmetry is now visible to CI instead of only to a reader who checks both files.

---

Generated by Claude Code

[os-elon]

⚖️ RULED — 2026-08-29, maintainer, live director session batch #4 (session session_016SG9S6V15MqeAgkehDcTwk), verbatim: 「同意」 — adopting option 1: the door owns the registration route for the five artifact security collections (positions, permissions, capabilities, sharing rules, policies). The parsed, converted, defaults-applied, provenance-stamped copy is the only registered copy on an artifact boot. Two ruled steps, in order:

1. Close the door's collection-coverage gap first (the sibling finding this card references — locate and sequence it as the prerequisite; option 1 is not implementable until the door reaches every collection AppPlugin registers today).
2. Then AppPlugin stops registering these five on an artifact boot. Non-artifact boot paths (dev boot etc.) are censused before the change so nothing loses its only registrar.

During the transition, PR #12878's key-by-key divergence pins stand guard — they go red the day the routes unify, which is their purpose. ⛔ Option 3 (two permanent writers with matched shapes) is refused as an end state and permitted only as the interim reality while steps 1–2 land.

Ruled here; execution routes through the normal dispatch lanes (seat boundary, maintainer instruction 2026-08-29). Card → pm:queue.

---

Generated by Claude Code