Validate website lane in bootstrap CI

.woodpecker/hypertwist-bootstrap.yml

@@ -28,3 +28,32 @@ steps:
       - Get-ChildItem 'UnrealHyperTwist/Source/UnrealHyperTwist/Public' -Recurse | Select-Object -First 20 FullName
     when:
       - event: [push, pull_request, manual, tag]
+
+  website_frontend_validation:
+    image: powershell
+    depends_on:
+      - repo_sanity
+    commands:
+      - Set-Location repo/website
+      - node --version
+      - npm --version
+      - npm ci
+      - npm run type-check
+      - npm test
+      - npm run build
+    when:
+      - event: [push, pull_request, manual, tag]
+
+  website_auth_validation:
+    image: powershell
+    depends_on:
+      - repo_sanity
+    commands:
+      - Set-Location repo/website/server
+      - node --version
+      - npm --version
+      - npm ci
+      - npm run type-check
+      - npm test
+    when:
+      - event: [push, pull_request, manual, tag]

docs/ops/HYPERTWIST_PUBLIC_WEBSITE_AUTH_BILLING_AND_DISTRIBUTION_PACKET_2026-06-22.md

@@ -143,6 +143,11 @@ Those production-shaped templates intentionally keep `replace-me` placeholders,
 and the readiness command now fails on those placeholder strings so copied
 templates cannot be mistaken for real launch config.
 
+The repo bootstrap CI now also validates the website lane directly through:
+
+- `website` frontend install, type-check, test, and build
+- `website/server` install, type-check, and test
+
 This is browser-based user access for the operator/account surface.
 
 It is **not** a claim that the simulator itself is now browser-owned.

docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md

@@ -263,7 +263,7 @@ repo.
 
 | Feature | Status | Primary authority | Notes |
 |---|---|---|---|
-| Public `hypertwist.app` marketing shell | Implemented now | first-party `website/` app + feature registry/roadmap authority | HyperTwist now has a dedicated first-party public web surface for homepage, about, resources, pricing, download, support, and legal routes. This lane is separate from the embedded Unreal browser runtime under `Content/Browser/` and does not claim browser-simulator parity. The same package now also carries a first-party external runtime-readiness verifier so deploy-time env and live health posture can be checked outside the dashboard, plus separated local-versus-production env templates whose placeholder values are intentionally rejected until real launch config is in place. |
+| Public `hypertwist.app` marketing shell | Implemented now | first-party `website/` app + feature registry/roadmap authority | HyperTwist now has a dedicated first-party public web surface for homepage, about, resources, pricing, download, support, and legal routes. This lane is separate from the embedded Unreal browser runtime under `Content/Browser/` and does not claim browser-simulator parity. The same package now also carries a first-party external runtime-readiness verifier so deploy-time env and live health posture can be checked outside the dashboard, plus separated local-versus-production env templates whose placeholder values are intentionally rejected until real launch config is in place, and bootstrap CI now validates both the frontend and auth-server website commands directly. |
 | Browser-based operator/account dashboard | Implemented now | first-party `website/` app + shared auth/dashboard packet | A protected browser dashboard is now live for operator access, account state, download posture, browser-access boundary explanation, notices review, and bounded billing/entitlement status. It reuses the shared SuperTokens auth posture proven in FamiliarOS and ScriptoriumAI while remaining HyperTwist-specific in product content and boundary claims, the current auth-health surface now truthfully distinguishes configured versus reachable or ready shared-core posture while exposing fallback-active reason instead of hardcoding readiness, and the same dashboard now also surfaces launch-readiness truth for download URLs, checkout links, source/notices URLs, billing-secret/map configuration, and local-versus-public runtime deployment posture. |
 | Desktop download posture and browser-to-desktop pairing | Implemented now | first-party `website/` app + `website/server` desktop-link endpoints | Public download targets, dashboard-side release posture, and short-lived desktop-link token generation/verification are now first-party owned. The current server posture now enforces exact website-origin matching, bounded per-user issuance, one-time token consumption, and billing-backed plan/download entitlement resolution with focused `website/server` tests green on `2026-06-22`, and the verify handshake now returns the same resolved download-entitlement posture the dashboard sees instead of only identity plus plan/role. The public `/download` page now keeps raw download URLs behind the protected dashboard instead of exposing them directly. Actual release URLs remain deployment configuration rather than hardcoded product truth. |
 | Paddle-ready pricing and billing webhook seam | Implemented now | first-party `website/` app + `website/server` billing endpoint | The public pricing surface now exists with plan structure, checkout-link configuration seams, and the same `/api/billing/paddle/webhook` endpoint family used by the broader product website lane. The current server now verifies `Paddle-Signature` against `PADDLE_WEBHOOK_SECRET` using the documented raw-body HMAC flow, persists a bounded first-party billing state file, and applies verified Paddle events into account/download entitlement state that the browser dashboard consumes, with focused `website/server` tests green on `2026-06-22`. Production checkout URLs, secret management, and broader operator/admin billing workflows remain deployment/application tasks, not shipped-code omissions. |

docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md

@@ -217,7 +217,8 @@ Current consolidated milestone snapshot:
   a first-party external runtime-readiness verifier for env plus live
   `/api/auth/health` posture before public launch, along with separate local
   versus production example env families whose `replace-me` scaffolding is now
-  explicitly rejected by that verifier,
+  explicitly rejected by that verifier, and the bootstrap CI lane now also runs
+  the website/frontend plus website/server validation commands directly,
   persists a bounded first-party billing-state file, applies verified Paddle
   events into account/download entitlement state, and surfaces that resolved
   billing/download posture back through `/api/auth/me`, the protected browser

website/README.md

@@ -81,3 +81,8 @@ Use the runtime-readiness command before public launch or deployment approval:
 
 - it fails if required public launch values are still missing
 - it can optionally verify live `/api/auth/health` posture from the deployed site
+
+The repo bootstrap CI now also validates this lane through:
+
+- frontend `npm ci`, `npm run type-check`, `npm test`, and `npm run build`
+- auth-server `npm ci`, `npm run type-check`, and `npm test`

website/server/README.md

@@ -88,3 +88,9 @@ Keep the example env files separated by posture:
 
 - `website/.env.example` and `website/server/.env.example` remain local-development defaults
 - `website/.env.production.example` and `website/server/.env.production.example` are public-posture scaffolds that still intentionally fail readiness until placeholder values are replaced
+
+The repo bootstrap CI now also validates this auth-server lane through:
+
+- `npm ci`
+- `npm run type-check`
+- `npm test`