From 45d718136ebc1e0c3b29e3f787c2ace3b944ed84 Mon Sep 17 00:00:00 2001 From: Adam Spiers Date: Fri, 1 May 2026 17:40:04 +0000 Subject: [PATCH] docs(demo): flag EPDS_CLIENT_THEME as required for client-branding e2e MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Re-running the e2e suite locally on a fresh worktree, all 8 @client-branding scenarios failed because packages/demo/.env didn't set EPDS_CLIENT_THEME. The demo's client-metadata.json then ships no branding.css, so auth-service inlines no theme CSS, so the suite's `expect(html).toContain('body { background: #1a1208')` mismatches. Update the .env.example comment to explicitly call out that running the @client-branding feature requires this var to be set. Doesn't change defaults — production deployments still pick the unthemed path. --- packages/demo/.env.example | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/packages/demo/.env.example b/packages/demo/.env.example index 446732f6..95636f28 100644 --- a/packages/demo/.env.example +++ b/packages/demo/.env.example @@ -48,6 +48,12 @@ AUTH_ENDPOINT=https://auth.pds.example/oauth/authorize # light look, and client-metadata.json ships no branding CSS — the # auth-service then renders its default Certified styling. Available # presets: ocean, amber. +# +# Required (uncomment) to run the @client-branding e2e feature locally: +# the suite asserts that auth-service inlines the demo's branding CSS, +# which only happens when client-metadata.json advertises one. Without +# it, every scenario in features/client-branding.feature fails with +# "expect(html).toContain('body { background: #1a1208')" mismatches. # EPDS_CLIENT_THEME=amber # Session signing secret (generate with: openssl rand -base64 32)