## Restaurants: Inventory Manager Using Django

### Summary
A inventory manager blueprint for restaurants built with Django on Ample. Domain schema: 
- **menu_items** (sku, name, section, price, allergens, active): the menu as a SKU catalog;  
- **stock_movements** (sku, delta, reason, moved_at): ingredient and prepared-item stock;  
- **orders** (order_no, service_type, status, placed_at): dine-in, pickup, and delivery orders;  
- **order_lines** (order_no, sku, qty, modifiers): order contents;  
- **events** (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

### Technical Basis
- An optimistic version check and an event row written in the same transaction.  
- A stale update is rejected, and a history query over the application-owned events (history=2 conflict=rejected).

### Public Information
- Menu with allergens and prices, locations, hours, reservations contact, and catering information.  
- Customer contact and payment details, staff schedules are kept out of scope until handling is reviewed.  
- Allergen information must be kept accurate by the operator; nothing here validates food-safety claims.

### Prerequisites
- A Django project (pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template).  
- A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted).  
- Bucket credentials from `ample bucket create` passed as encrypted S3_* environment variables.  
- A review of which restaurants data classes may be handled at all; this blueprint models public information only.

### Workflow Steps
1. **Model the restaurants domain**: Create the tables menu_items, stock_movements, orders, order_lines, events. The menu as a sku catalog lives in menu_items; keep the sensitive classes (customer contact and payment details, staff schedules) out of this schema.  
2. **Workflow step 1**: Model SKUs and stock movements; derive stock from movements.  
3. **Workflow step 2**: Apply movements transactionally with an optimistic version check on the SKU.  
4. **Workflow step 3**: Record an event per movement for history.  
5. **Workflow step 4**: Deploy and verify history and rejected stale updates.  
6. **Deploy**: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.  
7. **Verify**: Run the pattern self-test(s) from the example (/p/transactional-workflows) and your own acceptance checks for the restaurants workflow.

### Cost Estimate
- **Currency**: USD  
- **Monthly Amount**: 10.0  
- **Components**:  
  - App server: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: 5.0  
  - Managed PostgreSQL database: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: 5.0  
- Note: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle. Buckets are allocation-priced per quota and not included.

### Limitations
- The technical basis was verified with the pattern fixture; the restaurants schema and workflow are an original design for this blueprint and were not executed as a separate application.  
- Allergen information must be kept accurate by the operator; nothing here validates food-safety claims.

### Evidence Summary
- **Kind**: canary_run  
- **Summary**: Django pattern fixture deployed on Ample; the transactional workflows checks passed.  
- **Observed At**: 2026-09-20T03:31:44Z

### Examples
- **Django pattern fixture**: Verified transactional workflows basis for this blueprint.