finding(core,app-shell): after #6528 the relationship-target resolvers still accept array / `{ object }` CARRIERS the spec refuses — same leniency, second axis

[os-sales]

Surfaced by the census in objectui#6528, deliberately left out of that PR's scope.

objectui#6528 narrowed both relationship-target resolvers to the single spec SPELLING reference. It did not touch the CARRIER — the shape the value may take — because that is a separate axis and its own census was not in the charter. Measuring it turns up the same class of unfounded leniency.

Measurement

@objectstack/spec 17.2.0, ObjectSchema.safeParse, one lookup field, three carriers for the canonical reference key:

carrier	verdict
reference: 'crm_account'	ACCEPTED (positive control — parses green, value survives)
reference: ['crm_account']	REFUSED — invalid_type: Invalid input: expected string, received array
reference: { object: 'crm_account' }	REFUSED — invalid_type: Invalid input: expected string, received object

FieldSchema.reference is a plain string. Both resolvers nonetheless still branch on all three:

• packages/core/src/utils/chart-series.ts — resolveRelationshipTarget
• packages/app-shell/src/views/metadata-admin/inspectors/useDatasetFields.ts — resolveReferenceTo

if (typeof raw === 'string' && raw) return raw;
if (Array.isArray(raw) && typeof raw[0] === 'string') return raw[0];
if (raw && typeof raw === 'object') { /* { object } */ }

The array branch additionally makes a silent product decision: given a multi-target value it returns raw[0] and discards the rest.

Why it was not cut in #6528

Scope discipline, and one unfinished measurement. The spelling census had a clean population count behind it (445 of 565 lookup / master_detail defs in the framework tree spell the key reference); the carrier axis does not yet. A grep for producers emitting an array carrier returned zero in both trees, but that zero has not been run down to the same standard — in particular whether any polymorphic / multi-target lookup is intended to carry a list. Cutting on an unfinished census is exactly what #6528 was filed to stop.

The question to settle

Same one AGENTS.md #0.1 asks: a lenient consumer is where a wrong producer hides. If nothing produces an array or { object } carrier, both branches are dead code that reads like a measurement and should go, in both files in one pass (they must not diverge). If something DOES produce one, that is a producer-side defect or a spec question about multi-target lookups — fix it there, not by keeping the tolerant read.

Whoever takes this: the refusal pins added by objectui#6528 (refuses the legacy spelling ...) are the pattern to extend, and the two carrier assertions currently live in useDatasetFields.test.ts and chart-series.test.ts as green pins that would need the same triage — updated with the helper, not preserved as cover.

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6648-relationship-target-carriers.

Dispatch order

type: Task, priority:p2. No triage comment — the card body is the brief, and it is deliberate about what it has not established.

⛔⛔ The census comes first, and cutting before it is the one forbidden move

The card is explicit that its own zero is not yet good enough:

A grep for producers emitting an array carrier returned zero in both trees, but that zero has not been run down to the same standard — in particular whether any polymorphic / multi-target lookup is intended to carry a list. Cutting on an unfinished census is exactly what #6528 was filed to stop.

⇒ Run the carrier census to #6528's standard before removing anything. #6528's spelling census had a real population behind it (445 of 565 lookup / master_detail defs spell the key reference). Yours needs the same rigour on the carrier axis.

⭐ Apply this seat's zero-rule while you do it: a zero does not exist until a positive control fires in the same query shape. Make the census key-position aware — a bare grep for reference will conflate tiers, exactly as #6670's options row did (71 bare hits, zero on a ListColumn).

The measured facts you are starting from

@objectstack/spec 17.2.0, ObjectSchema.safeParse, one lookup field:

carrier	verdict
reference: 'crm_account'	ACCEPTED (positive control)
reference: ['crm_account']	REFUSED — expected string, received array
reference: { object: 'crm_account' }	REFUSED — expected string, received object

FieldSchema.reference is a plain string. Both resolvers branch on all three anyway:

• packages/core/src/utils/chart-series.ts — resolveRelationshipTarget
• packages/app-shell/src/views/metadata-admin/inspectors/useDatasetFields.ts — resolveReferenceTo

⚠️ Name this in your report: the array branch makes a silent product decision — given a multi-target value it returns raw[0] and discards the rest. That is data loss wearing a compatibility shim.

The two outcomes, and what each requires

• Census confirms zero producers ⇒ both branches are dead code that reads like a measurement. Remove them in both files in one pass — they must not diverge.
• Census finds a producer ⇒ ⛔ stop and report. That is either a producer-side defect or a spec question about multi-target lookups. Fix it there; ⛔ do not keep the tolerant read as the answer.

⚠️ Two existing tests are cover, not evidence

the two carrier assertions currently live in useDatasetFields.test.ts and chart-series.test.ts as green pins that would need the same triage — updated with the helper, not preserved as cover.

⇒ Those green pins currently assert the tolerant behaviour. ⛔ Do not treat them as a reason the tolerance is wanted; they are the tolerance, written down. Update them with #6528's refusal-pin helper.

The pattern to extend

#6528's refusal pins (refuses the legacy spelling …) are the established shape. Extend that, don't invent a second one.

Report the census first (population, method, positive control), then the decision it forces, then red-before/green-after on the pins, and your changeset score with reasoning.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
  "issue": 6648,
  "status": "done",
  "branch": "claude/issue-6648-relationship-target-carriers",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6718",
  "premise_still_valid": true,
  "summary": "CENSUS FIRST, cut second. Population: every `reference` KEY occurrence in both trees (objectui @ 98188c284, objectstack @ 8cb96ec, both origin/main; the framework tree was checked out fresh, not read off a stale working copy). Method: never a grep — JSON/YAML parsed and walked recursively, TS/TSX/JS read through the TypeScript compiler API, each hit recorded with its ancestor property chain, its initializer classified by AST node kind, and the SIBLING KEYS of its enclosing object literal. Tier A = the key position these two resolvers actually read (a field def: a sibling `type` naming a relationship, or an ancestor chain through `fields`); Tier B = every other tier that spells `reference`. 10,439 files parsed; 16 parse failures, every one a JSONC `tsconfig*.json`, enumerated, none a metadata document. RESULT: 690 key hits total, 607 at Tier A, of which 587 are the bare-string carrier (the POSITIVE CONTROL; the 449 of those in the framework tree corroborates #6528's independently-taken 445 of 565) and ZERO array or `{ object }` carriers from any producer. Every non-string Tier-A hit was run down by hand: the 1 Tier-A array is the chart-series green pin; of 8 `{ object }` hits, 2 are the other green pins, 4 are translation entries for a metadata-form field literally NAMED `reference`, 1 is a JSON-Schema descriptor that itself says type string, 1 is a field named `reference` of type text, and 1 is an objectstack lint FIXTURE whose own rule reader (`refOf`) is already string-only; all 11 dynamic initializers resolve to string-typed sources (PARENT/ACCOUNT string consts, `foreignKey.referencedTable` declared string, an object-name map declared Record(string, string), the two designer writers' `referenceTo` declared string, and `null` under a `z.string().nullable()` blueprint schema). Independently, all 28 `reference` TYPE declarations in either tree declare `string`, bar three `unknown` at the tolerant read sites and one `string | string[]` whose runtime reader refuses non-strings anyway. THE ZERO IS NOT A BLIND QUERY: the string row fires at 587 in the same Tier-A query shape, AND the array/object detector itself demonstrably fires at exactly that key position — everything it found was a test asserting the tolerance. THE CARD'S OPEN QUESTION (is any polymorphic / multi-target lookup intended to carry a list?) IS ANSWERED NO, from four independent directions: `Field.reference` is `type: string` in the spec's own JSON Schema; polymorphic lookup is an acknowledged UNBUILT gap in the spec's own audit report (`Current reference only supports a single target`, Tier 3 item T3-2); the spec's `multiple` key means multiple VALUES of one target, not multiple targets; and the platform's one implemented polymorphic reference (ADR-0018 xRef) is a STRING with a sibling discriminator, never a list. DECISION FORCED: zero producers, so both branches are dead code that reads like a measurement — removed in BOTH files in ONE pass (`resolveRelationshipTarget` in packages/core/src/utils/chart-series.ts and `resolveReferenceTo` in packages/app-shell/src/views/metadata-admin/inspectors/useDatasetFields.ts), each now `typeof raw === 'string' && raw ? raw : undefined`. NAMED AS ASKED: the array branch made a silent PRODUCT decision — handed a multi-target value it returned raw[0] and DISCARDED the rest, no warning, a plausible-looking answer; that is data loss wearing a compatibility shim, and it is the AGENTS.md #0.1 shape where a wrong producer hides. The two green carrier pins were treated as cover, not evidence: they asserted `.toBe(...)` on the tolerant reads, and are converted to refusal pins EXTENDING #6528's `refuses the legacy spelling ...` shape (same it.each, same `a producer emitting it is the bug` wording, same toBeUndefined), plus a third case per file for the multi-element array — the discarded-rest case the old branch was silently answering. Changeset scored `patch` for both packages, reasoning stated in the file and the PR: no user-visible behaviour changes for any input ObjectSchema accepts (the census is the evidence, not an assumption); not minor (nothing additive), not major (the only inputs whose result changes are ones the spec already refuses); same score #6528 took for this class on the spelling axis.",
  "tests": "All verification through the shared verify lock; every verdict quoted is the wrapper's own VERDICT line, never a bare $?. GREEN UNION re-run AFTER the final commit, at HEAD adb1c9ec8: (1) `pnpm exec vitest run --maxWorkers=2` on both pinned files (from the REPO ROOT — the repo guard refuses a package-dir vitest as silently-false-green) => `Test Files 2 passed (2)`, `Tests 62 passed (62)`, VERDICT command-exit 0; (2) `pnpm --filter @object-ui/core --filter @object-ui/app-shell type-check` (= `tsc --noEmit && tsc -p tsconfig.test.json`) => `Done` for both, `Scope: 2 of 47 workspace projects` (so no zero-match silent pass), VERDICT command-exit 0 — and `tsc -p tsconfig.test.json --listFiles` confirms BOTH edited test files are inside the program, so `typecheck clean` actually covers them rather than being NOT MEASURED. Dependency closures built first: `pnpm --filter '@object-ui/core^...' --filter '@object-ui/app-shell^...' build`, VERDICT command-exit 0. `pnpm check:control-bytes` => its own verdict line `check-control-bytes: OK (scanned 5570 tracked text file(s); skipped 85 binary)`, plus a direct control-byte scan of the four edited files (no hits). ABLATION / RED-BEFORE, run AFTER the fix was committed so the restore leg had a real reference point. Precondition checked and stated: both test files import the source RELATIVELY (`../chart-series`, `./useDatasetFields`), not through package exports, so no dist is in the resolution path and no rebuild leg is required — stated rather than assumed. Mutation = `git checkout origin/main --` the two resolvers, PROVED ON DISK by anchored counts rather than an editor exit code: `Array.isArray(raw)` reintroduced 1/1, the narrowed return gone 0/0, plus a non-empty `git diff HEAD --stat`. Script carried `trap '<restore>' EXIT INT TERM` with absolute paths resolved from `git rev-parse --show-toplevel`. Predicted direction before running: RED, and specifically only the six new carrier pins. Observed: vitest exit 1, `Test Files 2 failed (2)`, `Tests 6 failed | 56 passed (62)` — the six failures are exactly the three carrier refusal pins in each file, nothing else moved. Restore proved BY OBSERVING STATE, not by an exit code: `git hash-object` of each path equals its HEAD blob (both matched, neither hash empty), `git diff HEAD` empty, `git status --porcelain` empty. NOTE ON ONE NOT-MEASURED READING: an earlier ablation attempt returned the wrapper's exit 99 (queue-timeout after a 9m wait) — recorded as NOT MEASURED, never as a red; the script never started, the tree was verified clean afterwards, and the parked slot was resumed for the run reported above. LINT WAS NARROWED, AND THE NARROWING IS MEASURED: (a) the population comes from eslint's own config resolution rather than a guess about which files count; (b) `--format json` reports 4 files linted, 0 errors, 4 warnings — all four pre-existing in useDatasetFields.ts at lines 193/277/324, outside this diff; (c) the root config extends tseslint.configs.recommended with NO parserOptions.project and no projectService, i.e. type-aware linting is OFF, so each file's verdict is a function of its own text plus the shared config and a diff touching four source files and no config file cannot move any untouched file's verdict. Gate family derived by hand from objectui's own package.json and .github/workflows (scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about the wrong tree); check:designer-field-key-parity was inspected and reads MetadataService.ts / MetadataFieldsPage.tsx / designer.ts / MetadataObjectsPage.tsx, none of which this diff touches. CI runs the full farm regardless. PR body re-read in full after creation: byte-identical to what was sent apart from a platform-appended signature footer — the sanitizer ate nothing.",
  "mcp_calls": "7 — issue_read(get), issue_read(get_comments), create_pull_request, issue_write x2 (the two findings), add_issue_comment x2 (this report, plus one PR comment carrying the finding links). Everything else went through zero-quota channels: repo-scoped unauthenticated REST for the label lists, the PR read-back and the dedupe corpus (search/issues is blocked for this seat — `sessions are bound to their configured repositories` — so the dedupe was REST list plus local grep, with `reference` as a control word that hit 63 times in the same corpus to prove the grep was not blind), and git for everything else.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectui#6719: `AuditFieldDef` in packages/app-shell/src/utils/auditHistoryDisplay.ts is a THIRD relationship-target reader neither #6528 nor #6648 touched — it declares `reference?: string | string[]` and `reference_to?: string | string[]` and reads `reference_to ?? reference`, i.e. a widened carrier type plus #6528's legacy-spelling chain with the legacy spelling FIRST. Observation-class: its runtime reader already narrows with `typeof target === 'string'` and its comment says `skip polymorphic`, so no wrong answer is produced today — and that third author's choice to REFUSE rather than take element zero is corroborating evidence for this PR. Not ridden along: different file, and the spelling half is a different axis with its own census standard.",
    "filed as objectstack#13053: packages/lint/src/runtime-gate.object-writes.test.ts:358 spells `reference: { object: 'shop_invoice' }` on a master_detail field def — a carrier ObjectSchema refuses, and one the rule's own reader (`refOf` in validate-security-posture.ts, string-only) resolves to undefined. The test still passes because it asserts finding PATHS, not the parent. Filed in the tree the fix lands in. This was the only non-string carrier at a field-def key position in either tree that was not itself a test asserting the tolerance this PR removes."
  ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-sales]

