Ben Stull
999c4b65ef
Implements the M3-frontend slice of the §22 multi-project track, per docs/superpowers/specs/2026-06-03-m3-frontend-design.md (design merged in #10). Completes the runtime-config cut 0.33.0 (M3-backend Plan A) began. Frontend: - DeploymentProvider boots GET /api/deployment → {name, tagline, defaultProjectId, projects}; brandTitle() neutral 'RFC' pre-fetch fallback. - /p/:projectId/* routing with generic /e/<slug> segment. ProjectLayout fetches /api/projects/:id, applies per-project theme (reset on switch), provides ProjectContext, guards the corpus (served only for the default; others get NotServedPlaceholder — decouples this slice from Plan B). - Directory at / (2+ projects) with N=1 redirect into the single project; ProjectSwitcher in deployment chrome; entry-noun by project type. - VITE_APP_NAME hard cut: removed from vite.config + index.html; the 6 brand reads now use deployment.name via context; static <title>RFC</title> + JS document.title. Internal /rfc·/proposals links → /p/<project>/e|proposals via lib/entryPaths. Backend: - GET /api/deployment returns default_project_id (the guard contract). - Server-side 308s: /rfc/<slug>, /rfc/<slug>/pr/<n>, /proposals/<n> → /p/<default>/… . nginx (testing + prod) routes /rfc/ and /proposals/ to the backend. Tests: 3 new backend redirect/deployment tests (438 pass); Vitest unit for DeploymentProvider, ProjectLayout (theme/guard/404), Directory (11 pass); clean build with no VITE_APP_NAME. Playwright e2e deferred until Tier-1 seeds a registry (see CHANGELOG 0.35.0 step 5). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
83 lines
3.9 KiB
Bash
83 lines
3.9 KiB
Bash
# Frontend build-time configuration. Copy to `frontend/.env` and fill in.
|
|
#
|
|
# Vite picks up VITE_* variables from these files at build (`npm run build`)
|
|
# and dev (`npm run dev`) time. Real `.env` files are gitignored; only this
|
|
# `.env.example` is committed.
|
|
|
|
# §22.9 (M3, v0.35.0): the deployment name is NO LONGER a build-time var.
|
|
# It comes from the registry (`projects.yaml` `deployment.name`) and is served
|
|
# at runtime by GET /api/deployment. VITE_APP_NAME has been removed — set the
|
|
# name in your registry repo instead, and the same build serves any deployment.
|
|
|
|
# Optional contact line shown on the /beta-pending page when a deployment
|
|
# is in private-beta mode (i.e. the backend's `allowed_emails` table has
|
|
# rows). Free-text — an email address, a URL, or a one-line instruction
|
|
# tells visitors how to request an invitation. If unset, the page falls
|
|
# back to a generic "contact the deployment operator" line.
|
|
#
|
|
# Examples:
|
|
# VITE_BETA_CONTACT=ben@wiggleverse.org
|
|
# VITE_BETA_CONTACT=DM @ben on Matrix
|
|
VITE_BETA_CONTACT=
|
|
|
|
# Optional URL to the deployment's privacy policy (v0.13.0+, SPEC §14.5).
|
|
# The framework ships a minimal default privacy policy at `/privacy`
|
|
# that describes the framework's stance and lists the cookies the
|
|
# framework sets. When this var is set to an http(s) URL, the page
|
|
# renders the framework's stub above a link to the configured URL —
|
|
# deployments use this to layer their own policy content on top
|
|
# without forking the framework. Unset is OK; the stub is sufficient
|
|
# for a deployment that has nothing specific to add.
|
|
#
|
|
# Examples:
|
|
# VITE_PRIVACY_POLICY_URL=https://wiggleverse.org/privacy
|
|
VITE_PRIVACY_POLICY_URL=
|
|
|
|
# Optional URL to the deployment's cookies policy (v0.13.0+, SPEC §14.6).
|
|
# Same shape as VITE_PRIVACY_POLICY_URL. The framework's default
|
|
# `/cookies` page lists exactly which cookies the framework sets
|
|
# (rfc_session, the consent-choice localStorage entry); a deployment
|
|
# that adds its own cookies (analytics SDK once #13 lands, third-party
|
|
# embeds) points this var at a page that documents the full list.
|
|
# Unset is OK; the stub is sufficient for a default-config deployment.
|
|
#
|
|
# Examples:
|
|
# VITE_COOKIES_POLICY_URL=https://wiggleverse.org/cookies
|
|
VITE_COOKIES_POLICY_URL=
|
|
|
|
# v0.12.0 / roadmap item #10: CloudFlare Turnstile site key (public).
|
|
# Provision a Turnstile site at dash.cloudflare.com → Turnstile → Add
|
|
# site. The site key (this var) is embedded into the frontend bundle at
|
|
# build time and rendered by the Turnstile widget on the /login email-
|
|
# entry step. The secret key (private) lives in the backend env as
|
|
# CLOUDFLARE_TURNSTILE_SECRET — see backend/.env.example. Leave unset
|
|
# in dev to skip the widget; the backend's TURNSTILE_REQUIRED policy
|
|
# decides what happens to a tokenless request.
|
|
#
|
|
# Examples:
|
|
# VITE_TURNSTILE_SITE_KEY=0x4AAAAAAA...
|
|
VITE_TURNSTILE_SITE_KEY=
|
|
|
|
# v0.15.0 / roadmap item #13: Amplitude project API key (public).
|
|
# Embedded in the frontend bundle at build time and used by the
|
|
# analytics wrapper (`frontend/src/lib/analytics.js`) — which loads
|
|
# `@amplitude/unified` (Analytics + Session Replay) when the user
|
|
# has granted analytics consent (v0.13.0 cookie banner). Provision
|
|
# an Amplitude project at app.amplitude.com → Projects → New, copy
|
|
# the API key.
|
|
#
|
|
# Public by design: Amplitude browser keys are bundle-embedded
|
|
# (visible in dev tools), same nature as VITE_TURNSTILE_SITE_KEY
|
|
# (also public; the truly-secret half of that Turnstile pair is
|
|
# CLOUDFLARE_TURNSTILE_SECRET on the backend). For deployments
|
|
# behind flotilla, bind via `flotilla overlay set <deployment>
|
|
# VITE_AMPLITUDE_API_KEY=<key>` — NOT `flotilla secret set`. The
|
|
# vendor's installation wizard shows the key inline as a literal
|
|
# string in the init call, confirming the public framing. Leave
|
|
# unset in dev; the wrapper logs one console warning and no-ops
|
|
# (the app continues to work).
|
|
#
|
|
# Examples:
|
|
# VITE_AMPLITUDE_API_KEY=01234567890abcdef01234567890abcd
|
|
VITE_AMPLITUDE_API_KEY=
|