From 5aafbb47a4be592c0396dc2b6f8e9a6cc6424542 Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Sun, 31 May 2026 00:05:16 +0200 Subject: [PATCH] Document VS Code remote workflow and SSH keepalive posture --- ...6_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md | 200 +++++++++++++++++- ...TOVER_OPERATIONAL_INVARIANTS_2026-05-30.md | 20 ++ 2 files changed, 212 insertions(+), 8 deletions(-) diff --git a/docs/ops/HYPERTWIST_REMOTE_DEVELOPMENT_REGISTRATION_PLAN_JETBRAINS_GATEWAY_2026_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md b/docs/ops/HYPERTWIST_REMOTE_DEVELOPMENT_REGISTRATION_PLAN_JETBRAINS_GATEWAY_2026_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md index 3a3746e..acac606 100644 --- a/docs/ops/HYPERTWIST_REMOTE_DEVELOPMENT_REGISTRATION_PLAN_JETBRAINS_GATEWAY_2026_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md +++ b/docs/ops/HYPERTWIST_REMOTE_DEVELOPMENT_REGISTRATION_PLAN_JETBRAINS_GATEWAY_2026_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md @@ -10,6 +10,13 @@ the new VPS at `212.227.13.220`. It reflects the host state that was verified during the post-cutover sequence. It is not a generic remote-development checklist. +As of `2026-05-31`, the practical default lane has widened: + +- `VS Code Remote-SSH` is the primary day-to-day lane for agent-first work +- `JetBrains Gateway / Rider` remains available when a true remote IDE backend + is specifically wanted +- `Visual Studio 2022` remains the backup lane + ## Current prepared state The following is already true: @@ -44,6 +51,27 @@ The following is already true: - `docker`, `docker compose`, `jq`, `ripgrep`, `fd`, `tmux`, `htop` - server-side Forgejo push authentication for `/home/dev/src` main repos is now wired through SSH instead of HTTPS credential prompts +- `VS Code Remote-SSH` connection was proven against the new VPS +- remote workspace folders were opened successfully in VS Code without needing a + local source copy + +## Current practical primary lane + +Because the operator's current workflow is agent-first rather than +editor-first, the practical default is now: + +- use `VS Code Remote-SSH` for normal day-to-day remote work +- keep `JetBrains Gateway / Rider` optional +- keep `Visual Studio 2022` as targeted backup access + +Reason: + +- the critical requirement is remote file access plus remote command execution, + not local IDE semantic navigation +- VS Code Remote-SSH already proved easy to connect and easy to extend with + remote-installed extensions +- the heavier build/test/tooling work can still run on the VPS when launched + from the remote VS Code window ## Why the IDE session should use `dev`, not `root` @@ -66,11 +94,62 @@ Operational boundary: - use `dev` for JetBrains Gateway, Rider, terminal development, and Visual Studio remote registration +- use `dev` for `VS Code Remote-SSH` sessions as well - use `root` only for system administration, package installation, certbot, service repair, and recovery work +## Canonical remote folder roots + +For `VS Code Remote-SSH`, the authoritative open targets are the remote folder +roots, not the solution files. + +Current canonical roots: + +- `/home/dev/src/VectorShell` +- `/home/dev/src/HyperTwist` +- `/home/dev/src/ScriptoriumAI` +- `/home/dev/src/NyxOS` +- `/home/dev/src/VerticalTension` + +Additional optional roots: + +- `/home/dev/src/visual_studio_solutions/multi_project` +- `/home/dev/src/Workspaces` + +Current notable solution/package entry surfaces: + +- `VectorShell` + - root: `/home/dev/src/VectorShell` + - solution: `/home/dev/src/VectorShell/VectorShell.sln` +- `HyperTwist` + - root: `/home/dev/src/HyperTwist` + - solution: `/home/dev/src/HyperTwist/HyperTwist.sln` +- `ScriptoriumAI` + - root: `/home/dev/src/ScriptoriumAI` + - solution: `/home/dev/src/ScriptoriumAI/ScriptoriumAI.sln` +- `NyxOS` + - root: `/home/dev/src/NyxOS` + - package root: `/home/dev/src/NyxOS/package.json` +- `VerticalTension` + - root: `/home/dev/src/VerticalTension` + - package root: `/home/dev/src/VerticalTension/package.json` +- `multi_project` + - root: `/home/dev/src/visual_studio_solutions/multi_project` + - solution: `/home/dev/src/visual_studio_solutions/multi_project/multi_project.sln` + +Operational rule: + +- do **not** create or convert more repos into `.sln` form merely for + `VS Code Remote-SSH` +- keep the existing solutions where they already exist +- treat folder roots as the primary open targets in VS Code + ## Why JetBrains Gateway is the primary lane +This section remains technically true about the remote IDE backend model, but it +is no longer the default workflow recommendation for the current operator +posture. + JetBrains' current 2026.1 remote-development model is the correct fit for this VPS. @@ -98,6 +177,11 @@ Operational consequence for resource pressure: So yes: JetBrains Gateway is the lane that meaningfully offloads RAM pressure to the VPS. +But the current practical reading is: + +- `JetBrains Gateway / Rider` is the richer remote IDE lane +- `VS Code Remote-SSH` is the simpler practical default for agent-first work + Official references: - JetBrains Rider remote development overview: @@ -134,6 +218,36 @@ So Visual Studio 2022 is useful as: It is **not** a true thin-client replacement for Gateway, and it is **not** the best path if the goal is to move most IDE RAM pressure away from the laptop. +## Why VS Code Remote-SSH is viable for the current workflow + +For the current operator posture, `VS Code Remote-SSH` is viable because: + +- it installs `VS Code Server` on the remote host +- remote terminals, builds, tests, and most workspace-extension work can run on + the VPS +- the agent window can operate against the remote workspace when the relevant + extension is installed in the remote SSH target +- the local laptop still keeps the VS Code/Electron UI, but the heavier + workspace-side execution can move onto the server + +Operational boundary: + +- this is real offload, but not zero local RAM usage +- if a specific extension is UI-local only, some of its cost remains local +- for the current agent-first workflow, that tradeoff is acceptable and does + not justify forcing every repo into `.sln` form + +Official references: + +- VS Code Remote-SSH: + `https://code.visualstudio.com/docs/remote/ssh` +- VS Code extension host model: + `https://code.visualstudio.com/api/advanced-topics/extension-host` +- VS Code remote extensions: + `https://code.visualstudio.com/api/advanced-topics/remote-extensions` +- VS Code Agents window: + `https://code.visualstudio.com/docs/copilot/agents/agents-window` + Official references: - Connect to your remote Linux system by using Visual Studio: @@ -223,9 +337,53 @@ Validate this exact sequence: After `VectorShell` proves stable: 1. register `HyperTwist` -2. close the toolchain gaps -3. then register `ScriptoriumAI` -4. only then widen into the noisier repos +2. then register `ScriptoriumAI` +3. then register `NyxOS` +4. then register `VerticalTension` + +## VS Code Remote-SSH registration plan + +### Phase 1: local client preflight + +1. install `Remote - SSH` +2. connect using the prepared host alias: + - `scriptoriumai-new-dev` +3. if the host is entered manually by IP instead, use: + - host: `212.227.13.220` + - user: `dev` + - key: `C:\ScriptoriumAI\ops\ssh\scriptorium_vps_ed25519` + +### Phase 2: first remote window + +1. let VS Code install `VS Code Server` on the VPS +2. open the canonical remote folder root: + - `/home/dev/src/VectorShell` +3. add the other canonical roots to the workspace as needed: + - `/home/dev/src/HyperTwist` + - `/home/dev/src/ScriptoriumAI` + - `/home/dev/src/NyxOS` + - `/home/dev/src/VerticalTension` + +### Phase 3: extension placement rule + +1. install agent and development extensions into the remote SSH target when + they need workspace authority +2. confirm the extension is installed under the remote host target, not only in + the local VS Code UI + +### Phase 4: first offload validation + +Validate this exact sequence: + +1. open a remote terminal +2. run: + - `whoami` + - `pwd` + - `cd /home/dev/src/VectorShell` + - `git remote -v` +3. run one safe repo-native command from each active repo when needed +4. confirm the heavy command processes appear on the VPS rather than only on + the laptop ## Visual Studio 2022 backup registration plan @@ -337,12 +495,38 @@ Practical note: - the safest retreat is to switch workflow authority back to the laptop first and only then reduce the VPS-side convenience wiring +## SSH stability note + +Short transient disconnect/reconnect events can still happen if the underlying +network blips, but the current local SSH posture now includes keepalive +protection for the prepared host entries. + +Current local SSH config posture: + +- `ServerAliveInterval 30` +- `ServerAliveCountMax 6` +- `TCPKeepAlive yes` + +Prepared host entries: + +- `scriptoriumai` +- `scriptoriumai-new` +- `scriptoriumai-new-dev` +- direct host entry for `212.227.13.220` + +Operational reading: + +- prefer connecting through `scriptoriumai-new-dev` so the prepared keepalive + settings are definitely used +- immediate reconnect after a brief drop is acceptable during stabilization +- if disconnects become persistent rather than momentary, inspect the network + path before treating the VPS or toolchain as the root cause + ## Immediate next clean implementation slice -The next clean slice is no longer provisioning. It is registration and -validation: +The next clean slice is no longer provisioning. It is offload validation: -1. register `/home/dev/src/VectorShell` in JetBrains Gateway -2. validate one real fetch/edit/build cycle -3. if stable, register `HyperTwist` +1. close `Rider` if it is no longer needed for this lane +2. validate `VS Code Remote-SSH` offload on `/home/dev/src/VectorShell` +3. validate the same lane on `/home/dev/src/HyperTwist` 4. then widen into `ScriptoriumAI`, `NyxOS`, and `VerticalTension` diff --git a/docs/ops/HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md b/docs/ops/HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md index c30eaa5..dcdb8f9 100644 --- a/docs/ops/HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md +++ b/docs/ops/HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md @@ -67,6 +67,8 @@ Operational rule: - IDE sessions, terminal development, and remote Git work should use `dev` - `root` stays reserved for admin, certbot, package-management, and recovery work +- the current practical default remote-development lane is now `VS Code + Remote-SSH` for agent-first work ## Current public HTTPS state @@ -177,6 +179,24 @@ Current remote Git auth posture for server-side worktrees: - if later retreating to local-first development, revert workflow authority to the laptop first and only then unwind the VPS-side SSH convenience wiring +Current local SSH stability posture: + +- prepared host entries: + - `scriptoriumai` + - `scriptoriumai-new` + - `scriptoriumai-new-dev` + - direct host entry for `212.227.13.220` +- keepalive settings: + - `ServerAliveInterval 30` + - `ServerAliveCountMax 6` + - `TCPKeepAlive yes` + +Operational reading: + +- prefer `scriptoriumai-new-dev` for remote development +- short reconnects after transient network blips are acceptable during + stabilization + ## Reverse-sync lane The local reverse-sync scaffolding now exists here: