# HyperTwist Public Website Content and Operator Manual Packet

Created on `2026-06-22`.

Updated on `2026-07-03`:

- signup/login must be presented as a working account path, not as a diagnostic
  placeholder surface
- the public homepage, browser guide, pricing, download, help, resources, docs,
  legal, and support pages should describe HyperTwist to users in product terms
  instead of exposing raw preview/fallback/no-go/developer vocabulary
- remaining launch gaps are retained in the roadmap rather than hidden in public
  marketing pages
- public pages explain supported targets and the product model; protected account
  routes own entitled downloads, release notices, account state, desktop-link
  pairing, and billing follow-through
- the web version is valuable but intentionally inferior for simulator execution:
  it handles account, docs, pricing, notices, support, protected handoff, and
  pairing; the downloadable owns real training behavior
- the downloadable should not become a standalone password island or checkout
  surface; it should consume browser-issued account or desktop-link authority
- the public style system now uses the shared Performative UI-backed HyperTwist
  button wrappers, public light/dark mode controls, enlarged brand logo, and the
  HyperTwist-adapted pricing-frame glow treatment

## Purpose

This continuation strengthens the public `hypertwist.app` surface so the site
does more than expose routes and configuration seams. It now carries clearer
product positioning plus a real public-facing operator manual.

## Product-positioning correction

The website and the desktop build are both kept on purpose.

The website is **not** the simulator. It exists because HyperTwist needs:

- public product positioning
- account/auth access
- pricing and checkout posture
- release and package-proof posture
- legal/notices posture
- browser-to-desktop pairing
- support and rollout guidance

The website is intentionally inferior for the core simulator job:

- it does not own the native Unreal runtime
- it does not own packaged higher-dimensional execution
- it does not replace desktop-side device/runtime integration
- it does not claim the optional full-browser simulator branch is live

So the website is not superfluous. It is a complementary operator/distribution
surface around a desktop-first simulator.

## Landed public-manual continuation

The public pages now carry more explicit guidance for:

- what the browser shell does versus what the desktop runtime does
- how a user starts in the browser, signs in, and reaches the protected
  download lane
- how desktop pairing works through the browser-to-desktop token handoff
- how classic-cube, replay, diagnostics, and higher-dimensional truths should
  be understood from public-safe surfaces
- how operators should interpret package proof, release posture, and launch
  readiness

The later same-day continuation also widened the manual from page-shell copy
into a more practical public operator reference:

- the docs page now carries explicit public documentation principles derived
  from feature-registry discipline rather than generic marketing wording
- the docs and resources pages now carry a bounded simulator-use manual for:
  classic-cube recognition/correction, replay/coaching/analytics,
  higher-dimensional 120-cell and 5D runtime ownership, and operator
  diagnostics/release proof
- the widened manual stays public-safe by explaining the real desktop runtime
  instead of claiming the website itself performs the simulator job
- the public legal and delivery pages now also carry the same product truth:
  release notes explain how to read browser/operator versus simulator changes,
  open-source notices explain why public pages are themselves release surfaces,
  privacy and terms now describe the browser-versus-desktop boundary in
  operational language, and shipping/payment now carries the real digital
  delivery workflow instead of generic storefront filler

A later same-family continuity packet then added a dedicated public
`/getting-started` route so the shortest complete operator path no longer has
to be reconstructed from homepage, docs, and download fragments alone. That
route now acts as the canonical public onboarding/manual surface for:

- first-session browser-to-desktop flow
- access and protected download continuity
- first launch and higher-dimensional verification order
- explicit XR/controller boundary truth

The next same-family launch-authority continuation then added a dedicated
public `/launch-status` route so the current preview-versus-launch posture no
longer has to be reconstructed from pricing plus compact public banners alone.
That route now acts as the canonical public authority surface for:

- the current launch-readiness checklist
- rollout hardening tracks
- packaged desktop proof in launch context
- release-reference and support follow-through

## Protected-surface continuation

The protected browser shell is no longer only one strong dashboard route plus
thin adjacent placeholders.

The later continuation also hardened:

- `/app/browser-access` with live auth-health posture, browser-to-desktop
  handoff guidance, bounded branch truth, release-reference links, and the same
  bounded operator escalation map used by the public support lane
- `/app/account` with live release-manifest viewer posture, configured target
  visibility, and explicit operator follow-through links
- `/app/notices` with protected release-target notice posture, operator duties,
  linked protected/public notices plus corresponding-source references, and a
  protected release follow-through plus escalation surface that keeps
  entitlement, package, runtime, and rollout/compliance issues separated
- a later `2026-06-24` follow-up mirrored the same current Windows
  packaged-validation proof from the main dashboard into
  `/app/browser-access`, `/app/account`, and `/app/notices` so pairing,
  entitlement review, and protected distribution/legal follow-through stay tied
  to the real higher-dimensional desktop release evidence instead of only
  mentioning validation abstractly

This keeps the protected app shell aligned with the public manual packet so the
operator surface remains honest and useful after sign-in rather than becoming a
drop in information quality.

## Public pages widened by this packet

- homepage
- about page
- resources page
- docs page
- pricing page
- download page
- getting-started page
- launch-status page
- support page
- changelog page
- open-source notices page
- privacy page
- terms page
- shipping/payment page

## Source of truth used

- `docs/v6_5_deep_manual_pack/HyperTwist/FEATURE_REGISTRY.md`
- `docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md`
- `docs/v6_5_deep_manual_pack/HyperTwist/PRD.md`
- `website/README.md`
- existing `website/server` release-manifest and auth-health posture

## Non-claims kept explicit

This packet does not:

- reopen the optional full-browser simulator branch
- claim full native `MagicTile` renderer-port ownership
- claim the website has surpassed the desktop runtime for the core simulator
- claim unresolved launch-tier checkout/download values are already configured

## Validation

The same-day public-manual continuation passed:

- `npm run type-check` in `website/`
- `npm test -- --run src/__tests__/public-marketing-pages.test.tsx` in
  `website/`
- `npm run build` in `website/`
- `npm test -- --run` in `website/`
- `npm run type-check` in `website/server`
- `npm test -- --run` in `website/server`

