### Restaurants: Order Tracking Using Django

#### Summary
A order tracking 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.

Public information: menu with allergens and prices, locations, hours and reservations contact, catering information.

#### Resource Requirements
- **Primitive Compute**
- **Primitive PostgreSQL**
- **Primitive S3-compatible Object Storage**

#### Infrastructure Requirements
- **Compute**: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
- **Postgres**: Managed PostgreSQL runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.
- **S3-compatible Object Storage**: Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary.

#### 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

#### Workflow Steps
1. **Model the restaurants domain**: Create the tables menu_items, stock_movements, orders, order_lines, events.
2. **Workflow step 1**: Model orders with explicit status transitions and order lines.
3. **Workflow step 2**: Apply status changes transactionally and record an event per change.
4. **Workflow step 3**: Expose status history to authorized callers only.
5. **Workflow step 4**: Deploy and verify history and conflict rejection.
6. **Deploy**: Run the synchronous deploy once and read the result.
7. **Verify**: Run the pattern self-test(s) from the example and your own acceptance checks for the restaurants workflow.

#### Success Checks
1. App responds on its public URL
2. Transactional-workflows self-test from the example

#### Limitations
- The technical basis is verified with the pattern fixture; the restaurants schema and workflow were not executed as a separate application.
- Verified on the python-3.12 template.

#### Cost Estimate
- **Currency**: USD
- **Monthly Amount**: 10.0
- **Components**:
  - App server: 1 × s-1vcpu-1gb ($5.0)
  - Managed PostgreSQL database: 1 × s-1vcpu-1gb ($5.0)

#### Examples
- **Django Pattern Fixture**: Verified transactional workflows basis for this blueprint.

#### Next Actions
- Browse the catalog index
- Search published recipes by intent, stack and constraints
- Prepare a side-effect-free deployment plan for an authorized project