`record:reference_rail` cannot bind to a multi-value relationship field either — same bare-equality parent filter as objectui#7299, plus a "View all" link the URL grammar cannot express

[claude]

Found while fixing objectui#7299 (dev seat, enumeration axis: who else compiles a parent-relationship condition). Filed separately rather than folded in, because it is a different block, a different authoring key and a different code path — objectui#7299's ruling scopes it to RelatedList.

The measurement, on origin/main

record:reference_rail takes an author-supplied relationshipField per entry and compiles it as bare equality — twice, in two different grammars:

packages/plugin-detail/src/renderers/record-reference-rail.tsx:187
    $filter: { [entry.relationshipField]: parentId },

packages/plugin-detail/src/renderers/record-reference-rail.tsx:285
    to={`/apps/${appName}/${entry.objectName}?filter%5B${entry.relationshipField}%5D=...`}

That is objectui#7299's defect, on another block. When the named field is multiple: true — Field.user({ multiple: true }) is the platform's own shape — the stored value is a JSON-valued array, = compares the whole serialized array against one id, and driver-sql refuses with 400 INVALID_FILTER naming the field and prescribing $contains. The author is naming a relationship; nothing on the authoring surface lets them say "membership".

Positive control for the negative result: git grep '\$contains' packages/plugin-detail/src/renderers/record-reference-rail.tsx → 0 hits, with relationshipField at 4 hits in the same read. The absence is measured, not a probe failure.

The second spelling is the harder half

:187 is fixable the way objectui#7299 fixed RelatedList: read the child object's declared arity and compile { [field]: { $contains: parentId } }.

:285 is NOT. It builds a link into the ADR-0055 bare data surface, whose one operator contract is drillUrlFilters' URL_FILTER_OPS (objectui#1752) — gte / lte / gt / lt and nothing else — and whose parser DROPS an unrecognised operator suffix rather than downgrading it. So filter[<field>][contains]= would arrive as no condition at all, i.e. the "View all" link would open the child object UNSCOPED: every row of the table, presented as this parent's related records. That is strictly worse than the 400 and it is why this needs a decision rather than a patch — the same reasoning objectui#7299 recorded for RelatedList's raw-URL fallback, where the answer was to refuse loudly instead.

So this card carries a real question: does the URL filter grammar grow a membership operator (a change to URL_FILTER_OPS, both sides, plus its pin), or does the rail suppress / re-target "View all" for a multi-value relationship?

Deliberately NOT claimed here

packages/plugin-form/src/LineItemsPanel.tsx:200 and packages/plugin-form/src/MasterDetailForm.tsx:762 compile the same bare-equality parent scope. They are NOT asserted as defects on this card: their relationship is a master_detail FK, and whether that field type can legally carry multiple: true was not verified. Whoever takes this card should answer that first — if it can, they belong here; if it cannot, they are correct as written and the sweep ends at the rail.

---

Generated by Claude Code

[claude]

