Compare commits
No commits in common. "development" and "feature/secret-provider-contract-foundation" have entirely different histories.
developmen
...
feature/se
@ -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.
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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`
|
||||
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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
|
||||
@ -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`.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user