forked from eva/focus-flow
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# Planning Review Summary
|
||
|
||
Status: Planning artifact
|
||
|
||
## What the archived work established
|
||
|
||
Blocks 01–10 completed a well-tested pure Dart scheduling core. The repository
|
||
already contains the main domain concepts, scheduling operations, recurring
|
||
locked-block expansion, Backlog/quick capture, task actions, surprise logging,
|
||
child ownership/completion, UI-independent timeline mapping, basic internal
|
||
statistics, repository interfaces, in-memory fakes, and task/statistics document
|
||
mappings.
|
||
|
||
That work should be preserved and extended rather than restarted.
|
||
|
||
## Why the next work starts below the UI
|
||
|
||
The current UI-independent modules are individually useful, but a Flutter screen
|
||
would still have to assemble scheduling inputs, coordinate several repositories,
|
||
apply multiple task/stat/project mutations, interpret English notices, and save
|
||
multi-record changes itself. That is too much correctness responsibility for the
|
||
UI.
|
||
|
||
The active sequence therefore completes:
|
||
|
||
1. domain/time invariants
|
||
2. one scheduling occupancy policy
|
||
3. lifecycle/statistics/project/reminder policy
|
||
4. atomic application use cases and read models
|
||
5. complete versioned persistence contracts
|
||
6. a trusted MongoDB runtime adapter
|
||
7. integrated backend acceptance
|
||
|
||
Only then does the plan create a provisional Flutter shell and one vertical
|
||
slice.
|
||
|
||
## Highest-risk findings
|
||
|
||
- Free Slots exist as a task type but are not included consistently as protected
|
||
scheduler occupancy.
|
||
- Surprise tasks repair the immediate overlap, but their completed interval is
|
||
not consistently treated as future same-day occupancy by all operations.
|
||
- Recurring/local calendar semantics are represented with `DateTime` in ways that
|
||
can shift a date-only override when serialized as UTC.
|
||
- Task and task-statistics mappings are implemented, while projects, locked
|
||
records, settings, activities, and scheduling state are not fully mapped.
|
||
- Multi-task scheduling mutations have no application-level atomic transaction;
|
||
a future UI could accidentally persist only part of a result.
|
||
- Statistics counters exist but completion/locked-hour/project aggregation is not
|
||
wired through one exactly-once transition path.
|
||
- Reminder profile metadata exists only on projects; task overrides and
|
||
protected-rest policy are absent.
|
||
- The current timeline mapper is not yet a complete Today query and has a compact
|
||
“current versus next flexible” edge case.
|
||
- MongoDB is the committed target, but the trusted runtime/credential boundary is
|
||
not selected. The plan prohibits putting production credentials in Flutter.
|
||
|
||
## Plan outcome
|
||
|
||
When Blocks 11–17 are complete, the Flutter UI should be able to consume a small,
|
||
typed application facade for every V1 user intent. It should not need to know how
|
||
scheduling, statistics, migrations, transactions, or MongoDB work.
|