# HyperTwist Reverse-SSH Windows Build Lane Verification

Date: `2026-06-01`

Status: `verified live`

## Purpose

This note records that the documented HyperTwist reverse-SSH Windows shell path
is not merely theoretical.

It was re-verified live from the VPS on `2026-06-01`, and the Windows Unreal
build lane worked end-to-end.

## Governing docs

This verification sits beneath these authoritative docs:

- `C:\HyperTwist\docs\ops\HYPERTWIST_UNREAL_BUILD_VALIDATION_REQUIREMENT_2026-06-01.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_DEFERRED_TAILSCALE_AND_OPENSSH_LOCAL_REACHABILITY_NOTE_2026-05-31.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_AUTH_MODE_MISMATCH_AND_RECOVERY_2026-06-02.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_LIVE_CONNECTION_FACTS_2026-06-04.md`
- `C:\HyperTwist\docs\ops\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK_VPS_12_24_720_UBUNTU_24_04.md`

Credential details stay in the sensitive runbook.

## Verified path

The live verification used:

- VPS host: `212.227.13.220`
- reverse-tunnel listen port on the VPS: loopback-only `localhost:22022`
  backed by `127.0.0.1:22022` and `[::1]:22022` (primary)
- reverse-tunnel fallback listen port on the VPS: documented as
  `localhost:22023`, but absent in the latest `2026-06-04` live probe unless
  explicitly re-established
- Windows target identity:
  - user: `DESKTOP-KS3VGHU\anthracite ace`
  - hostname: `DESKTOP-KS3VGHU`

Verified VPS-side connect-back command shape:

```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10 -p 22022 -l 'DESKTOP-KS3VGHU\\anthracite ace' localhost
```

Fallback connect-back shape when `22022` is occupied or stale:

```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10 -p 22023 -l 'DESKTOP-KS3VGHU\\anthracite ace' localhost
```

Verified helper shape for short Windows-side PowerShell diagnostics on the same
lane:

```bash
HYPERTWIST_REMOTE_WINDOWS_PASSWORD='...' \
scripts/run-hypertwist-remote-windows-powershell.sh \
  --command 'Write-Output ("ComputerName=" + $env:COMPUTERNAME)'
```

## Current Linux-side pickup sequence

For a HyperTwist AI session that starts on Linux and needs to pick up the live
Windows build lane directly, the current proven sequence is:

1. stage the shared VPS key:

```bash
cp /home/dev/src/ScriptoriumAI/ops/ssh/scriptorium_vps_ed25519 /tmp/scriptorium_vps_ed25519_runtime
chmod 600 /tmp/scriptorium_vps_ed25519_runtime
```

2. enter the VPS:

```bash
ssh -tt -i /tmp/scriptorium_vps_ed25519_runtime -o StrictHostKeyChecking=no dev@212.227.13.220
```

3. from that VPS shell, connect back through the Windows reverse tunnel:

```bash
ssh -tt -o StrictHostKeyChecking=no -o PreferredAuthentications=password,keyboard-interactive -o PubkeyAuthentication=no -p 22022 -l "anthracite ace" localhost
```

If `22022` is occupied or fails SSH banner exchange, use:

```bash
ssh -tt -o StrictHostKeyChecking=no -o PreferredAuthentications=password,keyboard-interactive -o PubkeyAuthentication=no -p 22023 -l "anthracite ace" localhost
```

The current Windows password remains intentionally recorded only in the
sensitive runbook rather than duplicated here.

## Verified identity checks

Successful Windows-shell checks over the live reverse tunnel:

- `whoami` -> `desktop-ks3vghu\anthracite ace`
- `hostname` -> `DESKTOP-KS3VGHU`

## Verified Unreal build command

Successful Windows-side build command:

```cmd
"C:\Program Files\Epic Games\UE_5.7\Engine\Build\BatchFiles\Build.bat" UnrealHyperTwistEditor Win64 Development -Project="C:\HyperTwist\UnrealHyperTwist\UnrealHyperTwist.uproject" -WaitMutex -NoHotReloadFromIDE -NoUba
```

Current operational clarification:

- the command above remains the canonical repo-root example
- the currently maintained reverse-SSH validation root on the live Windows host
  is `C:\HyperTwist_worktrees\phase10validate`
- `C:\HyperTwist` is currently only a partial mirror on that host and should
  not be assumed to contain a usable authoritative `.uproject`

## Verified result

The build completed successfully on `2026-06-01`.

Reported results:

- `Target is up to date`
- `Result: Succeeded`
- UnrealBuildTool `Total execution time: 5.68 seconds`
- end-to-end stopwatch from the Windows shell: `6.16 seconds`

Interpretation:

- this measurement is the currently verified no-op or already-up-to-date
  incremental baseline
- real post-edit slice times may be longer depending on the changed files

## Operational meaning

For HyperTwist Unreal C++ work:

- AI instances running on the VPS can use this reverse-SSH path for real
  Windows Unreal validation
- Windows Unreal build validation is not blocked by architecture alone when
  either `localhost:22022` (primary) or `localhost:22023` (fallback) is live
- if `localhost:22022` is listening but SSH banner exchange fails, treat it as
  a stale listener and move to the fallback lane
- if neither `22022` nor `22023` can establish SSH banner/authentication, the
  correct report is that the tunnel is currently down, not that the Unreal
  slice was validated

## Addendum - 2026-06-04 (loopback-only live lane facts)

Live follow-up on `2026-06-04` established these current facts:

- `22022` is the active Windows reverse-shell lane
- the listener is loopback-only on the VPS, so the correct bridge target is
  `localhost:22022`, not public `212.227.13.220:22022`
- the listener was visible on both `127.0.0.1:22022` and `[::1]:22022`
- `22023` and `22024` were not visible in the latest probe and should be
  treated as unavailable until re-established
- live `whoami` over `22022` again returned `desktop-ks3vghu\anthracite ace`
- the repo now also carries
  `scripts/run-hypertwist-remote-windows-powershell.sh` as a bounded encoded-
  PowerShell wrapper for the reverse-SSH lane so future sessions can run short
  diagnostics or automation commands through `localhost:22022` without brittle
  nested shell quoting
- the repo now also carries
  `scripts/run-hypertwist-remote-unreal-automation.sh` as a thin first-party
  helper that builds canonical `UnrealEditor-Cmd` automation invocations on top
  of that encoded-PowerShell wrapper for the maintained
  `C:\HyperTwist_worktrees\phase10validate` lane
