Finalize VPS remote development registration plan

docs/ops/HYPERTWIST_REMOTE_DEVELOPMENT_REGISTRATION_PLAN_JETBRAINS_GATEWAY_2026_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md

@@ -16,6 +16,8 @@ The following is already true:
 
 - the preferred remote-development login is the additive `dev` user, not
   `root`
+- `dev` is in `sudo` and `docker`, so normal development and container
+  operations do not require a root IDE session
 - local SSH alias exists:
   - `scriptoriumai-new-dev`
 - local JetBrains/Gateway-compatible key path:
@@ -27,27 +29,45 @@ The following is already true:
 - the VPS currently exposes:
   - `12` vCPU
   - `23 GiB` RAM
-  - `0` swap
-- `cmake` and `g++` are already present on the host
+  - `16 GiB` swap
+- the VPS now has the following verified toolchains available for `dev`:
+  - `cmake`, `ninja`, `g++`, `clang`, `clangd`, `clang-format`,
+    `clang-tidy`, `gdb`, `lldb`, `ccache`
+  - `node 22`, `npm 10`, `pnpm`, `yarn`, `bun`
+  - `python3`, `pipx`, `uv`
+  - `rust`, `cargo`, `rust-analyzer`, `clippy`, `rustfmt`
+  - `go 1.22`
+  - `.NET SDK 8.0` and `.NET SDK 10.0`
+  - `git-lfs`
+  - `Java 21`
+  - `PowerShell 7`
+  - `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
 
-## Current host gaps that still matter
+## Why the IDE session should use `dev`, not `root`
 
-The following host-side toolchains are currently missing:
+This is an operational rule, not a suggestion.
 
-- `node`
-- `npm`
-- `git-lfs`
-- `dotnet`
-- swap
+Reasons:
 
-Operational reading:
+- JetBrains Gateway installs backend files, caches, logs, and indices into the
+  remote user profile; that should live under `/home/dev`, not under
+  `/root`
+- opening repos as `root` would create root-owned files inside the working
+  trees and introduce avoidable permission churn
+- `dev` already has the practical rights needed for normal work:
+  - `sudo`
+  - `docker`
+- `root` remains available as the recovery and admin anchor, but it should not
+  be the day-to-day IDE user
 
-- these gaps do **not** block JetBrains Gateway from registering a remote IDE
-  session
-- they **do** block or weaken real development on repos that rely on those
-  toolchains or pre-push hooks
+Operational boundary:
+
+- use `dev` for JetBrains Gateway, Rider, terminal development, and Visual
+  Studio remote registration
+- use `root` only for system administration, package installation, certbot,
+  service repair, and recovery work
 
 ## Why JetBrains Gateway is the primary lane
 
@@ -66,6 +86,18 @@ Relevant product facts:
 
 This matches the intended posture for this VPS.
 
+Operational consequence for resource pressure:
+
+- the JetBrains backend, indexes, caches, code analysis, language services, and
+  most long-lived IDE memory pressure move onto the VPS
+- the laptop still renders the client UI and keeps some local memory for the
+  frontend, but the heavy backend process is remote
+- when builds, package restores, code generation, and terminal work are run
+  inside the remote session, that CPU and RAM pressure also stays on the VPS
+
+So yes: JetBrains Gateway is the lane that meaningfully offloads RAM pressure to
+the VPS.
+
 Official references:
 
 - JetBrains Rider remote development overview:
@@ -89,12 +121,18 @@ Current Microsoft-documented behavior:
 - for remote .NET Linux debugging, Visual Studio attaches to a process over SSH
   and expects the relevant local source and symbols flow
 
+That means the local Visual Studio IDE remains the primary frontend and keeps
+its own solution state, UI memory, extensions, and language-service load on the
+laptop. The remote host is mainly a target for build/debug operations, not the
+persistent IDE backend.
+
 So Visual Studio 2022 is useful as:
 
 - a backup Linux C++ connection lane
 - a backup remote debugger lane
 
-It is **not** the preferred thin-client day-to-day environment for this VPS.
+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.
 
 Official references:
 
@@ -131,15 +169,12 @@ Reason:
 
 ### Phase 1: host preflight
 
-Confirm or complete the following before daily use:
+The host preflight is now complete.
 
 1. keep using the `dev` user for IDE sessions
 2. leave `root` as recovery/admin only
-3. add swap on the VPS
-4. install missing repo toolchains that matter to the active project:
-   - `node` / `npm`
-   - `git-lfs`
-   - `dotnet`
+3. keep the remote source tree under `/home/dev/src`
+4. leave the Forgejo push path on the server-side repos on SSH
 
 ### Phase 2: local client preflight
 
@@ -244,13 +279,70 @@ Visual Studio's Linux C++ path copies source to the remote Linux machine for
 remote targets. That is acceptable as a backup workflow, but it is not the same
 as the Gateway thin-client model.
 
+## Server-side Git auth and remote topology that were changed
+
+The following server-side changes were made to support remote development under
+`dev`:
+
+- local SSH alias added:
+  - `scriptoriumai-new-dev`
+- local Visual Studio-compatible private key added:
+  - `C:\ScriptoriumAI\ops\ssh\visualstudio_vps_ecdsa`
+- server-side Forgejo SSH key added for `dev`:
+  - `/home/dev/.ssh/id_ed25519_forgejo`
+- server-side working root seeded under:
+  - `/home/dev/src`
+- the following server-side repo `origin` remotes were changed from HTTPS to
+  SSH:
+  - `/home/dev/src/HyperTwist`
+  - `/home/dev/src/ScriptoriumAI`
+  - `/home/dev/src/VerticalTension`
+  - `/home/dev/src/NyxOS`
+  - `/home/dev/src/VectorShell`
+
+Authoritative SSH host used by those repos:
+
+- `git@git.scriptoriumai.io:...` on SSH port `2222`
+
+Important boundary:
+
+- these changes were made to the VPS-side working copies under `/home/dev/src`
+- this note does **not** assume that every local laptop repo was changed in the
+  same way
+
+## Retreat path if development returns to local-first
+
+If the operator later decides to retreat from server-first remote development,
+the clean reversal sequence is:
+
+1. pull or mirror any final server-side commits back to the authoritative local
+   laptop copies first
+2. disable or uninstall the reverse-sync scheduled task if it is no longer
+   wanted:
+   - `VPS-Remote-Dev-Reverse-Sync`
+3. stop using JetBrains Gateway / Visual Studio against the VPS for daily work
+4. for each server-side repo that should revert to HTTPS, run on the VPS:
+   - `git remote set-url origin https://git.scriptoriumai.io/<owner>/<repo>.git`
+5. if server-side SSH push auth is no longer wanted, remove:
+   - the `dev-vps-forgejo-212-227-13-220` key entry from the Forgejo account
+   - `/home/dev/.ssh/id_ed25519_forgejo`
+   - local alias `scriptoriumai-new-dev` from `~/.ssh/config`
+   - local key `C:\ScriptoriumAI\ops\ssh\visualstudio_vps_ecdsa` if the Visual
+     Studio path is also being retired
+6. leave `root` and `dev` accounts intact unless there is an explicit later
+   account-hardening operation
+
+Practical note:
+
+- the safest retreat is to switch workflow authority back to the laptop first
+  and only then reduce the VPS-side convenience wiring
+
 ## Immediate next clean implementation slice
 
