32 lines
761 B
Markdown
32 lines
761 B
Markdown
# 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.
|