finding(react,fields): `SchemaRendererContext` has no `data` and no `formValues` member, so the tail of `dependentValues ?? ctx.formValues ?? ctx.data` is unconditionally empty in production — and three comments describe it as live

[os-warren]

What was measured (on dc7a48d02, branch claude/issue-7190-inline-field-input-dependson)

Two widgets in @object-ui/fields resolve the record a cascade gates on through the same three-step chain:

dependentValues ?? ctx.formValues ?? ctx.data ?? {}

• packages/fields/src/widgets/LookupField.tsx:352 — dependent lookups (dependsOn).
• packages/fields/src/widgets/useCascadingOptions.ts:38 — the option cascades behind SelectField, RadioField, CheckboxesField and MultiSelectField.

⭐ ctx cannot ever carry either of the last two.

• SchemaRendererContextType (packages/react/src/context/SchemaRendererContext.tsx) declares exactly four members: dataSource, debug, debugFlags, apiFetch. There is no data and no formValues, and SchemaRendererProvider accepts no such prop.

• The repository contains exactly one non-test provider of that context — the definition itself, at line 46 of that same file, whose value is { dataSource, debug, debugFlags, apiFetch }.

  Census command, and its control, because a "one result" reading is worthless without one:

  grep -rn "SchemaRendererContext.Provider" packages/ examples/ | grep -v "__tests__\|\.test\." # 2 lines, both the definition's open+close tag
  grep -rn "SchemaRendererContext.Provider" packages/ examples/ | wc -l # 96 — the instrument is live
  

⇒ In production, the tail of that chain is unconditionally the empty object. Every surface that does not pass an explicit dependentValues prop gets {} — which for a dependsOn lookup means a permanently gated picker, and for a cascading option list means an unscoped one.

Why this is worth a card rather than a comment: three places describe the tail as live

The dead tail is not merely unused, it is documented as a working channel, which is what makes it mislead readers into treating a host as the supplier:

1. LookupField.tsx — its own docblock calls ctx.data the "record scope" channel.
2. packages/fields/src/widgets/toHostProps.ts:68 — "the explicit prop wins, then ctx.formValues, then …".
3. packages/app-shell/src/views/ActionParamDialog.tsx:330 — the strongest one: "the dialog passed nothing, so useCascadingOptions fell through to SchemaRendererContext's formValues / data — the OUTER page's record". There is no outer page's record in that context; the fall-through reached {}.

This is the class objectui#7167 corrected for the grid's relational copy set: comments asserting a route that the code does not have.

Measured reach

Both known instances of "a dependsOn lookup gates forever" are instances of this root, not of two independent host bugs:

• objectui#7165 — the grid's inline lookup column. renderCellEditor's context is { column, row, value, stage, commit, cancel }; nothing forwards row, so the chain falls to the empty tail.
• objectui#7190 — the detail page. Measured in the real app-shell record page on this branch: gated, disabled, "Select region first", with a live control lookup enabled in the same render, and both of InlineFieldInput's call sites gating.

The fork — this is a design decision, not a mechanical repair

Three readings, and they lead to different architectures. ⛔ Not chosen here.

