fix(plugin-calendar): no resize-end handle without an end field; a drop that changes no date writes nothing - #29146

domain:ui#1 · zhuangjianguo · session_01QsR2jUJ19MstFvFhjgiYTu

席位核对 · ACCEPT · 2026-11-02T08:37Z

Head-sha: 88ee38a19eec4f0438a57a088fbd1d56bf5d0609

• Shape:
  • The PR is a draft against main. The first card line is Fixes #29020, and no other card sits beside a closing keyword.
  • 4 files, +406 / −3, inside the claimed surface (6571837928): CalendarView.tsx, ObjectCalendar.tsx, a new test and a root changeset. check-governed-merges --pr 29146: 409 changed lines, under the human-merge threshold.
  • Clause-②: yes (widening) and Metadata-protocol: none start their lines in the body and the changeset, as claimed: CalendarViewProps is exported from the package's . entry and gains the optional endEditable (default true). The changeset is patch. The body does not cite the claim id because the id reached the dev after pr_create; its declaration lines match the claim.
• Read in the diff:
  • ObjectCalendar passes endEditable={Boolean(endDateField)}. With false, CalendarView draws no month resize-end handle and no week or day bottom handle, and it refuses a resize-end payload.
  • The default drop handler returns without writing when every date it would write is the instant the record already holds (toDisplayDate). An empty or unparseable stored value never matches, so a drop onto a record with no date still writes.
  • Views with an end field keep both handles and still write the end.
• Gates (check-runs on this head): 44 success, 11 skipped, 0 failed or pending. mergeable_state is clean.
• Tests (dev): new file 13 of 13. Against main's source, 7 fail and the 6 controls pass. Guard ablation reds 2. plugin-calendar 67 files and 490 tests; type-check 50 of 50. Derived gates 34 of 34.
• NOT MEASURED: the seat ran no live session.
• Findings: the week and day Resize start handle with no end field, and calendar-view-renderer not forwarding endEditable, are filed separately.
• Landing: ordinary queue landing, pr_ready then automerge_enable. Fixes #29020 closes the card on merge.

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Contract-review-claim: session_01AavokzJ5DndAwitDXvKy4U · head 88ee38a19eec4f0438a57a088fbd1d56bf5d0609 · 2026-11-02T10:02Z

Taken under references/contract-review.md rule (b): this head has waited over 60 minutes with no record, claim or hand-off on it. At TIER_DEFAULT.

Generated by Claude Code

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Contract review

Served-tier: TIER_DEFAULT
Head-sha: 88ee38a19eec4f0438a57a088fbd1d56bf5d0609
Local-runs: none

① Derived judgments

