Repository navigation
feat(types,plugin-kanban)!: object-kanban's conditionalFormatting takes the spec list view's { condition, style } rule only; the native and flat-colour dialects are refused by name (objectui#11522) - #11532
Conversation
…st view's { condition, style } rule only; the native and flat-colour rule dialects are refused by name (objectui#11522)
KanbanConditionalFormattingRuleSchema is the spec ListViewSchema rule element
by reference (.extend()), with the list view's own condition arm and the six
retired keys (field, operator, value, backgroundColor, borderColor, textColor)
as retirement tombstones. The TS twin extends SpecConditionalFormattingRule
with the same keys as `?: never`; KanbanNativeConditionalFormattingRule is
removed. The types pin is turned around to pin both refusals on all three
zod faces.
Claude-Session: https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPC
Co-authored-by: Claude <noreply@anthropic.com>
… { condition, style } rule; the kanban fixtures are respelled (objectui#11522)
The registry input description for conditionalFormatting no longer teaches
the native or flat-colour rule. The three plugin-kanban fixtures that authored
a retired dialect write the same predicate and paint as { condition, style }
and assert the same card is styled; a row pins that the whole style map
reaches the card. The schema-reference row, the console member-pin prose and
the one-authority test's note on the retired type name follow.
Claude-Session: https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPC
Co-authored-by: Claude <noreply@anthropic.com>
… on the two pending entries it makes false (objectui#11522) Claude-Session: https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPC Co-authored-by: Claude <noreply@anthropic.com>
… to { condition, style } (objectui#11522)
Claude-Session: https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPC
Co-authored-by: Claude <noreply@anthropic.com>
|
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 #11522 (body, comments Check-runs on the head: first read 2026-10-03T02:56:10Z, 42 runs, 37 ① Derived judgmentsAccept-set changes the diff implies, each judged against the head sources:
② Semver levelChangeset Clause-②: no (narrowing). RIGHT. Every face moves one way: two dialects refused, undeclared keys refused, nothing newly accepted; Pending sweep (read, not recalled). Of 2,695 entries, the readings this change makes false are exactly two, and both carry a dated, append-only note (
③ Boundary flags
Dev deviations: (1) Out-of-scope findings, each answered: (a) Boundary note, each item: Dev NOT MEASURED items: hotcrm, accepted on triage's own zero ( What the FAIL asks for, and nothing else: in Implemented-by: VERDICT: FAIL |
…ocus, a module export of src/zod/objectql.zod.ts that is not on the @object-ui/types/zod barrel (objectui#11522) The new changeset's @object-ui/types bullet and the dated note on the 7664 entry both placed the schema on `@object-ui/types/zod`. At this head that barrel does not re-export it and no `exports` entry carries it; the note now says so, and records that the 7664 bullet's own locus claim does not hold in this release either. Text only; no export added. Claude-Session: https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPC Co-authored-by: Claude <noreply@anthropic.com>
✅ 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: Round 2, re-review of round 1's record Check-runs on this head: first read 2026-10-03T03:15:20Z, 42 runs, 27 ① Derived judgments
② Semver level
Clause-②: no (narrowing), unchanged in the PR body, and a text-only commit widens nothing. RIGHT. The 7664 note stays append-only. The hunk is ③ Boundary flagsPatch report Carried from round 1, unchanged and not defects of this PR: escalation (b), the grid's native arm against objectstack main's by-reference typing, owed a Implemented-by: VERDICT: PASS |
…s the only authorable conditional-formatting rule on every list carrier (objectui#11534) (objectstack-ai#11595) Fixes objectstack-ai#11534 Clause-②: no One bullet of `skills/objectui/guides/schema-expressions.md` — the one under "CEL predicates over a row record" that opened with "Legacy shapes are translated, with a one-time warning." — is restated per the card's ruling (triage comment 5965309847, first branch; unlock comment 5966553335). Nothing else in the guide moves; no other file is touched. Governed surface (`skills/**`, the `skills-catalog` item of `GOVERNED_SURFACES`): this PR stays a DRAFT until an authorized APPROVED review is on it; the claiming seat lands it. The dev that drafted this does not flip it ready, enqueue it, or approve it. ## What the bullet says now - Authoring takes `{ condition, style }` only, on every list carrier (grid, list view, kanban). - The native `{ field, operator, value }` form and the `{ expression: "${…}" }` template form are retired, refused at the schema door by name with the respelling. - A STORED legacy rule still renders through the shared evaluator — a compatibility read, not an authoring form. - A `condition` string in legacy-only syntax still routes to the old engine with a one-time deprecation warning — a renderer-side fact that still holds and lives nowhere else, so it is kept. The old bullet's operator list and the `?.` marker went with the retired forms; the three facts above are the whole bullet. ## Reading one — premise verification on objectui `origin/main` `bdc9049` Cited by content (symbol names, test names, quoted message fragments), never by line address. **① Every list carrier's schema door refuses the native rule and the `{ expression }` rule.** Probed with `safeParse` on `ObjectKanbanSchema`, `ObjectGridSchema` and `ListViewSchema` (one `tsx` run against the `packages/types` source; the spec-shape `{ condition, style }` rule was the positive control and parsed on all three): | carrier | native `{ field, operator, value, backgroundColor }` | `{ expression, backgroundColor }` | control | |---|---|---|---| | `object-kanban` | refused at `field` / `operator` / `value` / `backgroundColor`: "belongs to the native kanban rule dialect … which `object-kanban`'s `conditionalFormatting` no longer accepts: RETIRED (objectui#11522), with no alias window. A rule is `{ condition, style }`" (`kanbanRuleKeyRetired`) | refused: "Unrecognized key(s) on this conditional formatting rule: `expression`. Did you mean `expression` → `condition`?" (the spec element's own strictness, inherited by `KanbanConditionalFormattingRuleSchema`) | success | | `object-grid` | refused at each key: "belongs to the native rule dialect … which `conditionalFormatting` on `object-grid` and `list-view` no longer accepts: RETIRED (objectui#11533), with no alias window" (`gridRuleKeyRetired`) | refused at `expression`: "`expression` is the template predicate of the native rule dialect … RETIRED (objectui#11533)" | success | | `list-view` | same `gridRuleKeyRetired` refusal (the member is `ConditionalFormattingRuleSchema`, one declaration shared by the two mirrors) | same named `expression` refusal | success | Pinned by the repository's own tests, run on this tree: `kanban-conditional-formatting.test.ts` ("refuses the native `{ field, operator, value, backgroundColor }` rule BY NAME, at each retired key"; "inherits the spec rule's strictness: an undeclared key is refused with the spec's own message") and `grid-list-view-conditional-formatting-11533.test.ts` ("refuses `expression` BY NAME, with the `condition` respelling"; "the grid's, the list view's and the named view's members all carry the one rule"). **② Stored legacy rules still render through the shared evaluator.** `resolveConditionalFormatting` in `@object-ui/core` (`listConditional.ts`) normalises a rule through `ruleToPredicate`: `condition` first, then a non-blank `expression` string, then `fieldOperatorValueToCel` for the native comparison — every arm kept, and the schema comment on both rules says so verbatim ("Stored stock is not authoring … keeps every arm as a compatibility read"). The legacy-dialect string route is `isLegacyDialectSource` + `warnLegacyDialect` (warn-once per source). Pinned by `listConditional.test.ts`: "native shape { field, operator, value } — translated to CEL", "native operators: not_equals / greater_than / less_than / contains / in", and under "legacy-dialect routing": "routes a `${…}` template string to the legacy engine and warns once". Test run (under the shared verification lock): the three files above — `Test Files 3 passed (3)` · `Tests 105 passed (105)` · `VERDICT command-exit 0`. The blocker is landed: objectui#11533 reached state completed when PR objectstack-ai#11540 merged to main; objectui#11522 (PR objectstack-ai#11532) is on main. No re-ruling away from retirement was found, so the ruling's first branch is what the bullet states. ## Reading two — the `skills/**` line readings | reading | before (`origin/main` `bdc9049`) | after (`fa1c5e7`) | |---|---|---| | the bullet | 7 lines | 8 lines (+1) | | `guides/schema-expressions.md` | 639 | 640 | | whole package, every `SKILL.md` under `skills/` (1 file) | 142 | 142 | | whole package, every `.md` under `skills/` (16 files) | 4811 | 4812 | | hits of "still work and are rewritten to CEL" in the guide | 1 | 0 | The dispatch's target was net zero against the old bullet's 7 lines; the restatement lands at +1 because it keeps the two compatibility facts the ruling asks for AND the still-true legacy-dialect-string fact, at 80 columns. No token gate exists for this catalog (objectui carries `check:skill-eval-tokens`, a must_contain oracle, not a line ceiling; green below). If the seat wants net zero, the last clause ("a `condition` in legacy-only syntax … write CEL.") is the one to drop, and the seat should say so rather than this PR guessing. ## Local gates (every exit code captured before any pipe) Green, exit 0, each verdict quoted from the gate's own last line: - `pnpm check:skills-paths` — ".claude/skills/ — 60/61 resolve across 4 file(s)" (the `skills/` root line above it also resolved) - `pnpm check:skill-eval-tokens` — "Every must_contain token is taught by its own skill bundle." · its `--self-test`: "29 cases pass" - `node scripts/check-doc-links.mjs` — "Links are valid across 17 scan roots." - `pnpm check:doc-fences` — "every TypeScript block in 227 document(s) is fenced ts/tsx/typescript" - `pnpm check:doc-example-ids` — "415 real reference(s) all resolve in the catalog registry." - `pnpm check:doc-types` — "Every documented component type is registered." · `pnpm check:prompt-keys` — "OK" - `node scripts/check-doc-expression-carriage.mjs` — exit 0 (census ran) - `node scripts/check-changeset-presence.mjs` — "No source or published contract of a released package changed in this range, so no changeset is owed." ⇒ no changeset file added - `pnpm check:changeset-claims` — exit 0 · `pnpm check:control-bytes` — "OK (scanned 10213 tracked text file(s))" - `node scripts/check-new-cross-file-line-citations.mjs` — "0 new citation(s)" - `node scripts/check-shell-escape-residue.mjs` — "OK (5/5 root(s) resolved … skills: 16 file(s), 211 fence(s)" - `pnpm check:pre-install-import-graph` — "OK" - `pnpm check:governed-queue-guard` (self-test) — "188 cases pass" · `node scripts/check-governed-queue-guard.mjs --test skills/objectui/guides/schema-expressions.md` — "⛔ GOVERNED — 1 of 1 path(s) … skills/** x1 — the published skills catalog" (exit 3, the expected answer for this PR) NOT MEASURED locally, declared narrowings (CI runs each with its scoped build): - `pnpm check:skill-examples` compiler leg — needs the 12-package closure its `--build-filter` names; the shared verification lock was never acquired in two 540-second waits (holder: the `issue-21465` gate run, `os-verify-lock.sh --status`). The gate judges MARKED fences only, and `check-skill-examples.mjs --list` names 0 candidate fences in `schema-expressions.md`; this diff edits prose inside one bullet and no fence anywhere, so the verdict is invariant to it. Its `--self-test` scanner leg ran; the compiler leg answered "PRECONDITION NOT MET (exit 2)" on the unbuilt tree, which is not a measurement. - `pnpm check:doc-snippets` and `pnpm check:doc-examples` — their population is `DOCS_ROOT = 'content/docs'`, `ROOT_PAGES = ['README.md']` and the package READMEs; `skills/**` is deliberately outside it (`check-doc-component-types.mjs` header: "not `skills/**`, not `docs/**`"), so this diff cannot move them. - `pnpm lint` — narrowed, three pieces at `fa1c5e7`: ① the population, read from `eslint.config.js`'s own `files:` globs, is `**/*.{ts,tsx}` plus a few named `.ts` files; ② `eslint --format json` on the touched file returns one result entry with `errorCount: 0` and the single message "File ignored because no matching configuration was supplied" — 0 files linted; ③ invariance: the config declares no `projectService` / `parserOptions.project` (0 matches), so no type-aware rule exists whose verdict on an untouched file a Markdown edit could move. - The `ci.yml` / `lint.yml` heavy steps skip on a Markdown-only diff by their own in-job switch; this PR is exactly that case. ## 维护者速读(草稿) **改了什么。** 只改 `skills/objectui/guides/schema-expressions.md` 里「CEL predicates over a row record」一节的一条 bullet:原来说原生 `{ field, operator, value }` 规则和 `{ expression }` 模板规则「仍然可用、会被透明改写成 CEL」,现在说:三个列表承载面(grid、list view、kanban)都只接受 `{ condition, style }` 作为可编写的条件格式规则,两种旧形式已退役、schema 门按名拒收并给出改写;已存储的旧规则仍经共享求值器渲染(兼容读,不是编写形式);带旧语法的 `condition` 字符串仍走旧引擎并一次性告警。净 +1 行(7 → 8)。 **为什么改。** objectui#11522(kanban,PR objectstack-ai#11532)与 objectui#11533(grid / list view,PR objectstack-ai#11540)落地后,指南这条与代码矛盾:照它写规则的作者或 AI 会被校验器拒收。分诊裁决定为「一次受管编辑,等 objectstack-ai#11533 落地后写最终事实」,objectstack-ai#11533 已落地,本 PR 按第一分支写。 **风险与代价(含回滚)。** 纯文档、单文件、不发版(changeset 门禁判「无需声明」)。风险只有措辞与代码不一致,已用 safeParse 探针和仓内 105 个 pin 测试按内容核对。回滚 = revert 这一个 commit。 **席位意见。** (留空,由席位定稿) **你要做的。** 在本 PR 上留一条 APPROVED review(受管面 `skills/**`,队列守卫要求 `os-zhuang` / `hotlong` 的批准记录),之后由席位翻 ready 并入队。 ## Acceptance notes - Observation, not filed: on `object-kanban` the `{ expression }` key is refused through the spec element's inherited strictness ("Unrecognized key(s) … Did you mean `expression` → `condition`?"), while `object-grid` / `list-view` carry a named `expression` tombstone (`gridRuleKeyRetired`). Both refusals are loud and both name the respelling, so the guide's "refused at the schema door by name with the respelling" holds on all three; the asymmetry is wording, not behaviour, and is below the filing bar. - Observation, not filed: the guide's bullet no longer lists the native operators (`equals` … `in`) or the `?.` legacy marker; the operator-to-CEL table now lives only in the refusal messages (`gridRuleKeyRetired` / `kanbanRuleKeyRetired`), which is where an author meets it. - Dispatch-prompt conflict noted per the dev contract: the prompt routed `pnpm install` through the shared verification lock; the contract lists install among the runs that do not take it. The contract was followed (install ran unlocked, 6.6 s); builds and the test run took the lock. - The dev's kept lock slot `issue-ui-11534` blocks nobody (a parked place, by the lock's own status text); it expires with this session. - Written by the objectui dev seat for session `session_01CB6W87z22K2yjUCDyVrJRk`; no model identifier appears in this PR, its commit or the guide. --- _Generated by [Claude Code](https://claude.ai/code/session_01CB6W87z22K2yjUCDyVrJRk)_ Co-authored-by: Claude <noreply@anthropic.com>
Fixes #11522
Clause-②: no (narrowing)
object-kanban'sconditionalFormattingtakes one rule dialect, the spec list view's{ condition, style }. The native{ field, operator, value, backgroundColor, borderColor }rule and the flat CEL rule (a colour written besideconditioninstead of insidestyle) are retired with no alias window and refused by name. This executes triage's ruling5963861071(retire, not widen). objectstack-ai/objectstack#21464 can then type the member by reference to its list-view member.What changes
object-kanban6903eafb){ condition, style }(string, envelope or''condition){ field, operator, value, backgroundColor }field,operator,valueandbackgroundColor, each naming the retirement{ condition, backgroundColor }invalid_unionat the rulebackgroundColor(named) andstyle(required){ condition, style, backgroundColor }style, aslistConditional.test.tspins); strict face refused it asinvalid_unionbackgroundColoron every face{ condition, style, label }unrecognized_keyswith the spec rule's own messageThe three faces are
ObjectKanbanSchema,safeValidateSchema(tolerant) andStrictAnyComponentSchema(strict). The before and after columns were read with a throwaway probe on each tree. The probe was deleted and never committed.@object-ui/types,zod/objectql.zod.ts).KanbanConditionalFormattingRuleSchemais the specListViewSchema.conditionalFormattingelement, taken throughstripImportedDefaultsand.extend()-ed. It is no longer a union. It inherits the spec rule's strictness and itsstylerecord. Two things are layered on top. First,conditionisSpecRuleConditionSchema, the list view's and the grid's own condition arm (objectui#10946), so a string condition is still not canonicalized and''is still accepted. Second, six retirement tombstones:field,operator,value,backgroundColor,borderColor,textColor.objectql.ts).KanbanConditionalFormattingRuleis an interface that extendsSpecConditionalFormattingRuleand declares the same six keys?: never.KanbanNativeConditionalFormattingRuleis deleted and dropped from the barrel (TS2305 for an importer). tsc reports a retired key by name (TS2322 at each key).@object-ui/plugin-kanban. The registration'sconditionalFormattingdescription no longer teaches the native or flat-colour rule.KanbanImpl's comments say what did and did not narrow. No render path changed: the description string is the only non-comment line.object-kanbanrow incontent/docs/api/schema-reference.mddocuments the one rule and its respelling.11522-kanban-rule-dialect-retired.md):typesandplugin-kanbanminor, with BREAKING and FROM/TO spelled out.Mechanism hypotheses, measured
H1, the census (writers of each retired dialect). The census used three instruments, and each one caught something the others missed. (1) Rule objects inside a
conditionalFormatting: [array. (2) Every object literal carrying a top-level colour key, classified by its other keys. (3) Every rule-shaped object within 400 characters after anyconditionalFormattingtoken, in any syntax, which catches tuples andkey:/value:rows. A fourth pass listed every{ field, operator }literal in files that mention bothconditionalFormattingandkanban. Each remaining hit was triaged by hand as a filter rule, a grid, list-view or report carrier, or a resolver unit test.object-kanbanat BASEpackages/types/src/__tests__/kanban-conditional-formatting.test.tspackages/types/src/__tests__/object-kanban-allow-collapse-retired-8801.test.ts{ condition: "record.status == 'open'", style: { backgroundColor: '#fee2e2' } }packages/plugin-kanban/src/__tests__/ObjectKanban.structuredMembersReachTheirSinks-8313.test.tsx{ condition: "record.owner == 'ann'", style: { backgroundColor: 'rgb(1, 2, 3)' } }and{ condition: "record.owner == 'bob'", style: { backgroundColor: 'rgb(4, 5, 6)' } }, plus one new row for the wholestylemappackages/plugin-kanban/src/__tests__/structuredKeysAreDeclaredAndHonoured-8313.test.ts{ condition: "record.owner == 'ann'", style: { backgroundColor: '#eef' } }packages/plugin-kanban/src/__tests__/objectFieldsIsAPropNotASchemaKey-7742.test.tsx{ condition: "record.owner == 'u1'", style: { backgroundColor: PAINT } }packages/plugin-kanban/src/index.tsx(registration description)content/docs/api/schema-reference.mdapps/console/src/__tests__/registry-inputs-spec-parity.test.ts(member-pin prose)examples/,apps/consolenon-test code,skills/object-kanbanin 4examples/files,kanbanin 9skills/files)examples/atf9a8eb88conditionalFormatting(app-showcasefield-zoo.view.ts) is{ condition, style }on a list view. Controls fire:kanbanhits inapp-crmviews, and{ field, operator, value }filter literals match the same matcherobjectstack-ai/hotcrmH2, by reference. The installed
@objectstack/spec17.5.0 exports no named rule schema. The rule is reachable asListViewSchema.shape.conditionalFormatting.unwrap().element, a strict object ofconditionandstyle. The zod twin.extend()s that element throughstripImportedDefaults. It does not override the condition with the bare spec slot, because the spec slot canonicalizes a string condition into an envelope and refuses''. The 10946 pins assert both behaviours onobject-kanban. The TS twin isSpecConditionalFormattingRule, which already indexesObjectListViewSchema's slot by reference. It is extended, not restated. A new pin assertsshape.styleis the spec element's ownstyle, by identity. Its control is thatshape.conditionis not the bare slot.H3, the refusal. With one arm, zod reports at the retired key's own path, and no
invalid_unionremains at the rule. The messages are identical onsafeValidateSchemaandStrictAnyComponentSchema. They are shown below, with backticks spelled as in the source:conditionalFormatting.N.field(and the same at.operatorand.value, with the key name swapped):conditionalFormatting.N.backgroundColor(borderColorandtextColorare the same;textColorsaysstyle: { color }):invalid_unionat.conditionandinvalid_typeat.style(both required), and a flat CEL rule drawsinvalid_typeat.style. An undeclared key draws the spec rule's ownunrecognized_keysmessage. Forexpressionthat message adds "Did you meanexpression→condition?".The
retirementTombstonehelper is the one used.aliasKeyRefusaldoes not fit: these keys are a retired dialect, not aliases of one canonical key.H4, the resolver. Every arm of
resolveConditionalFormattingstill has a live authorable carrier. This was measured on the builtsafeValidateSchemaandObjectGridSchema:object-gridnode (propertiesbag)ObjectGridSchema(viewtableslot / renderer props)object-viewtableslotlist-viewnodeobject-kanbannodecondition+styleexpressionfield/operator/valuebackgroundColor/textColor/borderColoroverridesNo arm has a measured zero carrier, so
listConditional.tsis untouched.H5, the render. A throwaway probe drew each rule through the real
SchemaRenderer→object-kanbanboard, and throughKanbanRendererwith and withoutobjectFields. It ran at BASE and again after the change. The two readings are byte-identical:Each respelling paints the card the retired rule painted, with the same style string. The respelled 8313 and 7742 rows pin this permanently through the real board, each with the live non-matching control.
The pins
kanban-conditional-formatting.test.ts(turned around). For each of the three faces, it pins: the{ condition, style }control; the native rule refused at each retired key, with the message starting with the key's name and containingRETIRED (objectui#11522)and{ condition, style }; the accepted rule at index 0 of the same document drawing no issue; the flat CEL rule refused atbackgroundColorwith thestyle: { backgroundColor }respelling and noinvalid_unionat the rule; and all three colour keys refused beside astyle. It also pins the identity ofstylewith the spec element (with its control) and the inherited strictness. On the TS face,@ts-expect-errorcovers each retired key,keyofequality holds between the two faces, andconditionandstyletypes are equal.spec-expression-wire-slots-10946.test.tsreadsconditionstraight off the rule's shape. There is no union arm left to index.zod-mirror-parity.test.ts: theKanbanConditionalFormattingRuleSchemaexclusion reason is rewritten. Its old reason ("a union of two rule dialects … the'kanban'arm") was false twice over. It stays an exclusion, compared where it is pinned, the wayExpressionWireSchemais.Pending changesets
10946-expression-wire-slots-by-reference.md. Its sentence "the list view's and the kanban board's rule unions share oneconditionschema" describes the kanban union.7664-kanban-arm-plugin-dialect.md. Its sentence "KanbanConditionalFormattingRuleSchemais … the rule union the'object-kanban'arm already applied" is now false.7664-plugin-kanban-declared-schema.md: says nothing about rules.8932-retire-kanban-enhanced.md: only namesKanbanConditionalFormattingRuleas the type to use, which still exists.8313-kanban-structured-authoring-keys.md: the key is still declared and honoured, and its description still states what the board reads.7727-conditional-formatting-record-scope.md: aboutrecord.*conditions.7928-listviews-by-reference-fold.md,9242-stray-kanban-groupby-lane-second-route.md: about named-view kanban config keys.8801-object-kanban-allow-collapse-retired.md:conditionalFormattingis still a live control key inplugin-kanban.7742-kanban-arm-batch70.md: aboutobjectFields.7322-object-kanban-group-by-limit.md: its "it now authorsgroupBy" remark about the kanban test still holds.6349,8165and8261: they name the one-authority gate, whose behaviour did not change; only its comments did.10275, names kanban only as a view binding.check:changeset-overwritereports the two modified entries with their declarations unchanged (types: minor), which is the appended-note case.Verification (head
6d3b4da0)pnpm exec vitest run --maxWorkers=2 packages/types/ packages/plugin-kanban/ apps/console/src/__tests__/registry-inputs-spec-parity.test.ts scripts/__tests__/one-authority-per-exported-name-6273.test.ts: 411 files, 9878 tests passed.VERDICT command-exit 0.pnpm --filter @object-ui/types run type-check(src, examples and test configs): exit 0. Before the types pin was turned around, the same check reported TS2322 at the four retired keys of its old native literal.pnpm --filter @object-ui/plugin-kanban run type-check: exit 0, afterpnpm --filter '@object-ui/plugin-kanban^...' build.turbo run build(35/35 tasks):check:doc-snippets: 777 of 777 blocks, 0 failed.check:doc-examples: exit 0.check:doc-types,check:readme-exports: OK.check:sdui-registration-pinsandcheck:component-surface-parity(report-only, no kanban row): both green.check:new-line-citations(0 new),check:control-bytes,check:changeset-claims,check:pending-changeset-literals,check:test-path-roots,check:spec-symbols,check:doc-fences,check-changeset-no-major,check-changeset-presence,check-changeset-fixed,check-doc-expression-carriage,check-type-check-coverage.main's spec; it belongs to CI). Specmaindeclares the rule with the samestrictObjecthelper and no refinements (read atf9a8eb88), so.extend()is expected to hold there. The repo-wide lint is also left to CI.Acceptance notes
ObjectView's kanban branch relays a named or active view'sconditionalFormatting, and objectui'sListViewSchemamember still declares the native rule ("broader than spec, migration deferred", per its own docblock). The generatedobject-kanbannode can therefore carry a rule the authoredobject-kanbancontract now refuses. It is never validated, which is the same shape as thegroupFieldnote in that branch. Carrier: none.main, the object-grid block is typed by reference to the list view (objectstack PR #21463, per the card). objectui's gridpropertiesbag andListViewSchemastill declare the native arm, and the installed 17.5.0 row isz.unknown()for bothobject-gridandobject-kanban. The grid's native arm meets the same disagreement on a spec bump. Carrier: none named.skills/objectui/guides/schema-expressions.mdlists "the native{ field, operator, value }form … still work" under renderer-side facts for "list/grid/kanban". That is true of the evaluator and no longer ofobject-kanbanauthoring.skills/**is governed, and this PR stays ungoverned, so it is left. Carrier: none.Session:
https://claude.ai/code/session_01XvhGmGAP79ZB8swnkapxPCGenerated by Claude Code