- the repo now also carries
  `scripts/run-hypertwist-remote-unreal-automation-sequence.sh` as a thin
  first-party fail-fast helper for short ordered batches of focused automation
  reruns on that same maintained validation lane
- the repo now also carries
  `scripts/run-hypertwist-remote-unreal-build.sh` as a thin first-party helper
  that builds canonical `Build.bat` invocations on top of that same encoded-
  PowerShell wrapper for the maintained
  `C:\HyperTwist_worktrees\phase10validate` lane, with the currently verified
  reverse-lane low-memory posture `-NoUBA -MaxParallelActions=2` as its
  default build shape

The sensitive runbook now carries the exact current Windows-side tunnel
commands, known-hosts scratch file, listener verification command, reverse-sync
commands, and the still-current password-backed login path.

## Addendum - 2026-06-30 (exact-source fallback refresh and host-lock recovery)

Live follow-up on `2026-06-30` established these additional facts:

- the primary reverse-SSH `localhost:22022` lane was still healthy for the
  current exact-source browser/package refresh sequence
- the repo now also carries
  `scripts/run-hypertwist-remote-exact-source-browser-package-refresh.sh` as a
  bounded first-party exact-source wrapper that:
  - re-proves the remote Windows shell identity
  - optionally syncs a bounded set of exact-source browser/package support
    files into the target Windows root
  - reruns the remote editor build, browser automation, and higher-dimensional
    package helper
  - pulls the refreshed browser/package evidence back into the tracked repo
  - re-renders
    `website/src/shared/generated/windows-package-validation-summary.json`
- the maintained validation root remained
  `C:\HyperTwist_worktrees\phase10validate`, but the exact-source editor build
  on that root failed twice with the same host-side file lock on:
  `C:\HyperTwist_worktrees\phase10validate\UnrealHyperTwist\Source\UnrealHyperTwist\Private\HyperTwistTraining\HyperTwistTrainingRepositoryLibrary.cpp`
- `scripts/run-hypertwist-remote-unreal-build.sh` now retries that exact
  transient Windows source-lock class once by default before declaring the
  build failed, so a host-state file lock is no longer silently conflated with
  an ordinary first-pass code failure
- because that maintained-root host lock persisted across the bounded retry,
  the same exact-source wrapper truthfully fell back to isolated Windows root
  `C:\HTpp`
- that fallback root initially lacked the current `Content\Browser`, package
  helper, manifest, and related exact-source support files, so the wrapper
  narrow-synced those first instead of pretending the fallback tree was already
  exact-source complete
- the fallback root also lacked the packaged-game target receipt
  `C:\HTpp\UnrealHyperTwist\Binaries\Win64\UnrealHyperTwist.target`, so the
  package helper correctly performed a full packaged build there instead of
  forcing `-SkipBuild`
- the same fallback root then passed the current exact-source browser
  automation proof through exported report
  `docs/generated/browser_automation/Browser-ExactSource-20260630/index.json`
  with:
  - `26` tests succeeded
  - `0` failed
  - `0` not run
  - `0` in process
- the same fallback root then passed the higher-dimensional package helper
  proof with:
  - `BuildCookRun` result `passed`
  - archive output in
    `C:\HTpp_packaged_phase6c_higherdim_refresh_20260630`
  - both dedicated-family packaged smoke maps green again:
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_Magic120CellTraining`
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_MagicCube5DTraining`
- the refreshed aggregate package proof was then pulled back into
  `docs/generated/higher_dimensional_training_maps/phase6c_dedicated_family_package_validation_report.json`
  and the public summary was re-rendered into
  `website/src/shared/generated/windows-package-validation-summary.json`
  with truthful `skip_build: false`
- later same-day maintained-root recovery then proved the inverse-but-still
  truthful packet shape on the primary root:
  - the exact-source wrapper again passed a fresh editor build first
  - the higher-dimensional package helper then legitimately reused the
    existing packaged-game receipt
  - the aggregate report and public summary therefore now need to carry both
    truths rather than overloading one `skip_build` field to mean the entire
    proof packet did or did not rebuild
- `scripts/run-hypertwist-remote-unreal-automation.sh` now also treats the
  exported automation report itself as authority, not only the
  `UnrealEditor-Cmd` process exit:
  - it clears any prior report directory first
  - requires the new `index.json` to exist
  - fails the wrapper when the report records any `failed`, `notRun`, or
    `inProcess` counts

Operational rules reinforced by this proof:

- when the maintained isolated Windows worktree is temporarily blocked by a
  host-side source-file lock, do not falsely report the whole exact-source lane
  as green or code-broken until the bounded retry and any declared fallback
  lane have both been truthfully exercised
- when a fallback Windows root is used for exact-source browser/package proof,
  sync the bounded browser/package support surfaces first instead of assuming a
  minimal Unreal tree is already sufficient evidence
- judge remote browser automation success by the exported report counts, not by
  process exit alone
- judge higher-dimensional package proof by the real target-receipt posture:
  use `-SkipBuild` only when the packaged-game receipt actually exists

## Addendum - 2026-06-22 (maintained validation-root clarification)

Live follow-up on `2026-06-22` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current
  classic-cube structural-cycle validation follow-up
- the Windows-side safe reverse-sync helper still updates `C:\HyperTwist`, but
  that path is currently only a partial mirror and does not contain a usable
  authoritative Unreal project root for validation
- the maintained build-validation root remained
  `C:\HyperTwist_worktrees\phase10validate`
- touched source files were hash-matched into that isolated worktree before the
  build rerun
- after removing an invalid `BlueprintPure` specifier from the new classic-cube
  operator interface, the same isolated worktree rebuilt successfully with
  `Result: Succeeded` and UnrealBuildTool `Total execution time: 656.71
  seconds`

Current interpretation after this follow-up:

- keep the canonical repo-root build command in doctrine, but treat the live
  maintained reverse-SSH validation root as
  `C:\HyperTwist_worktrees\phase10validate` until host state changes
- do not report a reverse-SSH Unreal slice as validated from
  `C:\HyperTwist` alone when that path is only a partial mirror on the live
  Windows host

## Addendum - 2026-06-11 (fallback lane package proof)

Live follow-up on `2026-06-11` established these additional facts:

- `22022` was no longer healthy for SSH in that session and should be treated as
  unavailable when it refuses banner/auth
- `22023` was healthy again and returned the Windows shell identity
  `desktop-ks3vghu\anthracite ace`

## Addendum - 2026-06-24 (remote sync hardening and rendered-truth proof)

Live follow-up on `2026-06-24` established these additional facts:

- the older append-based remote file-sync path could stall mid-transfer on this
  lane and leave a stale remote `cmd.exe` plus `powershell.exe` writer holding
  an exclusive lock on the target file
- the repo-local
  `scripts/run-hypertwist-remote-windows-file-sync.sh` helper is now hardened
  to stream a single fixed-length base64 payload per file and verify the remote
  SHA-256 hash afterward, instead of opening the destination in repeated append
  mode
- when an earlier stale writer is already present, the safe recovery shape is:
  identify only the exact remote processes whose command line names the locked
  target path, terminate only those stale sync writers, then rerun the helper
  from a clean state
- after that hardening and stale-writer cleanup, the same primary
  `localhost:22022` lane hash-matched:
  - `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingPanelWidget.cpp`
  - `UnrealHyperTwist/Source/UnrealHyperTwist/Tests/HyperTwistBrowserBridgeObjectTest.cpp`
  into maintained validation root
  `C:\HyperTwist_worktrees\phase10validate`
- the same maintained validation root then rebuilt with:
  - `Result: Succeeded`
  - UnrealBuildTool `Total execution time: 172.52 seconds`
- focused browser automation then exported:
  `C:\HyperTwist_worktrees\phase10validate\UnrealHyperTwist\Saved\AutomationReports\Browser-XrNoGoRendered-Verify`
  with all `20` `HyperTwist.Browser.*` tests passing
- that proof covered the native training-panel and coach-dashboard control
  surfaces after they were tightened to render the fixed desktop-hosted
  `No-Go` decision on native OpenXR/controller widening directly in their
  operator-facing detail lines

Accepted noise during that latest proof:

- unattended startup again emitted the known
  `Failed to create the web browser window.` message
- the focused automation run still completed successfully, exported the report,
  and kept the lane green despite that warning
- the Windows host name still resolved as `DESKTOP-KS3VGHU`
- a dirty primary `C:\HyperTwist` checkout was intentionally left untouched
- the validated route instead used an isolated Windows worktree:
  `C:\HyperTwist_worktrees\phase3pkg`
- a committed tree snapshot was streamed into that isolated worktree from the
  Linux side, avoiding Windows Git credential and dirty-worktree hazards
- `Build.bat` for `UnrealHyperTwistEditor` succeeded from the isolated worktree
- `RunUAT BuildCookRun` succeeded from the same isolated worktree and archived to
  `C:\HyperTwist_worktrees\phase3pkg_packaged`
- packaged smoke launch succeeded from
  `C:\HyperTwist_worktrees\phase3pkg_packaged\Windows\UnrealHyperTwist.exe`
- a later same-day follow-up on isolated worktree
  `C:\HyperTwist_worktrees\phase3to5` exposed a stale-UHT hazard when a
  Linux-side tar delta was extracted with preserved source mtimes
- preserving those mtimes left
  `Intermediate\Build\Win64\UnrealEditor\Inc\UnrealHyperTwist` stale and
  surfaced misleading reflected-type or generated-header failures around later
  classic-cube header changes
- the successful recovery sequence was: remove the stale generated-header
  directory, re-extract the delta with `tar -xf ... -m`, then rerun
  `Build.bat`

Operational rule added by this proof:

- if the primary Windows repo is dirty or lacks Git auth, do not force it clean
  just to obtain Unreal validation
- prefer an isolated reverse-SSH worktree populated from the committed source
  tree, then run build/package/smoke validation there
- when updating that isolated worktree from Linux-side tar deltas, prefer
  fresh mtimes on extraction rather than preserving source mtimes

## Addendum - 2026-06-12 (dedicated-map closure proof)

Live follow-up on `2026-06-12` established these additional facts:

- the verified fallback `localhost:22023` lane remained healthy for the current
  session
- the isolated Windows worktree `C:\HyperTwist_worktrees\phase3to5` was used as
  the authority validation lane for final `Phase 3A` through `Phase 5C`
  closure
- dedicated training maps and the authored classic-cube material family were
  generated there through `scripts\Invoke-HyperTwistClassicCubeMapAuthoring.ps1`
- the current headless `UnrealEditor-Cmd` lane still crashes during post-save
  shutdown with `EXCEPTION_INT_DIVIDE_BY_ZERO`, but the hardened authoring flow
  now checkpoint-saves the level and pre-creates materials so the authored
  assets survive that shutdown fault
- the resulting dedicated assets included:
  - `C:\HyperTwist_worktrees\phase3to5\UnrealHyperTwist\Content\HyperTwistTraining\Maps\L_HyperTwist_ClassicTraining.umap`
  - `C:\HyperTwist_worktrees\phase3to5\UnrealHyperTwist\Content\HyperTwistTraining\Maps\L_HyperTwist_FollowAlongTraining.umap`
  - `C:\HyperTwist_worktrees\phase3to5\UnrealHyperTwist\Content\HyperTwistTraining\Materials\...`
- `BuildCookRun` then succeeded from that same worktree and archived to
  `C:\HyperTwist_worktrees\phase3to5_packaged`
- the default packaged smoke boot for `L_HyperTwist_ClassicTraining` succeeded
- a second explicit packaged smoke boot for
  `/Game/HyperTwistTraining/Maps/L_HyperTwist_FollowAlongTraining` also
  succeeded

Operational rules reinforced by this proof:

- treat the fallback `22023` lane as valid only when it is explicitly
  reverified live
- when the headless editor crashes after asset save, verify helper postconditions
  and asset timestamps before reauthoring from scratch
- if the slice creates authority `.umap` or `.uasset` assets inside the
  isolated Windows worktree, pull them back into the tracked repo before
  calling the packet landed

## Addendum - 2026-06-12 (Phase 6A build and automation proof)

Live follow-up on `2026-06-12` established these additional facts:

- the primary `localhost:22022` lane was not healthy for the current `Phase 6A`
  validation pass, while the explicitly reverified fallback `localhost:22023`
  lane was healthy
- the validated route used the isolated Windows tree
  `C:\Users\Anthracite Ace\HyperTwist_phase6a_validate`