• Face, right. The committed tree is 4 files: .changeset/29020-calendar-resize-without-end-field.md, ui/packages/plugin-calendar/src/CalendarView.tsx, ui/packages/plugin-calendar/src/ObjectCalendar.tsx and one new test. None is under packages/spec/src/** and none is a governed surface (AGENTS.md Prime Directive feat: Comprehensive CRM example demonstrating all ObjectStack protocol features #14). There is no (narrowing) arm. The review is owed by the Clause-②: yes (widening) line alone, so this is the declaration face at TIER_DEFAULT.
• Public surface: CalendarViewProps.endEditable?: boolean (default true), right. CalendarViewProps is re-exported from the package's only exports entry . (src/index.tsx, the export type { CalendarViewProps, CalendarViewEvent } from './CalendarView' line), so an optional member widens the published type. It is additive and optional, and its default keeps a standalone CalendarView host's behaviour unchanged. MonthViewProps and TimeGridViewProps gain a required endEditable: boolean, but neither is exported (the file's only exports are CalendarViewEvent, CalendarViewProps, CalendarView and the test-only __resolveEventColorForTest), so that change is internal.
• The handle is gated on the declared field, right. ObjectCalendar passes endEditable={Boolean(calendarConfig.endDateField)}. calendarConfig is getCalendarConfig(schema), which reads the declared calendar block only (the endField alias is retired with a refusal, objectui#8355). It is the same endDateField that handleEventDropDefault uses to decide whether to write an end, so whether a handle is drawn and whether an end is written follow one source. At the head, every gesture that moves the end on its own is gated:
  • the month-view handle: showResizeHandle = !!onEventDrop && endEditable && isSpanEnd;
  • the month-view drop: a resize-end payload returns before onEventDrop when !endEditable;
  • the time-grid bottom handle: onEventDrop && endEditable && entry.isEnd.
    handleEventPointerDown sets resize-bottom only from that handle's "bottom" zone, and nothing else produces one. The top "Resize start" handle and the body move are left ungated on purpose (see ③). This matches the card's expected behaviour: no resize handle when the view declares no end field.
• No new key; Metadata-protocol: none, right. endEditable is a TypeScript component prop and not something an author can write in metadata:
  • packages/spec is untouched. CalendarConfigSchema stays a strictObject of the four keys startDateField, endDateField, titleField and colorField.
  • @object-ui/types is untouched.
  • ObjectCalendar computes the prop from the existing endDateField and never reads it from the schema.
  • calendar-view-renderer.tsx forwards a closed set of CalendarViewProps keys with no raw spread, so an authored calendar-view node cannot set the prop either.
    At the head, git grep endEditable outside the tests hits only CalendarView.tsx, ObjectCalendar.tsx and the changeset. No key, accepted value or metadata type is added, so this is not a protocol addition.
• Accept set: the no-op drop guard, right, and not a surface change. sameInstant and the early return in handleEventDropDefault stop the default handler from writing when the start it would write, and any end it would write, already equal the record's values read through toDisplayDate. An empty or unparseable stored value never matches, so a drop onto an empty date still writes. A host's own onEventDrop is not affected. It narrows no published input: it removes a write of unchanged values, which is the card's actual defect (updated_at bumps and after-update triggers fire).
• Gates. All 57 check-runs on this head are complete: 46 success, 11 skipped, 0 failed, 0 pending. These include Check Changeset, Type Check UI, Test UI (1/16 through 16/16), Lint UI, Build & E2E UI and Governed Surface Queue Guard.

② Semver level

• Clause-②: yes (widening) and Metadata-protocol: none each start their own line, in both the PR body and the changeset body. Both are right: the optional exported prop widens the public surface, and no metadata author can write anything new.
• The changeset is '@object-ui/plugin-calendar': patch, which is right. AGENTS.md's Post-Task Checklist step 3 sets the level by the protocol kind alone: kind none takes patch, and "a non-protocol change, widening or breaking, ships patch". Nothing is breaking, so no BREAKING banner, migration or ADR-0087 marker is owed. Check Changeset passed on this head.

③ Boundary flags

• open_questions is [] in the dev's os-dev-report (6572431153). There is nothing to answer.
• Out-of-scope finding 1, answered. With no end field, the time-grid top "Resize start" handle still writes the dragged start, and the event is redrawn an hour long. This is a real write of a changed date, not the card's unchanged-value write, so leaving it outside this PR is right. It is carried by Calendar with no end-date field: the week/day "Resize start" handle still moves the event, and the calendar-view renderer drops endEditable #29197 (open, domain:ui, p2).
• Out-of-scope finding 2, answered. calendar-view-renderer.tsx does not forward endEditable, so authored calendar-view nodes keep the default true. This is outside the claimed file surface, and the card concerns the object calendar view. Keeping it out is also what keeps the prop from being authorable here (see ①). It is carried by Calendar with no end-date field: the week/day "Resize start" handle still moves the event, and the calendar-view renderer drops endEditable #29197, which itself requires "No new metadata key".
• The PR author is objectstack-fleet[bot], so it was written through the relay and no off-relay author note is owed.
• The PR was merged as 10bfd70e before this record. This record judges the merged head and has no must-fix, so no follow-up card is owed.

Implemented-by: claude/project-thread-8vj6zf
Reviewed-by: session_01AavokzJ5DndAwitDXvKy4U

VERDICT: PASS

Generated by Claude Code