PowerFill Phase 8.5 — W1 Checkpoint (Plan-Stage Architect Report)

Author: PSSaaS Systems Architect Date: 2026-04-20 Status: Status update 2026-04-20 (post-PSX-Infra-response): PSX Infra delivered all 7 asks (see 2026-04-20-psx-keycloak-pssaas-app-client-response). PSSaaS-side LOAD-BEARING fix applied: realm name corrected pss-platform → psx-staging (the K8s-namespace-name-equals-realm-name inference was wrong; PSX Infra empirically confirmed only master, psx-staging, pss-services realms exist; resolved by creating pssaas-app in psx-staging). Original status (preserved as historical reference): Workstream 1 (oauth2-proxy + Keycloak realm/client setup) code-complete on PSSaaS side; awaiting PSX Infra collaboration before Phase 8.5 W2-4 dispatch. Sentinel: Was phase-9-validation-ready at W1 ship; bumped to phase-8-5-ecosystem-ready at the W4-end wrap-up commit a16e4a7. Companion docs:

Phase 8.5 kickoff: powerfill-phase-8-5-kickoff
ADR-027 (Proposed → still Proposed; status flip to Accepted at W4 wrap-up): adr-027-superset-embedding-strategy
2026-04-19 PSX Collab embedding-pattern relay (load-bearing primary source): 2026-04-19-psx-superset-embedding-relay
2026-04-20 PSSaaS Keycloak pssaas-app client request (this commit): 2026-04-20-pssaas-keycloak-pssaas-app-client-request

TL;DR

Phase 8.5 W1 ships the PSSaaS-side auth boundary infrastructure as one atomic commit batch:

