focus-flow/Human Documentation/Starter Architecture Notes.md

Starter Architecture Notes

Initial architecture decision

Start as a pure Dart scheduling-core package. Do not begin with UI. The scheduling rules are the hardest and most important part of the product, and they should be testable without a Flutter app running.

Future shape

Flutter UI
  ↓
View/application state
  ↓
Pure Dart scheduling core
  ↓
Repository interfaces
  ↓
MongoDB persistence adapter (planned later)
  ↓
Future sync layer, if explicitly planned

Why pure Dart first

• Easier to test scheduling rules.
• Less UI noise for Codex.
• Cleaner migration into Flutter later.
• Avoids premature sync/background complexity.

Key invariant

The scheduling core must never move locked or inflexible blocks during automatic rescheduling.

Persistence direction

MongoDB is the committed persistence target. The V1 scheduling core should still remain persistence-independent and testable without a running database. Repository interfaces should be designed so a later MongoDB adapter can persist document-shaped models without importing MongoDB APIs into scheduling logic.

Do not add alternative database assumptions to this project unless the product owner explicitly changes the persistence decision.