Document live hypertwist.app preview cutover

This commit is contained in:
axiomlogicnexus 2026-06-22 07:58:55 +00:00
parent 3e5cd793c3
commit e16e311ec0
8 changed files with 93 additions and 27 deletions

View file

@ -351,20 +351,25 @@ Validation result on `2026-06-22`:
Current live-origin evidence on `2026-06-22`:
- `https://hypertwist.app/` still served the earlier placeholder rollout page
- `https://hypertwist.app/api/auth/health` returned that same placeholder HTML
instead of live auth-health JSON
- `https://hypertwist.app/api/releases/manifest` returned that same
placeholder HTML instead of the public release-manifest JSON route
- shared-VPS inspection also confirmed that the current host has no
`/srv/hypertwist/current` checkout yet, no `hypertwist-website-auth-server`
service installed, and an existing FamiliarOS auth process already occupying
`*:3001`, so the HyperTwist same-origin deployment defaults now use `3011`
instead
- shared-VPS inspection already confirmed that FamiliarOS occupies `*:3001`, so
the HyperTwist same-origin deployment defaults use `3011`
- the root-owned same-origin cutover is now live on `https://hypertwist.app`
with `/srv/hypertwist/current`, `hypertwist-website-auth-server.service`, and
NGINX proxying into `127.0.0.1:3011`
- `https://hypertwist.app/health` now returns
`{"ok":true,"service":"hypertwist-auth-server"}`
- `https://hypertwist.app/api/auth/health` now returns `ok: true`,
`runtime.mode: mixed`, `public_origin_ready: true`, and
`webhookSecretConfigured: false`
- `https://hypertwist.app/api/releases/manifest` now returns the live public
preview-tier JSON with anonymous viewers denied raw download URLs
- the rendered preview-tier env pair now passes the real runtime-readiness CLI
against `https://hypertwist.app`
That means the remaining gap above this packet is live deployment cutover and
runtime configuration on the public host, not another missing first-party
website/product-surface code family.
That means the remaining gap above this packet is launch-tier
checkout/download/webhook completion and final release-value application, not
another missing first-party website/product-surface code family or a missing
live deployment cutover.
An additional isolated VPS-local staging proof on `2026-06-22` then confirmed
that the current committed HyperTwist `website/` lane can build and serve green

View file

@ -170,21 +170,25 @@ checked-in production example files.
Current live evidence on `2026-06-22`:
- `https://hypertwist.app/` still served the older placeholder rollout page
- `https://hypertwist.app/api/auth/health` returned that same HTML page instead
of the real auth-health JSON route
- `https://hypertwist.app/api/releases/manifest` returned that same HTML page
instead of the public release-manifest JSON route
- the same failure still reproduced when the readiness command was rerun
against env files emitted by the manifest-driven bundle renderer, so the
remaining gap is live host cutover rather than repo-side deployment bundle
ownership
- the shared VPS also already had FamiliarOS bound to `*:3001`, so the
HyperTwist same-origin lane now defaults to `3011` for host-safe deployment
- the root-owned same-origin cutover is now live on `https://hypertwist.app`
instead of the earlier placeholder rollout page
- `https://hypertwist.app/health` now returns
`{"ok":true,"service":"hypertwist-auth-server"}`
- `https://hypertwist.app/api/auth/health` now returns `ok: true`,
`runtime.mode: mixed`, `public_origin_ready: true`, and
`webhookSecretConfigured: false`
- `https://hypertwist.app/api/releases/manifest` now returns the public
preview-tier JSON with no anonymous raw download URLs and all platforms still
`configured=false`
- the rendered preview-tier env pair now passes
`npm run check:runtime-readiness -- --health-url https://hypertwist.app --deployment-tier preview`
against the live origin
This means the remaining public-launch gap is current deployment cutover and
runtime configuration on the live host, not missing first-party website or
auth-server ownership in the repo.
This means the remaining public-launch gap is launch-tier checkout/download/
webhook completion and related release-value application, not missing
first-party website/auth-server ownership or live host cutover.
The same host-state conclusion is now strengthened by an isolated VPS-local
staging proof on `3011` that successfully served `/health`, `/api/auth/health`,

View file

@ -181,6 +181,21 @@ Latest proof result on `2026-06-22`:
configured download or webhook-secret release lane yet
- left no retained temp checkout afterward
Live cutover result on `2026-06-22`:
- the committed HyperTwist `website/` tree is now installed at
`/srv/hypertwist/current`
- service user `hypertwist` now owns the live checkout and auth-state path
- `hypertwist-website-auth-server.service` is active and NGINX now proxies
`https://hypertwist.app` to `127.0.0.1:3011`
- live `GET /health`, `GET /api/auth/health`,
`GET /api/releases/manifest`, and root-shell verification are green on the
public origin
- the rendered preview-tier env pair now passes the real runtime-readiness CLI
against `https://hypertwist.app`
- the remaining gap is launch-tier value completion, not root-owned website
host cutover
### 4. Install the systemd service
Preferred validated bundle-generation path:

View file

@ -159,6 +159,29 @@ Operational reading from that second proof:
- the bundle/readiness helpers now align with the live website behavior that
already truthfully distinguishes preview posture from launch-ready posture
Final live cutover on `2026-06-22`:
- the committed HyperTwist `website/` tree is now installed at
`/srv/hypertwist/current`
- service user `hypertwist` and
`hypertwist-website-auth-server.service` are now live on the host
- `/etc/nginx/sites-available/hypertwist-app.conf` now proxies the public
origin to `127.0.0.1:3011` instead of serving `root /var/www/hypertwist`
- `https://hypertwist.app/health` returns
`{"ok":true,"service":"hypertwist-auth-server"}`
- `https://hypertwist.app/api/auth/health` returns `ok: true`,
`runtime.mode: mixed`, `public_origin_ready: true`, and the expected
preview-tier billing/runtime warnings
- `https://hypertwist.app/api/releases/manifest` returns the first-party public
preview manifest with anonymous download URLs withheld
Updated operational reading:
- the earlier host-state blocker has been cleared; the live origin no longer
serves the placeholder rollout page
- the remaining live work is launch-tier release, checkout, and webhook
completion rather than same-origin host cutover itself
## Related authorities
- `docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md`

View file

@ -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, bootstrap CI now validates both the frontend and auth-server website commands directly, and the auth server can now auto-serve the built `website/dist` bundle with bounded SPA fallback for same-origin public deployment. Request-level server coverage now also proves that public/app shell delivery does not shadow `/api/*`, `/auth*`, `/health`, or missing asset paths, while the pricing/download/notices routes now surface first-party preview-versus-launch posture from the same bounded launch checklist instead of relying on hidden operator-only status. The live website lane now also owns route-aware title/description/canonical/Open-Graph/Twitter metadata for the real `hypertwist.app` marketing surface so deployed public pages no longer remain on a single generic SPA title/description, plus first-party `robots.txt` and `sitemap.xml` assets for the public route set while keeping `/app`, `/login`, and `/register` out of crawler posture. The real `check-runtime-readiness` CLI is now also exercised against the checked-in production example env files, and a spawned `website/server` bootstrap proof now verifies the live same-origin process path from production-shaped env into `/health`, `/api/auth/health`, built-shell serving, and the public anonymous release-manifest posture for the shared desktop release lane. The same verifier now also probes the deployed root-shell marker and can explicitly fail when the public origin is still serving the older placeholder rollout page instead of the first-party website/auth-server lane, while the repo now also carries first-party `website/deploy/` `nginx` plus `systemd` handoff templates, a concrete same-origin public-host cutover guide, a deployment-file renderer that emits resolved operator outputs from real checkout paths, and a manifest-driven bundle renderer that lets one authoritative input own the public origin while emitting validated env plus install artifacts together, with the shared-VPS-safe default upstream moved to `3011` after live host inspection confirmed `3001` is already occupied by FamiliarOS. The same deployment lane now also distinguishes `launch` from `preview` posture so honest missing checkout/download/webhook/release values are accepted only for non-public rehearsal while placeholder strings still fail, `runtime.mode: mixed` plus `public_origin_ready: true` counts as valid preview-host proof, and the staging helper can archive either committed `HEAD` or the live worktree through `--archive-source worktree`. An isolated VPS-local staging proof then also confirmed that both the committed HyperTwist website lane and the later preview-tier worktree packet can serve green health, release-manifest, and first-party shell responses on that real shared host behind `3011`, and the repo now also ships that host-proof flow as a first-party staging helper so future sessions can rerun the temp checkout/build/boot verification path directly before root-owned cutover. |
| 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, bootstrap CI now validates both the frontend and auth-server website commands directly, and the auth server can now auto-serve the built `website/dist` bundle with bounded SPA fallback for same-origin public deployment. Request-level server coverage now also proves that public/app shell delivery does not shadow `/api/*`, `/auth*`, `/health`, or missing asset paths, while the pricing/download/notices routes now surface first-party preview-versus-launch posture from the same bounded launch checklist instead of relying on hidden operator-only status. The live website lane now also owns route-aware title/description/canonical/Open-Graph/Twitter metadata for the real `hypertwist.app` marketing surface so deployed public pages no longer remain on a single generic SPA title/description, plus first-party `robots.txt` and `sitemap.xml` assets for the public route set while keeping `/app`, `/login`, and `/register` out of crawler posture. The real `check-runtime-readiness` CLI is now also exercised against the checked-in production example env files, and a spawned `website/server` bootstrap proof now verifies the live same-origin process path from production-shaped env into `/health`, `/api/auth/health`, built-shell serving, and the public anonymous release-manifest posture for the shared desktop release lane. The same verifier now also probes the deployed root-shell marker and can explicitly fail when the public origin is still serving the older placeholder rollout page instead of the first-party website/auth-server lane, while the repo now also carries first-party `website/deploy/` `nginx` plus `systemd` handoff templates, a concrete same-origin public-host cutover guide, a deployment-file renderer that emits resolved operator outputs from real checkout paths, and a manifest-driven bundle renderer that lets one authoritative input own the public origin while emitting validated env plus install artifacts together, with the shared-VPS-safe default upstream moved to `3011` after live host inspection confirmed `3001` is already occupied by FamiliarOS. The same deployment lane now also distinguishes `launch` from `preview` posture so honest missing checkout/download/webhook/release values are accepted only for non-public rehearsal while placeholder strings still fail, `runtime.mode: mixed` plus `public_origin_ready: true` counts as valid preview-host proof, and the staging helper can archive either committed `HEAD` or the live worktree through `--archive-source worktree`. An isolated VPS-local staging proof then confirmed that both the committed HyperTwist website lane and the later preview-tier worktree packet can serve green health, release-manifest, and first-party shell responses on that real shared host behind `3011`, and a later root-owned cutover then replaced the public placeholder site with the live first-party same-origin preview deployment on `https://hypertwist.app`. The repo now also ships that host-proof flow as a first-party staging helper so future sessions can rerun the temp checkout/build/boot verification path directly before or after root-owned cutover. |
| 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. Focused frontend coverage now also protects deep-link login redirect preservation, safe `next`-path normalization across auth entry points, fallback/email auth-bootstrap normalization, login/register continuation behavior, public download-gating behavior, protected-route/shell behavior, real lazy-route tree behavior for key public and protected paths, top-level app-bootstrap and SuperTokens-wrapper posture, login/register unhappy-path and OAuth-button behavior, support-topic fallback routing when live checkout is not configured, desktop-link verify-url/dashboard readiness behavior, and explicit `noindex,nofollow` posture on protected/auth browser surfaces. The validation lane now also has a bounded signed test-session harness under `TEST_MODE=testing` that proves `/api/auth/me` and `/api/auth/desktop-link` behavior through the live spawned auth-server process without widening production auth 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 same lane now also owns a shared `GET /api/releases/manifest` runtime authority for release version/channel/build/published/file-size/checksum/docs/source metadata, with anonymous callers intentionally denied raw download URLs while entitled session-backed callers receive the configured direct platform URL. The public `/download` page now keeps raw download URLs behind the protected dashboard instead of exposing them directly, preserves requested platform continuity through `/app/downloads?platform=...`, and surfaces that requested target again after auth handoff inside the protected release lane. Both the public and protected download surfaces now also carry first-party rollout steps plus release/notices/source references so the desktop setup lane is more than a generic link bucket, and the dashboard plus public launch-status callouts now consume the same manifest-backed Windows download truth instead of only static frontend config. 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`. A spawned live-process proof now also verifies that a real signed webhook updates processed-event health and persisted billing state through the actual auth-server runtime, not only helper-level store tests, and transaction events no longer leak their id into stored `subscriptionId` state. Production checkout URLs, secret management, and broader operator/admin billing workflows remain deployment/application tasks, not shipped-code omissions. |

View file

@ -282,7 +282,10 @@ Current consolidated milestone snapshot:
accepted only for non-public preview rehearsal, `runtime.mode: mixed` with
public-origin readiness is treated as valid preview-host proof, and
`--archive-source worktree` can prove the exact in-progress packet on the
host before commit,
host before commit, and a later root-owned cutover then replaced the old
`/var/www/hypertwist` placeholder site with the live first-party same-origin
preview deployment on `https://hypertwist.app` while launch-tier commercial
and release values remain intentionally pending,
and the live public website lane now also owns route-aware
title/description/canonical/Open-Graph/Twitter metadata for the real
`hypertwist.app` marketing surface while marking protected/auth routes as

