Record VPS-local website staging proof
This commit is contained in:
axiomlogicnexus
parent
24e780e018
commit
3da1fabbcd
6 changed files with 77 additions and 2 deletions
|
|
@ -366,6 +366,13 @@ 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.
|
||||
|
||||
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
|
||||
`/health`, green `/api/auth/health`, anonymous `/api/releases/manifest`, and
|
||||
the first-party website shell on the real shared host behind `3011`, so the
|
||||
remaining work is root-owned cutover and production-value application rather
|
||||
than repository-side website behavior.
|
||||
|
||||
## Explicit non-claims
|
||||
|
||||
This packet does not claim any of the following:
|
||||
|
|
|
|||
|
|
@ -153,6 +153,11 @@ 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.
|
||||
|
||||
The same host-state conclusion is now strengthened by an isolated VPS-local
|
||||
staging proof on `3011` that successfully served `/health`, `/api/auth/health`,
|
||||
`/api/releases/manifest`, and the first-party root shell from a temporary
|
||||
HyperTwist checkout on the real shared host.
|
||||
|
||||
## Related authorities
|
||||
|
||||
- `website/README.md`
|
||||
|
|
|
|||
|
|
@ -233,6 +233,12 @@ As of the latest repo-side proof on `2026-06-22`, those live checks still
|
|||
returned the placeholder rollout page, so the rendered bundle is ready but the
|
||||
public-host cutover has not yet been applied.
|
||||
|
||||
That remaining cutover gap is now narrower than before: an isolated VPS-local
|
||||
staging proof on the same host succeeded on `3011` for `/health`,
|
||||
`/api/auth/health`, `/api/releases/manifest`, and the first-party shell marker,
|
||||
so the remaining work is root-owned enablement and vhost replacement rather
|
||||
than unresolved repo-side runtime behavior.
|
||||
|
||||
### 7. Run the first-party readiness verifier
|
||||
|
||||
From the live checkout:
|
||||
|
|
|
|||
|
|
@ -70,6 +70,60 @@ Before the real cutover can happen, the host still needs:
|
|||
reverse-proxy the HyperTwist website/auth-server process
|
||||
- root-owned service enablement and NGINX reload
|
||||
|
||||
## Addendum - isolated VPS-local staging proof on `2026-06-22`
|
||||
|
||||
A follow-up isolated-host proof was then executed from a temporary checkout on
|
||||
the same VPS:
|
||||
|
||||
- staged path:
|
||||
- `/tmp/hypertwist-website-staging-24e780e`
|
||||
- source shape:
|
||||
- current committed `website/` tree from `24e780e`
|
||||
- rendered env posture:
|
||||
- manifest-driven same-origin bundle
|
||||
- `publicOrigin=https://hypertwist.app`
|
||||
- `PORT=3011`
|
||||
- build/start flow:
|
||||
- `npm ci` in `website/`
|
||||
- `npm --prefix server ci`
|
||||
- `npm run build`
|
||||
- `npm --prefix server start`
|
||||
|
||||
Observed proof results:
|
||||
|
||||
- `GET http://127.0.0.1:3011/health`
|
||||
- returned `{\"ok\":true,\"service\":\"hypertwist-auth-server\"}`
|
||||
- `GET http://127.0.0.1:3011/api/auth/health`
|
||||
- returned `ok: true`
|
||||
- `supertokens.reachable: true`
|
||||
- `supertokens.ready: true`
|
||||
- `runtime.public_origin_ready: true`
|
||||
- `runtime.mode: mixed`
|
||||
- only runtime warning:
|
||||
`SUPERTOKENS_CORE_URI still targets a loopback/local-development host.`
|
||||
- `GET http://127.0.0.1:3011/api/releases/manifest`
|
||||
- returned the expected anonymous release-manifest JSON
|
||||
- Windows metadata was populated
|
||||
- raw download URL remained hidden from the anonymous viewer
|
||||
- `GET http://127.0.0.1:3011/`
|
||||
- included the first-party shell marker
|
||||
`hypertwist-site-shell`
|
||||
- included the expected `#root` mount
|
||||
|
||||
Cleanup result:
|
||||
|
||||
- the temporary `3011` listener was removed after the proof
|
||||
- the temporary `/tmp/hypertwist-website-staging-24e780e` tree was deleted
|
||||
|
||||
Operational reading:
|
||||
|
||||
- the repo-side same-origin website/auth-server lane is now proved on the real
|
||||
shared VPS behind the new host-safe `3011` port
|
||||
- the remaining gap is the root-owned live cutover from static
|
||||
`/var/www/hypertwist` NGINX serving into the long-lived HyperTwist
|
||||
website/auth-server process plus real production values, not another missing
|
||||
repository-side deployment behavior
|
||||
|
||||
## Related authorities
|
||||
|
||||
- `docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.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. |
|
||||
| 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. An isolated VPS-local staging proof then also confirmed that the committed HyperTwist website lane can serve green health, release-manifest, and first-party shell responses on that real shared host behind `3011`, so the remaining gap is root-owned live cutover rather than missing repo-side website behavior. |
|
||||
| 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. |
|
||||
|
|
|
|||
|
|
@ -271,7 +271,10 @@ Current consolidated milestone snapshot:
|
|||
the public origin and emit validated frontend env, server env, `systemd`,
|
||||
and `nginx` outputs together before live-host installation, with the shared
|
||||
VPS default now moved to `3011` after live host inspection confirmed that
|
||||
FamiliarOS already occupies `3001`,
|
||||
FamiliarOS already occupies `3001`, and an isolated VPS-local staging proof
|
||||
then confirmed the current committed HyperTwist `website/` lane can serve
|
||||
green health, release-manifest, and first-party shell responses on that real
|
||||
shared host behind `3011`,
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue