[finding] ApprovalService.resolveLookupFields requires an EXPLICIT reference on `user` fields, which spec declares fully specified without one — implicit-target metadata is silently invisible to inbox enrichment

[huangyiirene]

Surfaced by the os-dev delivering #19081 (PR #19197) as an out_of_scope_findings entry, and filed here by the domain:services seat — dev agents report findings with dedupe words; they ⛔ do not file. ⛔ Ungraded and unassigned: type and priority are the triage seat's. domain:services applied because the landing site is packages/plugins/plugin-approvals, this lane's.

⭐ The cited contract text was re-read verbatim on origin/main by the filing seat before filing, ⛔ not taken from the report.

The declared contract

packages/spec/src/data/field-value.zod.ts, the docblock on IMPLICIT_REFERENCE_TARGETS, verbatim:

Reference types whose target object is FIXED BY THE TYPE rather than chosen by the author, mapped to that target.

user is the only member … the Field.user() builder — unlike Field.lookup(reference, …) / Field.masterDetail(reference, …) — takes NO target argument and writes reference: 'sys_user' itself. The target is a CONSTANT OF THE TYPE, so reference on a user field materializes that constant; it does not supply it. Metadata authored without it (hand-written JSON, an AI author, a Studio form) is fully specified, not under-specified.

referenceTargetOf exists in that same module precisely to supply the implicit target (Framework#4443 / cloud#983).

What the code does instead

ApprovalService.resolveLookupFields (packages/plugins/plugin-approvals/src/approval-service.ts) accepts type: 'user' fields but requires an EXPLICIT reference. ⇒ a { type: 'user' } field authored without one — which the spec says is fully specified — is invisible to inbox display enrichment.

⇒ the declared contract says such metadata is complete; this reader treats it as incomplete and silently drops it.

Why it is filed rather than ridden into #19197

⛔ Pre-existing and UNCHANGED by that PR. #19081 narrowed four C2 carrier reads to answer absence instead of propagating an unreadable carrier; this is a different defect — a readable field whose target is implicit. Routing resolveLookupFields to referenceTargetOf would widen the accept set, which that dispatch's 回翻条款 says to stop and report rather than silently re-rule. The dev stopped and reported, which is the correct outcome.

Not established — ⛔ do not grade as a live outage without it

⛔ No reachability reading was taken: whether any deployment authors user fields without an explicit reference today is unmeasured. ⚠️ Note the shape this defect has if it IS reachable — it is an AI-metadata trap: an author (or an AI) writing the spelling the spec calls complete gets a silent drop, with no refusal and no warning.

⚠️ The dev also notes the analytics resolver does not admit type: 'user' at all, so the same question may apply there. ⛔ Unverified by the filing seat — stated as the dev reported it.

Dedupe words

user field implicit sys_user target · IMPLICIT_REFERENCE_TARGETS reader blind · referenceTargetOf vs referenceCarrierOf reader · approvals user lookup title unresolved · Framework#4443 implicit target residue

Related: #19081 / PR #19197 (the C2 carrier narrowing this was found beside) · Framework#4443 · cloud#983.

---

Generated by Claude Code