Plan Realtime Calendar Event CRUD

Plan realtime Firestore event CRUD for an existing Flutter shared calendar.

Introduction

30 Second Summary

A working shared calendar can be surprisingly fragile when a new feature is copied from another project. One mismatched name can break the parts people already rely on.

In this project, you will map your existing Part 2 before planning realtime event CRUD for its shared calendar. Your plan extends the existing Flutter app with Cloud Firestore while preserving its working sign-in, invitations, routes, styling, and membership model.

What You'll Build

Picture opening your completed plan and seeing every future edit tied to the exact calendar page, user ID, event path, membership record, and regression check in your existing app.

By the end of this project, you'll have:

A compatibility worksheet that records exactly where future event changes belong in the existing app.
A rollback-friendly CRUD sequence for adding event creation, persistence, realtime updates, editing, and deletion without replacing the working architecture.
A regression checklist for confirming that sign-in, invitations, membership access, and the original shared-calendar route still work after each future change.
Secret Mission: Filter the existing realtime schedule by the date already selected in the calendar interface.

Are there any prerequisites?

You need the existing Part 2 source with its current pubspec.yaml and current Firestore Security Rules. You also need a working signed-in shared calendar on your Windows device plus access to its Firebase project.

Before We Start

This is a future-editing plan for your existing Part 2 Flutter shared-calendar project. Before any changes begin, you are committing to preserve its architecture, routes, theme, authentication flow, invitation flow, calendar selection, and membership model through a backup or source-control commit.

Audit the Existing Calendar

Reference names from the appendix can clash with the calendar that already works. A copied path could deny valid members or create a second route.

This audit protects the existing Flutter app before feature work begins. You will capture its Cloud Firestore contract before classifying each reusable event capability.

In this step, get ready to:

Create a rollback point for the existing Part 2 project.
Record the calendar's exact compatibility contract.
Prove the original app passes analysis and opens successfully.

Protect the working project

A rollback point preserves the last known working version of Part 2. It gives every future event edit a safe place to return to.

Press the Windows key to open Windows search.
Type Visual Studio Code into the search field.
Press Enter to start Visual Studio Code.
Select the existing Part 2 project from your recent folders.

Signing in uses your existing account. Keep all credentials outside the compatibility worksheet.

Complete the existing Visual Studio Code sign-in flow if your account is not shown.

Two rollback methods fit this audit. Use the method already supported by your project.

Source-control commit

A source-control commit captures the current project state without duplicating its files.

Review the existing project for uncommitted changes.
Commit the current working state with a message that identifies the pre-edit baseline.
Confirm the source-control history shows the new baseline commit.

Folder backup

A folder-level copy provides a rollback point when the project does not use source control.

Press the Windows key to open Windows search.
Type File Explorer into the search field.
Press Enter to start File Explorer.
Locate the folder that contains the existing Part 2 project.
Copy the complete Part 2 project folder.
Paste the copy beside the original project folder.
Rename the copy so its name identifies it as the pre-edit backup.
Confirm the backup contains pubspec.yaml.
Confirm the backup contains the lib/ folder.

You now have a safe restore point. Future calendar changes are reversible from this baseline.

The route map connects the visible calendar to its existing state sources. Exact identifiers keep future edits inside the working architecture.

Trace the existing route that opens the signed-in shared calendar.
Record the shared-calendar page file here: existing calendar page file.
Record the shared-calendar page class here: existing calendar page class.
Record the calendar route here: existing calendar route.
Trace where the current calendar selection enters that route.
Record the selected calendar ID variable here: selected calendar ID variable.
Trace where the signed-in user identifier enters the calendar flow.
Record the authenticated UID variable here: authenticated UID variable.

Why Record the Existing Names?

The reference appendix uses names such as SharedCalendarPage to describe a possible implementation. An equivalent component in your existing project remains the source of truth.

The same rule applies to the route and state variables. Later edits belong inside the flow you just mapped.

Check the Firestore dependency

The existing dependency constraint may already be compatible with the working project. Preserving that version avoids an unnecessary package change.

Select pubspec.yaml in the Explorer sidebar.
Search pubspec.yaml for cloud_firestore.
Open a PowerShell terminal for the existing Part 2 project.
Confirm the terminal prompt points to the folder containing pubspec.yaml.

