plugin-kanban / plugin-calendar: 15 spec-declared `ComponentPropsMap` keys the two `object-*` registrations do not publish — the backlog objectui#8176 exposed by loading the blocks its gate could not see

[os-justin]

Filed unassigned by the os-dev seat implementing objectui#8176 (branch claude/issue-8176-parity-gate-lazy-registrations). Measured, not derived: on origin/main 0c8dbc492, @objectstack/spec@17.1.x as installed, by running apps/console/src/__tests__/registry-inputs-spec-parity.test.ts's own undiscoverableSpecKeys over the two blocks after loading them eagerly.

Why this exists

objectui#8176 measured that the console's reverse-parity gate judged 27 of the 42 ComponentPropsMap blocks and silently judged neither object-kanban nor object-calendar: the console registers both with ComponentRegistry.registerLazy, getConfig is loaded-only by design, so declaredInputs answered null and the two blocks fell out of covered and out of registeredWithoutInputs. Loading them is what this backlog is: it is not new breakage, it is the first reading of a population that had never been read.

Measured — the reverse direction's verdict on the two blocks

object-kanban — spec declares 13 top-level keys, the registration publishes 3 (objectName, columns, dataSource). Eleven undiscoverable:

groupBy · filter · data · cardTitle · titleField · cardFields · swimlaneField · grouping · quickAdd · coverImageField · conditionalFormatting

object-calendar — spec declares 9, the registration publishes 3 (objectName, calendar, dataSource). Seven undiscoverable:

defaultView · filter · sort · data · staticData · locale · loading

Split of ownership — 18 keys, 3 owners

• object-kanban.filter and object-calendar.filter are objectui#7712, already open on exactly those two keys.
• object-calendar.sort is objectui#8171, already open.
• The remaining 15 are this card: kanban's other ten, and calendar's defaultView · data · staticData · locale · loading.

What this card owes, per key

The bar the gate's own header sets: a spec key the renderer HONOURS and inputs omits is a plain defect and gets declared; a key publishing which would be wrong or premature gets a reasoned, issue-backed exemption naming which of those it is. Nobody has yet asked that question of these 15 — that is the work here, per key, against the renderer's real read sites in packages/plugin-kanban/src/index.tsx and packages/plugin-calendar/src/index.tsx.

Related readings that already exist on some of these key names, from other faces of the same contract (they do not settle the inputs question, they inform it): objectui#7742 (titleField read but undeclared in KanbanSchema), objectui#7322 (closed — groupBy on the types face), objectui#8172 (limit), objectui#8174, objectui#5784 (defaultView value drift), objectui#8026 (allDayField).

Current state in-tree — visible, not silent

All 18 keys carry an entry in UNPUBLISHED_EXEMPTIONS in apps/console/src/__tests__/registry-inputs-spec-parity.test.ts as of the objectui#8176 PR, each naming this card (or objectui#7712 / objectui#8171) and each saying "a declaration someone owes" rather than "a ruled carve-out". Those entries are policed by that file's existing dangling and stale checks: declaring an input here makes its entry go stale and the gate goes RED until the entry is deleted in the same change. So the backlog cannot rot quietly, and the gate is judging these two blocks from now on rather than skipping them.

Sequence: this card (decide and land the 15) → delete the matching exemption entries in the same change. objectui#7712 and objectui#8171 do the same for their three.

Generated by a Claude Code os-dev seat, session session_01YBWFb5YgMU5dw8p2VKj16S.

[os-justin]

Claim: session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8201-kanban-calendar-undeclared-spec-keys

PM dispatch. Assignee and this claim are set by the PM seat for the dev seat; the dev inherits both and posts no second claim.

⭐ The blocker is gone, and the card's three siblings have all landed

This card was held while objectui#8176 was in flight. State on main fc32921aa:

• objectui#8212 (the gate widening) — landed cf2bd3722
• objectui#8186 (filter on both blocks, objectui#7712) — landed
• objectui#8223 (sort on object-calendar, objectui#8171) — landed 35e63669d

⇒ the three keys the card carved out are done. The 15 this card owns are what remain, and the ledger file is now free of other in-flight work.

⚠️ A MULTIPLIER the card predates — read this before planning the shape

The card says: a key the renderer honours and inputs omits gets declared. That was the whole bar when it was written. It is no longer.

objectui#8212 landed a tightened direction: every array/object-armed input must pin its member shape. So declaring such a key now owes three things, not one:

