Record native XR host decision posture

docs/ops/HYPERTWIST_NATIVE_XR_HOST_AND_PLUGIN_DECISION_PACKET_2026-06-24.md

@@ -0,0 +1,102 @@
+# HyperTwist Native XR Host And Plugin Decision Packet
+
+Created on `2026-06-24`.
+
+## Purpose
+
+This note fixes the current native XR host/plugin posture so the project stops
+leaving “maybe XR is already basically there” ambiguity in the Unreal lane.
+
+## Current decision
+
+Current decision: `No-Go` on native OpenXR/controller runtime widening in the
+shipping HyperTwist lane.
+
+Current authoritative host posture:
+
+- the shipping immersive lane remains a desktop-hosted Unreal training runtime
+  with scenic presence, comfort, posture, and session-local settings ownership
+- the project does **not** currently enable an `OpenXR` plugin stack in
+  `UnrealHyperTwist.uproject`
+- the project does **not** currently prove a first-party headset/controller
+  runtime owner such as a dedicated VR pawn plus
+  `MotionControllerComponent`-driven interaction surface
+- the newly landed native control/input and control/settings inspect surfaces
+  must be treated as truthful bounded ownership around the desktop simulator,
+  not as proof of a finished XR runtime
+
+## Evidence checked
+
+### Project plugin posture
+
+- `UnrealHyperTwist/UnrealHyperTwist.uproject` currently enables:
+  - `RemoteControl`
+  - `ProceduralMeshComponent`
+  - `WebBrowserWidget`
+  - editor-only tooling such as `MovieRenderPipeline`,
+    `PythonScriptPlugin`, and `ModelingToolsEditorMode`
+- that file does **not** currently declare an enabled `OpenXR` plugin
+
+### Runtime ownership posture
+
+- `UnrealHyperTwist/Config/DefaultInput.ini` still proves real
+  `EnhancedInput` and broad motion-controller axis groundwork
+- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingImmersiveEnvironmentLibrary.cpp`
+  keeps the immersive lane explicitly bounded to scenic training ownership
+- the same immersive library explicitly excludes:
+  - `platform-global XR settings ownership`
+  - `platform-level locomotion shell ownership`
+  - `full locomotion rig ownership`
+- `UnrealHyperTwist/Source/UnrealHyperTwist/Tests/HyperTwistImmersivePhaseIBPresenceControlContractTest.cpp`
+  proves those exclusions are intentional and current
+
+### Native truth surfaces
+
+- the `2026-06-23` native control/input inspect surface already kept unfinished
+  XR/runtime plus preferences truth explicit inside Unreal
+- the `2026-06-24` native control/settings inspect surface now also keeps
+  unfinished XR/controller rebinding truth explicit while still proving current
+  camera, immersive, and dedicated-family view settings ownership
+
+## Interpretation
+
+HyperTwist already owns:
+
+- desktop-screen simulator input
+- scenic immersive training presentation
+- session-local presence and comfort posture
+- current camera and dedicated-family view settings ownership
+
+HyperTwist does **not** yet own:
+
+- headset-runtime plugin posture
+- controller interaction runtime ownership
+- polished controller rebinding/preferences ownership
+- packaged XR/controller proof
+
+Therefore the current truthful host decision is:
+
+- keep the immersive lane desktop-hosted
+- keep `OpenXR` disabled by default in the shipping branch
+- do not market VR/controller support as finished
+- do not let browser-side retained XR grounding imply native XR completion
+
+## Reopen criteria
+
+Future native XR widening may reopen only when all of the following are true:
+
+1. the exact plugin stack is chosen explicitly and checked in
+2. first-party runtime owners for headset/controller interaction are present
+3. controller bindings and rebinding/preferences ownership are first-party and
+   user-visible
+4. Windows build plus focused automation plus packaged validation prove that
+   lane
+5. public/product copy is updated only after those proofs exist
+
+## Immediate consequence
+
+No native XR implementation packet is currently open by default.
+
+If the project later reopens this lane, the first implementation packet should
+be a bounded native plugin/runtime-owner slice, not public marketing widening
+and not speculative controller polish in the absence of a chosen runtime host.

docs/ops/HYPERTWIST_UNREAL_INPUT_AND_XR_COMPLETENESS_AUDIT_2026-06-22.md

@@ -8,6 +8,10 @@ This note records the current truthful state of HyperTwist native input,
 controller, and XR completeness so later public copy and roadmap decisions do
 not overclaim the Unreal runtime.
 
+Current companion decision note:
+
+- `C:\HyperTwist\docs\ops\HYPERTWIST_NATIVE_XR_HOST_AND_PLUGIN_DECISION_PACKET_2026-06-24.md`
+
 ## Current truthful conclusion
 
 HyperTwist currently has real native input ownership for:
@@ -126,6 +130,9 @@ truthfully claim:
   first-party immersive/scenic environment direction, but it also explicitly
   keeps scope bounded away from platform-global XR settings or generic VR shell
   ownership
+- the current explicit decision packet on `2026-06-24` therefore fixes the
+  host/plugin posture to desktop-hosted scenic immersive training with a
+  current `No-Go` on native OpenXR/controller runtime widening
 
 ## Product-language consequence
 
@@ -157,12 +164,18 @@ manual:
 
 ## Next clean implementation packet
 
-If the project wants to raise this lane from “groundwork exists” to “shipping
-quality,” the next clean packet is:
+The explicit native host/plugin decision is now fixed by:
 
-1. explicit native XR host/plugin decision
-2. dedicated runtime interaction owner(s) for headset and controller handling
-3. finished controller-specific rebinding/preferences ownership above the
+- `C:\HyperTwist\docs\ops\HYPERTWIST_NATIVE_XR_HOST_AND_PLUGIN_DECISION_PACKET_2026-06-24.md`
+
+That packet leaves native XR widening closed by default.
+
+If the project later reopens this lane from the current `No-Go` posture, the
+first clean implementation packet should be:
+
+1. a bounded native plugin/runtime-owner slice above the current desktop-hosted
+   immersive lane
+2. finished controller-specific rebinding/preferences ownership above the
    already-landed camera/immersive/view settings surfaces
-4. packaged validation on the Windows Unreal lane with headset/controller truth
+3. packaged validation on the Windows Unreal lane with headset/controller truth
    kept explicit

docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md

@@ -235,3 +235,4 @@ package validation actually prove it.
 Current 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`

docs/v6_5_deep_manual_pack/HyperTwist/PRD.md

@@ -123,6 +123,7 @@ shipping VR/controller/preferences lane without a dedicated completion packet.
 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
 

website/src/site-data.ts

@@ -652,7 +652,7 @@ export const supportFaqs = [
   },
   {
     question: 'Is VR/controller support already fully finished?',
-    answer: 'Not yet. HyperTwist already has real EnhancedInput posture and motion-controller groundwork, but it does not yet claim a fully finished OpenXR/controller/runtime or polished rebinding lane.',
+    answer: 'Not yet. HyperTwist already has real EnhancedInput posture, motion-controller groundwork, and a desktop-hosted scenic immersive lane, but it does not yet claim a fully finished OpenXR/controller/runtime or polished rebinding lane.',
   },
   {
     question: 'Can I already customize controls and higher-dimensional view posture?',