Document future project history architecture

docs/spec/07-implementation-phases-todo.md

@@ -300,3 +300,72 @@ Acceptance criteria:
 - undo/redo does not disrupt the current reading position
 - the editor remains usable without overflowing the browser layout
 - active filters are easy to understand, change and clear
+
+## Phase 11: Persistence and Transaction Foundation
+
+Goal:
+
+Prepare the current SQLite implementation for persistent history and a later PostgreSQL adapter without changing user-facing behavior.
+
+Tasks:
+
+- add real SQLite integration tests for transaction commit and rollback
+- introduce an injectable transaction / unit-of-work boundary
+- remove direct database-client access from domain services
+- treat synchronous SQLite transactions as an adapter detail
+- remove dead persistence methods after coverage exists
+- verify database backup and restore independently from project history
+
+Acceptance criteria:
+
+- critical multi-write commands roll back completely in a real database test
+- domain command behavior is not coupled to `better-sqlite3`
+- adding a PostgreSQL persistence adapter does not require rewriting editor domain rules
+
+## Phase 12: Project Revisions and Persistent Undo / Redo
+
+Goal:
+
+Persist project-wide change history and restore points across reloads and application restarts.
+
+Tasks:
+
+- add project-scoped monotonic revisions
+- record immutable server-side change sets with before/after state
+- add optimistic revision checks for stale commands
+- persist undo/redo eligibility on the server
+- add named and periodic logical project snapshots
+- restore a historical snapshot as a new revision
+- keep database backups separate from logical history
+
+Acceptance criteria:
+
+- undo/redo remains available after a page reload
+- every logical command and inverse is atomic and auditable
+- restoring an older state does not delete intervening history
+- concurrent stale commands cannot silently overwrite newer project state
+
+## Phase 13: External Model Round-Trip
+
+Goal:
+
+Exchange model objects and planning parameters with Revit or comparable tools through CSV or another agreed format.
+
+Tasks:
+
+- model external sources, import batches and stable IFCGUID objects
+- stage and validate imports before applying them
+- show additions, changes, missing objects and conflicts
+- link external objects explicitly to project-domain entities
+- apply an import as one auditable project revision
+- configure inbound and outbound parameter mappings
+- export against a known project revision while preserving IFCGUID
+
+Acceptance criteria:
+
+- repeated imports match objects deterministically by source and IFCGUID
+- imports never silently overwrite local planning values
+- users approve the diff before it changes the project
+- exported data can be assigned back to the correct Revit objects
+
+PostgreSQL should be introduced when shared multi-user operation, background jobs or operational scale justify it. External-object count alone does not require an immediate migration.