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
  ↓
Local persistence, likely SQLite/Drift later
  ↓
Future sync layer

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.