Rectify Reactive BBQ tutorial with verbatim riddl-models source

Replaces fabricated RIDDL snippets with actual code from the
riddl-models repository. Adds 14 per-context pages covering all
11 bounded contexts plus external contexts and cross-cutting
patterns. Rewrites 5 existing pages and restructures navigation.

- 6 Restaurant context pages (FOH, Kitchen, Bar, Online, Delivery, Loyalty)
- 3 BackOffice context pages (Scheduling, Inventory, Reporting)
- 3 Corporate context pages (Menu Management, Supply Chain, Marketing)
- External contexts page (6 third-party integrations)
- Patterns page (7 cross-cutting RIDDL patterns)
- All GitHub links updated from riddl-examples to riddl-models

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: respencer-ncl

docs/riddl/tutorials/rbbq/backoffice/index.md

@@ -1,76 +1,101 @@
 ---
-title: "Back Office Subdomain"
-description: "Administrative operations in the Reactive BBQ domain model"
+title: "BackOffice Domain"
+description: "Administrative operations in the Reactive BBQ model"
 ---
 
-# Back Office Subdomain
+# BackOffice Domain
 
-The Back Office subdomain handles administrative and management functions
-that support restaurant operations but aren't directly customer-facing.
+The BackOffice domain handles administrative and management functions
+that support restaurant operations but aren't directly
+customer-facing. It contains three bounded contexts and two external
+system integrations.
 
-## Bounded Contexts
-
-### Scheduling
+## Domain Definition
 
-Manages staff schedules and shifts:
-
-- **Shift Planning** - Creating weekly schedules
-- **Time Tracking** - Recording hours worked
-- **Coverage** - Ensuring adequate staffing
+```riddl
+domain BackOffice is {
+
+  author OssumInc is {
+    name is "Ossum Inc."
+    email is "info@ossuminc.com"
+  } with {
+    briefly "Author"
+    described by "Ossum Inc."
+  }
 
-Key entities:
-- `Employee` - Staff member with role and availability
-- `Shift` - Time slot with required roles
-- `Schedule` - Weekly assignment of employees to shifts
+  user Manager is "Restaurant manager overseeing daily operations" with {
+    briefly "Manager"
+    described by "Manages scheduling, inventory, and reporting."
+  }
 
-### Inventory
+  user InventoryClerk is "Staff member managing stock" with {
+    briefly "Inventory Clerk"
+    described by "Receives shipments, tracks stock levels, and reorders."
+  }
 
-Tracks stock levels and supplies:
+  include "SchedulingContext.riddl"
+  include "InventoryContext.riddl"
+  include "ReportingContext.riddl"
+  include "external-contexts.riddl"
+
+} with {
+  briefly "Back office operations domain"
+  described by {
+    | Covers staff scheduling, inventory management, and
+    | operational reporting. Reporting is isolated in its
+    | own context with CQRS projectors so that report
+    | generation never degrades peak-hour performance.
+  }
+}
+```
 
-- **Stock Levels** - Current inventory counts
-- **Reordering** - Automated low-stock alerts
-- **Receiving** - Recording deliveries
+Notice the `user` definitions at the domain level — Manager and
+InventoryClerk are personas specific to back-office operations.
 
-Key entities:
-- `InventoryItem` - Product with quantity and reorder point
-- `StockTransaction` - Record of stock changes
-- `PurchaseOrder` - Order to supplier
+## Bounded Contexts
 
-### Reporting
+| Context | Purpose | Entities | Details |
+|---------|---------|----------|---------|
+| [Scheduling](scheduling.md) | Shift planning, time tracking | Shift | 6-command lifecycle |
+| [Inventory](inventory.md) | Stock levels, consumption | InventoryItem | Kitchen integration |
+| [Reporting](reporting.md) | Sales, labor, inventory reports | *(none)* | Pure CQRS projectors |
 
-Generates management reports:
+Plus two [external contexts](../external-contexts.md):
+**HRSystem** and **AccountingSystem**.
 
-- **Sales Reports** - Daily, weekly, monthly summaries
-- **Labor Reports** - Hours and costs by department
-- **Inventory Reports** - Usage and waste tracking
+## Cross-Context Integration
 
-## Integration Points
+The BackOffice domain integrates with the Restaurant domain in
+two key ways:
 
-The Back Office subdomain integrates with:
+1. **Inventory ← Kitchen** — The Inventory context has a
+   `FromKitchen` adaptor that listens for
+   `PreparationStarted` events. When the kitchen begins
+   preparing an order, stock is automatically consumed.
+   No manual tracking needed.
 
-- **Restaurant** - Receives sales data, provides schedules
-- **Corporate** - Sends reports, receives policies
+2. **Reporting ← Everything** — The Reporting context has
+   projectors that listen to events from multiple contexts:
+    - `SalesReport` ← payment events from FrontOfHouse and
+      OnlineOrdering
+    - `LaborReport` ← clock-in/out events from Scheduling
+    - `InventoryReport` ← stock events from Inventory
 
-```riddl
-context BackOffice is {
-  adaptor RestaurantAdapter from context Restaurant is {
-    // Transform Restaurant events into BackOffice commands
-    on event SaleCompleted from Restaurant.FrontOfHouse {
-      send command RecordSale to Reporting
-    }
-  }
-}
-```
+## Design Decisions
 
-## Challenges Addressed
+**Why isolate Reporting?** The CEO's interview revealed that
+report generation was slowing down production systems during
+peak hours. By making Reporting a pure CQRS read-model context
+with only projectors (no entities), reports are built
+asynchronously from events and never compete with production
+workloads.
 
-| Challenge | Solution |
-|-----------|----------|
-| Report interference | Separate context, isolated resources |
-| Peak hour impacts | Async processing, eventual consistency |
-| Multi-timezone | Location-aware scheduling |
+**Why separate Scheduling from HR?** The HR system is modeled
+as an external context (`option is external`). Scheduling owns
+the operational shift data while HR owns the master employee
+records. This separation means scheduling works independently
+even if the HR system is down.
 
-## Source Code
+## Source
 
