51 lines
1.7 KiB
Markdown
51 lines
1.7 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.
|
|
|
|
Flexible end-of-day rollover should use an explicit source-day window when
|
|
available. That prevents planned flexible tasks from future days from being
|
|
pulled into tomorrow during recovery.
|
|
|
|
Backlog staleness in the current V1 domain model uses task creation age for both
|
|
the stale filter and green/blue/purple marker. A later MongoDB-backed
|
|
persistence pass may add a separate backlog-entered timestamp, but the current
|
|
core keeps the timestamp semantics consistent and database-independent.
|
|
|
|
## 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.
|