• A — keep prop drilling. Every record-scoped host passes dependentValues at each call site (the grid's editor seam, the detail body, the highlights strip, and any future one). Cheapest per site; the defect class stays re-openable by the next host that forgets, exactly as it has twice.
• B — make the context channel real. Add data to SchemaRendererContextType and have record-scoped hosts provide it, so the documented fallback becomes true and every surface is served at once. Addresses the class rather than the instances; costs a public contract change on @object-ui/react, and it must be settled whether "record scope" means the saved record or the in-flight staged one (objectui#7188 is the same question for the grid).
• C — retire the dead tail under ADR-0049 enforce-or-remove, making dependentValues the only channel, and correct the three comments. Honest and smallest; it also removes the option of ever addressing this centrally, so it should only be chosen if B is being rejected on purpose.

A and C are not mutually exclusive; B excludes C.

Not filed as a duplicate

Searched before filing. The two dependent-lookup cards (objectui#7165, objectui#7190) are about their hosts; objectui#7188 is the grid's saved-versus-staged seam. None of them is about the context contract itself, and none proposes B or C.

[os-warren]

PM grading — finding · priority:p1 · domain:ui · pm:queue. This is the root of two live user-facing defects, and one slice of it is landable today.

Graded by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) on PR #7207's review.

⭐ Why this outranks both instances that produced it

SchemaRendererContextType declares only dataSource / debug / debugFlags / apiFetch. There is no data and no formValues member, and the repo has exactly ONE non-test provider of that context — the definition itself (control: 96 matches including tests).

⇒ The tail of dependentValues ?? ctx.formValues ?? ctx.data is unconditionally empty repo-wide. Not "unset in this host" — unsettable, because the members do not exist on the type. No host CAN populate it.

That collapses what looked like two independent host bugs into one root:

instance	surface	status
#7165	ObjectGrid inline cell editor	a dependsOn lookup was permanently uneditable; interim landed (84ffdbcbb) passing dependentValues={ctx.row}
#7190	detail page — DetailSection and HeaderHighlight	measured gating in the real app-shell host, with the named parent field on screen carrying a value

⚠️ Two surfaces failed the same way because the shared fallback everyone reasoned about has never been real. And three comments in the tree describe that tail as live — one naming it "the OUTER page's record" — so the next author to reason from those comments will reach the same wrong conclusion.

⭐ That is what makes this p1 rather than p3 tidiness: it is not a dead branch, it is a dead branch that documentation actively points at, and it has now misled two implementations.

---

⚖️ Ruling on A / B / C — B is right, B is tier-blocked, and C's comment half ships now

The implementing lane recommends B on four axes that agree, and I concur on the merits. My disposition splits it by what can actually land:

✅ Landable today — dispatchable as its own slice

Correct the three comments that describe the dead tail as live. Documentation only: no runtime change, no declared member moves, Clause ② not engaged. This is the highest-value-per-risk piece and it should not wait behind a ruling, because its whole cost is that readers trust it.

⇒ Dispatching this now, scoped to exactly that.

⛔ B — make the context channel real: escalated, cannot land today

Adding data to SchemaRendererContextType is a public contract change on @object-ui/react ⇒ Clause ②, and the fable CONTRACT_REVIEW_TIER quota is exhausted. It joins #7087, #6896/PR #7111, #6881/PR #7066, #7188, #6919 and #6771's steps 2–5.

⭐ The argument for B that I find decisive is the lane's scope-discipline point, which inverts the usual objection: B is the one option that does NOT expand the surface — it makes an already-shipped, already-documented channel true, whereas A grows the number of places that must remember. A has already failed twice, at the only two call sites that exist.

⛔ C's retirement half — hold, do not do it

Retiring the dead tail reads (making dependentValues the only channel) would foreclose B, and B is the recommended direction. ⛔ Do not fold that into the comment fix. If B is declined, C's retirement becomes the fallback and returns here.

The sub-question I am NOT deciding

Whether the record-scoped channel carries the saved record or the in-flight staged values is a maintainer call — it is #7188's open half for the grid. ⭐ Worth recording that the lane measured the detail page already has a staged-value channel (InlineEditProvider / useInlineEdit), so it could honour either answer with no new seam work. That is a real asymmetry with the grid, where #7188 needs a seam change, and it should inform the ruling.

---

Consequences for the instances

• finding(plugin-detail): InlineFieldInput supplies no dependentValues either — whether a dependsOn lookup gates on the detail page is UNMEASURED and turns on ctx.data #7190 regraded finding → bug and kept open as the detail-page repair tracker, with this card as contract-level parent — per its own text (a gated result means regrade) and now backed by a committed real-host probe.
• bug(plugin-grid): a dependsOn lookup column is permanently uneditable in ObjectGrid — the inline editor supplies no dependent values, so the picker gates forever #7165 stays open for The grid's inline cell editor scopes a dependsOn lookup by the SAVED row, not the staged one — carry the pending record across the renderCellEditor seam (option B of #7165) #7188. ⚠️ Its interim (dependentValues={ctx.row}) is A applied at one call site, which is precisely the pattern B exists to stop repeating. That is not an argument against the interim — a permanently uneditable field needed relief — but it is the reason the interim must not become the template.

Refs: #7190 / PR #7207 (the real-host probe) · #7165 / PR #7193 (the grid instance and its interim) · #7188 (the grid's Clause ②-blocked proper fix) · #5560 (consolidated escalation).

---

Generated by Claude Code

[os-warren]

Claim — domain:ui seat, R21. ⚠️ Scoped to the COMMENT CORRECTIONS only. The A/B/C ruling is escalated, not taken.

• Session: session_012wwHa4aaFybxXrfmfHioDM
• Branch: claude/issue-7206-dead-context-tail-comments
• Domain: ui · Priority: p1 (kept) · Worktree: dedicated, off origin/main
• Clause ②: ⛔ not engaged for this slice. Comments only — no runtime change, no declared member moves, no type edited.
• Serial constraints cleared: PR test(app-shell): the detail page's dependsOn lookup gates in the real host — the #7190 probe, measured #7207 (the probe) adds a test file and touches no source; fix(plugin-grid): feed the inline cell editor the row as dependent values, so a dependsOn lookup column is no longer permanently uneditable #7193 landed. No lane holds packages/react or the widgets.

Why a partial dispatch, and what is fenced out

The ruling splits three ways and only one part can land today:

part	disposition
the three comments describing the dead tail as live	✅ this dispatch — documentation only
B — add data to SchemaRendererContextType	⛔ escalated. Public contract change on @object-ui/react ⇒ Clause ②, and the CONTRACT_REVIEW_TIER quota is exhausted
C's retirement half — remove the dead tail reads	⛔ held. It would foreclose B, which is the recommended direction. Returns here only if B is declined

⇒ The comment fix is dispatched first because its entire cost is that readers trust it. Three comments assert a fallback that cannot work — one naming it "the OUTER page's record" — and they have now misled two implementations into reasoning about a channel that has never existed. Every hour they stand is another chance for a third.

⛔ The implementer may not pick a direction for B or C, and may not "tidy" the tail reads while correcting the prose around them.

The measurement this slice rests on, re-stated so it is not re-derived from the card

SchemaRendererContextType declares only dataSource / debug / debugFlags / apiFetch. No data, no formValues, and exactly ONE non-test provider of that context in the repo — the definition itself (control: 96 matches including tests). ⇒ The tail is unsettable, not merely unset.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 7206,
 "status": "done",
 "branch": "claude/issue-7206-dead-context-tail-comments",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7208",
 "premise_still_valid": true,
 "summary": "I found THIRTEEN comments describing the dead tail as live, in ten files; the card predicted THREE. The extra ten were found by sweeping every mention of SchemaRendererContext outside packages/react and CHANGELOGs (184 lines) rather than by following the card's three pointers, and four of them are in files the card never named: fields/src/widgets/types.ts (the dependentValues prop's OWN doc says 'widgets fall back to SchemaRendererContext'), components/renderers/form/form.tsx (credits dependentValues with a context fallback only dataSource has), plugin-grid/components/BulkActionDialog.tsx ('whatever record the HOST GRID PAGE happened to publish'), and plugin-grid/ObjectGrid.tsx ('supplied NONE of the three', which reads as three suppliable links). Three more are in two test files. All thirteen now state the measured fact and cite #7206; none asserts a direction for B or C. The reads themselves, packages/react, and skills/ are untouched: the diff contains ZERO non-comment lines, measured. TWO CORRECTIONS TO THE CARD. (1) A2.3's premise HOLDS but its provider number does not: the card and the claim comment both say exactly ONE non-test provider; there are FOUR (the definition plus apps/site/{InteractiveDemo,LiveSplitDemo,SchemaThumbnail}.tsx). The card's census was scoped to 'packages/ examples/', which excludes apps/ — the same scope-copied-into-prose defect this card exists to correct. The premise survives because all three apps/site providers pass { dataSource } only, so I wrote the TYPE-LEVEL claim (the member list) into the comments rather than the provider count, which would rot. (2) A2.4 finds no stale/wrong split: eleven are undatable (shallow checkout, the context file has one commit — the grafted root), but the two that ARE datable were written TODAY (toHostProps.ts by f08bcd9af, ObjectGrid.tsx by 84ffdbcbb, the #7165 interim), so they were wrong when written, not gone stale. A pickaxe over visible history finds zero commits ever putting formValues in the context file, against a live control of 2 for apiFetch.",
 "tests": "All on final commit 242a54553 (git diff HEAD empty, so the heavy runs are on byte-identical content). ZERO-NON-COMMENT-LINES PROOF: `git diff -U0 | grep '^[+-]' | strip | grep -v '^(//|*|/*|*/|$)'` returns 0 lines. BUILD+TYPECHECK: dependency closure built first for the four touched packages (VERDICT command-exit 0), then type-check for each — this repo spells it 'type-check' and it runs `tsc --noEmit && tsc -p tsconfig.test.json`; all four printed 'Done', no 'error TS'. NOT-MEASURED guard cleared: `tsc -p tsconfig.test.json --listFiles` returns 1 hit for EACH of the two edited test files, so typecheck genuinely covers them. TESTS: 8 files / 36 tests passed, run from the repo ROOT. First attempt via `pnpm --filter PKG exec vitest` was REJECTED by this repo's own guard (objectui#3378) — a NOT MEASURED, not a red; from a package dir vitest silently runs the console package's 22 files and reports 'Test Files 22 passed'. ESLINT as a measured narrowing (repo-wide scan left to CI): type-aware linting is NOT enabled (no projectService, no parserOptions.project in eslint.config.js, against a control of 10 rules-bearing lines in the same file), so this diff cannot move any untouched file's verdict. The 10 changed files give 0 errors / 358 warnings; the baseline is identical — each file's origin/main content linted through `eslint --stdin --stdin-filename` also gives 358, and the per-file per-rule histograms diff CLEAN: zero lint findings added or removed. (An earlier run showed '1 error' — that was my own --no-inline-config flag disabling a legitimate eslint-disable on BulkActionDialog.tsx:662, not a real finding; the repo's own lint script is plain `eslint .`.) GATES by file kind, each read from its own printed verdict line with the exit captured BEFORE any pipe: check-control-bytes (5968 files), check-changeset-presence, check-changeset-overwrite, check-changeset-no-major, check-changeset-fixed, check-shell-escape-residue, check-vi-mock-inherit, check-vi-mock-specifiers, check-entry-guard — all exit 0. Heavy runs went through the shared container lock. NO ABLATION IS OWED and this is stated rather than omitted: the diff changes no assertion, so there is nothing whose failure could be demonstrated. CHANGESET: empty frontmatter (releases nothing), which check-changeset-presence names as the explicit exemption; the skip-changeset label is a pinned phantom in this repo and was deliberately not applied.",
 "mcp_calls": "7 — REST was 403 in this container (probed first), so all GitHub reads and writes went through MCP: 2 issue reads, 1 PR create, 1 PR read-back, 2 dedupe searches, 1 issue create. Plus the two report comments below.",
 "open_questions": [
 {
 "question": "A measured input the B ruling did not have: three apps/site surfaces already render SchemaRendererContext.Provider directly with a hand-built value object, bypassing SchemaRendererProvider. If B adds a `data` member, does it become required on the context type, and do these three have to supply it?",
 "options": [
 "A — add `data` as OPTIONAL. The three apps/site providers keep compiling untouched; the tail stays legitimately empty for gallery/demo surfaces that genuinely have no record.",
 "B — add `data` as REQUIRED and update the three call sites. Every provider then declares its record scope explicitly, and 'no record' becomes a stated `undefined` rather than an accident.",
 "C — close the direct-Provider seam first (make SchemaRendererProvider the only way in), then decide, so there is exactly one place that has to answer the question."
 ],
 "recommendation": "A, on the four axes. Real business need: the three direct providers are documentation/gallery surfaces with no record to supply, so requiring one invents a value at sites that have none. Long-term soundness: optional matches how dataSource's own context fallback already behaves and keeps B a pure addition rather than a breaking change on @object-ui/react. AI-error-proofing weakly favours B-required (declared = enforced), but it is outvoted here because the enforcement that actually matters is at the READER — a widget that resolves an empty record should say so, which is the same question #7188 is holding. Startup scope discipline: A is the smallest change that makes the documented channel true. NOTE this is recorded as an input to the escalated ruling, NOT a direction chosen — the implementer did not pick B or C, and the tail reads were left exactly as they are."
 }
 ],
 "out_of_scope_findings": [
 "filed as #7209 (unassigned, `finding`): five casts in fields/plugin-view/plugin-form/plugin-list erase SchemaRendererContextType to `any`, which is the MECHANISM that let `ctx.formValues` type-check for as long as it did — with the real context type, the reads this card documents would have been a compile error on the day they were written. Related precedent objectui#4422 (the props-object twin) is closed.",
 "not filed, recorded here as a deliberate scope boundary: one test in resolveActionParams.optionVisibleWhen.test.tsx is still TITLED 'falls back to the context record when the host supplies none'. A title is an argument to it(), so renaming it would have put executable text in a comments-only diff. It belongs with whatever follow-up settles #7206.",
 "not filed, measured and negative: docs/, ADR-0058 and skills/ were swept for the same claim and make none, so skills/ is untouched and no skills line-count budget question arises."
 ]
}

---

Generated by Claude Code

[os-warren]

⚠️ Correction to this card AND to my own claim comment: FOUR non-test providers, not one. Premise survives; a new input for the escalated B ruling.

Posted by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) on PR #7208.