View file

@ -165,6 +165,13 @@ Use the runtime-readiness command before public launch or deployment approval:
- the public pricing/download/notices pages now also surface preview-versus-launch posture directly from the same bounded launch checklist
- the real `check-runtime-readiness` CLI is now also exercised against the checked-in `.env.production.example` files so placeholder launch scaffolds cannot silently drift away from the documented command
Live site status on `2026-06-22`:
- `https://hypertwist.app` now serves the first-party same-origin preview lane
instead of the older placeholder rollout page
- live `/health`, `/api/auth/health`, `/api/releases/manifest`, and root-shell
verification are green on that public origin
The repo bootstrap CI now also validates this lane through:
- frontend `npm ci`, `npm run type-check`, `npm test`, and `npm run build`

View file

@ -168,6 +168,15 @@ That means the verifier can now fail explicitly when `hypertwist.app` is still
serving the earlier placeholder rollout page instead of the real same-origin
website/auth-server deployment.
Live same-origin status on `2026-06-22`:
- the root-owned cutover now has `https://hypertwist.app` serving the
first-party website/auth-server lane from the shared VPS
- live `/health`, `/api/auth/health`, `/api/releases/manifest`, and root-shell
verification are green in preview posture
- the remaining live gap is launch-tier checkout/download/webhook completion,
not website-host cutover
Canonical deployment handoff:
- `docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md`