- a fresh incremental `Build.bat` pass for `UnrealHyperTwistEditor` succeeded
  there after the final `Phase 6A` quality-tightening patch
- the same lane then passed targeted headless automation for:
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.CellFirstProjectionContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.CellTurnContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.SceneContextContract`
- the command-line run closed with `**** TEST COMPLETE. EXIT CODE: 0 ****`

Operational rules reinforced by this proof:

- when a live HyperTwist Unreal slice depends on the fallback lane, record both
  the build result and the automation result rather than stopping at one or the
  other
- for a bounded runtime packet like `Phase 6A`, the landing bar is compile
  proof plus focused owned-contract automation, not compile proof alone

## Addendum - 2026-06-12 (Phase 6B build and automation proof)

Live follow-up on `2026-06-12` established these additional facts:

- the primary `localhost:22022` lane was not healthy for the current `Phase 6B`
  pass, while the explicitly reverified fallback lane at `localhost:22023` was
  healthy
- live `whoami` over that fallback lane again returned
  `desktop-ks3vghu\anthracite ace`
- the validated route used the isolated Windows tree
  `C:\Users\Anthracite Ace\HyperTwist_phase6a_validate`
- a fresh incremental `Build.bat` pass for `UnrealHyperTwistEditor` succeeded
  there after the new `Phase 6B` source files were reverse-synced into the
  isolated tree
- targeted headless automation then succeeded there for:
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.SceneContextContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.SliceTurnContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.VisibleProjectionContract`
- the project log closed that automation pass with:
  `**** TestExit: Automation Test Queue Empty ****`

Operational rules reinforced by this proof:

- when a bounded HyperTwist runtime slice introduces new translation units, the
  isolated Windows validation tree remains a valid place to reverse-sync only
  the changed files before running the canonical build
- for `Phase 6B`, the owned landing bar remained compile proof plus focused
  owned-contract automation on the same explicitly reverified tunnel lane

## Addendum - 2026-06-12 (Phase 9A / 9C / 10B primary-lane build and integration proof)

Live follow-up on `2026-06-12` established these additional facts:

- the primary `localhost:22022` lane was healthy again for the current
  validation pass, while the fallback listener behind `localhost:22023` was
  also visibly listening in the same session
- live `whoami` over the primary lane again returned
  `desktop-ks3vghu\anthracite ace`
- the validated route used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- a final post-patch incremental `Build.bat` pass for
  `UnrealHyperTwistEditor` succeeded there with `Result: Succeeded` and
  UnrealBuildTool `Total execution time: 590.90 seconds`
- the same primary lane then passed the full
  `HyperTwist.Integration.ClassicCube` suite there with
  `**** TEST COMPLETE. EXIT CODE: 0 ****`
- a superseded `BuildCookRun` attempt on that same isolated worktree left stale
  `AutomationTool` / `UnrealBuildTool` `dotnet.exe` processes behind; targeted
  termination of only those stale toolchain processes cleared the lane for the
  final build-plus-integration rerun

Operational rules reinforced by this proof:

- when both `22022` and `22023` are visibly listening, prefer the primary
  `22022` lane unless it actually fails SSH banner/authentication checks
- when a superseded or interrupted package attempt is abandoned, verify whether
  stale `AutomationTool` or `UnrealBuildTool` processes still own the isolated
  worktree before classifying the tunnel or source state as broken
- for the classic-cube replay/leaderboard validation packet, the owned landing
  bar is compile proof plus the full `HyperTwist.Integration.ClassicCube`
  suite on the same isolated worktree before the package gate is called closed

## Addendum - 2026-06-13 (Phase 10C primary-lane package proof)

Live follow-up on `2026-06-13` established these additional facts:

- the primary `localhost:22022` lane was healthy for the current package pass
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- a project-level `.uproject` disable alone did not keep the legacy
  `UnrealMCP` editor-toolbar module out of `UnrealEditor-Cmd`; the successful
  recovery added explicit commandlet/unattended guards in both legacy
  `UnrealMCP` and maintained `UnrealMCPChong` editor-startup paths
- after those guards landed, `BuildCookRun` succeeded there with
  `ExitCode=0` and `BuildCookRun time: 164.59 s`
- the resulting archive output was written to
  `C:\HyperTwist_worktrees\phase10validate_packaged`
- the default packaged smoke boot for `L_HyperTwist_ClassicTraining` succeeded
- a second explicit packaged smoke boot for
  `/Game/HyperTwistTraining/Maps/L_HyperTwist_FollowAlongTraining` also
  succeeded

Operational rules reinforced by this proof:

- treat editor-plugin commandlet safety as part of the real package gate when
  those plugins are present in the project
- when a package failure originates inside `UnrealEditor-Cmd`, fix the headless
  startup assumption directly and rerun the full package/archive/smoke chain on
  the same isolated worktree before calling the slice closed

## Addendum - 2026-06-13 (Phase 6C primary-lane build and automation proof)

Live follow-up on `2026-06-13` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current `Phase 6C`
  higher-dimensional validation pass
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- the new `Phase 6C` source files invalidated the existing makefile because a
  new translation unit was added, after which a fresh `Build.bat` pass for
  `UnrealHyperTwistEditor` still succeeded there with `Result: Succeeded` and
  UnrealBuildTool `Total execution time: 2829.95 seconds`
- targeted headless automation then found `4` tests under
  `HyperTwist.FirstParty.HigherDimensional.Phase6C`
- all `4` of those tests succeeded:
  - `ActivationCatalog`
  - `Magic120CellActivationProfile`
  - `MagicCube5DActivationProfile`
  - `TrainingRunDefinitionBridge`
- the command-line run closed with
  `**** TEST COMPLETE. EXIT CODE: 0 ****`

Operational rules reinforced by this proof:

- for an owned higher-dimensional widening packet like `Phase 6C`, the landing
  bar can remain compile proof plus focused contract automation before any
  interactive projection shell exists
- when a new higher-dimensional slice lands as a catalog/definition bridge
  first, validate both direct profile resolution and real training-run
  definition propagation on the same Windows Unreal lane

## Addendum - 2026-06-18 (Phase 6C continuation recovery and final proof)

Live follow-up on `2026-06-18` established these additional facts:

- the same primary `localhost:22022` lane remained healthy after an interrupted
  follow-up that initially made `LaunchExecution` appear stalled
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- the recovery path re-proved Windows login on the active reverse tunnel and
  then hash-matched the changed subsystem/test files back into that isolated
  worktree before rebuilding
- the cleaned `Build.bat` pass for `UnrealHyperTwistEditor` still succeeded
  there with `Result: Succeeded` and UnrealBuildTool `Total execution time:
  124.81 seconds`
- targeted headless automation then found `8` tests under
  `HyperTwist.FirstParty.HigherDimensional.Phase6C`
- all `8` of those tests succeeded, including `LaunchCatalog`,
  `ViewContextCatalog`, `LaunchExecution`, and
  `RunStateActivationResolution`
- the command-line run closed with
  `**** TEST COMPLETE. EXIT CODE: 0 ****`
- `LaunchExecution` remained long-running enough for the controller to emit
  `Ignoring very large delta of 499.13 seconds`, so the quiet interval is now
  known-good on this lane rather than a default corruption indicator

## Addendum - 2026-06-22 (higher-dimensional structured package-report proof)

Live follow-up on `2026-06-22` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current
  higher-dimensional package-helper proof
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- the maintained helper pair
  `scripts\Invoke-HyperTwistHigherDimensionalPackage.ps1` and
  `scripts\Launch-HyperTwistHigherDimensionalPackage.ps1` was narrow-synced
  into that isolated worktree without forcing a broad reverse-sync
- the packaged-game target receipt was already present there, so the helper was
  validated in `-SkipBuild` mode rather than spending time on an unrelated full
  game rebuild for this script-only slice
- before `BuildCookRun`, the helper verified that the
  `Magic120Cell` / `MagicCube5D` dedicated-family `.umap` files still matched
  the owned hashes recorded in
  `docs\generated\higher_dimensional_training_maps\phase6c_dedicated_family_map_manifest.json`
- `BuildCookRun` then succeeded from that same worktree with `ExitCode=0` and
  `BuildCookRun time: 118.53 s`
- archive output was written to
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase6c_higherdim`
- packaged smoke launch succeeded for
  `/Game/HyperTwistTraining/Maps/L_HyperTwist_Magic120CellTraining`
- packaged smoke launch also succeeded for
  `/Game/HyperTwistTraining/Maps/L_HyperTwist_MagicCube5DTraining`
- the maintained helper wrote aggregate report JSON to
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase6c_higherdim\validation\higher-dimensional-package-validation-report.json`
- the same aggregate proof was then pulled back into the tracked repo at
  `docs/generated/higher_dimensional_training_maps/phase6c_dedicated_family_package_validation_report.json`

Operational rules reinforced by this proof:

- for a script-only packaging helper slice on this lane, prefer a narrow file
  sync plus `-SkipBuild` when the packaged-game target receipt already exists
- when a package helper validates manifest-backed map freshness before cook,
  treat that manifest gate as part of the proof rather than as incidental log
  noise
- when a remote packaged-validation archive becomes relied-on source-backed
  evidence, pull the aggregate report back into the tracked repo before calling
  the lane closed

## Addendum - 2026-06-13 (replay, leaderboard, and structured package-report proof)

Live follow-up on `2026-06-13` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current
  replay/leaderboard/package continuation
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- a prior aborted broad tar sync had left remote
  `HyperTwistWhisperCppPhase6RESpeechTranscriptContractTest.cpp` corrupted in
  that worktree; targeted re-sync plus hash parity across the changed slice
  files repaired the lane before validation continued
- the canonical `Build.bat` pass then succeeded there with `Result: Succeeded`
  and UnrealBuildTool `Total execution time: 2029.78 seconds`
- a fresh `UnrealEditor-Cmd` integration pass then found `7` tests under
  `HyperTwist.Integration.ClassicCube` and passed all `7`, including
  `ReplayPersistenceNormalization`, `LeaderboardNormalization`, and
  `LeaderboardStatusLine`
- fresh focused `Phase 10B` commandlet passes on the same rebuilt binary also
  passed:
  - `HyperTwist.Simulation.ClassicCube.Behavior.Rotation`
  - `HyperTwist.Simulation.ClassicCube.Behavior.Solve`
  - `HyperTwist.Solver.Accuracy.RandomClassicStates`
  - `HyperTwist.Training.Timer.Accuracy`
  - `HyperTwist.Speech.Transcription.ClassicCubeMoveParsing`
- the timer-accuracy pass closed green but surfaced unrelated warning noise
  from missing local `vision` and `speech` health hosts, so that warning
  context should be recorded rather than misclassified as a test failure