The protected-surface continuation also passed:

- `npm test -- --run src/__tests__/protected-app-pages.test.tsx src/__tests__/app-route-tree.test.tsx`
- `npm test -- --run` in `website/` after the protected-route widening

The same validation hardening also gives the live-spawned
`website/server` bootstrap proof an explicit `15s` timeout so real child-process
boot plus same-origin HTTP verification does not fail spuriously on a loaded
host while the proof scope remains unchanged.

Latest same-lane follow-up on `2026-06-23` stayed green under the widened
public/protected/auth stack:

- `npm run type-check` in `website/`
- `npm test -- --run` in `website/`
  - `37` test files passed
  - `137` tests passed
- `npm run build` in `website/`
- `npm run type-check` in `website/server`
- `npm test -- --run` in `website/server`
  - `10` test files passed
  - `36` tests passed
- the current server suite again covered the production-shaped bootstrap lane,
  including:
  - same-origin health plus built-site serving
  - webhook/billing-state reflection
  - bounded testing-session resolution for `/api/auth/me` and
    `/api/auth/desktop-link`
- the embedded browser runtime also stayed green under:
  - `npm run verify:shell` in `Content/Browser/`
  - `npm run build` in `Content/Browser/`
- the same-day public-manual follow-up also widened the docs/resources manual
  depth with a more concrete runtime control guide covering:
  - current classic-cube desktop interaction posture
  - current higher-dimensional desktop interaction posture
  - explicit “supported now” versus “later XR/preferences packet” control
    boundaries
- the same-lane continuation then widened the public product surface again with:
  - a first-launch and desktop-setup guide on the public `/download` lane
    plus matching first-launch follow-through on the protected `/app/downloads`
    lane
  - the same first-launch follow-through mirrored into the protected dashboard
    overview and protected account surface so post-sign-in operator guidance
    stays aligned with the public download lane
  - a support-side escalation map separating account, package, runtime, and
    rollout/compliance issues
  - the same escalation separation then mirrored into protected
    `/app/browser-access` and `/app/notices` so the signed-in operator lane no
    longer drops back to thinner troubleshooting guidance than the public
    support surface
  - matching focused validation coverage on the public marketing-page suite
    plus the protected download-center suite

That follow-up also stayed green under:

- `npm run type-check` in `website/`
- `npm test -- --run src/__tests__/public-marketing-pages.test.tsx` in
  `website/`
- `npm run build` in `website/`
- `npm test -- --run` in `website/`
  - `37` test files passed
  - `137` tests passed
- `npm test -- --run src/__tests__/DashboardOverviewPage.test.tsx src/__tests__/download-center-page.test.tsx src/__tests__/protected-app-pages.test.tsx`
  in `website/`
  - `3` test files passed
  - `5` tests passed

The next same-family protected-surface continuation then stayed green under:

- `npm run type-check` in `website/`
- `npm test -- --run src/__tests__/protected-app-pages.test.tsx` in `website/`
  - `1` test file passed
  - `3` tests passed
- `npm test -- --run` in `website/`
  - `37` test files passed
  - `137` tests passed
- `npm run build` in `website/`
- `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6112`
  - `All rules pass`

Latest protected packaged-proof continuation on `2026-06-24` also stayed green
under:

- `npm --prefix website run type-check`
- `npm --prefix website test -- --run src/__tests__/protected-app-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx`
  - `2` test files passed
  - `9` tests passed
- `npm --prefix website run build`
- `npm --prefix website test -- --run`
  - `41` test files passed
  - `168` tests passed
- `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6190`
  - `All rules pass`

Latest same-family wording and truth-render follow-up on `2026-06-24`:

- the public/manual XR and control-posture copy was tightened so it now states
  the current desktop-hosted `No-Go` on native OpenXR/controller widening
  instead of sounding like a near-term open packet
- the same truth is now rendered directly in the native training and
  coach-dashboard control diagnostics, so public/manual copy and native
  operator-visible detail lines no longer drift apart on the XR boundary
- the current website changelog now records that rendered-truth continuation
  instead of leaving it implicit

That follow-up stayed green under:

- `npm run type-check` in `website/`
- `npm test -- --run src/__tests__/public-marketing-pages.test.tsx` in
  `website/`
- `npm test -- --run src/__tests__/protected-app-pages.test.tsx` in
  `website/`
- `npm run build` in `website/`
- the maintained reverse-SSH Unreal lane also rebuilt
  `C:\HyperTwist_worktrees\phase10validate` with `Result: Succeeded`,
  UnrealBuildTool `Total execution time: 172.52 seconds`, then exported
  `Saved\AutomationReports\Browser-XrNoGoRendered-Verify\index.json` with all
  `20` `HyperTwist.Browser.*` tests passing

Current truthful reading after that follow-up:

- the public pages are no longer just content-complete; they are backed by a
  fully green current website/runtime/server validation pass
- the shared auth/billing/dashboard/browser-to-desktop handoff surface is now
  materially better evidenced than a page-only smoke pass
- the public manual now reads more like a usage guide for the current desktop
  runtime instead of only a topology or release-story explanation
- the download/support surfaces now act more like an operator-first launch
  manual than a generic storefront wrapper around the desktop build
- the protected dashboard/account/download surfaces now project the same
  rollout and first-launch posture after sign-in instead of dropping back to a
  thinner release-only shell
- the protected browser-access/notices surfaces now also keep the same
  escalation and follow-through separation after sign-in instead of flattening
  access, package, runtime, and rollout questions together

Latest protected quick-routes follow-up on `2026-06-24`:

- the protected dashboard overview and protected download center now mirror the
  same three bounded public help lanes:
  - launch readiness
  - operator access
  - studio rollout
- those same topics no longer bounce a signed-in operator back through generic
  auth entry points when the target is already known
- instead, they now open direct protected follow-through routes such as:
  - `/app/downloads?platform=windows`
  - `/app/account`
  - `/app/browser-access`
  - `/app/notices`
  - `/pricing`
  - `/changelog`