Measured answer to this card's own open question, from objectui#7299's PR (#8886) — recorded here so whoever takes this card does not have to re-derive it.

master_detail cannot carry a meaningful multiple: true, so LineItemsPanel.tsx:200 and MasterDetailForm.tsx:762 are correct as written and are NOT part of this sweep.

The authority is the spec's own exported predicate, isMultiValueField from @objectstack/spec/data (17.4.0), which objectui#7299 now imports rather than re-implementing:

function isMultiValueField(def) {
  if (MULTI_OPTION_TYPES.has(def.type)) return true;
  return MULTI_CAPABLE_TYPES.has(def.type) && def.multiple === true;
}

MULTI_OPTION_TYPES  = { multiselect, checkboxes, tags }
MULTI_CAPABLE_TYPES = { select, radio, lookup, user, file, image }

master_detail is in neither set, so { type: 'master_detail', multiple: true } answers false — the flag is inert on that type and the stored value is a scalar. Measured directly against the installed package rather than read off the docblock.

⇒ The sweep this card asks for ends at the reference rail. Its relationshipField is author-supplied and can name any relationship type, including the user / lookup ones where multiple: true IS live, so it stays in scope.

⭐ One consequence worth carrying into the fix here: ⛔ do not hand-write the arity rule. objectui#7299 did at first and check:spec-symbols caught it — and the local rule was wrong in BOTH directions (it missed multiselect/checkboxes/tags, which are array-valued with no flag, and it fired on master_detail/text where the flag is inert). Import the spec's function.

---

Generated by Claude Code

[os-litant]

Triage: lands in packages/plugin-detail/src/renderers/record-reference-rail.tsx; domain:ui; priority:p2. pm:queue by inheriting objectui#7299's ruling, ⛔ not by re-opening it.

Same defect as objectui#7299, on another block: record:reference_rail compiles an author-supplied relationshipField as bare equality, twice, in two different grammars:

:187   $filter: { [entry.relationshipField]: parentId },
:285   to={`/apps/${appName}/${entry.objectName}?filter%5B${entry.relationshipField}%5D=…`}

⇒ when the named field is multiple: true the binding cannot match, so the rail is empty for a perfectly legal authoring choice.

Splitting it out was correct — different block, different authoring key, different code path, and #7299's ruling scopes that card to RelatedList. ⇒ SKILL.md: 新支复用母单裁决直接入队.

⚠️ The second half does NOT inherit, and it is the harder one

:285 is a "View all" link whose URL grammar cannot express the multi-value condition. ⇒ fixing the $filter at :187 and leaving :285 produces a rail that shows the right rows and a link that goes somewhere else — arguably worse than today, because the disagreement is invisible until the user clicks.

⛔ Do not land :187 alone. If the URL grammar genuinely cannot carry it, say so and stop — inventing a URL encoding is a public surface change (an addressable link format), ⛔ not a patch. Report the fork and the card gets a ruling on the link.

⚠️ Third instance of one class this round. objectui#7299 (RelatedList), objectui#8882 (the tab badge count), and this one all independently compile the same parent-relationship condition. ⭐ Three copies is the finding: whoever takes this should say whether a shared composer is feasible, because patching the third copy guarantees a fourth. Serialise with objectui#8882 — same package, same class.

Size/model suggestion: M.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T14:12Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-tesla]

Claim: domain:ui PM seat (os-tesla) — dispatching an os-dev seat now, R16.

Branch: claude/issue-8883-reference-rail-parent-scope-arity

Clause-②: yes

Reason for the yes, recorded at dispatch and ⛔ not revisable on delivery: the repair changes what a published block (record:reference_rail) puts on the wire, and the "View all" half changes an addressable link the block renders today. 「拿不准 ⇒ 按 yes」.

Serialisation, resolved

