13 changed files with 0 additions and 997 deletions
--- a/docs/architecture/platform-boundaries.md
+++ b/docs/architecture/platform-boundaries.md
@ -20,8 +20,3 @@ This repository is a modular multi-package platform library set.
 - Identity abstractions are not owned by this repository.
 - Downstream repositories consume package contracts from this repo.
 - Secret provider abstractions are provider-agnostic; concrete provider adapters are bound at runtime.
 ## Workspace Integration References
 - `docs/consumption/demo-auth-routing-runbook.md` defines centralized auth + demo host routing contracts.
 - `docs/consumption/demo-auth-routing-validation.md` defines post-change verification for routing and callback safety.
--- a/docs/architecture/stage40-43-execution-guardrails.md
+++ b/docs/architecture/stage40-43-execution-guardrails.md
@ -1,135 +0,0 @@
 # Stage 40-43 Execution Guardrails
 ## Purpose
 This document turns the Stage 39 master plan into an execution guard for Stages 40-43.
 Use it before starting any task in the following waves:
 - Stage 40: ops source-of-truth sync and Thalos auth hardening
 - Stage 41: restaurant backend and restaurant web workflow depth
 - Stage 42: furniture backend and furniture web workflow depth
 - Stage 43: end-to-end demo validation and completion hardening
 ## Stage Baseline
 - Active master plan: `plan/2026-03-27-s39-master-spa-depth-and-ops-hardening.md`
 - Guiding review: `plan/2026-03-27-review-current-gap.md`
 - Current execution audit: `plan/2026-03-27-audit-task-execution.md`
 Default wave choices locked by Stage 39:
 - balanced hardening
 - restaurant-first execution
 - manual or simulated login stays dev-only and must be hidden from production UX
 ## Architecture Constraints
 The workspace remains locked to:
 ```text
 Blueprint -> BuildingBlock -> Domain -> DAL -> Service -> BFF
 ```
 Execution safety rules:
 - no cross-repo `ProjectReference`
 - no repo may reference `legacy/`
 - BFF repos talk only to Service repos
 - Service repos must not depend on BFF repos
 - Identity ownership remains inside Thalos
 Before any implementation task is closed:
 1. validate dependency direction against `rules/15-workspace-dependency-graph.md`
 2. validate no cross-repo `ProjectReference` was introduced
 3. confirm docs were updated in the same repo as the code change
 ## Wave Dependency Order
 The default flow for the Stage 40-43 task graph is:
 1. `ARC-WORKSPACE-GUARD-900`
 2. `ARC-DEMO-SOURCE-OF-TRUTH-910`
 3. `SEC-THALOS-SERVICE-900`
 4. `SEC-THALOS-BFF-900`
 5. `WEB-THALOS-WEB-900`
 6. `ARC-OPERATIONS-SERVICE-920`
 7. `ARC-KITCHEN-SERVICE-920`
 8. restaurant BFF tasks:
   - `ARC-WAITER-FLOOR-BFF-930`
   - `ARC-CUSTOMER-ORDERS-BFF-930`
   - `ARC-KITCHEN-OPS-BFF-930`
   - `ARC-POS-TRANSACTIONS-BFF-930`
   - `ARC-RESTAURANT-ADMIN-BFF-930`
 9. restaurant web tasks:
   - `WEB-WAITER-FLOOR-WEB-940`
   - `WEB-CUSTOMER-ORDERS-WEB-940`
   - `WEB-KITCHEN-OPS-WEB-940`
   - `WEB-POS-TRANSACTIONS-WEB-940`
   - `WEB-RESTAURANT-ADMIN-WEB-940`
 10. furniture workflow depth:
   - `ARC-FURNITURE-SERVICE-950`
   - `ARC-FURNITURE-BFF-960`
   - `WEB-FURNITURE-WEB-970`
 11. `ARC-DEMO-VALIDATION-980`
 `DependsOn` remains authoritative when a task file is more specific than this summary.
 ## Validation Gates
 ### Gate A: Stage 40
 Before Stage 41 starts:
 - Portainer, Caddy, Vault, and demo source-of-truth ownership is documented
 - Thalos auth hardening tasks are completed
 - Thalos web production auth UX is documented as canonical
 ### Gate B: Stage 41
 Before Stage 42 starts:
 - `operations-service` and `kitchen-service` build and test successfully
 - restaurant BFF contracts expose the required workflow routes
 - every restaurant web repo passes container-first build and test validation
 ### Gate C: Stage 42
 Before Stage 43 starts:
 - `furniture-service` and `furniture-bff` build and test successfully
 - `furniture-web` no longer relies on local reservation projection
 - furniture web passes container-first build and test validation
 ### Gate D: Stage 43
 Wave completion requires:
 - authenticated demo flows validated on deployed hosts
 - docs and runbooks updated in every touched repo
 - no stale `.repo-tasks/active` entries left from Stage 40-43 work
 ## Documentation And Comment Rules
 Every implementation task in this wave must:
 - update repo docs in the same change set
 - add meaningful comments where logic is non-trivial
 - keep commit messages free of task/stage/AI wording
 Web repos additionally must:
 - validate using container-first test/build flow
 - keep auth/session behavior aligned with deployed host routing
 ## Known Boundaries
 This wave expands workflow depth, not architecture shape.
 That means:
 - no new repos in Stage 40-43
 - no auth provider expansion beyond the current Google path
 - no DAL or persistence redesign unless a task explicitly requires it to unblock a defined workflow
 - no UI work that bypasses BFF ownership boundaries