- the protected dashboard packaged-proof panel title was also normalized to
  `Current packaged desktop proof` so public and protected release evidence now
  read as one authority rather than two near-duplicate headings

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/DashboardOverviewPage.test.tsx src/__tests__/protected-app-pages.test.tsx`
  - `2` test files passed
  - `10` tests passed
- `./scripts/run-hypertwist-web-surface-validation.sh`
- `./scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6138`
  - `All rules pass`

Latest public-manual clarity follow-up later on `2026-06-24`:

- the homepage, About, Pricing, Download, and Support pages now share a direct
  `Choose the right HyperTwist surface` section
- that guide answers the recurring operator question more plainly than the
  larger surface matrix alone:
  - stay on the public website
  - move into the protected dashboard
  - use the desktop runtime
- each card now also carries a direct next action so the browser-versus-
  desktop split is actionable instead of only descriptive

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` test file passed
  - `12` tests passed

Latest browser-versus-desktop reality follow-up later on `2026-06-24`:

- the homepage, About, Docs, and Download routes now also share a reusable
  direct comparison section answering the more pointed operator question:
  why keep both a website and a desktop runtime at all
- that section now states plainly:
  - what the website is for
  - what the desktop runtime is for
  - why the browser is intentionally narrower
  - what current input/XR/settings truth is actually shipped
- the public FAQ wording also tightened so the browser lane is described as
  deliberately narrower for simulator work, not as a weaker accidental copy of
  the native runtime

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` test file passed
  - `12` tests passed

Latest pricing/resources parity follow-up later on `2026-06-24`:

- the public Pricing and Resources routes now also carry that same direct
  browser-versus-desktop comparison section instead of relying only on the
  lighter shared surface-choice guide
- this keeps:
  - commercial access language on pricing
  - operator-reference language on resources
  aligned with the sharper homepage/About/Docs/Download truth about what the
  website is for, what stays native, why the browser remains intentionally
  narrower, and how the current XR/controller boundary should be read

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - focused Pricing and Resources coverage stayed green

Latest protected-operator parity follow-up later on `2026-06-24`:

- the signed-in dashboard, protected downloads, and browser-access routes now
  also mirror the same browser-versus-desktop reality explanation instead of
  leaving that sharper boundary only on anonymous public pages
- the protected shell now states plainly:
  - what the browser shell is for after sign-in
  - what still stays native even after entitlement is resolved
  - why the browser lane remains intentionally narrower than simulator runtime
  - how the unfinished XR/controller boundary should still be read

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/protected-app-pages.test.tsx src/__tests__/download-center-page.test.tsx src/__tests__/DashboardOverviewPage.test.tsx`
  - `3` test files passed
  - focused protected dashboard/download/browser-access coverage stayed green

Latest protected account/notices parity follow-up later on `2026-06-24`:

- the protected Account and Notices routes now also carry the same compact
  browser-versus-desktop reality panel instead of leaving that sharper truth
  only on dashboard, downloads, and browser-access
- this keeps:
  - entitlement review on account
  - distribution/compliance follow-through on notices
  aligned with the same explicit browser-support versus native-simulator split
  and unfinished XR/controller boundary already shown on the other signed-in
  routes

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/protected-app-pages.test.tsx`
  - focused Account and Notices coverage stayed green

Latest auth-entry parity follow-up later on `2026-06-24`:

- the public Login and Register routes now also render a compact
  browser-versus-desktop reality panel instead of relying only on after-sign-in
  next-step notes plus the later protected dashboard to explain the split
- this keeps:
  - auth-entry account-access language
  - protected follow-through routing
  aligned with the same explicit native-runtime and unfinished
  XR/controller-boundary truth already present across the public manual and the
  signed-in browser shell

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-auth-pages.test.tsx`
  - focused Login and Register coverage stayed green

Latest feature/support parity follow-up later on `2026-06-24`:

- the public Feature atlas and Support routes now also carry the same direct
  browser-versus-desktop reality section instead of relying only on the lighter
  surface-choice guide
- this keeps:
  - capability review on Features
  - recovery/help routing on Support
  aligned with the same explicit website-purpose, native-runtime, and
  unfinished XR/controller-boundary truth already present on the other major
  public operator-facing pages

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - focused Features and Support coverage stayed green

Latest public-surface continuity follow-up later on `2026-06-24`:

- the reusable `Choose the right HyperTwist surface` guide is no longer limited
  to the homepage, About, Pricing, Download, and Support routes
- the same direct browser-versus-protected-versus-desktop handoff guidance now
  also appears on:
  - feature atlas
  - resources
  - docs
  - changelog
  - open-source notices
  - privacy
  - terms
  - shipping/payment
- this keeps lower-traffic but still public-facing manual and legal surfaces
  from falling back to older implicit topology language

That follow-up stayed green under:

- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` test file passed
  - `12` tests passed

Latest authority-sync follow-up later on `2026-06-23`:

- the public manual stayed aligned with the newer native
  control/input-readiness continuation rather than implying finished VR or
  preferences ownership
- focused website/manual coverage stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx src/__tests__/download-center-page.test.tsx src/__tests__/protected-app-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx`
  - `4` test files passed
  - `13` tests passed
- the embedded browser runtime also stayed green again under:
  - `npm --prefix Content/Browser run verify:shell`
  - `npm --prefix Content/Browser run build`
- the current public/docs/download/account/notices surfaces therefore remain
  consistent with the authoritative product truth:
  - desktop simulator is primary
  - browser shell is complementary and necessary
  - keyboard/mouse and higher-dimensional desktop interaction are real now
  - XR groundwork exists, but finished XR/preferences ownership is still a
    later native packet

Latest same-family public-manual follow-up on `2026-06-24`:

- the public and protected manual no longer make readers reconstruct product
  topology from separate card grids alone
- a new shared product-surface authority matrix now keeps five distinct
  surfaces visible across the homepage, feature atlas, public docs, and the
  protected dashboard:
  - public website
  - protected browser dashboard
  - embedded simulator browser shell
  - native Unreal desktop runtime
  - optional full-browser simulator branch

Latest auth-shell hardening follow-up later on `2026-06-24`:

- the same public/protected website lane now also carries the sibling-site
  auth-shell posture more faithfully instead of only reusing auth APIs and
  route pages
