web: new recurring event opens update scope dialog

[tyler-dane]

Bug report

Creating a new timed recurring event opens the "Apply Changes To" recurrence update-scope dialog before the event is saved. This interrupts first-time recurring event creation and asks the user to choose an edit/delete scope even though there is no existing series to scope.

Where it happened

Route: /week
Screen/feature: Week timed grid event form, recurrence/repeat controls, new recurring event save
Environment/account state: reporter screenshot from app.compasscalendar.com/week in Chrome, Google-connected account visible in sidebar

Workflow

1. Click an empty slot in the timed week grid.
2. Enter a title after the event form opens.
3. Click the repeat icon in the form to make the new event recurring.
4. Click Save.
5. The "Apply Changes To" dialog appears with This Event, This and Following Events, and All Events.

Expected outcome

The new recurring event should be created immediately and rendered on the calendar. No update-scope dialog should appear during first-time recurring event creation.

Screenshot

Diagnosis

Reproduction status: reporter provided a concrete workflow and screenshot showing the modal over /week; I did not run the full end-to-end flow locally during capture.

Code evidence points to the web draft confirmation gate opening the scope dialog before the submit action has a chance to classify the draft as a create. In packages/web/src/views/Week/components/Draft/hooks/state/useDraftConfirmation.ts, onSubmit computes draftIsRecurring = Array.isArray(rule) || draftIsInstance and then opens the recurrence update-scope dialog whenever isRecurringEvent is true. A brand-new recurring draft has no _id, but it does have recurrence.rule, so this condition treats creation like an existing recurring-series mutation.

The downstream submit path in packages/web/src/views/Week/components/Draft/hooks/actions/useDraftActions.ts already distinguishes creates with const isExisting = !!draft._id; if (!isExisting) return "CREATE";, then dispatches createEventSlice.actions.request(...). The dialog gate appears to be bypassing that intended create path for recurring drafts.

Relevant acceptance docs support the expected behavior: docs/Acceptance/recurring-events.md says the scope dialog appears when editing or deleting an instance/base recurring series, while Scenario 1 creates a weekly recurring event and expects the series to appear after submit.

Confidence: high for the frontend gate being the cause; medium until confirmed with a failing web test or local browser reproduction.

Likely fix

Start in packages/web/src/views/Week/components/Draft/hooks/state/useDraftConfirmation.ts. Scope-dialog prompting should only apply to mutations of existing recurring events/instances, not newly-created drafts. A minimal fix is likely to guard the recurrence dialog branch with an existing-event check such as _draft._id or reuse/align with the submit action's create-vs-update decision, while preserving existing behavior for:

• editing a recurring base event
• editing a generated recurring instance
• deleting recurring events
• converting an existing instance to standalone
• Someday recurrence behavior

Add or update a focused web test around useDraftConfirmation.onSubmit or the event form flow to assert that a draft without _id but with recurrence.rule calls create submit without opening RecurringEventUpdateScopeDialog.

Verification

1. Run the focused web test covering new recurring timed event submission.
2. Manually verify on /week: click timed grid, add title, enable Repeat, Save. The event series should render and the "Apply Changes To" dialog should not appear.
3. Regression-check an existing recurring event edit still opens the scope dialog with the expected options.
4. Run bun test:web before handoff/push.