[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]

Path: P2 | approvals | 北极星「优先级」4(永不静默)

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

[os-sam]

Triage: first-touch grading — pm:queue · priority:p2 · bug. domain:services kept as filed. Readings taken in THIS act, 2026-09-20T06:54Z. _{本评论来自分诊座位}

Class (b), and the contract text is unusually explicit about the exact case the code gets wrong. The docblock on IMPLICIT_REFERENCE_TARGETS states that a user field's target is 「a CONSTANT OF THE TYPE」 and that metadata authored without reference is 「fully specified, not under-specified」 — and referenceTargetOf exists in the same module precisely to supply it. ⇒ requiring an explicit reference is not a stricter reading of the contract; it is the opposite of what the contract says, on the one member the contract names.

⭐ Kept on the record because it is the part that makes this card trustworthy: the filing seat states it re-read the contract text verbatim on origin/main before filing, ⛔ rather than carrying it from the dev's report. The report-to-card boundary held — dev agents report with dedupe words, the seat files.

priority:p2 — the failure is silent: implicit-target metadata is simply invisible to inbox enrichment, with no refusal and no diagnostic, which is the shape 北极星 clause 4 names (「永不静默」). ⛔ Not p1: approvals still run and the inbox still renders; what degrades is enrichment, so 「能跑但出错」 rather than a broken capability. ⚠️ Upgrade trigger, checkable: if any approval routing or permission decision — ⛔ not merely display — consumes the enriched value, this becomes p1 the moment that is measured, because an invisible field would then change who can act.

