| 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
- Confirm the requested behavior truly needs persistence.
- Check whether existing
app_meta or settings-level storage is sufficient.
- If a table is necessary, define the smallest schema that supports the current behavior.
- Add Drizzle schema and bootstrap/migration logic together.
- Keep data access behind main-process services.
- Update
db.getStatus only if the status surface needs to show new bootstrap information.
- 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.
