Promote HyperTwist browser desktop boundary guidance

docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md

@@ -225,6 +225,21 @@ Latest same-day follow-up later on `2026-06-24`:
 - `scripts/run-hypertwist-gitnexus-status.sh` then again reported the bounded
   mirror `Status: up-to-date`
 
+Later same-family public-manual continuity follow-up still on `2026-06-30`:
+
+- the shared browser-versus-desktop decision FAQ is now promoted out of the
+  deeper support/manual lane into the highest-traffic public marketing routes
+  as well
+- homepage and About now directly surface:
+  - whether the simulator is fully in the browser
+  - why the web lane is intentionally narrower
+  - why keeping the website still strengthens the desktop-first product
+    posture instead of weakening it
+- focused public marketing coverage widened again under:
+  - `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
+  - homepage and About now explicitly prove the promoted browser-versus-desktop
+    FAQ presence
+
 Latest same-family native control-surface hardening follow-up on `2026-06-30`:
 
 - the native control-settings formatter no longer overstates absent dedicated

website/src/__tests__/public-marketing-pages.test.tsx

@@ -458,6 +458,9 @@ describe('public marketing pages', () => {
     expect(await screen.findByText('Public website and release posture')).toBeTruthy()
     expect(screen.getAllByText('Preview posture').length).toBeGreaterThan(0)
     expect(screen.getByText('Why HyperTwist keeps both a website and a desktop runtime')).toBeTruthy()
+    expect(screen.getByText('Common browser-versus-desktop questions')).toBeTruthy()
+    expect(screen.getByText('If the desktop app is primary, why keep the web version?')).toBeTruthy()
+    expect(screen.getByText(/It is intentionally inferior for the core simulator job/i)).toBeTruthy()
     expect(screen.getByText('What the website is for')).toBeTruthy()
     expect(screen.getByText('Current input, XR, and settings truth')).toBeTruthy()
     expect(screen.getAllByText('Paddle webhook secret: missing').length).toBeGreaterThan(0)
@@ -592,6 +595,9 @@ describe('public marketing pages', () => {
 
     expect(screen.getByText('How a real HyperTwist session unfolds')).toBeTruthy()
     expect(screen.getByText('Why HyperTwist keeps both a website and a desktop runtime')).toBeTruthy()
+    expect(screen.getAllByText('Common browser-versus-desktop questions').length).toBeGreaterThan(0)
+    expect(screen.getByText('Is the simulator fully in the browser?')).toBeTruthy()
+    expect(screen.getByText(/The current shipping lane is desktop-first and Unreal-backed/i)).toBeTruthy()
     expect(screen.getByText('What the desktop runtime is for')).toBeTruthy()
     expect(screen.getByText('Choose the right HyperTwist surface')).toBeTruthy()
     expect(screen.getByText('Stay on the public website')).toBeTruthy()

website/src/pages/public-page-helpers.tsx

@@ -17,6 +17,7 @@ import {
   releaseNotesUrl,
 } from '../site-config'
 import {
+  browserDesktopDecisionFaqs,
   browserDesktopRealityCards,
   controlProfileRosterCards,
   deliverySurfaceCards,
@@ -580,6 +581,22 @@ export function FaqCardSection({
   )
 }
 
+export function BrowserDesktopDecisionFaqSection({
+  title = 'Common browser-versus-desktop questions',
+  description = 'These are the direct product-boundary answers most operators want before deciding whether the browser lane is enough on its own or whether they should move into the native runtime.',
+}: {
+  title?: string
+  description?: string
+}) {
+  return (
+    <FaqCardSection
+      title={title}
+      description={description}
+      cards={browserDesktopDecisionFaqs}
+    />
+  )
+}
+
 export function SupportTopicDirectorySection({
   title,
   description,

website/src/pages/public-pages-marketing.tsx

@@ -33,6 +33,7 @@ import {
 } from '../site-data'
 import {
   BrowserAuthMethodsSection,
+  BrowserDesktopDecisionFaqSection,
   BrowserDesktopRealitySection,
   ControlProfileRosterSection,
   DeliverySurfaceResponsibilitiesGrid,
@@ -127,6 +128,10 @@ export function HomeLanding() {
 
         <BrowserDesktopRealitySection />
 
+        <BrowserDesktopDecisionFaqSection
+          description="The homepage should answer the web-versus-desktop question directly where first-time operators actually encounter the product boundary, instead of forcing them to infer it from deeper manuals or support pages."
+        />
+
         <Section
           title="What ships now"
           description="The public site only describes current product truth or explicitly marked retained/spec-only branches."
@@ -300,6 +305,10 @@ export function AboutPage() {
           <DeliverySurfaceResponsibilitiesGrid />
         </Section>
 
+        <BrowserDesktopDecisionFaqSection
+          description="The about page should also answer the recurring boundary questions directly: what the browser can do, what it should not claim, and why keeping both surfaces is the more trustworthy product posture."
+        />
+
         <Section title="What makes the product different">
           <div className="card-grid">
             <article className="card">

website/src/site-data.ts

@@ -1143,6 +1143,11 @@ export const publicManualRouteAtlasCards = [
 ] as const
 
 export const changelogEntries = [
+  {
+    date: 'June 30, 2026',
+    title: 'Homepage and About now answer the browser-versus-desktop boundary directly',
+    details: 'The highest-traffic public marketing routes no longer leave the web-versus-native question buried in deeper support copy alone. Homepage and About now surface the shared product-boundary FAQ directly, including why the browser lane stays narrower, why that is a strength instead of a weakness, and why the optional full-browser simulator branch still remains spec-only.',
+  },
   {
     date: 'June 30, 2026',
     title: 'Native control-settings diagnostics now distinguish missing versus partial higher-dimensional ownership',
@@ -1439,11 +1444,7 @@ export const sourceAvailability = {
   releaseNotesUrl,
 }
 
-export const supportFaqs = [
-  {
-    question: 'Which browser sign-in methods are actually supported?',
-    answer: 'Email/password is the baseline shared-auth lane. GitHub, Google, and ORCID may also appear when the current deployment has those providers configured. Regardless of method, browser sign-in only opens the protected account, release, and desktop-pairing surfaces; it does not replace the native desktop simulator.',
-  },
+export const browserDesktopDecisionFaqs = [
   {
     question: 'Is the simulator fully in the browser?',
     answer: 'No. The current shipping lane is desktop-first and Unreal-backed. The public website offers account, operator, support, and download access, while the optional full-browser simulator path remains spec-only, so the browser does not currently replace the package-validated native runtime.',
@@ -1456,6 +1457,14 @@ export const supportFaqs = [
     question: 'Is VR/controller support already fully finished?',
     answer: 'Not yet. HyperTwist already has real classic keyboard and mouse or touch ownership, viewer camera and immersive settings ownership, higher-dimensional selector and view ownership, EnhancedInput posture, and motion-controller groundwork. But the current host decision remains desktop-hosted No-Go on native OpenXR/controller widening. A future reopen would still need dedicated runtime owners, user-facing settings and controller-rebinding ownership, and Windows packaged controller validation with controller truth before the software could honestly claim a finished headset/runtime lane.',
   },
+]
+
+export const supportFaqs = [
+  {
+    question: 'Which browser sign-in methods are actually supported?',
+    answer: 'Email/password is the baseline shared-auth lane. GitHub, Google, and ORCID may also appear when the current deployment has those providers configured. Regardless of method, browser sign-in only opens the protected account, release, and desktop-pairing surfaces; it does not replace the native desktop simulator.',
+  },
+  ...browserDesktopDecisionFaqs,
   {
     question: 'Can I already customize controls and higher-dimensional view posture?',
     answer: 'Partly. The current desktop runtime already owns the classic keyboard profile, viewer camera settings, bounded camera-export continuity, immersive-presence settings, session-local immersive recall, and higher-dimensional projection, focus, stereo, symmetry, and visibility defaults. The native operator surfaces now also expose which Magic120Cell or MagicCube5D session surface, interactive scene, persistence boundary, and state-semantics contract currently owns that settings lane, and they can recall selector posture from the latest persisted generated-mode launch request. A broader polished controller rebinding and preferences layer remains outside the current desktop-hosted No-Go lane unless a later reopen lands dedicated runtime owners, user-facing settings/rebinding ownership, and Windows packaged controller validation with controller truth.',