# V1 Block 09 — Persistence Preparation

Status: Planned

Purpose: Prepare the domain layer for local persistence without overbuilding sync or database implementation too early.

## Chunk 9.1 — Repository interface

Recommended Codex level: medium

Tasks:

Define repository interfaces for:

- tasks
- projects
- locked blocks
- scheduling operations/state snapshots

Rules:

- Do not couple scheduling engine directly to SQLite.
- Use interfaces that a future Drift/SQLite layer can implement.
- Keep current implementation in-memory if needed.
- Repository interfaces should preserve domain rules rather than bypassing services.

Acceptance criteria:

- Domain services can depend on interfaces.
- Tests can use fake/in-memory repositories.
- Interfaces do not import Drift, SQLite, Flutter, or platform-specific APIs.

BREAKPOINT: Stop here. Confirm `extra high` mode before implementing the persistence edge-case test suite.

## Chunk 9.2 — Persistence edge-case regression test suite

Recommended Codex level: extra high

Tasks:

Before model serialization changes, add or expand tests that define persistence-sensitive behavior clearly.

Cover these cases:

- task IDs remain stable across copy/update operations
- project IDs remain stable across copy/update operations
- locked block IDs remain stable across copy/update operations
- DateTime values are stored and compared using the documented convention
- nullable fields can be intentionally preserved
- nullable fields that need clearing have explicit clear behavior or documented mapping behavior
- enum values have stable persistence names or a clearly tested mapping plan
- `RewardLevel.notSet` remains distinct from `RewardLevel.veryLow`
- backlog age behavior has a documented source timestamp or TODO before database work
- in-memory fake repositories can round-trip saved records without losing scheduling fields
- repository operations do not mutate input objects unexpectedly

Rules:

- This chunk may add tests and small model helpers needed to make persistence behavior testable.
- Do not add Drift/SQLite implementation yet.
- Do not add sync, networking, cloud accounts, or background services.
- Do not mark this chunk complete unless `dart analyze` and `dart test` pass.

Acceptance criteria:

- Persistence-sensitive test group exists.
- Tests capture stable IDs, enum mapping, nullable-field behavior, and DateTime convention.
- Any unresolved persistence detail is documented as a TODO in the plan or architecture notes.

BREAKPOINT: Stop here. Confirm `high` mode before model serialization changes.

## Chunk 9.3 — Serialization-safe models

Recommended Codex level: high

Tasks:

Make models persistence-friendly:

- stable IDs
- enum serialization helpers or clear mapping plan
- DateTime handling convention
- nullable fields documented
- nullable field clear helpers where needed
- migration-safe field names where possible
- map/json-like conversion helpers only if they do not over-couple the domain layer

Acceptance criteria:

- Models can round-trip through map/json-like structures or have a clear TODO for Drift mappings.
- Tests cover at least task serialization if implemented.
- Tests cover enum persistence mapping if implemented.
- Tests cover intentional clearing of nullable fields if helper behavior is added.

BREAKPOINT: Stop here. Confirm `low` mode before documenting the explicit non-sync boundary.

## Chunk 9.4 — Explicit non-sync boundary

Recommended Codex level: low

Tasks:

Document that V1 persistence is local-first and sync is out of scope.

Rules:

- No network sync code.
- No cloud assumptions.
- No background service implementation.
- No mobile notification or background reconciliation implementation in this block.

Acceptance criteria:

- README or architecture doc states sync is future work.
- Docs distinguish local persistence preparation from actual sync.
- Wishlist/future notes contain sync as a later feature, not a V1 requirement.

Commit suggestion:

```text
feat(data): prepare persistence interfaces for scheduling core
```
