forked from eva/focus-flow
43 lines
1.2 KiB
Markdown
43 lines
1.2 KiB
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
|
|
↓
|
|
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.
|