docs(data): document MongoDB non-sync boundary

Codex Documentation/Archived plans/V1_BLOCK_09_Persistence_Preparation.md

@@ -1,6 +1,6 @@
 # V1 Block 09 — Persistence Preparation
 
-Status: In progress — Chunks 9.1, 9.2, and 9.3 complete
+Status: Complete
 
 Purpose: Prepare the domain layer for future MongoDB-backed persistence without adding a MongoDB driver, network behavior, sync behavior, or database runtime dependency too early.
 
@@ -170,6 +170,12 @@ Acceptance criteria:
 - Docs distinguish MongoDB persistence preparation from actual sync or database adapter implementation.
 - Wishlist/future notes contain sync as a later feature, not a V1 requirement.
 
+Completed:
+
+- Updated root README to state MongoDB is the committed persistence target while V1 remains adapter-free and runtime-database-free.
+- Updated architecture notes to distinguish MongoDB preparation from MongoDB adapter implementation, sync, accounts, Atlas setup, local server requirements, and background services.
+- Documented sync and actual MongoDB runtime setup as future work, not V1 requirements.
+
 Commit suggestion:
 
 ```text

Codex Documentation/Archived plans/V1_BLOCK_09_Persistence_Preparation_UPDATED.md

@@ -1,6 +1,6 @@
 # V1 Block 09 — Persistence Preparation
 
-Status: In progress — Chunks 9.1, 9.2, and 9.3 complete
+Status: Complete
 
 Purpose: Prepare the domain layer for future MongoDB-backed persistence without adding a MongoDB driver, network behavior, sync behavior, or database runtime dependency too early.
 
@@ -170,6 +170,12 @@ Acceptance criteria:
 - Docs distinguish MongoDB persistence preparation from actual sync or database adapter implementation.
 - Wishlist/future notes contain sync as a later feature, not a V1 requirement.
 
+Completed:
+
+- Updated root README to state MongoDB is the committed persistence target while V1 remains adapter-free and runtime-database-free.
+- Updated architecture notes to distinguish MongoDB preparation from MongoDB adapter implementation, sync, accounts, Atlas setup, local server requirements, and background services.
+- Documented sync and actual MongoDB runtime setup as future work, not V1 requirements.
+
 Commit suggestion:
 
 ```text

Codex Documentation/Current Software Plan/README.md

@@ -1,7 +1,7 @@
 # Current Software Plan
 
-Execute active V1 block documents in numeric order. Blocks 01-08 are completed
-and archived; the next active block is Block 09.
+Execute active V1 block documents in numeric order. Blocks 01-09 are completed
+and archived; the next active block is Block 10.
 
 ## Execution rules
 
@@ -34,5 +34,5 @@ Do not infer a new level name.
 6. `V1_BLOCK_06_Task_Actions_State_Transitions_UPDATED.md` — archived
 7. `V1_BLOCK_07_Child_Tasks.md` — archived
 8. `V1_BLOCK_08_Today_Timeline_State.md` — archived
-9. `V1_BLOCK_09_Persistence_Preparation.md`
+9. `V1_BLOCK_09_Persistence_Preparation.md` — archived
 10. `V1_BLOCK_10_Testing_Documentation_Handoff.md`

Human Documentation/Starter Architecture Notes.md

@@ -57,5 +57,16 @@ remain persistence-independent and testable without a running database. Reposito
 interfaces should be designed so a later MongoDB adapter can persist document-shaped
 models without importing MongoDB APIs into scheduling logic.
 
+Current V1 persistence preparation includes pure Dart repository interfaces,
+in-memory fakes for tests, UTC DateTime conventions, stable enum names, and
+MongoDB-friendly document-shaped map helpers. It does not include a MongoDB
+driver, adapter implementation, connection string, Atlas/cloud setup, local
+MongoDB server requirement, user accounts, network sync, background sync, or
+mobile background reconciliation.
+
+Sync remains future work and should only be added if an active plan explicitly
+asks for it. The core should continue to operate in-memory for tests and local
+domain behavior until a later MongoDB adapter plan is approved.
+
 Do not add alternative database assumptions to this project unless
 the product owner explicitly changes the persistence decision.

README.md

@@ -8,8 +8,12 @@ The repository intentionally starts with a **pure Dart scheduling core** before
 
 - V1/MVP: Today view, backlog/wishlist, quick capture, flexible task pushing, recurring hidden locked blocks, task-state transitions, and a testable scheduling core.
 - V2.0: Week/month views, reports, overwhelm shield, drag-and-drop, task history panels.
-- Persistence direction: MongoDB is the committed database target, but the current core remains database-independent until the active plan adds a MongoDB adapter.
-- Wishlist/future: Dependencies, context tags, advanced sync, long-running task behavior decisions.
+- Persistence direction: MongoDB is the committed database target. Current V1
+  work prepares repository interfaces and document-shaped mappings only; it does
+  not add a MongoDB adapter, connection string, Atlas setup, local server
+  requirement, accounts, sync, or background service.
+- Wishlist/future: Dependencies, context tags, advanced sync, actual MongoDB
+  adapter/runtime setup, long-running task behavior decisions.
 
 ## Repository layout
 
@@ -40,8 +44,9 @@ The repository intentionally starts with a **pure Dart scheduling core** before
 
 Install a Dart SDK that satisfies `pubspec.yaml` first. This starter is a pure
 Dart package, so Flutter is not required for the current core/test loop. MongoDB
-is the planned persistence target, but no database service is required for the
-current in-memory domain/test loop.
+is the planned persistence target, but no MongoDB service, Atlas account,
+connection string, network access, or sync/background process is required for
+the current in-memory domain/test loop.
 
 ```bash
 dart pub get