Your next action depends on whether the dependency already exists and whether the installed Flutter SDK supports the pinned version.

✔️ Dependency is already present

Keep the existing compatible cloud_firestore version. The final analysis check confirms that the current dependency still resolves.

Leave the existing dependency constraint unchanged.
Record the current dependency status here: current cloud_firestore dependency status.

ⓧ Dependency is missing with compatible Flutter

Check the installed Flutter SDK version by running:

flutter --version

What Does This Command Check?

The command prints the Flutter SDK version used by this project. The pinned Firestore package requires Flutter 3.27.0 or newer.

Continue with the package addition only when the reported version is 3.27.0 or newer.

Add the missing pinned dependency by running:

flutter pub add cloud_firestore:7.1.0

What Does This Command Change?

The command adds cloud_firestore version 7.1.0 to the existing Flutter project. It preserves the current source files while updating the package configuration.

Return to pubspec.yaml.
Confirm the file lists cloud_firestore at the requested 7.1.0 version.
Record the current dependency status here: current cloud_firestore dependency status.

Package Addition Failed?

Confirm the PowerShell prompt points to the existing Part 2 folder. The folder must contain pubspec.yaml.

A dependency-resolution failure can indicate that another package constraint conflicts with the pinned version. Restore the rollback point before testing a different package combination.

Still blocked? Help me diagnose why the pinned cloud_firestore package does not resolve in my existing Flutter project.

ⓧ Dependency is missing with older Flutter

Check the installed Flutter SDK version by running:

flutter --version

What Does This Command Check?

The command prints the current Flutter SDK version. A version below 3.27.0 cannot use the pinned cloud_firestore version from this plan.

Leave pubspec.yaml unchanged.
Record the older Flutter SDK as a compatibility blocker.
Record the current dependency status here: current cloud_firestore dependency status.

Map data access and prove the baseline

The event path decides where shared events live. The membership lookup is enforced by Security Rules.

Search the existing project for code that reads or writes calendar events.
Record the event collection path here: existing event collection path.
Trace the membership check used by the current shared-calendar flow.
Record the membership representation here: existing membership representation.
Record the membership path here: existing membership path.

Why Membership Comes First

Event rules must recognize the same members as the existing calendar. A different membership lookup could reject users who already have valid access.

Firebase account access can feel sensitive. Use the existing project account without placing credentials in the worksheet.

Open the Firebase console for the existing project.
Complete the existing Firebase sign-in flow if prompted.
Select the Firebase project connected to Part 2.
Open the current Firestore rules editor.
Record the existing Security Rules location here: existing Security Rules location.
Record the existing Security Rules contents here: existing Security Rules contents.

Preserve Every Existing Rule

The current rules may protect authentication, invitations, memberships, or calendars. Future event permissions must be merged without removing those rule blocks.

Each existing event capability now needs one decision. The decision describes the smallest safe future change.

How to Classify Each Capability

Mark Keep when the existing capability already provides the required behavior.
Mark Edit when an equivalent capability exists but needs a small addition.
Mark Missing when the existing project has no equivalent capability.

Record the event model decision here: Keep, Edit, or Missing for the event model.
Record the realtime stream decision here: Keep, Edit, or Missing for the realtime stream.
Record the create decision here: Keep, Edit, or Missing for create behavior.
Record the update decision here: Keep, Edit, or Missing for update behavior.
Record the delete decision here: Keep, Edit, or Missing for delete behavior.

The project-specific entries above form the live compatibility map. A companion file now records the exact scope that map must cover.

Create compatibility-worksheet.md beside pubspec.yaml in the existing Part 2 project.
Document the worksheet scope by copying this text into compatibility-worksheet.md:

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior.

What Does This File Record?

The file defines the compatibility worksheet's required scope. The live fields above hold the exact identifiers and decisions from your existing Part 2 project.

Together they prevent future edits from assuming reference names or paths.

Save compatibility-worksheet.md.
Confirm the Explorer sidebar lists compatibility-worksheet.md beside pubspec.yaml.

Worksheet File Missing?

Confirm you created the file inside the existing Part 2 project. It must sit beside pubspec.yaml.

Check the filename for spelling differences. The expected name is compatibility-worksheet.md.

