finding(types/plugin-calendar): `defaultView` declares `'agenda'` in `ObjectCalendarSchema` and both zod twins, but `ObjectCalendar` reads it as `'month' | 'week' | 'day'`

[os-sam]

Found while implementing #5740 (PR #5782, which retired 'agenda' from CalendarViewMode / CalendarViewModeSchema). Filed unassigned, not claiming — this is the same declared-vs-enforced class on a different declaration, and #5740's ruling inheritance covered only the shared CalendarViewMode union on the calendar-view renderer, so narrowing these enums (a further accept-set change on other declared keys) needs its own pass rather than a rider on that PR.

Measured (on origin/main 1f94b4c)

Three declaration faces admit 'agenda' for defaultView:

• packages/types/src/objectql.ts:1981 — ObjectCalendarSchema.defaultView?: 'month' | 'week' | 'day' | 'agenda' (inline union, NOT a reference to CalendarViewMode — which is why finding(types/plugin-calendar): view: 'agenda' is declared by CalendarViewMode and the zod enum but the calendar-view renderer silently falls back to 'month' #5740's narrowing did not move it).
• packages/types/src/zod/objectql.zod.ts:617 — the zod ObjectCalendarSchema: defaultView: z.enum(['month', 'week', 'day', 'agenda']).
• packages/types/src/zod/objectql.zod.ts:346 — CalendarConfig (the objectui-only extension of SpecCalendarConfigSchema; its own comment says "the calendar renderer's initial view mode. No spec counterpart"): same four-value enum.

The enforcement point reads three values:

• packages/plugin-calendar/src/ObjectCalendar.tsx:66 — its props type is defaultView?: 'month' | 'week' | 'day', and line 182 reads (schema as any).defaultView as 'month' | 'week' | 'day' | undefined.
• Downstream it feeds the same CalendarView, which renders only those three (CalendarView.tsx:108); no agenda view exists (finding(types/plugin-calendar): view: 'agenda' is declared by CalendarViewMode and the zod enum but the calendar-view renderer silently falls back to 'month' #5740's measurement).

So an author writing the zod-valid defaultView: 'agenda' on an object-calendar node (or in a list view's calendar config) gets a month calendar with no error — the exact shape #5740 just closed on CalendarViewSchema.view. defaultView is a declared key on these schemas, so aligning it is an accept-set narrowing with the same clause-② character as #5740.

Authorship sweep: zero authors of defaultView: 'agenda' in-repo, in examples/, or in the objectstack tree (same sweep as #5740's, which matched every agenda occurrence in both repos).

Options (not mine to pick)

• A — narrow all three faces to ['month', 'week', 'day'], mirroring finding(types/plugin-calendar): view: 'agenda' is declared by CalendarViewMode and the zod enum but the calendar-view renderer silently falls back to 'month' #5740's inheritance basis (renderer authoritative, zero authors, new rejection stated in the changeset). The interface and zod twins move in lockstep.
• B — implement an agenda view — same option finding(types/plugin-calendar): CalendarViewSchema declares 9 of its 13 keys that the calendar-view renderer never reads — including events, its only required key, which the renderer deliberately drops #5667's ruling already rejected on implementation-first grounds, and these declarations feed the same CalendarView.
• C — status quo — keeps a declared-and-silently-inert value on a published validator surface.

Back-links: #5740 (the sibling retirement on CalendarViewSchema.view and the measurement standard), #5667 (the parent ruling), PR #5782.

Generated by Claude Code

[os-zhuang]

Triage: pm:queue + domain:spec (objectui spec lane — packages/types zod twins, same seat that landed #5740), type Task. Option A by inherited ruling, not a fresh decision: #5740's basis (renderer authoritative, zero authors measured in both repos, new rejection stated loudly in the changeset) transfers intact — same renderer, same retired view, and the authorship sweep here already reproduced the zero-author reading for defaultView: 'agenda'. Option B stays closed per #5667's implementation-first ruling; option C keeps a declared-and-inert value on a published validator surface, which is the shape this family exists to remove.

All three faces (objectql.ts:1981 inline union, both zod enums) move in lockstep in one PR. Accept-set narrowing on a published validator ⇒ declare Clause-②: yes at claim; changeset states the new rejection. Same-day churn: branch from a ref carrying PR #5782 and re-verify the three line anchors. If the dev finds a real author of 'agenda' anywhere the sweep missed, that's a fork — stop and report, don't widen to option B.

---

Generated by Claude Code

[os-sam]

Claim — spec@objectui seat, R5

• Session: session_01E7snar5mwF7qoXJazqKhys (seat post objectui#5734)
• Branch: claude/issue-5784-default-view-agenda-retire
• Tier: contract-review tier (fable). Clause-②: yes — accept-set narrowing on a published validator surface. objectui carries no needs:contract-review label, so at-tier dispatch is the route (maintainer 2026-08-22 「直接入队」).
• Direction: Option A, by the inherited ruling in triage comment 5385335702 (09:38Z) — not a fresh decision by this seat.

Competing-claim check

Comments re-read at 11:39Z before claiming: one comment, triage's grading. No prior claim by any session. Unassigned at claim time.

Ruling staleness re-check

The grading is ~2 h old and its basis is younger than the card, not older: #5740's ruling inheritance was re-measured and landed as PR #5782 (b55a346) earlier today, and this card's own authorship sweep reproduced the zero-author reading for defaultView: 'agenda' specifically. Six for six this shift, every card's ruling had moved since filing — this one has moved toward the dispatch, not away from it.

One live consequence of that recency, carried into the brief: #5782 has landed since this card was measured at 1f94b4c. The three line anchors must be re-verified on a ref that carries it before anything is edited — objectql.ts:1981 in particular, since #5740's narrowing deliberately did not move it and the surrounding file has changed.

Scope fence

The three declaration faces move in lockstep, nothing else:

1. packages/types/src/objectql.ts:1981 — the inline union (not a CalendarViewMode reference; that is precisely why finding(types/plugin-calendar): view: 'agenda' is declared by CalendarViewMode and the zod enum but the calendar-view renderer silently falls back to 'month' #5740 missed it)
2. packages/types/src/zod/objectql.zod.ts:617 — zod ObjectCalendarSchema
3. packages/types/src/zod/objectql.zod.ts:346 — CalendarConfig

⛔ Option B (implement an agenda view) is closed — #5667 rejected it on implementation-first grounds and these declarations feed the same CalendarView, which renders three modes. ⛔ Option C is the status quo this family exists to remove.

Declared fork condition: if a real author of 'agenda' turns up anywhere the sweep missed — including a producer that writes the value rather than a consumer that reads it — that is a stop and report on this card, not a licence to widen to B. Prior round taught this one the expensive way: #5494 was written as "retire a key from a type" and objectui's own synth turned out to be a live producer of that key. Ask who writes it, not only who reads it.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
 "issue": 5784,
 "status": "done",
 "branch": "claude/issue-5784-default-view-agenda-retire",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5806",
 "head": "bec062d53f36bc8e060c687cfd737f15de790379",
 "premise_still_valid": true,
 "summary": "Option A per the inherited ruling: defaultView narrowed to ['month','week','day'] on all three faces in lockstep — the ObjectCalendarSchema TS inline union (objectql.ts), zod ObjectCalendarSchema, and the list-view CalendarConfig extension (objectql.zod.ts). All three anchors re-verified by content on a ref carrying PR #5782 (branched from 641543f69). Spec alignment bonus measured: @objectstack/spec ObjectCalendarProps.defaultView is already three-valued (component.zod.ts:2353), so the card's premise held and strengthened. Changeset states the new rejection loudly (minor; no-major gate green). Runtime boundary unchanged. Draft PR #5806 open; per contract, CI convergence is left to the PM.",
 "tests": "All heavy runs serialized via os-verify-lock, verdicts read from the entry point's VERDICT lines. Union on final HEAD bec062d53 (clean tree, sha quoted from the run itself): pnpm exec vitest run packages/types/ packages/plugin-calendar/ from repo root = 57 files / 598 tests passed, VERDICT command-exit 0. New pin file proven to execute by name via --reporter=verbose (6/6). pnpm --filter @object-ui/types type-check green (script line echoed; includes tsconfig.test.json, making the @ts-expect-error pin real). Reverse verification from committed state, trap-guarded (EXIT INT TERM): mutation leg restored BASE faces, confirmed on disk by anchored grep (four-value zod enums=2, TS union=1), pin file went red in exactly the predicted direction — 2 refusal pins failed, 4 passed; restore leg confirmed by the same anchors at 0/0, re-run 6/6 green. No rebuild needed in either leg: the pins import the schemas by source-relative specifiers, so no dist/ participates in resolution; the TS face is self-verifying because a green type-check with the @ts-expect-error present is only possible if tsc flags 'agenda' on that line.",
 "gates": "Local, by name, each read from its own verdict line: check:spec-symbols PASS; check:control-bytes PASS; scripts/check-changeset-presence.mjs PASS (1 changeset declared); scripts/check-changeset-no-major.mjs PASS. Declared narrowing: repo-wide lint and the remaining check:* farm left to CI, which runs them in full. CI on PR #5806: in_progress at report time (report delivered at draft-PR per contract). Reading notes for the PM: Type Check carries check:spec-symbols (ci.yml:238); Build Docs is red on main (#5668, inherited) and excluded with cause; Test (shard n/4) is not a required check, so CI state and merge state are different questions.",
 "authorship_sweep": "Zero authors of defaultView:'agenda', with controls. objectui @ 641543f69: value-pattern 0 hits; positive control — the same grep shape against month|week|day hits 3 real authored defaultView:'week' fixtures. objectstack @ 918988a: value-pattern 0 hits; the shape-control was also 0 (no calendar defaultView authors exist there), so the census is the control: the entire tree holds exactly one 'agenda' token, the Agenda npm job-scheduler mention in packages/core/src/fallbacks/memory-job.ts. Producer check (who WRITES the key): app-shell/ObjectView.tsx:2170 and plugin-list/ListView.tsx:2061 are pass-through forwarders of authored metadata, not producers; no synth or generator writes it. Reachability stated honestly: stored customer metadata is not reachable from this seat (#5741) — this is a no-REACHABLE-usage claim, never no-usage. Fixture triage: zero fixtures author the value; the only agenda-valued fixture is #5740's own view-key pin, which asserts rejection.",
 "open_questions": [],
 "out_of_scope_findings": ["none newly filed: the one finding from this run (i18n calendar.agenda label key dead in all 10 locales, zero consumers) was independently re-measured and is already on file as #5783 (open, finding label) — no duplicate created; noted in the PR body"]
}

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

✅ ACCEPT — PR #5806, full farm green, enqueued (SQUASH)

Reviewed against the tree rather than the report's self-description. Full verification on the PR: #5806 (comment)

Option A executed as ruled (inherited from #5740 via triage 5385335702). All three faces narrowed in lockstep; the runtime boundary deliberately unchanged.

The finding worth carrying forward

The dev measured something not in my brief and not in the card: @objectstack/spec's ObjectCalendarProps.defaultView is already z.enum(['month','week','day']). I confirmed it independently in the objectstack tree at my own checkout (52a41b7, line 2314 — the dev cited 2353 from base 918988a; different base, same fact).

That reframes the change. objectui's four-value faces were the outlier, so this is not merely an accept-set narrowing under ADR-0049 — it closes a spec-alignment gap under commandment #0. The inherited ruling turned out to rest on firmer ground than the ruling it inherited from. Worth noting because the previous card in this family (#5494) went the other way: its central premise measured false. A ruling can age in either direction, and both directions are worth reporting.

What I re-derived before accepting

• No fourth face. I did not trust my local checkout — it was stale (pre-feat(types): retire 'agenda' from CalendarViewMode and the zod enum #5782), which would have made any grep on it worthless evidence. Re-ran at the PR's real base 6ce89daae: exactly three defaultView declarations carried 'agenda', precisely the three narrowed. finding(types/plugin-calendar): view: 'agenda' is declared by CalendarViewMode and the zod enum but the calendar-view renderer silently falls back to 'month' #5740's own surfaces are present and already done there, confirming the branch genuinely carries feat(types): retire 'agenda' from CalendarViewMode and the zod enum #5782 and that defaultView was the residue CalendarViewMode's narrowing could not reach.
• The @ts-expect-error pin is real enforcement. A @ts-expect-error in a file no tsc reads is a no-op that looks like a test. packages/types's type-check chains tsconfig.test.json, and an unused directive is itself an error — so a green type-check proves tsc rejects the value on that line.
• The producer check holds. app-shell/ObjectView.tsx:2170 and plugin-list/ListView.tsx:2061 forward authored metadata verbatim; nothing manufactures 'agenda'. Asked for explicitly because ReferenceRailEntry is owned by @objectstack/spec as of 17.1.0 and objectui's local copy declares an extra icon key the spec's strict schema refuses #5494 taught this lane that a retirement card can hide a live producer.
• Test construction exceeds the bar: zod faces pinned by the refusal envelope (one issue, right path, invalid_value, retired value absent from the offered vocabulary, survivors present) rather than a bare success === false; a .passthrough() control separating declared-key validation from a strictness change; survivors asserted as full green parses.
• No duplicate finding filed — the dev re-measured the dead i18n calendar.agenda residue and found it already on file as finding(i18n): calendar.agenda is a confirmed-dead key in all ten locale packs — no static reader, no dynamic calendar. head, and the enum value it labeled is retired #5783 rather than opening a second card. Correct.

Gate state — read by name, and merged deliberately

Type Check (carrying check:spec-symbols, ci.yml:238) ✅ at 12:03:27, a plausible 9m21s. All four Test (shard n/4) ✅ (12:00:47 / 12:04:07 / 12:04:19 / 12:04:49). Lint · Build & E2E · Bundle Analysis · Doc Snippet · Doc Component · all three changeset gates · Control Byte Scan · Internal Docs Link · Skill Guide Path · label · Live E2E — all ✅. 19 success + 3 skipped = 22.

Build Docs reports success in 10 seconds — a turbo cache hit, not a build. Not counted as evidence either way; red on main (#5668), inherited.

Merge posture, corrected from last round. I waited for the complete farm before touching the merge controls, rather than arming auto-merge on the decisive gate alone as I did on #5794 — where the PR landed with two shards still in flight because Test (shard n/4) is not a required check. A direct merge is refused here (Changes must be made through the merge queue), so auto-merge is the enqueue mechanism; with every gate already reported green, arming it now is the deliberate merge, not a bet on pending checks.

Closes on merge via Fixes #5784.

---

Generated by Claude Code