sqlite-minimal-persistence

name	sqlite-minimal-persistence
description	Extend Ordinus SQLite persistence conservatively. Use when touching better-sqlite3, Drizzle schema, database bootstrap, app_meta, migrations, durable state, persistence boundaries, or proposals to add new product tables.

SQLite Minimal Persistence

Objective

Use SQLite as durable local app state without designing product tables before the workflow model is clear.

Current Policy

• The minimum database starts with app_meta.
• Add new tables only when the product behavior needs durable state now.
• Avoid adding agent, task, provider, schedule, inbox, or run schemas speculatively.
• Keep secrets out of ordinary product tables unless a secure storage decision has been made.
• Treat SQLite as main-process owned. Renderer must access state only through typed IPC.

Workflow

1. Confirm the requested behavior truly needs persistence.
2. Check whether existing app_meta or settings-level storage is sufficient.
3. If a table is necessary, define the smallest schema that supports the current behavior.
4. Add Drizzle schema and bootstrap/migration logic together.
5. Keep data access behind main-process services.
6. Update db.getStatus only if the status surface needs to show new bootstrap information.
7. Run typecheck, lint, build, and a runtime smoke test that opens the app.

Design Guidance

• Prefer durable state for user-visible history, resumable work, and app configuration.
• Prefer filesystem storage for large artifacts and generated files, with database metadata later when needed.
• Prefer explicit timestamps and schema versioning for local migrations.
• Keep schema names product-oriented and stable.

Red Flags

• A table is added because a future module might need it.
• Renderer imports database code.
• Database writes are mixed into UI event handlers.
• Migration behavior is not exercised by opening the app.