Atomic recurring schedules and venue wall time
The primary web schedule editor now uses the same canonical series core as the admin API. A create or edit is one database transaction covering its template, rolling occurrence projection or recurrence reconciliation, booked/conflict confirmation, audit evidence, and durable notification obligation. A failed audit or any other database step rolls the whole mutation back; notification delivery can
The primary web schedule editor now uses the same canonical series core as the admin API. A create or edit is one database transaction covering its template, rolling occurrence projection or recurrence reconciliation, booked/conflict confirmation, audit evidence, and durable notification obligation. A failed audit or any other database step rolls the whole mutation back; notification delivery can retry from the outbox without replaying schedule writes. Occurrence instants are built from the occurrence's calendar date plus wall time in the venue's IANA timezone. Copenhagen summer and winter dates therefore retain the operator's intended local time with the correct UTC offset. A spring DST gap is rejected before save. An autumn repeated time exposes explicit Earlier and Later choices (including offsets), and the selected policy is saved on the template for later generator runs. The database independently round-trips every supplied instant through the venue timezone before accepting it. Structural edits reconcile the rolling 30-day window: missing desired occurrences are created, stale unbooked occurrences are cancelled, and a stale booked occurrence is never silently removed. `from_date` begins at that venue's local midnight. A structural rewrite over historical occurrences is intentionally unavailable; operators must correct those classes individually. Client parity classification: - **Business Mobile:** the shared REST contract accepts the new recurrence, streaming, scope, and `ambiguous_time_choice` fields and returns the same refusal codes. A native Earlier/Later picker is still a bounded client UI follow-up before Business Mobile can author a repeated wall time directly. - **Consumer and Branded apps:** no schedule-authoring UI change. They consume the corrected occurrence instants through existing schedule reads. - **Shared-data impact:** yes. All clients see the transactionally reconciled class instances; no public response field was removed or renamed. No new public help or marketing material is required. This is reliability and operator-safety hardening of an existing capability.
Flexible pass publishing works again
Valid Flexible pass drafts can now be published normally; failed attempts kept the saved draft and created no partial pass.