- HyperTwist now has its own first-party auth-shell backdrop ownership for:
  - `/login`
  - `/register`
  - `/auth/*`
- that backdrop is now present through both:
  - a runtime route-sync layer inside the React app
  - a first-paint HTML fallback in `website/index.html`
- the `SuperTokensWrapper` posture is now route-aware rather than global:
  - anonymous brochure routes no longer pay for the full auth shell merely
    because auth is configured
  - protected app routes, auth routes, and stored-session continuity still do
- this keeps HyperTwist closer to the intended FamiliarOS/ScriptoriumAI
  structure while remaining truthful to HyperTwist's desktop-first product
  stance
- focused auth/bootstrap validation stayed green under:
  - `npm --prefix website test -- --run src/__tests__/App.bootstrap.test.tsx src/__tests__/auth-shell-backdrop.test.ts src/__tests__/public-auth-pages.test.tsx src/__tests__/route-shells.test.tsx`
  - `4` test files passed
  - `21` tests passed
- the broader owned web-surface umbrella also stayed green again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release suite: `12` files, `62` tests passed
  - website/server suite: `10` files, `36` tests passed
  - website plus `Content/Browser` production audits: `found 0 vulnerabilities`
  - website/server retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual
- current truthful product reading after this follow-up:
  - the public website and protected dashboard still stay complementary to the
    desktop runtime rather than pretending to replace it
  - the shared auth lineage is now not only conceptual but also structural at
    the bootstrap/shell layer
  - the next public/web packets can focus on higher-order product polish or
    deployment truth rather than missing auth-shell parity
- the public `/changelog` lane now also carries an explicit release-rollout
  checklist so release notes remain tied to package proof, protected download
  posture, and notices or corresponding-source follow-through instead of
  acting like isolated chronology
- focused public-page coverage now also proves that the newest
  `June 24, 2026` selector-recall diagnostics entry stays visible on the
  public release-notes page together with that rollout checklist
- the current broader website validation then stayed green again under:
  - `npm --prefix website run type-check`
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
    - `1` test file passed
    - `11` tests passed
  - `npm --prefix website run build`
  - `npm --prefix website test -- --run`
    - `39` test files passed
    - `158` tests passed
- the public manual therefore now also keeps the release-notes lane honest at
  page level instead of only carrying the new selector-recall packet in shared
  data
- that matrix now makes two easy-to-confuse truths materially clearer:
  - the public website and the embedded browser shell are not the same thing
  - the embedded browser shell and the frozen optional full-browser simulator
    branch are not the same thing
- the protected dashboard therefore now carries the same topology/ownership map
  as the public manual instead of relying on operator memory after sign-in
- focused validation for that matrix and protected-dashboard continuation then
  stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx src/__tests__/protected-app-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx src/__tests__/app-route-tree.test.tsx`
  - `4` test files passed
  - `30` tests passed
- the broader current website/runtime/server umbrella then also stayed green
  again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `12` test files passed,
    `61` tests passed
  - `npm --prefix website run build`
  - `npm --prefix website/server run type-check`
  - `npm --prefix website/server test -- --run`
  - `10` website/server test files passed, `36` tests passed
  - `npm --prefix Content/Browser run verify:shell`
  - `npm --prefix Content/Browser run build`
  - website and `Content/Browser` production audits stayed at
    `found 0 vulnerabilities`
  - website/server still retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual

Latest runtime-recovery hardening follow-up later on `2026-06-24`:

- the same public/protected website lane now also owns a first-party top-level
  runtime-recovery surface rather than relying on framework-default crash
  behavior for route/render failures
- `website/src/App.tsx` now wraps `AppRouteTree` in a HyperTwist-owned
  `ErrorBoundary`
- the default recovery card keeps product truth explicit:
  - the browser shell remains the operator and distribution surface
  - the fallback does not imply the native simulator runtime itself failed
  - the operator gets both retry and return-home actions
- focused validation for the new recovery seam stayed green under:
  - `npm --prefix website test -- --run src/__tests__/ErrorBoundary.test.tsx src/__tests__/App.bootstrap.test.tsx src/__tests__/auth-shell-backdrop.test.ts src/__tests__/public-auth-pages.test.tsx src/__tests__/route-shells.test.tsx`
  - `5` test files passed
  - `25` tests passed
- the broader website suite also stayed green under:
  - `npm --prefix website test -- --run`
  - `41` test files passed
  - `168` tests passed
- the owned umbrella and structural gates then also stayed green again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release suite: `12` files, `62` tests passed
  - website/server suite: `10` files, `36` tests passed
  - website plus `Content/Browser` production audits: `found 0 vulnerabilities`
  - website/server retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6189`
  - `All rules pass`

Latest public-manual control-roster follow-up later on `2026-06-24`:

- the public manual no longer only says “keyboard/mouse are real” and
  “finished VR is not”; it now also exposes a more concrete shipped desktop
  roster
- the public `about`, `features`, `resources`, and `docs` pages now all carry
  a first-party selectable control/settings roster covering:
  - the shipped `classic-wca-keyboard/v1` profile
  - the current scenic immersive preset families
  - dedicated `Magic120Cell` and `MagicCube5D` selector/view ownership
  - bounded selector-recall persistence truth
  - the still-unfinished XR/controller-rebinding boundary
- this makes the current manual materially better at answering the operator
  question “what can I actually choose or persist today?” without widening
  public claims into finished VR or generalized preferences ownership
- focused validation for that manual-content continuation stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` test file passed
  - `11` tests passed
- the broader website suite then also stayed green under:
  - `npm --prefix website test -- --run`
  - `41` test files passed
  - `168` tests passed
- the owned umbrella and structural gates then stayed green again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release suite: `12` files, `62` tests passed
  - website/server suite: `10` files, `36` tests passed
  - website plus `Content/Browser` production audits: `found 0 vulnerabilities`
  - website/server retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6189`
  - `All rules pass`

Latest protected control-roster continuation later on `2026-06-24`:

- the same signed-in operator shell now also mirrors the native control and
  settings truth instead of leaving that detail only on the public manual
- `website/src/pages/app-pages.tsx` now projects a shared protected
  control-roster panel into:
  - `/app`
  - `/app/browser-access`
  - `/app/account`