Need help? Help me find why compatibility-worksheet.md is not appearing beside pubspec.yaml in Visual Studio Code.

✔️ Awesome, I've got everything!

Great. Your compatibility scope is saved beside the existing project configuration.

ⓧ I'd like to double check the full code

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior.

How to Compare the File

Compare this reference with your saved file character by character. The sentence should match exactly.

The audit closes by measuring the unchanged project. These checks establish the baseline that every later edit must preserve.

Before you analyze the project, do you expect the untouched Part 2 source to pass its existing checks?

Analyze the existing Dart source by running:

flutter analyze

What Does This Command Prove?

The command analyzes the project's Dart source. A clean result proves the existing baseline resolves before event changes begin.

You should see the analysis finish without reported problems. That result confirms the current source passes its baseline check.

Analysis Reports Problems?

Confirm the PowerShell prompt points to the existing Part 2 folder containing pubspec.yaml.

If the issue appeared after adding the dependency, restore the rollback point before changing another package constraint.

Need a second pair of eyes? Help me interpret my Flutter analysis result without replacing existing project files.

An existing Flutter build can take a few minutes while dependencies resolve. That pause is normal.

Before you launch the app, do you expect the original shared-calendar route to look the same as it did before the audit?

Choose the existing Windows target if Flutter asks for a device.
Launch the existing Part 2 app by running:

flutter run

What Does This Command Prove?

The command builds and runs the existing Flutter program. PowerShell stays attached to the app while it is running.

Complete the existing sign-in flow with the current Firebase Authentication account if prompted.
Open the original shared-calendar route.

You should see the existing calendar design with its original navigation. The signed-in shared-calendar flow should still open successfully.

That is the baseline secured. Your working app now has a rollback point and a compatibility map for every future event edit.

Original Calendar Does Not Open?

Confirm PowerShell is running from the existing Part 2 folder. The same folder must contain pubspec.yaml.

Confirm the selected Windows target can run the existing app. Restore the rollback point if the original route changed during the audit.

Still blocked? Help me diagnose why my existing signed-in Flutter calendar no longer opens after this audit.

Leave the Flutter process running for the next step.
Stop it later by pressing Ctrl+C in PowerShell.

Your original calendar still works, and its exact compatibility contract is recorded. Next, you can add only the data pieces that the audit marked for editing or creation.

Plan the Missing Event Data

Your audit pinned down the names and paths that already power the shared calendar. That map protects the working Flutter route from duplicate screens or competing event state.

This section turns those findings into a minimal Cloud Firestore event plan. Every planned addition fills a confirmed gap.

In this step, get ready to:

Map the existing event types to the reference data shapes.
Define one repository plan for the missing CRUD behavior.
Protect the original calendar route as the only interface source.

Map the existing event types

An event model translates stored documents into values the interface can display. The reference names guide your comparison without forcing new class names into the existing project.

Switch back to Visual Studio Code from earlier.
Select compatibility-worksheet.md in the Explorer sidebar.
Use the recorded shared-calendar page file to locate the current event type.
Compare its properties with title, start, end, and createdBy.
Record either the existing model or a planned CalendarEvent addition in the worksheet.
Locate the current type that carries values from the event form.
Record either that existing type or a planned EventDraft addition in the worksheet.

Why separate stored events from drafts?

CalendarEvent represents an event retrieved from storage. It carries the document ID plus title, start, end, and createdBy.
EventDraft carries the editable title, start, and end values. The repository supplies storage-specific values when it creates a document.

Define the data access plan

A snapshot stream sends event changes to the schedule as matching documents change. Planning one stream keeps the existing schedule synchronized without introducing a second local event list.

Use the recorded event collection path to locate the current Firestore service.
Record either the existing service or a planned EventRepository addition in the worksheet.
Mark watchEvents as Keep if the existing service already exposes one event stream.
Mark createEvent as Keep if the existing service already writes valid events.
Mark updateEvent as Keep if the existing service already updates editable event fields.
Mark deleteEvent as Keep if the existing service already deletes one selected event.
Record the selected calendar ID as the repository input.
Record the authenticated user ID as the source for createdBy.

Keep one source of truth

The future implementation creates the event stream once outside repeated widget rebuilds. The original schedule area consumes that stream.

