# 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

```text
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.