> ## Documentation Index > Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt > Use this file to discover all available pages before exploring further. # Native recurring Calendar events > Create and edit canonical recurring events with explicit scopes. Calendar and the integrated Tasks Calendar offer **Recurring event** in Create. It saves to canonical Tuturuuu Calendar. Daily, weekly, absolute monthly and yearly rules support an interval and no end, an occurrence count, or an inclusive end date. Choose a named time zone: local wall-clock times remain stable across DST. Nonexistent spring-forward slots are skipped; repeated fall-back times use the earlier instant. All-day end dates are exclusive midnight boundaries. Generated occurrences open a dedicated editor. **Only this occurrence**, **Entire series**, and **This and following occurrences** are explicit choices, defaulting to this occurrence. Requests preserve its immutable original slot and use the loaded series revision. Concurrent changes require an explicit reload. Whole-series editing uses the original anchor; future count rules retain remaining slots. Advanced relative-weekday patterns are preserved while editing details. Virtual occurrences never use ordinary event CRUD or drag mutation APIs. Dragging and resizing are disabled; use the scoped editor to move an occurrence. Native ranges revalidate in the background, retaining same-actor data through transport, throttling and temporary failures. Definitive access denial clears retained data. Reads and writes use verified actor lifetimes and separate workspace cache keys. Unchanged failed write intents reuse idempotency keys. Reopening or changing the workspace/account resets form state. Provider recurrence creation and scoped editing remain outside this native UI until provider APIs support them. External calendar adapters retain their existing behavior; the native Create dialog does not select a provider source. Regression evidence: `native-recurrence-model.test.ts` covers DST, validation, all-day boundaries, original identities, remaining counts and retry intent IDs; `native-recurrence-dialog.test.tsx` covers forms, permission and reset behavior; `use-native-calendar-occurrences.test.tsx` covers SWR and actor/permission fences; `use-calendar-readonly.test.tsx` proves virtual mutations cannot reach ordinary write APIs. ## Unsupported provider rules When the provider recurrence pilot is enabled, a complete, stable Google or Outlook snapshot with an unsupported rule becomes **read-only**. The exact raw master and exceptions are retained in an actor/source-bound encrypted journal; no approximate native rule is created. Calendar and integrated Tasks Calendar show a read-only badge and direct the user to the original calendar. Ordinary writes and scoped provider writes check authoritative private state, including when a delayed import loses its visible metadata marker. A previously supported canonical series is hidden rather than left visible with outdated dates. A subsequent supported snapshot restores the same series identity and removes verified legacy duplicates atomically. Publication compares both the captured master ETag and observation hash, so separately edited exceptions cannot overwrite a newer observation. Pending canonical or ordinary provider operations defer this transition; database admission rejects new legacy operations after the read-only state is published. Other calendars and unmatched provider identities remain untouched. The provider mutation pilot remains disabled by default. These checks do not establish authenticated Google/Outlook write parity or enable provider editing in the native creation dialog. Rollout still requires provider runtime verification. Regression evidence: `calendar-provider-readonly.sql`, provider inbound snapshot and service tests, `readonly.test.ts`, and `calendar-provider-readonly.test.ts`. ## Recoverable connected-calendar editor The shared Calendar recurrence editor checks actor-scoped provider capabilities before offering Google or Outlook calendars. Admission remains disabled by production default. An offered connection must belong to the current actor, have active credentials and outbound sync, an explicit writable provider role, and an enabled linked workspace calendar. These configuration capabilities do not prove provider access; each mutation still rechecks credentials and the fresh provider master. Imported provider series always use the provider operation API, including this-occurrence, entire-series and future changes. They never fall back to native series writes. Disabled admission, missing ownership or uncertain capabilities makes the imported series read-only. Native Tuturuuu series retain the native API. Pending provider changes keep fields frozen and expose a continue-synchronization action. The actor/workspace-scoped query cache retains the original intent; only its operation UUID is written to tab-scoped session storage before dispatch. No event content, tokens or account details are persisted there. Refreshing or reopening the dialog resumes that same UUID, and only an applied receipt closes the dialog and invalidates Calendar data. Applied provider receipts also revalidate the affected workspace’s database and provider event projections, including a creation resumed after a reload; pending receipts leave those views intact. If session storage is unavailable, new provider writes fail before dispatch. Cross-device operation history is not provided by this editor. Provider write admission still requires authenticated Google and Outlook parity evidence before production enablement. Regression coverage: provider `capabilities.test.ts`, operation-route tests, `native-recurrence-provider-routing.test.tsx` and `use-provider-recurrence-operation.test.tsx` cover source permissions, native fallback exclusion, ambiguous responses, dialog dismissal, tab reload recovery and actor separation. ### Calendar settings workspace identity Calendar settings resolves route aliases such as `personal` before mounting integration sync or hours/timezone consumers. These consumers and their caches use the resolved workspace ID; resolution failures do not dispatch alias requests to UUID-only Calendar APIs. This applies to the standalone Calendar settings shell. Regression coverage: `apps/calendar/src/components/settings/settings-dialog.test.tsx`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.