## Direct-to-consumer brands: inventory manager using Django

### Summary
A inventory manager blueprint for direct-to-consumer brands built with Django on Ample. Domain schema:
- **products** (sku, name, collection, price, active): product catalog;
- **stock_movements** (sku, warehouse, delta, reason, moved_at): fulfillment stock;
- **orders** (order_no, channel, status, placed_at): orders with status transitions;
- **order_lines** (order_no, sku, qty, unit_price): order contents;
- **events** (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

Public information: product catalog and collections, shipping and returns policy, brand story.

### Representative Queries
- Direct-to-consumer brands: inventory manager using Django
- Where can I host Direct-to-consumer brands: Inventory manager built with Django?
- I need a genuinely specialized inventory manager workflow covering product variants, branded media and fulfillment-state handling.

### 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 direct-to-consumer brands data classes may be handled at all; this blueprint models public information only

### Workflow Steps
1. **Model the direct-to-consumer brands domain**: Create the tables products, stock_movements, orders, order_lines, events. Product catalog lives in products; keep the sensitive classes (customer contact and payment details, discount codes tied to individuals) 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 direct-to-consumer brands workflow.

### Limitations
- The technical basis (transactional workflows on Django) was verified with the pattern fixture; the direct-to-consumer brands schema and workflow are an original design for this blueprint and were not executed as a separate application.
- No health, financial, privacy or other compliance claim is made. Checkout and payment are handled by your commerce provider; only catalog, stock and order status are modeled here.
- Public content and synthetic examples only until actual data-handling requirements have been reviewed.

### Cost Estimate
- Currency: USD
- Monthly Amount: 10.0
- Basis: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
- **Components**:
  - App server (s-1vcpu-1gb): 5.0
  - Managed PostgreSQL database (s-1vcpu-1gb): 5.0

### Evidence Summary
- **Kind**: canary_run
- **Summary**: Django pattern fixture deployed on Ample (pip install into .ample/python from requirements.txt), the transactional workflows checks passed: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events.
- **Observed At**: 2026-09-20T03:31:44Z