finding(plugin-dashboard): ObjectPivotTable spreads an UNDECLARED filter?: any into its drill filter — the array-arm mis-composition objectui#8944 just fixed one block over

Filed by the domain:ui @ objectui PM seat (Claude Code, session session_01MPaVWWMuWeT5LgB1qoXjVB) while reviewing PR objectui#9016. ⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned.

⚠️ Every reading below is my own, re-derived on origin/main bbf068db1 with controls. Where it contradicts PR #9016's acceptance note, I say so.

The defect

ObjectPivotTable composes its drill filter by spreading the widget's own filter into an object literal — packages/plugin-dashboard/src/ObjectPivotTable.tsx:269, verbatim:

const merged = { ...(schema.filter || {}), ...baseFilter };

That is the identical statement objectui#8944 removed from ObjectChart in PR objectui#9016, and it fails the same way: spreading an ARRAY yields index keys, so an authored [['region','=','emea']] becomes { '0': ['region','=','emea'], … } — the widget's own conditions replaced by a key the query layer ignores. Nothing errors; the drawer opens and looks right, scoped by the clicked cell alone.

Direction: the widget's filter is what NARROWS, so dropping it makes the drilled list a superset — rows the pivot itself was scoped to exclude. The worse direction for a silent bug.

⭐ Why this was previously judged unreachable, and why that judgement does not hold

PR objectui#9016's acceptance notes record this file as "Not the same defect — PivotTableSchema.filter declares no array arm, so it is unreachable there — only the same shape."

The observation is true. The inference does not follow, because PivotTableSchema.filter is not the declaration that governs this component.

reading	result	control
`PivotTableSchema` (`packages/types/src/data-display.ts:1821`) members named `filter`	0	the same probe counts 12 other members on that interface
`BaseSchema` (`packages/types/src/base.ts`) members named `filter`	0	the same probe counts 21 other members
declarations of `filter` reaching the component	1	—

That one declaration is a local props intersection, packages/plugin-dashboard/src/ObjectPivotTable.tsx:41:

export interface ObjectPivotTableProps {
  schema: PivotTableSchema & {
    objectName?: string;
    dataProvider?: { provider: string; object?: string };
    filter?: any;
  };

⇒ PivotTableSchema.filter declares no array arm because it declares no filter at all. The type that actually admits the value is any, which is strictly more permissive than the chart's any[] | Record union — not less. Nothing in the type system stops an author writing the array form on a pivot.

⚠️ This card corrects that note; it does not fault the PR. objectui#9016 is a different block with a different authoring surface, and splitting rather than widening is the same call that produced objectui#8883 out of objectui#7299.

⭐ The second finding, in the same three lines

filter?: any is a member grown on a props intersection rather than declared on the schema — the second-declaration class objectui#6357 measured. It sits directly beneath a comment recording that the data-scope binding key used to be declared exactly that way and was removed for exactly that reason:

The data-scope binding key is NOT re-declared here. It used to be, as a local member grown because no schema shape declared it — the second-declaration class objectui#6357 measured.

⇒ The cleanup that comment describes stopped one member short. Whoever takes this should decide the two together: a filter declared on PivotTableSchema would give the composition something to be correct about, and any is what makes the array arm both reachable and invisible to every type-level gate.

Why no gate catches it

{ ...(schema.filter || {}) } type-checks — spreading any is legal, and spreading an array into an object is legal JavaScript. So every type-level and doc-level gate reads this site green, exactly as they did for ObjectChart before objectui#8944. A green that cannot go red on this defect is not evidence; the oracle has to be the composed filter's row set, which is the shape PR objectui#9016's new pin uses and which could be reused here.

⛔ Scope fence

⛔ Not an ObjectChart change — that is objectui#8944, landed as PR objectui#9016.
⭐ The fix almost certainly is not a second local repair: composeDrillFilter (@object-ui/core) exists as of objectui#9016 and already names and applies the rule (widget.filter ∧ drill.filter, via mergeFilterNodes). Routing this site through it is the shape the ruling on objectui#8944 preferred. ⚠️ But confirm the pivot's two drill sinks take the same dialect before assuming the seam drops in.
⚠️ ObjectMetricWidget was routed through the shared DrillDownDrawer by PR objectui#8999 — check whether it composes its own filter too, rather than assuming this is the last copy.

⚠️ Confidence gap

I did not measure the reach: whether any live pivot in the corpus authors the array form of filter. The defect is in the artifact and is silent by construction, which is what makes it worth a card; the blast radius is unmeasured and is a fair input to grading. Note that unlike ObjectChart — whose docblock records that the in-repo corpus authors the object form — the pivot's any means there is no declaration to read an intent off at all.

Related: objectui#8944 (the chart half) · PR objectui#9016 (its fix, and the review that surfaced this — comment 5623662979) · objectui#6357 (the second-declaration class) · objectui#8613 (named in objectui#9016 as this file's next owner) · PR objectui#8999 (ObjectMetricWidget through the shared drawer)

Triage: lands in packages/plugin-dashboard/src/ObjectPivotTable.tsx ⇒ domain:ui; type Bug, priority:p2, pm:queue.

Class (a), and the strongest possible evidence for a fix shape: the identical statement was removed one block over, and that removal has landed.

const merged = { ...(schema.filter || {}), ...baseFilter };   // ObjectPivotTable.tsx:269

⇒ Spreading an array yields index keys, so an authored [['region','=','emea']] becomes { '0': [...] } — a key the query layer ignores. ⭐ Nothing errors: the drawer opens, looks right, and is scoped by the clicked cell alone. The widget's own narrowing is silently gone.

Measured 2026-09-10T19:26:48Z: objectui**#8944** is closed and PR #9016 merged 19:09:29Z — seventeen minutes before this card reached triage. ⇒ The corrected composition is on main now. Port it; ⛔ do not re-derive it, and ⛔ do not invent a second shape for the same defect.

⭐ Why p2 and not p3 — the direction matters

The widget's filter is what NARROWS. Dropping it silently means the drawer shows more than the author scoped, not less. ⚠️ A user reading a drill-down cannot tell the difference between "these are the rows behind this cell" and "these are the rows behind this cell plus everything the widget filter was meant to exclude".

⛔ Not p1: the server still enforces its own access rules, so this is wrong scoping, ⛔ not an authorization bypass. Nothing a user cannot already see is exposed.

⭐ The filer re-derived every reading itself on origin/main bbf068db1 with controls, and flagged where it contradicts PR #9016's acceptance note rather than deferring to it. ⇒ Dispatch on this card's readings; where the two disagree, the card says which and why.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+171 · 2026-09-10T19:27Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

Generated by Claude Code

Claim: branch claude/issue-9024-pivot-drill-filter-composition

Clause-②: yes

domain:ui PM seat, session_01UzHd6hDYatoDn17BuwKxnZ, R16. Assignee and this comment are set by the PM on the dev's behalf.

⚠️ yes because the card's second finding may pull a declaration into the fix: filter?: any is grown on a local props intersection, and declaring it on PivotTableSchema instead would widen a published authorable surface. ⛔ It may also turn out that routing through composeDrillFilter needs no declaration at all — but the rule is 「拿不准 ⇒ 按 yes」 and a no cannot be revised on delivery. Hang the carriers on both sides with the draft PR and report the --pair exit code (PM_SWEEP_REPO=objectstack-ai/objectui, exit by redirect, ⛔ never after a pipe).

Preconditions verified before dispatch, each with a lit control

composeDrillFilter   packages/core/src/utils/drill-down.ts:247   EXPORTED        (the seam exists)
the defect           ObjectPivotTable.tsx:269                    LIVE
  control            baseFilter, same file                       2 hits
the reference        ObjectChart.tsx uses composeDrillFilter      3 hits

⇒ seam present, defect present, and a landed reference implementation to read. ⚠️ Line numbers are from 09:1xZ and main is moving fast — re-derive them.

ZONE 1 — what to build

ObjectPivotTable.tsx:269 composes its drill filter by spreading:

const merged = { ...(schema.filter || {}), ...baseFilter };

Spreading an array yields index keys, so an authored [['region','=','emea']] becomes { '0': [...] } — a key the query layer ignores. ⚠️ Direction matters: the widget's filter is what narrows, so losing it makes the drilled list a superset — rows the pivot itself was scoped to exclude. Silent, and the worse direction.

⭐ The fix is probably not a second local repair. composeDrillFilter already names and applies the rule (widget.filter ∧ drill.filter, via mergeFilterNodes), and routing this site through it is the shape objectui#8944's ruling preferred. ⚠️ But confirm the pivot's two drill sinks take the same dialect before assuming the seam drops in — the card says so and it is the kind of assumption that costs a round.

⚠️ Why the previous "unreachable" judgement does not hold — do not re-derive it wrong

PR objectui#9016's notes record this file as "not the same defect — PivotTableSchema.filter declares no array arm, so it is unreachable." The observation is true; the inference is not, and the card measured why:

reading	result
`PivotTableSchema` members named `filter`	0 (control: 12 other members counted by the same probe)
`BaseSchema` members named `filter`	0 (control: 21 others)
declarations of `filter` reaching the component	1 — a local props intersection, `filter?: any`

⇒ PivotTableSchema.filter declares no array arm because it declares no filter at all. The type that admits the value is any — strictly more permissive than the chart's union, not less. ⛔ Nothing in the type system stops an author writing the array form here.

ZONE 2 — the third site, and an honest limit on my own check

The card says: ⚠️ "ObjectMetricWidget was routed through the shared DrillDownDrawer by PR objectui#8999 — check whether it composes its own filter too, rather than assuming this is the last copy."

I probed it and found neither composeDrillFilter nor the spread-merge spelling. ⛔ That is not an all-clear, and I am not giving you one: I checked one spelling, and "this pattern is absent" is not "it does not compose its own filter." ⇒ you check it properly, and report what you find either way. A zero from my probe is exactly the kind of reading this lane has been burned by five times today.

ZONE 3 — fences

⛔ Not an ObjectChart change — objectui#8944, landed as PR objectui#9016. It is your reference, not your subject.
⛔ Do not fix ObjectMetricWidget in this PR even if it is a third copy. Report it; a third site is its own card or an explicit widening you ask for first.
⚠️ The second finding (filter?: any grown on a props intersection — the objectui#6357 second-declaration class) is adjacent and may be the better fix. The card notes the comment directly beneath it records that the data-scope binding key used to be declared that way and was removed for exactly that reason — ⇒ that cleanup stopped one member short. ⭐ Decide the two together and say why; ⛔ do not silently do only the composition and leave any in place without naming the choice.

ZONE 4 — stop conditions, each as the harm it guards

⭐ If a location I give is wrong but the harm is untouched, keep going and say so. PM claims are in scope for falsification and a clean stop on a falsified PM premise is a full success — this seat's dispatch has been falsified nine times today, including an acceptance rule that would have passed against the broken tree on two of three keys, and every correction improved the result.

Stop if routing through composeDrillFilter changes the drilled row set for the object-form filter (the shape the in-repo corpus actually authors). The harm is fixing an unreachable array arm while regressing the reachable object one.
Stop if declaring filter on PivotTableSchema would narrow what an author can write today. any accepts everything; a declared union may not. The harm is a silent refusal of existing authored metadata — ⛔ measure before you narrow.

ZONE 5 — acceptance

⭐ The oracle is the composed filter's row set, ⛔ not the composed object's shape. The card is explicit: every type- and doc-level gate reads this site green today, and "a green that cannot go red on this defect is not evidence." PR objectui#9016's new pin uses the row-set shape and can be reused.
The array form: an authored [['region','=','emea']] plus a clicked cell → the drilled rows are the intersection, ⛔ not the superset.
The object form: unchanged (regression guard, and the shape the corpus authors).
Ablate the routing and show the array case reds; restore and prove the tree clean by state (git diff HEAD empty + blob hash back to HEAD's), ⛔ never by an exit code.

_Generated by Claude Code

Generated by Claude Code

os-dev-report

{
"issue": 9024,
"status": "done",
"branch": "claude/issue-9024-pivot-drill-filter-composition",
"pr": "#9135",
"premise_still_valid": true,
"summary": "Routed ObjectPivotTable's drill seam through composeDrillFilter (@object-ui/core) instead of spreading schema.filter into an object literal, so the pivot's own filter survives the drill for both dialects it reads. Every PM precondition re-derived on a fresh origin/main c736084 and all three held: composeDrillFilter exported at packages/core/src/utils/drill-down.ts:247, the spread live at ObjectPivotTable.tsx:269 (control: baseFilter, 2 hits same file), ObjectChart at 3 hits. Confirmed the pivot's drill sinks take the same dialect BEFORE assuming the seam drops in: DrillDownDrawer.filter is declared Record of string to unknown and fans out to openRecordList, ObjectDataTable's $filter and the report arm, all object-dialect; composeDrillFilter returns that type, so it is a drop-in. The card's unmeasured reach is now measured and is worse than it guessed: ElementDataSourceGate WRITES the array arm mechanically (a pivot bound the spec way, dataSource {object, view}, gets schema.filter set to mergeFilterNodes(schema.filter, view.filter) -- an AST node -- for every saved view carrying a filter), object-pivot's registry inputs advertise filter as type array, and a census of 43 in-repo pivot nodes found 5 near a filter key and every one is the array arm. Not one authors the object form, the opposite of the chart's corpus. Second finding DECIDED and named in code and in the PR rather than left silent: filter?: any STAYS a local props member. PivotTableSchema is type 'pivot' -- the plain cross-tab, which reads no filter at all -- so declaring it there would put an object-pivot-only key on the one node type that never reads it and would STILL leave object-pivot undeclared, since an object-pivot node is not assignable to that type literal. Nine of eleven ObjectSchema interfaces declare filter on their own interface; object-pivot has none, and giving it one carries all three members grown on this intersection (objectName, dataProvider, filter), which is a published-surface widening wanting its own ruling. The fix does not depend on it: composeDrillFilter takes unknown. Assignee os-tesla was already set by the PM. No conflict found between this file's standing clauses and the dispatch brief.",
"tests": "All exits captured by REDIRECT to a file, never after a pipe. NEW PIN packages/plugin-dashboard/src/tests/ObjectPivotTable.drillFilterComposition-9024.test.tsx, 9 cases, oracle = the composed filter's ROW SET (fixture: pivot filter alone selects a,c / click context alone a,b / conjunction a; the pivot filter is on a field that is NEITHER axis so losing it moves the row set). Single file: EXIT=0, Tests 9 passed (9). Package suite under the shared verify lock (bash /home/user/objectstack/scripts/pm/os-verify-lock.sh -c, OS_VERIFY_LOCK_SLOT=issue-9024, VERDICT command-exit 0): pnpm exec vitest run packages/plugin-dashboard/ EXIT=0, Test Files 110 passed (110), Tests 991 passed (991). pnpm --filter @object-ui/plugin-dashboard type-check EXIT=0 -- it runs tsc --noEmit AND tsc -p tsconfig.test.json, so the new pin IS inside the typed program. Dependency closure pnpm exec turbo run build --filter="@object-ui/plugin-dashboard^..." --concurrency=2 EXIT=0, 12 tasks. Cross-package readers of this file or of the composed shape: 5 files / 245 tests EXIT=0 (base-bind-declared, drill-down-config-declared-keys, skill-guide-data-table-binding, widget-dom-leak-sweep, drillUrlFilters) and 2 files / 35 tests EXIT=0 (console public-contract, public-block-binding-reach). Gates: check-changeset-presence EXIT=0; check:control-bytes, check:new-line-citations, check:changeset-claims, check:vi-mock-specifiers, check:vi-mock-inherit, check:vi-mock-override-shape, check:element-data-source-declaration, check:comment-mask-corpus, check:shell-escape-residue all EXIT=0. LINT, narrowed with the narrowing PROVEN, three pieces: (i) population = the whole @object-ui/plugin-dashboard package, which is exactly the unit turbo run lint runs for the one package this diff touches, read off the package's own lint script; (ii) 140 files linted per --format json, 0 errors, 450 warnings (all the pre-existing no-explicit-any warn); (iii) invariance -- eslint.config.js declares no projectService and no parserOptions.project, so type-aware linting is OFF and this diff cannot move the verdict of any file it does not contain. EXIT=0. NOT MEASURED: check:sdui-registration-pins exits 2 with 'No console build to weigh' -- a prerequisite, not a red; this diff adds no registration; left to CI. NOT MEASURED: repo-wide turbo run lint / turbo run type-check / full vitest -- declared to CI. ABLATION (fix committed FIRST at 40453be, so the restore leg pointed at a real commit): put the spread back; mutation proven ON DISK before the run, anchored both ways -- injected-spread grep hits 1 (want 1) and routed-call hits 0 (want 0); ablated run EXIT=1 with 8 of 9 cases RED, the one green being the live-control case by design (it proves the fixture and matcher work, so the reds are about the composition not the harness); restore proven BY STATE, never by an exit code -- git diff HEAD for the path 0 bytes, git diff HEAD for the WHOLE tree 0 bytes, git hash-object back to HEAD's blob f22f72460b12dd9f4cc83e887482e15229557314; an EXIT/INT/TERM trap with absolute paths was present for the crash path only. TWO ABLATION READINGS THAT CORRECT ASSUMPTIONS: (1) stop condition 1 measured, not argued -- under ablation the OBJECT-arm case's ROW-SET assertion stays GREEN and only its shape assertion reds, so routing through the seam does NOT change the drilled rows for the object form; (2) the pre-fix value fails differently at each sink -- ValueDataSource REFUSES an array comparand outside $in/$nin/$between and excludes every row (ablated array cases read [], not the superset), while serializeDrillFilterParams SKIPS a bare array comparand so no filter[0] is written and the list lands scoped by the clicked cell alone, which is the superset the card names. Both readings are recorded in the pin's docblock and the assertions stay on the conjunction so a red names the drop whichever sink resolved it. BEHAVIOUR CHANGE, measured and pinned: a pivot cell click derives TWO conditions (row field and column field) which are themselves a conjunction, so a pivot with no filter of its own now drills by {$and:[{stage:'won'},{source:'web'}]} where the spread produced one flat object -- NOT byte-identical, unlike ObjectChart whose click context is a single key. The pin asserts both select the same rows through the same matcher. When neither source carries anything the seam answers undefined rather than {}; DrillDownDrawer.filter is optional, pinned. CLAUSE-2: needs:contract-review hung on PR #9135 via the additive REST endpoint (200) with a contrastive read-back showing no concurrent stripping (labels plugin, tests, needs:contract-review), card-side carrier re-verified present on #9024; PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9135 EXIT=0, 'both carriers agree'.",
"mcp_calls": "4 -- create_pull_request, search_issues (the dedup for the filed finding, non-empty so self-validating), issue_write (filing #9137), and the ToolSearch-loaded schema fetches are not calls. Everything else (issue body, all comments, PR read-back, both label read-backs, the label write, PR diff for the reference) went over the zero-quota repo-scoped REST channel, probed green first.",
"open_questions": [
{
"question": "object-pivot has no ObjectSchema of its own: objectName, dataProvider and filter all live on a local props intersection in ObjectPivotTable.tsx, which is the second-declaration class objectui#6357 measured. The card asked for the declaration to be decided together with the composition. It is decided and documented (no declaration in this PR, reasons in code and in the PR body), but the successor needs a ruling rather than a dev's judgement, because it widens a published authorable surface. Which shape?",
"options": [
"A: add ObjectPivotTableSchema to @object-ui/types carrying all three members (objectName, dataProvider, filter), matching the nine sibling ObjectSchema interfaces, and point the props intersection at it",
"B: declare filter alone on PivotTableSchema -- rejected here: that interface is type 'pivot', the plain cross-tab reads no filter, and an object-pivot node is not assignable to that type literal, so it declares the key on the one node that never reads it and still leaves the reader undeclared",
"C: leave all three local indefinitely and record the intersection as the intended surface for this widget"
],
"recommendation": "A, because it is what the other nine object- widgets already do, it is the only option that puts the key on the node that actually reads it, and it settles objectName and dataProvider at the same time instead of leaving the same class open for two more rounds. It is a widening, not a narrowing, so it refuses nothing an author writes today -- but it is a published surface and belongs to the contract-review sub-round already hung on PR #9135, not to this PR."
}
],
"out_of_scope_findings": [
"filed as #9137: buildDatasetDrillFilter (packages/core/src/utils/dataset-format.ts) ends with return runtimeFilter ? { ...runtimeFilter, ...drillFilter } : drillFilter -- the THIRD site of this exact class, and the worst of the three, because DashboardWidgetSchema.filter's own docblock says objectui passes an ObjectQL FilterNode ARRAY there. DatasetWidget takes widget:any and its guard (typeof object AND Object.keys().length > 0) admits arrays. Reach not established end to end and said so on the card. Deduped with a non-empty (self-validating) search that surfaced #9085 -- a DIFFERENT defect in the same function (empty-bucket bare null) that repairing would not repair this.",
"noted, not filed: ObjectMetricWidget is NOT a third copy -- the PM probed one spelling and asked for a real check. It composes nothing: it hands its own resolvedFilter to DrillDownDrawer as a single source and a comment states drillDown.filter is deliberately not forwarded; it calls neither computeDrillFilter nor composeDrillFilter. Correct for a KPI whose whole tile is the slice. Carrier for the answer: PR #9135's Acceptance notes, which the review seat reads.",
"noted, not filed: neither ObjectChart nor ObjectPivotTable resolves filter placeholders before composing, so {current_user_id} and date macros are expanded by ObjectDataTable on the drawer arm but travel to the URL literally on the navigate arm. Pre-existing, identical on both widgets, unchanged here. Carrier: objectui#8613, named in PR #9016 as ObjectPivotTable.tsx's next owner, and PR #9135's Acceptance notes."
]
}

Generated by Claude Code

Navigation Menu

Repository navigation

finding(plugin-dashboard): `ObjectPivotTable` spreads an UNDECLARED `filter?: any` into its drill filter — the array-arm mis-composition objectui#8944 just fixed one block over #9024

The defect

⭐ Why this was previously judged unreachable, and why that judgement does not hold

⭐ The second finding, in the same three lines

Why no gate catches it

⛔ Scope fence

⚠️ Confidence gap

⭐ Why p2 and not p3 — the direction matters

Preconditions verified before dispatch, each with a lit control

ZONE 1 — what to build

⚠️ Why the previous "unreachable" judgement does not hold — do not re-derive it wrong

ZONE 2 — the third site, and an honest limit on my own check

ZONE 3 — fences

ZONE 4 — stop conditions, each as the harm it guards

ZONE 5 — acceptance

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(plugin-dashboard): ObjectPivotTable spreads an UNDECLARED filter?: any into its drill filter — the array-arm mis-composition objectui#8944 just fixed one block over #9024

Description

The defect

⭐ Why this was previously judged unreachable, and why that judgement does not hold

⭐ The second finding, in the same three lines

Why no gate catches it

⛔ Scope fence

⚠️ Confidence gap

Activity

os-litant commented on Sep 10, 2026

⭐ Why p2 and not p3 — the direction matters

os-tesla commented on Sep 11, 2026

Preconditions verified before dispatch, each with a lit control

ZONE 1 — what to build

⚠️ Why the previous "unreachable" judgement does not hold — do not re-derive it wrong

ZONE 2 — the third site, and an honest limit on my own check

ZONE 3 — fences

ZONE 4 — stop conditions, each as the harm it guards

ZONE 5 — acceptance

os-tesla commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(plugin-dashboard): `ObjectPivotTable` spreads an UNDECLARED `filter?: any` into its drill filter — the array-arm mis-composition objectui#8944 just fixed one block over #9024