--- a/docs/architecture/stage40-43-execution-guardrails.puml
+++ b/docs/architecture/stage40-43-execution-guardrails.puml
@ -1,59 +0,0 @@
@startuml
 title Stage 40-43 Execution Guardrails
 skinparam monochrome true
 skinparam shadowing false
 rectangle "Stage 40" as S40 {
  component "ARC-WORKSPACE-GUARD-900" as G900
  component "ARC-DEMO-SOURCE-OF-TRUTH-910" as D910
  component "SEC-THALOS-SERVICE-900" as TS900
  component "SEC-THALOS-BFF-900" as TB900
  component "WEB-THALOS-WEB-900" as TW900
 }
 rectangle "Stage 41" as S41 {
  component "ARC-OPERATIONS-SERVICE-920" as OS920
  component "ARC-KITCHEN-SERVICE-920" as KS920
  component "Restaurant BFF Tasks" as RBFF930
  component "Restaurant Web Tasks" as RWEB940
 }
 rectangle "Stage 42" as S42 {
  component "ARC-FURNITURE-SERVICE-950" as FS950
  component "ARC-FURNITURE-BFF-960" as FB960
  component "WEB-FURNITURE-WEB-970" as FW970
 }
 rectangle "Stage 43" as S43 {
  component "ARC-DEMO-VALIDATION-980" as DV980
 }
 G900 --> D910
 G900 --> TS900
 TS900 --> TB900
 TB900 --> TW900
 TB900 --> OS920
 TB900 --> KS920
 OS920 --> RBFF930
 KS920 --> RBFF930
 RBFF930 --> RWEB940
 TW900 --> RWEB940
 TB900 --> FS950
 FS950 --> FB960
 FB960 --> FW970
 TW900 --> FW970
 D910 --> DV980
 RWEB940 --> DV980
 FW970 --> DV980
 note bottom
 DependsOn in each task file is authoritative.
 This diagram is the planning guardrail summary.
 end note
@enduml
--- a/docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.md
+++ b/docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.md
@ -1,169 +0,0 @@
 # Stage 44-48 Shared Restaurant Lifecycle Guardrails
 ## Purpose
 This document turns the Stage 44 master plan into an execution guard for Stages 45-48.
 Use it before starting any task in the following waves:
 - Stage 45: shared restaurant lifecycle domain and persistence backbone
 - Stage 46: restaurant service and BFF orchestration over the shared lifecycle
 - Stage 47: restaurant web integration for organic cross-app flow
 - Stage 48: end-to-end restaurant flow validation and demo hardening
 ## Stage Baseline
 - Active master plan: `plan/2026-03-31-s44-master-shared-restaurant-lifecycle.md`
 - Supporting review: `plan/2026-03-27-review-current-gap.md`
 - Current execution audit: `plan/2026-03-27-audit-task-execution.md`
 Default wave choices locked by Stage 44:
 - workflow realism before broader feature expansion
 - restaurant integration before remaining furniture depth work
 - operations owns restaurant order and check lifecycle
 - kitchen owns ticket execution state
 - POS eligibility is derived from shared lifecycle state, not isolated UI actions
 ## Architecture Constraints
 The workspace remains locked to:
 ```text
 Blueprint -> BuildingBlock -> Domain -> DAL -> Service -> BFF
 ```
 Execution safety rules:
 - no cross-repo `ProjectReference`
 - no repo may reference `legacy/`
 - BFF repos talk only to Service repos
 - Service repos must not depend on BFF repos
 - DAL repos must not depend on Service or BFF repos
 - Identity ownership remains inside Thalos
 - restaurant apps must share workflow state through service and domain contracts, not through UI-local projection
 Before any implementation task is closed:
 1. validate dependency direction against `rules/15-workspace-dependency-graph.md`
 2. validate no cross-repo `ProjectReference` was introduced
 3. confirm docs were updated in the same repo as the code change
 4. confirm any remaining demo-bounded limitation is documented explicitly
 ## Wave Dependency Order
 The default flow for the Stage 45-48 task graph is:
 1. `ARC-WORKSPACE-GUARD-1000`
 2. domain backbone:
   - `DOM-OPERATIONS-DOMAIN-1000`
   - `DOM-KITCHEN-DOMAIN-1000`
 3. persistence backbone:
   - `ARC-OPERATIONS-DAL-1010`
   - `ARC-KITCHEN-DAL-1010`
 4. orchestration layer:
   - `ARC-OPERATIONS-SERVICE-1020`
   - `ARC-KITCHEN-SERVICE-1020`
 5. restaurant BFF integration:
   - `ARC-WAITER-FLOOR-BFF-1030`
   - `ARC-CUSTOMER-ORDERS-BFF-1030`
   - `ARC-KITCHEN-OPS-BFF-1030`
   - `ARC-POS-TRANSACTIONS-BFF-1030`
 6. restaurant web integration:
   - `WEB-WAITER-FLOOR-WEB-1040`
   - `WEB-CUSTOMER-ORDERS-WEB-1040`
   - `WEB-KITCHEN-OPS-WEB-1040`
   - `WEB-POS-TRANSACTIONS-WEB-1040`
 7. `ARC-RESTAURANT-DEMO-FLOW-1050`
 `DependsOn` remains authoritative when a task file is more specific than this summary.
 ## Shared Restaurant Lifecycle Boundary
 The canonical restaurant flow for this wave is:
 `Draft -> Submitted -> Accepted -> InKitchen -> Preparing -> Ready -> Served -> Payable -> Paid`
 Ownership of the lifecycle is split deliberately:
 - `operations-domain`: order, check, eligibility, and status history rules
 - `kitchen-domain`: ticket and work-item transition rules
 - `operations-service`: orchestration of customer and waiter entry points plus payment eligibility
 - `kitchen-service`: orchestration of ticket progression and completion feedback
 - restaurant BFF/web repos: role-specific views and actions only
 This means:
 - waiter and customer apps must converge on the same order identity
 - kitchen must progress tickets linked to that order identity
 - POS must operate only on payable state derived from the shared lifecycle
 ## Validation Gates
 ### Gate A: Stage 45
 Before Stage 46 starts:
 - lifecycle ownership is documented in `operations-domain` and `kitchen-domain`
 - persistence tasks are ready to implement against explicit lifecycle contracts
 - no repo bypasses Domain ownership while introducing persistence
 ### Gate B: Stage 46
 Before Stage 47 starts:
 - `operations-service` and `kitchen-service` build and test successfully
 - waiter, customer, kitchen, and POS BFF routes are backed by shared-lifecycle service behavior
 - service docs explain any remaining demo limitations clearly
 ### Gate C: Stage 47
 Before Stage 48 starts:
 - waiter-floor, customer-orders, kitchen-ops, and POS web repos pass container-first validation
 - shared identifiers and lifecycle states are visible in the role-specific UIs
 - the apps reflect one workflow rather than isolated status projections
 ### Gate D: Stage 48
 Wave completion requires:
 - the deployed restaurant demo proves an order can move from customer or waiter submission into kitchen and then into POS eligibility
 - docs and runbooks are updated in every touched repo
 - no stale `.repo-tasks/active` entries remain from Stage 45-48 work
 ## Documentation And Comment Rules
 Every implementation task in this wave must:
 - update repo docs in the same change set
 - add meaningful comments where workflow logic is non-trivial
 - keep commit messages free of task, stage, or AI wording
 Web repos additionally must:
 - validate using container-first test and build flow
 - document which lifecycle states and actions are visible to the role-specific UI
 ## Follow-Up Wave
 Stage 48 validation exposed a runtime propagation gap that is now tracked by Stage 49.
 Continue with:
 - `plan/2026-03-31-s49-master-restaurant-propagation-and-runtime-alignment.md`
 - `docs/architecture/stage49-52-restaurant-propagation-guardrails.md`
 Use Stage 49 when newly accepted orders do not yet appear consistently across customer, waiter, kitchen, and POS reads in the deployed demo.
 ## Known Boundaries
 This wave expands restaurant workflow realism, not the entire workspace architecture.
 That means:
 - no new repositories in Stage 45-48
 - no auth provider redesign
 - no furniture feature expansion inside this wave unless a restaurant dependency explicitly forces it
 - no UI-level coordination that bypasses service contracts
--- a/docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.puml
+++ b/docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.puml
@ -1,71 +0,0 @@
@startuml
 title Stage 44-48 Shared Restaurant Lifecycle Guardrails
 skinparam packageStyle rectangle
 skinparam shadowing false
 package "Blueprint" {
  [Workspace Guard]
 }
 package "Domain" {
  [Operations Domain]
  [Kitchen Domain]
 }
 package "DAL" {
  [Operations DAL]
  [Kitchen DAL]
 }
 package "Service" {
  [Operations Service]
  [Kitchen Service]
 }
 package "BFF" {
  [Waiter Floor BFF]
  [Customer Orders BFF]
  [Kitchen Ops BFF]
  [POS Transactions BFF]
 }
 package "Web" {
  [Waiter Floor Web]
  [Customer Orders Web]
  [Kitchen Ops Web]
  [POS Transactions Web]
 }
 [Workspace Guard] --> [Operations Domain]
 [Workspace Guard] --> [Kitchen Domain]
 [Operations Domain] --> [Operations DAL]
 [Kitchen Domain] --> [Kitchen DAL]
 [Operations DAL] --> [Operations Service]
 [Kitchen DAL] --> [Kitchen Service]
 [Operations Service] --> [Waiter Floor BFF]
 [Operations Service] --> [Customer Orders BFF]
 [Operations Service] --> [POS Transactions BFF]
 [Kitchen Service] --> [Kitchen Ops BFF]
 [Operations Service] --> [Kitchen Ops BFF]
 [Waiter Floor BFF] --> [Waiter Floor Web]
 [Customer Orders BFF] --> [Customer Orders Web]
 [Kitchen Ops BFF] --> [Kitchen Ops Web]
 [POS Transactions BFF] --> [POS Transactions Web]
 note right of [Operations Domain]
 Defines restaurant order/check lifecycle
 and payment eligibility rules.
 end note
 note right of [Kitchen Domain]
 Defines kitchen ticket progression
 linked to restaurant orders.
 end note
 note bottom of [POS Transactions Web]
 UI must only expose payment actions
 for payable lifecycle state.
 end note
