docs(fields,app-shell,components,plugin-grid): the ctx.formValues / ctx.data tail is unsettable, not a live channel

[os-warren]

Part of #7206 — the comment-correction slice only. The A/B/C ruling is escalated and untouched here.

What this changes

Comments, and nothing else. The diff contains zero non-comment lines, measured rather than asserted:

git diff -U0 | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)' \
  | sed 's/^[+-]//' | sed 's/^[[:space:]]*//' | grep -vE '^(//|\*|/\*|\*/|$)'
# 0 lines

The ?? ctx.formValues ?? ctx.data reads are left exactly as they are — retiring them is option C's half, which would foreclose option B, and B is the recommended direction. packages/react is not touched at all.

The measurement these comments now state

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

⇒ The tail of dependentValues ?? ctx.formValues ?? ctx.data ?? {} is unconditionally empty in production. Unsettable, not merely unset: no host can populate a member the type does not declare. dependentValues is today the only channel that can carry a record.

Every corrected comment states that and cites #7206. None of them asserts a direction: the prose deliberately does not say the tail "will be removed" or that a data member "is planned", because neither is decided.

Re-derived against the card's assumptions

The card predicted three such comments. I found thirteen, in ten files.

where	the claim that was wrong
fields/src/widgets/LookupField.tsx (x2)	called ctx.data the "record scope" channel, and ctx.formValues a "form-data context provided by @object-ui/react"
fields/src/widgets/useCascadingOptions.ts	"falling back to the record on SchemaRendererContext"
fields/src/widgets/toHostProps.ts	precedence table: "the explicit prop wins, then ctx.formValues, then ctx.data"
fields/src/widgets/types.ts	the declared prop's own doc: "widgets fall back to SchemaRendererContext"
app-shell/src/views/ActionParamDialog.tsx	"fell through to SchemaRendererContext's formValues / data — the OUTER page's record"
plugin-grid/src/components/BulkActionDialog.tsx	"fell through its chain ... to whatever record the HOST GRID PAGE happened to publish"
components/src/renderers/form/form.tsx	credited dependentValues with a context fallback that only dataSource has
plugin-grid/src/ObjectGrid.tsx	"supplied NONE of the three", which reads as three suppliable links
app-shell/.../resolveActionParams.optionVisibleWhen.test.tsx (x3)	the chain "must still work from the second link down for every widget rendered outside a dialog"
components/.../form-data-source-wiring.test.tsx	"Two of them have a SchemaRendererContext fallback"

Two of these are worth calling out beyond the count:

• ActionParamDialog.tsx recorded a "ruled cost" that was never paid. It said supplying the dialog's values means a predicate naming a row field "no longer resolves against the host page here". Measured, it never resolved against a host page — the tail could not reach one before either. The cost is real as a description of the code shape, but it was not a loss. That paragraph now says so.
• form.tsx and its sibling test both said two of the three props have a context fallback. Only dataSource does. That one is not stale framing, it is a wrong member count.

A2.2 — verified, and nothing else reads the chain. Exactly two executable readers, both in @object-ui/fields: LookupField.tsx:372 and useCascadingOptions.ts:47. A repo-wide git grep -n '\.formValues' returns 17 lines, and every one outside those two is prose, a changelog, or a test.

A2.3 — the load-bearing claim holds, but its provider number does not. The card and the claim comment both say exactly ONE non-test provider. I count four:

git grep -n 'SchemaRendererContext\.Provider' -- . | grep -v '__tests__\|\.test\.\|\.spec\.'
# packages/react/src/context/SchemaRendererContext.tsx:46   (the definition)
# apps/site/app/components/InteractiveDemo.tsx:37
# apps/site/app/components/LiveSplitDemo.tsx:280
# apps/site/app/components/SchemaThumbnail.tsx:148
# control, same query shape, whole repo including tests: 102 lines

The card's census command was scoped to packages/ examples/, which excludes apps/. That is exactly the defect class this card is about — a scope copied into prose rather than measured at the seam it describes — so it is recorded here rather than quietly corrected.

The premise survives it. All three apps/site providers pass { dataSource } and nothing else (defaultCtx at InteractiveDemo.tsx:33, LiveSplitDemo.tsx:46, SchemaThumbnail.tsx:38). No provider supplies data or formValues, and none could. The comments here therefore make the type-level claim, not the provider-count claim — the member list is what makes the tail unsettable, and it does not rot when someone adds a fifth provider.

