docs(blueprint-platform): record restaurant hardening validation

docs/architecture/stage40-43-execution-guardrails.md

@@ -0,0 +1,135 @@
+# 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

docs/architecture/stage40-43-execution-guardrails.puml

@@ -0,0 +1,59 @@
+@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

docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.md

@@ -0,0 +1,169 @@
+# 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
+

docs/architecture/stage44-48-shared-restaurant-lifecycle-guardrails.puml

@@ -0,0 +1,71 @@
+@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

docs/architecture/stage49-52-restaurant-propagation-guardrails.md

@@ -0,0 +1,137 @@
+# 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

docs/architecture/stage49-52-restaurant-propagation-guardrails.puml

@@ -0,0 +1,52 @@
+@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

docs/architecture/workspace-cross-repo-reference-guard.md

@@ -32,3 +32,10 @@ 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`

docs/consumption/demo-auth-routing-runbook.md

@@ -8,6 +8,10 @@ This runbook defines the centralized login routing contract used by demo environ
 - 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 |
@@ -74,4 +78,5 @@ All web containers must provide:
 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. Record route changes in this runbook in the same change set.
+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.

docs/consumption/demo-runtime-source-of-truth.md

@@ -0,0 +1,120 @@
+# 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.

docs/consumption/restaurant-demo-flow-validation.md

@@ -0,0 +1,72 @@
+# 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

docs/consumption/secret-provider-rollout.md

@@ -32,3 +32,11 @@ 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`.