Repository navigation
fix(plugin-dashboard,types): object-metric refuses drillDown.filter and drillDown.mode on its prop type - #10681
Merged
objectstack-fleet[bot] merged 2 commits intoSep 25, 2026
Conversation
…nd drillDown.mode on its prop type Ruling B on objectui#9002, a per-block refusal: `ObjectMetricDrillDownConfig` in `@object-ui/types` is `DrillDownConfig` with `filter?: never` and `mode?: never` tombstones naming the blocks that do read each key, and `ObjectMetricWidget`'s `drillDown` prop takes it. The shared type is unchanged. The `object-metric` registration's `drillDown` description says the same in one sentence. Refused at the TypeScript door only: no runtime validator here reads the members of an `object-metric` `drillDown`. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC
Contributor
|
changeset-claim-re-read
|
Contributor
✅ Console Performance Budget
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
Size Limits
|
The widget now imports it from `@object-ui/types` like every other type in the file, so the emitted `ObjectMetricWidget.d.ts` names the root entry rather than the `./data-display` subpath (which a node10-resolution consumer cannot resolve: the package has no `typesVersions`). The changeset says the type is published on both entries. PM patch round on objectui#9002. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC
Contributor
✅ Console Performance Budget
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
Size Limits
|
objectstack-fleet
Bot
deleted the
claude/issue-9002-metric-drilldown-refusal
branch
September 25, 2026 17:45
This was referenced Sep 25, 2026
akarma-synetal
pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Sep 28, 2026
…se the DrillDownConfig members they never read (objectui#10685) (objectstack-ai#10710) Fixes objectstack-ai#10685 Clause-②: no — a per-block narrowing, as the ruling recorded for objectui#9002 ## What this does This applies objectui#9002's ruling B (comment `5643445104`, a per-block refusal) to the sibling blocks of `object-metric`, as triage `5837818071` directed. Each block refuses, by name, the `DrillDownConfig` members it can never honour; the shared `DrillDownConfig` keeps every member for the blocks that read them. The seat's round-2 ruling (option A) widened the claim's file surface by `packages/types/src/objectql.ts` and `packages/types/src/zod/objectql.zod.ts`, so the `object-data-table` half shuts BOTH doors here, and merging this PR completes the card. - **`@object-ui/types`** adds two per-block shapes beside `ObjectMetricDrillDownConfig` in `data-display.ts`, exported on the root entry and on the `@object-ui/types/data-display` subpath: - `ObjectPivotDrillDownConfig`: `DrillDownConfig` plus a `mode?: never` tombstone (the objectstack-ai#10681 idiom: a `REFUSED BY NAME` docblock and `@deprecated`, naming `object-data-table` as the block that reads `mode`). - `ObjectDataTableDrillDownConfig`: `DrillDownConfig` plus `filter?: never`, `maxRows?: never` and `report?: never` tombstones, and `target?: 'drawer' | 'dialog'`. Each tombstone names the blocks that do read the key. - **TypeScript door.** `ObjectDataTableSchema.drillDown` in `objectql.ts` is typed with `ObjectDataTableDrillDownConfig`. The data table's component prop is anchored `Equal` to that schema by the two objectui#6576 pins, so the widget's prop refuses exactly what the schema refuses. - **Zod door.** The `object-data-table` mirror's `drillDown` in `objectql.zod.ts` is the shared `DrillDownConfigSchema` extended so that `filter`, `maxRows` and `report` are `retirementTombstone` arms whose messages name the key and the blocks that read it, and `target` is `z.enum(['drawer', 'dialog'])` with an error naming the refused `'navigate'`. `enabled`, `mode`, `title` and `columns` parse exactly as before. Nothing else in `objectql.zod.ts` changes. This is the door `objectui validate` and `objectui check` run (`safeValidateSchema`), so a stored JSON table config carrying one of the four is now refused there. - **`@object-ui/plugin-dashboard`**: `ObjectPivotTableProps.schema` gains `drillDown?: ObjectPivotDrillDownConfig`, and the component reads its drill config through that type instead of through `any`. - **Docblocks**: the shared `DrillDownConfig.mode` docblock names only `object-data-table` (none of charts, pivot tables or metric cards reads it) and says what each value does there; the `DrillDownConfig` class docblock no longer says "`target` is honoured by all of them", and the declared-keys pin's comment no longer names the table among the `navigateOnly` deliverers. - **`object-chart`: no type change** (see H4). Its refused set is pinned. - **Pins**: `drill-down-per-block-10685.test.ts` in `@object-ui/types` (one `describe` per block, `@ts-expect-error` per refused member with the read members as controls, plus a RUNTIME `describe` over the zod door), and `ObjectPivotTable.drillDownRefusal-10685.test.tsx` in `@object-ui/plugin-dashboard` (the published component's prop). The two 6576 anchor pins are re-pointed at the table shape, and the 7352 mirror pin's table leg runs over the values the table now accepts, with a non-vacuity check that the host-synthesised table configs stay in it. - **Changesets**: `10685-drilldown-per-block.md` (`@object-ui/types` `minor` with a breaking banner, `@object-ui/plugin-dashboard` `patch`) opens with the banner "Breaking for authored metadata, graded `minor` by this repo's convention": `objectui validate` / `safeValidateSchema` now refuse a stored `object-data-table` config carrying `drillDown.filter`, `.maxRows`, `.report` or `target: 'navigate'` that parsed green before, none was ever read, and the migration is to delete the key or write `'drawer'` / `'dialog'`. `minor` because the change narrows the published validator's accept set and the published `ObjectDataTableSchema` type, the grade every pending zod-door refusal in this repo carries (6881, 6951, 6972, 7322, 7963, 8801, 7352); objectui#9002's `patch` was graded on a TypeScript-door-only refusal, which does not describe this change. `@object-ui/plugin-dashboard` stays `patch`: a React-prop narrowing with no runtime door, the 9002 shape. The changeset also says `object-pivot`'s refusal is at the TypeScript door only (no zod mirror exists for it). H6: `.changeset/7352-drill-down-config-mirror.md` and `.changeset/6576-widget-schema-anchors.md` each have the falsified sentence scoped "at this change" plus a `⚠️ Dated note, 2026-09-25 … objectui#10685`; frontmatter md5 before and after: 7352 `ecedb10c5189b2c8841ea736b67c3cc6` both, 6576 `b25dbc26fe50c14d0b6f0cc8fe6cb9e1` both. ## H1: the table, re-measured per block Read sites were re-read on `origin/main` `5c61e524` this round. The one-member-at-a-time runtime probe (rendered DOM, data source calls and `openRecordList` calls compared against a control, with and without a `DrillNavigationProvider`) was run in round 1 at `bc97f9247` and is recorded in report comment `5839013332`; it was not re-run, and no read site moved since. | block | reads | never reads | |:--|:--|:--| | `object-chart` | `enabled` (`isDrillEnabled`), `filter` (`computeDrillFilter`), `title` (`resolveDrillTitle`), `target` including `'navigate'` (`openRecordList`), `maxRows` (drawer `pageSize`), `columns` | `mode`, `report`: already refused by the spec's `ChartDrillDown` type and by the zod mirror (`unrecognized_keys`) | | `object-pivot` | `enabled`, `filter`, `title`, and `target`, `columns`, `maxRows`, `report` through `DrillDownDrawer` | `mode` | | `object-data-table` | `enabled` (`isDrillEnabled`), `mode` (`'record'` opens the row; `'filter'` turns the drill off), a non-template `title`, `columns` (the record drawer's field list), `target` in two arms (`'dialog'`, anything else drawn as a drawer) | `filter`, `maxRows`, `report`; `target: 'navigate'` was drawn as a drawer | `@object-ui/core`'s `drill-down.ts` helpers read `enabled`, `filter` and `title` only; `DrillNavigationContext` carries one handler, `openRecordList(objectName, filter)`; the `data-table` renderer the table spreads its node into never names `drillDown`; `RecordDetailDrawer` takes `fields`, `title` and a two-armed `target`. The card's runtime-door bullet also names `ChartSchema.drillDown`. That is the plain `chart` node, whose renderer `ChartRenderer.tsx` reads no `drillDown`; it is outside this card's three blocks and deliberately untouched, the plain-`chart` remainder. ## H2: can never honour, or not yet honoured (one line each) - `object-pivot` · `mode`: never. Every pivot click point is an aggregated bucket (a cell, a row or column header, a total), so the pivot always drills through; `mode` chooses drill-to-record for a clicked ROW, and a pivot has none. This is the metric's reasoning in `5643445104`. - `object-chart` · `mode`, `report`: never, by the contract. Its drill type is `@objectstack/spec`'s `ChartDrillDown`, which declares neither; the spec's schema refuses both by name ("A chart segment is always an aggregate"). Already refused before this card; only pinned here. - `object-data-table` · `filter`, `maxRows`, `report`: never. All three configure a drilled LIST (its scope, its row cap, the report that replaces it). The table drills to the RECORD its row already is, `RecordDetailDrawer` lists nothing, and the block's `mode: 'filter'` arm is pinned as "ignored", so there is no list drill for them to act on. A row that drills through to a list of another object would need a drill-target member `DrillDownConfig` does not have: a new capability, not an unread member. - `object-data-table` · `target: 'navigate'`: refused, not honoured (H3). ## H3: `navigate` on the data table `object-chart` honours `navigate` by calling `openRecordList(objectName, merged filter)`, the object's LIST page scoped by the drill filter. `DrillNavigationContext` has no record-level handler and `@object-ui/app-shell`'s `useOpenRecordList` builds only the list route. The table's click point is one record, so the list page is the wrong destination, and a "navigate to this record" arm needs a new host seam, not a small hunk. So the table's shape refuses `navigate` on both doors and an author gets a type error, or a `validate` refusal, instead of a drawer. ## H4: where the shape differs from PR objectui#10681 - **`object-chart` keeps its spec-bound type.** `ObjectChartSchema.drillDown` is already per-block (the spec's `ChartDrillDown`), pinned `Equal` to that symbol by `object-chart-undeclared-keys-8885.test.ts`. A tombstoned local type would unbind it from the spec. A fresh `mode` or `report` literal is already a compile error and the zod mirror already refuses both by name. - **Registration sentences: none added.** The `object-pivot` and `object-data-table` registrations advertise no `drillDown` input (adding one widens the designer palette, a shape decision). `object-chart`'s description is pinned by `packages/plugin-charts/src/index.test.ts` to list exactly the six spec keys and NOT `mode` or `report`. - **Zod door narrowed for the table only**, because a runtime validator (`safeValidateSchema`, run by `objectui validate`) reads that block's drill members and accepted all four; the round-1 probe showed the same door refuses a bad value on `enabled`, so it does reach `drillDown`. `object-pivot` has no zod mirror, so its refusal is TypeScript-only and the changeset says so. ## Verification (measured at `430223947f` = `a1217b515` merged with `origin/main` `5c61e524`; head `64d43b6d67` = that head + a second merge of `origin/main` `41ae65b26` + the changeset commit) - **Round 3 delta and its gates (head `64d43b6d67`).** Against `430223947f` the 14 files of this card differ in two places only: the changeset (the `minor` grade and its banner) and one line of `index.ts` that `main`'s own objectstack-ai#10730 deleted (a retired `ColumnWidthConfig` export); the other 12 are byte-identical, and the branch's diff against `main` is still exactly these 14 files. Re-run at this head, each exit 0: `check-changeset-presence` (11 source files of 2 released packages, 1 changeset); `changeset:check`; `check-changeset-no-major` (the `Changeset Bump Policy` step); `check:changeset-claims` (36 pending changesets, unchanged reading); `check:pending-changeset-literals`; `check:new-line-citations` (`0 new citation(s)`); `check:control-bytes` OK; `check-changeset-overwrite` (report-only: it reports the 6576 and 7352 edits, the intended shape). No suite, type-check or ablation was re-run: the delta is a changeset plus `main`'s already-green commits merged with a clean `merge-tree`, and none of the measured sources moved. - Closure build `pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-dashboard^...' run build`, under the verify lock: `VERDICT command-exit 0`. `dist/data-display.d.ts` and `dist/objectql.d.ts` carry `ObjectDataTableDrillDownConfig` (2 hits each), `dist/index.d.ts` carries `ObjectPivotDrillDownConfig`. - `pnpm --filter @object-ui/types run type-check` then `pnpm --filter @object-ui/plugin-dashboard run type-check`: `VERDICT command-exit 0`. `tsc --listFilesOnly` on each `tsconfig.test.json` lists the four types pins and the two plugin-dashboard pins, and plugin-dashboard's program reads `@object-ui/types` through `dist/data-display.d.ts` and `dist/objectql.d.ts`. - `pnpm exec vitest run --maxWorkers=2 packages/types/ packages/plugin-dashboard/` from the repo root: `Test Files 378 passed (378)`, `Tests 6562 passed (6562)`, `VERDICT command-exit 0`. - Gates, each exit 0: `check-changeset-presence` (11 source files of 2 released packages, 1 changeset); `check:new-line-citations` (`0 new citation(s)`); `check:control-bytes` OK; `changeset:check` (no `major`); `check:pending-changeset-literals`; `check:changeset-claims` (36 pending changesets name a touched file; the two whose prose is about drill-down, 7363 and 8885, were read and stay true, and the rest describe other regions of these files); `check:spec-symbols`; `check:self-import`; `check:esm-specifiers`; `check:test-path-roots`; `check:vi-mock-specifiers`; `check:handler-key-reads`; `check:unreferenced-sources`; `check:metadata-write-doors`; `type-check:coverage`; `check:component-surface-parity`; `check:doc-types`; `check-governed-queue-guard --test` over the 14 paths: NOT GOVERNED. - NOT MEASURED: `check:readme-exports` exits 1 on a prerequisite (385 README self-imports unjudgeable because other packages' `dist/index.d.ts` are not built); this diff edits no README. Left to CI. - ESLint was run on the 11 touched source and test files, not the whole repo. The narrowing is a measurement, for three reasons: the config is the root `eslint.config.js` and neither package has its own; `--format json` reports 11 files, 0 errors and 80 warnings (all `no-explicit-any`, none on a line this branch added, by intersecting message lines with the branch's added-line set); `--print-config` shows empty `parserOptions`, so there is no type-aware linting and the diff cannot move any untouched file's verdict. Under `--no-inline-config` the same run shows 1 error, the block-disabled `SpecFormField` alias in `index.ts` that is on `main` and outside this diff; the package `lint` scripts are `eslint .`, which honours the disable. Full `pnpm lint` is left to CI. - CI on this head: `Inert vi.mock Specifier Check` is red on `main` since `f9c06ef6a` (PR objectui#10729), filed as objectui#10732. Confirmed locally in a no-install probe worktree at `5c61e524`: exactly one hit, `apps/console/src/__tests__/filterContextTokensSweep-10666.test.tsx`, outside this surface; in an installed worktree the specifier is found through `node_modules` and the checker passes. Not touched here. ## Red on base, then green on head The five touched sources (`data-display.ts`, `index.ts`, `objectql.ts`, `zod/objectql.zod.ts`, `ObjectPivotTable.tsx`) were swapped to their `origin/main` `5c61e524` blobs with the HEAD pins in place, then restored to HEAD (every blob equal to `HEAD`, `git diff HEAD` empty, types dist rebuilt, markers back to 2 and 1). - Types test program (`tsc -p tsconfig.test.json`): exit 2. `TS2305`/`TS2724` on the two new type names imported by the per-block pin and the 6576 pin, and nine `TS2578 Unused '@ts-expect-error'` on the per-block pin's refusals (the pivot's two, the table's seven). - Vitest on the per-block pin and the 7352 mirror pin: `Tests 4 failed | 59 passed (63)`, the four failures being the zod describe's `filter`, `maxRows`, `report` and `target` rows. - Types dist built from base sources (markers 0 and 0), then the plugin-dashboard test program: exit 2, `TS2305` on the 6576 anchor's `ObjectDataTableDrillDownConfig` import and two `TS2578` on the pivot pin. ## Ablations (each through `ablation-replace.mjs`: anchor hit once, blob changed, command run, restored to the HEAD blob with an empty `git diff HEAD`) - **TS wiring.** `ObjectDataTableSchema.drillDown` back to the shared `DrillDownConfig`, with a JSDoc marker `ABLATED_10685_TS1` on the line. Types program exit 2: `TS2344` on `_SchemaTakesTheTableShape`, `TS2578` on `nodeWithFilter` and `nodeWithNavigate`, `TS2344` on the 6576 pin's `assertionDrillDownDeclared`, plus `zod-mirror-parity.test.ts` going red with `objectql.zod.ts#ObjectDataTableSchema` (the repo's TS/zod parity pin sees the two doors disagree: a second, independent instrument). Dist leg: types rebuilt, marker count in `dist/objectql.d.ts` 1, plugin-dashboard program exit 2 (`TS2344` on `ObjectDataTable.schemaAnchor-6576`'s `Equal`); after the restore rebuild the marker count is 0 and `ObjectDataTableDrillDownConfig` is back to 2. A first pass of this leg read the dist marker with the wrong grep (tsc emits the `import()` type with single quotes) and got 0; the downstream red was the same in both passes, and the marker form above is the evidence. - **Each table tombstone alone** (`never` to `DrillDownConfig['KEY']`): `filter` gives `TS2578` on `withFilter` and `nodeWithFilter`; `maxRows` on `withMaxRows`; `report` on `withReport`; `target` widened back to the shared union gives `TS2578` on `withNavigate` and `nodeWithNavigate`. Each also turns `zod-mirror-parity` red as above. - **Pivot tombstone** neutralised (marker `ABLATED_10685_PIVOT`): types program `TS2578` on `withMode` and `handedAcross`; dist marker 1; plugin-dashboard program exit 2 with two `TS2578` on the pivot pin; marker 0 after the restore rebuild. - **Chart binding** (`ObjectChartSchema.drillDown` to the shared type): `TS2578` on the chart pin's `withMode` and `withReport`, plus the 8885 pin's `TS2344` and `TS2578`. - **Zod door** back to the shared mirror: `Tests 4 failed | 59 passed (63)`, the four refusal rows. **Each zod member alone** (the tombstone renamed away, or `target` widened to include `navigate`): exactly one failure each, its own row, `62 passed`. Direction: red as predicted in every leg, with one increase (the parity pin) beyond the prediction. ## Serial `origin/main` `5c61e524` and PR objectui#8941's head `bb7d5e718` (`claude/pr-7058-lucide-react-1.41.0`) were fetched into private refs; `git merge-tree --write-tree` exits 0 against both. PR objectui#10707 and PR objectui#10643 have merged; objectui#10657 has no open PR and no branch (its test is on `main`). `main` had moved in three of this PR's files (the `filter` docblocks in `objectql.ts`, the `masked` column in `data-display.ts`, the `filter` describes in `objectql.zod.ts`), so `main` was merged in (`430223947f`, a merge commit, no conflicts). In round 3 `main` had moved again in one file (`index.ts`, objectstack-ai#10730's retired export), so `origin/main` `41ae65b26` was merged in the same way (`4f2f7a530f`, no conflicts). At head `64d43b6d67`, `merge-tree --write-tree` exits 0 against `origin/main` `41ae65b26` and against the three open PRs that touch these files: PR objectui#10734 (`856ecc953`, `ObjectChartSchema` regions of `objectql.ts` / `objectql.zod.ts`, disjoint), PR objectui#10714 (`218f642484`, `data-display.ts`) and PR objectui#8941 (`bb7d5e718`, `objectql.ts`). The branch diff against `main` is exactly the 14 files of this card. ## Acceptance notes - **`mode: 'filter'` on `object-data-table`** turns the row drill off, as `ObjectDataTable.drill.test.tsx` pins, instead of drilling through. The rewritten docblock says so. Value-level, outside the card's member set; recorded here only. - **`maxRows`** reaches each drill list as the drill table's `pageSize` (`DrillDownDrawer` and the chart's drawer), a page size rather than the "Hard cap on rows fetched" the shared docblock promises. Observation, outside this card. - **`object-chart`, non-fresh values.** A value typed as the shared `DrillDownConfig` is still assignable to `ObjectChartSchema.drillDown`, because the spec type omits `mode` and `report` rather than tombstoning them. No producer in the tree hands a typed shared config across. - **Spec guidance text.** `@objectstack/spec`'s `ChartDrillDownSchema` refusal text for `mode` calls it "a TABLE / PIVOT / METRIC drill key"; on `object-pivot` and `object-metric` it is now refused. Reported to the seat in round 1 for the spec repository; not touched here. - **PR assignee.** Set to `os-elon-musk` in round 1 (read back matching); found empty at the start of this round and set again to match the card's assignee, per the dispatch rule. Session: `https://claude.ai/code/session_014mXUNuFomfj24w7s1pZzhN` --- _Generated by [Claude Code](https://claude.ai/code/session_014mXUNuFomfj24w7s1pZzhN)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9002
Clause-②: no
What this does
This implements ruling B on objectui#9002 (comment
5643445104), a per-block refusal.drillDown.filteranddrillDown.modeare refused on theobject-metricblock's prop type. The sharedDrillDownConfigkeeps both keys for the blocks that read them.@object-ui/types: addsObjectMetricDrillDownConfigbesideDrillDownConfigindata-display.ts. It isDrillDownConfigplusfilter?: neverandmode?: nevertombstones. They use the repo's existing idiom (?: never, aREFUSED BY NAMEdocblock,@deprecated, as onPivotTableSchema.body), and each docblock names the blocks that do read the key:filter:object-chartandobject-pivot, throughcomputeDrillFilter;mode:object-data-table, on its row click.@object-ui/plugin-dashboard:ObjectMetricWidgetProps.drillDownnow uses the new type. The prop docblock and the drawer-section comment ("deliberately NOT forwarded") now cite the ruling. They no longer defer to "the judgement objectui#8970 asks for".object-metricregistration'sdrillDowninput description gains one sentence. It says the two keys do not apply to a metric, and names where they do apply.patch.objectMetricDrillDownMembers-8071.test.tsxgets an amendment note. Its advice against a narrower metric drill schema is now ruled for these two members. Its recorded measurements are unchanged.Premise re-measured on
origin/maind08ab2fc8object-metricstill reads neither key. These are all the reads of the metric'sdrillDown:isDrillEnabledreadsenabled;resolveDrillTitlereadstitle;DrillDownDrawerreceivestarget,columns,maxRowsandreport.DrillDownDrawertakes afilterprop that is already computed (the metric's own resolved filter). Its inner table gets a hard-coded{ enabled: true, mode: 'record', target: 'dialog' }and never the authored config.Across the repo,
drillDown.filteris read only throughcomputeDrillFilter(called byObjectChartandObjectPivotTable).drillDown.modeis read only byObjectDataTable.Which door sees an authored
object-metricdrillDown: measured, in orderObjectMetricWidgetis exported from the package entry, typed asReact.FCofObjectMetricWidgetProps. The props interface is not exported by name, butReact.ComponentPropsand JSX reach it.inputsand manifestdrillDownistype: 'object'with noof. Codegen emits a Record of string to unknown, andvalidateTreechecks only the coarse kind.objectui validate/objectui checksafeValidateSchema(AnyComponentSchema) has noobject-metricarm, so everyobject-metricnode is refused at thetypediscriminator, with or withoutdrillDown(probe below).checkuses it only as a recogniser, alongside the known-type list.@objectstack/spec17.4.0,ObjectMetricPropsSchema.drillDownisz.unknown().ChartDrillDownSchemais the chart-only REACT-TIER record and does not govern this block.The probe runs
tsxoverpackages/types/src/zod/index.zod.ts, callingsafeValidateSchema:The last two rows are the positive control: on a block it has an arm for, the same door does reach
drillDown.⇒ No existing runtime door parses the members of an⚠️ A stored JSON metric config carrying either key is still accepted and ignored at render. The refusal is at the TypeScript door only. The changeset banner says so instead of using the ruling's 「refused at the door」 wording. The PM decides whether that wording holds.
object-metricdrillDown, so, as the dispatch instructed, no validator and no runtime channel was added.Verification (HEAD
fdaeab1b1; the patch round's re-runs atecff10661are under Acceptance notes)Build of the dependency closure,
pnpm --filter "@object-ui/plugin-dashboard^..." run build: lockVERDICT command-exit 0. The new interface is present inpackages/types/dist/data-display.d.ts.pnpm --filter @object-ui/types run type-checkandpnpm --filter @object-ui/plugin-dashboard run type-check:VERDICT command-exit 0.--listFilesOnlyconfirms each program compiles its pin. It also shows that plugin-dashboard's test program reads@object-ui/typesthroughdist/data-display.d.ts, notsrc.pnpm exec vitest run packages/plugin-dashboard/src/ packages/types/src/__tests__/, from the repo root:Test Files 371 passed (371),Tests 6526 passed (6526). A verbose rerun of the named suites (both new pins, drill-down declared-keys and mirror, zod-mirror-parity, both widget-schema-anchor pins, and the metric drill suites) gave10 passed,160 passed.Cross-package suites that load the registration (
registry-inputs-spec-parity,public-contract,ga-honoured-inputs-author-reach,component-input-union-specimens,packages/sdui-parser):21 passed,459 passed.Gates, each with exit 0:
check:control-bytes: OK.check:new-line-citations:0 new citation(s).check-changeset-presence: 6 source files of 2 released packages, 1 changeset.changeset:check: nomajor.check:changeset-claims: 8 pending changesets namedata-display.ts. All 8 were read, and all describe other regions and stay true.check:spec-symbols,check:doc-types,check:pending-changeset-literals,check:component-surface-parity,check:element-data-source-declaration,check:registry-bare-names,check:phantom-deps,check:unused-deps,check:self-import,check:esm-specifiers,check:test-path-roots,check:unreferenced-sources,check:lint-rule-coverage,check:vi-mock-specifiers,type-check:coverage.check-governed-queue-guard --testover the 7 paths: NOT GOVERNED.NOT MEASURED:
check:sdui-registration-pinsexited 2 (No console build to weigh at apps/console/dist/assets), a prerequisite that was not met. The gate judges registrations dropped at bundle time. This diff edits only thedescriptiontext of an existing input and touches nosideEffectsarray. Left to CI.ESLint was run on the 6 touched source and test files only, not the whole repo. The narrowing is safe for three reasons:
eslint.config.js, and neither package has its own;--format jsonreports 6 files, 0 errors and 52 warnings, all pre-existing (no-explicit-any, react-refresh, react-hooks), none on an added line;parserOptions {}, so there is no type-aware linting, and no rule ineslint-rules/reads the disk. The diff cannot change the verdict on any untouched file.The full
pnpm lintis left to CI.Ablation: the pins fail without the narrowing (both mutations committed first, applied through
ablation-replace.mjs, restored by blob)A. The narrowing removed. The anchor
export interface ObjectMetricDrillDownConfig extends DrillDownConfig {becameexport type ObjectMetricDrillDownConfig = DrillDownConfig; export interface AblatedMetricTombstones9002 {, which leaves the tombstones on an unrelated interface. The anchor count went 1 to 0, and the blob wenta8934d1c74bato4790116b9ce8.@object-ui/typestest program: exit 2, threeTS2578 Unused '@ts-expect-error'errors, on the freshfilterliteral, the freshmodeliteral, and the widenedDrillDownConfighanded across.dist/data-display.d.tswas 1. The plugin-dashboard test program then exited 2 with twoTS2578errors, on the JSXfilterandmodelines.a8934d1c74baandgit diff HEADis empty. The dist restore leg was a rebuild (exit 0) that left the marker count at 0 and the tombstone at 1. Both test programs then exited 0, andgit status --porcelainwas empty.B. The widget wiring removed. The anchor
drillDown?: ObjectMetricDrillDownConfig;becamedrillDown?: import('@object-ui/types').DrillDownConfig;, and the blob went3b41b51f0045to835d48b78e36.TS2344on_PropIsTheMetricShape, plus twoTS2578errors.tsc --noEmit) stayed at exit 0 under this mutation. The pin is the only thing guarding the wiring.3b41b51f0045and the diff is empty.Direction: red as predicted in both cases.
ablation-dist-preflight.mjscould not be used here because it resolves its repo root from its own location, which is the sister checkout. The dist proof is the marker count above: 1 under the mutation, 0 after the restore rebuild.Acceptance notes
ecff10661). The seat answered open question 2 with A and extended the claim's surface topackages/types/src/index.ts.ObjectMetricDrillDownConfigis now on the root export list besideDrillDownConfig, and the widget imports it from@object-ui/typeslike every other type in that file, so the emittedObjectMetricWidget.d.tsalso resolves undernode10. The changeset names both the root entry and the@object-ui/types/data-displaysubpath. The patch round re-ran: the closure build, both type-checks,plugin-dashboardbuild, 15 suites / 169 tests (the 9002 pins, 8071, 8970, the widget-schema anchors, zod-mirror parity and the root-barrel / export census suites),check:spec-symbols,check:changeset-claims,check:control-bytes,check:new-line-citationsandcheck:self-import, all exit 0.object-metric.drillDownrow inregistry-inputs-spec-parity.test.ts(in apps/console, outside this surface) recordsfilterandmodeas having no read site on this block and as deliberately not asserted. Both statements remain true: nothing at runtime changed.DrillDownConfig.modedocblock says the'filter'drill-through mode is "Used by charts, pivot tables and metric cards". None of the three readsmode. This is raised in the report together with the sibling gap: chart and pivot never readmode, and the data table never reads the drillfilter. The seat filed this with the sibling gap as objectui#10685.data-display.tshunk sits betweenDrillDownConfigandPivotTableSchema, and does not overlap theTableColumnregion that objectui#10643 edits.data-display.zod.ts,DataTableSchemaandTableColumnSchemaare untouched.Session:
https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNCGenerated by Claude Code