This plan excludes a parallel page or local event source. One route owns the interface.

Keep the recorded event collection path unchanged in the plan.
Keep the recorded membership path unchanged in the plan.
Mark any parallel page or listener as excluded from the future implementation.

Lock the worksheet and verify the baseline

The compatibility worksheet now acts as the change contract for the future implementation. Its final summary must preserve every recorded path while naming only the missing data behavior.

Append this sentence to compatibility-worksheet.md:

Updated with the existing equivalents or planned additions for CalendarEvent, EventDraft, EventRepository, watchEvents, createEvent, updateEvent, deleteEvent, title, start, end, and createdBy, while retaining the recorded existing event and membership paths.

Save compatibility-worksheet.md.

✔️ Awesome, I've got everything!

Your saved worksheet now records the smallest compatible event data plan.

ⓧ I'd like to double check the full code

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, cloud_firestore dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for CalendarEvent, EventDraft, EventRepository, watchEvents, createEvent, updateEvent, deleteEvent, title, start, end, and createdBy, while retaining the recorded existing event and membership paths.

Switch back to Windows PowerShell from earlier.
Confirm the current project still analyzes cleanly by running:

flutter analyze

What does this check prove?

The analyzer checks the existing Dart source without applying the worksheet plan. A clean result confirms that this planning step has preserved the working code baseline.

You should see the analysis finish without reported issues. Your worksheet update has left the application source untouched.

Does the analyzer report an issue?

Confirm that the PowerShell prompt points to the existing project folder containing pubspec.yaml.
Compare the reported source file with your backup because this step should only change compatibility-worksheet.md.

Need another pair of eyes? Help me understand why my unchanged Flutter baseline now fails analysis.

Before you check the app, do you expect this plan-only update to alter the original calendar route?

Return to the existing signed-in Flutter app from earlier.
Use the recorded original calendar route to display its schedule area.

You should see the same shared-calendar page with its original schedule area. The plan has not created a parallel page or event source.

Strong work. Your worksheet now defines the smallest event data change that fits the existing app. Next up, you can plan the creation flow around these recorded types and paths.

Plan Event Creation

A create flow can look correct while still bypassing the architecture of your existing Flutter calendar. A temporary local implementation gives you a controlled way to prove that the current interface accepts a complete event.

This step turns your compatibility map into a rollback-friendly create sequence. You will preserve the current action, form, theme, navigation, route, schedule area, event model, and page state.

In this step, get ready to:

Map the existing Add Event action to the current form or the reference dialog.
Plan how the form validates its values before constructing an event draft.
Document the temporary local-state checkpoint for the future implementation.

Map the existing create entry point

The current Add Event action already belongs to the established calendar route. Reusing that entry point keeps the new flow inside the interface your signed-in members already use.

Locate the existing Add Event action recorded in your compatibility worksheet.
Mark the current event form as Keep when it already collects the required values.
Mark the current event form as Edit when it needs only missing validation or fields.
Choose the reference EventEditorDialog only when the existing Part 2 has no equivalent form.
Keep the existing theme as the visual source of truth.
Keep the existing navigation behavior as the routing source of truth.

Why reuse the current action?

The existing action already has the selected calendar context. Reusing it prevents a second route from competing with the original calendar screen.

The result stays inside the schedule area you mapped earlier. That creates one visible place to test event creation.

Plan validation and draft creation

The form needs a complete set of values before it can produce an EventDraft. The reference dialog keeps those values in state until _save confirms that the draft is valid.

Map the current title input to _titleController when adapting the reference dialog.
Keep TextEditingController as the controller type for the title input.
Map the selected event date to _date.
Map the chosen start time to _startTime.
Map the chosen end time to _endTime.
Use _pickTime for each time-picker interaction when the current form has no equivalent helper.
Reserve _errorText for title or time validation feedback.
Return an EventDraft from _save after validation passes.

How the dialog plan fits

The optional CalendarEvent value lets the same reference dialog support a future edit flow.
The _titleController value supplies the trimmed event title.
The _date value supplies the event year, month, and day.
The _startTime value supplies the starting hour and minute.
The _endTime value supplies the ending hour and minute.
The _save method rejects an empty title.
The _save method rejects an end time that does not follow the start time.
A successful save returns one EventDraft to the existing Add Event action.

