Strengthen public operator manual continuity

This commit is contained in:
axiomlogicnexus 2026-06-30 23:19:19 +00:00
parent 433a25ec16
commit aa537fb48f
9 changed files with 304 additions and 0 deletions

View file

@ -3370,3 +3370,36 @@ Later same-day recommendation-history micro-follow-up (`2026-06-30`):
- focused validation stayed green under:
- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx`
- `npm --prefix website run type-check`
## Latest public manual verification/reporting continuity follow-up (`2026-06-30`)
- the next same-family continuation stayed inside the first-party `website/`
operator-manual lane instead of reopening native topology:
- `website/src/site-data.ts`
- `website/src/pages/public-pages-commerce.tsx`
- `website/src/pages/public-pages-marketing.tsx`
- `website/public/manual/hypertwist-operator-manual.md`
- `website/src/__tests__/public-marketing-pages.test.tsx`
- `website/src/__tests__/offline-operator-manual.test.ts`
- `/download`, `/getting-started`, and `/docs` now carry a shared
first-session verification packet, so package delivery, onboarding, and the
broader public manual all teach the same concrete release-build, control,
classic-runtime, and higher-dimensional checks before a fresh install is
treated as trustworthy runtime authority
- `/docs` and `/support` now also carry a shared issue-reporting packet, so
account/pairing, release/install, runtime-training, and rollout/compliance
reports stay route-aware and higher-signal instead of flattening those
distinct surfaces together
- the same-origin downloadable operator manual now mirrors that stronger public
truth by stating:
- where the website is intentionally weaker than the native runtime
- the same first-session verification checklist
- the same issue-reporting checklist
- the new regression guard `offline-operator-manual.test.ts` keeps that offline
manual from silently drifting back into a materially thinner shell than the
live public routes
- focused validation stayed green under:
- `npm --prefix website test -- --run src/__tests__/public-marketing-pages.test.tsx src/__tests__/offline-operator-manual.test.ts`
- `npm --prefix website run type-check`
- `npm --prefix website run build`
- `scripts/run-hypertwist-sentrux-source-only.sh`

View file

@ -397,6 +397,17 @@ When a new packet materially adds or changes a normalized feature:
## Summary
### Latest continuity note (`2026-06-30`)
- the first-party `website/` public manual lane widened again without changing
topology:
- `/download`, `/getting-started`, and `/docs` now carry a shared
first-session verification packet
- `/docs` and `/support` now also carry a shared issue-reporting packet
- the same-origin downloadable operator manual now mirrors that
browser-limitations, verification, and reporting truth under a dedicated
regression test instead of remaining a materially thinner offline sibling
This file is the shortest path from packet authority to later user-facing
explanation.

View file

@ -749,3 +749,20 @@ load while keeping the coverage itself unchanged.
Canonical same-origin cutover guide:
- `docs/ops/HYPERTWIST_WEBSITE_SAME_ORIGIN_DEPLOYMENT_HANDOFF_2026-06-22.md`
Latest public manual verification/reporting continuity follow-up on `2026-06-30`:
- the public `/download`, `/getting-started`, `/docs`, and `/support` routes
now carry a stronger same-family first-session verification and
issue-reporting packet instead of leaving that operational guidance scattered
across adjacent sections only
- the same-origin downloadable operator manual at
`public/manual/hypertwist-operator-manual.md` now also mirrors the explicit
browser-limitations truth, the first-session verification checklist, and the
higher-signal reporting checklist so the offline manual no longer trails the
stronger live public routes
- focused validation stayed green under:
- `npm test -- --run src/__tests__/public-marketing-pages.test.tsx src/__tests__/offline-operator-manual.test.ts`
- `npm run type-check`
- `npm run build`
- `../scripts/run-hypertwist-sentrux-source-only.sh`

View file

@ -49,6 +49,33 @@ Important boundary:
- they own access, pricing, entitlement, notices, release posture, and pairing
- the desktop runtime remains the actual simulator authority
## Why the website stays and where it is intentionally weaker
### What the website is for
- public docs, route atlas, and product-safe onboarding
- pricing, launch posture, release notes, and notices
- support-safe rollout guidance
- protected account state, entitlement, and browser-to-desktop pairing
### What the desktop runtime is for
- package-validated simulator execution
- recognition, replay, coaching, analytics, and training continuity
- higher-dimensional packaged execution
- native diagnostics and runtime-adjacent operator work
### What the browser does not claim
- package-validated training behavior
- higher-dimensional packaged execution authority
- low-latency native device/runtime integration authority
- finished XR/controller runtime ownership
That narrower browser boundary is intentional. It keeps access, release,
billing, pairing, and legal-distribution work inspectable outside the simulator
while keeping the real training runtime easier to trust.
## Browser access and account posture
The browser lane is intentionally narrower than the simulator.
@ -105,6 +132,45 @@ Use this as the current first serious-session path.
- verify the higher-dimensional lane you intend to use
- keep the XR/controller boundary explicit
## First-session verification checklist
### Verify the delivered build and release context
- confirm the platform, channel, version/build id, and packaged-validation
summary on the public or protected download surface
- review release notes, notices, and corresponding-source posture before wider
rollout or redistribution
- keep the protected release lane as the delivery authority instead of relying
on remembered package assumptions
### Verify the shipped control roster and current boundary
- confirm the shipped classic profile `classic-wca-keyboard/v1` together with
pointer, orbit, zoom, hint, and hold-to-talk behavior
- read camera-export continuity, immersive recall, and higher-dimensional
selector posture as current bounded settings truth rather than a finished
global rebinding suite
- keep the desktop-hosted `No-Go` on native OpenXR/controller widening explicit
instead of treating groundwork as finished VR or controller support
### Verify the classic training lane
- launch the classic-cube lane and confirm timer, scramble, HUD, replay,
coaching, and diagnostics posture
- treat recognition, reconstruction, and solve-guidance behavior as native
runtime authority
- return to the browser shell only when account, release, entitlement, or
support posture becomes the next actual job
### Verify the higher-dimensional lane you plan to use
- launch the dedicated `Magic120Cell` or `MagicCube5D` packaged map from the
desktop runtime
- confirm the selector, projection, focus, symmetry/stereo, and visibility
posture you intend to use
- use native diagnostics when session, interactive-scene, persistence-boundary,
or state-semantics ownership needs confirmation
## Current desktop workflow tracks
### Classic-cube practice
@ -335,6 +401,46 @@ HyperTwist already has real adjunct operator surfaces around the simulator.
- do not treat fallback continuity as proof of full production readiness or full public-launch readiness
- use the protected launch-status and support routes for the next truthful move
## Issue reporting checklist
### Account, pairing, or entitlement issue report
- include whether the failure happened on a public route or a protected route
and name the exact path such as `/login`, `/app`, or `/app/downloads`
- state the sign-in method and whether the UI showed normal, mixed, or fallback
auth posture when the problem occurred
- call out whether the problem is sign-in, plan visibility, desktop-link
pairing, or protected release access
### Download, install, or release issue report
- include platform, channel, version/build id, and the packaged-validation
summary line
- state whether the issue is archive delivery, install, first launch,
release-note mismatch, or notices/corresponding-source follow-through
- note whether missing raw download URLs were expected public gating or an
actual failure inside the protected release lane
### Runtime or training issue report
- state whether the issue affects classic-cube training, recognition, replay or
coaching, `Magic120Cell`, `MagicCube5D`, or the `MagicTile` browser-host lane
- include the current control profile or settings lane when relevant,
especially for camera continuity, selector recall, or higher-dimensional view
posture
- separate a real shipped regression from the explicit unfinished
XR/controller/preferences boundary
### Rollout, pricing, or compliance issue report
- include the route, checkout/source/notices target, and whether the problem is
launch posture, billing/provisioning configuration, or legal-distribution
follow-through
- keep pricing, notices, corresponding-source, and release-reference issues
distinct from simulator bugs even when found during the same operator session
- attach launch-status or release-note context when it materially explains why
the public or protected shell could not complete the expected next move
## Support and escalation lanes
### Account and entitlement issues

View file

@ -0,0 +1,19 @@
import { readFileSync } from 'node:fs'
import { resolve } from 'node:path'
import { describe, expect, it } from 'vitest'
const manualPath = resolve(process.cwd(), 'public/manual/hypertwist-operator-manual.md')
describe('offline operator manual', () => {
it('keeps browser-versus-desktop truth, first-session verification, and issue-reporting guidance explicit', () => {
const manual = readFileSync(manualPath, 'utf8')
expect(manual).toContain('## Why the website stays and where it is intentionally weaker')
expect(manual).toContain('### What the browser does not claim')
expect(manual).toContain('## First-session verification checklist')
expect(manual).toContain('## Issue reporting checklist')
expect(manual).toContain('desktop-hosted native OpenXR/controller widening is `No-Go`')
expect(manual).toContain('`Magic120Cell`')
expect(manual).toContain('/app/downloads')
})
})

View file

@ -286,6 +286,8 @@ describe('public marketing pages', () => {
expect(within(downloadDecisionGuideSection as HTMLElement).getByText('Need the protected desktop-download lane?')).toBeTruthy()
expect(within(downloadDecisionGuideSection as HTMLElement).getByText('Need notices, corresponding source, or release follow-through?')).toBeTruthy()
expect(screen.getByText('First launch and desktop setup')).toBeTruthy()
expect(screen.getByText('First-session verification checklist')).toBeTruthy()
expect(screen.getByText('Verify the higher-dimensional lane you plan to use')).toBeTruthy()
expect(screen.getByText('Offline operator manual')).toBeTruthy()
expect(screen.getByRole('link', { name: 'Download offline operator manual' }).getAttribute('href')).toBe('/manual/hypertwist-operator-manual.md')
expect(screen.getByText('First desktop session after install')).toBeTruthy()
@ -1043,6 +1045,8 @@ describe('public marketing pages', () => {
expect(screen.queryByText('Google sign-in')).toBeNull()
expect(screen.getByText('Shows account, auth, billing, and release readiness posture')).toBeTruthy()
expect(screen.getByText('Support lanes')).toBeTruthy()
expect(screen.getByText('Issue reporting checklist')).toBeTruthy()
expect(screen.getByText('Account, pairing, or entitlement issue report')).toBeTruthy()
expect(screen.getByText('Support topic quick routes')).toBeTruthy()
expect(screen.getAllByText('Manual and route focus').length).toBeGreaterThan(0)
expect(screen.getByText('Recovery and degraded-state guidance')).toBeTruthy()
@ -1334,7 +1338,9 @@ describe('public marketing pages', () => {
expect(screen.getByText('Native training and coaching core')).toBeTruthy()
expect(screen.getByText('Operator manual')).toBeTruthy()
expect(screen.getByText('First real desktop session')).toBeTruthy()
expect(screen.getByText('Operational verification checklist')).toBeTruthy()
expect(screen.getByText('Recovery and degraded-state manual')).toBeTruthy()
expect(screen.getByText('Issue reporting checklist')).toBeTruthy()
expect(screen.getByText('Offline operator manual')).toBeTruthy()
expect(screen.getByRole('link', { name: 'Download offline operator manual' }).getAttribute('href')).toBe('/manual/hypertwist-operator-manual.md')
expect(screen.getByText('Support topic quick routes')).toBeTruthy()
@ -1479,6 +1485,7 @@ describe('public marketing pages', () => {
expect(screen.getByRole('link', { name: 'Download offline operator manual' }).getAttribute('href')).toBe('/manual/hypertwist-operator-manual.md')
expect(screen.getByText('Browser account access methods')).toBeTruthy()
expect(screen.getByText('First launch and desktop setup')).toBeTruthy()
expect(screen.getByText('First-session verification checklist')).toBeTruthy()
expect(screen.getByText('Simulator use today')).toBeTruthy()
expect(screen.getByText('Higher-dimensional family guide')).toBeTruthy()
expect(screen.getByText('Current control and device truth')).toBeTruthy()

View file

@ -15,6 +15,7 @@ import {
desktopReleaseSignals,
digitalDeliveryCards,
distributionDoctrineCards,
firstSessionVerificationCards,
inputAndDevicePostureCards,
openSourceNotices,
operatorManualTracks,
@ -325,6 +326,12 @@ export function DownloadPage() {
cards={desktopFirstLaunchCards}
/>
<BulletCardSection
title="First-session verification checklist"
description="The download lane is stronger when it also tells operators exactly what to confirm before they treat a fresh install as a trustworthy training runtime."
cards={firstSessionVerificationCards}
/>
<DownloadableOperatorManualSection
description="The download lane now also includes a same-origin offline manual so the first-session path, current controls, higher-dimensional runtime guide, and rollout boundary can be carried alongside the desktop build."
/>

View file

@ -16,8 +16,10 @@ import {
desktopFirstLaunchCards,
deploymentReadinessTracks,
digitalDeliveryCards,
firstSessionVerificationCards,
featureAtlasCurrentTracks,
heroMetrics,
issueReportingChecklistCards,
operatorManualTracks,
operatorPlaybooks,
publicDocumentationPrinciples,
@ -667,6 +669,12 @@ function GettingStartedPageContent({
</div>
</Section>
<BulletCardSection
title="First-session verification checklist"
description="This keeps the onboarding route operationally stronger by showing the exact checks that should happen before a new install is treated as a trustworthy training runtime."
cards={firstSessionVerificationCards}
/>
<BrowserDesktopRealitySection />
<SimulatorManualSection
@ -797,6 +805,12 @@ export function DocsPage() {
cards={desktopWorkflowTracks}
/>
<BulletCardSection
title="Operational verification checklist"
description="The public manual is more useful when it also shows how to verify a fresh install and a serious training session before operators widen into rollout or support work."
cards={firstSessionVerificationCards}
/>
<OperatorDesktopQuickstartSection />
<BrowserAuthMethodsSection
@ -809,6 +823,12 @@ export function DocsPage() {
cards={degradedStateRecoveryTracks}
/>
<BulletCardSection
title="Issue reporting checklist"
description="This is the public-safe reporting packet for account, release, runtime, and rollout issues so support receives higher-signal operator reports."
cards={issueReportingChecklistCards}
/>
<SupportTopicDirectorySection
title="Support topic quick routes"
description="These are the public docs entry points for the concrete help lanes HyperTwist already recognizes: launch readiness, operator access, and studio rollout."
@ -1001,6 +1021,12 @@ export function SupportPage() {
</div>
</Section>
<BulletCardSection
title="Issue reporting checklist"
description="These reporting prompts keep support requests concrete and route-aware so rollout, account, package, and runtime issues do not blur together."
cards={issueReportingChecklistCards}
/>
<SupportTopicDirectorySection
title="Support topic quick routes"
description="Use these cards when the issue already has a clear help lane and you want the shortest path through public, protected, and rollout-safe surfaces."

View file

@ -1542,6 +1542,84 @@ export const desktopFirstLaunchCards = [
},
] as const
export const firstSessionVerificationCards = [
{
title: 'Verify the delivered build and release context',
description: 'Treat the first session as a release-verified operator flow, not as a detached post-download guess.',
bullets: [
'Confirm the platform, channel, version/build id, and current packaged-validation summary on the public or protected download surface before deeper troubleshooting begins.',
'Review release notes, notices, and corresponding-source posture before wider rollout or redistribution so the exact build story stays attached to the runtime you installed.',
'Keep the protected release lane as the delivery authority instead of relying on stale browser tabs, screenshots, or remembered package assumptions.',
],
},
{
title: 'Verify the shipped control roster and current boundary',
description: 'The installed runtime should match the current public control truth before broader device expectations enter the session.',
bullets: [
'Confirm the shipped classic profile `classic-wca-keyboard/v1` together with pointer, orbit, zoom, hint, and hold-to-talk behavior so the first native session starts from the intended control baseline.',
'Read camera-export continuity, immersive recall, and higher-dimensional selector posture as current bounded settings truth rather than as a finished global rebinding suite.',
'Keep the desktop-hosted `No-Go` on native OpenXR/controller widening explicit instead of treating project groundwork as proof of finished VR or controller support.',
],
},
{
title: 'Verify the classic training lane',
description: 'Classic-cube execution is the fastest way to confirm that the delivered desktop runtime matches current product truth.',
bullets: [
'Launch the classic-cube lane and confirm timer, scramble, HUD, replay, coaching, and diagnostics posture before escalating a runtime issue outward.',
'Treat recognition, reconstruction, and solve-guidance behavior as native runtime authority instead of expecting the public browser shell to reproduce those flows directly.',
'Return to the browser shell only when account, release, entitlement, or support posture becomes the next actual job.',
],
},
{
title: 'Verify the higher-dimensional lane you plan to use',
description: 'The serious 120-cell and 5D families should be confirmed intentionally, not inferred from broad capability claims.',
bullets: [
'Launch the dedicated `Magic120Cell` or `MagicCube5D` packaged training map from the desktop runtime instead of assuming browser parity.',
'Confirm the current selector, projection, focus, symmetry or stereo, and visibility posture you intend to use before treating the session as higher-dimensional-ready.',
'Use native diagnostics when session, interactive-scene, persistence-boundary, or state-semantics ownership needs confirmation for a higher-dimensional issue report.',
],
},
] as const
export const issueReportingChecklistCards = [
{
title: 'Account, pairing, or entitlement issue report',
description: 'Support can move faster when account-facing failures stay attached to the exact browser surface and auth posture that produced them.',
bullets: [
'Include whether the failure happened on a public route or a protected route, and name the exact path such as `/login`, `/app`, or `/app/downloads`.',
'State the current sign-in method and whether the UI showed normal, mixed, or fallback auth posture when the failure occurred.',
'Call out whether the problem is sign-in, plan/entitlement visibility, desktop-link pairing, or protected release access rather than flattening them together.',
],
},
{
title: 'Download, install, or release issue report',
description: 'Package-facing problems need the concrete delivery facts that tie the issue back to one release surface and one runtime artifact.',
bullets: [
'Include platform, channel, version/build id, and the current packaged-validation summary line so support can tell whether the problem is delivery, install, or launch.',
'State whether the issue is archive delivery, install, first launch, release-note mismatch, or notices/corresponding-source follow-through.',
'Note whether the absence of a raw download URL was expected public gating or an actual failure inside the protected release lane.',
],
},
{
title: 'Runtime or training issue report',
description: 'Simulator bugs are easier to classify when the report keeps the actual runtime family and current control posture visible.',
bullets: [
'State whether the issue affects classic-cube training, recognition, replay/coaching, `Magic120Cell`, `MagicCube5D`, or the `MagicTile` browser-host lane.',
'Include the current control profile or settings lane when relevant, especially if the issue involves camera continuity, selector recall, or higher-dimensional view posture.',
'Separate a real shipped regression from the current explicit unfinished XR/controller/preferences widening so expected non-claims do not get filed as product breakage.',
],
},
{
title: 'Rollout, pricing, or compliance issue report',
description: 'Commercial and legal follow-through stay easier to resolve when they are reported as rollout posture issues rather than simulator defects.',
bullets: [
'Include the route, checkout/source target, and whether the problem is public launch posture, billing/provisioning configuration, or legal-distribution follow-through.',
'Keep pricing, notices, corresponding-source, and release-reference issues distinct from simulator bugs even when they were discovered during the same operator session.',
'Attach the current launch-status or release-note context when it materially explains why the public or protected shell could not complete the expected next move.',
],
},
] as const
export const desktopReleaseSignals = [
{
title: 'Package validation truth stays visible',