- that continuation keeps the signed-in browser shell honest about the current
  desktop runtime by exposing:
  - the shipped `classic-wca-keyboard/v1` profile
  - the scenic immersive preset families
  - the current `Magic120Cell` and `MagicCube5D` selector/view ownership
  - selector-recall continuity truth
  - the explicit unfinished XR/controller-rebinding boundary
- this closes the information-quality drop that previously happened after
  sign-in, where public pages had more concrete simulator-control truth than
  adjacent protected routes
- focused validation for that protected continuation stayed green under:
  - `npm --prefix website run type-check`
  - `npm --prefix website test -- --run src/__tests__/protected-app-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx`
  - `2` test files passed
  - `9` tests passed
- the broader website suite also stayed green under:
  - `npm --prefix website test -- --run`
  - `41` test files passed
  - `168` tests passed

Latest protected-surface resilience follow-up later on `2026-06-23`:

- the shared release-manifest fallback was tightened so protected browser
  surfaces now retain the signed-in viewer posture from local session truth
  when live auth-server manifest authority is temporarily unavailable
- the protected download-center lane then also stopped relying only on the
  local auth snapshot for the actual download action:
  - when live manifest authority resolves fresher entitled viewer truth, the
    protected release lane now follows that server-backed viewer posture for
    download access instead of leaving the operator blocked behind stale local
    state
  - when live manifest authority is unavailable, the protected release lane
    now explicitly tells the already-entitled operator that release authority
    is temporarily unavailable, instead of mislabeling that state as lack of
    account entitlement
- the shared browser auth layer then also gained a bounded release-authority
  reconciliation path:
  - when protected pages receive fresher live manifest viewer truth, the
    browser session snapshot is now refreshed and persisted from that release
    authority instead of remaining stale until a later bootstrap
  - the adjacent protected dashboard and account surfaces now expose a compact
    live-authority sync notice summarizing what was refreshed, so operators can
    see the session catch-up instead of only inferring drift after the fact
- the same shared auth layer then also tightened stale-session invalidation:
  - when shared auth is configured and `/api/auth/me` now returns `401`, the
    provider clears the stale stored browser session instead of preserving a
    false authenticated protected-shell posture
  - the local-fallback lane remains intact when shared auth is not configured
    or the account API is simply unreachable, so the stricter invalidation does
    not erase the intended offline fallback behavior
- that fallback remains intentionally conservative:
  - raw direct package delivery still stays withheld until live manifest
    authority returns
  - public fallback metadata still does not expose direct download URLs
- focused current validation stayed green under:
  - `npm --prefix website run type-check`
  - `npm --prefix website test -- --run src/__tests__/release-manifest.test.ts src/__tests__/protected-app-pages.test.tsx src/__tests__/download-center-page.test.tsx src/__tests__/public-auth-pages.test.tsx src/__tests__/public-marketing-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx`
  - `7` test files passed
  - `27` tests passed
  - `npm --prefix website/server test -- --run`
  - `10` test files passed
  - `36` tests passed
  - `npm --prefix website test -- --run src/__tests__/platform-auth.bootstrap.test.tsx src/__tests__/download-center-page.test.tsx src/__tests__/protected-app-pages.test.tsx src/__tests__/DashboardOverviewPage.test.tsx src/__tests__/app-route-tree.test.tsx src/__tests__/route-shells.test.tsx src/__tests__/release-manifest.test.ts`
  - `8` test files passed
  - `34` tests passed
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6105`
  - `All rules pass`

Latest website and dependency hardening follow-up later on `2026-06-23`:

- the broader website and delivery lane then also stayed green under:
  - `npm --prefix website run build`
  - `npm --prefix website/server run type-check`
  - `npm --prefix website/server test -- --run`
  - `npm --prefix Content/Browser run verify:shell`
  - `npm --prefix Content/Browser run build`
- the repo now also owns a one-command validation proof for that same public or
  protected or embedded-browser website family:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - it completed successfully in default mode on `2026-06-23`
  - it re-proved the current website checks, auth-server checks,
    `Content/Browser` verify/build lane, clean production audits for
    `website/` plus `Content/Browser/`, and the documented auth-server
    residual warning path
- the same same-family continuation then also tightened the packaged-proof
  bridge used by the public/manual website lane:
  - the website/browser release surfaces no longer depend on a stale
    hand-maintained Windows packaged-validation summary constant
  - the current public/protected release surfaces now consume a sanitized
    generated summary rendered from the checked-in authoritative higher-
    dimensional package report at
    `docs/generated/higher_dimensional_training_maps/phase6c_dedicated_family_package_validation_report.json`
  - the new renderer lives at
    `scripts/render-hypertwist-web-package-validation-summary.mjs`
  - the owned web-surface validation gate now checks that generated summary
    for freshness before approving the public/auth/download/browser lane
- the browser runtime now also has a checked-in `package-lock.json`, so its
  dependency truth is no longer implicit or non-auditable
- production dependency audit truth is now clearer across the current public
  and protected website family:
  - `npm audit --omit=dev --audit-level=high` in `website/` returned
    `found 0 vulnerabilities`
  - `npm audit --omit=dev --audit-level=high` in `Content/Browser/` returned
    `found 0 vulnerabilities`
- the auth server dependency lane was hardened by upgrading
  `supertokens-node` from `21.1.0` to `24.0.2`
- that auth-server upgrade remained type-safe and behavior-safe under the
  existing same-origin, auth-health, release-manifest, billing, and
  desktop-link server tests
- remaining auth-server dependency risk is now explicit:
  - `npm audit --omit=dev --audit-level=high` in `website/server/` still
    reports the upstream `supertokens-node -> nodemailer@8.0.11` advisory
    chain
  - no unsupported forced major override was landed just to hide that result,
    because current upstream package metadata still declares `nodemailer`
    support through the `^8.0.2` range
- the current public manual therefore remains strengthened rather than
  weakened:
  - browser and desktop surfaces are better validated
  - current package and auth-server posture is more explicit
  - unresolved third-party dependency residue is documented honestly instead
    of being silently ignored

Latest shared-release-bundle follow-up on `2026-06-25`:

- the public website now carries a reusable shared release-reference bundle
  across the full operator-facing public route family:
  - homepage
  - about
  - features
  - resources
  - docs
  - support
  - changelog
  - pricing
  - download
  - open-source notices
  - privacy
  - terms
  - shipping/payment
- that shared bundle keeps public docs, release notes, corresponding source,
  public repo/notices reference, and support contact visible together instead
  of requiring operators to reconstruct the release follow-through path from
  scattered footer or page-local fragments
- the same follow-up also removed duplicated public release-manifest
  resolution logic from `PricingPage` and `DownloadPage` by routing both
  through the shared `usePublicReleaseManifestView()` helper already used by
  the rest of the public route family
- focused validation for that continuation stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `12` tests passed
- the broader owned website/runtime/server umbrella then also stayed green
  again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `12` files, `64` tests
    passed
  - `npm --prefix website run build`
  - `npm --prefix website/server run type-check`
  - `npm --prefix website/server test -- --run`
  - `10` website/server files passed, `36` tests passed
  - `npm --prefix Content/Browser run verify:shell`
  - `npm --prefix Content/Browser run build`
  - `website/` and `Content/Browser/` production audits: `found 0
    vulnerabilities`
  - `website/server` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- the HyperTwist-owned structural loop remained clean on the same packet:
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6210`
  - all `7` rules pass
  - `scripts/run-hypertwist-gitnexus-analyze.sh`
  - `16,253` nodes, `38,116` edges, `665` clusters, `300` flows
  - `scripts/run-hypertwist-gitnexus-status.sh`
  - bounded mirror `Status: up-to-date`