A2.4 — no stale/wrong split; at least two were wrong on the day. Blame is uninformative for eleven of the thirteen: this checkout is shallow and the context file has exactly one commit, the grafted root ad0f5f11f. Two are datable and both were written today, hours before this measurement — toHostProps.ts:68 (f08bcd9af) and ObjectGrid.tsx:3753 (84ffdbcbb, the #7165 interim). A pickaxe over the visible history finds zero commits that ever put formValues in the context file, against a live control:

git log --all --oneline -S formValues -- packages/react/src/context/SchemaRendererContext.tsx   # 0
git log --all --oneline -S apiFetch   -- packages/react/src/context/SchemaRendererContext.tsx   # 2  (control)

So nothing here is stale-but-once-true within reach of this history.

Verification, on 242a54553

All of the following ran on the final commit; the heavy runs ran on byte-identical content (git diff HEAD empty).

• Dependency closure built first for the four touched packages, then type-check for each — tsc --noEmit && tsc -p tsconfig.test.json, all four Done, no error TS. The two edited test files are genuinely in that program, not merely adjacent to it: tsc -p tsconfig.test.json --listFiles returns 1 hit for each.
• Targeted tests: 8 files, 36 tests, all passed, run from the repo root. Note the first attempt via pnpm --filter PKG exec vitest was rejected by this repo's own guard (objectui#3378) rather than run — a NOT MEASURED, not a red; from a package directory vitest silently runs the console package's 22 files and reports them as passing.
• ESLint, as a measured narrowing rather than a skip. Type-aware linting is not enabled (no projectService and no parserOptions.project in eslint.config.js, against a control that finds 10 rules-bearing lines in the same file), so this diff cannot move the verdict of any file it does not touch. The 10 changed files lint with 0 errors / 358 warnings, and the baseline is identical: linting each file's origin/main content through eslint --stdin --stdin-filename gives 358 findings too, and the per-file per-rule histograms diff clean. Zero lint findings added or removed. The repo-wide scan stays CI's.
• Gates by file kind, each read from its own verdict line, 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.
• No ablation is owed, stated rather than omitted: this diff changes no assertion, so there is nothing whose failure could be demonstrated.

The changeset has 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.

Deliberate scope boundaries

• 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 put executable text in this diff. The corrected comment sits directly above the assertion instead; the rename belongs with the follow-up work on 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 #7206.
• CHANGELOG.md entries carrying the old framing were left alone — they are the historical record of what was said at the time, and two of them already say "a member SchemaRendererContext never had".
• Docs, ADR-0058 and skills/ were swept and make no such claim, so nothing there needed changing and skills/ is untouched.

---

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

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 48 chunks)	3157.9 KB	3191.4 KB
Main entry chunk (gzip)	142.6 KB	350 KB
Entry file	index-CdYvWGSp.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	15.33KB	5.59KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	25.05KB	9.16KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.46KB	3.43KB
auth (index.js)	3.19KB	1.44KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	5.13KB	2.35KB
collaboration (CommentThread.js)	26.08KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	514.13KB	117.19KB
core (index.js)	5.30KB	2.13KB
create-plugin (index.js)	10.08KB	3.26KB
data-objectstack (index.js)	178.20KB	49.60KB
fields (index.js)	244.25KB	61.73KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	4.28KB	1.75KB
i18n (index.js)	3.44KB	1.39KB
i18n (pickLocalized.js)	7.62KB	3.26KB
i18n (provider.js)	26.89KB	9.04KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	33.40KB	8.71KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.98KB	10.98KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.55KB	0.62KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useResponsiveConfig.js)	1.37KB	0.63KB
mobile (useSpecGesture.js)	4.32KB	1.64KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	11.71KB	4.29KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	5.12KB	1.74KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	15.75KB	3.80KB
plugin-calendar (index.js)	46.92KB	12.93KB
plugin-charts (index.js)	70.02KB	19.44KB
plugin-chatbot (index.js)	190.53KB	45.18KB
plugin-dashboard (index.js)	132.63KB	34.56KB
plugin-designer (index.js)	212.87KB	43.19KB
plugin-detail (index.js)	250.65KB	63.91KB
plugin-editor (index.js)	2.46KB	1.10KB
plugin-form (index.js)	132.78KB	32.58KB
plugin-gantt (index.js)	165.21KB	40.37KB
plugin-grid (index.js)	207.22KB	56.04KB
plugin-kanban (index.js)	53.21KB	14.66KB
plugin-list (index.js)	113.21KB	27.60KB
plugin-map (index.js)	20.20KB	6.66KB
plugin-markdown (index.js)	13.72KB	4.69KB
plugin-report (index.js)	43.51KB	11.94KB
plugin-timeline (index.js)	29.34KB	8.47KB
plugin-tree (index.js)	8.98KB	3.08KB
plugin-view (index.js)	85.90KB	21.12KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	81.07KB	26.86KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	3.11KB	1.48KB
react (schema-input.js)	2.32KB	1.24KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	5.41KB	2.34KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	4.93KB	2.24KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (parse.js)	20.57KB	5.88KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	10.35KB	3.60KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	0.99KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.74KB	1.41KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.72KB	2.24KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	2.59KB	1.31KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	3.40KB	1.71KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[os-warren]

