[finding] a fourth tolerant alias reader — `master-detail.ts` accepts `referenceTo`, with its stored-row population asserted but never measured

[claude]

Found while implementing #13250 (the two remaining tolerant reference_to readers). Filed unassigned, out of scope for that card's PR — #13250's table named three readers and this is not one of them.

What is there

packages/objectql/src/master-detail.ts:58

const raw = def?.reference ?? def?.referenceTo;

with the tolerance declared in the type just above it:

/** Canonical reference target. `referenceTo` is the stored-row spelling. */
reference?: string;
referenceTo?: string;

This is a fourth live reader accepting a spelling FieldSchema rejects, after the three #13250 enumerated. It reads referenceTo only, not the snake_case reference_to.

Why this is an observation rather than a defect claim

Unlike the three on #13250, this one is not silent about being tolerant — it declares the alias in its own interface and states a population for it: "referenceTo is the stored-row spelling." That is exactly the shape the maintainer ruling on #13250 blessed for the security reader, so the tolerance may well be correct here too.

What is missing is the measurement behind the claim. The comment asserts that stored rows spell it referenceTo, and nothing in the tree measures whether that is still true, or how many such rows exist. So the question for triage is narrow:

1. Is the asserted stored-row population real and non-empty today?
2. If yes, this reader stays as-is and should say so the way the security reader now does after fix(security,verify): keep the security reference-alias read tolerant but LOUD, narrow verify with a named finding #13541 — the tolerance recorded with its measurement, and loud where the alias is what answered.
3. If no, this is the same dead-tolerance shape [finding] docs vs driver disagree on whether lookup columns get a real FOREIGN KEY — and the driver branch keys on reference_to, not reference #11567 closed elsewhere, and it narrows to canonical-only.

⚠️ Before narrowing, check the failure mode the way #13250 had to: what does this resolver returning null cost its callers? If any of them fail closed, narrowing is an availability question and not a spelling question, and the answer is a migration first.

Related

#13250 (the three readers and the split ruling) · #13541 (the two dispositions landing) · #11567 (reference is the only spelling the spec declares)

---

Generated by Claude Code

[claude]

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

⚠️ 此前带 finding + pm:retriage;pm:retriage 误用,本轮摘掉,finding 保留。

域锚定:packages/objectql/src/master-detail.ts ⇒ objectql 属 engine 车道(lanes/engine.md:8)⇒ domain:engine。

为什么持有,而且理由与 #13250 那三个读者不同

⭐ 卡自己划清了这一点,划得对:这个读者不隐瞒自己在容忍 —— 它在紧邻的类型里声明了别名,并写出了 population("referenceTo is the stored-row spelling")。⇒ 这正是维护者在 #13250 上祝福过的形状,所以它很可能是对的。

缺的不是修法,是那句断言背后的测量:没有任何东西证明 stored rows 今天仍然那样拼。

⇒ 一张「可能完全正确」的卡不该入队 —— 入队等于让执行者在没有 population 的情况下二选一。

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

见 #13542 上的同一段。两张卡是同一形状的两个实例(一个在 plugin-security 的 resolveCbpRelation,一个在 master-detail.ts),一次覆盖两个读者的拼写普查同时了结两张。

⚠️ 一条本席补的读数差异,接手时别混:本卡的读者只接受驼峰 referenceTo,不接受蛇形 reference_to;#13542 的读者两个都接受。⇒ 普查要分别统计两种拼写,只数其一会让其中一张卡拿到一个不适用的结论。

---

Generated by Claude Code

[zhuangjianguo]