- the maintained package helper was then revalidated in `-SkipBuild` mode
  against the already-present packaged-game receipt, wrote archive output to
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase10b10c9a9c`,
  completed `BuildCookRun` with `ExitCode=0` and `BuildCookRun time: 69.16 s`,
  wrote aggregate JSON to
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase10b10c9a9c\validation\classic-cube-package-validation-report.json`,
  wrote per-map smoke JSON beneath
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase10b10c9a9c\validation\smoke\`,
  and smoke-launched both training maps successfully

Operational rules reinforced by this proof:

- when a broad reverse-sync is interrupted or aborted, hash-check or explicitly
  re-sync the changed files before treating later remote compiler failures as
  true source regressions
- when validating package-helper archive/report behavior and the packaged-game
  receipt already exists, prefer a fresh `-SkipBuild` package proof over an
  unrelated full game rebuild
- when using `-SkipBuild` for package-helper proof, do not treat receipt
  existence alone as sufficient: the packaged-game receipt and binary must
  also be fresh against current `.uproject`, `Source`, `Config`, and `Plugins`
  inputs or the helper should force a truthful rebuild instead
- when one `UnrealEditor-Cmd` `ExecCmds` string attempts to queue multiple
  disjoint `Automation RunTests` filters, inspect the exported report JSON or
  rerun the filters explicitly; the first filter may be the only one reflected
  in the report

## Addendum - 2026-07-02 (XR packaged-validation lane posture)

Live follow-up on `2026-07-02` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current bounded
  XR packaged-validation continuation on maintained Windows worktree
  `C:\HyperTwist_worktrees\phase10validate`
- the repo now also carries first-party bounded XR packaged-validation helpers:
  - `scripts\Invoke-HyperTwistXrPackage.ps1`
  - `scripts\Launch-HyperTwistXrPackage.ps1`
- the first exact-source packaged rerun exposed a real stale-artifact truth:
  the older helper posture could allow `-SkipBuild` from a merely editor-green
  state even when the packaged-game target receipt and Win64 game binary were
  stale relative to current source/config/plugin inputs
- that helper posture is now repaired: `-SkipBuild` is only valid when those
  packaged-game artifacts are both present and fresh against the current build
  inputs
- after that repair, the same maintained root then completed a truthful full
  packaged-game rebuild with:
  - `Result: Succeeded`
  - UnrealBuildTool `Total execution time: 2499.70 seconds`
  - `BuildCookRun time: 2593.82 s`
- the first packaged smoke after that rebuild then exposed a second host-state
  truth on this lane: under the unattended reverse-SSH session, windowed XR
  packaged proof failed swapchain creation with `DXGI_ERROR_NOT_CURRENTLY_AVAILABLE`
- the current owned recovery path is therefore explicit:
  - use `RuntimeLaunchMode=windowed` only for future live headset/controller
    observation proof on a suitable non-headless host context
  - use `RuntimeLaunchMode=nullrhi` for the current reverse-SSH packaged
    structural launch/ownership proof
- the final exact-source rerun on that same maintained root then stayed green
  in `nullrhi` mode with:
  - `BuildCookRun time: 85.47 s`
  - aggregate report `result: passed`
  - both XR smoke maps green:
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_FollowAlongTraining`
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_ClassicTraining`
  - checked-in aggregate proof:
    `docs/generated/xr/xr_packaged_validation_report_2026-07-02.json`
  - explicit remaining gate ids:
    - `xr/windows-packaged-headset-session-observation`
    - `xr/windows-packaged-controller-input-observation`

Operational rules reinforced by this proof:

- for headless reverse-SSH packaged XR proof, `nullrhi` is the truthful
  current structural launch path and should not be mislabeled as live
  headset/controller proof
- for live packaged headset/controller observation, reopen a non-headless
  `windowed` proof context instead of overloading the current unattended lane
- when packaged proof is the goal, judge `-SkipBuild` freshness from the
  packaged-game receipt and binary timestamps against current build inputs, not
  from artifact existence alone
- the repo now also carries `scripts\Invoke-HyperTwistXrWindowedObservation.ps1`
  as the bounded first-party interactive-desktop wrapper for that remaining
  live observation gate
- the first exact-source probe through that wrapper on `2026-07-02` proved the
  current reverse-SSH/OpenSSH session itself is not the required windowed lane:
  - current PowerShell session id: `0`
  - Explorer desktop session ids: `1`
  - current `OpenXR` active-runtime registry entry: absent
  - checked-in aggregate probe:
    `docs/generated/xr/xr_windowed_live_observation_probe_2026-07-02.json`
- operational reading after that probe:
  - the reverse-SSH lane remains authoritative for editor builds, automation,
    package/archive work, and headless `nullrhi` XR structural proof
  - the reverse-SSH lane is **not** the authoritative live windowed XR proof
    lane while it is entering Session `0` rather than the interactive desktop
    Session `1`
  - that left the remaining headset/controller observation gate temporarily
    blocked on the interactive-desktop launch context
- the next same-day continuation then closed that launch-context gap without
  widening beyond the XR proof lane:
  - the repo now also carries
    `scripts\Invoke-HyperTwistInteractiveDesktopTask.ps1`
  - checked-in bridge proof:
    `docs/generated/xr/xr_interactive_desktop_task_probe_2026-07-02.json`
  - that bridge proof shows:
    - scheduler task creation from Session `0`: passed
    - scheduler task run from Session `0`: passed
    - resulting task session id: `1`
    - resulting task explorer-session parity: `1`
  - a later same-day XR rerun through that new bridge then produced:
    `docs/generated/xr/xr_windowed_interactive_desktop_probe_2026-07-02.json`
    with:
    - `currentSessionId: 1`
    - `isInteractiveDesktopSession: true`
    - `openXrActiveRuntimePresent: false`
    - error narrowed to missing active `OpenXR` runtime
- operational reading after the bridge continuation:
  - the reverse-SSH lane plus first-party interactive-desktop task bridge can
    now initiate the real Session `1` windowed XR proof path
  - the remaining blocker is no longer the desktop-session bridge
  - the remaining blocker is the absent active `OpenXR` runtime on the logged-
    in Windows desktop
- the next same-day continuation then removed the runtime-resolution blocker
  too without changing the machine-wide registry:
  - `scripts\Launch-HyperTwistXrPackage.ps1` and
    `scripts\Invoke-HyperTwistXrWindowedObservation.ps1` now also accept
    `-OpenXrRuntimePathOverride`
  - the maintained lane used override path
    `C:\Windows\System32\MixedRealityRuntime.json`
  - the first override-backed rerun exposed a real wrapper defect rather than a
    host/runtime defect: the packaged runtime report arrived after the original
    timeout window, which falsely marked the pass failed
  - the wrapper was then hardened with a bounded windowed-only runtime-report
    grace window, and the maintained bridge-assisted rerun checked in:
    `docs/generated/xr/xr_interactive_desktop_task_probe_wmr_override_grace_2026-07-02.json`
    and
    `docs/generated/xr/xr_windowed_interactive_desktop_probe_wmr_override_grace_2026-07-02.json`
  - that corrected rerun now proves:
    - Session `1`: reached
    - `openXrRuntimeSource`: `environment-override`
    - `openXrActiveRuntimePresent`: `true`
    - packaged runtime report result: `passed`
    - packaged proof status: `pending-hmd-session-observation`
    - `bHeadMountedDisplayConnected`: `false`
    - `bHeadMountedDisplayEnabled`: `false`
    - observed controller input: none
- operational reading after the override plus grace continuation:
  - the reverse-SSH lane plus first-party desktop bridge is now sufficient to
    launch a real Session `1` windowed XR proof without relying on a machine-
    wide `ActiveRuntime` registry entry
  - the remaining live blockers are now the actual physical headset-session
    and controller-input observations, not the launcher bridge and not runtime
    manifest resolution
- canonical local Windows desktop command for that remaining gate is still:

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File C:\HyperTwist_worktrees\phase10validate\scripts\Invoke-HyperTwistXrWindowedObservation.ps1 -PackageRoot C:\HyperTwist_worktrees\phase10validate_packaged_xr_20260702_rebuild
```

