2.1 KiB
Local recipe application
The local application uses SQLite as its canonical data store. YAML remains a portable import/export format, but normal application saves do not modify it. Derived nutrition and cost are still calculated rather than stored.
Source-of-truth rule
- SQLite is the only writable source of truth for a running installation.
- Humans should edit through the management application.
- Automation and AI agents should call validated application commands or domain
save functions such as
saveRecipeStructure(). - Agents should not edit YAML to change live data and should not issue unrestricted SQL when a domain operation exists.
- Generated site projections and exports are downstream products of SQLite.
A safe automated recipe change follows this flow:
agent request
-> validate recipe structure and references
-> domain save function
-> SQLite transaction
-> refresh derived projection
-> optional explicit export for backup or review
Create the initial database from the current portable dataset with Node 22 or newer, then run either application mode:
npm run db:reset
npm run dev:readonly
npm run dev:app
Read-only mode serves the same application with SQLite opened read-only, removes editing controls, and rejects modifying HTTP requests. Browser-side scaling, unit conversion, nutrition, and costing calculations remain available.
The database is written to var/recipe-book.sqlite and is intentionally ignored
by Git. migrations/001_initial.sql defines the complete relational schema.
The application does not support upgrading databases from older schemas: rebuild
from portable data with npm run db:reset. Recipe edits are transactional and a
private save token prevents stale browser tabs from overwriting newer changes.
There is no recipe revision history.
npm run db:import:yaml and npm run db:reset both delete and replace the
database from portable YAML. They are intended only for initial setup or an
explicit restore. Running either command after application edits can discard
newer SQLite-only data.