From ebe2696006fc72c7d691d7daf37724087a5fc4ac Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Sat, 30 May 2026 21:35:14 +0200 Subject: [PATCH] Finalize VPS remote development registration plan --- ...6_1_2_AND_VISUAL_STUDIO_2022_2026-05-30.md | 148 ++++++++++++++---- ...TOVER_OPERATIONAL_INVARIANTS_2026-05-30.md | 41 ++++- 2 files changed, 159 insertions(+), 30 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 df43e29..3a3746e 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 @@ -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//.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` 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 8ed1c71..c30eaa5 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 @@ -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: