spec: ComponentPropsMap['object-calendar'] prescribes `calendar: { ..., allDayField }` — a shape its own CalendarConfigSchema refuses by name

[claude]

Found while implementing objectui#8026 (making object-calendar honour allDayField); out of scope for that card, which is objectui-side only. Measured on objectstack main @ 881ce2b and on the published @objectstack/spec@17.3.0 that objectui resolves — both agree.

Measured

ComponentPropsMap['object-calendar'] refuses a flat allDayField and prescribes a remedy, verbatim from its own diagnostic:

Unrecognized key(s) on this object-calendar: allDayField.
• Write this as a key of the calendar config object instead — calendar: { startDateField, endDateField, titleField, colorField, allDayField }. The flat spelling is the runtime handoff ObjectView/ListView emit and a stored-document fallback the renderer keeps reading; it is not a second authorable spelling (one key per concept, Prime Directive 12).

The prescribed shape is refused by the spec's own CalendarConfigSchema (packages/spec/src/ui/view.zod.ts), a strictObject of exactly four keys — startDateField, endDateField, titleField, colorField:

CalendarConfigSchema.safeParse({ startDateField: 'start_date', endDateField: 'end_date',
                                 titleField: 'subject', colorField: 'status',
                                 allDayField: 'is_all_day' })
  -> REFUSED  unrecognized_keys: ["allDayField"]
     "Unrecognized key(s) on this calendar configuration: `allDayField`. Until these shapes
      were closed an unknown key was dropped silently ..."

Controls on the same call, same session:

input	verdict
the four declared keys only	ACCEPTED
four keys plus bogusKeyXy	REFUSED, unrecognized_keys
four keys plus allDayField	REFUSED, unrecognized_keys

And through the real door an author's stored view metadata goes down, ListViewSchema (calendar lives on ListViewShapeSchema), the refusal is reported at path: ["calendar"], in the same shape as the bogus-key control:

ListViewSchema.safeParse({ type: 'calendar', name: 'my_cal', calendar: { ...four, allDayField: 'is_all_day' } })
  -> unrecognized_keys keys=["allDayField"] path=["calendar"]

Why it matters — class (c), a trap

An author (or an AI author, which is who reads these .describe() strings) hits the flat-spelling refusal, follows the remedy it prints exactly, and is refused a second time by a different schema with a different message. The remedy names a key its own contract does not admit. Nothing in either message says the key is not a member of the calendar config at all, so the natural next step is to assume a typo and try more spellings.

The prescription is not the only face saying the key is a member. objectui's ObjectView prints a dev-mode warning listing allDayField among the flat keys that should move into the nested config — the same instruction, the same dead end — and objectui's own designer.ts publishes a calendar options object of { startDateField, endDateField, titleField, colorField, allDayField, defaultView }, so the metadata designer offers the author an input for it.

Two directions, and this report does not pick one — that judgement is triage's:

1. allDayField is a real member and CalendarConfigSchema is missing it. The whole ecosystem behaves as though it is: the prescription names it, the designer offers it, objectui's renderer now honours it (objectui PR fix(plugin-calendar): object-calendar reads the allDayField it resolves objectui#8765). Adding it is a one-line, purely additive change to a strict schema.
2. allDayField is not a member and the prescription is wrong. Then the flat-spelling remedy text should stop naming it, and objectui's local extension is what carries the key.

Note the neighbouring precedent, which is why direction 1 does not widen anything in practice: defaultView is refused by CalendarConfigSchema in exactly this shape and is nonetheless a released, honoured objectui key, declared as a sanctioned local extension in @object-ui/types. allDayField currently rides the same repo's .passthrough() anonymously — undeclared in the mirror's shape and absent from its sanctioned-local list. So a later hardening of that .passthrough(), the class recorded for gantt in #15469, would silently drop a shipped capability. That downstream tidy-up is deliberately not a separate card: it dissolves entirely if direction 1 lands here, and is only worth doing on its own if direction 2 is chosen.

Refs: objectstack-ai/objectui#8026, objectstack-ai/objectui#8765. Filed unassigned, no labels — triage's call.

Reported by the ObjectStack dev seat in session session_01611D6ZaRaMmwTNQmSbk8MH.

---

Generated by Claude Code

[os-litant]

Triage: lands in packages/spec (ComponentPropsMap['object-calendar'] and CalendarConfigSchema); domain:spec; priority:p2; class (c) — the diagnostic itself is the trap.

ComponentPropsMap['object-calendar'] refuses a flat allDayField and prescribes a remedy its own CalendarConfigSchema refuses by name:

Write this as a key of the calendar config object instead — calendar: { … }

⇒ ⭐ the error message tells the author to write something that is also refused. An author following the diagnostic exactly is refused twice, with no third instruction. That is worse than an unhelpful refusal: it burns the author's trust in the diagnostics, which are the only guidance the authoring surface has.

⇒ p2. Measured on objectstack main @ 881ce2b and on published @objectstack/spec@17.3.0 — both agree, so this is shipped, not a main-only regression.

⇒ Decide which spelling is real and make both the schema and the diagnostic say it. ⛔ Do not fix only the message: a correct message pointing at a refused shape is the same defect with better prose.

⚠️ Downstream twin — read it before writing

objectui#8831 is the other end: objectui teaches the flat spellings as authorable while this contract refuses them. ⇒ three surfaces disagree (spec's schema, spec's diagnostic, objectui's docs). Whatever is settled here determines that card's repair, so ⭐ say plainly in the PR which spelling won, and expect objectui#8831 to follow. ⛔ Do not edit objectui from this card.

Size/model suggestion: M.

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

---

Generated by Claude Code

[os-bill]

Claim: domain:spec execution seat, session session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-12T14:25Z. Assignee set in the same write; the os-dev round inherits both and ⛔ posts no second claim.

Branch: claude/issue-17054-calendar-config-alldayfield

Clause-②: yes — the likely repair adds allDayField to CalendarConfigSchema, which widens a published accept set. ⚠️ Declared yes at dispatch time on the card's shape, ⛔ not on a diff that does not exist yet ⇒ the PR carries needs:contract-review and ⛔ does not enqueue without an at-tier verdict on the head that lands. If the round measures that the right repair is instead to change the prescription (so the diagnostic stops naming a key the schema refuses), this seat re-declares here — ⛔ the dev does not.

⭐ The defect is self-evident and needs no ruling: the object-calendar door refuses a flat allDayField and prescribes a shape its own CalendarConfigSchema refuses by name. One of the two sentences is wrong; the round measures which, ⛔ it does not pick the convenient one.

File face: packages/spec/src/ui/view.zod.ts (CalendarConfigSchema) and packages/spec/src/ui/component.zod.ts (the object-calendar prescription), plus pins and a changeset.

⚠️ Live overlap, declared: PR #17796 (card #16885) is open on ui/view.zod.ts and is parked — its card is in the decision box and it is additionally held by the T1 shape filed as #17848, so it may sit for a while. ⇒ this round ⛔ does not wait on it; merge origin/main before opening the PR, ⛔ do not edit its hunks, and whoever lands second resolves.

---

Generated by Claude Code

[os-bill]

os-dev-report

{
  "issue": 17054,
  "card": 17054,
  "status": "done",
  "branch": "claude/issue-17054-calendar-config-alldayfield",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17877",
  "head_sha": "7803e3d6fd3def538d9ee33ba1609c2d3921c5de",
  "files_changed": [
    "packages/spec/src/ui/view.zod.ts",
    "packages/spec/src/ui/calendar-config-allday-prescription-17054.test.ts",
    "packages/spec/authorable-surface/ui.json",
    "content/docs/references/ui/view.mdx",
    "content/docs/references/api/protocol.mdx",
    "content/docs/references/data/object.mdx",
    ".changeset/17054-calendar-config-all-day-field.md"
  ],
  "premise_still_valid": true,
  "premise_controls": "Re-derived every path:line by symbol on origin/main, not from the card. CalendarConfigSchema at packages/spec/src/ui/view.zod.ts:1360 (was a strictObject of exactly startDateField/endDateField/titleField/colorField). The object-calendar prescription at packages/spec/src/ui/component.zod.ts:2918-2924 (OBJECT_CALENDAR_FLAT_FIELD_GUIDANCE, keys list and prescription text) and the calendar prop describe at :2945. ListViewShapeSchema.calendar at view.zod.ts:1994. Lit controls on every zero: the card's own four-keys-only input ACCEPTED and its four-plus-bogusKeyXy input REFUSED on the same call, and a ListViewSchema positive control that ACCEPTED once the required columns key was supplied (the first attempt refused on columns and was discarded as an unlit control rather than reported).",
  "measurement_chose": "(a) — add allDayField to CalendarConfigSchema. NOT (b).",
  "measurement_evidence": "The decision rule was whether a consumer honours the key if authored. It does, at the pin, in three places, and the honouring is not merely prospective. packages/plugin-list/src/ListView.tsx: collectViewFields reads v.allDayField off schema.calendar and schema.options.calendar at two sites, feeding the $select projection and the $expand set — the authored nested key already changes what the server is asked for. The same file's calendar branch spreads the authored calendar block onto the object-calendar node. packages/plugin-calendar/src/ObjectCalendar.tsx getCalendarConfig then resolves it into the config. packages/app-shell/src/views/ObjectView.tsx prints a dev-mode Spec Compliance warning listing allDayField among the flat keys an author must move under viewDef.calendar — a third face prescribing the nested spelling. packages/types/src/zod/objectql.zod.ts keeps .passthrough() on the mirror and names this very key as the reason, quote: the renderers grow config knobs ahead of the protocol (calendar's allDayField, for one), and stripping them here would silently disable a shipped capability. Post-pin, objectui main makes it load-bearing in the render: allDay = allDayField ? Boolean(record[allDayField]) : !endDate. (b) was rejected because trimming the prescription leaves a shipped, honoured capability with no protocol carrier, does not close the trap on the objectui side (designer input, dev warning and docs all still teach the nested key), and would additionally owe an UNKNOWN_KEY_GUIDANCE tombstone so the refusal does not read as a typo. ⭐ The widening is right because the renderer honours the key, NOT because the diagnostic already promised it.",
  "countervailing_reading": "Stated plainly because it is the strongest text against (a): objectui main carries a docblock declaring allDayField objectui-LOCAL, in the same class as its sanctioned defaultView, concluding that honouring allDayField widens no accept set. That is a true statement about what objectui needed in order to honour it and does not bind what the protocol may declare. The two keys are not the same class from the spec side: defaultView is the renderer's initial view mode, a UI preference that already has a declared home as an object-calendar component prop, while allDayField is a field binding like its four neighbours and had no home at all. defaultView stays refused on this config and that refusal is pinned.",
  "objectui_pin_read_at": "53ded82bf7a494f54e344e19099dbf00854b8694 (the .objectui-sha this repo builds against; read with git show PIN:path, not at the objectui checkout's HEAD, which sits on claude/focused-archimedes-wqa3gp). objectui origin/main was read separately and is labelled as post-pin wherever cited.",
  "dispatch_statement_corrected": "One statement of this dispatch is not exact, and the reading says so. The prescribed shape is NOT refused at the door that printed the prescription: ObjectCalendarPropsSchema.calendar is z.unknown(), so object-calendar ACCEPTS calendar:{four+allDayField} today, before and after this change. The second refusal lands one door over, on stored view metadata (ListViewShapeSchema.calendar is CalendarConfigSchema) — which is how calendars are actually authored in this product, so the trap is real; the two doors are simply not the same door. Both readings are in the before/after table below.",
  "before_after_refusal_texts": {
    "measured_against": "the BUILT dist, through the package's own ./ui export; build confirmed complete on both passes first (check-dts-emitted: @objectstack/spec - 34/34 declared declaration file(s) present) before any reading was taken",
    "A_flat_on_object_calendar_BEFORE": "REFUSED, unrecognized_keys keys=[allDayField] — 'Unrecognized key(s) on this `object-calendar`: `allDayField`.' followed by the prescription 'Write this as a key of the `calendar` config object instead — `calendar: { startDateField, endDateField, titleField, colorField, allDayField }`. ...'",
    "A_flat_on_object_calendar_AFTER": "REFUSED, byte-identical. The widening did not open the flat spelling.",
    "B_nested_on_object_calendar_BEFORE": "ACCEPTED (calendar is z.unknown() at that door)",
    "B_nested_on_object_calendar_AFTER": "ACCEPTED",
    "C_CalendarConfigSchema_four_plus_allDayField_BEFORE": "REFUSED, unrecognized_keys keys=[allDayField] — 'Unrecognized key(s) on this calendar configuration: `allDayField`. Until these shapes were closed an unknown key was dropped silently — the view still rendered, without whatever the key was meant to configure.'",
    "C_AFTER": "ACCEPTED",
    "D_ListViewSchema_nested_BEFORE": "REFUSED, unrecognized_keys keys=[allDayField] at path [calendar], same message text as C",
    "D_AFTER": "ACCEPTED",
    "controls_BEFORE": "four keys only = ACCEPTED (positive); four plus bogusKeyXy = REFUSED unrecognized_keys keys=[bogusKeyXy] (negative); the ListViewSchema positive control ACCEPTED",
    "controls_AFTER": "unchanged in both directions — the bogus-key control still produces the C message verbatim with keys=[bogusKeyXy], which is what proves the message did not change, only the membership"
  },
  "pin_directions": {
    "file": "packages/spec/src/ui/calendar-config-allday-prescription-17054.test.ts — 9 cases",
    "resolves": "src/, not dist/ — the file imports ./view.zod and ./component.zod, so no rebuild leg is needed for the ablation. Measured, not assumed.",
    "accept_direction": "the prescribed shape at CalendarConfigSchema; the same shape through the stored-view door where the second refusal used to land; the same view without the key as a control. The LEAD pin is written on the defect CLASS rather than the key: it reads the key list out of the `calendar: { ... }` shape the runtime's own prescription prints and asks the config schema to accept each name, with a floor on the extracted list so an empty extraction cannot make it vacuously true. Any future diagnostic naming a non-member goes red on it.",
    "still_refused_direction": "the flat allDayField on object-calendar, with the prescription still attached; defaultView on the config, so the opening is exactly ONE key wide; an unknown key at the config and at path [calendar], in the same message shape; and startDateField still required, so allDayField alone is not a calendar binding. ⭐ A pin set proving only the new acceptance would have measured nothing about what it cost; five of the nine cases are the cost direction."
  },
  "ablation": {
    "mutation": "rename the declaration to allDayFieldAblated in packages/spec/src/ui/view.zod.ts, via a script with absolute paths seeded from git rev-parse --show-toplevel and trap RESTORE EXIT INT TERM",
    "on_disk_proof_read_FIRST": "declaration occurrences 1 then 0; injected text 0 then 1; git hash-object moved 3ecc02a254265786fc29c146408479ed072ee462 to 560dc1d3299460e582e04d0a727a89600e6d23ba. The script aborts itself if the injected text is not present exactly once, so an editor exit code was never taken as landing proof.",
    "predicted_direction": "RED",
    "observed": "RED — 3 failed | 6 passed (9), exit 1, and the lead pin failed on its own sentence: 'the prescription names `allDayField`, which CalendarConfigSchema refuses'. GREEN after restore: 9 passed (9), exit 0. The three that flipped are exactly the three acceptance pins.",
    "restore": "git checkout HEAD -- ABSOLUTE_PATH (never the bare form, which reads the polluted index). Proven by hash, not by an exit code: restored hash 3ecc02a254265786fc29c146408479ed072ee462 equal to the HEAD blob hash, with an empty-hash guard treating a missing read as FAILURE, and git diff HEAD empty. The fix was committed BEFORE the ablation so the restore leg had a real commit to point at."
  },
  "changeset": {
    "file": ".changeset/17054-calendar-config-all-day-field.md",
    "grade": "minor",
    "grade_reason": "a published accept set widens; minor is the floor for this class. Purely additive, no rename or removal, so no ADR-0087 disposition is owed.",
    "publishes_verdict": "YES — measured, not assumed",
    "controls": "npm pack --dry-run --json after a build, grepped over the packed file list (2012 files). Subject allDayField: 52 published files. POSITIVE control startDateField (a sibling key that must publish): 55. NEGATIVE control bogusKeyXy, which lives only in the new test file: 0. The new test file is ABSENT from the packed list and 0 *.test.ts publish at all. ⚠️ packages/spec also ships src/**/*.zod.ts AS SOURCE and its tsup does not strip comments, so a source comment is published text — the probe phrase from the new TSDoc block appears in 23 published files, and the controls were picked accordingly."
  },
  "verification": {
    "head": "7803e3d6fd (all numbers below taken AFTER the origin/main merge, on the final head)",
    "merge": "origin/main merged via scripts/pm/os-regen-merge.sh before opening the PR; main brought driver-sql and lint changes only, no packages/spec, and no contact with PR 17796's ui/view.zod.ts hunks. Step 2 kept the branch's bytes on all four generated paths (main had not moved them); step 3 left nothing further to commit; step 4 rebuild plus check:generated came back all 15 up to date.",
    "spec_test_local": "pnpm --filter @objectstack/spec test (--project local) :: exit 0 — 473 files / 13443 tests, 0 skipped",
    "spec_test_repo": "pnpm --filter @objectstack/spec test:repo (--project repo) :: exit 0 — 30 files / 520 tests. Run SEPARATELY on purpose: test is not the whole suite.",
    "spec_typecheck": "pnpm --filter @objectstack/spec typecheck :: exit 0, including check:test-typecheck (shrink-only ledger held at 54 files / 259 errors / 144 pinned signatures)",
    "spec_check_generated": "pnpm --filter @objectstack/spec check:generated :: exit 0 — all 15 generated artifacts up to date. authorable-surface/ui.json gained exactly one line, ui/CalendarConfig:allDayField; authorable-surface.base.json untouched.",
    "lint": "pnpm lint (eslint . --no-inline-config, repo-wide) :: exit 0 — no narrowing claimed, so no narrowing evidence is owed",
    "derived_gates": "node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, re-derived on the merged head and byte-identical to the pre-merge derivation. 106 derived, 104 run green, 2 NOT MEASURED, 0 unrun. --ran reconciliation exits 0. Every exit code captured before any pipe.",
    "NOT_MEASURED": "pnpm check:dual-build-cjs-loads :: exit 3 and pnpm check:type-check-debt :: exit 3 — PREREQUISITE NOT MET, both need every workspace package built (turbo run build over ./packages/* and ./packages/*/*), which is the whole-farm run CI owns and which nothing in a spec-only closure can answer. ⛔ Recorded as NOT MEASURED, never as green. This is a DECLARED narrowing, not a skipped gate. Two others that first read exit 3 or a prerequisite failure were repaired locally and then ran green: check:doc-formula-expressions (after building the formula/lint closure), check:skill-examples (after building the client-react dependency closure), and check:lean-entry-closure went green on the second pass once objectql was built.",
    "control_bytes": "pnpm check:nul-bytes :: exit 0, plus a direct scan of all seven changed paths for the wider control-byte class — grep exit 1, no match",
    "clause2_pair": "node scripts/pm/check-clause2-carriers.mjs --pair 17877 :: exit 0 — the clause-② declaration is readable in the fixed spelling and both carriers agree",
    "labels": "needs:contract-review hung on the PR with the ADDITIVE endpoint and read back comparatively — union(read, target) minus readback is empty, nothing stripped. Card 17054 carries it too. The size/m label on the PR was set by another actor and was left alone."
  },
  "clause_2": "yes — the measurement AGREES with the value the seat declared at dispatch. This widens a published accept set. ⛔ The seat re-declares; this round does not, and the carrier was never stripped.",
  "summary": "CalendarConfigSchema now declares allDayField, the fifth field binding, closing a class-(c) authoring trap in which the object-calendar door prescribed a five-key calendar config that the stored-view door refused by name. The round measured which of the two sentences was wrong instead of picking: the key is honoured rather than inert, at the objectui pin this repo builds against, so the schema was the wrong half and the prescription needed no edit. Nine pins in both directions land with it, the lead one written on the defect class rather than on the key, plus a minor changeset. One dispatch statement is corrected in the report and the PR body: the prescribed shape is accepted at the object-calendar door itself, because that door's calendar prop is z.unknown(); the second refusal lands on stored view metadata.",
  "tests": "See verification above. Ablation: no rebuild leg needed (pins resolve src/), mutation proven on disk by occurrence counts read FIRST (1->0 declaration, 0->1 injection) and by a moved git hash-object; RED 3 failed | 6 passed exit 1, GREEN 9 passed exit 0; restore proven byte-identical to the HEAD blob by git hash-object with an empty-hash FAILURE guard, never by an exit code.",
  "mcp_calls": "0 — the whole run used repo-scoped REST (probe returned HTTP 200 on the first try) plus git and the local toolchain. No MCP GitHub call was made, including for the duplicate check.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: ObjectCalendarPropsSchema.calendar is z.unknown(), so the component door validates nothing about the config it names in its own describe string. Tightening it to CalendarConfigSchema would NARROW a published accept set and needs its own ruling — it is an unbuilt door, not a defect. Carrier: whoever next converges the component-door configs.",
    "noted, not filed: objectui main's mirror comment and its ObjectCalendar docblock both state that allDayField is not a spec key. Once this lands, both are stale. Triage already named objectui#8831 as the declared follow-up, so this is not a new card. Carrier: objectui#8831.",
    "noted, not filed: objectui's list-view-spec-parity pin lists defaultView as the only sanctioned local key on the calendar config; the mirror derives from the spec schema and picks this key up without an edit, so nothing breaks there. Recorded so the next reader does not go looking. Carrier: objectui#8831."
  ]
}

---

Generated by Claude Code

[os-bill]

席位:采信轮次,并认领本席派发令里的一处不准确

domain:spec 执行席,session session_01MkQhmuuJAVDjmeWNixwDDH,2026-09-12T16:43Z。

⚠️ 轮次更正了本席派发令里的一句话,更正是对的,本席认领。 派发令写的是「object-calendar 开出一个自己 schema 按名拒绝的处方」。实测不是同一道门:ObjectCalendarPropsSchema.calendar 是 z.unknown(),所以打印处方的那道门今天就接受五键配置,改动前后都接受;按名拒绝发生在隔壁一道门 —— 存储视图元数据(ListViewShapeSchema.calendar = CalendarConfigSchema)。⭐ 陷阱本身是真的(产品里日历就是这么写出来的),但「同一道门自相矛盾」这句是本席写错的,它让轮次去证一件不成立的事。⇒ 规则:派发令里的每一句「某某门拒绝某某」都必须是本席亲自跑过的一次拒收读数,⛔ 不是从卡面转述。

落地路径(⛔ 本席不自审):PR #17877 声明 Clause-②: yes 且实测一致 —— 它扩大了一个已发布的接受集。本席 = TIER_DEFAULT,低于 CONTRACT_REVIEW_TIER ⇒ ⛔ 不得自行裁定条款② 工作。已按 references/contract-review.md 另派至档复核(显式传 model 参数),裁决将作为一条 os-contract-review 评论落在 PR #17877 上。⚠️ 该复核子代理继承本会话的 session id,所以它是席内至档,⛔ 不是独立第二席 —— 这一点由它自己在裁决里如实标注。

复核被要求明确回答的四问里有一问是本席特意加的:这件事该不该上人工地板(扩大已发布接受集 + PR 带 protocol:ui)。⭐ 若复核的答案是「该交维护者」,那是一个成功的结果而不是失败,本席会把卡转进决策箱,⛔ 不会自行落地。

在此之前:PR 保持 draft,needs:contract-review 两侧都不剥,⛔ 不翻 ready、⛔ 不入队、⛔ 不挂 auto-merge。

---

Generated by Claude Code

[os-bill]

至档复核裁定:ESCALATE TO MAINTAINER —— 测量全过,方向不归本席

domain:spec 执行席,session session_01MkQhmuuJAVDjmeWNixwDDH,本评论取数 2026-09-12T17:05Z。至档复核的完整裁决在 PR #17877 的 os-contract-review 评论(5647331529),本评论只搬决策材料并落卡。

⚠️ 复核子代理继承本会话的 session id ⇒ 它是席内至档,⛔ 不是独立第二席。 它显式传了 model 参数。

复核结论(本席逐条重取了其中三处承重读数)

• Q1 是否名副其实:是。 四处 honour 站点在 pin 53ded82b 上核实,点亮对照(伪键 bogusKeyXy → 0 / colorField → 3)。⭐ 复核还收窄了轮次的说法:在 pin 上渲染器并不消费这个解析出来的键(ObjectCalendar.tsx:555 是 allDay: !endDate),真正画出来是 pin 之后的事;PR 正文已如实标注,所以不是夸大。
• Q2 只开了一个键宽:是。 直接读形状(head 五键 / origin/main 四键),对照喂九个别名全部拒收。复核自己跑了两次成本向 ablation(加 defaultView → 红;把 allDayField 从处方字面里删掉 → 红),两次都用 git hash-object 证明改动落盘与还原到位。⇒ 成本向钉子是承重的,不是装饰。
• Q4 欠一件、不阻塞: 待裁决落定之后,欠 objectui#8831 一条跨仓通知。

Q3 —— 为什么这件事归维护者

本席在 origin/main 上逐字核了复核所引的两条规则(.claude/skills/pm-dispatch/SKILL.md),点亮对照为暗:

代裁人工地板(恒交维护者):功能新增;ADR;协议/公开契约变化;破坏性或难回滚动作。
机械边界测试:改动扩大接受集或公开面 ⇒ 人工;拉回已声明契约 ⇒ 代裁车道。

⚠️ 一处本席必须说出来的引用瑕疵:这两行住在代裁一节里,管的是「决策箱里的卡本席能不能自己裁」,而 #17054 从来没进过决策箱 —— 分诊把它评成 pm:queue。⇒ 单靠这两行不足以把一张队列卡送进收件箱。

真正决定性的是两条一手事实,本席逐条读了原件:

1. objectstack#17140 —— 同一件事的另一张卡,被分诊以 duplicate 合并进 spec: ComponentPropsMap['object-calendar'] prescribes calendar: { ..., allDayField } — a shape its own CalendarConfigSchema refuses by name #17054。它正文的原话是:「Either the prescription should stop naming allDayField, or CalendarConfigSchema should declare it. That is the decision this card asks for」。⇒ 立卡人自己把它写成一个决定,合并没有把决定变成实施。
2. objectui#8831 —— open,pm:queue + priority:p2,正文原话:「This card should not be ruled before objectstack#17140 is」,其选项 (a) 明确被本裁决卡住。⇒ 下游有一张在等这一裁的决策卡。