@enduml
--- a/docs/architecture/stage49-52-restaurant-propagation-guardrails.md
+++ b/docs/architecture/stage49-52-restaurant-propagation-guardrails.md
@ -1,137 +0,0 @@
 # Stage 49-52 Restaurant Propagation Guardrails
 ## Purpose
 This document turns the Stage 49 master plan into an execution guard for Stages 50-52.
 Use it before starting any task in the following waves:
 - Stage 50: restaurant propagation backend fixes
 - Stage 51: BFF read-model alignment and runtime rollout
 - Stage 52: demo reseed, redeploy, and public-host revalidation
 ## Stage Baseline
 - Active master plan: `plan/2026-03-31-s49-master-restaurant-propagation-and-runtime-alignment.md`
 - Supporting review: `plan/2026-03-27-review-current-gap.md`
 - Current execution audit: `plan/2026-03-27-audit-task-execution.md`
 - Prior restaurant flow validation: `docs/consumption/restaurant-demo-flow-validation.md`
 Default wave choices locked by Stage 49:
 - runtime propagation realism before additional feature breadth
 - deployed restaurant behavior must match repo state before validation can pass
 - customer, waiter, kitchen, and POS reads must all reflect the same shared lifecycle records
 - deterministic seeds help walkthroughs, but they do not replace live mutation proof
 ## Architecture Constraints
 The workspace remains locked to:
 ```text
 Blueprint -> BuildingBlock -> Domain -> DAL -> Service -> BFF
 ```
 Execution safety rules:
 - no cross-repo `ProjectReference`
 - no repo may reference `legacy/`
 - BFF repos talk only to Service repos
 - Service repos must not depend on BFF repos
 - DAL repos must not depend on Service or BFF repos
 - runtime rollout must not skip a repo that materially changes lifecycle propagation
 - no summary-only projection may hide a successful shared-lifecycle mutation during Stage 52 validation
 Before any implementation task is closed:
 1. validate dependency direction against `rules/15-workspace-dependency-graph.md`
 2. validate no cross-repo `ProjectReference` was introduced
 3. confirm docs were updated in the same repo as the code change
 4. confirm any remaining demo limitation is documented explicitly
 ## Wave Dependency Order
 The default flow for the Stage 50-52 task graph is:
 1. `ARC-WORKSPACE-GUARD-1100`
 2. backend propagation:
   - `ARC-OPERATIONS-SERVICE-1110`
   - `ARC-KITCHEN-SERVICE-1110`
 3. BFF read-model alignment:
   - `ARC-CUSTOMER-ORDERS-BFF-1120`
   - `ARC-WAITER-FLOOR-BFF-1120`
   - `ARC-KITCHEN-OPS-BFF-1120`
   - `ARC-POS-TRANSACTIONS-BFF-1120`
 4. runtime rollout:
   - `ARC-RESTAURANT-RUNTIME-ROLLOUT-1130`
 5. deterministic reset and revalidation:
   - `ARC-RESTAURANT-DEMO-RESEED-1140`
   - `ARC-RESTAURANT-DEMO-FLOW-1150`
 `DependsOn` remains authoritative when a task file is more specific than this summary.
 ## Propagation Success Criteria
 A Stage 52 validation pass is only considered successful when the deployed public demo proves this flow:
 1. a customer or waiter submits a new restaurant order
 2. the order becomes visible through customer detail or history
 3. the same order becomes visible to the kitchen board
 4. kitchen progression advances the shared lifecycle
 5. waiter-facing reads reflect the live progression
 6. POS exposes the resulting check only when lifecycle state makes it payable
 If any step is still backed by seeded-only or summary-only data, the validation task stays open or blocked.
 ## Validation Gates
 ### Gate A: Stage 50
 Before Stage 51 starts:
 - `operations-service` exposes lifecycle-backed detail and history reads
 - `kitchen-service` exposes ticket visibility for newly accepted orders
 - service docs describe any remaining bounded simplifications explicitly
 ### Gate B: Stage 51
 Before Stage 52 starts:
 - customer, waiter, kitchen, and POS BFF reads no longer depend on summary-only fallbacks for the core flow
 - the latest images are published and the deployed restaurant runtime is refreshed together
 - rollout docs distinguish repo state, image state, and deployed state clearly
 ### Gate C: Stage 52
 Wave completion requires:
 - public-host validation proves newly accepted orders flow across customer, waiter, kitchen, and POS
 - deterministic seed guidance remains aligned with the actual demo files
 - the Stage 48 blocked finding is explicitly resolved or narrowed with evidence
 - no stale `.repo-tasks/active` entries remain from Stage 49-52 work
 ## Documentation And Comment Rules
 Every implementation task in this wave must:
 - update repo docs in the same change set
 - add meaningful comments where propagation logic or fallback removal is non-trivial
 - call out any remaining projection shortcuts clearly in code or docs
 - keep commit messages free of task, stage, or AI wording
 Rollout and validation tasks additionally must:
 - use the public auth host plus public demo hosts as the primary validation path
 - distinguish deterministic seed walkthroughs from live mutation proof
 - record any runtime drift that would invalidate public conclusions
 ## Known Boundaries
 This wave fixes restaurant propagation and runtime truthfulness, not the whole workspace roadmap.
 That means:
 - no new repositories in Stage 49-52
 - no auth provider redesign
 - no furniture expansion inside this wave unless restaurant propagation work proves a shared dependency
 - no UI-side workaround that bypasses the service and BFF boundaries
--- a/docs/architecture/stage49-52-restaurant-propagation-guardrails.puml
+++ b/docs/architecture/stage49-52-restaurant-propagation-guardrails.puml
@ -1,52 +0,0 @@
@startuml
 skinparam monochrome true
 skinparam shadowing false
 skinparam packageStyle rectangle
 title Stage 49-52 Restaurant Propagation Guardrails
 rectangle "Stage 49\nPlanning Guard" as S49 {
  [ARC-WORKSPACE-GUARD-1100]
 }
 rectangle "Stage 50\nBackend Propagation" as S50 {
  [ARC-OPERATIONS-SERVICE-1110]
  [ARC-KITCHEN-SERVICE-1110]
 }
 rectangle "Stage 51\nBFF Alignment + Rollout" as S51 {
  [ARC-CUSTOMER-ORDERS-BFF-1120]
  [ARC-WAITER-FLOOR-BFF-1120]
  [ARC-KITCHEN-OPS-BFF-1120]
  [ARC-POS-TRANSACTIONS-BFF-1120]
  [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130]
 }
 rectangle "Stage 52\nReset + Validation" as S52 {
  [ARC-RESTAURANT-DEMO-RESEED-1140]
  [ARC-RESTAURANT-DEMO-FLOW-1150]
 }
 [ARC-WORKSPACE-GUARD-1100] --> [ARC-OPERATIONS-SERVICE-1110]
 [ARC-WORKSPACE-GUARD-1100] --> [ARC-KITCHEN-SERVICE-1110]
 [ARC-OPERATIONS-SERVICE-1110] --> [ARC-KITCHEN-SERVICE-1110]
 [ARC-OPERATIONS-SERVICE-1110] --> [ARC-CUSTOMER-ORDERS-BFF-1120]
 [ARC-OPERATIONS-SERVICE-1110] --> [ARC-WAITER-FLOOR-BFF-1120]
 [ARC-KITCHEN-SERVICE-1110] --> [ARC-KITCHEN-OPS-BFF-1120]
 [ARC-OPERATIONS-SERVICE-1110] --> [ARC-POS-TRANSACTIONS-BFF-1120]
 [ARC-KITCHEN-SERVICE-1110] --> [ARC-POS-TRANSACTIONS-BFF-1120]
 [ARC-CUSTOMER-ORDERS-BFF-1120] --> [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130]
 [ARC-WAITER-FLOOR-BFF-1120] --> [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130]
 [ARC-KITCHEN-OPS-BFF-1120] --> [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130]
 [ARC-POS-TRANSACTIONS-BFF-1120] --> [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130]
 [ARC-RESTAURANT-RUNTIME-ROLLOUT-1130] --> [ARC-RESTAURANT-DEMO-RESEED-1140]
 [ARC-RESTAURANT-DEMO-RESEED-1140] --> [ARC-RESTAURANT-DEMO-FLOW-1150]
 note bottom
 Validation only passes when a newly accepted order propagates across
 customer, waiter, kitchen, and POS through the deployed public demo hosts.
 end note
@enduml
--- a/docs/architecture/workspace-cross-repo-reference-guard.md
+++ b/docs/architecture/workspace-cross-repo-reference-guard.md
@ -32,10 +32,3 @@ greenfield/blueprint-platform/tools/validate-no-cross-repo-projectrefs.sh
 - Execute this guard before merge to `development`.
 - Keep only intra-repo `ProjectReference` entries.
 - Use package references for cross-repo consumption.
 ## Related Governance Docs
 - `docs/architecture/stage40-43-execution-guardrails.md`
 - `docs/architecture/stage40-43-execution-guardrails.puml`
 - `docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.md`
 - `docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.puml`
