Document VS Code remote workflow and SSH keepalive posture
This commit is contained in:
axiomlogicnexus
parent
ebe2696006
commit
5aafbb47a4
2 changed files with 212 additions and 8 deletions
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue