Repository navigation
feat(types)!: showFilters is retired on object-grid, refused by name with the list view's userActions.filter named (objectui#11068) - #11306
Conversation
…ame with `userActions.filter` named (objectui#11068) An `object-grid` has no filter UI and never read `showFilters`; the one filter surface is the `list-view` toolbar's builder, switched by `userActions.filter`. The key is now `?: never` on the `ObjectGridSchema` interface and a `retirementTombstone()` on its Zod twin, so both authoring faces refuse it by name. An `object-view`'s and a `list-view`'s own `showFilters` are untouched. The root README's `object-grid` example and the 9729 byte-ruler corpus stop authoring the key; the schema reference and the plugin-grid guide name the retirement. Claude-Session: https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZ Co-authored-by: Claude <noreply@anthropic.com>
…wFilters` is still declared The retirement in the previous commit made that sentence false; `keyboardNavigation` is the one key it still describes. Claude-Session: https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZ Co-authored-by: Claude <noreply@anthropic.com>
github-actions
Bot
added
documentation
|
changeset-claim-re-read
|
✅ 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
|
Contract reviewServed-tier: PR objectui#11306 ( ① Derived judgments
② Semver level
③ Boundary flags
Implemented-by: VERDICT: PASS |
…inside the `calendar` block; the flat spelling is the runtime handoff (objectui#8831) (objectstack-ai#11308) Fixes objectstack-ai#8831 Clause-②: no ## What changes `@objectstack/spec` refuses `startDateField` / `endDateField` / `titleField` / `colorField` / `allDayField` written flat on an `object-calendar` node. Its diagnostic prescribes `calendar: { startDateField, endDateField, titleField, colorField, allDayField }`. Since 17.5.0 the spec's `CalendarConfigSchema` declares all five, `allDayField` included. This PR is ruled direction (a): objectui stops teaching the flat spelling at the `object-calendar` position and teaches the container. - **`packages/plugin-calendar/README.md`** - Both `object-calendar` snippets ("With ObjectQL Integration" and "ObjectQL Integration") now write the five keys inside `calendar`, with `allDayField` in the block. Both are compiled by `check:doc-snippets`. - One paragraph names the flat spelling for what it is: the runtime handoff `ObjectView` / `ListView` emit, which `getCalendarConfig` reads only when the node has no `calendar` block. It is declared because the renderer reads it, and it is not a second authorable spelling (Prime Directive objectstack-ai#12). - The snippet comment no longer says the block "proves" the flat keys are declared. It now says what the annotation checks on the block (values, not key names). - The "gates the whole configuration" paragraph is rewritten for the block, because it described the flat path. Its behavioural claims were measured, see below. - **`packages/types`, both faces of `ObjectCalendarSchema`** - The five flat members' `.describe()` text (one shared helper, `objectCalendarFlatField`) and TS docblocks call them the FLAT spelling, read but not authored, and point at `calendar.KEY`. - The `calendar` member's text calls the block the authored spelling. - The `allDayField` docblock no longer says the key is objectui-local. It records that 17.5.0 declares it. - **`ObjectCalendarBlockConfigSchema`'s `.extend({ allDayField })`.** Only its description and comment changed: it no longer says the spec refuses the key. See H2. - **Pin.** The `calendar-flat-color-allday-8466` row "the README still teaches all five together, which is what makes them authorable" is inverted. It now reads the README's authored `object-calendar` nodes by brace matching and asserts: - none writes a field-name key flat; - one `calendar` block carries all five; - control, same instrument, opposite verdict: a `calendar-view` node is seen writing `titleField` flat. The file's header gets a dated note. - **Changesets.** New `.changeset/8831-calendar-flat-teaching-face.md` (`@object-ui/types` patch, `@object-ui/plugin-calendar` patch). The pending `.changeset/8466-calendar-color-allday-fields.md` says the README "already teaches" the flat keys, which this release makes false. It gets a dated, append-only note, and its frontmatter is byte-identical (md5 of the first three lines unchanged). ## What is NOT changed - **No accept set moves.** The flat members stay declared on both faces with the same types, because `ObjectCalendar` reads them and `ObjectView` / `ListView` emit them. - Excluded regions are untouched: `ObjectCalendarSchema.objectName` and `requireRecordSource` (held by objectui#11117), the `CalendarViewSchema` declarations, `navigation`, and `registry-inputs-spec-parity.test.ts` (held by objectui#11168). ## Premises, re-measured in this worktree (base `1ccb5ba7d`, installed `@objectstack/spec` 17.5.0, single store copy) - **Unlock predicate.** The card's probe exits **0**. Two lit controls run beside it: `{ startDateField }` parses (`true`), and `{ startDateField, bogusKeyZz }` is refused (`false`, `unrecognized_keys` naming `bogusKeyZz`). Shape keys: `allDayField, colorField, endDateField, startDateField, titleField`. - **The trap is real at the public row.** - `ComponentPropsMap['object-calendar']` refuses the README's old first snippet: `unrecognized_keys` on all five, and the message starts "Write this as a key of the `calendar` config object instead". - It also refuses the second snippet (three keys). - It accepts the rewritten container form. - Control: a bogus key is refused. - **H1, the `calendar-view` site.** `ComponentPropsMap` has no `calendar-view` row (55 rows; the `object-calendar` control is present), and `CalendarViewSchema` has no `calendar` container. So the flat keys are that element's only spelling, and the container cannot be taught there. - Decision: keep the five-key sentence, scope it explicitly to `calendar-view` ("on a `calendar-view` node ... here the flat keys are the only spelling"), and point to the `object-calendar` block in the next section. - The compiler-pinned `CalendarViewNode` listing and the "Calendar Event Structure" fence are `calendar-view`'s and stay. - **H2, the `.extend({ allDayField })`.** It is now an identity. The spec's `CalendarConfigSchema.partial()` member and the local `z.string().optional()` agree on 8 of 8 values: two strings, `undefined`, `42`, `true`, `null`, `{}`, an array. On the TS side, `ObjectCalendarSchema['allDayField']` equals `CalendarConfig['allDayField']`; a tsc probe checked this, and its control fired. - Only the description and comment changed. The member is kept: removing it is an accept-set no-op, but the `zod-mirror-parity` ledger comment names this extension, and that file is outside this claim. - **H3, docs pages.** Falsified. Every `object-calendar` snippet on `content/docs/plugins/plugin-calendar.mdx` already writes `calendar: { ... }`, and its Schema API fence lists no flat key. `git grep` found no other `content/docs/**`, `examples/**` or `skills/**` site that authors `object-calendar` with a flat key. The flat keys in `content/docs/api/schema-reference.md` and the schema-catalog JSON are `calendar-view`'s. ⇒ no docs page changed. - **H4, the 8830 header.** Left as it is. It is framed "Measured on the dispatch base, with `@objectstack/spec` 17.4.0 installed then", and the test body's 17.5.0 row explains the move. A reader does not take it as current. - **README behavioural claims, measured.** A one-off render probe went through the real `SchemaRenderer` and registry, and was deleted afterwards (tree clean): - control: a correct block draws both rows, with no unscheduled area; - a misspelt start key inside the block draws nothing, shows `Unscheduled (2)`, and no refusal screen; - a node with no `calendar` block renders "Calendar configuration required". ## Verification, all at HEAD `bac7f8789` Run from the worktree; heavy runs went through the shared verify lock. The verdict lines are quoted. | gate | result | |---|---| | `turbo run build` over `check:doc-snippets --build-filter` (36 packages, `--concurrency=2`) | `Tasks: 35 successful, 35 total`, `VERDICT command-exit 0` | | `pnpm check:doc-snippets` | exit 0, `Semantic phase: 698 of 698 block(s) judged, 0 failed.` | | `pnpm check:readme-exports` | exit 0, `check-readme-exports: OK (... 554 real, 0 wrong-path, 0 fabricated ...)` | | `pnpm --filter @object-ui/types type-check` (the script echoed: `tsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.json`) | exit 0. `tsc -p tsconfig.test.json --listFiles` counts the 8466 file once, so the test face is in it | | `pnpm exec vitest run --maxWorkers=2 packages/types/ packages/plugin-calendar/src/readme-calendar-view-schema.test.ts` | `Test Files 302 passed (302)`, `Tests 7605 passed (7605)`, `VERDICT command-exit 0` | | eslint on the three changed TS files (`--no-inline-config`) | 0 errors. The 8466 file keeps exactly its 2 documented `no-explicit-any` warnings | | `check:doc-types`, `check:doc-fences`, `check:doc-example-ids`, `check:installed-pin-claims`, `check:new-line-citations`, `check:control-bytes`, `check:test-path-roots`, `check:pending-changeset-literals`, `check:vi-mock-specifiers`, `check:vi-mock-inherit`, `check:vi-mock-override-shape`, `check:spec-symbols`, `check:component-surface-parity`, `check:designer-field-key-parity`, `check:element-data-source-declaration` | all exit 0 | | `check-changeset-presence` / `-no-major` / `-fixed` | exit 0, `3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)` | | `markdown-test-inputs --audit` | exit 0, `107 candidate test files, all adjudicated; 78 declared entries, all present.` | | `check:comment-mask-corpus` | exit 0, within the residue objectui#7882 holds (1 file, 0 fabricated) | | `check:changeset-claims`, `check-changeset-overwrite` (report-only) | Read. 30 pending changesets name the touched files. The three that mention calendar keys (7632, 7804, 9606) describe other regions and are not made false. The overwrite report is case 2 (deliberate append, declaration unchanged) | | `check-governed-queue-guard --test` over the six paths | `NOT GOVERNED` | The repo-wide `pnpm lint` and the full CI matrix are left to CI. `dispatch-gates.mjs --repo objectstack-ai/objectui` refuses (exit 2), as it does for any objectui card, so this list is hand-derived from the diff. ## Reverse verification (one-shot; each mutation landed through `ablation-replace.mjs`, which checks the anchor count and the blob hash, and was restored to the HEAD blob with `git diff HEAD` empty) - **The new pin can fail.** A flat `titleField` was put back on the README's second `object-calendar` node. - Result: `× the README authors the five INSIDE the calendar block ...`, `AssertionError: a README object-calendar node writes titleField flat`, `Tests 1 failed | 18 passed`. Direction as expected: red. - The first attempt was a no-op and is declared here: its replacement contained the anchor, the tool refused it before running anything, and no reading was taken. - **`check:doc-snippets` judges the README block's values.** - `allDayField: 'isAllDay'` was changed to `allDayField: 42` inside the block. - Result: `[semantic] packages/plugin-calendar/README.md ... TS2322: Type 'number' is not assignable to type 'string'.`, `698 of 698 block(s) judged, 1 failed`. Red, as expected. ## Round 2 (`a86a6afdb`) Two findings from round 1, folded in on the seat's order. They are this card's own subject (what the published faces teach about the `calendar` container and `allDayField`), and neither could ride anywhere else. - `content/docs/plugins/plugin-calendar.mdx`, section "CalendarConfig": the paragraph that said neither published face of `ObjectCalendarSchema` declares the `calendar` container (false since objectui#8651) now says what holds on the installed 17.5.0: - Both faces declare the container, with the five keys as members. - Values are checked: `calendar: { startDateField: 42 }` is refused, and `dateField` / `endField` are refused by name (objectui#8355). - The block is `.passthrough()`, so any other key parses. - On `object-calendar`, the spec declares the `calendar` key but not its shape. - On the list-view path, objectui's mirror is open while the spec's own block is strict. - Dated, append-only corrections, each with its frontmatter and existing bytes identical (prefix md5 equal, 0 deleted lines): - `.changeset/8026-objectcalendar-alldayfield-honoured.md`: its "Not spec surface" paragraph. Made false by objectui#11073. - `.changeset/8830-calendar-doc-key-set.md`: "objectui's own `allDayField`". Made false by objectui#11073. - `.changeset/olive-buckets-scream.md`: "the four `CalendarConfigSchema` names plus objectui's `allDayField`", made false by objectui#11073; and the kept `dateField` / `endField` rungs and the parsing `calendar.dateField`, made false by objectui#8355. - Left as dated history: `.changeset/7928-listviews-by-reference-fold.md`, whose list of refused named-view keys is labelled "Measured on 17.4.0". - Gates at `a86a6afdb`, all exit 0: - `check:doc-snippets` (698/698 judged, 0 failed), `check:doc-types`, `check:doc-fences`, `check:doc-example-ids`; - `check-changeset-presence` / `-no-major` / `-fixed` / `-overwrite`, `check:changeset-claims`, `check:pending-changeset-literals`; - `check:new-line-citations`, `check:control-bytes`, `check:installed-pin-claims`, `check-doc-links`. - The 19 tests that read the four changed markdown files: 773 passed. ## Acceptance notes None of these was changed here. Each one is drift, outside this claim, or both: - `packages/plugin-calendar/src/ObjectCalendar.tsx`, the `ObjectCalendarConfig` docblock, still says `allDayField` is not a spec key. That sentence is already a `stale` entry in `check-installed-spec-pin-claims.mjs`'s ledger. Carrier: none. - `apps/console/src/__tests__/registry-inputs-spec-parity.test.ts` pin text calls `allDayField` "an objectui-local extra key" and the spec side "exactly the four documented keys". Carrier: objectui#11168, which holds that file this round. - `packages/types/src/__tests__/zod-mirror-parity.test.ts`, the ledger comment beside `objectql.zod.ts#ObjectCalendarSchema`, still speaks of the "four-key calendar config vocabulary" and objectui's "single local knob". Removing the now-identity `allDayField` extension would make it fully false, which is why that removal is not in this PR. Carrier: none; objectui#6152 (another seat) holds that file. - `packages/types/src/zod/objectql.zod.ts`, the list-view mirror note ("`.passthrough()` is kept ... because the renderers grow config knobs ahead of the protocol (calendar's `allDayField`, for one)") cites an example that has been out of date since 17.5.0. The list-view `CalendarConfig` mirror now takes `allDayField` from the spec. The note sits outside this card's region (PR objectstack-ai#11306 and objectui#11117 hold neighbouring regions). Carrier: none. - Round 1's two items on `plugin-calendar.mdx` and the three pending changesets were folded into round 2 above. --- _Generated by [Claude Code](https://claude.ai/code/session_01VhxTqosz7wn54ahqyxgERT)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
2 participants
Part of #11068
Clause-②: yes
The
showFiltershalf of the card, as triage's retriage answer (comment 5896596687) ruled it: RETIRE, with a named tombstone that points at the list view'suserActions.filter.keyboardNavigationis not in this PR. It waits until objectstack-ai/objectstack#20694's row is installable (PR objectstack-ai/objectstack#20882 is not in@objectstack/spec17.5.0), so the card stays open.What changed
@object-ui/types, zod twin (ObjectGridSchemainzod/objectql.zod.ts):showFilters: z.boolean().optional()is nowretirementTombstone(OBJECT_GRID_SHOW_FILTERS_RETIRED), next to therowSpecActions/bulkSpecActions/name/placeholdertombstones. The one string goes into both.describe()and the parse message. It names the card, says the grid has no filter UI, sends the author to alist-viewand itsuserActions.filter, and namesfilterfor narrowing the grid's own rows.@object-ui/types, TypeScript twin (ObjectGridSchemainobjectql.ts):showFilters?: boolean(the deprecated "legacy filters toggle") is nowshowFilters?: neverwith a RETIRED docblock. It is not deleted, because the key would then fall back toBaseSchema's index signature and type-check again. That is the same conventionrowSpecActionsuses.ObjectViewSchema.showFilters(both faces), whichObjectViewreads. The list view'sshowFilters(zodListViewSchema), whichListViewfolds ontouserActions.filter.NamedListView.showFilters, already?: neversince objectui#7924.DashboardConfig.showFilters. Theobject-viewtableslot's existing by-name refusal.README.mdobject-gridexample, and the objectui#9729 byte-ruler corpus inObjectGrid.operatorsInert-9729.test.tsx. That corpus's "filter surface on" document carriedshowFilters: true, which never drew anything. It now measures with the grid's search box (searchableFields), and the test is renamed to match.schema-reference.mdgets a retired callout underObjectGridSchemaand an updated history sentence.plugin-grid.mdxgets a paragraph next to the four earlier retirements.packages/types/src/__tests__/object-grid-show-filters-retired-11068.test.tscovers both authoring faces, the metadata channel, member-not-deletion, the upstream half and the TS twin.ObjectGrid.declaredKeys-11068.test.tsxaddsshowFilters(true and false) to the byte ruler. Comment-only count updates (four to five) inobject-view-slot-key-lists.test.tsand the two slot docblocks..changeset/11068-object-grid-show-filters.mdis@object-ui/typesminor, with a BREAKING (authoring) line. The pending.changeset/11068-grid-declared-keys.md(from PR objectui#11130, not yet released) said "showFiltersandkeyboardNavigationare still declared and still not read". This PR makes that false, so it now names onlykeyboardNavigation.Dispatch assumptions, measured
1563d3e10b, the new pin read 5 failed / 13 passed.{ type: 'object-grid', objectName, showFilters: true }parsed green onsafeValidateSchemaand onStrictAnyComponentSchema("showFilters: true parsed green: expected true to be false"). The 13 that passed are the controls. The renderer half is a byte ruler: the same grid drawn with and withoutshowFilters(true and false) gives identical bytes, and the lit controldescriptionmoves them.packages/plugin-grid/srcis not edited, so the ruler reads base behaviour.objectql.tsdeclaresshowFilterson three interfaces. These areObjectGridSchema(retired here),ObjectViewSchema(its own key, read byObjectViewas the fallback behinduserActions.filter) andNamedListView(already a tombstone). The zod side declares it onObjectGridSchema(retired),ObjectViewSchema,ListViewSchema,DashboardConfigSchema, and in the table-slot withheld set.object-viewtable slot: holds, and nothing changes there. The slot isObjectGridSchema.omit(type, objectName).extend(OBJECT_VIEW_TABLE_WITHHELD). The withheld set already refusedshowFiltersby name (objectui#10976), and.extendoverrides the grid's tombstone, so the slot's message is byte-for-byte the same. No live read goes through the slot.ObjectViewreads only the node-levelschema.showFilters, andOBJECT_VIEW_TABLE_RELAY_KEYSdoes not carry it.@objectstack/spec17.5.0,ComponentPropsMap['object-grid']isObjectGridPropsSchema, which does not declareshowFilters. It refuses{ objectName, showFilters: true }withunrecognized_keys, while{ objectName }alone parses green.ListViewSchema.userActionsdeclaresfilter. The pin re-derives both facts.schema-reference.mdtable row that namesshowFilters(theshowSearch/showFilters/showCreaterow) is in theObjectViewSchematable, not the grid's, so it stays. TheObjectGridSchematable never listed the key. The card said its only producer was the doc example, which PR objectui#11130 removed. Two more in-repo producers turned up: the rootREADME.mdobject-gridexample and the 9729 ruler corpus. Both now omit the key. Theplugin-view.mdxandpackages/plugin-view/README.mdmentions are about the object view's own key and the table slot, and stay.Tests (head
b87cbca042, after mergingmainat1ccb5ba7de, which brought in PR objectui#11292)pnpm --filter @object-ui/types build && pnpm --filter @object-ui/types type-check && pnpm --filter @object-ui/plugin-grid type-check && pnpm --filter @object-ui/plugin-view type-checkgivesVERDICT command-exit 0. The types type-check runs three legs:tsc --noEmit,tsconfig.examples.jsonandtsconfig.test.json.pnpm exec vitest run packages/types/ examples/schema-catalog/givesTest Files 338 passed (338),Tests 9836 passed (9836).pnpm exec vitest run packages/plugin-grid/plus the ten other suites thatgit grep -l showFiltersfinds (app-shell ×3, core ×3, plugin-list ×1, plugin-view ×3) givesTest Files 187 passed (187),Tests 1959 passed (1959).@object-ui/plugin-viewdependency closure (turbo run build --filter='@object-ui/plugin-view^...' --concurrency=2: 15/15 tasks).Ablations ran on committed code (
181b9b615a) through objectstack'sscripts/ablation-replace.mjs, in WRAP mode. Each anchor went from x1 to x0, the blob changed, and the restore was proven (blob equals HEAD,git diff HEADempty). The tests readsrc, so there is nodistleg.objectql.ts,showFilters?: neverchanged toboolean.tsc -p tsconfig.test.jsonthen exits 2 withTS2578 Unused '@ts-expect-error'in the new pin, plusTS2322in thezod-mirror-paritytype ratchet.z.boolean().optional(). The new pin then reads5 failed / 13 passed, the same red as at base.Repo checks (at
b87cbca042):check-control-bytes: OK.new-cross-file-line-citations:VERDICT … 0 new citation(s).check-changeset-presence: "6 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)".changeset:check: nomajor.check:doc-types,check:doc-fences,check:doc-example-ids,docs:check-links,check:doc-example-readersandcheck:test-path-roots: all OK.check:component-surface-parity: report-only, and the report is identical before and after (noobject-gridrow either way).check:changeset-claims: report-only. The one falsified pending sentence is repaired as described above.check-governed-queue-guard --teston the 11 paths: NOT GOVERNED.NOT MEASURED:
check:doc-snippetsandcheck:doc-examplesexit 2 ("THE GATE COULD NOT RUN"): about 20 packages they import are unbuilt. This diff adds or changes nots/tsxfence line (counted: 0), and the only fenced edit is one line removed from ajsonfence inREADME.md. These are left to CI.pnpm lintis CI's to run.ObjectGridSchemaimporters (core, plugin-calendar, plugin-dashboard, plugin-designer, plugin-gantt, plugin-kanban, plugin-list, plugin-map, plugin-tree, console) is left to CI. A grep finds no typed writer ofshowFilterson anObjectGridSchemavalue. Every other writer targets anobject-view, alist-viewor a dashboard.Acceptance notes
object-viewtable slot refusestable.showFilterswith "ObjectGridhas no read of it". An author who wrote it probably meant the object view's ownshowFilters, whichObjectViewreads, and the message does not name it. This is polish to the wording of a refusal that is already loud. Carrier: none. Left as is, because the dispatch rules out widening or reworking that slot.operatorstombstone's comment inobjectql.zod.tsstill describes the objectui#9729 reading as "with the filter surface off AND on". That is a historical description of a measurement taken when the corpus carriedshowFilters, and it is left as written.keyboardNavigationis still declared onObjectGridSchemaand still unread. It is the card's remaining half.Session:
https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZGenerated by Claude Code