Repository navigation
Product Roadmap
Source: a detailed scenario list supplied by the project owner (2026-08-06),
covering the failure modes and edge cases a real restaurant hits that a
"happy path" POS build tends to miss. Tracked as GitHub issues under the
roadmap label — this page is the narrative overview; the issues are the actionable checklist.
Master tracker: #11
#1 — Event-sourced order lifecycle
Instead of mutating Order/OrderItem rows in place, record append-only
business events:
Order opened → Guest count changed → Item added → Item modified →
Item cancelled → KOT sent → Item prepared → Item served →
Discount applied → Payment received → Refund processed → Order closed
Each event is timestamped, attributed to an employee, and never deleted. Current order state is a projection derived from the event log, not the source of truth itself.
This single change is what makes three other epics tractable instead of bolted-on:
- Offline sync (#2): an offline device just generates more events; the merge-on-reconnect problem becomes "append events," not "reconcile two divergent row states."
- Audit trail (#8): every event already carries who/what/when — the audit log is a read of the event log, not a second system to keep in sync.
- Reporting (#9, #10): shift-close and owner-dashboard numbers become aggregations over events instead of ad hoc queries against mutable state.
Recommend sequencing this early. Retrofitting event sourcing under already-shipped mutation-based features costs more than building on top of it from the start.
| # | Epic | Depends on |
|---|---|---|
| #1 | Event-sourced order lifecycle | — (foundational) |
| #2 | Resilience: offline-first + power/network outages | benefits from #1 |
| #3 | Kitchen operations: printer failover, rejection, multi-station, remakes | — |
| #4 | Table management: move, merge, split, colors, waitlist | — |
| #5 | Ordering & menu: delta KOTs, modifiers, combos, price/tax snapshotting | — |
| #6 | Inventory: auto-deduct, auto-hide out-of-stock, reconciliation | — |
| #7 | Billing & payments: approvals, split tender, refunds, reopen-after-print | — |
| #8 | Employee accountability: audit trail, attendance, RBAC hardening | benefits from #1 |
| #9 | Shift close (Z-report) + cash drawer reconciliation | benefits from #1 |
| #10 | Owner dashboard: the at-a-glance numbers that matter | benefits from #1 |
- #1 first if feasible.
- #2 next — "never lose data" is a trust-critical property for a restaurant's primary revenue system.
- #3–#7, #9, #10 in whatever order matches the operator's actual pain points first — none of them block each other architecturally.
A pass through the scenario list before filing these issues found several items already implemented in the current codebase — noted inline on the relevant issue rather than filed as new work:
- Adding items to an open order already sends only the new items to the kitchen (not a full resend).
- Menu price and tax rate are already snapshotted onto the order item at the moment it's added — a later menu edit never rewrites an open order.
- Multi-station KOT routing (pizza → kitchen, drinks → bar) already exists.
- Loyalty points (earn + redeem), gift cards, partial refunds, and merging two open orders' bills already exist.
- Order cancellation (blocked once the kitchen has started preparing) and a direct "start a new order" action from an available table were added 2026-08-05/06.
This page and its linked issues describe what to build, not a delivery timeline. Each epic issue is sized as its own body of work — some (event sourcing, offline-first) are substantially larger than others (owner dashboard consolidation). Pick an epic and scope an implementation plan for it separately when ready to start.