Document the temporary create checkpoint

The first future implementation appends the validated draft only to the existing page state. This isolates the interface test from the later Cloud Firestore write.

Before you record the restart checkpoint, do you think an event stored only in page state will survive a full app restart?

Plan to create one event through the existing Add Event action.
Plan to confirm that the event appears in the current schedule area.
Plan to restart the app from PowerShell after the event appears.

The temporary event disappears after the restart because page state exists only for the current app process. That intended result proves the interface works while exposing the missing persistence layer.

Plan to remove only the temporary append when repository-backed creation replaces it.
Plan to preserve the existing Add Event action during that replacement.
Plan to preserve the existing schedule area during that replacement.

Why keep the temporary append small?

A single local append is easy to identify after the restart test. Removing only that append keeps the validated form integration intact for the repository handoff.

In Visual Studio Code, select compatibility-worksheet.md from the existing project files.
Find this current content:

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for `CalendarEvent`, `EventDraft`, `EventRepository`, `watchEvents`, `createEvent`, `updateEvent`, `deleteEvent`, `title`, `start`, `end`, and `createdBy`, while retaining the recorded existing event and membership paths.

What does this reference show?

This is the compatibility record from the previous planning step. It maps the existing data pieces without recording the create-flow sequence yet.

Replace the current content with the expanded plan below:

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for `CalendarEvent`, `EventDraft`, `EventRepository`, `watchEvents`, `createEvent`, `updateEvent`, `deleteEvent`, `title`, `start`, `end`, and `createdBy`, while retaining the recorded existing event and membership paths. Includes the future Add Event sequence: reuse the current action and form where possible; otherwise adapt `EventEditorDialog`; validate title, date, start time, and end time; create an `EventDraft`; prove temporary local state behavior; restart to confirm non-persistence; then remove the temporary append when Firestore creation replaces it.

What changed in the worksheet?

The final sentence records the complete future create-flow sequence. It preserves the current interface before documenting the temporary local checkpoint.

The sequence ends with a narrow replacement boundary. Only the temporary append is removed when persistent creation is introduced.

Save compatibility-worksheet.md.

Before you compare the saved worksheet, which action should follow the future restart checkpoint?

Compare the final sentence with the full reference below.

✔️ Awesome, I've got everything!

Your worksheet now preserves the current interface while defining the temporary create test. The plan is ready for a future rollback-friendly implementation.

ⓧ I'd like to double check the full code

Compare your entire compatibility-worksheet.md file with this reference.

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for `CalendarEvent`, `EventDraft`, `EventRepository`, `watchEvents`, `createEvent`, `updateEvent`, `deleteEvent`, `title`, `start`, `end`, and `createdBy`, while retaining the recorded existing event and membership paths. Includes the future Add Event sequence: reuse the current action and form where possible; otherwise adapt `EventEditorDialog`; validate title, date, start time, and end time; create an `EventDraft`; prove temporary local state behavior; restart to confirm non-persistence; then remove the temporary append when Firestore creation replaces it.

What should match?

Your file should contain this single paragraph exactly. The final sentence should end with the replacement of the temporary append by Firestore creation.

You should see the current action and form reused first. You should then see the local-state test followed by the restart checkpoint and the later Firestore handoff.

Does the worksheet differ?

Check that the original compatibility record still appears before the new final sentence.
Remove any extra plan that creates a parallel route, form, schedule area, or local event source.
Confirm that the sequence removes only the temporary append during the future repository handoff.

Still seeing a mismatch? Help me compare my event creation plan with the required compatibility worksheet.

Your create plan now has a controlled interface test plus a deliberate restart checkpoint. Next, you will plan how repository-backed creation replaces the temporary append without disturbing the existing calendar flow.

Plan Realtime Firestore Sync

Your create-flow plan now proves the existing interface before any remote write touches the app. Its restart check deliberately exposes the temporary event's persistence gap.

This step plans how Cloud Firestore closes that gap. You will map the recorded event path to one repository write plus one realtime stream.

In this step, get ready to:

Map the recorded calendar ID to the existing event collection path.
Plan the repository write that persists each event's required fields.
Plan one realtime stream for the existing schedule.

Map the existing event destination

The selected calendar ID keeps each event attached to the correct shared calendar. The recorded event path remains the source of truth for future reads plus writes.

Return to compatibility-worksheet.md in Visual Studio Code.
Locate the selected calendar ID variable already recorded in the worksheet.
Locate the event collection path already recorded beside it.
Choose the recorded event path as the future write destination.
Use calendars/{calendarId}/events/{eventId} only when the worksheet marks the event path as missing.

Why preserve the existing path?

An existing path may already contain event documents or support current queries. Preserving it keeps one source of calendar data.

The reference path supplies a fallback when no event structure exists. Your compatibility worksheet decides which path wins.

Design one write and one stream

The planned EventRepository places event persistence behind the existing calendar page. The page can keep its current route plus visual structure.

Identify the temporary local append from the future create-flow sequence.
Match the EventDraft values to title, start, end, plus createdBy.
Choose the existing repository create method when an equivalent already exists.
Use EventRepository.createEvent only when the project needs the reference method.
Reserve CollectionReference.add for missing repository-backed creation behavior.
Map createdBy to the authenticated UID recorded in the worksheet.

How is the repository divided?

FirebaseFirestore supplies the database instance held by _firestore.
_events points to the mapped event collection.
watchEvents owns the ordered event snapshot stream.
createEvent persists a validated EventDraft.
updateEvent keeps future event edits inside the same repository.
deleteEvent keeps future event removal inside the same repository.

The planned page state keeps _repository, _eventsStream, plus _selectedDate as long-lived fields. It routes editor behavior through _openEditor, _createEvent, _editEvent, _deleteEvent, plus _showMessage.

Plan _repository construction once in initState.
Plan _eventsStream assignment once from _repository.watchEvents().
Keep _selectedDate as the existing calendar UI state.
Render the existing schedule from the Stream<List<CalendarEvent>>.
Remove duplicate snapshot listeners after realtime rendering works.
Remove parallel local event lists after realtime rendering works.

Why create the stream once?

Widget rebuilds can happen whenever page state changes. A stream created once keeps those rebuilds from establishing repeated listeners.

One listener also gives the existing schedule a single event source. That makes restart persistence plus cross-member updates easier to verify.

Record the realtime checkpoint

The worksheet needs one rollback-friendly sentence that connects the path decision to the future verification. This checkpoint keeps the implementation sequence concise.

Return to compatibility-worksheet.md.
Locate the paragraph's final sentence about the future Add Event sequence.
Append the following sentence to the same paragraph:

Includes the future realtime sequence: map the recorded calendar ID to the recorded event path, persist `title`, `start`, `end`, and `createdBy`, create one stream outside rebuilds, render the existing schedule from that stream, remove duplicate listeners and local lists, and verify persistence across restart plus cross-member realtime updates.

What does this checkpoint capture?

The path clause protects the event location already chosen by the existing project.
The field clause defines the complete persisted event record.
The stream clause keeps realtime rendering outside repeated rebuilds.
The cleanup clause removes competing listeners plus local event sources.
The verification clause requires persistence after restart plus an update in another authorized member session.

Save compatibility-worksheet.md.
Read the final paragraph in the editor to confirm the new sentence follows the Add Event sequence.

You should see one continuous paragraph ending with the future realtime sequence. The original compatibility notes remain above it unchanged.

Does the worksheet differ?

Remove any new reference path when the worksheet already records an existing event path.
Keep the realtime sentence inside the existing paragraph.
Restore any compatibility notes that changed during the edit.

Still seeing a mismatch? Help me compare my compatibility worksheet with the required realtime checkpoint.

Before you compare the finished worksheet, do you expect the plan to introduce a second event path or preserve the path already recorded?

✔️ Awesome, I've got everything!

Solid work. Your compatibility worksheet now connects the temporary create flow to one persistent realtime event source.

ⓧ I'd like to double check the full code

