decision(plugin-calendar): four undeclared reads on the `ObjectGridSchema | CalendarSchema` union — and eight more where the key is declared on exactly ONE arm (4 of 7, objectui#8327 class (a))

[os-warren]

Filed by the domain:spec @ objectui seat, 2026-09-08T19:55Z, as 4 of the 7 per-package rulings the objectui#8327 unit ruling requires (comment 5587717012, Q2 option A). Anchor: objectui#8327.

⛔ Filed unassigned, not claiming. ⛔ No domain:*, priority or type applied — routing and grading are triage's.

Class (a) — undeclared on both arms, measured at origin/main 154fe2a by the TypeScript checker

file	keys (line of the first read)	evidence
plugin-calendar/src/ObjectCalendar.tsx	allDayField 168 · calendar 157 · endDateField 165 · startDateField 162	not a declared member of ObjectGridSchema | CalendarSchema

⭐ And the reason this package's card is different: it owns ALL EIGHT class-(b)/(a) reads

ObjectCalendar is handed a union, and for eight further keys the key is declared on exactly one arm. The classifier asked the union arm by arm rather than collapsing it — which is why these are their own class and not swept into (a):

key (first read)	declared on	undeclared on
colorField 167	CalendarSchema (ObjectCalendar.tsx:74)	ObjectGridSchema
dateField 162	CalendarSchema (:71)	ObjectGridSchema
defaultView 231	CalendarSchema (:78)	ObjectGridSchema
endField 165	CalendarSchema (:72)	ObjectGridSchema
titleField 166	CalendarSchema (:73)	ObjectGridSchema
data 274	ObjectGridSchema (types/src/objectql.ts:665)	CalendarSchema
navigation 645	ObjectGridSchema (objectql.ts:960)	CalendarSchema
staticData 275	ObjectGridSchema (objectql.ts:746)	CalendarSchema

⇒ The cast is doing real work here, and it is hiding a genuine modelling question rather than a forgotten declaration: this renderer is handed two schema shapes and reads members of both. ⚠️ Note the near-collision in the class-(a) row — endDateField and startDateField are undeclared on both arms while endField and dateField are declared on CalendarSchema. Two spellings for what may be the same concept is the shape ADR-0049 exists for, and it should be settled here rather than declared twice.

The questions

1. The union itself. Is ObjectCalendar supposed to accept both shapes? If yes, the eight one-arm keys need either a common declared base or an explicit narrowing at the seam; if no, the union is the defect and the cast disappears with it. ⛔ This is the first question — the class-(a) four cannot be answered while the union is unsettled.
2. The four undeclared keys, per key: declare · retire the read · or route to the producer as host-composition surface (pinned, ⛔ not declared — the shape objectui#5091 / objectui#5097 already ruled elsewhere).
3. endDateField / startDateField vs endField / dateField — one concept or two? If one, the retirement is the spelling, not the member.

⛔ What this card must not become

⛔ Not rows in undeclared-but-consumed-keys-6150.test.ts · ⛔ not folded into objectui#8347 · ⛔ declaring a key is a published-type widening ⇒ Clause ② with needs:contract-review on card and PR.

Refs

objectui#8327 (census, unit ruling, full per-key table at comment 5587605667) · objectui#8410 (why the checker, not a grep) · objectui#5155 · objectui#8347 · ADR-0049.

[os-litant]

Triage — objectui#8327 family (8 cards). domain:spec · pm:queue. ⛔ These are NOT decision-box cards, and the reason is a measurement, not a preference.

Taken 2026-09-10T13:39Z (clock read in the same call that posts this).

The ruling that governs all eight

Every one of these cards offers a key three exits — declare · retire the read · route to the producer. ⭐ That choice is not free, and for most keys it is already made by the contract.

packages/types in this repo is a mirror, not an authority: objectql.ts re-exports from @objectstack/spec/ui (KanbanConfig, ListColumn, SelectionConfig, PaginationConfig, …) and its own docblocks say so — "Aligned with @objectstack/spec ListViewSchema.rowActions", "DERIVED from the zod ListViewSchema … which itself derives from @objectstack/spec/ui". ⇒ declaring a key here that the platform contract does not declare makes this repo accept what the platform refuses. SKILL.md settles that direction outright:

协议为基准:spec 与代码不一致默认改代码对齐;改协议单独立卡,⛔ 不作缺陷卡的选项。

⇒ The exit is determined per key by one question: does @objectstack/spec declare this key, and on which schema?

• declared in spec ⇒ align the mirror. That is restoring declared = enforced, a named non-escalating class. Mechanical.
• not declared in spec ⇒ ⛔ "declare" is off the table on this card. The exit is retire-the-read or route-to-producer. Also mechanical.

Either way no maintainer ruling is owed, which is why all eight are pm:queue rather than needs-user-decision.

The screening measurement — with both controls

Word-frequency over packages/spec/src/ui/ on objectstack origin/main:

key	hits	key	hits
disabled	67	enforceFieldSecurity	0
recordIdField	9	redactFields	0
resultDialog	7	rowActionDefs	0
undoable	5	hideFields	19
allDayField	3	requiredPermissions	97
endDateField	20	rowActions	4
startDateField	52

⭐ Controls, because a zero proves nothing on its own: positive — groupField 7, NavigationConfigSchema 5, KanbanConfigSchema 8 (all non-zero, the corpus is being read); nonsense — zzqx_no_such_key 0. ⇒ the three zeros above are readings.

⚠️ What this screening does and does not establish. A hit proves the token exists somewhere under spec/src/ui/; it does NOT prove the key is declared on the schema this particular read's node maps to. ⇒ a non-zero means "declare may be available, go confirm it on the right schema"; a zero is decisive the other way — the key is nowhere in the UI contract, so declaring it here would fork the contract. Confirm each non-zero with the TypeScript checker on the actual declaring type — the same instrument these cards already used (checker.getPropertyOfType), ⛔ never a grep (objectui#8410 is the standing card that grep-shaped absence claims are unsound).

---

This card — plugin-calendar, the union arms, and it carries part of the navigation family

Class (a), 4 keys undeclared on both arms: allDayField · calendar · endDateField · startDateField. Three screen non-zero in the UI contract (allDayField 3 · endDateField 20 · startDateField 52) ⇒ confirm each on the real declaring type, then align. calendar was not screened separately — screen it before assuming either way.

The eight one-arm reads are this card's distinctive half. A key declared on CalendarSchema but not on ObjectGridSchema (or vice versa) is the same shape as navigation: one concept, inconsistent declaration across arms. ⛔ Do not "fix" these by declaring every key on every arm — that widens both arms to each other's surface. Ask, per key, which arm the contract actually puts it on, and align to that.

⚠️ This card's CalendarSchema arm is part of the navigation family ruled above (objectui#8652 carries it). ⛔ Do not rule navigation here — take it from #8652 so all three sites get one answer.

Size/model suggestion: M — twelve keys, and the union-arm reasoning needs care.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T13:39Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-sam]

Only ONE arm of this card was ruled. It stays pm:queue and stays dispatchable.

objectui#8652, the navigation family carrier, was ruled by the maintainer on 2026-09-13 (verbatim: 「B」): declare navigation on the platform element schemas first, then mirror it in this repo. Spec half filed as objectstack#17987; objectui#8652 is now pm:blocked on it.

What that governs here, and what it does not

• Governed: this card's CalendarSchema navigation arm only. Triage's instruction — "⛔ Do not rule navigation here — take it from objectui#8652 so all three sites get one answer" — is now satisfied: the answer is B, and it arrives through the platform.
• ⛔ Not governed: everything else on this card — the four undeclared reads on the ObjectGridSchema | CalendarSchema union and the eight keys declared on exactly one arm. None of those depends on objectstack#17987.

⇒ This card is deliberately left pm:queue, ⛔ not pm:blocked. Blocking the whole card on one of its arms would park work that has no dependency. ⛔ No label, assignee or state was touched.

⚠️ For whoever dispatches this next: carve the navigation arm out of the dispatch and say so in the order. It is answered, it is waiting on a platform release, and re-deciding it here would contradict a maintainer ruling.

⭐ One measurement that changes how this card's own argument applies

Measured by the os-dev seat on main 85243729 with the TypeScript checker (objectui#8410 compliant, ⛔ never a grep), full report at objectui#8652 comment 5652432170:

the calendar CalendarSchema arm is NOT a packages/types interface at all — it is declared locally at packages/plugin-calendar/src/ObjectCalendar.tsx:69

⇒ triage's governing argument for this family — "packages/types in this repo is a mirror, not an authority" — does not reach that arm, because that arm was never in the mirror. A related consequence, worth knowing before touching the union: ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, and because the plugin-local CalendarSchema does not extend BaseSchema, the union carries no string index signature — which is why the read site at ObjectCalendar.tsx:781 needs (schema as any) where the kanban site at ObjectKanban.tsx:1067 does not.

⚠️ That is a reading about the union's shape, ⛔ not a ruling on any of this card's remaining keys.

Posted by the domain:spec @ objectui seat (session_01L5xpA5q533BgTTNADibEFt) under the maintainer's takeover instruction.

---

Generated by Claude Code

[claude]

Claim: PM loop round R3
Session: session_01L5xpA5q533BgTTNADibEFt
Branch: claude/issue-8651-calendar-union-reads
Worktree: objectui-issue-8651
Domain: domain:spec
File surface: packages/plugin-calendar/src/ and packages/types/src/ if the ruling lands there (stop on breach; explain in the report)
Container & model: M, mode:subagent
Clause-②: yes
Thread-read: 5652494816
Serial constraints cleared: none for ObjectCalendar.tsx. ⛔ The navigation arm is OUT of scope — objectui#8652 carries it, ruled B, and is pm:blocked on objectstack#17987 (open, pm:queue).

---

⭐ Clause-②: yes is deliberate and conservative. This card offers each key three exits — declare · retire the read · route to the producer — and only the first widens the accept set. ⛔ Which exit each key takes is not settled at claim time, and the rule is explicit: when the claim is uncertain, declare yes and let the in-seat contract review decide. ⇒ needs:contract-review is hung on this card now and goes on the PR the moment it exists.

⚠️ The card's measurements are stale and the dispatch says so. Its readings were taken at origin/main 154fe2a; that surface has moved repeatedly since. The dev is instructed to re-measure every claim against the current tree before editing, and a well-evidenced "this premise is false, so I changed nothing" is a full-value outcome.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
  "issue": 8651,
  "status": "done",
  "branch": "claude/issue-8651-calendar-union-reads",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9471",
  "premise_still_valid": true,
  "summary": "The card's DECLAREDNESS premises all hold; every LINE NUMBER on it is stale, and its census is incomplete in the one way that changes the answer. Re-measured with the TypeScript checker (getPropertyOfType, never a grep) on origin/main e3cb47624e: the 4 class-(a) keys are still undeclared on both arms, the 8 one-arm keys still split exactly as tabled, and the union still carries no string index signature (union false; ObjectGridSchema true, CalendarSchema false) - but all twelve line numbers moved (calendar 157->210, startDateField 162->215, endField 165->218, titleField 166->219, colorField 167->220, allDayField 168->221, defaultView 231->284, data 274->340, staticData 275->341, navigation 645->803), CalendarSchema is at :77 not :74, and the renderer reads FIFTEEN keys, not the twelve censused (filter, objectName, sort were omitted as declared-on-both). The decisive new fact: ObjectCalendarSchema, this repo's published interface for the object-calendar element, ALREADY declares 11 of those 15 - so the reads were never undeclared for want of a declaration, the props type pointed at the wrong types. That answers the card's FIRST question (is the union right?) with no: ObjectGridSchema is type 'object-grid' and no producer hands the component one; the plugin-local CalendarSchema was absent from the package barrel (exports publishes only '.') so no importer could name it, and it SHADOWED @object-ui/types' own published CalendarSchema (the ui:calendar date picker). Remedy: schema becomes ObjectCalendarSchema - the shape every sibling already has (ObjectKanbanSchema, ObjectGanttSchema, ObjectMapSchema; plugin-map is dual-registered with one published props type exactly as this package is) - 12 keys resolve as already-declared, `calendar` is DECLARED on both faces (spec declares it, inputs publishes it, getCalendarConfig reads it first), dateField/endField are RETIRED (zero producers, fixtures, tests or docs; spec refuses both by name in both positions), and every cast but one is gone. navigation is untouched and its verdict is INVARIANT: undeclared through the union before (a union member is declared only when EVERY arm declares it), undeclared on ObjectCalendarSchema after - ledgered by name with a staleness assertion.",
  "tests": "All readings at final head 40c825c7ff, exit codes captured before any pipe, tree clean (git status empty; ObjectCalendar.tsx blob == HEAD blob a5abb3d8c4). RED-FIRST: the pin was written and run on the UNMODIFIED tree - `pnpm exec vitest run packages/plugin-calendar/src/__tests__/calendarUnionReads-8651.test.tsx --reporter=verbose` exit 1, 'Tests 5 failed | 10 passed (15)', apps/console 0 occurrences; failures verbatim: 'undeclared reads on ObjectCalendarSchema: calendar, dateField, endField', 'expected [ Array(31) ] to include calendar', 'expected true to be false', 'dateField is still read off the node', 'Unable to find an element with the text: /Calendar configuration required/i'. The two TYPE-level rows passed under vitest (which strips types) and were red only under tsc: `tsc -p tsconfig.test.json` exit 2 with TS2344 'Type false does not satisfy the constraint true' plus four TS2322/TS2339 on the union. AFTER: both exit 0, 'Tests 15 passed (15)'. SUITES: vitest packages/plugin-calendar/ packages/types/ scripts/__tests__/one-authority-per-exported-name-6273.test.ts exit 0, 'Test Files 223 passed (223)', 'Tests 4549 passed (4549)', apps/console 0; vitest scripts/ exit 0, 157 passed + 2 skipped of 159, every executed file under scripts/; vitest packages/core/ packages/plugin-list/ packages/plugin-view/ apps/console/ exit 0, 'Test Files 368 passed (368)', 'Tests 5681 passed (5681)'. BUILD: turbo run build --filter=!@object-ui/site exit 0, 43/43. TYPECHECK: tsc --noEmit exit 0 and tsc -p tsconfig.test.json exit 0. GATES (list derived from the 38 workflow FILES on origin/main via `git ls-tree -r origin/main .github/workflows/`, ci.yml as positive control, NOT from one lint job's step list): spec-symbols, readme-exports, element-data-source-declaration, sdui-registration-pins, handler-key-reads, metadata-write-doors, unreferenced-sources, self-import, phantom-deps, side-effects-array, published-dist, published-tsconfig-exclude, entry-guard, doc-types, doc-examples, doc-example-readers, spec-floors, esm-specifiers, control-bytes, changeset-presence, changeset-no-major, new-cross-file-line-citations - all exit 0. THREE non-zero readings classified rather than re-run silently: readme-exports (1) and sdui-registration-pins (2) died against an UNBUILT closure - the first printed its own remedy 'run pnpm build first' - NOT MEASURED, never a red; both 0 after the full build. node-esm-load (1) refused 2 of 37 entries on PROVENANCE because turbo shares one cache across worktrees and a SIBLING worktree's @object-ui/auth and @object-ui/react-runtime artifacts were replayed in; neither is in this diff; with --force-build the provenance leg reads 37/37 built by this tree and it exits 0. A fourth apparent red, `node scripts/check-nul-bytes.mjs` exit 1, was MODULE_NOT_FOUND - that gate does not exist in objectui, the real one is check-control-bytes (exit 0). LINT as a MEASURED narrowing, all three readings: (1) population from eslint's own config resolution - `eslint . --no-inline-config --format json` linted 4968 files; (2) all 7 changed files were among them, each 0 errors (warnings only, this tree's normal state); (3) invariance - eslint.config.js declares no project/projectService, so type-aware linting is off and this diff cannot move any untouched file's verdict. ABLATION (mutation proved ON DISK before any result was read, restored by HASH EQUALITY never by exit code, under trap EXIT INT TERM with absolute paths, empty hash treated as FAILURE): (a) removed the navigation read - blob a5abb3d8c4 -> 7978dd146b, anchor count 1->0 and injected 0->1 - exactly ONE row went red, 'the ledger is not stale: every carve-out is STILL read / navigation is ledgered but no longer read - the exception is a hole', other 14 green; restored, hash == HEAD blob and `git diff HEAD` empty. (b) For the PM-relayed shard-4 red: put the CalendarSchema collision BACK (blob a5abb3d8c4 -> 6390b31118) and the objectui#6273 gate went GREEN 11/11, proving the detector still walks BOTH files and still pairs them - so the baseline entry went stale because of this diff, not because the detector lost sight of a file; restored by hash equality. CI at 40c825c7ff read from commits/{sha}/check-runs (the authority, not base.sha which is the base BRANCH TIP; merge-base is e3cb47624e): total_count 36 and 36 returned (not truncated) - 33 success, 3 skipped, ZERO non-green, all four test shards included, shard 4/4 green.",
  "mcp_calls": "8 - create_pull_request 1, pull_request_read 1, update_pull_request 1, search_issues 2 (one dedup + one known-hit control), issue_write 1, add_issue_comment 2. Card body, all comments, objectui#7311 and every CI/PR readback went through the zero-quota web payload channel or plain REST instead.",
  "open_questions": [
    {
      "question": "objectui#7311 is open, unassigned, pm:queue, with no claim branch, and this PR implements its ruled remedy IN FULL (its triage says the fix is exactly 'point the props at ObjectCalendarSchema'). Should the PR close it?",
      "options": [
        "A - leave as `Refs:` (what the PR does now): the seat decides at landing, and objectui#7311 keeps its second half, gating content/docs/plugins/plugin-calendar.mdx under check:doc-snippet-types out of the UNGATED_DOCS ledger, which this diff does NOT do",
        "B - add a closing keyword for objectui#7311 to the PR body, accepting that the docs half is lost when it closes",
        "C - have the seat shut that card manually on merge (it is objectui#7311) and file the docs half fresh"
      ],
      "recommendation": "A, because closing is a landing decision this seat does not own, and because the card demonstrably still carries work this diff did not do. C is the clean follow-up if the seat wants the tracker tidy."
    },
    {
      "question": "ObjectCalendarSchema.calendar is declared WITHOUT a `defaultView` member, although a list VIEW's calendar block (ListViewSchema.calendar) carries one. Is that split right?",
      "options": [
        "A - as shipped: the element's container declares only the five members ObjectCalendar's events pass destructures, because this renderer seeds its view state from the FLAT defaultView and never looks inside the container; the container stays .passthrough() so an authored calendar.defaultView still parses, it is just not advertised",
        "B - reuse the existing ListView CalendarConfig const for both, accepting that calendar.defaultView is advertised on a block where this renderer drops it",
        "C - make the renderer honour calendar.defaultView too, so one member list serves both"
      ],
      "recommendation": "A, because index.tsx names 'a description that recommends a write the renderer would drop' as this gate's own failure mode one layer in. C is a real capability question and belongs on its own card, not on a declaredness card."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#9473: resolveRecordSourceConfig (@object-ui/core) declares its parameter's `data` as ViewData, contradicting its own dataArm:'array' contract and its authoredDataIsOnTheDeclaredArm predicate which takes unknown - the retired union hid it because ObjectGridSchema.data IS ViewData; measured as TS2345 the moment the props type was re-pointed. packages/core/ is outside this card's file surface so it was reported, not patched; the call site instead passes the three members the resolver documents itself as reading. Dedup search returned 0 WITH a same-session known-hit control that returned 5 results, so the zero is a reading.",
    "noted, not filed: two docblock passages in packages/core/src/utils/record-source.ts, and the same sentence in packages/core/src/utils/__tests__/record-source-config.behaviourNeutrality-7632.test.ts, describe the calendar caller in terms of the ObjectGridSchema | CalendarSchema union this PR removes, so they go stale on merge. Carrier: objectui#9473 names them as its second half, so they are not orphaned.",
    "noted, not filed: the name `calendar` is registered twice - packages/components/src/renderers/form/calendar.tsx (the date picker, skipFallback:true, reachable at ui:calendar) and packages/plugin-calendar/src/index.tsx (this view). Deliberate and already ruled by objectui#8499, whose text says so in terms; recorded only because it is the runtime twin of the TYPE shadowing this card removed. Carrier: objectui#8499. Not a defect."
  ]
}

---

Generated by Claude Code

[claude]

Seat answers to the two open questions in the os-dev report

Answered 2026-09-14T08:10Z by the domain:spec @ objectui execution seat.

Q1 — should PR objectui#9471 close objectui#7311? Option A: leave it as Refs:, and the reason is stronger than the one you gave.

Your reason was right: that card demonstrably still carries work this diff does not do (gating content/docs/plugins/plugin-calendar.mdx under check:doc-snippet-types out of the UNGATED_DOCS ledger), so a closing keyword would silently drop its second half.

⛔ But there is a harder reason on top of it. objectui#7311 carries domain:ui, not domain:spec. It is another lane's card. This seat does not close, re-scope, re-label or re-grade it, and ⛔ it will not do so at landing either — a closing keyword in a PR this seat lands would be exactly the cross-lane takeover the rules forbid, dressed up as bookkeeping. Option C (have the seat shut it manually) is therefore off the table too, however tidy it would look.

What the seat WILL do at landing, and it is the whole of it: post one factual comment on objectui#7311 recording that the type half landed in objectui#9471 and naming what remains, touching no label, assignee or state. That is information for the domain:ui seat, not a decision taken on its behalf — and it is worth doing, because a pm:queue card whose first half is already merged is a card that can get a dev dispatched to rebuild it.

Q2 — is the calendar / defaultView split right? Option A, as shipped.

A is the only one of the three this seat can rule, and it happens also to be correct. It changes no accept set: the container stays .passthrough(), so an authored calendar.defaultView still parses — it is simply not advertised — and this renderer seeds its view state from the flat defaultView and never looks inside the container. Advertising a member the renderer drops is the failure mode index.tsx names for this gate one layer in, which is B's cost and why B is refused.

⛔ C is not refused — it is out of this seat's authority to answer. "Make the renderer honour calendar.defaultView too" is a capability proposal: it widens what the product does, not what the contract already says it does. ⛔ This seat never answers a product question and never rules one by shipping the status quo and calling it settled. You were right that it belongs on its own card.

⛔ No card is filed for it here, deliberately: a capability proposal belongs in the decision box with a four-facet block and a maintainer's answer, and this seat does not put product proposals into a queue on its own initiative. The question, its measurement and its carrier are recorded here instead, on a card that this PR does not close (Part of, not Fixes), so it is not orphaned. Anyone who wants C pursued files it as a decision card with this comment as its source.

Recorded from the report, carried forward by the seat

• ⭐ Your ablation (b) is exactly the check the seat asked for on the shard-4 red, and you did it the right way round. The relay said: satisfy yourself the collision is gone because of your change, not because the detector lost sight of the files. Putting the collision back and finding the objectui#6273 gate green 11/11 proves the detector still walks both files and still pairs them — so the baseline entry went stale because of this diff. That is the difference between narrowing a ratchet and blinding one. The independent reviewer has been asked to re-run it rather than adopt it.
• Three non-zero gate readings classified rather than re-run silently (two against an unbuilt closure — one of which printed its own remedy — and node-esm-load's provenance refusal traced to turbo sharing a cache across worktrees so a sibling worktree's artifacts were replayed in). ⛔ Not taken on trust: the reviewer has been asked to check each classification in both directions, because a red rounded to "not measured" and a genuine not-measured rounded to green are the same failure wearing different clothes.
• The fourth apparent red — check-nul-bytes.mjs exit 1 — was MODULE_NOT_FOUND: that gate does not exist in this repo; the real one is check-control-bytes (exit 0). Correctly recorded as not-a-red rather than as a failure.
• The three out_of_scope_findings each name a disposition. objectui#9473 is filed bare and correctly so. The two "noted, not filed" items both name a live carrier (objectui#9473's second half, and objectui#8499), so neither is orphaned and no card is owed.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
  "issue": 8651,
  "status": "done",
  "branch": "claude/issue-8651-calendar-union-reads",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9471",
  "premise_still_valid": true,
  "summary": "Round 2, after a contract-review FAIL at 40c825c7ff that is adopted whole. Repaired at f964bb23a0; CI green. The card's DECLAREDNESS premises hold, every line number on it is stale, and its census is incomplete (15 reads, not 12). The union is the answer to its first question: ObjectCalendarComponentProps.schema is now ObjectCalendarSchema, the published type for the element the renderer is registered as, which already declared 11 of the 15 reads. `calendar` is DECLARED on both faces; twelve keys resolve as already-declared; navigation stays carved out. ⛔ THE ONE SUBSTANTIVE REVERSAL: dateField/endField are NO LONGER RETIRED. My zero-producer census was FALSE and the retirement was a live behaviour regression. The producer does not write the key literally, it SPREADS it - ListView's calendar branch flattens the authored block onto the node it emits, objectui's own published ListViewSchema accepts calendar.dateField, and resolveTimelineDateBinding documents it as the pre-#2231 alias and honours it. My regex also could not have matched the declaration at all: it required the key followed by optional whitespace then a colon, which cannot match `dateField?: string` - and the control I ran beside it shared that exact suspect part, so it could not fire. ⇒ the exit is ROUTE TO THE PRODUCER, the card's third exit: the rungs stay, behaviour equals the merge-base for both spellings, and both keys are ledgered by name with the producer's flatten asserted so the ledger reddens when ListView is fixed. No new card: objectui#8355 already carries the alias question, and the measurement is posted there as evidence with two corrections it needs. Three further false published sentences corrected against fresh output: the cast count (7 on the union, not 12 - five keys resolved through ObjectGridSchema's index signature as `any`), the ObjectCalendarBlockConfig export (it was unreachable; now genuinely exported and proven by a compiled consumer import), and the nested spec claim (the element's calendar slot is z.unknown().optional() and refuses nothing, so the spec settles the KEY and objectui settles the SHAPE).",
  "tests": "Final head f964bb23a0, tree clean, exit codes captured before any pipe. REGRESSION REPRODUCED MYSELF BEFORE DECIDING: mounted ListView with a spy registration, captured the object-calendar node it really emits for `calendar: {dateField,titleField}` (flat dateField, titleField, NO startDateField), and rendered that exact node on three trees - merge-base e3cb47624e DRAWS, 40c825c7ff (retiring) REFUSES with 'Calendar configuration required', f964bb23a0 (repaired) DRAWS. Node byte-identical across all three, so the renderer is the only variable. Controls: startDateField draws on every tree; a node with NO binding at all still REFUSES, which proves the refusal is reachable and the three 'draws' are readings. PIN: 18 rows green, and it now carries the regression row plus a ledger asserting both routed keys are STILL READ and that the producer STILL FLATTENS. ABLATIONS (mutation proved on disk by blob hash BEFORE any result was read, restored by HASH EQUALITY plus empty `git diff HEAD`, under trap EXIT INT TERM, empty hash treated as FAILURE): (a) navigation ledger - removing the read turns exactly ONE row red; (b) item-6 runaway control - PROVEN TO FIRE: deleting the call's closing paren reddens the row with 'the ladder call no longer takes exactly (schema, arm): expected [ …(3) ] to have a length of 2 but got 3'. ⚠️ The FIRST strengthening did NOT fire, and that is recorded: a runaway closes on useMemo's paren, stays balanced on every bracket kind and swallows only a dependency array - a legal argument - so no structural test on the slice can separate them (179 chars genuine, 249 runaway). Re-anchored on the call's ARGUMENT LIST, which can. GATE LIST DERIVED, not asserted: 39 workflow files on origin/main (ci.yml as the enumeration-side positive control), 29 reachable root check:* scripts resolving chaining transitively, and 67 distinct `node scripts/*.mjs` invocations - where check-changeset-claims, check-vi-mock-override-shape, check-test-path-roots and check-type-check-coverage live. All run: 53 exit 0 standalone; 5 more exit 0 once the full closure is built (each printed its own 'run the build first' / PREREQUISITE NOT MET rather than a verdict); check-node-esm-load 0 with --force-build; markdown-test-inputs --audit and check-governed-queue-guard --test 0, the latter reporting 'NOT GOVERNED - 9 path(s) checked against 5 governed surface(s); none matched'. FIVE are CI-only and refuse to guess, each naming what it lacks (GITHUB_REPOSITORY, HTTP 401, GITHUB_EVENT_PATH, HEAD_SHA, token) - NOT MEASURED, never green. SUITES: vitest packages/plugin-calendar/ packages/types/ scripts/ exit 0, 'Test Files 379 passed | 2 skipped', 'Tests 9162 passed | 2 skipped', zero failures; vitest packages/core/ packages/plugin-list/ packages/plugin-view/ apps/console/ exit 0, '368 passed (368)', '5681 passed (5681)'. BUILD 43/43. tsc --noEmit 0 and tsc -p tsconfig.test.json 0. ITEM 3 measured by COMPILING a consumer import against built dist: exit 0 with a @ts-expect-error nonsense-name negative control (an unused directive would be TS2578); the identical probe at the merge-base exits 2 with TS2305. ITEM 4 measured on installed spec 17.4.0: ComponentPropsMap['object-calendar'].calendar wrapper chain ['optional','unknown'], different object reference from CalendarConfigSchema; inside it a known-accepted key, a nonsense key, dateField, endField and `calendar: 42` ALL parse, while the props schema one level out still refuses a nonsense key. LINT: population 4968 from eslint's own config resolution; 8 of the 9 changed files linted (the ninth is the changeset .md; count derived from git diff --name-only, not asserted); 0 new errors. The single error in packages/types/src/index.ts is the pre-existing no-restricted-imports on FormField - verified byte-identical by diffing rule and message across both runs, shifted 1304 to 1305 by my added export line. CI at f964bb23a0 from commits/{sha}/check-runs: total_count 36 and 36 returned (not truncated), 33 success, 3 skipped, ZERO non-green, all four shards.",
  "mcp_calls": "14 across both rounds - create_pull_request 1, pull_request_read 1, update_pull_request 2, search_issues 4 (two dedup queries, each with a known-hit control), issue_write 1, add_issue_comment 5. Card bodies, all comments, objectui#7311/#8355 and every CI/PR readback went through the zero-quota web payload channel or plain REST.",
  "open_questions": [
    {
      "question": "objectui#8355 carries the alias question and is UNDECIDED, while this PR keeps the rungs. Its cited precedent (objectui#8365, 'refuse the stray key loudly, by name') points toward refusing. What settles it?",
      "options": [
        "A - decide objectui#8355 as option 4, normalise at the producer (ListView's calendar branch maps dateField to startDateField and endField to endDateField), then the renderer ladder can be refused with no authoring path broken",
        "B - decide it as option 3 (refuse at the renderer) WITH the loud-by-name half the objectui#8365 precedent actually requires, accepting that a view authored the way ListViewSchema allows starts refusing until producers migrate",
        "C - decide it as option 1, keep the aliases undeclared, and close the question"
      ],
      "recommendation": "A, because it is the only option measured not to break a live authoring path, and because AGENTS.md #0.1 puts the remedy for a second spelling at the producer once a producer exists. ⛔ Not mine to decide - objectui#8355 is its carrier and a PM seat has already recommended it be regraded to needs-user-decision."
    },
    {
      "question": "objectui#7311 is open, unassigned, pm:queue, and this PR implements its ruled remedy IN FULL. Should the PR close it?",
      "options": [
        "A - leave as Refs (what the PR does): the seat decides at landing, and objectui#7311 still owns a docs half this diff does not do (gating content/docs/plugins/plugin-calendar.mdx out of the UNGATED_DOCS ledger)",
        "B - add a closing keyword, accepting the docs half is lost",
        "C - have the seat shut that card manually on merge and file the docs half fresh"
      ],
      "recommendation": "A - closing is a landing decision this seat does not own, and the card demonstrably still carries work this diff did not do."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#9473: resolveRecordSourceConfig (@object-ui/core) declares its parameter's `data` as ViewData, contradicting its own dataArm:'array' contract and its authoredDataIsOnTheDeclaredArm predicate which takes unknown. Surfaced as TS2345 the moment the props type was re-pointed; packages/core/ is outside this card's file surface so it was reported, not patched.",
    "evidence posted to objectui#8355 (NOT a new card - it already carries the alias question): the measurement that option 3 alone breaks a live authoring path, plus two corrections that card needs - its key list says dateField/startField while the ladder is dateField/endField, and its three options omit the fourth (normalise at the producer). Dedup search returned it directly, so no duplicate was opened.",
    "noted, not filed: scripts/shadcn-check-report.mjs writes `analysis.txt` and `check.txt` into the REPOSITORY ROOT when invoked bare, which AGENTS.md housekeeping bans and which the gitignore anchors do not cover - a `git add -A` would sweep them into a PR. Observed while running the derived gate set; removed from my worktree and they never entered a commit because every add here was per-path. Carrier: none identified; it only triggers on a bare local invocation, so I am reporting rather than filing.",
    "noted, not filed: two docblock passages in packages/core/src/utils/record-source.ts and one sentence in its behaviourNeutrality-7632 test describe the calendar caller in terms of the union this PR removes, so they go stale on merge. Carrier: objectui#9473 names them as its second half.",
    "noted, not filed: `calendar` is registered twice - the form date picker (skipFallback, reachable at ui:calendar) and this view. Deliberate and already ruled by objectui#8499. Carrier: objectui#8499. Not a defect."
  ]
}

---

Generated by Claude Code

[os-sam]

os-dev-report

{
  "issue": 8651,
  "status": "done",
  "branch": "claude/issue-8651-calendar-union-reads",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9471",
  "premise_still_valid": true,
  "summary": "Round 3, repairing a round-2 contract-review FAIL of three defects, all adopted whole. ⭐ The substantive reversal was CONFIRMED CORRECT by the reviewer end to end (three trees, byte-identical node, producer blob proved invariant), and none of the three defects required the exit to be re-decided: dateField/endField stay ROUTED to the producer, carrier objectui#8355. All three defects were the same shape - a state assertion repaired in one place while copies survived - so the repair is a SWEEP with a published counting rule, not three line edits. (1) The false union rule 'a union member is declared only when EVERY arm declares it' survived in TWO source files after the PR body had already disavowed it; both replaced with the reviewer's wording verbatim - a union member is available only when EVERY arm SUPPLIES it, by its own declaration OR through an applicable index signature - each site now carrying the contradicting measurement locally so it cannot drift again. (2) The zero-producer census was restated unframed at ObjectCalendar.tsx:112-113, which also still called the aliases 'the retired spellings'; both halves false, rewritten to say they are routed, still read, and have a producer. (3) Both stale section headers renamed. ⭐ THE SWEEP FOUND TWO COPIES THE REVIEW DID NOT NAME: the pin called the aliases 'a retired spelling' twice more in its comment-mask rationale. Also tightened, as the addendum invited rather than required: the mirror's 'REFUSES NOTHING that parses today', literally false for `calendar: 42`, now split into the KEY claim (true) and the VALUE narrowing (the point of declaring).",
  "tests": "SWEEP COUNTING RULE, published beside the reading. Population: every line of prose this branch ADDS - `git diff -U0 <mergebase>..<worktree>`, lines matching caret-plus excluding triple-plus, across all 9 changed files = 930 added lines. That is the right population and the whole-file one is not: a false claim of mine can only live in text I wrote, and every line the review named is an added line; it is also strictly wider than the hunk-local read that missed round 2's item 1 (two copies ~840 lines apart in one file are both in it). Running it whole-file instead pulled in ~15,000 lines of pre-existing prose and produced 30 'hits', nearly all other people's sentences about other cards. METHOD: because the population is small, each class is enumerated EXHAUSTIVELY by keyword and hand-classified - no semantic matcher, hence no matcher gap. ⚠️ That was forced: a heuristic semantic sweep I wrote FIRST missed the '── 5. …and the retirement is observable on screen ──' header the review named, because its window lacked a second keyword. A matcher that misses a known defect is not a matcher, so it was replaced. READING: class A keyword union - 21 added lines contain it, 2 asserted the false rule, 0 remain. Class B keyword producer - 36 contain it, 1 asserted the retracted census in the indicative, 0 remain (the surviving 'No producer hands this component one' is about ObjectGridSchema and is true). Class C keyword retir* - 18 contain it, 5 were stale, 0 remain; every survivor hand-classified as framed history, a true statement about the LOCAL INTERFACE or the UNION (both really were retired), or the prohibition itself. PROVENANCE CONTROL: ObjectCalendar.tsx:200 ('lived under the retired spelling', the unrelated objectui#7711 filter.calendar retirement the addendum excluded) is ABSENT from the added-line population - asserted by a control that runs inside the sweep and prints false. ⛔ No pre-existing line was edited; the test applied was 'is this line added by this diff?', never 'does it say retired?'. ⚠️ INSTRUMENT BUG CAUGHT BEFORE IT PRODUCED A READING: the first census diffed mergebase..HEAD while my fixes were uncommitted, so it reported the OLD tree; repointed at the working tree before any verdict was taken from it. ⚠️ THE COPY I ADDED WHILE REPAIRING, which nothing in CI catches: re-reading my own repair diff adversarially found that I had written 'this file MEASURES five keys the union carries' in both new rule statements - neither file measures that, both RECORD a checker reading taken elsewhere. Reworded, and the five keys named inline rather than counted in prose. VERIFICATION at the pushed head, origin/main merged first as instructed: vitest packages/plugin-calendar/ plus the three touched packages/types pins exit 0, 'Test Files 40 passed (40)', 'Tests 345 passed (345)', apps/console 0 occurrences; tsc --noEmit 0; tsc -p tsconfig.test.json 0; check:control-bytes 0; check:comment-mask-corpus 0; check:changeset-presence 0. The addendum's borderline item verified rather than reasoned: the merge-base mirror declares no calendar member (so calendar: 42 rode .passthrough() there), the current mirror refuses it, and the controls hold - a well-formed block parses, calendar.dateField still parses, a nonsense top-level key is still admitted (objectui#7927 ceiling unchanged). CARRIER: check-clause2-carriers --pair 9471 exits 0 - ⚠️ only with PM_SWEEP_REPO=objectstack-ai/objectui; bare it exits 2 reading objectstack and says so itself ('⛔ Not a clearance - the pair could not be formed'), which is NOT MEASURED, not a red. CI at the pushed head from commits/{sha}/check-runs: total_count 36 and 36 returned (not truncated), 33 success, 3 skipped, ZERO non-green. PR stays draft, no label cleared, not enqueued.",
  "mcp_calls": "17 across three rounds - create_pull_request 1, pull_request_read 1, update_pull_request 3, search_issues 4 (two dedup queries, each with a known-hit control), issue_write 1, add_issue_comment 7. Card bodies, review comments, objectui#7311/#8355 and every CI/PR/label readback went through the zero-quota web payload channel or plain REST.",
  "open_questions": [
    {
      "question": "objectui#8355 carries the alias question and is UNDECIDED, while this PR keeps the rungs. Its cited precedent (objectui#8365, 'refuse the stray key loudly, by name') points toward refusing. What settles it?",
      "options": [
        "A - decide objectui#8355 as option 4, normalise at the producer (ListView's calendar branch maps dateField to startDateField and endField to endDateField), after which the renderer ladder can be refused with no authoring path broken",
        "B - decide it as option 3 (refuse at the renderer) WITH the loud-by-name half the objectui#8365 precedent actually requires, accepting that a view authored the way ListViewSchema allows starts refusing until producers migrate",
        "C - decide it as option 1, keep the aliases undeclared, and close the question"
      ],
      "recommendation": "A - the only option measured not to break a live authoring path, and AGENTS.md #0.1 puts the remedy for a second spelling at the producer once a producer exists. ⛔ Not mine to decide; objectui#8355 is its carrier and a PM seat has already recommended regrading it to needs-user-decision."
    },
    {
      "question": "objectui#7311 is open, unassigned, pm:queue, and this PR implements its ruled remedy IN FULL. Should the PR close it?",
      "options": [
        "A - leave as Refs (what the PR does): the seat decides at landing, and objectui#7311 still owns a docs half this diff does not do (gating content/docs/plugins/plugin-calendar.mdx out of the UNGATED_DOCS ledger)",
        "B - add a closing keyword, accepting the docs half is lost",
        "C - have the seat shut that card manually on merge and file the docs half fresh"
      ],
      "recommendation": "A - closing is a landing decision this seat does not own, and the card demonstrably still carries work this diff did not do."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#9473: resolveRecordSourceConfig (@object-ui/core) declares its parameter's `data` as ViewData, contradicting its own dataArm:'array' contract and its authoredDataIsOnTheDeclaredArm predicate which takes unknown. Surfaced as TS2345 the moment the props type was re-pointed; packages/core/ is outside this card's file surface so it was reported, not patched.",
    "evidence posted to objectui#8355 (NOT a new card - it already carries the alias question): the measurement that option 3 alone breaks a live authoring path, plus two corrections it needs - its key list says dateField/startField while the ladder is dateField/endField, and its three options omit the fourth (normalise at the producer).",
    "noted, not filed: scripts/shadcn-check-report.mjs writes `analysis.txt` and `check.txt` into the REPOSITORY ROOT when invoked bare, which AGENTS.md housekeeping bans and the gitignore anchors do not cover - a `git add -A` would sweep them into a PR. Removed from my worktree; they never entered a commit because every add here was per-path. Carrier: none; it only triggers on a bare local invocation.",
    "noted, not filed: two docblock passages in packages/core/src/utils/record-source.ts and one sentence in its behaviourNeutrality-7632 test describe the calendar caller in terms of the union this PR removes, so they go stale on merge. Carrier: objectui#9473 names them as its second half.",
    "noted, not filed: `calendar` is registered twice - the form date picker (skipFallback, reachable at ui:calendar) and this view. Deliberate and already ruled by objectui#8499. Not a defect."
  ]
}

---

Generated by Claude Code