ACCEPT — PR #6718, head adb1c9ec8, ready and armed (29/29 green).

The census came first, and it is the best this seat has commissioned

The order said cutting before the census was the one forbidden move. What came back is a census, not a grep:

• 10,439 files parsed. JSON/YAML walked recursively; TS/TSX/JS read through the TypeScript compiler API; every hit recorded with its ancestor property chain, its initializer classified by AST node kind, and — the part that makes it work — the sibling keys of its enclosing object literal, so a reference on a field def is separable from one at any other tier.
• 16 parse failures, every one a JSONC tsconfig*.json, enumerated. None a metadata document.
• 690 key hits → 607 Tier A → 587 bare-string. ⭐ Zero array and zero { object } carriers from any producer.

Every non-string Tier-A hit was run down by hand rather than bucketed: the 1 array is the chart-series green pin; of 8 { object } hits, 2 are the other pins, 4 are translation entries for a metadata-form field literally named reference, 1 is a JSON-Schema descriptor that itself says type: string, 1 is a field named reference of type text, and 1 is an objectstack lint fixture whose own rule reader (refOf) is already string-only. All 11 dynamic initializers resolve to string-typed sources.

⭐ The zero is proven non-blind two independent ways

1. The string row fires at 587 in the same Tier-A query shape.
2. The array/{object} detector demonstrably fires at that exact key position — everything it found was a test asserting the very tolerance being removed.

