Domain Ledgers on D1 for a Learning OS

A task row cannot represent every stage of learning. “Done” says little about recall, errors, later review, or a result approved for a portfolio. Instead of replacing the running application, this migration adds ledgers around the existing data.

One table per durable meaning

Goals store outcomes and weights. Weekly plans store accepted capacity. Attempts store score and response signals. Errors point back to attempts and have their own resolution state. Reviews store interval stage and next date. Evidence items track visibility and a guarded publication state.

This separation prevents unrelated meanings from being compressed into a single completion flag. It also allows an incorrect answer to remain unresolved even when the video or task that produced it is marked complete.

Runtime compatibility and migrations work together

The application currently runs on D1 in more than one local mode. A checked-in SQL migration documents the intended schema, while idempotent runtime setup protects older local databases during gradual rollout. CREATE TABLE IF NOT EXISTS, additive columns, and explicit indexes keep startup safe. Neither mechanism discards the existing database.

State transitions are server rules

Evidence cannot jump from candidate directly to published. The server accepts candidate -> approved -> published, and both states may move to archived. A test confirmed that the invalid direct transition returns 409, while approval succeeds and preserves private visibility.

The design is intentionally a modular monolith. D1 is sufficient for validating contracts and behavior; queues, search clusters, or microservices would add operational cost without current measurements proving a need.