Skip to content

fix(components): delete the shadowed SimpleTableRenderer and guard against same-namespace duplicate registration (#5125) - #5338

Merged
os-support-ai merged 3 commits into
mainfrom
claude/issue-5125-shadowed-simple-table-renderer
Aug 19, 2026
Merged

os-support-ai merged 3 commits into
mainfrom
claude/issue-5125-shadowed-simple-table-renderer

Conversation

@os-support-ai

Copy link
Copy Markdown
Collaborator

Fixes #5125

Implements the auto-adjudicated ruling: options 1 + 3 together — remove the shadowed SimpleTableRenderer, and add a same-namespace duplicate-registration guard. Option 2 (teaching complex/table.tsx to read bind) is not implemented; it widens the authorable key surface and is a Feature for the maintainer.

Verified at a0c2a72e2.

Both stop conditions were checked before deleting anything

(A) Fork clause — census of published teaching of bind-on-table. Result: zero, and the surface teaches the opposite.

grep -rInE -B8 -A4 "['\"]?bind['\"]?\s*[:=]" content/docs skills $(find packages -name README.md -not -path '*/node_modules/*')

12 bind occurrences, every one classified by the type of the node it sits on: object-grid x2, kanban x1, gantt x1, list x2, prose x3, data-table x3. table: zero.

Counter-probes, because a zero is not a reading:

  • bind on list — a genuinely reachable bind reader — is taught, at skills/objectui/guides/schema-expressions.md:407 and :441. The grep does reach the surface.
  • table itself is taught in 14 places across the census surfaces (grep -rInE -A12 "type.*:.*'table'"), and not one of those nodes carries bind. So the surface covers this component and consistently omits the key.
  • skills/objectui/guides/schema-expressions.md:462 states it outright: "table does not read bind." The published teaching already matches today's reachable truth, which is what the ruling says stays unchanged.

The three data-table cases are the known #5126 class (data-table is a different registry key and does not read bind either). Two of them sit in files #5126 does not name — recorded separately below, not touched here.

(B) Published-surface check — SimpleTableRenderer is NOT a named export of @object-ui/components. Measured on the built artifact, not a grep of src/:

  • dist/index.d.ts (the types entry) is 23 lines; no re-export path reaches ./renderers/data-display/table. Its export * list is ./ui, ./custom, ./notifications, ./debug, ./share.
  • grep -rn SimpleTableRenderer dist/ returns exactly one hit — dist/renderers/data-display/table.d.ts:2, the symbol's own per-file declaration. Zero hits in dist/index.js and dist/index.umd.cjs.
  • The exports map is closed (. and ./style.css only), so a deep import cannot reach it either: require.resolve('@object-ui/components/dist/renderers/data-display/table.js') from a real consumer fails with ERR_PACKAGE_PATH_NOT_EXPORTED.
  • src/index.ts:36 imports ./renderers for side effects only — there is no export * from the renderers tree.

Deleting it therefore removes no published capability, and the ruling's mechanical boundary holds.

The premise re-verified — and a second instance found

Re-verified on today's main: data-display/table.tsx:76 and complex/table.tsx:25 both register table under namespace ui, and renderers/index.ts imports ./data-display (L13) before ./complex (L17), so the complex one registers last and wins.

Rather than eyeballing it, the barrel was instrumented and every register() call counted: 160 calls, 158 distinct keys, 2 same-namespace duplicates.

key shadowed (loses) serves the key (wins)
ui:table data-display/table.tsx — SimpleTableRenderer, the only table renderer that read bind complex/table.tsx
ui:kbd basic/html-elements.tsx — kbd in the TAGS loop data-display/kbd.tsx

ui:kbd was not in the card. It is fixed here rather than deferred, for a reason that is load-bearing: the ruled guard must fail on any same-namespace duplicate, so leaving ui:kbd in place would have meant shipping the guard red on day one, or allow-listing the exact class the guard exists to catch. The correct shape was not a judgement call — basic/html-elements.tsx's own comment states the TAGS list "deliberately excludes anything already registered", and kbd violated that invariant. Removing it keeps the renderer that already served the key, so it is the same no-op-by-construction as the table deletion.

In both cases the winner is untouched, so the registry's contents are identical before and after this PR.

The guard catches the class, not the instance

packages/components/src/renderers/__tests__/registration-uniqueness.test.tsx counts every registration the production barrel makes and fails on any key registered twice under one namespace.

A test rather than filling in the runtime warning that Registry.register already carries as a commented-out hook: re-registering a key is a supported pattern here — 72 test files call ComponentRegistry.register, many to swap a production renderer for a stub, and Registry.unregister exists precisely so they can restore it. A runtime warning would fire mostly on legitimate overrides, alongside the two console.warn channels register() already emits (the meta-less deprecation and the bare-name fallback collision). A third channel that cries wolf trains readers to ignore all three. Scoping the check to what renderers/index.ts registers puts it where deliberate overrides do not happen, and makes it fail instead of scroll past.

Note the existing bare-name collision guard cannot cover this: its condition is existing.type !== fullType, which excludes same-namespace duplicates by construction.

Ablation — proving it catches the class. With both real duplicates fixed, a duplicate was introduced on a third key the guard was never written against (badge added to the TAGS loop, colliding with data-display/badge.tsx):

AssertionError: Same-namespace duplicate registration(s): ui:badge (registered 2x).

Removed again; suite back to green. No build artifact sits between that edit and the test — the root vitest config aliases @object-ui/core and @object-ui/components to their src/, and the ablation flipping green-to-red from a pure source edit with no rebuild is itself the proof (had dist mediated, the edit would have been invisible and the ablation would have passed vacuously).

The guard also carries a floor assertion (callsByKey.size > 100) so it cannot pass vacuously over an empty map if the barrel import ever stops registering.

Reverse-verification — one leg is degenerate, and that is the finding

Restored the deleted file and its barrel registration, predicted before running:

leg predicted observed
registration-uniqueness.test.tsx RED, naming ui:table (2x) only RED, naming ui:table (registered 2x) only
shadowed-renderer-behaviour.test.tsx all 6 green, unchanged all 6 green, unchanged

Predicted matched observed. The behaviour leg is degenerate by construction, and stating that plainly is more honest than filling in a template: restoring a shadowed renderer restores a loser. complex/table.tsx still registers later and still wins, so nothing observable moves. That degeneracy is precisely the evidence for the ruling's "changes no reachable behaviour" claim — the defect was never visible in rendered output, only in the registration ledger, which is why an accidental probe was needed to find it and why the guard is the half that can actually go red.

Tests

packages/components/src/renderers/__tests__/shadowed-renderer-behaviour.test.tsx pins today's reachable behaviour — these passed identically before and after the deletion:

  • table renders inline data against columns (2 rows).
  • table ignores bind: header renders, zero rows, and no "No results." row — the discriminator, since the shadowed renderer emitted one for empty data. This reproduces the probe that found the card.
  • table still serves caption and footer, which only complex/table.tsx supports — a positive identity check, so the file cannot be satisfied by no table renderer being registered.
  • list and tree-view, the other two useDataScope consumers, still register and still read bind.
  • kbd renders one element per entry in keys, proving the surviving renderer is the one that served the key before.

Side effect the ruling asked to record

This confirms for #5126 that no reachable table renderer reads bind — complex/table.tsx does not, complex/data-table.tsx does not (re-verified: zero hits for bind / useDataScope), and the only one that did was unreachable and is now gone. That doc card's direction is stable under this ruling. Nothing in #5126 is addressed by this PR.

Gates run locally (all at a0c2a72e2)

gate result
vitest run packages/components/ (repo root, CI's config) 168 files, 1516 tests passed
pnpm --filter @object-ui/components type-check pass (tsc --noEmit && tsc -p tsconfig.test.json)
pnpm --filter @object-ui/components lint 0 errors (890 pre-existing warnings, all in the src/ui/** no-touch zone)
pnpm check:doc-types pass — every documented component type is still registered
pnpm check:control-bytes pass (4724 files)
pnpm check:self-import pass

Vitest is run from the repo root deliberately: a package-scoped run is not refused, but it resolves a different config than CI uses, so its green would not be CI's green.

Changeset: @object-ui/components patch.

Out of scope, filed not fixed


Generated by Claude Code

claude added 3 commits August 19, 2026 16:08
…ace duplicate-registration gate

Baseline commit: the behaviour pins are green on main, the gate is RED and
names both offenders (ui:table, ui:kbd). The fix follows in the next commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE
…owed kbd tag entry

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE
@github-actions

Copy link
Copy Markdown
Contributor

✅ Console Performance Budget

Metric Value Budget
Main entry (gzip) 25.3 KB 350 KB
Entry file index-CpmQyts1.js —
Status PASS —

📦 Bundle Size Report

Package Size Gzipped
app-shell (index.js) 9.83KB 3.70KB
app-shell (runtime-config.js) 7.42KB 2.32KB
app-shell (types.js) 0.01KB 0.04KB
app-shell (urlParams.js) 8.92KB 3.41KB
auth (AuthContext.js) 0.31KB 0.24KB
auth (AuthGuard.js) 1.17KB 0.53KB
auth (AuthProvider.js) 29.33KB 7.05KB
auth (AuthShell.js) 3.49KB 1.40KB
auth (ForgotPasswordForm.js) 12.21KB 3.45KB
auth (LoginForm.js) 18.13KB 5.39KB
auth (PreviewBanner.js) 0.90KB 0.50KB
auth (RegisterForm.js) 6.64KB 2.21KB
auth (SocialSignInButtons.js) 9.60KB 3.89KB
auth (UserMenu.js) 3.40KB 1.22KB
auth (auth-gate-events.js) 1.29KB 0.66KB
auth (authStyles.js) 5.04KB 1.72KB
auth (createAuthClient.js) 40.21KB 10.79KB
auth (createAuthenticatedFetch.js) 6.34KB 2.43KB
auth (index.js) 2.71KB 1.22KB
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.02KB 0.88KB
auth (useIsWorkspaceAdmin.js) 1.61KB 0.85KB
collaboration (CommentThread.js) 26.07KB 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.65KB 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) 505.53KB 113.13KB
core (index.js) 4.11KB 1.62KB
create-plugin (index.js) 10.08KB 3.26KB
data-objectstack (index.js) 159.80KB 44.34KB
fields (index.js) 237.07KB 59.46KB
i18n (LocalizationContext.js) 1.76KB 0.96KB
i18n (currency.js) 1.22KB 0.64KB
i18n (i18n.js) 4.28KB 1.75KB
i18n (index.js) 3.42KB 1.39KB
i18n (pickLocalized.js) 3.69KB 1.73KB
i18n (provider.js) 23.13KB 7.63KB
i18n (useDisplayLocale.js) 2.85KB 1.45KB
i18n (useObjectLabel.js) 29.43KB 7.15KB
i18n (useSafeTranslation.js) 7.77KB 3.13KB
layout (index.js) 39.16KB 10.97KB
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.74KB
mobile (index.js) 1.50KB 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.71KB 0.42KB
mobile (useResponsiveConfig.js) 1.36KB 0.63KB
mobile (useSpecGesture.js) 4.32KB 1.64KB
mobile (useTouchTarget.js) 1.01KB 0.54KB
permissions (MePermissionsProvider.js) 9.35KB 3.31KB
permissions (PermissionContext.js) 0.31KB 0.25KB
permissions (PermissionGuard.js) 0.89KB 0.45KB
permissions (PermissionProvider.js) 4.42KB 1.42KB
permissions (evaluator.js) 5.12KB 1.74KB
permissions (index.js) 0.91KB 0.41KB
permissions (store.js) 0.91KB 0.42KB
permissions (useFieldPermissions.js) 1.28KB 0.52KB
permissions (usePermissions.js) 1.81KB 0.83KB
plugin-ai (index.js) 15.75KB 3.80KB
plugin-calendar (index.js) 46.62KB 12.83KB
plugin-charts (index.js) 64.75KB 18.37KB
plugin-chatbot (index.js) 181.21KB 43.14KB
plugin-dashboard (index.js) 127.92KB 32.80KB
plugin-designer (index.js) 212.39KB 42.83KB
plugin-detail (index.js) 241.46KB 60.56KB
plugin-editor (index.js) 2.46KB 1.10KB
plugin-form (index.js) 124.19KB 30.20KB
plugin-gantt (index.js) 164.10KB 39.87KB
plugin-grid (index.js) 198.27KB 53.29KB
plugin-kanban (index.js) 52.93KB 14.60KB
plugin-list (index.js) 111.66KB 27.13KB
plugin-map (index.js) 20.08KB 6.62KB
plugin-markdown (index.js) 13.72KB 4.69KB
plugin-report (index.js) 43.49KB 11.93KB
plugin-timeline (index.js) 26.68KB 7.66KB
plugin-tree (index.js) 8.50KB 2.88KB
plugin-view (index.js) 84.55KB 20.67KB
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.44KB 0.22KB
providers (types.js) 0.01KB 0.04KB
react-runtime (index.js) 5.62KB 2.34KB
react (LazyPluginLoader.js) 3.77KB 1.33KB
react (SchemaRenderer.js) 36.10KB 12.26KB
react (data-invalidation.js) 5.05KB 2.08KB
react (index.js) 1.33KB 0.69KB
react (schema-input.js) 1.45KB 0.83KB
react (spec-input.js) 0.20KB 0.18KB
sdui-parser (codegen.js) 5.41KB 2.34KB
sdui-parser (index.js) 4.77KB 2.16KB
sdui-parser (input-type.js) 2.84KB 1.40KB
sdui-parser (parse.js) 10.76KB 3.17KB
sdui-parser (provenance.js) 3.66KB 1.82KB
sdui-parser (types.js) 0.29KB 0.24KB
sdui-parser (validate.js) 6.92KB 2.40KB
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) 0.20KB 0.18KB
types (crud.js) 0.20KB 0.18KB
types (dashboard-filter-alias.js) 6.23KB 2.74KB
types (data-display.js) 0.20KB 0.18KB
types (data-protocol.js) 0.20KB 0.19KB
types (data.js) 0.20KB 0.18KB
types (designer.js) 1.87KB 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-retry.js) 4.32KB 2.02KB
types (index.js) 3.08KB 1.53KB
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 (system-fields.js) 3.33KB 1.54KB
types (theme.js) 0.20KB 0.18KB
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-support-ai
os-support-ai marked this pull request as ready for review August 19, 2026 16:42

Copy link
Copy Markdown
Collaborator Author

ACCEPT — PM review, round 17.

  • Path surface: 6 files — data-display/table.tsx (deleted) and its barrel import, basic/html-elements.tsx, two new test files, one changeset. Zero governed-surface hits.
  • Gates: every gate job completed: success — Lint, Type Check, Test shards 1–4, Build & E2E, Build Docs, Doc Snippet / Doc Component Type Check, Changeset Declaration / Bump Policy / Fixed Group, Bundle Analysis, Control Byte Scan, Internal Docs Link Check, Skill Guide Path Check. No cancelled, no in_progress.

Both stop conditions were genuinely tested, not waved through

(B) the published-surface check — the one I added because the ruling assumed it rather than stating it — was answered the only way that counts: the built dist/index.d.ts was read in full (23 lines) and has no re-export path to ./renderers/data-display/table; dist/ yields exactly one hit, the symbol's own per-file .d.ts; zero in dist/index.js and dist/index.umd.cjs; and the exports map is closed, so a deep import from a real consumer fails ERR_PACKAGE_PATH_NOT_EXPORTED. Not a grep of src/. So this is dead-code removal, not removal of a published capability, and it stays inside an auto-adjudicated card's boundary.

(A) the census found 12 bind keys and zero on a table node, counter-probed three ways: bind-on-list is taught (schema-expressions.md:407,441), table is taught in 14 places (none with bind), and schema-expressions.md:462 states outright that "table does not read bind". The fork clause did not fire, and now we know why rather than assuming it.

The guard found a second instance immediately — which is the point of writing it for the class

The premise was re-verified by instrumenting the barrel: 160 register calls, 158 distinct keys, 2 same-namespace duplicates — ui:table (the card's) and ui:kbd, which the card did not know about. basic/html-elements.tsx listed kbd in its TAGS loop while data-display/kbd.tsx owns ui:kbd, so that entry never ran.

That file was outside the surface I granted, and taking it was right: a guard that must fail on any duplicate would otherwise have shipped red on day one, or been born with an allow-list for the exact class it exists to catch. The file's own comment already claimed the list "deliberately excludes anything already registered" — the change makes that claim true and the guard now enforces it. Surface extension flagged in the report rather than slipped in.

The ablation was run on a third key (badge, which the guard was never written against) → Same-namespace duplicate registration(s): ui:badge (registered 2x), then removed and re-run green. That is a class-level proof, not an instance-level one. The guard also carries a floor assertion (size > 100) against its own vacuous-pass mode.

The degenerate leg, reported rather than dressed up

Reverse-verification predicted the guard red naming ui:table only and the 6 behaviour pins green and unchanged; observed exactly Tests 1 failed | 7 passed. And the behaviour leg is degenerate by construction — restoring a shadowed renderer restores a loser; complex/table.tsx still registers later and still wins, so nothing observable moves. The report says so plainly instead of filling in the template, and then makes the sharper point: that degeneracy is itself the evidence for "changes no reachable behaviour" — the defect only ever existed in the registration ledger, never in rendered output, which is why an accidental probe found it and why the guard is the only leg that can go red.

No build artifact on any leg, and proven rather than asserted: the root vitest config aliases @object-ui/core and @object-ui/components to their src/, and the ablation flipping green→red from a pure source edit with no rebuild is the proof — had dist mediated, the edit would have been invisible and the ablation would have passed vacuously.

Side effect recorded as the ruling asked: this confirms for #5126 that no reachable table renderer reads bind. Also filed: #5337, the same data-table + bind teaching distortion in two files #5126 does not name, filed as a sub-issue so all three get one ruling instead of three edits.

Merging via the queue.


Generated by Claude Code

@os-support-ai
os-support-ai added this pull request to the merge queue Aug 19, 2026
Merged via the queue into main with commit 2d0bd16 Aug 19, 2026
22 checks passed
@os-support-ai
os-support-ai deleted the claude/issue-5125-shadowed-simple-table-renderer branch August 19, 2026 16:43
os-support-ai pushed a commit that referenced this pull request Aug 20, 2026
…hree sites (#5126, #5337)

Three published skill guides taught `{ "type": "data-table", "bind": "customers" }`
and stated that "the table component calls `useDataScope("customers")` and gets
the array". `DataTableRenderer` takes its rows from `data: rawData = EMPTY_ROWS`
off the node and contains neither `bind` nor `useDataScope`, so copying the
example produced no error and no warning — a header over the "No results found"
empty state.

Direction inherited from #5125 (merged PR #5338): the only bind-reading table
renderer was DELETED under enforce-or-remove rather than promoted, so
`data-table` does not gain `bind`; the teaching is what changes.

- schema-expressions.md, protocol.md, data-integration.md: the `bind` example is
  now `list`, which does call `useDataScope`, bound to a string array so it
  renders visible entries rather than the empty `li` a record array produces.
- Each site names the real readers (`list` / `tree-view` plus the `object-*`
  plugin widgets) and states that `data-table` is not one of them.
- The `useDataScope` mechanism sentence, which described a different component,
  is gone.
- schema-expressions.md and data-integration.md keep a `data-table` example, now
  in its real inline-`data` form. Their `columns` entries are byte-identical to
  main: the `{ name, label }` spelling is the separate open question on #5120,
  parked with the maintainer, and this change decides nothing about it.

A pin test lifts the blocks out of the real guide files and renders them through
the real SchemaRenderer: the taught forms put rows/entries on screen, and the
retired `bind` form is measured producing the empty state.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE
akarma-synetal pushed a commit to akarma-synetal/objectui that referenced this pull request Aug 23, 2026
…hree sites (objectstack-ai#5371)

* docs(skills): teach the binding `data-table` actually reads, in all three sites (objectstack-ai#5126, objectstack-ai#5337)

Three published skill guides taught `{ "type": "data-table", "bind": "customers" }`
and stated that "the table component calls `useDataScope("customers")` and gets
the array". `DataTableRenderer` takes its rows from `data: rawData = EMPTY_ROWS`
off the node and contains neither `bind` nor `useDataScope`, so copying the
example produced no error and no warning — a header over the "No results found"
empty state.

Direction inherited from objectstack-ai#5125 (merged PR objectstack-ai#5338): the only bind-reading table
renderer was DELETED under enforce-or-remove rather than promoted, so
`data-table` does not gain `bind`; the teaching is what changes.

- schema-expressions.md, protocol.md, data-integration.md: the `bind` example is
  now `list`, which does call `useDataScope`, bound to a string array so it
  renders visible entries rather than the empty `li` a record array produces.
- Each site names the real readers (`list` / `tree-view` plus the `object-*`
  plugin widgets) and states that `data-table` is not one of them.
- The `useDataScope` mechanism sentence, which described a different component,
  is gone.
- schema-expressions.md and data-integration.md keep a `data-table` example, now
  in its real inline-`data` form. Their `columns` entries are byte-identical to
  main: the `{ name, label }` spelling is the separate open question on objectstack-ai#5120,
  parked with the maintainer, and this change decides nothing about it.

A pin test lifts the blocks out of the real guide files and renders them through
the real SchemaRenderer: the taught forms put rows/entries on screen, and the
retired `bind` form is measured producing the empty state.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE

* test(components): the guide pin imports `../renderers`, not the package by name

`import '@object-ui/components'` from inside that package is a self-import:
`tsc -p tsconfig.test.json` refused it (TS2882) and
`scripts/check-package-self-import.mjs` guards the same rule. The relative entry
registers the same renderers. Also drops the two `any`s the package's lint
warns on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE

* fix(skills): the pivot widget's registry key is `object-pivot`, and the reader list is pinned

The reader list added in the previous commit named `object-pivot-table` — that
is the component file (`ObjectPivotTable.tsx`), not the key it registers. An
author copying it would have written a type nothing is registered under.

Adds the guard that would have caught it: every `object-*` name the guides list
must be registered by exactly one plugin package, and that package must read
`schema.bind` through `useDataScope`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE

* docs(skills): qualify the one remaining unqualified `bind` sentence in data-integration.md

`data-integration.md:143` said "Components with `bind: "customers"` will then
access `staticData.customers`" with no qualifier — the same over-broad claim
this card corrects 40 lines below, in miniature. Names the qualification and
points at the section that carries it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

2 participants