--- a/docs/consumption/demo-auth-routing-runbook.md
+++ b/docs/consumption/demo-auth-routing-runbook.md
@ -1,82 +0,0 @@
 # Demo Auth Routing Runbook
 ## Purpose
 This runbook defines the centralized login routing contract used by demo environments.
 - Browser applications are exposed by dedicated demo hosts.
 - Session endpoints are routed through Thalos (`auth.dream-views.com` and identity API paths).
 - Domain BFF APIs remain host-scoped by path.
 Related runtime ownership reference:
 - `docs/consumption/demo-runtime-source-of-truth.md`
 ## Active Public Hosts
 | Host | Role |
 |---|---|
 | `auth.dream-views.com` | Central Thalos auth host |
 | `furniture-display-demo.dream-views.com` | Furniture display web + furniture API + identity API |
 | `furniture-admin-demo.dream-views.com` | Furniture admin web + furniture API + identity API |
 | `kitchen-ops-demo.dream-views.com` | Kitchen web + kitchen API + identity API |
 | `waiter-floor-demo.dream-views.com` | Waiter web + waiter API + identity API |
 | `customer-orders-demo.dream-views.com` | Customer orders web + customer API + identity API |
 | `pos-transactions-demo.dream-views.com` | POS web + POS API + identity API |
 | `restaurant-admin-demo.dream-views.com` | Restaurant admin web + admin API + identity API |
 ## Routing Contract
 ### 1. Central Auth Host
 `auth.dream-views.com` proxies directly to Thalos BFF runtime (`127.0.0.1:20080`).
 Use cases:
 - OIDC launch endpoints (for example `/api/identity/oidc/google/start`)
 - OIDC callback endpoints
 - Session endpoints (`/api/identity/session/*`)
 ### 2. Demo Host Path Routing
 For each demo host:
 - `/api/identity/session*` -> Thalos session upstream
 - domain-specific API paths -> domain BFF upstream
 - all other paths -> web SPA upstream
 ### 3. Domain Path Scopes
 | Host | Domain API Path Prefix |
 |---|---|
 | `furniture-display-demo.dream-views.com` | `/api/furniture*` |
 | `furniture-admin-demo.dream-views.com` | `/api/furniture*` |
 | `kitchen-ops-demo.dream-views.com` | `/api/kitchen/ops*` |
 | `waiter-floor-demo.dream-views.com` | `/api/waiter/floor*` |
 | `customer-orders-demo.dream-views.com` | `/api/customer/orders*` |
 | `pos-transactions-demo.dream-views.com` | `/api/pos/transactions*` |
 | `restaurant-admin-demo.dream-views.com` | `/api/restaurant/admin*` |
 ## Web Runtime Configuration Contract
 All web containers must provide:
 - `API_BASE_URL`: same-origin default for domain API calls
 - `THALOS_AUTH_BASE_URL`: centralized auth base (typically same host or `auth.dream-views.com`)
 - `THALOS_DEFAULT_RETURN_URL`: safe same-origin callback target
 - `THALOS_DEFAULT_TENANT_ID`: tenant context default
 ## Safety Rules
 - Callback return targets must be sanitized to same-origin paths.
 - Identity routes are always Thalos-owned.
 - No direct DAL access from web clients.
 - No cross-repo `ProjectReference` exceptions are introduced by routing changes.
 ## Change Workflow
 1. Update Caddy site entries under `/etc/caddy/sites-enabled/*.caddy`.
 2. Validate Caddy config before reload.
 3. Reload Caddy.
 4. Run demo auth-routing validation checklist (see `docs/consumption/demo-auth-routing-validation.md`).
 5. Confirm the updated route behavior still matches `docs/consumption/demo-runtime-source-of-truth.md`.
 6. Record route changes in this runbook in the same change set.
--- a/docs/consumption/demo-auth-routing-validation.md
+++ b/docs/consumption/demo-auth-routing-validation.md
@ -1,80 +0,0 @@
 # Demo Auth Routing Validation
 ## Scope
 Validate centralized auth routing and per-host API routing for demo stacks.
 ## Prerequisites
 - Caddy is running on the VPS.
 - Demo stacks are running in Portainer.
 - DNS records point to the VPS for all demo hosts.
 ## Caddy Validation
 ```bash
 caddy validate --config /etc/caddy/Caddyfile
 ```
 ```bash
 sudo systemctl reload caddy
 ```
 ## Host Health Checks
 Run from any machine that can resolve public demo hosts:
 ```bash
 curl -i https://auth.dream-views.com/health
 curl -i https://furniture-display-demo.dream-views.com/
 curl -i https://furniture-admin-demo.dream-views.com/
 curl -i https://kitchen-ops-demo.dream-views.com/
 curl -i https://waiter-floor-demo.dream-views.com/
 curl -i https://customer-orders-demo.dream-views.com/
 curl -i https://pos-transactions-demo.dream-views.com/
 curl -i https://restaurant-admin-demo.dream-views.com/
 ```
 ## Identity Route Checks
 ```bash
 curl -i https://furniture-display-demo.dream-views.com/api/identity/session/me
 curl -i https://kitchen-ops-demo.dream-views.com/api/identity/session/me
 curl -i https://restaurant-admin-demo.dream-views.com/api/identity/session/me
 ```
 Expected outcomes:
 - `200` when an authenticated session cookie is present.
 - `401` when no session cookie is present.
 - No `404` on identity paths.
 ## Domain API Route Checks
 ```bash
 curl -i "https://furniture-display-demo.dream-views.com/api/furniture/demo-context/availability"
 curl -i "https://kitchen-ops-demo.dream-views.com/api/kitchen/ops/board?contextId=demo-context"
 curl -i "https://waiter-floor-demo.dream-views.com/api/waiter/floor/assignments?contextId=demo-context"
 curl -i "https://customer-orders-demo.dream-views.com/api/customer/orders/status?contextId=demo-context"
 curl -i "https://pos-transactions-demo.dream-views.com/api/pos/transactions/summary?contextId=demo-context"
 curl -i "https://restaurant-admin-demo.dream-views.com/api/restaurant/admin/config?contextId=demo-context"
 ```
 Expected outcomes:
 - Routed to the corresponding domain BFF.
 - No cross-domain path leakage.
 ## Callback Journey Check
 1. Open one demo web host.
 2. Start Google login.
 3. Complete callback on `auth.dream-views.com`.
 4. Confirm return to same-origin route defined by `THALOS_DEFAULT_RETURN_URL`.
 Expected outcomes:
 - Callback does not redirect to external origins.
 - Session-enabled API calls succeed after login.
 ## Regression Guard
 - Re-run smoke scripts for `greenfield/demo/furniture` and `greenfield/demo/restaurant` after routing changes.
 - Re-check all web containers can still load runtime config values.