Compare your saved compatibility-worksheet.md with this complete reference:

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for `CalendarEvent`, `EventDraft`, `EventRepository`, `watchEvents`, `createEvent`, `updateEvent`, `deleteEvent`, `title`, `start`, `end`, and `createdBy`, while retaining the recorded existing event and membership paths. Includes the future Add Event sequence: reuse the current action and form where possible; otherwise adapt `EventEditorDialog`; validate title, date, start time, and end time; create an `EventDraft`; prove temporary local state behavior; restart to confirm non-persistence; then remove the temporary append when Firestore creation replaces it. Includes the future realtime sequence: map the recorded calendar ID to the recorded event path, persist `title`, `start`, `end`, and `createdBy`, create one stream outside rebuilds, render the existing schedule from that stream, remove duplicate listeners and local lists, and verify persistence across restart plus cross-member realtime updates.

What should match?

The complete reference preserves every earlier compatibility decision. Its only new content is the final future realtime sequence.

The final sentence anchors writes to the recorded event path. It names the four persisted fields. It creates one stream outside rebuilds. It removes duplicate listeners plus local lists. It requires restart persistence plus a cross-member realtime update.

Your worksheet now has a path-safe plan for persistent realtime events. Next, you can plan explicit edit plus delete controls before merging member-only rules.

Plan Edit, Delete, and Rules

Your future sync plan now persists events through Cloud Firestore. It also feeds the existing schedule from one realtime stream.

The last planning gap is full event control. Careless updates can overwrite the event creator.

Member-only Security Rules must fit around the rules that already protect Part 2. A regression plan proves the original shared-calendar experience survives the future change.

In this step, get ready to:

Plan event edits that preserve document identity.
Plan confirmed deletion under member-only access.
Record regression checks for every existing shared-calendar flow.

Plan safe event edits

An event update should change only the fields a member can edit. The existing document remains the same event throughout the update.

The future editor receives the selected CalendarEvent so it can prefill the current values. The update keeps the original document identity.

Return to compatibility-worksheet.md in Visual Studio Code.
Find the recorded Keep, Edit, or Missing decision for update behavior.
Map an explicit edit control to the existing event card.
Route the selected CalendarEvent into the existing or adapted editor.
Restrict the future update to title, start, and end.
Preserve the existing event document ID.
Preserve the existing createdBy value.

Plan confirmed deletion and member-only rules

A confirmation dialog gives the member one final checkpoint before deletion. The delete operation then targets only the selected event document.

The isCalendarMember helper centralizes the membership lookup. The future event block points it at the membership path already recorded in the worksheet.

Map an explicit delete control to the existing event card.
Require a confirmation dialog before calling deleteEvent.
Target the selected event document with deleteEvent.
Point isCalendarMember at the recorded membership document path.
Use eventFieldsAreValid to validate title, start, end, and createdBy.
Require createdBy to match request.auth.uid during creation.
Restrict updates to title, start, and end.
Preserve every existing rule block when the event block is merged.

Why merge the event rules?

The existing rule blocks protect working Part 2 behavior such as invitations or membership access. Keeping those blocks retains the current access decisions.

The merged event block adds member reads, protected creates, limited updates, and member deletes. One rules file continues to protect the whole app.

Record the regression sequence

A focused feature can still disturb nearby behavior. The regression sequence checks the original app after the future event changes are complete.

Add the complete future edit, delete, rules, and regression sequence to the end of compatibility-worksheet.md by appending this sentence:

Includes the future edit, delete, rules, and regression sequence: add explicit event-card controls, preserve document ID and creator during updates, confirm deletions, merge `isCalendarMember` and `eventFieldsAreValid` rules into current rules without deleting existing blocks, test member and non-member access, and retest sign-in, invitations, calendar opening, navigation, theme, and membership flows.

What does this plan capture?

Explicit controls extend the existing event cards.
Updates preserve the document ID plus the original creator.
Member-only event rules extend the current rules file.
Regression checks cover access behavior plus the original shared-calendar experience.

Save compatibility-worksheet.md.

Before you compare the worksheet, which existing flows do you expect the regression sequence to protect?

Compare the final sentence in compatibility-worksheet.md with the reference below.

You should see the original five sentences unchanged. A sixth sentence should begin with Includes the future edit, delete, rules, and regression sequence:.

That closes the final planning gap. Your worksheet now protects event identity, member access, and the working Part 2 experience.

Does the worksheet differ?

Check that the earlier five sentences still match the prior worksheet.
Replace only the final sentence with the supplied reference text.

Still seeing a mismatch? Help me compare my compatibility worksheet with the required final artifact.

✔️ Awesome, I've got everything!

