Circuit-Forge/focus-flow
6
0
Fork 0
forked from eva/focus-flow
Code Pull requests Activity
focus-flow/archive/Archived plans/PLAN_REVIEW_SUMMARY.md

2.8 KiB
Raw Blame History

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.