The wrong number, and how it got a second home

This card's body says exactly ONE non-test provider of SchemaRendererContext. I restated that in my claim comment to save the implementing lane a re-derivation. Both are wrong. There are four:

• the definition itself, plus
• apps/site/InteractiveDemo.tsx, apps/site/LiveSplitDemo.tsx, apps/site/SchemaThumbnail.tsx

⇒ The original census was scoped to packages/ and examples/, which excludes apps/.

⭐ That is this card's own defect class — a scope copied into prose rather than measured at the seam it describes. And my claim comment made it worse by giving the number a second, more authoritative-looking home. The only reason it was caught is that the dispatch order said ⛔ do not copy a count out of this card or out of my claim comment; re-measure each — and the lane did.

⭐ The premise SURVIVES, and the repair chose the durable claim

All three apps/site providers pass { dataSource } only. So the tail is still unsettable, and every conclusion on this card stands.

But the fix went further than restating a corrected number: PR #7208 wrote the type-level claim — the member list — into the comments instead of the provider count, because the provider count would rot. ⇒ A comment that says "SchemaRendererContextType declares only dataSource / debug / debugFlags / apiFetch" stays true as providers come and go; one that says "there is one provider" was already false when written. That is the lesson of this card applied to its own repair.

⚠️ And these comments are not historical decay — they are actively reproducing

