# HyperTwist Reverse-SSH Live Connection Facts

Date: `2026-06-04`

Status: `verified live`

## Purpose

This note records the latest live connection facts for the Windows reverse-SSH
lane used by HyperTwist AI sessions and Windows Unreal validation.

It exists to preserve the current tunnel reality separately from the broader
verification doctrine and separately from the sensitive runbook.

## Governing authorities

- `C:\HyperTwist\docs\ops\HYPERTWIST_UNREAL_BUILD_VALIDATION_REQUIREMENT_2026-06-01.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_WINDOWS_BUILD_LANE_VERIFICATION_2026-06-01.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_REVERSE_SSH_AUTH_MODE_MISMATCH_AND_RECOVERY_2026-06-02.md`
- `C:\HyperTwist\docs\ops\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK_VPS_12_24_720_UBUNTU_24_04.md`

Secret material stays in the sensitive runbook only.

## Current live facts

- VPS host: `212.227.13.220`
- active reverse listener:
  - `127.0.0.1:22022`
  - `[::1]:22022`
- binding owner: `sshd`
- latest absent listeners in the same probe:
  - `22023`
  - `22024`
- current accepted Windows shell path remains the reverse tunnel behind
  `localhost:22022`

Operational reading:

- the lane is loopback-only on the VPS by design
- the correct bridge target is `localhost:22022`
- public `212.227.13.220:22022` is not the intended path for this workflow

## Current proven login shape

The latest live session re-confirmed:

- Windows SSH principal usable from the VPS side:
  - `anthracite ace`
- explicit Windows identity resolution:
  - `whoami` -> `desktop-ks3vghu\anthracite ace`
  - `hostname` -> `DESKTOP-KS3VGHU`

The still-current password remains documented only in the sensitive runbook.

## Current non-secret command family

Listener classification:

```bash
ss -ltnp | rg ':22022|:22023|:22024'
```

Primary VPS-side smoke command:

```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -p 22022 -l "anthracite ace" localhost whoami
```

Current interpretation:

- if `22022` works, use it
- if `22022` fails banner exchange or auth, classify before widening
- if `22023` is not visibly listening, do not assume fallback availability;
  re-establish it first
- if Linux-side tar deltas are being unpacked into an isolated Windows worktree,
  prefer `tar -xf ... -m` so UHT/generated-header outputs are not accidentally
  left stale behind preserved source mtimes
- on the current Windows host, treat
  `C:\HyperTwist_worktrees\phase10validate` as the maintained authoritative
  reverse-SSH validation root; `C:\HyperTwist` is currently only a partial
  mirror and should not be assumed to contain a usable authoritative
  `.uproject`

## Loopback-only meaning

Loopback-only is the correct secure shape for this lane.

It is suitable for:

- VPS-side Windows Unreal builds
- VPS-side reverse-sync and downsync flows
- Linux-side AI sessions that hop through the VPS into the Windows shell

It is not meant to provide arbitrary public direct access to the Windows shell
listener.

## Addendum - 2026-06-12 (fallback lane closure pass)

Live follow-up on `2026-06-12` established these current additions:

- the fallback listener behind `localhost:22023` was healthy again for the
  current package-closure session
- live `whoami` over that fallback lane again returned
  `desktop-ks3vghu\anthracite ace`
- the lane carried the recovered isolated Windows worktree
  `C:\HyperTwist_worktrees\phase3to5` for final classic-cube map authoring,
  automation, build, and packaged validation
- the same fallback lane packaged and smoke-launched both
  `L_HyperTwist_ClassicTraining` and `L_HyperTwist_FollowAlongTraining`

Current interpretation after this follow-up:

- keep `localhost` as the canonical bridge target because the listener family is
  still loopback-only by design
- keep treating `22022` and `22023` availability as live facts, not as stable
  assumptions carried forward without re-check

## Addendum - 2026-06-12 (Phase 6A validation pass)

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

- the primary `22022` lane was not healthy for the current `Phase 6A` pass,
  while the fallback listener behind `localhost:22023` was healthy
- live `whoami` over that fallback lane again returned
  `desktop-ks3vghu\anthracite ace`
- the lane carried the isolated Windows validation tree
  `C:\Users\Anthracite Ace\HyperTwist_phase6a_validate`
- `Build.bat` for `UnrealHyperTwistEditor` succeeded again there after the final
  `Phase 6A` quality-tightening patch
- targeted `UnrealEditor-Cmd` automation also succeeded there for:
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.CellFirstProjectionContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.CellTurnContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6A.SceneContextContract`

Current interpretation after this follow-up:

- keep treating `22022` and `22023` as live facts that must be rechecked rather
  than assumed from an earlier packet
- the fallback `localhost:22023` lane remains a valid HyperTwist Windows Unreal
  build and automation bridge when it is explicitly reverified live

## Addendum - 2026-06-12 (Phase 6B validation pass)

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

- the primary `22022` lane was not healthy for the current `Phase 6B` pass,
  while the fallback listener behind `localhost:22023` was healthy
- live `whoami` over that fallback lane again returned
  `desktop-ks3vghu\anthracite ace`
- the lane carried the isolated Windows validation tree
  `C:\Users\Anthracite Ace\HyperTwist_phase6a_validate`
- `Build.bat` for `UnrealHyperTwistEditor` succeeded there after the `Phase 6B`
  files were reverse-synced into the isolated tree
- targeted `UnrealEditor-Cmd` automation also succeeded there for:
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.SceneContextContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.SliceTurnContract`
  - `HyperTwist.CleanRoom.HactarCE.Phase6B.VisibleProjectionContract`