A detector that found nothing anywhere would be indistinguishable from a broken query. This one found things, and they were all tests.

⭐⭐ The card's open question is answered NO from four independent directions

The card asked whether any polymorphic / multi-target lookup is intended to carry a list. Not one argument — four:

• Field.reference is type: string in the spec's own JSON Schema;
• polymorphic lookup is an acknowledged unbuilt gap in the spec's own audit report (Tier 3, T3-2: "Current reference only supports a single target");
• the spec's multiple key means multiple values of one target, not multiple targets;
• the platform's one implemented polymorphic reference, ADR-0018 xRef, is a string with a sibling discriminator — never a list.

⭐ Plus a cross-validation against an independent prior census: the 449 framework-tree strings corroborate #6528's separately-taken 445 of 565.

The decision that census forced

Zero producers ⇒ both branches are dead code that reads like a measurement. Removed in one pass across both files (resolveRelationshipTarget, resolveReferenceTo), each now typeof raw === 'string' && raw ? raw : undefined. They must not diverge, and they don't.

Named, as the order required: the array branch made a silent product decision — handed a multi-target value it returned raw[0] and discarded the rest, no warning, a plausible-looking answer. That is data loss wearing a compatibility shim, and it is precisely the AGENTS.md #0.1 shape where a wrong producer hides.

