From e16e311ec04bf8fae953d8a190053880336e1a8d Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Mon, 22 Jun 2026 07:58:55 +0000 Subject: [PATCH] Document live hypertwist.app preview cutover --- ...LING_AND_DISTRIBUTION_PACKET_2026-06-22.md | 31 +++++++++++-------- ..._RUNTIME_CONFIGURATION_GUIDE_2026-06-22.md | 28 ++++++++++------- ...ME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md | 15 +++++++++ ...TE_VPS_PRECUTOVER_HOST_STATE_2026-06-22.md | 23 ++++++++++++++ .../HyperTwist/FEATURE_REGISTRY.md | 2 +- .../HyperTwist/ROADMAP.md | 5 ++- website/README.md | 7 +++++ website/server/README.md | 9 ++++++ 8 files changed, 93 insertions(+), 27 deletions(-) diff --git a/docs/ops/HYPERTWIST_PUBLIC_WEBSITE_AUTH_BILLING_AND_DISTRIBUTION_PACKET_2026-06-22.md b/docs/ops/HYPERTWIST_PUBLIC_WEBSITE_AUTH_BILLING_AND_DISTRIBUTION_PACKET_2026-06-22.md index 4c8ca88..3527eee 100644 --- a/docs/ops/HYPERTWIST_PUBLIC_WEBSITE_AUTH_BILLING_AND_DISTRIBUTION_PACKET_2026-06-22.md +++ b/docs/ops/HYPERTWIST_PUBLIC_WEBSITE_AUTH_BILLING_AND_DISTRIBUTION_PACKET_2026-06-22.md @@ -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 diff --git a/docs/ops/HYPERTWIST_WEBSITE_RUNTIME_CONFIGURATION_GUIDE_2026-06-22.md b/docs/ops/HYPERTWIST_WEBSITE_RUNTIME_CONFIGURATION_GUIDE_2026-06-22.md index a41af51..cdb61df 100644 --- a/docs/ops/HYPERTWIST_WEBSITE_RUNTIME_CONFIGURATION_GUIDE_2026-06-22.md +++ b/docs/ops/HYPERTWIST_WEBSITE_RUNTIME_CONFIGURATION_GUIDE_2026-06-22.md @@ -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`, diff --git a/docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md b/docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md index 88b6729..4b89dee 100644 --- a/docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md +++ b/docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md @@ -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: diff --git a/docs/ops/HYPERTWIST_WEBSITE_VPS_PRECUTOVER_HOST_STATE_2026-06-22.md b/docs/ops/HYPERTWIST_WEBSITE_VPS_PRECUTOVER_HOST_STATE_2026-06-22.md index 9fa6e94..2fc4782 100644 --- a/docs/ops/HYPERTWIST_WEBSITE_VPS_PRECUTOVER_HOST_STATE_2026-06-22.md +++ b/docs/ops/HYPERTWIST_WEBSITE_VPS_PRECUTOVER_HOST_STATE_2026-06-22.md @@ -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` diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md b/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md index 7537efa..838116f 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md +++ b/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, 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. | diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md index ff26296..a98ab99 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md @@ -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 diff --git a/website/README.md b/website/README.md index b5234a1..e8a48a6 100644 --- a/website/README.md +++ b/website/README.md @@ -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` diff --git a/website/server/README.md b/website/server/README.md index 26b8827..db285c4 100644 --- a/website/server/README.md +++ b/website/server/README.md @@ -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`