- the project log closed that run with
  `**** TestExit: Automation Test Queue Empty ****`

Current interpretation after this follow-up:

- keep treating `22022` and `22023` as live facts that must be rechecked rather
  than assumed from an earlier packet
- the fallback `localhost:22023` lane remains a valid HyperTwist Windows Unreal
  build and automation bridge for bounded `Phase 6B` runtime validation when it
  is explicitly reverified live

## Addendum - 2026-06-12 (primary-lane replay and validation closure pass)

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

- both loopback listeners behind `localhost:22022` and `localhost:22023` were
  visibly present on the VPS in the same session
- the primary `22022` lane was healthy again and was used as the actual
  validation bridge for the current replay/leaderboard packet
- live `whoami` over that primary lane again returned
  `desktop-ks3vghu\anthracite ace`
- the lane carried the isolated Windows validation tree
  `C:\HyperTwist_worktrees\phase10validate`
- the final post-patch incremental `Build.bat` pass succeeded there with
  UnrealBuildTool `Total execution time: 590.90 seconds`
- the full `HyperTwist.Integration.ClassicCube` suite also succeeded there with
  `**** TEST COMPLETE. EXIT CODE: 0 ****`
- a superseded package attempt on that same worktree left stale
  `AutomationTool` / `UnrealBuildTool` `dotnet.exe` processes behind; clearing
  only those stale toolchain processes restored the lane cleanly

Current interpretation after this follow-up:

- keep preferring `localhost:22022` when it is actually healthy, even if
  `22023` is also visible in the same probe
- keep treating stale build-tool ownership on the isolated Windows worktree as
  a recoverable lane artifact, not as proof that the tunnel itself is broken

## Addendum - 2026-06-13 (primary-lane package closure pass)

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

- the primary `22022` lane was healthy for the current packaged validation pass
- the lane again carried the isolated Windows validation tree
  `C:\HyperTwist_worktrees\phase10validate`
- the current package closure required explicit commandlet/unattended guards in
  both the legacy `UnrealMCP` editor-toolbar path and the maintained
  `UnrealMCPChong` local bridge startup path
- after those guards landed, `BuildCookRun` succeeded there with `ExitCode=0`
  and `BuildCookRun time: 164.59 s`
- archive output was written to
  `C:\HyperTwist_worktrees\phase10validate_packaged`
- packaged smoke launches succeeded for both
  `L_HyperTwist_ClassicTraining` and `L_HyperTwist_FollowAlongTraining`

Current interpretation after this follow-up:

- keep treating `localhost:22022` as the preferred bridge when it is actually
  healthy for both integration and package proof, not only editor-build proof
- keep treating commandlet-safe plugin startup as a live packaging concern when
  editor-side bridge plugins remain present in the project

## Addendum - 2026-06-13 (primary-lane Phase 6C activation validation pass)

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

- the same primary `22022` lane was also healthy for the current `Phase 6C`
  higher-dimensional activation pass
- the lane again carried the isolated Windows validation tree
  `C:\HyperTwist_worktrees\phase10validate`
- because the slice introduced a new translation unit, the editor makefile was
  invalidated and a fresh `Build.bat` pass was required there
- that `Build.bat` run still succeeded with UnrealBuildTool `Total execution
  time: 2829.95 seconds`
- targeted `UnrealEditor-Cmd` automation then found `4` tests under
  `HyperTwist.FirstParty.HigherDimensional.Phase6C`
- all `4` tests succeeded, including the real training-run bridge check, and
  the run closed with `**** TEST COMPLETE. EXIT CODE: 0 ****`

Current interpretation after this follow-up:

- keep treating `localhost:22022` as sufficient for owned higher-dimensional
  compile-plus-automation proof as long as the lane passes a fresh login check
- for a clean-room activation-catalog slice, do not stop at direct profile
  lookup tests; also prove that real training-run puzzle-definition resolution
  follows the same lane

## Addendum - 2026-06-18 (primary-lane Phase 6C continuation recovery pass)

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

- the same primary `22022` lane remained healthy after an interrupted
  continuation run and was directly re-proved through a fresh Windows login
- the lane again carried the isolated Windows validation tree
  `C:\HyperTwist_worktrees\phase10validate`
- the changed `Phase 6C` subsystem/test files were hash-matched back into that
  isolated worktree before the final proof pass
- the cleaned `Build.bat` run still succeeded with UnrealBuildTool `Total
  execution time: 124.81 seconds`
- targeted `UnrealEditor-Cmd` automation then found `8` tests under
  `HyperTwist.FirstParty.HigherDimensional.Phase6C`
- all `8` tests succeeded, including `LaunchCatalog`, `ViewContextCatalog`,
  `LaunchExecution`, and `RunStateActivationResolution`, and the run closed
  with `**** TEST COMPLETE. EXIT CODE: 0 ****`
- the long quiet `LaunchExecution` interval can legitimately produce controller
  output such as `Ignoring very large delta of 499.13 seconds` even when the
  lane is healthy, so that interval is now treated as expected behavior for
  this slice rather than a default stall/corruption signal

## Maintenance rule

If the live listener set, accepted login shape, or command family changes,
update this note and the linked governing docs in the same turn.
