# 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.