Latest onboarding-manual depth follow-up on `2026-06-28`:

- the canonical public `/getting-started` route was widened again so it no
  longer depends on the docs or resources pages alone for the two most
  simulator-specific public manual seams:
  - the same first-session route now includes the current
    higher-dimensional family guide directly, covering the dedicated native
    `Magic120Cell` and `MagicCube5D` lanes plus the current embedded-browser
    `MagicTile` host posture
  - that same route now also includes the public runtime control guide
    directly, including the shipped classic desktop control posture, the
    current higher-dimensional desktop-control truth, the native diagnostics
    check, and the explicit desktop-hosted `No-Go` XR/controller boundary
- this keeps the canonical onboarding page closer to a genuine operator manual
  instead of requiring users to reconstruct the real first-session path from
  scattered public pages
- focused validation for that follow-up stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `15` tests passed
- the same packet also rechecked the owned structural and graph-analysis
  posture so the public-manual widening did not quietly degrade the refactor
  baseline:
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6228`
  - all `7` rules pass
  - `scripts/run-hypertwist-gitnexus-analyze.sh`
  - `16,380` nodes, `38,646` edges, `679` clusters, `300` flows
  - `scripts/run-hypertwist-gitnexus-status.sh`
  - bounded mirror `Status: up-to-date`

Latest feature-atlas parity follow-up on `2026-06-28`:

- the public `/features` route then widened again so the feature atlas no
  longer stops at capability and roster summaries when the rest of the manual
  already carries a more practical desktop-usage seam
- that same atlas now also includes the shared runtime control guide directly,
  including:
  - the shipped classic desktop control posture
  - the current higher-dimensional desktop-control posture
  - the native diagnostics check
  - the explicit desktop-hosted `No-Go` XR/controller boundary
- this keeps the public feature atlas closer to the broader operator/distribution
  manual instead of forcing advanced readers to leave `/features` for docs,
  resources, or getting-started just to find the practical control and
  diagnostics truth
- focused validation for that atlas-parity follow-up stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `15` tests passed
- the broader owned website/runtime/server umbrella then also stayed green
  again under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `12` files, `74` tests
    passed
  - `npm --prefix website run build`
  - `npm --prefix website/server run type-check`
  - `npm --prefix website/server test -- --run`
  - `10` website/server files passed, `36` tests passed
  - `npm --prefix Content/Browser run verify:shell`
  - `npm --prefix Content/Browser run build`
  - `website/` and `Content/Browser/` production audits: `found 0
    vulnerabilities`
  - `website/server` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- the owned structural loop stayed green on the same continuation:
  - `scripts/run-hypertwist-sentrux-source-only.sh`
  - `Quality: 6228`
  - all `7` rules pass

Latest responsive manual-route proof expansion on `2026-06-29`:

- the next same-family production-hardening packet then widened the existing
  public responsive Playwright proof so the newer canonical public manual and
  launch-authority routes are no longer outside the browser-level viewport
  evidence lane
- `website/tests/e2e/responsive-public-pages.spec.ts` now also covers:
  - `/features`
  - `/docs`
  - `/getting-started`
  - `/launch-status`
- that means the responsive public-route proof now covers the practical public
  operator/distribution surfaces that were widened most heavily in the recent
  manual packet, rather than only the older marketing and commerce routes
- current validation truth for that responsive-proof expansion is green:
  - `npm --prefix website run test:e2e:responsive`
  - responsive public-route Playwright proof: `22` tests passed
  - `scripts/run-hypertwist-web-surface-validation.sh --with-responsive-e2e`
  - focused website route/auth/release validation: `12` files, `74` tests
    passed
  - responsive public-route Playwright proof: `22` tests passed
  - responsive protected-route Playwright proof: `12` tests passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory

Latest commerce/download manual deepening follow-up on `2026-06-29`:

- the public pricing and download routes were widened again so the commercial
  and release-access lanes no longer stop too early at entitlement, package
  choice, and browser-to-desktop handoff
- `/pricing` now also carries:
  - the practical simulator-use manual for the installed software
  - the higher-dimensional family guide covering `Magic120Cell`,
    `MagicCube5D`, and the current embedded-browser `MagicTile` posture
  - the current input/device plus runtime-control truth, including the
    explicit desktop-hosted `No-Go` XR/controller boundary
- `/download` now also carries:
  - the practical installed-runtime manual
  - the higher-dimensional family guide directly on the package route
  - the same current input/device plus runtime-control truth before first
    launch
- this keeps the public commerce and package lanes professional and
  self-sufficient instead of forcing operators to jump into docs/resources
  before they can understand what the entitled desktop software actually does
- current validation truth for that manual-deepening continuation is green:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `15` tests passed
  - `npm --prefix website run build`
  - production website build passed
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `12` files, `74` tests
    passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory

Latest shared public-manual refactor follow-up on `2026-06-29`:

- the same-family continuation then tightened the public-manual ownership
  layer itself so the widened page set stays easier to evolve without silent
  copy drift
- shared first-party public-manual card sections now live in:
  - `website/src/pages/public-page-helpers.tsx`
  - `PrincipleCardSection`
  - `BulletCardSection`
  - `StepCardSection`
  - `FaqCardSection`
- the current public/manual consumers now route through those shared helpers
  instead of each page re-implementing the same card-grid structure:
  - `website/src/pages/public-pages-marketing.tsx`
  - `website/src/pages/public-pages-features.tsx`
  - `website/src/pages/public-pages-commerce.tsx`
- this does not widen product scope or alter the browser-versus-desktop truth;
  it keeps the existing operator-manual packet more coherent and less likely to
  diverge across the public route family
- current validation truth for that shared-ownership follow-up is green:
  - `npm --prefix website run type-check`
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `15` tests passed
  - `npm --prefix website run build`
  - production website build passed

Latest responsive-proof revalidation after the shared-manual continuation on `2026-06-29`:

- the current same-family continuation then re-proved the widened public and
  protected browser lanes at real browser viewport sizes after the newer
  shared-section and commerce/manual deepening work
- this did not widen product claims; it re-validated that the now-richer page
  set still behaves like a production operator/distribution surface on mobile
  and tablet breakpoints
- the owned responsive route proof stayed green under:
  - `scripts/run-hypertwist-web-surface-validation.sh --with-responsive-e2e`
  - focused website route/auth/release validation: `12` files, `74` tests
    passed
  - responsive public-route Playwright proof: `22` tests passed
  - responsive protected-route Playwright proof: `12` tests passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- the responsive public-route proof still covers the heavier manual and
  authority routes that matter most to this packet:
  - `/features`
  - `/docs`
  - `/getting-started`
  - `/launch-status`
  - plus the already-covered homepage, about, resources, pricing, download,
    support, and register routes
- the responsive protected-route proof also stayed current for:
  - `/app`
  - `/app/launch-status`
  - `/app/downloads`
  - `/app/browser-access`
  - `/app/account`
  - `/app/notices`
- current truthful reading after this revalidation:
  - the public/manual website lane remains intentional and professional rather
    than brochure-only
  - the richer manual/commerce copy introduced by the recent continuations did
    not regress the owned browser delivery surfaces

Latest launch-authority alignment follow-up on `2026-06-29`:

- the next same-family continuation then closed a remaining authority-gap seam
  between the documented auth-server launch summary and the browser surfaces
  that read it
- `website/src/shared/public-launch.ts` now prefers the richer server-provided
  `launch` summary from `GET /api/auth/health` when available, including its
  explicit blocker labels, checklist truth, and operator/studio checkout
  targets, instead of always reconstructing launch posture only from lower
  rollout booleans on the client
- that keeps the public `/launch-status` route and the protected
  `/app/launch-status` route better aligned with the intended server-owned
  rollout authority while still preserving bounded local derivation as a safe
  fallback if the richer summary is absent
- current validation truth for that authority-alignment continuation is green:
  - `npm --prefix website run type-check`
  - `npm --prefix website test -- --run src/__tests__/public-launch.test.ts src/__tests__/public-marketing-pages.test.tsx src/__tests__/protected-app-pages.test.tsx`
  - `3` files passed
  - `29` tests passed
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `13` files, `79` tests
    passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory

Latest shared public-manual section consolidation later on `2026-06-29`:

- the next same-family continuation stayed inside the owned public-manual lane
  and reduced drift risk by moving more repeated section rendering into shared
  helper ownership
- `website/src/pages/public-page-helpers.tsx` now also owns reusable public
  sections for:
  - simulator manual
  - higher-dimensional runtime guide
  - input and device posture
  - control-profile roster
  - runtime control guide
- the current page consumers now route those shared sections through:
  - `website/src/pages/public-pages-marketing.tsx`
  - `website/src/pages/public-pages-commerce.tsx`
- this does not widen product claims; it keeps the public docs/about/resources/
  pricing/download/getting-started family aligned as one professional operator
  manual instead of a set of near-copy pages that can drift separately
- validation stayed green on the same consolidation pass:
  - `npm --prefix website run type-check`
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `13` files, `79` tests
    passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory

Latest protected responsive recovery follow-up later on `2026-06-29`:

- the next same-family website quality pass fixed a real protected-route mobile
  regression instead of widening scope again
- the affected route was the signed-in `/app/launch-status` surface, where the
  stacked action rows could widen the viewport by a couple of pixels on narrow
  mobile widths because the button links still sized themselves to long labels
- `website/src/styles/global.css` now hardens the owned small-screen button-row
  posture so stacked protected actions fill the available column width and
  allow wrapped labels
- this correction stayed entirely inside the existing protected operator shell
  and did not alter the browser-versus-desktop truth or release-lane claims
- the full owned browser validation lane then re-ran green under:
  - `scripts/run-hypertwist-web-surface-validation.sh --with-responsive-e2e`
  - focused website route/auth/release validation: `13` files, `79` tests
    passed
  - responsive public-route Playwright proof: `22` tests passed
  - responsive protected-route Playwright proof: `12` tests passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- current truthful reading after this follow-up:
  - the richer public/protected manual lane is not only source-accurate, but
    also still behaves like a deliberate operator/distribution surface at real
    mobile and tablet breakpoints after the latest content widening

Latest feature-atlas shared-section completion plus public legal-route responsive expansion later on `2026-06-29`:

- the next same-family continuation stayed inside the owned public/manual lane
  and closed a remaining drift-risk gap instead of widening product scope
- the public feature-atlas route now also routes its repeated manual sections
  through the same shared helper ownership already used by the broader
  marketing and commerce families:
  - `HigherDimensionalRuntimeGuideSection`
  - `InputAndDevicePostureSection`
  - `ControlProfileRosterSection`
  - `RuntimeControlGuideSection`
- that means the higher-dimensional runtime guide, current input/device truth,
  selectable roster, and practical runtime-control guidance now share one
  first-party rendering path across the main public route family instead of
  leaving `/features` on a separate near-copy structure
- the same continuation then widened browser-level responsive proof across the
  remaining public legal/reference routes that were already content-complete
  but not yet inside the explicit mobile/tablet viewport lane:
  - `/changelog`
  - `/open-source-notices`
  - `/privacy`
  - `/terms`
  - `/shipping-payment`
- a later adjacent auth-entry parity continuation then also added `/login` to
  that same owned responsive public-route matrix so the real browser-entry
  surface sits under the same mobile/tablet proof lane as `/register`
- the owned responsive public-route proof therefore now covers the broader
  public operator/distribution family rather than only the marketing,
  onboarding, support, and core commerce subset
- current validation truth for that continuation is green:
  - `scripts/run-hypertwist-web-surface-validation.sh --with-responsive-e2e`
  - focused website route/auth/release validation: `13` files, `79` tests
    passed
  - responsive public-route Playwright proof: `34` tests passed
  - responsive protected-route Playwright proof: `12` tests passed
  - `website/server` suite: `10` files, `36` tests passed
  - `Content/Browser` shell verification and production build passed
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- current truthful reading after this continuation:
  - the feature atlas now sits on the same shared public-manual ownership path
    as the surrounding major public routes
  - the broader public legal/reference family now has real browser-level
    mobile and tablet overflow proof instead of relying only on route tests and
    source-level review

Latest feature-atlas capability-FAQ continuity follow-up on `2026-06-29`:

- the next same-family continuation stayed inside the owned public/manual lane
  and widened the public `/features` route from a capability matrix plus
  runtime-guide surface into a cleaner question-answering route as well
- the feature atlas now also renders a dedicated `Common capability questions`
  section backed by the same shared FAQ authority already used on the broader
  docs/support family
- those answers now keep the exact product-boundary questions visible directly
  on the capability route, including:
  - why the browser surface is intentionally narrower than the desktop runtime
  - why HyperTwist still keeps the web product surface even though the
    simulator is desktop-first
  - why XR/controller completion is not yet marketed as finished
  - how current control, settings, and bounded higher-dimensional continuity
    should be read honestly
- the FAQ wording itself was also tightened so the public manual now states the
  key inferiority points explicitly instead of leaving them implicit:
  - the browser surface does not own package-validated training behavior,
    low-latency native input, higher-dimensional packaged execution, or
    device/runtime integration authority
  - the current desktop runtime does own real keyboard or mouse or touch plus
    settings and higher-dimensional selector posture, but it still does not
    claim finished packaged XR/controller proof or polished rebinding
- focused validation for that continuation stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
  - `1` file passed
  - `16` tests passed

Latest same-family offline-manual continuity follow-up on `2026-06-30`:

- the public site now also ships one same-origin downloadable operator manual
  at `website/public/manual/hypertwist-operator-manual.md`
- homepage, resources, docs, getting-started, and download now all expose that
  same offline manual so the desktop-first product story, first-session path,
  and XR/controller non-claims can travel outside the browser intact
- the adjacent protected-surface continuation then threaded that same manual
  into the signed-in release-reference bundle too, so dashboard, launch-status,
  account, browser-access, download, and notices follow-through no longer fall
  back to public-only manual links once the operator is already signed in
- focused validation for that continuation stayed green under:
  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx src/__tests__/protected-app-pages.test.tsx`
  - `npm --prefix website run type-check`
  - `npm --prefix website run build`