-See the Back Office subdomain implementation:
-[backoffice/domain.riddl](https://github.com/ossuminc/riddl-examples/tree/main/src/riddl/ReactiveBBQ/backoffice)
+[`backoffice/domain.riddl`](https://github.com/ossuminc/riddl-models/tree/main/hospitality/food-service/reactive-bbq/backoffice)

docs/riddl/tutorials/rbbq/backoffice/inventory.md

@@ -0,0 +1,224 @@
+---
+title: "Inventory Context"
+description: "Stock level tracking with automated kitchen integration"
+---
+
+# Inventory Context
+
+The Inventory context manages stock levels, receiving,
+consumption tracking, manual adjustments, and reorder
+thresholds. It integrates with the Kitchen context to
+automatically track consumption as items are prepared.
+
+## Purpose
+
+Every restaurant location tracks hundreds of ingredients and
+supplies. The Inventory context provides the operational
+foundation: receiving shipments, tracking consumption,
+triggering reorder alerts, and creating purchase orders when
+stock runs low.
+
+## Types
+
+```riddl
+type InventoryItemId is Id(Inventory.InventoryItem) with {
+  briefly "Inventory item identifier"
+  described by "Unique identifier for an inventory item."
+}
+
+type UnitOfMeasure is any of {
+  Each,
+  Pound,
+  Ounce,
+  Gallon,
+  Liter,
+  Case,
+  Box
+} with {
+  briefly "Unit of measure"
+  described by "Measurement unit for inventory quantities."
+}
+
+type InventoryItemStatus is any of {
+  InStock,
+  LowStock,
+  OutOfStock,
+  Discontinued
+} with {
+  briefly "Inventory item status"
+  described by "Current stock status of an inventory item."
+}
+
+type StockAdjustmentReason is any of {
+  Spoilage,
+  Breakage,
+  Theft,
+  CountCorrection,
+  Donation,
+  OtherAdjustment
+} with {
+  briefly "Stock adjustment reason"
+  described by "Reason for a manual stock adjustment."
+}
+```
+
+The `StockAdjustmentReason` enumeration captures why stock was
+manually adjusted — essential for loss tracking and audit
+compliance.
+
+## Entity: InventoryItem
+
+The `InventoryItem` entity has a 5-command lifecycle:
+
+```riddl
+entity InventoryItem is {
+
+  command ReceiveStock is {
+    inventoryItemId is InventoryItemId
+    receivedQuantity is Decimal(10, 2)
+    receivedUnit is UnitOfMeasure
+    supplierRef is optional String(1, 100)
+    stockReceivedAt is TimeStamp
+  }
+
+  command ConsumeStock is {
+    inventoryItemId is InventoryItemId
+    consumedQuantity is Decimal(10, 2)
+    consumedUnit is UnitOfMeasure
+    consumptionRef is optional String(1, 100)
+  }
+
+  command AdjustStock is {
+    inventoryItemId is InventoryItemId
+    adjustmentQuantity is Decimal(10, 2)
+    adjustmentUnit is UnitOfMeasure
+    adjustmentReason is StockAdjustmentReason
+    adjustmentNotes is optional String(1, 500)
+  }
+
+  command SetReorderThreshold is {
+    inventoryItemId is InventoryItemId
+    reorderThreshold is Decimal(10, 2)
+    reorderUnit is UnitOfMeasure
+  }
+
+  command CreatePurchaseOrder is {
+    inventoryItemId is InventoryItemId
+    orderQuantity is Decimal(10, 2)
+    orderUnit is UnitOfMeasure
+    preferredSupplier is optional String(1, 100)
+  }
+
+  // Events: StockReceived, StockConsumed, StockAdjusted,
+  //         ReorderThresholdSet, PurchaseOrderCreated
+
+  state TrackedItem of InventoryItem.InventoryItemStateData
+
+  handler InventoryItemHandler is {
+    on command ReceiveStock {
+      morph entity Inventory.InventoryItem to state
+        Inventory.InventoryItem.TrackedItem
+        with command ReceiveStock
+      tell event StockReceived to
+        entity Inventory.InventoryItem
+    }
+    on command ConsumeStock {
+      tell event StockConsumed to
+        entity Inventory.InventoryItem
+    }
+    on command AdjustStock {
+      tell event StockAdjusted to
+        entity Inventory.InventoryItem
+    }
+    on command SetReorderThreshold {
+      tell event ReorderThresholdSet to
+        entity Inventory.InventoryItem
+    }
+    on command CreatePurchaseOrder {
+      tell event PurchaseOrderCreated to
+        entity Inventory.InventoryItem
+    }
+  }
+}
+```
+
+Note that `ReceiveStock` uses `morph` — this is where an
+inventory item first enters the system. Subsequent commands use
+the standard `tell` pattern.
+
+The `StockConsumed` event includes a `remainingStockLevel`
+field, enabling downstream systems (like the Reporting context's
+`InventoryReport` projector) to track stock levels without
+querying the entity directly.
+
+## Repository
+
+```riddl
+repository InventoryItemRepository is {
+  schema InventoryItemData is relational
+    of items as InventoryItem
+    index on field InventoryItem.inventoryItemId
+    index on field InventoryItem.inventoryItemStatus
+}
+```
+
+The index on `inventoryItemStatus` enables quick queries for
+low-stock and out-of-stock items.
+
+## Adaptor: FromKitchen
+
+The most interesting part of the Inventory context is its
+cross-context integration with the Kitchen:
+
+```riddl
+adaptor FromKitchen from context Restaurant.Kitchen is {
+  handler KitchenConsumptionIntake is {
+    on event Restaurant.Kitchen.KitchenTicket.PreparationStarted {
+      prompt "Consume stock for items being prepared"
+    }
+  }
+} with {
+  briefly "Kitchen adaptor"
+  described by {
+    | Receives preparation events from the kitchen to
+    | automatically track stock consumption.
+  }
+}
+```
+
+When the Kitchen starts preparing a ticket
+(`PreparationStarted` event), the Inventory context
+automatically issues `ConsumeStock` commands for the ingredients
+required. No manual tracking needed — stock consumption follows
+directly from kitchen activity.
+
+This is a powerful example of cross-context integration via
+events. The Kitchen doesn't know about inventory. It just
+prepares food and emits events. Inventory reacts to those
+events to keep stock levels accurate.
+
+## Design Decisions
+
+**Why automatic consumption from Kitchen events?** Manual
+stock tracking is error-prone and labor-intensive. By
+listening to `PreparationStarted` events and looking up the
+recipe's ingredient list, the system can automatically deduct
+the right quantities. Discrepancies are handled through the
+`AdjustStock` command with explicit reasons.
+
+**Why `Decimal(10, 2)` for quantities?** Inventory items are
+measured in fractional quantities (2.5 pounds of brisket,
+0.75 gallons of sauce). Using `Decimal` instead of `Natural`
+supports precise tracking with proper unit handling.
+
+**Cross-domain relationship:** This context is in the
+BackOffice domain but listens to events from the Restaurant
+domain's Kitchen context. This cross-domain integration is
+exactly what adaptors are designed for — they bridge context
+boundaries cleanly.
+
+## Source
+
+- [`InventoryContext.riddl`](https://github.com/ossuminc/riddl-models/tree/main/hospitality/food-service/reactive-bbq/backoffice/InventoryContext.riddl)
+- [`inventory-types.riddl`](https://github.com/ossuminc/riddl-models/tree/main/hospitality/food-service/reactive-bbq/backoffice/inventory-types.riddl)
+- [`InventoryItem.riddl`](https://github.com/ossuminc/riddl-models/tree/main/hospitality/food-service/reactive-bbq/backoffice/InventoryItem.riddl)