- canonical Session `0` bridge-assisted command shape is now:
  without override:

```powershell
& 'C:\HyperTwist_worktrees\phase10validate\scripts\Invoke-HyperTwistInteractiveDesktopTask.ps1' -InlineCommand "& 'C:\HyperTwist_worktrees\phase10validate\scripts\Invoke-HyperTwistXrWindowedObservation.ps1' -PackageRoot 'C:\HyperTwist_worktrees\phase10validate_packaged_xr_20260702_rebuild'"
```

- canonical Session `0` bridge-assisted command shape with bounded runtime
  override is now:

```powershell
& 'C:\HyperTwist_worktrees\phase10validate\scripts\Invoke-HyperTwistInteractiveDesktopTask.ps1' -InlineCommand "& 'C:\HyperTwist_worktrees\phase10validate\scripts\Invoke-HyperTwistXrWindowedObservation.ps1' -PackageRoot 'C:\HyperTwist_worktrees\phase10validate_packaged_xr_20260702_rebuild' -OpenXrRuntimePathOverride 'C:\Windows\System32\MixedRealityRuntime.json'"
```

- that local desktop run writes the aggregate live-observation report beneath:
  `C:\HyperTwist_worktrees\phase10validate_packaged_xr_20260702_rebuild\validation\windowed-live\`

## Addendum - 2026-06-13 (Phase 9B Unreal-native media-export proof)

Live follow-up on `2026-06-13` established these additional facts:

- the primary `localhost:22022` lane remained healthy for the current
  classic-cube media-export proof
- the validated route again used the isolated Windows tree
  `C:\HyperTwist_worktrees\phase10validate`
- the authoritative replay-capture sequence asset
  `LS_HyperTwist_ClassicReplayCapture.uasset` was authored there through
  `scripts\hypertwist_author_classic_cube_export_assets.py`
- the authoring leg required `-NullRHI` on the reverse-SSH lane to avoid the
  detached-session swapchain crash while still saving the sequence asset
- the real `MovieRenderQueue` render leg required `-RenderOffScreen`; without
  it, the remote `UnrealEditor-Cmd` render process failed on the same lane with
  `CreateSwapChainResult failed with error DXGI_ERROR_NOT_CURRENTLY_AVAILABLE`
- the first successful offscreen render still surfaced a real timing mismatch:
  the authored sequence display rate was `60 fps` while the export plan and
  custom end frame were computed at `30 fps`, which truncated the first MP4 to
  `43` frames and `1.4333 s`
- aligning the authored sequence display rate to `30 fps` repaired that timing
  mismatch on the next proof pass
- the final proof then produced all three canonical media artifacts plus the
  aggregate report:
  - MP4: `C:\HyperTwist_worktrees\phase10validate\Saved\MediaExport\ClassicCube\video\classic-cube-classic-cube-integration-replay.mp4`
  - still: `C:\HyperTwist_worktrees\phase10validate\Saved\MediaExport\ClassicCube\still\classic-cube-classic-cube-integration-replay-still.png`
  - share card: `C:\HyperTwist_worktrees\phase10validate\Saved\MediaExport\ClassicCube\classic-cube-classic-cube-integration-replay-share.png`
  - aggregate report:
    `C:\HyperTwist_worktrees\phase10validate\Saved\MediaExport\ClassicCube\validation\classic-cube-classic-cube-integration-replay-report.json`
- post-proof sanity on the exported MP4 confirmed a real `H.264` stream at
  `1280x720`, `30 fps`, `85` frames, and `2.8333 s`

Operational rules reinforced by this proof:

- on the reverse-SSH headless Windows lane, split replay-export validation into
  two explicit phases: asset authoring with `-NullRHI`, then real
  `MovieRenderQueue` rendering with `-RenderOffScreen`
- when a replay-export end frame is computed from replay duration plus tail at
  a target output frame rate, keep the authored `LevelSequence` display rate
  aligned with that same frame rate or compute the end frame in sequence-rate
  units instead of output-rate units
- when the export helper reports success, do one lightweight media sanity check
  on the canonical MP4 rather than trusting file existence alone; current proof
  used `ffprobe` to confirm codec, resolution, frame count, and duration
- when the refreshed reverse-SSH Windows lane only has about `1.2 GB` of free
  physical memory and the host is still carrying large resident
  `chrome.exe` / `Code.exe` workloads, expect UnrealBuildTool to fall back to
  one active compiler worker; that is a slow-but-healthy memory-pressure
  condition, not by itself proof of tunnel corruption or a looping build
- when a future session needs a short bounded PowerShell diagnostic over the
  reverse-SSH lane, prefer
  `scripts/run-hypertwist-remote-windows-powershell.sh` over ad hoc nested
  shell quoting; the wrapper was re-proved on `2026-06-23` against the live
  `22022` lane with `ComputerName=DESKTOP-KS3VGHU`
- when a future session needs a focused `UnrealEditor-Cmd` automation rerun on
  the maintained Windows lane, prefer
  `scripts/run-hypertwist-remote-unreal-automation.sh`; its generated command
  shape was dry-run-validated on `2026-06-23` for
  `HyperTwist.FirstParty.Skill` before the next live post-build invocation
- when that future session instead needs a short ordered batch of those focused
  automation reruns, prefer
  `scripts/run-hypertwist-remote-unreal-automation-sequence.sh`; its generated
  command shape was dry-run-validated on `2026-06-23`

Additional `2026-06-23` lane truth:

- the primary tunnel on `localhost:22022` remained healthy for a same-lane
  skill-memory repair continuation
- the isolated Windows build root again stayed
  `C:\HyperTwist_worktrees\phase10validate`
- a safe narrow-sync route was re-proved from the Windows side by using the
  remote host's own `scp.exe` plus the retained VPS key to pull changed files
  directly from `root@212.227.13.220` into that isolated worktree
- that route is now suitable when the active lane needs only a few touched
  Unreal files refreshed in the maintained validation tree and a broad
  reverse-sync would be wasteful or riskier than necessary
- after that narrow sync, the authoritative incremental Unreal editor rebuild
  succeeded and the widened `S3` skill-memory automation packet finished with
  all `9` expected `Skill-S3-Full-PostFixture-*` reports present and green

## Addendum - 2026-06-29 (exact-source browser rerun and package refresh)

Live follow-up on `2026-06-29` established these additional facts:

- the primary tunnel on `localhost:22022` remained healthy for the current
  exact-source continuation
- the repo-local encoded PowerShell helper again returned the live Windows
  identity over that lane:
  - `whoami=desktop-ks3vghu\anthracite ace`
  - `hostname=DESKTOP-KS3VGHU`
  - working directory: `C:\Users\Anthracite Ace`
- the maintained validation root again stayed
  `C:\HyperTwist_worktrees\phase10validate`
- the canonical remote editor-build helper
  `scripts/run-hypertwist-remote-unreal-build.sh` completed successfully on
  that maintained root with:
  - `Target is up to date`
  - `Result: Succeeded`
  - UnrealBuildTool `Total execution time: 3.40 seconds`
- the same primary lane then exported a fresh exact-source browser report via:
  - `scripts/run-hypertwist-remote-unreal-automation.sh --filter HyperTwist.Browser --report-name Browser-ExactSource-20260629`
  - resulting report path:
    `C:\HyperTwist_worktrees\phase10validate\UnrealHyperTwist\Saved\AutomationReports\Browser-ExactSource-20260629\index.json`
  - report result:
    - `26` `HyperTwist.Browser.*` tests succeeded
    - `0` failed
    - `0` not run
- the same lane then revalidated the maintained higher-dimensional package
  helper on that current source state through
  `scripts\Invoke-HyperTwistHigherDimensionalPackage.ps1`, again in
  `-SkipBuild` mode against the existing receipt, with:
  - `BuildCookRun time: 64.78 s`
  - archive output:
    `C:\HyperTwist_worktrees\phase10validate_packaged_phase6c_higherdim_refresh_20260629`
  - successful packaged smoke boots for both:
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_Magic120CellTraining`
    - `/Game/HyperTwistTraining/Maps/L_HyperTwist_MagicCube5DTraining`