-To make remote development genuinely ready rather than merely connectable, the
-next implementation slice should be:
+The next clean slice is no longer provisioning. It is registration and
+validation:
 
-1. add swap on the VPS
-2. install `node`, `npm`, `git-lfs`, and the required `dotnet` SDK/runtime
-3. register `/home/dev/src/VectorShell` in JetBrains Gateway
-4. validate one real fetch/edit/build cycle
-5. only then widen into the other repos
+1. register `/home/dev/src/VectorShell` in JetBrains Gateway
+2. validate one real fetch/edit/build cycle
+3. if stable, register `HyperTwist`
+4. then widen into `ScriptoriumAI`, `NyxOS`, and `VerticalTension`

docs/ops/HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md

@@ -51,10 +51,23 @@ Current additive users on the new VPS:
 
 Current role:
 
-- both are additive convenience accounts for remote development and service
-  operations
+- `dev` is the default remote-development user
+- `deploy` is an additive service-operations helper
 - neither replaces `root` as the recovery anchor for this lane
 
+Current privilege state:
+
+- `dev` is in `sudo`
+- `dev` is in `docker`
+- `deploy` is in `sudo`
+- `deploy` is in `docker`
+
+Operational rule:
+
+- IDE sessions, terminal development, and remote Git work should use `dev`
+- `root` stays reserved for admin, certbot, package-management, and recovery
+  work
+
 ## Current public HTTPS state
 
 As of `2026-05-30`, these hostnames are live on the new VPS with working public
@@ -140,6 +153,30 @@ Current seeded top-level trees:
 - `Workspaces`
 - `visual_studio_solutions/multi_project`
 
+Current remote-development host profile:
+
+- `12` vCPU
+- `23 GiB` RAM
+- `16 GiB` swap
+- verified toolchains under `dev`:
+  - native/C++: `cmake`, `ninja`, `g++`, `clang`, `clangd`, `clang-format`,
+    `clang-tidy`, `gdb`, `lldb`, `ccache`
+  - JavaScript/TypeScript: `node 22`, `npm 10`, `pnpm`, `yarn`, `bun`
+  - Python: `python3`, `pipx`, `uv`
+  - Rust: `rust`, `cargo`, `rust-analyzer`, `clippy`, `rustfmt`
+  - Go: `go 1.22`
+  - .NET: SDK `8.0` and `10.0`
+  - supporting CLI: `git-lfs`, `Java 21`, `PowerShell 7`, `jq`, `ripgrep`,
+    `fd`, `tmux`, `htop`
+
+Current remote Git auth posture for server-side worktrees:
+
+- `/home/dev/src` main repos now use Forgejo SSH remotes under the `dev` user
+- the previous VPS-side HTTPS credential-prompt posture was replaced with SSH
+  key-based Git auth for the server 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
+
 ## Reverse-sync lane
 
 The local reverse-sync scaffolding now exists here: