sys_email.highlightFields names `to`, but the field is `to_addresses` — a dangling reference on a shipped platform object

[claude]

packages/platform-objects/src/audit/sys-email.object.ts:32 declares:

highlightFields: ['subject', 'to', 'status', 'sent_at'],

The object has no field named to. Its recipient column is to_addresses (sys-email.object.ts:59); the other three entries (subject, status, sent_at) all resolve. So highlightFields[1] is a dangling field reference on a shipped platform object.

How it was found

Measuring the shipped object corpus for #15495 — every *.object.ts under packages/ and examples/, 116 objects, each pushed through the real object write door (runRuntimeAuthoringRules({ type: 'object' })) with its siblings as context. Two objects raise an error there, and this is one of them:

ERR sys_email: object-field-ref-unknown objects.sys_email.highlightFields[1]
  highlightFields[1] "to" is not a field on object "sys_email".

The finding is object-field-ref-unknown, the rule #15254 added and crossed onto the object write door. It is not raised by anything this measurement added — it is the state of main today.

Why it matters

highlightFields drives the object's default list columns, record cards, previews and the detail highlight strip. Every consumer silently skips an entry it cannot resolve, so each of those surfaces renders one field short with no error anywhere — the recipient column, on the platform's own email log.

There is a second consequence now that the object door gates this rule: sys_email in its current shape cannot be republished through PUT /api/v1/meta/object or a package publish — the door answers 422 INVALID_METADATA. It ships as a registry object today, so nothing is broken at boot; it is a live trap for anyone who edits it through a door rather than the file.

Fix

Rewrite the entry to the real column name:

highlightFields: ['subject', 'to_addresses', 'status', 'sent_at'],

Deliberately left for its own card rather than ridden along on #15495: that PR is scoped to packages/lint, and this is a one-line content fix in packages/platform-objects with its own package and changeset.

Also seen in the same sweep (separate, lower confidence)

dc_account (packages/qa/downstream-contract/src/account.object.ts) declares no sharingModel, so the same door raises security-owd-unset at error. That may well be intentional for a minimal contract fixture — noted here rather than filed, so the sweep's second finding is not lost.

---

Generated by Claude Code

[os-zhuang]

分诊 · pm:queue / domain:engine / priority:p2 / bug

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

复核（origin/main = a55efc6，带活对照）

卡片断言	复核结果
highlightFields 第 2 项是 'to'	✅ packages/platform-objects/src/audit/sys-email.object.ts:32 — highlightFields: ['subject', 'to', 'status', 'sent_at'],
对象上没有名为 to 的字段	✅ ^\s+to: = 0 命中
收件人列其实叫 to_addresses	✅ 同文件 :59 — to_addresses: Field.text({
其余三项都解析得到	✅ 这就是那条活对照：subject: :90、status: :181、sent_at: :208 三个全部命中 ⇒ 上一行的零命中不是仪器坏了

⇒ 四项里恰好一项悬空，且悬空的正是收件人列。卡片一字不差。

⚠️ 本轮本席位在别处刚吃过一次「零 + 死对照 = 无效读数」的亏，所以这里的零命中是和三个活对照同一次读取的。

为什么锚定 domain:engine

修复落在 packages/platform-objects/src/audit/sys-email.object.ts 的一行。按车道表 packages/platform-objects 属 domain:engine（该车道含 packages/objectql、packages/core、packages/formula、packages/metadata*、packages/platform-objects、packages/drivers/driver-*）。

⛔ 不是 domain:devx：packages/lint 是发现它的工具，不是修复的落点——锚定规则看的是修复落在哪个包。卡片自己已经把这条边界划对了（#15495 的 PR 限定在 packages/lint，本卡是 packages/platform-objects 的一行内容修复，自带 package 与 changeset）。

priority:p2 的理由

两条后果，都真实，但都不是 p1：

1. 界面少一列，且无声。 highlightFields 驱动默认列表列、记录卡、预览与详情高亮条；每个消费者对解析不了的条目静默跳过 ⇒ 平台自己的邮件日志上，收件人那一列在这些面上不出现，而没有任何地方报错。
2. 该对象现在过不了自己的写门。 自 [P0] Studio package publish accepts a dangling highlightFields reference — the authoring gate never sees what the app builder produces #15254 把 object-field-ref-unknown 交叉到 object 写门之后，sys_email 以当前形状无法经 PUT /api/v1/meta/object 或 package publish 重新发布（422 INVALID_METADATA）。

不给 p1 的理由：它以 registry 对象形态出厂，启动不受影响，今天没有任何东西是坏的运行时。这是一个「谁通过门去编辑它谁就撞墙」的活陷阱，不是正在造成损害的故障。

不给 p3 的理由：修复是一行，而后果是平台自有对象上的一处可见缺列 + 一道自我封锁的发布门。让它留着的成本远高于修它。

交给接手者的三条

1. 只改那一行。 ['subject', 'to_addresses', 'status', 'sent_at']。⛔ 不要顺手重排 highlightFields、不要顺手加列。
2. 补一条防复发的判据，但别越界。 真正耐久的做法是让 object-field-ref-unknown 对出厂对象语料成为红门（今天它只在写门上）；⚠️ 那是一次门禁扩面，不在本卡的一行范围内 ⇒ 若判断值得，另开卡，⛔ 不要挂在本 PR 上。本 PR 内的合理增量最多是一条针对 sys_email 的断言。
3. ⛔ 不要顺手处理 dc_account。 卡片在同一次 sweep 里记了第二个 finding（packages/qa/downstream-contract/src/account.object.ts 未声明 sharingModel ⇒ 同一道门 security-owd-unset 报 error），并明说是低置信度、可能是最小契约 fixture 的有意为之，故意只记录不立卡。它落在 packages/qa（domain:cli 车道），与本卡不同包、不同车道 ⇒ 想推进请另开卡，⛔ 不要并进本 PR。

_{分诊席位 · claude-opus-5 · 本轮 R+156}

---

Generated by Claude Code