hypertwist/docs/v6_5_deep_manual_pack/HyperTwist/PRD.md

HyperTwist - PRD.md

Product definition

HyperTwist is a native cube and hypercube training environment that combines:

• physical recognition and reconstruction
• replay and explanation
• training/coaching orchestration
• hyper puzzle simulation
• publication/social training surfaces
• bounded voice/speech sidecars

Canonical discovery surfaces

Use these before expanding or describing product truth:

• FEATURE_REGISTRY.md for normalized feature extraction and confidence tiers
• ROADMAP.md for current sequencing truth
• C:\HyperTwist\docs\ops\HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md for current landed runtime anchors
• C:\HyperTwist\docs\ops\HYPERTWIST_MEMORY_LANE_AUTHORITY_AND_PHASE_IMPLEMENTATION_DOCTRINE_2026-05-21.md for memory lane taxonomy and sequencing
• C:\HyperTwist\docs\ops\HYPERTWIST_PROVIDER_NEUTRALITY_AND_BYOK_DOCTRINE_2026-05-21.md for provider-neutral/BYOK rules
• C:\HyperTwist\docs\ops\HYPERTWIST_SKILLIZATION_AND_COMMAND_SURFACE_DOCTRINE_2026-05-21.md for skill-layer rollout

Current product-state truth

The current product must be described carefully.

HyperTwist already has real first-party owned implementation, but later manual/marketing work must distinguish:

• implemented now
• deep-source grounded retained capability
• shallow placeholder capability

The canonical normalized surface for that distinction is:

• FEATURE_REGISTRY.md

Do not infer product truth from donor presence, queue position, or prompt-pack presence.

Website and simulator boundary

HyperTwist keeps both of these because they solve different product problems:

• the website owns public pages, account/auth, pricing, release posture, notices, and desktop pairing
• the desktop Unreal runtime owns the real simulator, packaged training flow, device/runtime integration, and higher-dimensional interaction

The website is therefore not superfluous, but it is intentionally inferior for the core simulator job. Public and manual wording must keep that distinction explicit.

Concrete interpretation rule:

• the browser version is for public docs, pricing, release posture, notices, support-safe onboarding, protected account state, and browser-to-desktop handoff
• the browser version is not the place to overclaim package-validated training behavior, higher-dimensional packaged execution, low-latency native input authority, or finished XR/controller runtime ownership
• the downloadable remains the materially more powerful product surface because it owns the simulator itself, the higher-dimensional family maps, packaged proof, and the current serious training workflows

The current first-party website also doubles as a bounded public-facing operator manual:

• homepage and about explain the browser-versus-desktop split
• docs and resources explain rollout-safe product truth and simulator-use guidance
• pricing, download, and notices surfaces explain entitlement, package proof, and public distribution posture

Users

• beginners learning 3D solving
• intermediate and advanced cubers
• hypercubers
• educators
• content creators
• self-directed AI-assisted learners

Core problems solved

• weak solve analysis in existing tools
• separation between physical practice and virtual analysis
• insufficient support for higher-dimensional practice
• fragmented training, timing, recognition, replay, and coaching flows

Core feature families

• physical cube recognition and reconstruction
• replay and state explanation
• algorithm/drill training and session control
• coaching/progression
• hyper puzzle catalog/topology/runtime
• public website/account/distribution surfaces
• deferred immersive training environments and focus-presence shells
• publication/challenge/social training surfaces
• analytics/reporting and provenance
• browser account, pricing, download, and legal distribution surfaces
• bounded speech/voice sidecars

Deferred first-party experiential lane

HyperTwist now has one explicit deferred experiential milestone:

• scenic virtual training environments and focus-presence shells

Important interpretation rule:

• this is planned HyperTwist-native product direction
• it is not current shipped capability
• it is not a generic virtual desktop/workspace shell
• it is separate from any future VectorShell immersive workspace lane

Canonical scoping note:

• C:\HyperTwist\docs\HYPERTWIST_VIRTUAL_TRAINING_ENVIRONMENT_AND_SCENIC_IMMERSION_SCOPING_NOTE_2026-05-31.md

Current Unreal input and XR truth

The current desktop runtime has real first-party input ownership for classic mouse/touch flows, higher-dimensional keyboard interaction, and project-level motion-control groundwork, but HyperTwist should not yet claim a fully finished shipping VR/controller/preferences lane without a dedicated completion packet.

The latest native/operator truth follow-up on 2026-06-28 also tightened the higher-dimensional side of that statement: native control-input readiness now proves shipped Magic120Cell and MagicCube5D host, view-context, session, and interactive-scene ownership explicitly by activation profile id instead of only implying readiness from broad runtime-catalog validity.

The adjacent native control-settings ownership seam was tightened the same day too: operator-facing settings truth now proves dedicated-family session, interactive-scene, persistence-boundary, and state-semantics ownership explicitly for both Magic120Cell and MagicCube5D instead of leaving that family-owned runtime state hidden behind generic view-settings wording.

The next adjacent non-XR preferences-continuity follow-up then tightened the same native/operator truth again without reopening the current controller lane: camera settings now keep bounded camera-export continuity explicit, scenic immersive settings now keep session-local recall ownership explicit, and the current product story stays honest that this is real local continuity rather than a finished global preferences or rebinding suite.

The same-family truth pass also carried that bounded continuity and active scene ownership into the native control-profile roster seam, so the selectable roster truth now stays aligned with the sibling control-settings and active runtime surfaces instead of leaving those facts implied.

The next same-family 2026-07-01 follow-up then moved the XR side of that statement forward too without overclaiming launch-tier completion:

• the desktop-hosted branch now enables OpenXR plus XRBase
• first-party bounded runtime-owner/profile ownership now exists through:
  • xr/openxr-desktop-training-runtime-owner
  • xr-openxr-training-preferences/v1
  • xr-openxr-motion-controllers/v1
• a dedicated AHyperTwistXrTrainingPawn now owns bounded camera/controller anchors, posture switching, recentering, and desktop fallback pitch handling
• the maintained Windows validation lane then re-proved the exact-source state with:
  • editor build Result: Succeeded, UnrealBuildTool Total execution time: 124.26 seconds
  • focused XR automation XR-BoundedRuntimeOwner-20260701-Final: 3/3 green
  • full browser automation Browser-XrBoundedRuntime-20260701-Final: 26/26 HyperTwist.Browser.* green

That is real bounded runtime ownership, but it is still not the same thing as finished launch-tier controller rebinding, packaged headset proof, or generic marketed VR completion.

Canonical audit note:

• C:\HyperTwist\docs\ops\HYPERTWIST_UNREAL_INPUT_AND_XR_COMPLETENESS_AUDIT_2026-06-22.md
• C:\HyperTwist\docs\ops\HYPERTWIST_NATIVE_XR_HOST_AND_PLUGIN_DECISION_PACKET_2026-06-24.md

Product guardrails

• packet docs and live code beat summaries when conflicts exist
• provider-specific donor patterns must not define the top-level provider contract
• compacted or assistive-transformed outputs must remain derived, not authoritative
• skills must remain optional assistive layers, not mandatory product truth

Success criteria

• users measurably improve faster
• higher-dimensional users take the platform seriously
• physical and virtual practice reinforce each other
• the product feels native, rigorous, and coherent