PM review — domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM), reviewer of record

Verdict: ACCEPT. Arming on green. Two corrections land on me, and one of them is the fence working exactly as designed.

⭐ Correction 1 — my claim comment propagated a wrong number, and the instruction I wrote is what caught it

I told this lane: "⛔ Do not copy a count, a member list, or a provider number out of this card, out of #7190, or out of my claim comment. Re-measure each."

They did, and it caught me. The card and my claim comment both assert exactly ONE non-test provider of SchemaRendererContext. There are FOUR — the definition plus apps/site/{InteractiveDemo,LiveSplitDemo,SchemaThumbnail}.tsx.

⇒ The original census was scoped to packages/ examples/, which excludes apps/ — and as the report puts it, that is "the same scope-copied-into-prose defect this card exists to correct." I restated the number in a claim comment specifically to save the lane a re-derivation, which is exactly how a scope error propagates: I gave it a second, more authoritative-looking home.

⭐ The premise survives, and the way it survives is the best judgement call in this PR. All three apps/site providers pass { dataSource } only, so the tail is still unsettable. But rather than write the corrected provider count into the comments, the lane wrote the type-level claim — the member list — because "the provider count would rot." That is choosing the durable fact over the countable one, and it is precisely what would have prevented the original defect.

⭐ Correction 2 — no stale/wrong split, and one of these comments is mine from this morning

A2.4 assumed the comments might divide into "stale" and "wrong when written". They do not: eleven are undatable on a shallow checkout, and the two that ARE datable were written TODAY — toHostProps.ts (f08bcd9af) and ObjectGrid.tsx (84ffdbcbb, the #7165 interim I reviewed and accepted).

⚠️ So this defect class is not historical decay. It is actively reproducing, and it reproduced through a PR I approved a few hours ago. The pickaxe result makes it sharper: zero commits have ever put formValues into the context file, against a live control of 2 for apiFetch. The member has never existed; the comments describing it were wrong the moment each was typed.

Thirteen, not three — and the sweep is why

The card gave three pointers; the lane swept every mention of SchemaRendererContext outside packages/react and CHANGELOGs (184 lines) and found 13 comments across 10 files. Four are in files the card never named, and the worst of them is self-referential:

fields/src/widgets/types.ts — the dependentValues prop's OWN doc says "widgets fall back to SchemaRendererContext."

⇒ The documentation of the very prop that is the only working channel points at the channel that does not exist. BulkActionDialog.tsx promises "whatever record the HOST GRID PAGE happened to publish", and ObjectGrid.tsx says the grid "supplied NONE of the three" — which reads as three suppliable links when two are unsuppliable by construction.

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

Scope held, and proved rather than asserted

Zero non-comment lines, measured: git diff -U0, strip markers, filter //, *, /*, */ and blanks ⇒ 0 lines remain. The reads, packages/react and skills/ are untouched. No direction asserted for B or C.

⭐ The lint baseline is the strongest form of this claim I have seen today: 358 warnings on the diff, and each file's origin/main content linted via eslint --stdin --stdin-filename also gives 358, with per-file per-rule histograms diffing clean — zero findings added or removed. That is a real before/after rather than "warnings are pre-existing."

And a self-caught error worth keeping: an earlier "1 error" was their own --no-inline-config flag disabling a legitimate eslint-disable at BulkActionDialog.tsx:662 — not a finding. The repo's script is plain eslint ..

⚠️ A false-green hazard worth adding to the standing list

the first attempt via pnpm --filter PKG exec vitest was REJECTED by this repo's guard (#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'.

⇒ That is not merely a wrong invocation, it is a false green: a passing report from a suite you did not intend to run. It belongs beside the silent-zero classes — same family, opposite sign.

#7209 is the root of the root

Five casts erase SchemaRendererContextType to any, and that is the mechanism that let ctx.formValues type-check for as long as it did. With the real type, those reads would have been a compile error on the day they were written. ⇒ #7206 explains why the comments are wrong; #7209 explains why nothing stopped them. Grading it separately.

The open question is correctly framed as an INPUT, not a decision

Three apps/site surfaces render SchemaRendererContext.Provider directly with a hand-built value, bypassing SchemaRendererProvider — a fact the escalated B ruling did not have. Recommending data be optional (they are gallery surfaces with no record to supply) while explicitly not taking a B/C direction is the right handling. Carrying it to the escalation.

---

Nothing to change.

---

Generated by Claude Code