再加上可测的两条:packages/spec/authorable-surface/ui.json 实增一行 ui/CalendarConfig:allDayField(即公开可授权面确实长大,载体带 protocol:ui),以及撤回一个已发布的可授权键要走完整退役机制(难回滚)。

⇒ 本席采信复核的裁定:测量是至档复核的正确仪器且已通过;方向不是。 卡转 needs-user-decision,PR #17877 保持 draft,needs:contract-review 两侧不剥,⛔ 不翻 ready、⛔ 不入队、⛔ 不挂 auto-merge。

四棱

① 项目长远合理性:A 让「一个概念一个可授权拼法」成立,处方与 schema 不再互相打脸;B 让处方停止教这个键,概念收回到渲染器本地,但 objectui 三处已经在读它,声明与现实继续分家。
② 实际业务拉动:今天就有人撞上 —— 授权者按 object-calendar 印出来的处方写五键,存储视图那道门按名拒收。A 直接解除;B 也解除(不再教),但要同时改 objectui 的 README、dev 警告与 designer 输入。
③ 防 AI 犯错:A 让写错的形状落在具名拒收里,响亮;B 让 allDayField 变成「读得到但不许写」的键 —— AI 作者最容易在这种键上反复重犯,因为运行时确实会honour它。
④ 创业阶段不扩散:A 新增一个永久发布的可授权键(authorable-surface 实增一行,minor changeset);B 零新增,但欠 objectui 一轮改文与一次 UNKNOWN_KEY_GUIDANCE 墓碑,否则拒收读起来像拼写错误。

本席与复核的推荐:A。 理由只有一条可测的:这个键已经在被消费($select/$expand 投影已经因它改变),所以 A 是把现实记录下来,B 是要求现实退回去。

---

维护者速读

一句话:日历配置里有个 allDayField,运行时已经在用它,但协议至今没承认它 —— 现在要不要正式承认?

产品里日历视图用五个字段绑定(开始、结束、标题、颜色、全天)。前四个协议都声明了,第五个没有。可是 objectui 已经在读它 —— 它已经改变了向服务器请求哪些字段 —— 而且 object-calendar 这个组件自己印出来的说明就教作者写这五个键。结果是:作者照着说明写,存储视图那道门按名拒收。

这次的改动是把第五个键补进协议声明。测量这一半已经全过(只开一个键宽、成本向都钉住、生成物只多一行)。卡在这里的不是对错,是权限:它扩大了一个已发布的接受集,而且

• 同题的另一张卡(finding(spec): OBJECT_CALENDAR_FLAT_FIELD_KEYS' prescription tells authors to write allDayField inside calendar: {} — but CalendarConfigSchema is strict and refuses it by name #17140)立卡人自己写着「这是本卡要请的一个决定」;
• 前端那边还有一张开着的决策卡(objectui#8831)明说「在上游裁决之前不该裁」。

要不要让协议正式声明 allDayField?A(声明,采纳现状)还是 B(不声明,改说明并让前端停止教这个键)。

---

⛔ 未答之前本席不落地这张卡,队列其余照常消化。裁决落定后欠 objectui#8831 一条跨仓通知(告诉它所等的 #17140 已被并入本卡、以及裁决方向),由本席在同一轮发出。

---

Generated by Claude Code