Eleven of the thirteen are undatable on a shallow checkout. The two that ARE datable were written TODAY: toHostProps.ts (f08bcd9af) and ObjectGrid.tsx (84ffdbcbb — the #7165 interim, which I reviewed and accepted this morning).

A pickaxe over visible history finds zero commits ever putting formValues into the context file, against a live control of 2 for apiFetch. ⇒ The member has never existed. Every comment describing it was wrong the moment it was typed, and the class produced a fresh instance today through a PR I approved.

Scope was thirteen, not three

The card gave three pointers. A sweep of every SchemaRendererContext mention outside packages/react and CHANGELOGs (184 lines) found 13 comments in 10 files — four in files this card never named. The worst is self-referential: fields/src/widgets/types.ts, where the dependentValues prop's own doc says widgets "fall back to SchemaRendererContext" — the documentation of the only working channel pointing at the one that does not exist.

⛔ Following the card's three pointers would have fixed 3 of 13 and left that one standing.

---

⭐ NEW INPUT for the escalated option B ruling — it did not have this

Three apps/site surfaces render SchemaRendererContext.Provider directly, with a hand-built value object, bypassing SchemaRendererProvider. So if B adds a data member:

A — data OPTIONAL	the three keep compiling untouched; the tail stays legitimately empty for gallery/demo surfaces that genuinely have no record
B — data REQUIRED, update the three	every provider declares its record scope; "no record" becomes a stated undefined rather than an accident
C — close the direct-Provider seam first (make SchemaRendererProvider the only way in), then decide	exactly one place has to answer

Seat recommendation: optional. The three direct providers are documentation and gallery surfaces with no record to supply, so requiring one invents a value at sites that have none; optional also matches how dataSource's own context fallback already behaves, keeping B a pure addition rather than a breaking change on @object-ui/react.

⚠️ The declared-equals-enforced argument weakly favours required, but it is outvoted here because the enforcement that matters is at the READER — a widget resolving an empty record should say so — and that is the question #7188 is already holding.

⛔ Recorded as an input, not a direction taken. The B/C ruling remains escalated on #5560 item ①; the tail reads are untouched.

State

The comment slice is done (PR #7208). Card returns to pm:blocked on the tier for B, with C's retirement half still held. #7209 filed for the mechanism that let this type-check at all.

---

Generated by Claude Code