- the refreshed package report was then pulled back into the repo through the
  repo-local SHA-256-verified file-pull helper
  `scripts/run-hypertwist-remote-windows-file-pull.sh`, and the public
  packaged-summary artifact was re-rendered locally from that refreshed report

Operational reading after this follow-up:

- the current repo-local wrappers are sufficient for healthy same-lane
  identity check, editor build, browser automation, package refresh, and
  report pullback without reopening the older brittle manual quoting path
- the maintained `phase10validate` lane continues to support exact-source
  native proof plus public-summary propagation on the same day without needing
  a separate ad hoc Windows repo state
- the primary `localhost:22022` lane remains the correct current path unless a
  later live probe proves it stale again

## Addendum - 2026-06-03 (stale-listener recovery)

Live follow-up on `2026-06-03` established this additional operational rule:

- a TCP-listening `22022` socket is not sufficient proof of a healthy tunnel
- a healthy lane requires SSH banner exchange and password-auth success
- when a stale-listener condition appears, use a split sequence:
  1. smoke login + `whoami`/`hostname`
  2. canonical Unreal build with explicit result marker capture

The fallback `22023` lane passed smoke-auth checks during this recovery flow.

## Maintenance rule

If any of these change:

- reverse port
- Windows host identity
- build command
- auth posture

update this note and the linked governing docs in the same turn.

## Addendum - 2026-06-30 (maintained exact-source recovery closed on the live root)

Later same-day follow-up on `2026-06-30` established these additional facts:

- the primary reverse-SSH tunnel on `localhost:22022` remained healthy for the
  maintained-lane recovery itself; fallback root `C:\HTpp` was no longer the
  latest authority once the live host state was repaired
- the maintained Windows validation root remained
  `C:\HyperTwist_worktrees\phase10validate`
- the earlier host-side lock on
  `HyperTwistTrainingRepositoryLibrary.cpp` was traced to stale Windows-side
  remote-sync writer trees still holding the file open; after stopping only
  those stale writer processes, a bounded exclusive-open retest on the same
  path succeeded
- the current exact-source continuation then repaired a real local compile seam
  in `HyperTwistTrainingRepositoryLibrary.cpp` by scoping the
  `Completed` queue-summary branch correctly and replacing the deprecated
  `RightChopInline(..., false)` overload with `EAllowShrinking::No`
- the same maintained root then exposed a truthful parity miss rather than a
  source failure: it lacked the split coach-repository ownership files
  `HyperTwistTrainingRepositoryLibraryCoachWorkflow.cpp` and
  `HyperTwistTrainingRepositoryLibraryCoachSummaries.cpp`
- the repo-local wrapper
  `scripts/run-hypertwist-remote-exact-source-browser-package-refresh.sh` now
  carries that current bounded training-repository ownership set in its default
  exact-source sync list, so future maintained-lane refreshes do not rely on
  ad hoc manual `--sync-file` recovery for this family
- after that maintained-root parity repair, the same exact-source wrapper
  completed end-to-end on `C:\HyperTwist_worktrees\phase10validate` with:
  - editor build `Result: Succeeded`
  - pulled browser report
    `docs/generated/browser_automation/Browser-ExactSource-20260630maintained/index.json`
  - `26` browser tests succeeded
  - `0` failed
  - `0` not run
  - `0` in process
  - refreshed higher-dimensional package proof pulled back into
    `docs/generated/higher_dimensional_training_maps/phase6c_dedicated_family_package_validation_report.json`
  - refreshed public summary re-rendered into
    `website/src/shared/generated/windows-package-validation-summary.json`
- the maintained higher-dimensional package refresh archive was written to:
  `C:\HyperTwist_worktrees\phase10validate_packaged_phase6c_higherdim_refresh_20260630maintained`
- packaged smoke validation succeeded again for both dedicated-family maps on
  that maintained package set:
  - `/Game/HyperTwistTraining/Maps/L_HyperTwist_Magic120CellTraining`
  - `/Game/HyperTwistTraining/Maps/L_HyperTwist_MagicCube5DTraining`

Operational reading after this follow-up:

- the live maintained `phase10validate` root is again the latest exact-source
  authority for build, browser automation, and higher-dimensional package
  proof
- the earlier `C:\HTpp` fallback proof remains valid historical evidence, but
  it is no longer the newest same-day authority for this lane
- when a maintained-root failure shifts from host lock to missing split source
  ownership, prefer bounded hash-verified file sync and same-root rerun over
  reopening a broader fallback narrative
