# 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
```

## 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
```

## 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 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-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.