--- a/docs/consumption/demo-runtime-source-of-truth.md
+++ b/docs/consumption/demo-runtime-source-of-truth.md
@ -1,120 +0,0 @@
 # Demo Runtime Source Of Truth
 ## Purpose
 This document defines which system is authoritative for demo runtime behavior, how repo docs relate to deployed state, and how to validate or change that state safely.
 The goal is to remove ambiguity between:
 - Portainer stack definitions
 - VPS Caddy site files
 - Vault runtime and bootstrap material
 - repo-owned runbooks and planning documents
 ## Ownership Model
 The source-of-truth model is split by concern.
 | Concern | Canonical Source | Live Materialization | Validation Path |
 |---|---|---|---|
 | Wave intent and execution order | `plan/2026-03-27-s39-master-spa-depth-and-ops-hardening.md` | N/A | Confirm task graph and plan links |
 | Demo routing contract | `docs/consumption/demo-auth-routing-runbook.md` | Caddy site files on VPS | Validate hosts, path routing, and auth flow behavior |
 | Demo container composition | Portainer stack definitions for demo stacks | Running Docker containers on VPS | Validate stack config against docs and deployed services |
 | Secret operations and recovery | `general_information/Vault.md` | Vault host paths and `core-vault` container | Validate unseal, health, and expected secret paths |
 | Registry endpoints and publication targets | `general_information/Gitea.md` | Gitea package and registry services | Validate package/image endpoints and login/pull paths |
 | Cross-repo dependency safety | `docs/architecture/workspace-cross-repo-reference-guard.md` | `.csproj` graph in workspace | Run `tools/validate-no-cross-repo-projectrefs.sh` |
 ## Canonical Interpretation Rules
 Use the following rules when repo docs and runtime state disagree:
 1. Planning files define intended execution order and scope.
 2. Repo runbooks define the expected runtime contract for routing, validation, and operational ownership.
 3. Portainer and Caddy define the actual deployed runtime and must be reconciled back to the repo runbooks.
 4. Vault operational recovery steps remain owned by `general_information/Vault.md` until a repo-owned ops runbook replaces them.
 5. Gitea publication endpoints remain owned by `general_information/Gitea.md` until a repo-owned publication runbook replaces them.
 This means:
 - repo docs are canonical for expected behavior
 - deployed systems are authoritative for current runtime
 - any mismatch must be documented and reconciled, not silently accepted
 ## Required Change Order
 When changing demo runtime behavior, use this order:
 1. Update the relevant repo docs first.
 2. Apply runtime changes in the owning platform:
   - Portainer for demo stacks
   - Caddy for ingress and host routing
   - Vault for runtime secret operations
 3. Validate deployed behavior against the updated docs.
 4. Record any recovery or rollback notes in the same repo-owned runbook.
 ## Current Runtime Boundaries
 ### Portainer
 Portainer owns:
 - demo stack definitions
 - container image references
 - environment variable and mount bindings at stack level
 Portainer does not own:
 - public hostnames
 - Caddy route logic
 - application behavior contracts
 ### Caddy
 Caddy owns:
 - public hostnames
 - reverse proxy path routing
 - auth host and demo host ingress behavior
 Caddy does not own:
 - app container composition
 - secret values
 - application workflow semantics
 ### Vault
 Vault owns:
 - secret storage
 - seal and unseal lifecycle
 - bootstrap and recovery material
 Vault does not own:
 - auth UX behavior
 - route ownership
 - application feature flags outside secret-backed configuration
 ## Validation Checklist
 Before closing any runtime or auth-alignment task:
 - Confirm the active plan and mini plan still match the intended work.
 - Confirm Portainer stacks match the documented demo service layout.
 - Confirm Caddy host and path routing match the documented auth and demo routing contract.
 - Confirm Vault paths and operations notes still match the expected runtime secret behavior.
 - Confirm no cross-repo `ProjectReference` violations were introduced while adjusting repo docs or validation scripts.
 ## Rollback Principle
 Rollback is not automatic.
 If runtime validation fails:
 1. stop at the system that drifted
 2. restore the last known-good runtime configuration in that system
 3. update the repo runbook if the rollback exposed undocumented behavior
 Do not treat repo docs and deployed systems as independent sources of truth.
 They must converge after every runtime-facing change.
