Repository navigation
feat(types,plugin-kanban,sdui-parser)!: retire quickAdd on object-kanban and stop forwarding it (objectui#8285) - #11231
Conversation
…anban and stop forwarding it (objectui#8285) Ruling B (decision batch #91): the board does not grow an inline record-creation write path. `@objectstack/spec` 17.5.0 already tombstones `ComponentPropsMap['object-kanban'].quickAdd`; this is objectui's half. - types: `ObjectKanbanSchema.quickAdd` is `?: never` on the TS face and a `retirementTombstone()` on the zod mirror, refused by name. - plugin-kanban: `ObjectKanban` no longer forwards `quickAdd` to the board, on every object-kanban entry point. `KanbanRenderer` keeps the pair for a React host that mounts it directly. - sdui-parser: the interim `inert-quick-add` diagnostic and its four exports are removed; the tier's own `unknown-prop` is accurate now that every face refuses the key. - The tripwire that stayed green after the spec retirement is rewritten: its helper read only `issue.keys`, which zod fills on `unrecognized_keys` issues, and a tombstone reports `invalid_type` at the key's path. Claude-Session: https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZ Co-authored-by: Claude <noreply@anthropic.com>
…ban-quickadd-retire
|
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: Inputs: card #8285 (body and all 13 comments, the ruling ① Derived judgmentsJudged against ruling B and the spec tombstone, not against the report's prose. At the tag,
Check-runs on the head (read twice; second read after the diff review): 30 ② Semver levelChangeset Prose, line by line: (i) "BREAKING — The earlier interim changeset
③ Boundary flagsDev deviations, each answered:
Out-of-scope findings: (i) objectstack's parser copy and its Nothing blocking found. The nine unconcluded check-runs are named in ① and are neither adopted nor pre-empted by this verdict. Implemented-by: VERDICT: PASS |
Fixes #8285
Clause-②: yes
objectui's half of ruling B (director seat, decision batch #91, comment 5583979207): "The board does not grow an inline record-creation write path",
object-kanban.quickAddis retired, and objectui stops forwarding it.@objectstack/spec17.5.0 (installed since objectui#11086) already carries the spec half as aretiredKey(...)tombstone. TheClause-②: yesline is copied from the claim (comment 5912959131): the published@object-ui/typesface narrows, and theinert-quick-addcode leaves@object-ui/sdui-parser's diagnostic payload.What changed
@object-ui/types:ObjectKanbanSchema.quickAddis now?: never(TypeScript face) andretirementTombstone(...)(zod mirror). An authored value is refused BY NAME (invalid_typeatquickAdd, with the remedy), not stripped. I used the existing tombstone helper; no new helper. TheonQuickAdddocblock is rewritten because this change made its old wording false. See the open question below.@object-ui/plugin-kanban:ObjectKanbanstops forwardingquickAdd. ItseffectiveSchemanow carriesquickAdd: undefined.KanbanRendereris byte-identical. TheOBJECT_KANBAN_INPUTSdocblock now records the retirement instead of the "PREMATURE" carve-out.@object-ui/sdui-parser: I deleted the interimkanban-quick-add.tsmodule, its wiring invalidate.tsand its four barrel exports. The references to the deleted symbol inbody-dialect.tsand its test are removed too.quickAddIsDiagnosedNotDropped-8285.test.tstoquickAddRetiredNotForwarded-8285.test.tsx. I rewrotekanban-quick-add-8285.test.tsfor the new state and addedobject-kanban-quick-add-retired-8285.test.ts. The 8801 and 8802 pins usedquickAdd: trueas a "live member" control, so it is removed from those lists.content/docs/plugins/plugin-kanban.mdxandcontent/docs/api/schema-reference.md. Both passages said the key "still parses" and that the tier answersinert-quick-add, and both are false after this change. Only prose changed; no fenced block moved..changeset/8285-object-kanban-quick-add-retired.md,minor×3 with BREAKING wording and a migration section. Per objectui's version rule, a breaking change isminor, nevermajor.The premises, measured (dispatch Zone 2)
node_modules/@objectstack/spec(17.5.0),ComponentPropsMap['object-kanban'].quickAddis aretiredKey(...). Parsing{ objectName, quickAdd: true }givessuccess=falsewith one issue:code=invalid_type,path=["quickAdd"],keys=undefined, and a message that starts "object-kanbanpropertyquickAddwas removed in @objectstack/spec 17 (ADR-0049)".quickAdd: falseis refused the same way. Controls on the same call:bogusPropgivesunrecognized_keyswithkeys=["bogusProp"], and{ objectName }alone givessuccess=true.refusedByNamecollectedissue.keys. zod fillskeysonly onunrecognized_keys. A tombstone declares the key asnever, so its refusal isinvalid_typeat the key's path with nokeys. The helper therefore returned[]whether the spec published the key or retired it. The row'sbogusPropcontrol is anunrecognized_keysissue, so it could not fail for the reason the row was meant to catch. On the base commit, the two 8285 files ran 18/18 green with the key already retired. The newrefusedByNamereads both shapes and has a control for each.object-kanbanis the onlyComponentRegistry.register(...)call forObjectKanbanRenderer.kanbanretired with objectui#8802 andkanban-uiwith objectui#8257, and both readhas() === falsein the new row 5.kanban-ui's Quick Add pair now lives on the exportedKanbanRenderercomponent, andObjectKanbanalso renders that component. So I cut the key upstream, inObjectKanban, where theschemathatKanbanRendererreads is built. Everyobject-kanbanentry point goes throughObjectKanban: the tag, the publishedkanbanComponents['object-kanban']map and a host mountingObjectKanbandirectly. Cutting only inObjectKanbanRenderer, the file the claim names, would have missed the map. The tombstone text namesKanbanRenderer, not akanban-uitag, because a document naming that tag is now anunknown-componenterror.retirementTombstone()is what thegroupFieldandallowCollapsemembers next to it use.validateTreeprobe over anobject-kanbanmanifest gives, with the module:quickAdd=trueproduceswarning / inert-quick-add, andquickAdd=falsefalls through towarning / unknown-prop("has no prop quickAdd"). Without it, both producewarning / unknown-prop, andcompile()staysok=true. That message is now true on every face: the spec, both@object-ui/typesfaces, the registry inputs and the renderer. On this tier it is also the whole remedy, because a constrained-JSX page cannot write the handler, so deleting the key is the only edit open to its author. The retiredbodydialect keeps its own replacement diagnostic for a different reason: it has a replacement spelling (children) to name.quickAddhas none. Severity is unchanged (warning), so no page that saves today stops saving.Measurements
All runs are at head
5218c1fa1a(this branch withmainmerged atdded788ada), and heavy ones went through the shared verify lock. Exit codes were captured before any pipe.turbo run build --filter='@object-ui/plugin-kanban^...' --concurrency=2, 12/12 tasks successful. This includes@object-ui/sdui-parser's owncheck-dist-completeness.pnpm --filter X type-checkgives exit 0 for@object-ui/types,@object-ui/plugin-kanbanand@object-ui/sdui-parser. All three new or rewritten test files are in thetsconfig.test.jsonprograms (--listFiles, 1 hit each), so the type-level pins really run.pnpm exec vitest run packages/plugin-kanban/ packages/sdui-parser/ packages/types/, plus a 16-file sweep. The sweep is the console registry↔spec ledger,public-contract, the handler-key and doc-type script tests, the schema-catalog corpora, and the cli validate, app-shell block-config, plugin-view and plugin-list consumers of theobject-kanbanarm, and the doc readers. Result: 391 files, 8375 tests passed, VERDICT command-exit 0.check-changeset-presence(15 source files of 3 released packages, 1 changeset),check-changeset-no-major,check:control-bytes,check:handler-key-reads,check:new-line-citations,check:phantom-deps,check:unused-deps,check:doc-types,check:doc-fences,check:changeset-claims,check:pending-changeset-literals,check:test-path-roots,check:unreferenced-sources,check:self-import,check:spec-symbols,check:installed-pin-claims,check:component-surface-parity,check:designer-field-key-parity. The governed-surface guard says NOT GOVERNED.**/*.{ts,tsx}blocks, and the count of 13 comes from--format json. The config enables no type-aware linting (noparserOptions.project, noprojectService), so this diff cannot move the verdict on any file it does not touch. Warnings on the four edited source files are identical to base, 31/23/34/1.check:doc-snippetsandcheck:doc-examplesexit 2 (PRECONDITION NOT MET, they need a broad build), but no fenced line changed in the docs diff (0 lines).check:sdui-registration-pinsandcheck:readme-exportsneed console and whole-tree builds and were not run. This diff adds or changes no registration, and no README names the four removed exports.Ablations, each done through
ablation-replace.mjswith an on-disk anchor count and blob-hash proof, and restored toblob == HEADwith an emptygit diff HEAD:quickAdd: undefinedcut. The renderer pin's row 1 goes red (expected [ button …, … ] to have a length of +0 but got 2, one control per lane). The other 4 rows stay green, row 2 included. That row is the control: the same query finds the host pair's control.quickAdd: trueliteral typedObjectKanbanSchema, planted in@object-ui/plugin-kanbanagainst the rebuilt@object-ui/typesdist, fails withTS2322: Type 'true' is not assignable to type 'undefined'. My first attempt was a no-op that the tool refused: the replacement contained the anchor, so the count did not drop and tsc never ran. I re-anchored it and ran it again.Open question:
onQuickAddonobject-kanban(not settled here)With
quickAddretired and no longer forwarded,ObjectKanbanSchema.onQuickAddstill reaches the board by identity; thehandlerKeyDispositionsMeasured-7804andkanban-handler-slots-7664pins still hold. But the board never calls it, because the control needs both halves. Retiring it too would need a?: nevertombstone and a'retired'disposition.check:handler-key-readsrefuses that while a renderer still reads the key off the document, and its static walk reachesKanbanRenderer'sschema.onQuickAddread throughObjectKanban. So the read on theObjectKanbanpath would first have to move offKanbanRenderer'sschema, without changing the host pair. The ruling namesquickAddonly, so I left the slot as it is and wrote the question into the card report.Cross-repo consequence (not filed)
objectstack keeps its own copy of this parser, and its
objectui-lockstep.jsonstill listsinert-quick-add, recorded against objectuidb11afd4967c. At objectstack's next.objectui-shabump,check:sdui-lockstepwill name that code as present on one side only, and their copy should drop it the same way. That is the lockstep working as designed, so I have noted it rather than filed it.Acceptance notes
index.tsx'sOBJECT_KANBAN_INPUTSdocblock still says "bothObjectKanbanRenderertags" in its heading. That has been stale since objectui#8802 and this change does not touch it. Noted, not fixed.Generated by Claude Code