[finding] the deliberate `reference_to` tolerance in plugin-security has no measured stored-metadata population — the prerequisite for ever narrowing it

[claude]

Deferred by the maintainer ruling on #13250 (2026-08-30, verbatim 「同意」), which named it out of scope for that card in its own words: narrowing the security reader for real is a separate card, not a rider. Filed unassigned so the option is recorded rather than lost. ⛔ Nothing here is claimed to be broken today.

Where this stands

resolveCbpRelation in packages/plugins/plugin-security/src/security-plugin.ts deliberately still reads reference ?? reference_to ?? referenceTo, and PR #13541 made that tolerance loud rather than removing it. The in-file comment there records why, and it is not a style preference:

• The alias genuinely reaches that reader — a raw registerObject skips Zod, so the registry serves the field back with the alias verbatim (measured on main while implementing fix(security,verify): keep the security reference-alias read tolerant but LOUD, narrow verify with a named finding #13541).
• A miss there is fail-closed, not a quiet wrong answer: the read leg answers RLS_DENY_FILTER (zero rows for every non-admin caller) and the write leg throws MasterDetailRelationMissingError. So narrowing a reachable reader is an availability outage on a population that provably exists.

What would have to be measured before narrowing

The ruling's option C. None of this has been done, and this card exists to hold the question, not to answer it:

1. Size the population. How many raw-registered / stored objects actually spell reference_to or referenceTo on the field that resolves a controlled_by_parent master relation? The repo-wide source sweep done for fix(security,verify): keep the security reference-alias read tolerant but LOUD, narrow verify with a named finding #13541 found the spelling only in tests, the spec's own alias tables and other readers' documentation — no example app or platform object uses it. That says nothing about metadata stored in a live deployment's database, which is the population that matters here.
2. Decide the migration. If the population is non-empty, a sweep that rewrites the key has to land, and be verifiable, before any narrowing.
3. Only then flip the reader, and delete the tolerance note along with it.

If step 1 measures zero across every reachable corpus, the narrowing becomes cheap and this card is small. If it does not, the outage cost above is the thing to weigh.

Related

#13250 (the ruling and both dispositions) · #13541 (the loud tolerance) · #11567 (reference is the only declared spelling)

---

Generated by Claude Code

[claude]

分诊定级 · 首次定级 · 持有 finding · domain:services · ⛔ 不入队

⚠️ 此前带 finding + pm:retriage。pm:retriage 是误用(本卡从未被定级,没有可异议的对象),本轮摘掉;finding 保留 —— 它正确。

域锚定:packages/plugins/plugin-security 在 services 车道的身份侧(lanes/services.md:11 逐字列出 plugin-security)⇒ domain:services。

为什么持有

卡自己把理由写全了,且不主张今天坏了:容忍是有意的,PR #13541 让它变响而非移除;别名确实到达该读者(裸 registerObject 跳过 Zod,注册表原样发回);而 miss 是 fail-closed —— 读腿答 RLS_DENY_FILTER(每个非 admin 调用者零行)、写腿抛 MasterDetailRelationMissingError。

⇒ 收窄一个可达的读者 = 对一个已证明存在的 population 制造可用性中断。 在那份 population 被量出来之前,收窄不可判定 ⇒ 无可派之事。

⚠️ 并记一条本席核过的边界:lanes/services.md 的红线写明「安全/权限边界的放宽……是人工地板」。本卡方向是收紧不是放宽,故不因该条恒升级;但其后果(可用性中断)使它在测量之前同样不可代裁。

⭐ 重启条件 —— 与 #13543 共用一次测量,⛔ 不要测两遍

本卡与 #13543 是同一个形状:一个容忍别名的读者,断言了一份 stored-row population,而没有任何东西测量它。两张卡问的是同一个问题的两个实例。

重启条件:任何一次对「stored-row 里 reference / reference_to / referenceTo 的实际拼写分布」的测量落地 ⇒ 本卡与 #13543 同时可判。

⇒ 谁先接到其中一张,请把测量做成覆盖两个读者的一次普查,并把结果落在卡上;⛔ 两张卡各测一次,是把同一份成本付两遍,且两份结果可能不一致。

其余重启条件:#13250 的选项 C 被维护者重新拾起;或今后任何单已要改 resolveCbpRelation ⇒ 顺带结算。

---

Generated by Claude Code

[zhuangjianguo]

定级补齐(skills 席代分诊):priority:p2(domain:services 已在)—— 维护者裁定明言的独立卡:窄化前必须先量 stored-metadata 人口(裁决选项 C 的三步)。fail-closed 的中断代价已在卡上记死 ⇒ ⛔ 任何人不得未量先窄。与 #13543 同族(见彼卡)。

---

Generated by Claude Code