--- a/docs/consumption/restaurant-demo-flow-validation.md
+++ b/docs/consumption/restaurant-demo-flow-validation.md
@ -1,72 +0,0 @@
 # Restaurant Demo Flow Validation
 ## Scope
 This document records the restaurant demo validation passes across Stage 48, the Stage 49 propagation follow-up, and the Stage 53 hardening pass hosted behind the public `dream-views.com` demo domains.
 ## Validated On
 - Date: `2026-03-31`
 - Auth entrypoint: `https://auth.dream-views.com`
 - Demo hosts:
  - `https://waiter-floor-demo.dream-views.com`
  - `https://customer-orders-demo.dream-views.com`
  - `https://kitchen-ops-demo.dream-views.com`
  - `https://pos-transactions-demo.dream-views.com`
 ## Confirmed Working
 - Public Thalos session login and cookie-backed session validation work through the public host path.
 - The restaurant runtime was refreshed from current repo state, including `operations-dal`, `kitchen-dal`, `operations-service`, `kitchen-service`, `waiter-floor-bff`, `customer-orders-bff`, `kitchen-ops-bff`, and `pos-transactions-bff`.
 - Public routes for waiter, customer, kitchen, and POS demos return `200`.
 - Customer-origin orders propagate through the shared lifecycle:
  - submission is accepted
  - customer status and detail show the new order
  - kitchen board derives a queued ticket for that order
  - kitchen transitions advance the order into a payable POS check
  - POS capture succeeds for that check
  - customer detail now moves to `paid` after full capture
 - Waiter-origin orders also propagate into waiter activity and kitchen visibility through the same shared lifecycle.
 - New kitchen-derived work-item and ticket IDs now use the full order identity and do not collide for similar numeric suffixes.
 - Kitchen transition responses now return `transitioned: true` when the upstream mutation is applied successfully.
 ## Important Runtime Note
 - Session cookies are scoped to the public `dream-views.com` hosts.
 - Validation against `127.0.0.1` BFF ports does not accurately exercise the deployed session behavior because those cookies do not round-trip on localhost.
 - End-to-end validation for the deployed demo should use the public auth host plus the public demo hosts.
 ## Validation Evidence
 ### Customer-origin flow
 - Submitted order: `ORD-S53-CUSTOMER-002`
 - Kitchen board derived `WK-ORD-S53-CUSTOMER-002` and `KT-ORD-S53-CUSTOMER-002`
 - Kitchen transitions returned `transitioned: true` for prepare, ready, and served steps
 - POS exposed payable check `CHK-ORD-S53-CUSTOMER-002`
 - POS capture succeeded and customer detail became `paid`
 ### Waiter-origin flow
 - Submitted order: `ORD-S53-WAITER-002`
 - Waiter activity reflected the new submission immediately
 - Kitchen board derived `WK-ORD-S53-WAITER-002` and `KT-ORD-S53-WAITER-002`
 ## Accepted Runtime Note
 The live demo still contains historical records created before the collision-safe kitchen ID fix. Those pre-fix rows remain visible until the restaurant demo is reseeded, but newly created orders now derive unique kitchen identifiers correctly.
 ## Stage Status
 - Stage 48 blocked finding is resolved for the core restaurant flow.
 - Stage 49 runtime rollout is complete.
 - Stage 53 hardening is complete for:
  - payment-to-order closure
  - collision-safe kitchen identifier derivation for new orders
  - truthful kitchen transition success reporting
 - The remaining restaurant follow-up is demo reseed hygiene, not runtime propagation correctness.
 ## Recommended Follow-Up
 - execute `ARC-RESTAURANT-DEMO-RESEED-1140` when we want the VPS database reset to a fresh deterministic walkthrough baseline
 - optionally remove or archive pre-fix demo records after the reseed so the board starts from a cleaner demo state
--- a/docs/consumption/secret-provider-rollout.md
+++ b/docs/consumption/secret-provider-rollout.md
@ -32,11 +32,3 @@ The default fallback returns unresolved lookups and never introduces provider-sp
 - Stage 33 keeps this contract-only baseline.
 - Concrete Vault/OIDC provider integration should be implemented in infrastructure/runtime layers only.
 - Existing identity logic ownership remains in Thalos repositories.
 ## Runtime Ownership Note
 Provider contract ownership and runtime operational ownership are separate concerns.
 - Contract ownership for provider-agnostic secret access remains in Blueprint and consuming repos.
 - Vault runtime ownership, bootstrap, and recovery operations currently remain documented in `general_information/Vault.md`.
 - Demo runtime reconciliation guidance is documented in `docs/consumption/demo-runtime-source-of-truth.md`.