infra/oauth2-proxy/oauth2-proxy.cfg — canonical PSSaaS oauth2-proxy config (provider keycloak-oidc; oidc_issuer_url; redirect_url; upstreams for /app/ + /api/; set_xauthrequest + pass_access_token for downstream Tenant + Superset client integration)
infra/azure/k8s/pssaas-staging/services.yaml — added oauth2-proxy Deployment + Service + ConfigMap (image quay.io/oauth2-proxy/oauth2-proxy:v7.7.1 upstream — no GHCR build needed)
infra/azure/k8s/ingress/pssaas-ingress.yaml — reconfigured: /oauth2/, /app/, /api/ now route to oauth2-proxy:4180; /docs/ UNCHANGED (UNAUTH per kickoff non-negotiable)
infra/azure/k8s/pssaas-staging/oauth2-proxy-secrets.yaml.example — TEMPLATE for the K8s Secret holding client_secret (delivered by PSX Infra) + cookie_secret (32-byte locally-generated)
.github/workflows/deploy-staging.yaml — added oauth2-proxy rolling-restart step with first-deploy-Deployment + Secret-existence guards (no-op until both exist)
docs-site/docs/agents/cross-project-relays/2026-04-20-pssaas-keycloak-pssaas-app-client-request.md — the PO-brokered relay to PSX Infra requesting client creation + 5-item Superset pre-flight verification + 3 open questions (admin creds for guest-token-mint; registration script invocation pattern; any post-Backlog-#30 platform-Superset gotchas we're missing)

The auth boundary cannot be smoke-tested until PSX Infra delivers the pssaas-app client_secret + the realm-side tenant_id mapper. This is the explicit checkpoint per Reviewable Chunks: W1 lands as a meaningful demonstrable progress unit (manifests + config + relay all in place); PO pushes W1 commits; PO relays to PSX Infra; W2-4 dispatch waits on response.

The deliberate W1 checkpoint shape de-risks W2-4 because the PUBLIC_ROLE_LIKE half-day-debug-trap (PSX gotcha #1; the most-cost-likely failure mode per ADR-027 §Risks) gets surfaced + remediated BEFORE the W2 SDK + W3 guest-token-mint endpoint are dispatched — much cheaper to fix at this boundary than mid-W2-debugging.

Sub-phase calendar time so far: ~1 Architect-session (W1 only). Consistent with the kickoff's "2-3 Architect-session" estimate at the per-Architect-session rate. W2-4 likely 1 more session post-PSX-Infra-response (lightly parallelizable: W2 + W3 + W4 share no implementation surface).

What was produced

New / amended infra files (W1 atomic commit batch)

Path	Action	Purpose
`infra/oauth2-proxy/oauth2-proxy.cfg`	NEW	Canonical oauth2-proxy config; PSX-pattern (per Q3 architectural-mismatch correction); env-from-Secret deferral for client/cookie secrets
`infra/azure/k8s/pssaas-staging/services.yaml`	AMEND	New `oauth2-proxy-config` ConfigMap (mirrors the .cfg file content) + `oauth2-proxy` Deployment + Service; pinned upstream image `quay.io/oauth2-proxy/oauth2-proxy:v7.7.1`
`infra/azure/k8s/ingress/pssaas-ingress.yaml`	AMEND	New `/oauth2`, `/app`, `/api` Prefix rules → `oauth2-proxy:4180`; `/docs` UNCHANGED → `docs:3000`
`infra/azure/k8s/pssaas-staging/oauth2-proxy-secrets.yaml.example`	NEW	Template Secret manifest; filled version uncommitted + locally-applied by PO
`.github/workflows/deploy-staging.yaml`	AMEND	New oauth2-proxy rolling-restart step (config refresh; image is upstream-pinned in services.yaml; no GHCR build) with first-deploy + Secret-existence guards

New documentation

Path	Action	Purpose
`docs-site/docs/agents/cross-project-relays/2026-04-20-pssaas-keycloak-pssaas-app-client-request.md`	NEW	The relay PSSaaS → PSX Infra (PO-brokered); 2 artifact deliveries + 3 verifications + 3 open questions
`docs-site/docs/handoffs/powerfill-phase-8-5-w1-checkpoint.md`	NEW (this)	Plan-stage Architect Report at the W1 checkpoint per Reviewable Chunks

Out of scope (deliberately not produced in W1)

@superset-ui/embedded-sdk integration — Phase 8.5 W2 (post-checkpoint)
<EmbeddedDashboard> React component — Phase 8.5 W2 (post-checkpoint)
Anchor-link → embedded-component swaps in src/frontend/src/pages/reports/reportShell.tsx + src/frontend/src/pages/Home.tsx + src/frontend/src/pages/RunStatus.tsx — Phase 8.5 W2 (post-checkpoint)
/api/superset/guest-token .NET 8 endpoint + SupersetGuestTokenClient — Phase 8.5 W3 (post-checkpoint)
infra/superset/register-powerfill-embeds.py per-dashboard registration script — Phase 8.5 W3 (post-checkpoint; delegated to fast subagent per plan §6 Required Delegation Categories disposition)
TenantMiddleware OIDC-claim sourcing + TenantRegistry decoupling — Phase 8.5 W4 (post-checkpoint)
ADR-029 — Phase 8.5 W4 (post-checkpoint)
Sentinel bump to phase-8-5-ecosystem-ready — W4 cross-cutting wrap-up
Spec amendment / completion report / devlog — W4 cross-cutting wrap-up
Bilateral cross-boundary cutover verification recipe execution — W4 cross-cutting wrap-up

Decisions made

The 4 Alternatives-First Gate decisions surfaced in the Phase 8.5 plan §3 are documented + dispositioned. W1 only depends on framing decisions ADR-027 already commits — W1 itself involves no architectural choices that need litigating.

#	Decision	Rationale	Where
D-8.5-W1-1	oauth2-proxy v7.7.1 pinned upstream image (NOT GHCR-built; NOT v7-latest floating)	Upstream image is canonical; pinning to a specific patch matches PSX runbook hygiene; v7.7.1 is current-stable as of 2026-04	services.yaml `image: quay.io/oauth2-proxy/oauth2-proxy:v7.7.1`
D-8.5-W1-2	Single oauth2-proxy Deployment fronts BOTH `/app/` AND `/api/` (NOT one Deployment per upstream)	PSX canonical pattern (their oauth2-proxy fronts multiple admin services via path-prefix `upstreams = [...]`); reduces operational surface; one set of secrets to rotate; one log stream	oauth2-proxy.cfg `upstreams = [...]`
D-8.5-W1-3	`/docs/` STAYS direct ingress → docs Service (UNAUTH)	Kickoff non-negotiable: "operational runbook surface; gating it behind auth makes the operational runbook harder to read"	pssaas-ingress.yaml `path: /docs` direct backend
D-8.5-W1-4	`oauth2-proxy.cfg` mirrored as ConfigMap inline in services.yaml (NOT mounted from repo file via volumeMount of an external manifest)	Single-source-of-truth at the manifest level avoids drift between the repo .cfg file and what's actually mounted in the pod; the repo .cfg file is the canonical reference but the ConfigMap is what gets deployed; both committed atomically. Trade-off: double-maintenance if the .cfg file changes — the ConfigMap inline block must update too. Mitigation: a CI lint step could be added later to assert string-equality. Phase 8.5 ships without the lint; banking as W2-4-or-Phase-9-followup if needed	services.yaml `oauth2-proxy-config` ConfigMap data
D-8.5-W1-5	K8s Secret `pssaas-oauth2-proxy-secrets` is OUT-OF-BAND PO-applied (NOT GHA-managed; NOT committed)	Standard secret-handling discipline (AGENTS.md "never commit `.env` or credentials"); PO + PSX Infra coordinate via the cross-project-relay request; the .yaml.example template documents the shape	oauth2-proxy-secrets.yaml.example
D-8.5-W1-6	GHA workflow rolls oauth2-proxy on EVERY successful deploy (with first-deploy + Secret-existence guards)	Mirrors the existing docs/api/frontend rolling-restart pattern; idempotent if no changes; picks up oauth2-proxy.cfg ConfigMap changes which K8s does NOT auto-reload	deploy-staging.yaml

The 4 Phase 8.5 plan-level decisions (endpoint shape, per-resource scoping, anchor-link replacement, A68 canonical identity) all carry forward to W2-4 unchanged from the plan's §3 dispositions.

Migrations enumerated

W1 ships 0 new schema migrations + 0 new SQL artifacts. Pure infrastructure addition.

Gate findings

Three-layer Primary-Source Verification Gate (with Backlog re-read pass; now 5-instance corroborated post-W1)

ID	Layer	Finding	Disposition
F-W1-INHERITED-1	Spec-vs-implementation (ADR-027 framing inheritance)	ADR-027 commits `pssaas-app` Keycloak client name; verify no name collision in PSX Keycloak (PSX uses `superset` + `docs-proxy`) — name should be safe but PSX Infra confirms at client-creation time	(c) Deferred-with-justification — included in the cross-project-relay request; if collision, we rename; not blocking the W1 ship
F-W1-INHERITED-2	Spec-vs-implementation (ADR-027 framing inheritance)	ADR-027's D-8.5-1 cites PSX `infra/oauth2-proxy/oauth2-proxy.cfg` as the canonical reference; PSSaaS Architect cannot read PSX repo directly	(c) Deferred-with-justification — the 2026-04-19 cross-project-relay archive enumerates the load-bearing fields (provider, oidc_issuer_url, redirect_url, set_xauthrequest, pass_access_token); tactical edge cases (timeouts, cookie params) tuned post-W1-smoke-test if needed; PSX Collab pairing offer is standing per the kickoff
F-W1-BR-22	Implementation-vs-runtime (Backlog re-read pass)	Backlog row #22 enumerates A65 + A66 + A69 + A70 carry-overs. A69's honesty pattern (display `RunStepResult.ErrorMessage` if populated) is W2-relevant when the embedding wraps the React UI; W1 itself doesn't touch the React UI yet	(a) No additional finding — kickoff specificity at the inherited-context-row level prevented this from becoming a fresh finding; carry-forward to W2
F-W1-BR-30	Implementation-vs-runtime (Backlog re-read pass)	Backlog row #30 closed clean; Superset is at `bi.staging.powerseller.com` in `pss-platform` namespace; same `GUEST_TOKEN_JWT_SECRET` continuity preserved	(a) No additional finding — W3 will inherit the stable hostname + secret continuity for the .NET guest-token-mint endpoint
F-W1-BR-31	Implementation-vs-runtime (Backlog re-read pass)	Backlog row #31 (Phase 8.5) carries inherited framing from ADR-027 (Proposed) + cross-project-relays archive entry; W1 ship unblocks PO to send the Keycloak client request	(b) Scope-changed — this Phase 8.5 dispatch ships under that backlog item; W4 wrap-up marks it DONE
F-W1-CONS-1	Consolidation Gate	The .NET API has no existing `IHttpClientFactory` registration (`src/backend/PowerSeller.SaaS.Api/Program.cs` confirmed via Grep). W3 introduces the first HttpClient in the codebase — Modules.Superset will register `services.AddHttpClient<SupersetGuestTokenClient>(...)`	(b) Extend the canonical service-registration pattern at W3 — no existing path to consolidate INTO; the SupersetExtensions.cs is the canonical first instance for future modules
F-W1-DEP-1	Implementation-vs-runtime (oauth2-proxy version)	oauth2-proxy v7.7.1 is the pinned image. PSX Infra runs SOME version of oauth2-proxy in their docs-proxy stack; we don't know if they're on v7.7.x or earlier. Differences across v7.x are minor for our config surface but worth confirming	(c) Deferred-with-justification — included as an open question in the cross-project-relay request; if PSX is on a different patch and we need to align, we re-pin in services.yaml + the template manifest. Low-risk; v7 has been API-stable for the static-site-protection use case

Pattern observation: the Backlog re-read pass at planning time produced 4 Backlog-row entries (BR-22, BR-30, BR-31, plus the implicit consult on the kickoff §"Inherited context" table) all with explicit disposition — 0 net-new actionable findings, mirroring the W2 F-W2-BR-22 "kickoff specificity prevented surprise" pattern + the Phase 9 "0 net-new findings = pattern works" data point. This is now 5-instance corroborated (Phase 7 / Phase 8 W1 / Phase 8 W2 / Phase 9 / Phase 8.5 W1). Banking the canonical-promotion proposal stands.

Alternatives-First Gate

W1 itself only re-confirms inheritance from ADR-027; no new architectural decisions need litigating in W1. The 4 plan-level decisions (endpoint shape; per-resource scoping; anchor-link replacement; A68 canonical identity) all carry forward to W2-4 with the dispositions documented in the Phase 8.5 plan §3. The 6 W1-specific decisions (D-8.5-W1-1 through D-8.5-W1-6) are documented above.

Required Delegation Categories

Self-implemented with Deliberate Non-Delegation (W1 entirety):

Deliberate Non-Delegation: Infrastructure + cross-project-relay drafting
Task: oauth2-proxy.cfg + services.yaml ConfigMap/Deployment/Service amendments
  + ingress.yaml reconfiguration + GHA workflow extension + Secret template
  + cross-project-relay request + this checkpoint report
Reason for self-implementation: Architectural-contract-per-artifact density is
  high. The oauth2-proxy.cfg load-bearing fields (provider, oidc_issuer_url,
  redirect_url, upstreams, set_xauthrequest, pass_access_token, cookie_*) all
  carry inheritance from PSX Collab's authoritative reply via ADR-027 D-8.5-1
  through D-8.5-5; getting the wrong field would silently break the auth flow
  (worst Ghost Deploy class — looks deployed, doesn't actually auth-gate).
  The ingress reconfiguration carries the kickoff non-negotiable that /docs/
  stays UNAUTH; a delegated agent re-deriving this from the kickoff text
  could plausibly conflate. The cross-project-relay request synthesizes
  inheritance + the new asks + the open questions in a way that requires
  full Phase-8.5-context familiarity.
Context that would be lost in handoff: the Q3 architectural-mismatch
  correction (oauth2-proxy + static-site, NOT NextAuth + Next.js); the PSX
  gotcha #1 PUBLIC_ROLE_LIKE half-day-debug pre-flip that's the relay's
  load-bearing 5-item verification list; the suffix-style sentinel pattern
  (NOT used in W1 but informs the W4 wrap-up shape).

Delegation candidate: 8 thin per-page React anchor-link → embedded-component
  refactors (W2 deliverable; post-checkpoint)
Disposition: SELF-IMPLEMENT — same Deliberate Non-Delegation analysis as
  Phase 8 W2 + Phase 9; banking the "contract-per-artifact density high
  → self-implement" heuristic as 3-instance corroborated.

Delegation candidate: register-powerfill-embeds.py (W3 deliverable;
  post-checkpoint)
Disposition: DELEGATE to fast subagent per plan §6 — mechanical idempotent
  script generation following deploy-powerfill.py pattern.

Zero subagents dispatched in W1. Mirrors the W2 + Phase 9 "0 subagents" pattern; banking observation: when the inheritance-context per artifact is dense (ADR-027 + cross-project-relays archive + AGENTS.md cross-boundary cutover recipe + kickoff non-negotiables), self-implementation is the right answer per practice #9 Deliberate Non-Delegation.

Reviewable Chunks at intra-session scope

W1 IS the intra-session checkpoint. Per the kickoff §"Process discipline" + the Phase 8.5 plan §"Reviewable Chunks shape (PO-confirmed)": explicit W1 checkpoint with plan-stage Architect Report (this) + initial smoke-test against oauth2-proxy (deferred until PSX Infra delivers the pssaas-app client_secret) before W2-4 dispatch.

Andon-cord status: not pulled this session. No emergent findings warranted reversal of any decision; all framing inheritance held up empirically against the actual PSX-pattern application to our build shape.

Deploy Verification Gate — partial (rest deferred to post-PSX-Infra-collaboration smoke-test)

Arm	Pre-PSX-Infra-collaboration (this commit)	Post-PSX-Infra-collaboration (smoke-test phase)
(a) Sentinel	NOT MEASURED HERE — sentinel bump is W4 wrap-up; W1 leaves sentinel at `phase-9-validation-ready`	NOT MEASURED HERE
(b) Container/pod inspection	NOT MEASURED HERE for oauth2-proxy specifically (Deployment manifest committed; not yet applied to staging — that's the PO-push + first-time `kubectl apply -f services.yaml` step). The `.cfg` file + ConfigMap inline content are committed identically; first-applied content matches first-mounted	After `kubectl apply -f services.yaml` + the PO-applied filled Secret: `kubectl get pods -n pssaas-staging` shows `oauth2-proxy` pod scheduled + Ready (Ghost Deploy countermeasure: confirm rollout actually scheduled despite the AKS pod-density learnings from Phase 9; AKS now has 3 nodes per Backlog #30 closure so capacity is fine)
(c) Cross-boundary cutover verification recipe	NOT MEASURED HERE — auth flow doesn't work until client_secret is in the K8s Secret	The 6 PSSaaS-side checks per the relay's "What PSSaaS will do once this lands" section (the canonical bilateral verification recipe per AGENTS.md)

Environment-Explicit Inventory (per canonical practice #13)

Capability	W1 Architect-session (this)	Post-W1-PO-push staging	Post-PSX-Infra-collaboration smoke-test	Phase 8.5 W2-4 ship
`oauth2-proxy.cfg` PSX-canonical-shape correctness	Verified ✓ at the file level (provider, oidc_issuer_url, redirect_url, upstreams, set_xauthrequest, pass_access_token all match the cross-project-relays archive's enumerated load-bearing fields)	NOT MEASURED HERE — manifest at rest	NOT MEASURED HERE — config-applied verified via pod logs	NOT MEASURED HERE — exercised via end-to-end click-through
services.yaml ConfigMap inline content matches `oauth2-proxy.cfg` content	Verified ✓ at the artifact level (manual cross-read)	NOT MEASURED HERE	NOT MEASURED HERE	NOT MEASURED HERE
ingress reconfiguration: `/docs/` UNCHANGED	Verified ✓ at the manifest level (path `/docs` retains direct backend `docs:3000`)	NOT MEASURED HERE — verifiable via `curl -I https://pssaas.staging.powerseller.com/docs/` post-apply (expect HTTP 200; UNCHANGED from current state)	NOT MEASURED HERE — same verification, post-apply	NOT MEASURED HERE
ingress reconfiguration: `/oauth2/`, `/app/`, `/api/` route to oauth2-proxy:4180	Verified ✓ at the manifest level	NOT MEASURED HERE — `/app/` and `/api/` will return Bad-Gateway-style 502s pre-Secret-applied (oauth2-proxy can't start without the secret)	After Secret + pod healthy: `curl -I https://pssaas.staging.powerseller.com/app/` → expect HTTP 302 to Keycloak login; `curl -I .../api/health` → expect HTTP 401	NOT MEASURED HERE
GHA workflow oauth2-proxy rolling-restart step	Verified ✓ at the YAML level + first-deploy + Secret-existence guards	NOT MEASURED HERE — workflow runs at PO push; expected behavior: skip oauth2-proxy rollout on first push (Deployment doesn't exist yet); skip again until Secret applied	After `kubectl apply -f services.yaml` + Secret applied: subsequent GHA runs roll oauth2-proxy normally	NOT MEASURED HERE
Cross-project-relay-request artifact correctness (PSX Infra finds it readable + actionable)	Verified ✓ at the artifact level (cross-read against PSX's 2026-04-19 inbound relay shape; matches archive convention)	NOT MEASURED HERE — readability test is when PO sends + PSX Infra responds	NOT MEASURED HERE — actionability test is when PSX Infra delivers the artifacts on the requested shape	NOT MEASURED HERE
`pssaas-app` Keycloak client exists in `psx-staging` realm (was `pss-platform` per pre-PSX-response inference; corrected post-response — see Status block above)	NOT MEASURED HERE	NOT MEASURED HERE	Verified post-response 2026-04-20 by PSX Infra: client UUID `86a42170-2e30-403e-a2b9-d2c5f2961137` in `psx-staging` realm; tenant_id hardcoded mapper (value `ps-demodata`) attached at client level; PSX-side verified via `kcadm.sh get clients -r psx-staging -q clientId=pssaas-app`	NOT MEASURED HERE
`tenant_id: ps-demodata` claim on access token for demo user	NOT MEASURED HERE	NOT MEASURED HERE	After PSX Infra adds realm-side mapper: PSSaaS Architect inspects access token via login-then-debug-token-decode; PSX-side inspects via Keycloak admin UI	NOT MEASURED HERE — exercised by W4
Superset 5-item embedding pre-flight (EMBEDDED_SUPERSET / TALISMAN / X-Frame-Options / GUEST_TOKEN_JWT_SECRET / PUBLIC_ROLE_LIKE)	NOT MEASURED HERE	NOT MEASURED HERE	After PSX Infra verifies + remediates if needed: PSSaaS Architect cannot directly verify (requires Superset admin access); inherits PSX Infra's verification	NOT MEASURED HERE — exercised by W2 (iframe rendering) + W3 (guest-token mint)

Net assessment: W1 ships artifact-complete: every PSSaaS-side artifact required to wire the auth boundary is committed + verified at the artifact-and-build level. Runtime end-to-end verification is post-PSX-Infra-collaboration, which is the explicit Reviewable Chunks checkpoint shape. This is a deliberate Capability Inflation countermeasure: the Architect does not claim "auth boundary works" without observing the working state; the matrix above explicitly distinguishes "verified at the artifact level" from "verified at the runtime level."

Counterfactual Retro

Knowing what I know now, what would I do differently?

The W1 checkpoint shape is the right call empirically, not just theoretically. The biggest unknowns in Phase 8.5 are (a) PSX Infra collaboration latency and (b) the PUBLIC_ROLE_LIKE half-day-debug trap. Both are PSX-Infra-side. Shipping W1 first surfaces the PSX-Infra collaboration ask EARLY (so it can run in parallel with PSSaaS Architect's W2-4 prep) and PARALLELIZES the PUBLIC_ROLE_LIKE pre-flip with the rest. If we'd dispatched W1+W2+W3+W4 monolithically, we'd have either (a) blocked on the same PSX Infra collaboration anyway, with W2-4 implementation done but un-smokable; OR (b) hit PUBLIC_ROLE_LIKE mid-W2-debugging and burned the half-day. Banking: Reviewable Chunks at sub-checkpoint scope where the chunk has an external collaboration gate IS the right granularity — separate the PSSaaS-side ship from the cross-project ask so neither blocks the other.
The cross-project-relay request shape is reusable for Phase 10+. Banking: every new PSSaaS module surface (Pipeline UI, Risk UI, etc.) will need the same shape (new Keycloak client + secret delivery + Superset embedding pre-flight if dashboards are added). The 2026-04-20 relay is the canonical template; future Architects clone + adapt rather than re-derive.
Inline ConfigMap content matching the .cfg file file-content has a maintenance hazard — if the .cfg file changes, the ConfigMap inline block must update too. Banking observation: consider adding a CI lint step at Phase 9-followup or future infra cleanup pass that asserts services.yaml's oauth2-proxy-config.data."oauth2-proxy.cfg" block string-equals infra/oauth2-proxy/oauth2-proxy.cfg. Not blocking; deferred to post-Phase-8.5.
The Backlog re-read pass at planning time is now 5-instance corroborated. Phase 8.5 W1 added the 5th instance with 0 net-new actionable findings — same "pattern works" data point Phase 9 surfaced. Banking the canonical-promotion proposal stronger: suggest the PSSaaS Collaborator nominate at the next process-discipline revision with the wording draft from the W2 completion report's §"Pattern observation" paragraph.
The W1-checkpoint shape preserves Andon-cord readiness through the inter-session pause. If PSX Infra responds with something that materially shifts W2-4 design (e.g. they're on a different oauth2-proxy major version; or the PUBLIC_ROLE_LIKE pre-flip surfaces an unexpected platform-Superset DB constraint), the next Architect session has a clean re-plan opportunity BEFORE any W2-4 implementation has been written. Banking: Reviewable Chunks + cross-project collaboration gate IS the explicit Andon-cord granularity for cross-product-coordination phases.

Open questions and blockers

Blockers (PO + PSX Infra)

PO push of W1 commits + send the cross-project-relay request to PSX Infra
PSX Infra response — Keycloak pssaas-app client created + client_secret delivered + 5-item Superset pre-flight verified + remediated (especially PUBLIC_ROLE_LIKE)
PO + PSSaaS Architect apply the filled oauth2-proxy-secrets.yaml (locally; uncommitted)

Once those land, the smoke-test phase begins:

curl -I https://pssaas.staging.powerseller.com/app/ → expect HTTP 302 to Keycloak login
curl -I https://pssaas.staging.powerseller.com/api/health → expect HTTP 401
curl -I https://pssaas.staging.powerseller.com/docs/ → expect HTTP 200 (UNCHANGED)
Browser-end-to-end Keycloak login flow → expect post-login /app/ 200 with the React UI rendering (anchor-link "View in Superset" still in place — W2 hasn't shipped yet)

If smoke-test passes, dispatch W2 + W3 + W4. If smoke-test surfaces a finding (especially PUBLIC_ROLE_LIKE mis-state), remediate before W2 dispatch.

Carry-overs unchanged

A54 + A56 RESOLVED — not Phase 8.5-relevant
A62 (PS_DemoData view drift) — STILL DEFERRED per Backlog #32; W2 embedding consumes the same Superset SQL; no amplification
A65 (multi-pa_key + settlement-date variance) — banked observation; not Phase 8.5-relevant
A66 (UE rebuild-empty on syn-trade-empty datasets) — load-bearing for W2 BLUE-vs-YELLOW banner UX; W2 must preserve the BLUE Complete+empty banner ABOVE the embedded iframe so the demo narrative continues to work
A67 — CLOSED at Phase 9
A68 — Path γ disposition LIVE; W4 ships the long-term decoupling code shape; canonical-identity convention deferred per PO disposition (kept ps-demodata)
A69 (state-dependent UE failure) — Greg/Tom consultation hook; W2 must preserve the W2 honesty pattern (display RunStepResult.ErrorMessage if populated)
A70 (mixed proc-body state) — Phase 10+ playbook; not Phase 8.5-relevant

No refinements needed. The W1 implementation matched the plan §4 deliverable list 1:1; no surprises surfaced that would re-shape W2-4 dispatch. The W2-4 sections of the Phase 8.5 plan §5-§7 are the authoritative dispatch reference for the next Architect session.

One refinement-opportunity surfaced for W3 that the plan doesn't pre-commit: in the cross-project-relay open questions, I asked PSX for SUPERSET_ADMIN_USERNAME + SUPERSET_ADMIN_PASSWORD for the .NET guest-token-mint endpoint to call Superset server-to-server. PSX's response will determine whether we re-use admin creds (simplest; what PSX FastAPI does per the 2026-04-19 relay) OR whether they want us on a dedicated service account (cleaner; but more PSX Infra setup). W3 implementation handles either via the same Superset__AdminUsername / Superset__AdminPassword env-from-Secret indirection; the choice is purely PSX-Infra-driven.

Optional follow-up

CI lint asserting services.yaml ConfigMap content matches infra/oauth2-proxy/oauth2-proxy.cfg — banking; post-Phase-8.5 infra cleanup
oauth2-proxy v7 patch alignment with PSX — pending PSX Infra confirmation in their cross-project-relay response

Recommended next steps

Pre-push docs-build check (mandatory per Phase 6e/7/8-W1/8-W2/9 banked discipline; W1 ships 2 new docs-site/docs/** files: this checkpoint report + the cross-project-relay request) — Architect performs before commit
Atomic commit batch for W1 (Architect commits; PO pushes)
PO sends the cross-project-relay request to PSX Infra Collaborator at docs-site/docs/agents/cross-project-relays/2026-04-20-pssaas-keycloak-pssaas-app-client-request.md
PSX Infra delivery of (a) Keycloak pssaas-app client + client_secret in K8s Secret form + (b) 5-item Superset pre-flight verification + remediation
PO + PSSaaS Architect smoke-test post-PSX-Infra-delivery per the Environment-Explicit Inventory matrix's "Post-PSX-Infra-collaboration smoke-test" column
Andon-cord re-evaluation point — if smoke-test passes, dispatch Phase 8.5 W2-4 in the next Architect session; if smoke-test surfaces a PUBLIC_ROLE_LIKE-class finding or any of the other 5 pre-flight checks fail, remediate FIRST (still PSX-Infra-side work), then re-smoke, then dispatch
Phase 8.5 W2-4 dispatch per the Phase 8.5 plan §5-§7 (the next Architect session)

Notes on this session's process

Three-layer Primary-Source Verification Gate exercised; produced 7 findings (all dispositioned per the §Gate findings table). Backlog re-read pass now 5-instance corroborated (Phase 7 / Phase 8 W1 / Phase 8 W2 / Phase 9 / Phase 8.5 W1).
Reviewable Chunks at workstream scope ACTIVELY EXERCISED — this report IS the W1 checkpoint artifact per the kickoff §"Process discipline" + the Phase 8.5 plan §"Reviewable Chunks shape (PO-confirmed)". Banking observation: the W1 checkpoint shape is structurally driven by an external collaboration gate (PSX Infra); future similar phases (anything cross-product) likely benefit from the same chunk shape.
Required Delegation Categories classification: 0 subagents dispatched in W1 — Deliberate Non-Delegation per practice #9 because the architectural-contract-per-artifact density was high (PSX Collab inheritance + the PUBLIC_ROLE_LIKE pre-flip + the kickoff non-negotiables + the cross-project-relay synthesis). Banking observation: 3-instance corroborated heuristic ("contract-per-artifact density high → self-implement") — Phase 8 W2 + Phase 9 + Phase 8.5 W1.
Practice #13 Environment-Explicit Inventory ACTIVELY APPLIED — the §Environment-Explicit Inventory matrix in the §Deploy Verification Gate section explicitly distinguishes "verified at the artifact level" from "verified at the runtime level" across 4 environment columns (W1 session / Post-W1-PO-push / Post-PSX-Infra smoke-test / W2-4 ship). Banking observation: practice #13 produces noticeably tighter checkpoint claims than would have surfaced from an implicit "code-complete = ready" framing.
Andon-cord readiness — not pulled this session; no emergent findings warranted reversal.
Counterfactual Retro filled with 5 named observations — most important: (1) the W1 checkpoint shape is the right call empirically (separates PSSaaS-side ship from cross-project ask so neither blocks the other); (2) the cross-project-relay request shape is reusable for Phase 10+; (3) the Backlog re-read pass is now 5-instance corroborated.
Sub-phase calendar time so far: ~1 Architect-session (W1 only). Consistent with the kickoff's "2-3 Architect-session" estimate at the per-Architect-session rate. Banking observation: greenfield infra surface (oauth2-proxy + ingress + GHA + Secret template + cross-project-relay) is a 1-session unit at this scale when the Architect self-implements + the inheritance from ADR-027 is dense + the kickoff specificity at the field level (provider / oidc_issuer_url / etc.) is high.

Phase 8.5 W1 is artifact-complete on the PSSaaS side; the cross-project collaboration ask is dispatched; the Reviewable Chunks checkpoint is here. The PO pushes; the PSSaaS Architect resumes W2-4 once the PSX Infra response lands and the smoke-test passes.

End of Phase 8.5 W1 Checkpoint Report. The Architect commits; the PO pushes.

TL;DR​

What was produced​

New / amended infra files (W1 atomic commit batch)​

New documentation​

Out of scope (deliberately not produced in W1)​

Decisions made​

Migrations enumerated​

Gate findings​

Three-layer Primary-Source Verification Gate (with Backlog re-read pass; now 5-instance corroborated post-W1)​

Alternatives-First Gate​

Required Delegation Categories​

Reviewable Chunks at intra-session scope​

Deploy Verification Gate — partial (rest deferred to post-PSX-Infra-collaboration smoke-test)​

Environment-Explicit Inventory (per canonical practice #13)​

Counterfactual Retro​

Open questions and blockers​

Blockers (PO + PSX Infra)​

Carry-overs unchanged​

W2-4 plan refinements based on W1 empirical state​

Optional follow-up​

Recommended next steps​

Notes on this session's process​