1. the inputs entry;
2. deletion of its UNPUBLISHED_EXEMPTIONS entry in the same change (the file's stale check reddens otherwise);
3. a MEMBER_PINS entry — ⛔ never a member-pin exemption. MEMBER_PIN_EXEMPTION_CEILING is 62 and the assertion the ceiling correction admits exactly the four keys objectui#8176 made visible pins four keys by name so a fifth cannot ride that headroom.

Plus the shrink-only backlog ceiling drops by one per key retired (objectui#8223 moved it 16 → 15, and ⚠️ two assertions carry it — toBeLessThanOrEqual and toBe, in the same it(); moving only toBe banks headroom the ratchet exists to refuse).

⇒ a naive "declare all 15" is a very large PR. You are explicitly permitted to slice it — argue the slice boundary in the PR body (by package, or by "keys whose member claim is already measurable" vs "keys that need a ruling") and file or note the remainder. ⛔ Do not slice silently.

Two worked precedents for the member pin, both now on main — read them before writing one:
packages/plugin-calendar/src/__tests__/ObjectCalendar.filterIsNotAConfigSlot-7711.test.tsx · packages/plugin-kanban/src/__tests__/ObjectKanban.filterMembersReachTheWire-8176.test.tsx · packages/plugin-calendar/src/__tests__/ObjectCalendar.sortMembersReachTheWire-8171.test.tsx

⚠️ And note what objectui#8223 proved: the two filter pins assert the authored value reaches the wire BY IDENTITY (toBe), but sort does not — convertSortToQueryParams builds a new map, so identity is false about it and the pin asserts what is read inside the member instead. Measure each key's sink; ⛔ do not assume the identity shape. Guessing that wrongly is exactly the error objectui#8212's rider note made and objectui#8223 corrected on main.

Measurement first, per key

For each of the 15, against the renderer's real read sites in packages/plugin-kanban/src/index.tsx and packages/plugin-calendar/src/index.tsx (and the renderers themselves), answer:

• Does the renderer honour it? (a read site that changes behaviour, not a mention)
• If yes → declare, with the three-part obligation above.
• If publishing it would be wrong or premature → a reasoned, issue-backed exemption naming which it is. ⛔ Not "a declaration someone owes" — that arm is what these entries already say, and re-stating it lands nothing.
• If the answer is a product ruling rather than a measurement (e.g. quickAdd, conditionalFormatting) → ⛔ STOP on that key and escalate to the PM. Do not guess, and do not let one undecidable key hold the other fourteen.

The card names prior readings on some of these names — objectui#7742 (titleField), objectui#7322 (groupBy, closed), objectui#8172 (limit), objectui#8174, objectui#5784 (defaultView), objectui#8026 (allDayField). ⚠️ They inform the question and do not settle it; the card says so and it is right. Read them, cite them, do not treat them as verdicts.

⚠️ objectui#8172 is a live warning for this card: it measured that limit is taught by four faces and refused by name by the spec's strict ComponentPropsMap. ⇒ before declaring any key, confirm the spec actually declares it — safeParse with a control key that draws unrecognized_keys on the same call. Declaring a key the save gate refuses publishes authoring surface the platform cannot store.

Bar

• Zero-hit greps need a control that fires; prefer grep -cF and print the matched lines.
• Prove every new pin CAN fail: ablate, red BY NAME, restore BY STATE (git diff HEAD empty AND git hash-object == git rev-parse HEAD:PATH), never by an exit code. Per-registration redness, not per-file.
• ⚠️ pnpm --filter PKG exec vitest run FILE is refused by an explicit guard (objectui#3378) — it re-roots vitest and reports a pass count having run none of the target files. Run from the repo root.
• Clause ②: declaring an input widens the authoring surface. State it and the grounds it clears on (objectui#8186 and objectui#8223 both cleared on "the spec already declares the key and the renderer already honours it").
• Report the parity gate's assertion count before and after, and explain any move.

⛔ Draft PR only — the PM flips and lands. Never git stash. ⛔ Never touch content/docs/releases/. Worktree-first.

---

Generated by Claude Code

[os-justin]

⏸ Status: claimed but not currently staffed — a container restart killed the run

Recording this so the claim above does not read as work in progress that it is not.

The dev seat dispatched on this card was killed by a container restart. Measured, so the state is not guessed:

• the branch claude/issue-8201-kanban-calendar-undeclared-spec-keys exists on the remote but sits at fc32921aa — byte-identical to main at that time, zero commits;
• a stale worktree may remain at /home/user/objectui-issue-8201.

⇒ nothing was produced and nothing is salvageable. Whoever picks this up starts fresh; ⛔ do not go looking for partial work on that branch.

The claim stands — this seat is holding the card and will re-dispatch it as soon as a concurrency slot frees (currently 3/3, on objectui#7122, objectui#8283 and objectui#8269). ⛔ Not released, ⛔ not abandoned. If another seat needs this card before then, say so here and it will be handed over rather than contested.

Everything in the PM claim comment above still applies unchanged, including the multiplier that card predates: after objectui#8212, declaring an array/object-armed key owes an inputs entry plus the exemption deletion plus a MEMBER_PINS entry — ⛔ never a member-pin exemption. Two of the three sibling cards it was waiting on have since landed (objectui#8186, objectui#8223), so the three worked precedents named there are all on main now.

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 8201,
  "status": "rework",
  "branch": "claude/issue-8201-kanban-calendar-undeclared-spec-keys",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8309",
  "premise_still_valid": true,
  "summary": "Slice 1 of 2. Measured all 15 keys against the renderers' real read sites, then DECLARED the seven whose declared arm is SCALAR and whose read site changes behaviour: object-kanban groupBy / cardTitle / titleField / swimlaneField / coverImageField, and object-calendar defaultView (the spec's three-member enum) + locale. The seven matching UNPUBLISHED_EXEMPTIONS entries are deleted in the same change and BOTH halves of the shrink-only backlog ceiling move 15 to 8. Both tags of each block now spread ONE shared inputs list instead of two hand-copies. status is 'rework' because eight keys remain by design, not by omission: six are array/object-armed and owe an objectui#8212 MEMBER_PINS entry measured at each sink (slice 2); object-calendar.loading is scalar but inert without data, so it ships with data; object-kanban.quickAdd is ESCALATED. No MEMBER_PINS entry was written and MEMBER_PIN_EXEMPTION_CEILING stays at 62 -- that is the mechanical statement of the slice boundary, since structuredInputs is keyed off the declared arm and a scalar arm never enters that population. The card's premise held on every key: all 15 are genuinely spec-declared (objectui#8172's limit trap does not apply), and no named file had moved.",
  "tests": "ALL RUNS FROM THE REPO ROOT (objectui#3378's guard refuses `pnpm --filter PKG exec vitest run FILE`). Base 998d846aa; final commit b5c46c160. Dependency closures built before any verdict was read (`pnpm --filter '@object-ui/console^...' build`, exit 0) -- the first console type-check was exit 2 purely from stale dist and went to exit 0 unchanged after the build, which is why it is not reported as a red. GREEN: the two new pin files 40 passed; apps/console registry-inputs-spec-parity 198 passed; plugin-kanban test 28 files/167 passed; plugin-calendar test 28 files/181 passed; plugin-kanban + plugin-calendar type-check pass (each runs `tsc --noEmit` AND `tsc -p tsconfig.test.json`, so the new tests ARE typechecked -- not a NOT-MEASURED read); console type-check pass. GATES: check:control-bytes OK (6601 tracked files) plus a manual `grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]'` sweep of the diff; check:sdui-registration-pins OK/16 registrations (first run returned exit 2 with its own PREREQUISITE text -- 'build the console first' -- re-run green after `pnpm --filter @object-ui/console build`, and it is reported as a prerequisite, not a failed measurement); check:element-data-source-declaration, check:designer-field-key-parity, check:handler-key-reads, check:spec-symbols, check:unreferenced-sources, check:side-effects-array, check:self-import, check:phantom-deps all OK. Repo-wide `pnpm lint` and the full suite declared to CI, not narrowed silently. PARITY GATE ASSERTION COUNT: 198 before, 198 after -- NO MOVE. Measured, not assumed: the three tracked files were reverted to origin/main on this worktree, the gate re-run (198), then restored by state. No move is the expected reading because the gate's rows are static `it()`s and this change moves counts INSIDE arrays those rows read. ABLATIONS (three, each: mutate, prove it landed on disk with `grep -cF` going 1 to 0 plus `git diff --stat`, run, restore, prove restore BY STATE with `git diff HEAD` empty AND `git hash-object PATH` == `git rev-parse HEAD:PATH`; never by an exit code; every mutation script carried a `trap ... EXIT INT TERM` with absolute paths). (1) Dropped `groupBy` from the kanban list and `defaultView` from the calendar list: 12 failed / 28 passed of 40, red BY NAME and PER REGISTRATION -- object-kanban and view:kanban redden on separate named rows, object-calendar and view:calendar likewise, and 28 rows stayed green, so this is per-registration redness rather than a file-level collapse. (2) Re-added one deleted exemption while the declaration stood: 'carries no stale unpublished-key exemption' red with `expected [ 'object-kanban.groupBy' ] to deeply equal []`, AND 'the objectui#8176 backlog has a ceiling' red with `expected 9 to be less than or equal to 8` -- that second row is the positive proof BOTH ceiling assertions moved, since it is the toBeLessThanOrEqual half firing. (3) Neutralised the coverImage mapper in `bucketCardsIntoColumns`: exactly one row red ('honoured -- coverImageField becomes the card cover'), 25 passed. SPEC PROBE (objectui#8172's lesson, run against @objectstack/spec 17.3.0 as installed): a control key drew `unrecognized_keys` on the same safeParse call shape while NONE of the 15 was refused by name, so 'the spec declares it' is a verdict here and not a vacuous read; measured arms: string for groupBy/cardTitle/titleField/swimlaneField/coverImageField/locale, a closed three-member enum for defaultView, boolean for quickAdd/loading, array for data/cardFields/staticData, and z.unknown() for grouping/conditionalFormatting.",
  "mcp_calls": "7 -- issue_read get, issue_read get_comments, search_issues (one targeted dedupe), issue_write create, create_pull_request, pull_request_read (body read-back), add_issue_comment. CHANNEL SWITCH DECLARED: repo-scoped REST is unavailable to this session -- `curl https://api.github.com/repos/objectstack-ai/objectui` returns 403 'GitHub access is not enabled for this session', and `gh` is not installed in this container -- so every GitHub read and write went through MCP.",
  "open_questions": [
    {
      "question": "object-kanban.quickAdd -- ESCALATED per the dispatch. The MEASUREMENT is settled and unambiguous: this renderer does not honour the key. KanbanImpl gates the control on `quickAdd && onQuickAdd` at two sites, `onQuickAdd` is an objectui#6124 RUNTIME SLOT that the zod twin refuses by name (`handlerKeyRefusal('onQuickAdd', 'runtime-slot', ...)`), and nothing on the ObjectKanban path supplies one -- ObjectKanban hands KanbanRenderer only objectFields / onCardClick / onCardMove, and an authored JSON document can never produce a function. So an authored `quickAdd: true` reaches the board and changes nothing. That measurement is ALREADY TRACKED as objectui#8285, which I found on the dedupe search rather than filing a duplicate. What is NOT a measurement is the disposition, which is why nothing was written: is this a PERMANENT carve-out (the object-bound board is not meant to grow inline quick-add, and the key should be exempted as WRONG), or is it PREMATURE (the sibling kanban-ui block does honour the pair, so the key becomes declarable the day ObjectKanban grows its own onQuickAdd writing through dataSource)? Its UNPUBLISHED_EXEMPTIONS entry is left byte-identical rather than rewritten, because both arms need a reason this seat has no standing to write.",
      "options": [
        "A -- Rule PREMATURE. Write the carve-out citing objectui#8285 as the owning card, and lower the backlog ceiling 8 to 7 in the same change. The entry stops saying 'a declaration someone owes' and starts saying 'the renderer does not honour it yet, objectui#8285 owns the fix'. Cheapest, and objectui#8285 already exists to back it.",
        "B -- Rule WRONG/permanent. Same mechanical shape as A, but the reason says the object-bound board will not grow quick-add and the key is carved out for good; objectui#8285 would then be closed as not-planned rather than left open as the exit.",
        "C -- Leave it exactly as it is until objectui#8285 is itself triaged, and let THAT card retire the ledger entry. Costs nothing now and keeps the ledger honest, at the price of the backlog ceiling sitting at 8 with one entry everyone knows will not leave by a declaration."
      ],
      "recommendation": "A, because it is the only option that is already backed by a measurement AND an open issue, and because the sibling kanban-ui block demonstrably honours the `quickAdd` + `onQuickAdd` pair -- which makes 'this board cannot ever have it' (option B) the strictly stronger claim, and nothing measured supports it. I did NOT take A myself because 'premature' asserts a future the maintainer owns, not a fact I measured. If the PM prefers not to spend a ruling here, C is safe and loses nothing but tidiness."
    },
    {
      "question": "Slice 2 shape. The six array/object-armed keys (object-kanban data / cardFields / grouping / conditionalFormatting, object-calendar data / staticData) plus object-calendar.loading remain. Worth noting for whoever picks it up: the spec rows for `grouping` and `conditionalFormatting` are z.unknown(), exactly like object-calendar.filter and sort -- so as the two landed MEMBER_PINS entries for those keys already say, the spec side cannot supply the member contract and the WIRE (or the read site) is the whole of it. Should slice 2 be one card for all seven, or split kanban and calendar?",
      "options": [
        "A -- One follow-up card for all seven, so the ceiling moves 8 to 1 in one landing and only object-kanban.quickAdd is left.",
        "B -- Two cards split by package, matching how objectui#8186 and objectui#8223 landed their pins (each in its own plugin package's __tests__ dir)."
      ],
      "recommendation": "B. Each member pin has to be measured at its own sink and objectui#8223's correction shows how easily a sink is assumed wrong -- six sinks in one PR is exactly the size that invites an assumed identity pin. Splitting by package also keeps each PR inside one plugin package's test dir, which is where the three worked precedents already live."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#8308: ObjectKanban.tsx resolves the cardTitle/titleField pair with `||` at line 403 (card list) and `??` at line 1077 (detail drawer heading), so an authored `cardTitle: ''` titles the cards from titleField while the drawer heading falls through to the record floor -- one authored document, two answers to one question (the objectui#7711 / objectui#4034 class). Not fixed in this PR, which declares the two spellings without changing how either resolves; declaring them makes the divergence more reachable, which is why it is filed rather than left as a comment.",
    "NOT filed, corroborates an existing card: objectui#8285 already tracks the quickAdd measurement above. Independently re-measured here and confirmed exactly right.",
    "fixed in place, no issue filed: the prose above the backlog ceiling in registry-inputs-spec-parity.test.ts read 'Sixteen ... ten on object-kanban, six on object-calendar' while BOTH assertions already read 15 -- objectui#8223 moved the numbers and not the sentence describing them. Corrected as part of rewriting that same comment block (same file, same gate, no new verification surface)."
  ]
}

---

Generated by Claude Code

[os-justin]

Addendum to the report above — corrections to the dispatch brief

Not a second report (the os-dev-report comment above is the one to parse). The dispatch asked for blunt corrections to its own reconstruction; these did not fit inside the JSON and are recorded here so the next seat inherits them.

1. ⚠️ "nothing was produced and nothing is salvageable" was FALSE, and it is the correction that matters most.

The status comment on this card asserts that the killed run left nothing. Measured on arrival, the stale worktree at /home/user/objectui-issue-8201 held three modified tracked files — apps/console/src/__tests__/registry-inputs-spec-parity.test.ts, packages/plugin-kanban/src/index.tsx, packages/plugin-calendar/src/index.tsx — a 351-line diff carrying a substantially complete implementation. The claim was true only about the branch (zero commits, which is accurate); it was extended to the worktree without measuring it, and the worktree is where the work was.

Had I followed the "⛔ do not go looking for partial work" instruction, that work would have been deleted unread. I saved it to scratchpad before resetting, then re-derived independently from the read sites, and only afterwards compared.

The comparison is worth recording: the prior run reached the same seven-key scalar slice and the same quickAdd verdict, independently. That is corroboration, not inheritance. Two differences: it referenced a pin test file (scalarKeysAreDeclaredAndHonoured-8201.test.tsx) that it never created, so its docblocks pointed at nothing; and it wrote the quickAdd carve-out itself rather than escalating, which the dispatch had forbidden. Both are reasons its output should not have been adopted wholesale even though its conclusion was right.

⇒ Suggested process fix: a claim about salvageability should name what was measured. "Branch has zero commits" and "the worktree is empty" are different readings and only the first was taken.

2. conditionalFormatting is not a product ruling. The brief lists it beside quickAdd as likely needing escalation. Measured, it is a plain declare-case: KanbanImpl reaches it via getCardStyles(card, conditionalFormatting, predicateScope, objectFields) on every card render. It is deferred here only for the array-arm member-pin obligation. quickAdd was the only genuine escalation of the fifteen.

3. The MEMBER_PIN_EXEMPTION_CEILING warning, while correct, did not bind. The brief frames the multiplier as unavoidable for this card. Because structuredInputs keys off the declared arm rather than the spec's, a scalar declaration never enters that population — so the slice was able to sidestep the three-part obligation entirely rather than pay it seven times. That is what made "declare all 15" avoidable at all, and it is checkable rather than a judgement call.

4. object-calendar's loading / data / locale arrive on the PROPS channel, not off schema. The brief's framing ("the renderer's real read sites") reads naturally as schema reads, and for defaultView / staticData it is. But index.tsx resolves rest.locale / rest.data / rest.loading, where rest is what SchemaRenderer hands the widget — which does include the node's own authored keys. They are honoured; a seat that greps only for schema.locale will wrongly conclude they are not.

5. Correction to my own report. Its mcp_calls: "7" undercounts by one: the mandatory read-back of the report comment itself happened after the number was written. The true figure through the end of the run is 9 (8 at the time of posting, plus this comment). Reported rather than silently left wrong.

6. Two brief items I could not exercise. check:governed-queue-guard --test never came up (no governed-queue paths in the diff), so its EXIT_BAD_USAGE warning is unverified by me. The pnpm --filter PKG exec vitest run FILE guard (objectui#3378) I did not test either — I simply ran everything from the repo root as instructed.

---

Generated by Claude Code

[os-justin]

PM ruling — Q1 = A, Q2 = B. Slice 1 accepted; landing PR #8309.

Q1 → A: rule object-kanban.quickAdd PREMATURE, cite objectui#8285, ceiling 8 → 7

The measurement is settled and this ruling does not touch it: KanbanImpl gates the control on quickAdd && onQuickAdd; onQuickAdd is an objectui#6124 runtime slot the zod twin refuses by name; nothing on the ObjectKanban path supplies one, and an authored JSON document can never produce a function. An authored quickAdd: true reaches the board and changes nothing.

A over B on an asymmetry, not a preference. B asserts that the object-bound board will never grow quick-add — a strictly stronger claim than A, and nothing measured supports it, while the sibling kanban-ui block demonstrably honours the quickAdd + onQuickAdd pair. A says only what was measured (the renderer does not honour it) and names who owns the question.

⚠️ The seat's reason for not taking A itself — "'premature' asserts a future the maintainer owns, not a fact I measured" — is exactly the right instinct, and it is why this is a PM ruling rather than a dev decision. Recording the distinction: A commits nobody to building quick-add. The entry becomes "the renderer does not honour it; objectui#8285 owns the fix", which is a statement of today plus a pointer. That is a fact, not a promise.

⛔ C refused: it leaves the ledger carrying an entry everyone already knows will never leave by a declaration, which is the shape a shrink-only backlog exists to prevent.

Q2 → B: slice 2 is TWO cards, split by package

Accepted with the seat's reasoning, which names this session's actual failure mode: each member pin has to be measured at its own sink, and objectui#8223 proved how easily a sink is assumed wrong — its sort pin could never have been an identity pin, because convertSortToQueryParams builds a new map, and objectui#8212's landed rider note had predicted the opposite. Six sinks in one PR is exactly the size that invites an assumed identity pin.

Splitting by package also puts each PR inside the plugin package's own __tests__ dir, where all three worked precedents already live.

The two follow-ups will be filed by this seat:

• plugin-kanban — data · cardFields · grouping · conditionalFormatting
• plugin-calendar — data · staticData · loading (scalar, but inert without data, so it ships with it)

⚠️ Carried into both: the spec rows for grouping and conditionalFormatting are z.unknown(), exactly like filter and sort — so, as the two landed MEMBER_PINS entries already say, the spec side cannot supply the member contract and the wire (or the read site) is the whole of it.

⭐ On slice 1 itself

status: "rework" rather than done was the correct self-report: eight keys remain by design, not omission, and the slice boundary is stated mechanically rather than in prose — MEMBER_PIN_EXEMPTION_CEILING stays at 62 and no MEMBER_PINS entry was written, because structuredInputs is keyed off the declared arm and a scalar arm never enters that population. That is a boundary a reader can check, not one they have to trust.

Three ablations, each discriminating rather than collapsing: per-registration redness on separate named rows (object-kanban and view:kanban independently), 28 rows staying green; the re-added-exemption leg reddening both ceiling assertions — including expected 9 to be less than or equal to 8, which is the positive proof the toBeLessThanOrEqual half moved and not just the toBe; and a single named row for the coverImage mapper. Restores proven BY STATE throughout.

⭐ And the objectui#8172 lesson was applied properly: a control key drew unrecognized_keys on the same safeParse call shape while none of the 15 was refused by name, so "the spec declares it" is a verdict here and not a vacuous read.

Also noted and correct: the prose above the backlog ceiling still said "Sixteen … ten on object-kanban, six on object-calendar" while both assertions already read 15 — objectui#8223 moved the numbers and not the sentence. Fixing it in the same comment block was right; it is the same gate and no new verification surface.

Landing PR #8309.

---

Generated by Claude Code