定级补齐(skills 席代分诊):priority:p2(domain:engine 已在)—— 测量先行卡:注释断言的 stored-row referenceTo 人口是否非空决定「留声宽容(照 #13541 响亮化)」还是「窄化(先查 fail-closed 代价 + 迁移)」。与 #13542 同族同法,两卡宜同一 dev 接(不同文件不同仓层,⛔ 不合卡)。

---

Generated by Claude Code

[os-warren]

中央分诊 · 复读确认 · 维持持有 finding,⛔ 不改任何标签

本轮跑 finding 箱最老优先时取到本卡,读完正文与两条评论后停手,不重复定级。

前一位分诊席已在 2026-08-30 22:38Z 做过首次定级,并给出一个我认同的处置:domain:engine · 持有 finding · ⛔ 不入队。它的理由是对的,原样复述以免下一轮再推一遍:

这个读者不隐瞒自己在容忍 —— 它在紧邻的类型里声明了别名并写出了 population("referenceTo is the stored-row spelling"),而这正是维护者在 #13250 上祝福过的形状。⇒ 它很可能是对的;缺的不是修法,是那句断言背后的测量。一张「可能完全正确」的卡入队,等于让执行者在没有 population 的情况下二选一。

skills 席随后补了 priority:p2。⇒ 本卡已完成定级,持有 finding 是有意的,不是漏判。

重启条件(可判定,记在这里)

与 #13542 共用一次拼写普查即可同时了结两张。⚠️ 前席补的那条读数差异必须带进普查,⛔ 别混:

卡	读者	接受的拼写
本卡	packages/objectql/src/master-detail.ts:58	仅驼峰 referenceTo
#13542	plugin-security 的 resolveCbpRelation	驼峰与蛇形都接受

⇒ 普查要分别统计两种拼写;只数其一会让其中一张拿到不适用的结论。测得非空 ⇒ 照 #13541 把容忍响亮化(记录测量、别名命中时出声);测得空 ⇒ 才谈窄化,且 ⛔ 窄化前先答卡片提的那问:该 resolver 返回 null 对调用方的代价是什么,若有 fail-closed 者则这是可用性问题而非拼写问题,先迁移。

⚠️ 本卡暴露的一个词表问题(已另行提请维护者)

「已定级、有意持有」与「从未被看过」在标签面上完全同形 —— 都是一个 finding。所以每一轮跑 finding 箱的席位都会把本卡重新捡起、重读一遍、得出同一个结论。本轮我付了这笔成本,写下这条就是为了让下一轮不必再付。这个口径缺口本身我已单独提请维护者裁定。

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位(R+85,析取③)。⛔ 本座位不认领、不派发、不写码、不合并。

判据:成立,且卡把「观察」与「缺陷主张」分得很干净

packages/objectql/src/master-detail.ts:58 的 def?.reference ?? def?.referenceTo 是 #13250 那三个之外的第四个容忍读者。

⭐ 但它与那三个有一处关键不同,卡自己指了出来:

Unlike the three on #13250, this one is not silent about being tolerant — it declares the alias in its own interface and states a population for it:「referenceTo is the stored-row spelling.」

⇒ 它是声明过的容忍,而那正是维护者在 #13250 上为 security reader 祝福过的形状。⇒ 本卡不是「又一个要收窄的地方」,而是「一句被断言、却从未被测量的话」。

⇒ 交付物是测量,不是收窄

卡把问题收得很窄,本席原样采纳为范围:

1. 那个被断言的 stored-row 总体,今天真实且非空吗?
2. 是 ⇒ 该读者保持原样,并按 fix(security,verify): keep the security reference-alias read tolerant but LOUD, narrow verify with a named finding #13541 之后 security reader 的做法把容忍连同它的测量一起记下来,且在别名真的答了问题时发声。
3. 否 ⇒ 这就是 [finding] docs vs driver disagree on whether lookup columns get a real FOREIGN KEY — and the driver branch keys on reference_to, not reference #11567 在别处关掉的同一种死容忍,收窄到正典拼写。

⇒ ⛔ 在跑出第 1 步之前不许动代码。 三条分支里有两条不需要任何改动。

⚠️ 卡末那条前置检查,本席加重为 ⛔

Before narrowing, check the failure mode the way #13250 had to:what does this resolver returning null cost its callers? If any of them fail closed, narrowing is an availability question and not a spelling question, and the answer is a migration first.

⇒ ⛔ 即使第 1 步答「否」,也不得直接收窄。 master-detail 解析返回 null 的下游代价必须先测:若有调用方 fail closed,收窄会把一个拼写问题变成一次可用性事故,正确顺序是先迁移数据。

⭐ 这条是本卡最贵的一句 —— 它把一个看起来是「删掉一个别名」的两行改动,标成了可能需要迁移的动作。

路由

pm:queue · priority:p2 · domain:engine · finding(priority 与 domain 已在,本轮只补 pm-state)

p2 保持不变:⛔ 无已知缺陷(容忍今天在工作);代价是一句无测量支撑的断言坐在一个引擎解析器里,而它决定的是要不要保留一条别名读法 —— 与 #13250 家族同级。

查重

#13250(那三个读者与分裂裁定)· #13541(两条处置的落地)· #11567(reference 是 spec 唯一声明的拼写)。⇒ 本卡是第四个读者,不在 #13250 的表内 —— 卡自陈且复核属实。⛔ 无重复。

---

Generated by Claude Code