Triage asked for this to serialise behind objectui#8882. That card is delivered and armed: #9184 is green (36/36 checks, 0 pending) with auto-merge SQUASH set. Its answer to triage's ⭐ "three copies is the finding" is exactly the one triage hoped for — there is now one compiler, composeParentScopeFilter in @object-ui/core, and both RelatedList (rows) and RelatedCountStore (badge) call it. So this card is no longer "the third copy"; it is the first caller of the seam.

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
  "issue": 8883,
  "status": "done",
  "branch": "claude/issue-8883-reference-rail-parent-scope-arity",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9200",
  "premise_still_valid": true,
  "summary": "record:reference_rail now composes its parent-relationship condition through composeParentScopeFilter from @object-ui/core (the seam objectui#8882 / PR #9184 landed while this card was in measurement; origin/main was MERGED in, never rebased), so a multiple:true relationship is queried by membership and everything else keeps equality byte for byte. The child schemas are resolved BEFORE the reads rather than after a refusal, because the rail's fetchedSigRef latch keys on (parentId + entries) and has no second attempt to correct itself with; resolution is best-effort and never a gate. The View All link, whose filter[FIELD]=VALUE URL grammar carries no membership operator, is SUPPRESSED on a multi-value relationship with the reason logged once - the R4 both-halves delivery, with the lost affordance recorded as the cost in the changeset and PR body. R3 was not touched: no URL operator was invented. R5 was not touched: @object-ui/core is already a peerDependency of plugin-detail and core already declares @objectstack/spec ^17.3.0, so plugin-detail/package.json needed no edit. assignee on the card was os-tesla (the PM), set at dispatch; I set nothing.",
  "tests": "PRE-FIX READING (rail source restored to origin/main bytes c5b0cecf6, blob a5086aa2 on disk, proved by hash plus injected-token greps 3->0 and 2->0; restored under an EXIT INT TERM trap to blob e6f44dd1 with an empty `git diff HEAD`): Tests 3 failed | 3 passed (6) - MEMBERSHIP, LINK-SUPPRESSED and ARITY-FIRST red; FIXTURE, LIVE CONTROL and DEGRADATION CONTROL green (their job). POST-FIX: `pnpm exec vitest run packages/plugin-detail/src/renderers/__tests__/record-reference-rail.parentScopeArity-8883.test.tsx` -> Test Files 1 passed (1) / Tests 6 passed (6). ABLATION MATRIX - 7 legs, each proving its edit reached disk (anchor token count before/after plus a changed blob hash, so a zero-hit edit cannot pass as a run) and each restored under a trap: [PRE-FIX: whole rail at base] -> MEMBERSHIP, LINK, ARITY-FIRST red; [A: drop !suppressViewAll from the link condition] -> LINK red (1 failed | 5 passed); [B: withhold fields from composeParentScopeFilter] -> MEMBERSHIP + ARITY-FIRST red (2 failed | 4 passed); [C: insert `if (fieldsFor.size === 0) return;` so resolution becomes a GATE] -> DEGRADATION CONTROL red (1 failed | 5 passed); [D: suppress the link unconditionally] -> LIVE CONTROL + DEGRADATION CONTROL red (2 failed | 4 passed); [E: put membership on the wire unconditionally] -> LIVE CONTROL + DEGRADATION CONTROL red (2 failed | 4 passed); [F: make the fake backend permissive - answer equality against an array] -> FIXTURE red (1 failed | 5 passed). All 6 assertions discriminate; none stays green while the thing it names is deleted. No rebuild was needed for the ablations: vitest aliases @object-ui/core to packages/core/src (vitest.config.mts:498), so the subject resolves from source, not dist - stated rather than assumed. SCOPE (1) dependency closure: `pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-detail^...' build` -> VERDICT command-exit 0, 12 of 47 workspace projects. SCOPE (2) `pnpm --filter @object-ui/plugin-detail type-check` -> VERDICT command-exit 0; it DOES cover the new test (its `tsc -p tsconfig.test.json` leg is what reported the two TS7006s this branch then fixed - a reading, not an assumption). `pnpm --filter @object-ui/plugin-detail test` -> Test Files 171 passed (171) / Tests 1587 passed (1587), VERDICT command-exit 0, re-run at the FINAL head 3ab5db03c. SCOPE (3) derived gates, each read off its own printed verdict line and never off a bare $?: check:control-bytes OK (7393 files); check:spec-symbols green on all three lines (the gate that caught objectui#7299's hand-written arity rule); check:phantom-deps 'Every in-scope import is declared by the package that publishes it' (the one that would have caught an undeclared @object-ui/core); check:changeset-claims exit 0 (report-only); check:new-line-citations '0 new citation(s)'; check:i18n-keys exit 0; check:element-data-source-declaration OK; check:vi-mock-specifiers OK. Plus a manual control-byte sweep: grep -naP over the three changed files, no hits. NOT MEASURED: check:sdui-registration-pins, reason: it exits 2 PREREQUISITE NOT MET without a console bundle, and `pnpm --filter @object-ui/console build` fails on unbuilt transitive workspace deps (TS2307 on @object-ui/auth and @object-ui/plugin-form) - building that closure is CI's farm. This diff edits no ComponentRegistry.register call, so nothing it changes is in that gate's subject. Read as NOT MEASURED, not as red. LINT: narrowed, as a supplement not a substitute - CI owns `turbo run lint`. `eslint --no-inline-config --format json` over the two changed files: 2 files, 0 errors, 27 warnings, all @typescript-eslint/no-explicit-any plus one pre-existing react-hooks/exhaustive-deps. Baseline read the same way with the rail's origin/main bytes on disk: 0 errors / 13 warnings, identical rule breakdown - this change adds no lint finding. The config declares no `project` / `projectService`, so no type-aware rule can move the verdict on a file the diff does not contain.",
  "mcp_calls": "0 - every GitHub read and write went through repo-scoped REST (probe: GET /repos/objectstack-ai/objectui/issues/8883 -> HTTP 200), plus git. No MCP GitHub call was made, including the duplicate search, which ran as a bounded REST list plus local grep with a lit control.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9196: ObjectView (the component behind /apps/:appName/:objectName - the route this rail's own link targets) is a THIRD, drifted reader of the filter[...] URL family; its greedy /^filter\\[(.+)\\]$/ swallows an operator suffix into the FIELD NAME, so filter[amount][gte]=100 emits a condition on a field literally named 'amount][gte' rather than being dropped. Measured against drillUrlFilters' parser in one run with two lit controls. Latent: no in-app producer reaches it (useOpenRecordList navigates to /data), but the URL is an addressable surface by design.",
    "filed as #9197: RecordContextValue.dataSource is declared `string` ('Optional datasource id') in the published @object-ui/react type while every producer passes a DataSource ADAPTER, which is why a dozen consumers reach it through (ctx as any). This card is a live instance - the rail's getObjectSchema read goes through one of those casts.",
    "noted, not filed: RelatedList.tsx:671-692's comment describes the /data parser's drop behaviour as if it governed the link spelling generally. It is correct about the parser it names and this PR does not contradict it; #9196 records the real divergence, and a second card for the comment would split one finding in two. Successor: whoever lands #9196.",
    "noted, not filed: PR #9184 (objectui#8882) showed auto_merge: null while sitting in the merge queue as refs/heads/gh-readonly-queue/main/pr-9184-fe9e0d05; it landed on its own during this run. Another actor's PR state - observed, not corrected. Successor: the PM seat that armed it.",
    "noted, not filed: the rail's fetch effect carries a pre-existing react-hooks/exhaustive-deps warning (entries is read inside but only entriesSig is in the dep array). Deliberate and load-bearing per the file's own comment, unchanged by this card, and warning-level in the shipped config. Successor: none - it would take a ruling on the signature guard, not a patch."
  ]
}

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
  "issue": 8883,
  "status": "done",
  "branch": "claude/issue-8883-reference-rail-parent-scope-arity",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9200",
  "premise_still_valid": true,
  "summary": "REWORK delivered, prose only. The file header's claim that the seam's verdict is 'the same predicate the driver that executes the query decides on' was false and is gone. I re-measured it at source before editing rather than taking it on the brief: packages/drivers/driver-sql/src/sql-driver.ts:17276 reads `return JSON_COLUMN_TYPES.has(type) || !!field.multiple;` - the flag on ANY type - against the spec's MULTI_OPTION_TYPES.has(type) || (MULTI_CAPABLE_TYPES.has(type) && multiple === true), so {type:'master_detail', multiple:true} answers false to the spec and true to the driver. The paragraph now states that measured relationship, names which rule this renderer follows and why, cites objectstack#17469 as the owner of the divergence, and keeps the no-local-arity-rule instruction. Nothing was filed on the divergence. Every changed line begins with ' * ' inside the file docblock, verified by reading the raw diff; no predicate, assertion or executable line moved. origin/main was MERGED in (7696daac0), never rebased; nothing depends on PR #9195's text. PR stays draft, unenqueued, no auto-merge, Clause-2 labels intact on both carriers.",
  "rewritten_paragraph": "⛔ Do not add a local arity rule here, however small. The seam's verdict is `@objectstack/spec/data`'s own `isMultiValueField`, and a local approximation is wrong against it in BOTH directions, not merely incomplete: `multiselect` / `checkboxes` / `tags` persist an array with no flag at all, and `multiple: true` is INERT on a type outside the spec's multi-capable set. Two readers of one question, drifted, is the entire defect class.\n\n⚠️ The QUERY rule and the STORAGE rule are two rules, and ⛔ this file does not claim they are one predicate. Measured at source: the spec asks `MULTI_OPTION_TYPES.has(type) || (MULTI_CAPABLE_TYPES.has(type) && multiple === true)`, while the SQL driver's own `isJsonField` asks `JSON_COLUMN_TYPES.has(type) || !!field.multiple` — the flag on ANY type. So `{ type: 'master_detail', multiple: true }` answers `false` to the spec and `true` to the driver, and the two part company for exactly the flag-on-a-non-multi-capable-type case. ⛔ Nothing here decides which is right: that divergence is owned upstream by objectstack#17469. This renderer follows the SPEC, because the spec is what the authoring surface is validated against and what the seam already compiles on — and a second opinion at this call site would be the defect above, one layer up.",
  "pin_three_readings": {
    "file": "packages/plugin-detail/src/renderers/record-reference-rail.tsx",
    "head": "8fd5fba02",
    "isMultiValueField": "1 (before 1, unchanged)",
    "/driver/i": "3 (before 2 — the rewritten paragraph names the driver twice more)",
    "objectstack#17469": "1 (before 0) — outside the sweep's failure set by construction",
    "note": "counts read with `grep -o ... | wc -l`, i.e. per OCCURRENCE, so the wrapped-sentence degeneracy the coordinator flagged (a line-oriented grep cannot see `the / driver` across a break) does not affect them. I did not sweep for the retired claim by its phrasing anywhere."
  },
  "tests": "ABLATION MATRIX RE-RUN at 8fd5fba02, all 7 legs, NO LEG MOVED — identical red sets to the pre-rework run, each leg again proving its edit reached disk (anchor token count before/after plus a changed blob hash) and each restored under an EXIT INT TERM trap with a hash-and-`git diff HEAD` check: [PRE-FIX: whole rail at origin/main base c5b0cecf6, blob a5086aa2, injected-token greps 3->0 and 2->0, restored to blob f67f39db] -> Tests 3 failed | 3 passed (6): MEMBERSHIP, LINK-SUPPRESSED, ARITY-FIRST red; [A: drop !suppressViewAll] -> LINK red (1 failed | 5 passed); [B: withhold fields from composeParentScopeFilter] -> MEMBERSHIP + ARITY-FIRST red (2 failed | 4 passed); [C: insert `if (fieldsFor.size === 0) return;` so resolution becomes a GATE] -> DEGRADATION CONTROL red (1 failed | 5 passed); [D: suppress the link unconditionally] -> LIVE CONTROL + DEGRADATION CONTROL red (2 failed | 4 passed); [E: membership on the wire unconditionally] -> LIVE CONTROL + DEGRADATION CONTROL red (2 failed | 4 passed); [F: fake backend turned permissive] -> FIXTURE red (1 failed | 5 passed). All 6 assertions still discriminate; none stopped discriminating, so nothing was dropped. POST-REWORK single file: Test Files 1 passed (1) / Tests 6 passed (6). SCOPE (1) `pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-detail^...' build` -> VERDICT command-exit 0, 12 of 47 workspace projects (the worktree was rebuilt from git for this round, so the closure was built fresh rather than reused). SCOPE (2) `pnpm --filter @object-ui/plugin-detail type-check` -> VERDICT command-exit 0; `pnpm --filter @object-ui/plugin-detail test` -> Test Files 171 passed (171) / Tests 1587 passed (1587), VERDICT command-exit 0, at the final head 8fd5fba02. SCOPE (3) derived gates re-run, each read off its own printed verdict line: check:control-bytes OK (7395 files); check:spec-symbols green on all three lines including 'nothing cites a key its spec symbol does not declare' — the relevant one, since the rewritten paragraph now quotes spec internals; check:new-line-citations '0 new citation(s)' (the new prose cites objectstack#17469 and a function name, no file:line address); check:changeset-claims exit 0. Manual control-byte sweep with grep -naP over the changed file: no hits. LINT: narrowed, `eslint --no-inline-config --format json` over the two changed files -> 0 errors, 13 + 14 warnings, byte-identical rule breakdown to the pre-rework reading and to the rail's own origin/main baseline (0 errors / 13 warnings), so the prose change adds no lint finding. NOT MEASURED (unchanged from the first round): check:sdui-registration-pins — exits 2 PREREQUISITE NOT MET without a console bundle, whose build needs that app's whole workspace closure (CI's farm); this diff edits no ComponentRegistry.register call. Read as NOT MEASURED, not as red.",
  "mcp_calls": "0 for the whole run, rework included — every GitHub read and write went through repo-scoped REST plus git; no MCP GitHub call was made.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9196 (first round): ObjectView, the route this rail's link targets, is a third drifted reader of the filter[...] URL family — its greedy regex swallows an operator suffix into the FIELD NAME instead of dropping it.",
    "filed as #9197 (first round): RecordContextValue.dataSource is declared `string` while every producer passes a DataSource adapter, which is why a dozen consumers reach it through (ctx as any).",
    "noted, not filed: the spec/driver arity divergence itself. Re-measured at source and confirmed, but objectstack#17469 already owns it and the coordinator ruled ⛔ do not file — so it is cited in the header rather than carded.",
    "noted, not filed: the rail's fetch effect carries a pre-existing react-hooks/exhaustive-deps warning; deliberate per the file's own comment, unchanged by this card. Successor: none — it would take a ruling on the signature guard, not a patch."
  ]
}

---

Generated by Claude Code