Scope: make resolveLookupFields consult referenceTargetOf for the implicit-target types rather than requiring the materialized reference. ⛔ Do not "fix" this by making authors write reference on user fields — that would contradict the declared contract and push the cost onto every author, which is the 消费端宽容 direction the charter rejects.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round R5
Session: session_01AhQASwqJr2Z7XfGWUdvnbF
Branch: claude/issue-19198-implicit-reference-lookup
Worktree: objectstack-issue-19198
Domain: domain:services
Seat: domain:services#1
File surface: packages/plugins/plugin-approvals/ (stop on breach; explain in the report). ⛔ packages/spec is read-only here — referenceTargetOf and IMPLICIT_REFERENCE_TARGETS are imported, ⛔ never edited.
Container & model: M, mode:subagent, model: opus — quoting THIS act's node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --tier packages/plugins/plugin-approvals/src/approval-service.ts, derived at tree 7d0f911da: 「no path-derived mandate: the surface hits none of the 3 declared glob(s)」 ⇒ PM judgment, floor sonnet · default opus · ceiling fable.
Clause-②: no
Thread-read: 5748247853
Serial constraints cleared: none. Two channels, taken in THIS act. (1) All 22 open PRs enumerated, 314 changed-file rows: approval-service.ts and lookup-field-reference-carrier.test.ts held by 0; plugin-approvals has 0 held rows, and the firing control sits on the enclosing prefix — packages/plugins/** has 6 held rows in the same scan (#19242, #18319) ⇒ the predicate does fire on this path family, so the zero is a reading. (2) git ls-remote --heads origin 'refs/heads/claude/issue-19198*' ⇒ 0 of 1148 heads (control: the listing answers 1148). Lane hot-file serial queue is empty.

⚠️ Sibling card #19206 is claimed by this seat in the same round. ⛔ Not a fold and ⛔ not serial with it: different package, different defect, zero shared files (examples/app-todo/** vs packages/plugins/plugin-approvals/**).

---

North Star clause 3 — why this p2 is taken

Open P0/P1 re-read in this act: p0 = 4 · p1 = 46 ⇒ clause 3 LIVE, barring p2/p3 工具卡 / 契约卫生卡 only. This card is a silent runtime defect: implicit-target user metadata is invisible to inbox enrichment with no refusal and no diagnostic — the shape 北极星 clause 4 names (「永不静默」). ⛔ Not tooling, ⛔ not hygiene ⇒ not barred.

⭐ The direction is fixed by the grading comment and is ⛔ not the executing seat's to re-open: resolveLookupFields consults referenceTargetOf for the implicit-target types, ⛔ rather than requiring authors to materialize reference on user fields — that inverse would contradict the declared contract and push cost onto every author, the 消费端宽容 direction the charter rejects.

---

Generated by Claude Code

[huangyiirene]

os-dev-report
{
"issue": 19198,
"status": "done",
"branch": "claude/issue-19198-implicit-reference-lookup",
"pr": "#19263",
"session": "session_01AhQASwqJr2Z7XfGWUdvnbF",
"premise_still_valid": true,
"summary": "Premise re-verified verbatim on origin/main at 7d0f911 before editing: the IMPLICIT_REFERENCE_TARGETS docblock in packages/spec/src/data/field-value.zod.ts does say a user field's target is a CONSTANT OF THE TYPE and that metadata authored without reference is 'fully specified, not under-specified', and ApprovalService.resolveLookupFields did gate on the materialized carrier. resolveLookupFields now asks referenceTargetOf instead; the admitted type set (lookup, master_detail, user) is unchanged, so the only behaviour that widens is the one the contract already declared complete. The per-field TypeError catch for an unreadable carrier is unchanged and the existing pins in lookup-field-reference-carrier.test.ts pass untouched; only the warning prefix now names the reader, because referenceTargetOf takes no reader label. Call-path sweep: git grep for the symbol found resolveLookupFields is the ONLY site in packages/plugins/plugin-approvals that resolved a field target from reference, and its sole consumer is enrichRows. The card's assignee was already set by the PM dispatch and was not written by this run.",
"tests": "All exit codes captured before any pipe, at HEAD aef74f0, worktree clean. (1) pnpm --filter @objectstack/plugin-approvals test :: exit 0 - 'Test Files 49 passed (49) / Tests 780 passed (780)'. (2) pnpm --filter @objectstack/plugin-approvals typecheck :: exit 0 - the package's own script names THREE legs (tsc --noEmit && tsc --noEmit -p tsconfig.scripts.json && pnpm check:test-typecheck), read from its package.json and run as spelled; check:test-typecheck: 'OK - 8 file(s) / 324 error(s) / 27 pinned signature(s)', i.e. the EXACT test-typecheck-debt ratchet is unmoved and the new test file takes no entry. (3) Derived gate set: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands => 61 families; all 61 run, reconciled with --ran: '61 derived famil(ies) accounted for - 61 run, 0 NOT-MEASURED (a DERIVED zero - all 61 recorded an exit code and none of them is 3)'. (4) Six gates first answered exit 3 = PREREQUISITE NOT MET = NOT MEASURED: check:dts-closure, check:dual-build-cjs-loads, check:i18n, check:lean-entry-closure, check:sourcemap-no-sources-content, check:type-check-debt. Prerequisites cleared (dependency closure build, then turbo run build over ./packages/* and ./packages//, 72 tasks successful) and every one re-run to exit 0. None reported as a zero. (5) pnpm lint (eslint . --no-inline-config, the repo's only style authority) :: exit 0 over the whole tree - no narrowing claimed. (6) ABLATION, run from the committed state via scripts/ablation-replace.mjs with a trap-guarded restore: anchor 'reference = referenceTargetOf(f);' hit x1 as declared, replaced with the pre-repair carrier-only read, on-disk blob 703a30813264 -> b1fa2e3f0300 (the tool's own count+hash verdict, not a sed exit code). Result: 'Test Files 1 failed | 1 passed (2) / Tests 3 failed | 6 passed (9)' - the three substantive new cases go red ('expected undefined to deeply equal { key: "owner", reference: "sys_user" }' and 'expected [] to have a length of 1 but got +0'), the two CONTROL cases and the whole sibling carrier suite stay green, so the mutation is narrow. Direction observed: turned red, as predicted. Restore proven by state, not by exit code: blob back to 703a30813264 == HEAD blob, git diff HEAD empty. No ablation artifact is left in the tree. (7) VERBATIM verdict lines that die with this worktree - engine-double-contract's non-failing census: 'UNRECOGNISED [engine-double-contract]: 9 construct(s) in packages, examples declare a scanned verb (delete, update, findOne) alongside engine siblings, and this gate could not read the implementation -- so they are in NEITHER the pinned population nor the ledger. 213 further construct(s) are SCOPED OUT by a stated criterion and are not counted here. This is a verdict, not a finding: it never fails a run (#9747, ruling of 2026-08-18).' And check-changeset-no-major --self-test: 'LEVEL AXIS: NOT APPLICABLE - this run has no pull_request to read a declaration from, so the clause-2 axis has no input by construction rather than by omission. It is a PR-scoped reading: the RC cut (cut-rc.yml) and a local run reach here, and neither is a PR that could have declared.' Both pre-exist this diff. (8) grep os-regen .gitattributes read on the spot: 19 managed paths, none of them in this diff.",
"mcp_calls": "0 - no MCP GitHub tool was called, read or write. Every GitHub read and write went through the REST proxy with curl.",
"api_writes": "2 REST writes: POST /repos/objectstack-ai/objectstack/pulls (draft PR #19263, HTTP 201) and POST /repos//issues/19198/comments (this report). Plus 3 ordinary git pushes to claude/issue-19198-implicit-reference-lookup (the empty-branch routing probe, the fix, the changeset). ZERO label writes: the dispatch named no label, Clause-2 is no so needs:contract-review does not apply, and the diff publishes (@objectstack/plugin-approvals is not private and ships dist/) so skip-changeset is false - the permitted set is empty. PR body written once, in the create call; read back and byte-identical apart from the trailing newline, one footer.",
"open_questions": [],
"out_of_scope_findings": [
"to file (3 classes, dedupe words: plugin-audit tracked lookup user implicit target / planTrackedLookupReads reference carrier gate / trackHistory user field raw id timeline / audit-writers REFERENCE_FIELD_TYPES referenceTargetOf / Framework#4443 implicit target residue audit): class (b) - the SAME defect, one package over. packages/plugins/plugin-audit/src/audit-writers.ts:472 (planTrackedLookupReads) admits user in its REFERENCE_FIELD_TYPES set and then requires typeof field.reference === 'string', skipping the field otherwise - so a trackHistory'd { type: 'user' } field authored without the constant is read-planned for nobody and displayFieldValue falls back to the raw id, which is exactly the symptom #7230 fixed ('Rating Owner: empty -> oBK25...'). Same silent shape, same contract text, same one-line remedy (referenceTargetOf). Its own docblock already declares it shares the vocabulary with approvals ('one vocabulary for "this value is a reference", not two'), so the two are now out of step until it is repaired. Outside this card's file surface, so not fixed here.",
"triage input, not a card: the UPGRADE TRIGGER on the grading comment answers NO, measured. No approval ROUTING or PERMISSION decision consumes the enriched value. resolveLookupFields has exactly one consumer (enrichRows); enrichRows has exactly two call sites, both read APIs (listRequests and the single-request read), and it writes only display fields. Approver routing reads the RAW record: resolveApproverSpec's field arm does csvSplit(record[a.value]) and never consults a field definition's target. Corpus grep over packages, examples, apps and content, excluding CHANGELOGs and tests: payload_display has ONE writer (approval-service.ts:5943) and no reader anywhere; positive control on the same corpus and the same grep, pending_approvers (a sibling row field routing does consume), returns 10+ files including packages/lint/src/validate-approval-approvers.ts and examples/app-showcase - so the zero is a reading. => stays p2 by the grading comment's own trigger.",
"triage input - this card's own unverified note is HALF FALSIFIED. The card says 'the analytics resolver does not admit type: user at all'. Measured: packages/services/service-analytics/src/dimension-labels.ts:142 ALREADY delegates to referenceTargetOf and its docblock names the user constant explicitly, so for the dimension-label resolver the note is false. What the note does hit is a DIFFERENT site: packages/services/service-analytics/src/plugin.ts:735 (relationshipResolver) gates on field.type === 'lookup' || field.type === 'master_detail' and reads referenceCarrierOf, so a user field named in a dataset include resolves no target. That failure is LOUD (the dataset compiler rejects it), not silent, so it is a different shape from this card and may well be deliberate. Reported rather than filed; triage's to grade.",
"noted, not filed: tree is the fourth member of REFERENCE_VALUE_TYPES and neither this enrichment nor plugin-audit admits it (plugin-audit states the exclusion deliberately: 'tree is NOT on the list: it carries no reference'). Admitting it would widen what the inbox resolves rather than repair what it silently dropped, so it stays out. Successor: whoever next touches the shared three-type reference vocabulary in either package - it is one edit in two files, and both already cite each other.",
"noted, not filed: the approvals warning for an unreadable carrier now carries the reader's name in its own prefix instead of inheriting it from referenceCarrierOf's message, because referenceTargetOf takes no reader label. The existing assertion on that message passes unchanged. Successor: none - it is inside the same function this PR already rewrites."
]
}

---

Generated by Claude Code

[huangyiirene]

✅ ACCEPT — PR #19263, reviewed against the tree and the API, ⛔ not against the report

_{domain:services seat · session_01AhQASwqJr2Z7XfGWUdvnbF · Seat: domain:services#1 · written 2026-09-20T08:00Z. Readings pinned to head aef74f0fa.}

Shape and scope

draft ✅ · base main ✅ · first line Fixes #19198 ✅ · Clause-②: no at line start ✅. Machine closing-keyword scan over the whole body: exactly one hit, this card (#4443 / #983 carry no verb). 3 files — the changeset, approval-service.ts, and a new test. 🔴 packages/spec zero-change, as the dispatch required. No content/docs/releases/**.

Changeset owed and present, verified by reading: @objectstack/plugin-approvals has no private key ⇒ published ⇒ patch changeset correct.

The repair is the ruled one, read off the diff

referenceCarrierOf → referenceTargetOf, and the type gate is unchanged — still lookup · master_detail · user. The per-field catch is preserved (so one unreadable carrier cannot drop every reference field of the object), and tree is deliberately not admitted with the reason stated: it takes an author-chosen target, so admitting it would widen rather than repair. ⛔ The inverse fix the grading comment forbids — making authors materialize reference on user fields — was not taken.

Clause-② re-judged on the diff, ⛔ not inherited from the claim: the admitted type set does not grow, resolveLookupFields is private, and no exported surface moves. What changes is that the spelling the contract already calls complete now resolves. ⇒ no holds.

⭐ The contract quote was spot-checked verbatim on origin/main rather than taken from the PR body: packages/spec/src/data/field-value.zod.ts:165-168 reads 「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 … is fully specified, not under-specified.」 The changeset and the new docblock quote it accurately.

⭐ Why the green is readable: a narrow, direction-checked ablation

Run from the committed state with a trap-guarded restore: the anchor reference = referenceTargetOf(f); (hit ×1 as declared) was replaced with the pre-repair carrier read, blob 703a30813264 → b1fa2e3f0300 by the tool's own count+hash verdict, ⛔ not a sed exit code. Result: the three substantive new cases go red, while the two CONTROL cases and the whole sibling carrier suite stay green ⇒ the mutation is narrow and the direction is the predicted one. Restore proven by state — blob back to 703a30813264, git diff HEAD empty — ⛔ not by a wrapper's exit code.

check:test-typecheck reports 8 file(s) / 324 error(s) / 27 pinned signature(s) ⇒ the EXACT ratchet is unmoved and the new test file takes no debt entry.

CI

16 success · 3 skipped · 12 in_progress · 0 failure, pinned to aef74f0fa. Converging; ⛔ no flip to ready until the required jobs read conclusion: success on the then-current head and the whole set is green.

📥 Two triage inputs the delivery produced — ⛔ recorded, not acted on

1. The grading comment's upgrade trigger answers NO, and it was measured. The trigger was: if any approval routing or permission decision — ⛔ not merely display — consumes the enriched value, this becomes p1. Measured: resolveLookupFields has exactly one consumer (enrichRows); enrichRows has two call sites, both read APIs, and writes only display fields; approver routing reads the raw record (resolveApproverSpec's field arm does csvSplit(record[a.value]) and never consults a field definition's target). Corpus grep: payload_display has one writer and no reader; positive control on the same corpus and same grep, pending_approvers (a sibling field routing does consume), returns 10+ files ⇒ the zero is a reading. ⇒ stays p2 by the trigger's own terms. ⛔ Triage's to confirm.

2. 🔴 This card's own unverified note is HALF FALSIFIED — and it is this seat's note, so it is corrected here. The card said 「the analytics resolver does not admit type: user at all」. Measured: packages/services/service-analytics/src/dimension-labels.ts:142 already delegates to referenceTargetOf and its docblock names the user constant explicitly ⇒ false for the dimension-label resolver. What the note does hit is a different site, service-analytics/src/plugin.ts:735 (relationshipResolver), which gates on lookup || master_detail and reads referenceCarrierOf, so a user field named in a dataset include resolves no target — but that failure is LOUD (the dataset compiler rejects it), so it is a different shape from this card and may be deliberate. ⭐ The note was marked unverified on the card when filed, and that marking is exactly what made this cheap to correct instead of costly.

🔴 A class-(b) residue is being filed separately — with a scope the report UNDERSTATED

The delivery reported the same defect one package over at plugin-audit/src/audit-writers.ts:472. Verified on origin/main — and re-read the whole file rather than the named line, because understating a site count is the error this seat made on #18973 this shift. There are two carrier-gated planner sites, ⛔ not one: :471-473 in planTrackedLookupReads and :628-630 in the milestone-token planner — both admit user via REFERENCE_FIELD_TYPES and then continue unless field.reference is a non-empty string. referenceTargetOf is not imported in that file at all (positive control: the symbol is real and used in 6+ modules). The third REFERENCE_FIELD_TYPES site, :434 in displayFieldValue, does not gate on the carrier — it is the consumer where the symptom surfaces as a raw id. Filed with that corrected scope.

---

Generated by Claude Code