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

Acceptance criteria:

- Domain services can depend on interfaces.
- Tests can use fake/in-memory repositories.

## Chunk 9.2 — 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
- migration-safe field names where possible

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.

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

## Chunk 9.3 — 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.

Acceptance criteria:

- README or architecture doc states sync is future work.

Commit suggestion:

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