⭐ The two green pins were treated as cover, not evidence

They asserted .toBe(...) on the tolerant reads — i.e. they were the tolerance, written down. Converted to refusal pins extending #6528's shape (same it.each, same "a producer emitting it is the bug" wording, same toBeUndefined), plus a third case per file for the multi-element array — the discarded-rest case the old branch was silently answering, which had never been asserted at all.

Ablation: 6 failed / 56 passed, the six being exactly the three refusal pins in each file. ⭐ And an earlier ablation attempt returned the wrapper's exit 99 (queue timeout after a 9-minute wait) — recorded as NOT MEASURED, never as a red; the script never started and the tree was verified clean afterwards.

Scoring: patch on both packages, with the reasoning stated: no user-visible behaviour changes for any input ObjectSchema accepts — and the census is the evidence for that, not an assumption. Same score #6528 took for this class on the spelling axis.

Two findings, one cross-repo

• finding(app-shell): AuditFieldDef is a third relationship-target reader — widened carrier type + #6528's legacy spelling chain #6719 — AuditFieldDef is a third relationship-target reader neither finding(app-shell): resolveReferenceTos referenceTo branch is unreachable now that the read door strips the key #6528 nor this card touched, declaring reference?: string | string[] and reference_to?: string | string[] with the legacy spelling first. ⭐ Observation-class, and the reason it is filed rather than ridden along is good: its runtime reader already narrows with typeof target === 'string' and its comment says "skip polymorphic" — so that third author's choice to refuse rather than take element zero is corroborating evidence for this PR.
• objectstack#13053 — a lint test authors reference: { object: 'shop_invoice' } on a master_detail field def, a carrier ObjectSchema refuses and the rule's own reader resolves to undefined. It still passes because it asserts finding paths, not the parent. Filed in the tree the fix lands in. ⭐ It was also the only non-string carrier at a field-def key position in either tree that was not itself a test asserting the tolerance this PR removes — which is why it is worth a card rather than a footnote.

---

Generated by Claude Code