Feature: Scheduled orders with release semantics
Summary
Support orders scheduled for a future time (e.g. tomorrow 5pm). Today creating an order immediately marks it pending, deducts inventory (main/routes/orders.ts ~556/767) and notifies KDS — so adding a bare scheduled_for column would let the kitchen see tomorrow's pizza today.
Proposed approach
Keep scheduling separate from kitchen state:
orders: scheduled_for, release_status (scheduled|released), released_at
Flow: Customer places order → sits in scheduled queue → at release time it becomes a normal pending order → KDS.
- A background timer releases due orders; on startup, release any overdue orders in case the app was closed when the timer should have fired.
- One explicit product decision required (do not invent): does inventory get reserved at scheduling time or at release time?
Acceptance criteria
Feature: Scheduled orders with release semantics
Summary
Support orders scheduled for a future time (e.g. tomorrow 5pm). Today creating an order immediately marks it
pending, deducts inventory (main/routes/orders.ts~556/767) and notifies KDS — so adding a barescheduled_forcolumn would let the kitchen see tomorrow's pizza today.Proposed approach
Keep scheduling separate from kitchen state:
Flow: Customer places order → sits in scheduled queue → at release time it becomes a normal
pendingorder → KDS.Acceptance criteria
PRAGMA user_versionmigration; see AGENTS.md data-safety rules).