docs(plugin-kanban): stop naming which face declares which kanban key (objectui#9726)

.changeset/7322-object-kanban-component-props.md

@@ -36,8 +36,8 @@ block above.
 
 ## What settled it: the read set
 
-`ObjectKanban` reads thirteen keys off `schema`. Neither declaration covers them; the two
-TOGETHER cover twelve, and each arm is load-bearing:
+`ObjectKanban` reads more keys off `schema` than either declaration covered on its own —
+that read set is the bullet list below, and each arm is load-bearing:
 
 - `objectName`, `groupBy`, `limit`, `cardFields` — declared on both;
 - `columns`, `cardTitle`, `swimlaneField`, `grouping` — `KanbanSchema` only **as of
@@ -53,6 +53,21 @@ TOGETHER cover twelve, and each arm is load-bearing:
   `ObjectKanbanSchema` on 2026-09-09. Measured and reported, **not** changed here: this
   card moves the prop, not the two published schema faces.
 
+⏱ **Two cardinals removed on 2026-09-17 (objectui#9726), ⛔ not replaced with newer
+ones.** This paragraph read 「reads thirteen keys off `schema`」 and 「the two TOGETHER cover
+twelve」. Re-measured BY BINDING — property reads off the component's own `schema` prop, with
+`resolveKanbanTitleField`'s same-named parameter excluded by region — the read set is **14**
+today and was **14** at this entry's own measurement commit `6ca6e12a7`, because the bullets
+above omit `navigation`, which this entry's own 「Casts this removes」 section names as a read
+(`(schema as any).navigation` then, `schema.navigation` now). ⇒ 「thirteen」 was one short when
+it was written — **born false**, ⛔ not rotted afterwards, which is why it gets no row in
+the dated table above: that table records readings something LATER falsified, and nothing
+falsified this one, it arrived wrong. ⛔ The table's 「none was born false」 is a statement
+about those five rows, not about this cardinal. It is not restated as 14: a cardinal in an
+entry that publishes verbatim is derived once and then never again, and the bullets above
+already ARE the set. Which face declares each of them is `ObjectKanbanSchema`'s answer, and
+`tsc` already reads it.
+
 So naming `ObjectKanbanSchema` alone — the remedy the original card implied — would have
 been wrong in the other direction: it drops four declared reads and the `'kanban'`
 registration.

.changeset/9726-objectkanban-docblock-tense.md

@@ -0,0 +1,4 @@
+---
+---
+
+Comment-only repair in `@object-ui/plugin-kanban`: two `ObjectKanban.tsx` docblocks no longer state which published schema face declares which kanban key. That inventory had gone false for three of the five keys it named, and `tsc` already answers the question off `ObjectKanbanSchema`. No published behaviour changes and nothing is released by this entry.

packages/plugin-kanban/src/ObjectKanban.tsx

@@ -138,11 +138,17 @@ export function resolveKanbanCardFields(
 
 /**
  * The two spellings of the ONE card-title choice, as this board reads them off
- * a node. Structural on purpose: both declared arms of
- * {@link ObjectKanbanComponentProps.schema} satisfy it and neither declares
- * both keys — `KanbanSchema` declares `cardTitle` and tombstones `titleField`
- * (`titleField?: never`, objectui#7742), `ObjectKanbanSchema` declares
- * `titleField` and reaches `cardTitle` through `BaseSchema`'s index signature.
+ * a node. Structural on purpose: `resolveKanbanTitleField` below is exported
+ * and pure so it can be judged against a bare object, and these two keys are
+ * the whole of what it reads — it needs no node type to do that.
+ *
+ * ⛔ Do NOT restate here which published face declares which of the two keys.
+ * This docblock did (objectui#8308, 2026-09-10), naming TWO declared arms and
+ * an index-signature hop for `cardTitle`, and both halves were false inside
+ * eight days: objectui#8802 left ONE arm nine hours later, and objectui#9606
+ * declared `cardTitle` on that arm on 2026-09-17. The split is declared on
+ * `ObjectKanbanSchema` in `@object-ui/types` and `tsc` already reads it — ask
+ * the instrument, ⛔ never this comment (objectui#9726).
  */
 interface KanbanTitleFieldSource {
   /** Canonical spelling: the record field rendered as the card title. */
@@ -241,14 +247,24 @@ export interface ObjectKanbanComponentProps {
    *
    * ## What that costs, measured rather than waved past
    *
-   * `ObjectKanban` reads thirteen keys off `schema`. `ObjectKanbanSchema`
-   * declares `objectName`, `groupBy`, `limit`, `cardFields`, `titleField`; the
-   * retired arm was the only declaration of `columns`, `cardTitle`,
-   * `swimlaneField` and `grouping`. Those four now resolve through
-   * {@link BaseSchema}'s `[key: string]: any` — as `filter` always has, and as
-   * every one of them ALREADY did on an `object-kanban` document, which was
-   * never judged by the `kanban` arm. ⇒ No `object-kanban` node changes
-   * meaning; what changed is that `kanban` nodes no longer exist.
+   * Nothing, for an `object-kanban` document. Such a node was never judged by
+   * the `kanban` arm, so every key this component reads off `schema` that
+   * `ObjectKanbanSchema` does not declare reached the renderer through
+   * {@link BaseSchema}'s `[key: string]: any` BEFORE the retirement and still
+   * does. ⇒ No `object-kanban` node changes meaning; what changed is that
+   * `kanban` nodes no longer exist.
+   *
+   * ⛔ WHICH keys those are is deliberately not listed here, and neither is
+   * how many there are. This paragraph listed both (objectui#8802,
+   * 2026-09-10) and the list was stale in hours: `filter` had been a declared
+   * member for a day when the list put it on the index signature
+   * (objectui#8174), `columns` joined it six hours after the list was written
+   * (objectui#8913), and `cardTitle` a week after that (objectui#9606) —
+   * leaving `swimlaneField` and `grouping` as the only two it still fits. A
+   * source comment is the surface a changeset sentence gets copied FROM, so an
+   * inventory here is a factory for the same rot one step downstream. Read the
+   * split off `ObjectKanbanSchema`, which `tsc` already judges
+   * (objectui#9726).
    *
    * `__tests__/object-kanban-component-props-7322.test.ts` derives the
    * registered key set from `index.tsx` off disk and goes red if the prop and
@@ -1094,9 +1110,14 @@ export const ObjectKanban: React.FC<ObjectKanbanComponentProps> = ({
   // precedent objectui#5903). That arm RETIRED with the bare `kanban` node key
   // (objectui#8802), and the surviving `ObjectKanbanSchema` face never declared
   // the key — so on an `object-kanban` document this read has ALWAYS ridden
-  // `BaseSchema`'s `[key: string]: any`, exactly as `filter` does. ⛔ Nothing
-  // about an `object-kanban` board changed here; what went is the only face
-  // that ever declared the key, and it only ever judged `kanban` documents.
+  // `BaseSchema`'s `[key: string]: any`. ⛔ This line used to name a companion
+  // key here — 「exactly as `filter` does」 — and that comparison was false
+  // when it was written: `filter` had been a declared member of
+  // `ObjectKanbanSchema` for 26 hours by then (objectui#8174). Ask
+  // `ObjectKanbanSchema` about any other key, ⛔ never a neighbouring comment
+  // (objectui#9726). ⛔ Nothing about an `object-kanban` board changed here;
+  // what went is the only face that ever declared the key, and it only ever
+  // judged `kanban` documents.
   // The designer face still declares it — `OBJECT_KANBAN_INPUTS` (`index.tsx`).
   // Reported on the retirement PR as a follow-up for the `object-kanban` face.
   const navConfig = schema.navigation ?? { mode: 'drawer' };