- the owned continuity/tooling rerun also stayed green under:
  - `scripts/run-hypertwist-sentrux-source-only.sh` -> `Quality: 6248`
  - `scripts/run-hypertwist-gitnexus-analyze.sh` -> `Indexed commit: 1b4adda`
    with the already-documented local post-index non-zero exit salvaged by
    follow-up status proof
  - `scripts/run-hypertwist-gitnexus-status.sh` -> `Status: up-to-date`
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - website focused route/auth/release suite: `14` files, `84` tests passed
  - website deployment/readiness tooling suite: `4` files, `34` tests passed
  - website/server suite: `10` files, `36` tests passed
  - successful website and `Content/Browser` production builds

Later same-family offline-manual deepening follow-up still on `2026-06-30`:

- the downloadable operator manual is no longer only the lighter companion to
  the live route atlas
- `website/public/manual/hypertwist-operator-manual.md` now mirrors the richer
  public-manual truth directly, including:
  - current browser auth/account posture
  - the first operator journey from public launch posture through protected
    downloads and desktop-link pairing
  - concrete desktop workflow tracks for classic practice, recognition and
    correction, replay/coaching review, higher-dimensional training, and
    browser-return governance
  - the shipped classic control roster plus bounded settings/persistence truth
  - dedicated `Magic120Cell`, `MagicCube5D`, and embedded-browser `MagicTile`
    runtime guidance
  - operator adjunct families such as bounded speech, provider/routing, and
    continuity/provenance posture
  - degraded-state recovery guidance
  - public/protected route atlas descriptions instead of route-name lists alone
- the public release feed now also carries that manual change explicitly
  through the new same-day `changelogEntries` item in `website/src/site-data.ts`
- the full owned web-surface gate was rerun again on that deeper manual state
  and stayed green under:
  - `scripts/run-hypertwist-web-surface-validation.sh`
  - focused website route/auth/release validation: `14` files, `84` tests passed
  - deployment/readiness tooling validation: `4` files, `34` tests passed
  - `website/server` validation: `10` files, `36` tests passed
  - successful website and `Content/Browser` production builds
  - `website/` and `Content/Browser/` production audits stayed at
    `found 0 vulnerabilities`
  - `website/server/` again retained only the same already-documented upstream
    `supertokens-node -> nodemailer` residual advisory
- current truthful reading after this follow-up:
  - the offline manual is now closer to a real deployment/reference packet,
    not just a shorter brochure copy
  - the public website and protected shell still remain complementary to the
    native simulator rather than competing claims over the same runtime job