Your worksheet now contains the complete future implementation plan. The existing Part 2 project remains unchanged.

ⓧ I'd like to double check the full code

The full worksheet should match this reference exactly.

Created for the future implementation. Records the existing calendar page file and class, calendar route, selected calendar ID variable, authenticated UID variable, event path, membership path and representation, existing Security Rules location and contents, `cloud_firestore` dependency status, and Keep/Edit/Missing decisions for event model, realtime stream, create, update, and delete behavior. Updated with the existing equivalents or planned additions for `CalendarEvent`, `EventDraft`, `EventRepository`, `watchEvents`, `createEvent`, `updateEvent`, `deleteEvent`, `title`, `start`, `end`, and `createdBy`, while retaining the recorded existing event and membership paths. Includes the future Add Event sequence: reuse the current action and form where possible; otherwise adapt `EventEditorDialog`; validate title, date, start time, and end time; create an `EventDraft`; prove temporary local state behavior; restart to confirm non-persistence; then remove the temporary append when Firestore creation replaces it. Includes the future realtime sequence: map the recorded calendar ID to the recorded event path, persist `title`, `start`, `end`, and `createdBy`, create one stream outside rebuilds, render the existing schedule from that stream, remove duplicate listeners and local lists, and verify persistence across restart plus cross-member realtime updates. Includes the future edit, delete, rules, and regression sequence: add explicit event-card controls, preserve document ID and creator during updates, confirm deletions, merge `isCalendarMember` and `eventFieldsAreValid` rules into current rules without deleting existing blocks, test member and non-member access, and retest sign-in, invitations, calendar opening, navigation, theme, and membership flows.

Secret mission

Filter the Existing Schedule by Selected Date

Use the date already selected in the existing calendar to filter its realtime schedule. Plan a two-date check that proves the filter keeps create, edit, delete, and synchronization working.

Clean Up Your Resources

This outline created only compatibility-worksheet.md, with no app changes or ongoing cloud costs. Decide whether to keep the plan, pause your work, or delete the planning artifact.

Cost warning

The planning work starts no listeners. It creates no Cloud Firestore documents.

Normal learning usage during future implementation stays inside the free quota.

Realtime listeners consume reads when result documents change. Membership lookups in Security Rules can add dependent-document reads.

Resources you used:

The compatibility-worksheet.md planning file containing the future implementation plan and regression checklist.

Keep everything running

No action needed. Choose this if you want to use the worksheet during the future implementation.

Keep compatibility-worksheet.md alongside the existing Part 2 source.
Retain the project backup or source-control commit as your rollback point.
Leave the existing app source and cloud data unchanged.

Pause - I'll come back to this later

Close the planning tools to pause your work. Keep the worksheet and rollback point so you can resume safely.

Close compatibility-worksheet.md in Visual Studio Code.
Stop the existing Flutter app by pressing Ctrl+C in PowerShell if the app is currently running.
Retain the backup or source-control commit for the future implementation.

Delete - I don't want to use this again

Remove the planning artifact if you want to discard this outline.

Deleting the worksheet can feel final. Your existing Part 2 app remains untouched.

In Visual Studio Code, select compatibility-worksheet.md from the file list in the left sidebar.
Press the Delete key.
Confirm the deletion if Visual Studio Code asks.
Check that compatibility-worksheet.md no longer appears in the file list.

That cleanup is complete. The written plan is gone while the existing app and its data remain intact.

No test event documents need deleting because this planning section created none.

Nice Work!

You made it! You completed a compatibility-first editing plan for adding realtime event CRUD to the existing shared calendar while preserving its working architecture.

You've learned how to:

Build a compatibility map that records the existing route, identifiers, data paths, dependency state, membership model, and rules before future edits begin.
Design an incremental CRUD sequence that reuses the current model, repository, schedule, form, and event path. Each future change ends with a visible run or regression check.
Plan a safe merge of member-only Cloud Firestore Security Rules without removing existing rule blocks. The regression plan protects sign-in, invitations, calendar opening, navigation, theme, and membership flows.
Plan the optional Secret Mission to filter the realtime schedule with _selectedDate and _sameDay. The plan keeps one Firestore listener while showing visibleEvents, an Events on label, and a date-specific empty state.

Ready to quiz yourself?