Refine VPS migration auth, TLS, and remote-dev scope

docs/ops/HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md

@@ -68,8 +68,8 @@ Operational implication:
 
 - if the new VPS is meant to replace the old host completely, these vhost roles
   must be either migrated or deliberately dropped
-- if only Forgejo/Woodpecker is moving first, leave the ScriptoriumAI and
-  VerticalTension vhosts on the old host until a later cutover
+- the current operator decision is a **full-host replacement**, so these roles
+  should now be treated as migration targets rather than optional leftovers
 
 ## TLS certificate inventory
 
@@ -97,8 +97,15 @@ Observed certbot certificates:
 
 Certificate rule for reconstruction:
 
-- do not copy old Let's Encrypt files as the primary migration plan
-- reissue matching SAN certificates on the new host after DNS points to it
+- reissuing matching SAN certificates on the new host remains the clean end
+  state
+- however, for currently covered names, copying the old VPS
+  `/etc/letsencrypt/live`, `/etc/letsencrypt/archive`, and
+  `/etc/letsencrypt/renewal` trees is an acceptable initial continuity bridge
+- this certificate continuity posture is entirely VPS-side and does **not**
+  depend on the IONOS DNS UI
+- `www.verticaltension.com` is the explicit exception because it is not covered
+  in the currently observed old-host certificate inventory
 
 ## Stack root inventory
 
@@ -338,14 +345,27 @@ Additional full-host rule:
   NGINX/vhost/TLS shape because live inspection of the old host currently shows
   a certificate-name mismatch on that host
 
+Additional remote-development rule:
+
+- the new VPS should also receive the current local remote-development workspace
+  payloads under a dedicated non-public root such as `/srv/dev`
+- confirmed current seed set:
+  - `C:\visual_studio_solutions\multi_project`
+  - `C:\VectorShell`
+  - `C:\HyperTwist`
+  - `C:\ScriptoriumAI`
+  - `C:\VerticalTension`
+  - `C:\NyxOS`
+  - `C:\Workspaces`
+- the current local helper script
+  `C:\ScriptoriumAI\ops\ssh\sync-vps-remote-dev-workspaces.ps1`
+  now codifies that seed set
+
 ## Recommended next action
 
 Before live migration:
 
-1. decide whether this is:
-   - control-plane-only replacement
-   - or full-host replacement
-2. if exact continuity matters, archive and copy the deployed web roots and app
-   service directories from the old VPS
-3. then bootstrap the new `212.227.13.220` host and restore only the selected
-   role set
+1. restore working SSH access to the new `212.227.13.220` host
+2. archive and copy the deployed web roots, app service directories, stack
+   roots, cron jobs, scripts, and cert material from the old VPS
+3. bootstrap the new host and restore the full selected role set

docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md

@@ -396,6 +396,19 @@ Additional cutover rule:
 - this is necessary because live inspection of the old host currently shows a
   certificate-name mismatch on `https://www.verticaltension.com`
 
+TLS continuity rule:
+
+- for the currently covered ScriptoriumAI and VerticalTension hostnames, the
+  existing VPS-side Let's Encrypt material can be copied to the new VPS as an
+  **initial continuity bridge**
+- this does **not** require changing IONOS nameserver delegation or relying on
+  the IONOS certificate UI
+- browsers only care about the certificate actually presented by NGINX on the
+  VPS they connect to
+- `www.verticaltension.com` remains the exception because the currently observed
+  old-host certificate inventory does **not** cover that name, so leaving it
+  strictly "as-is" would preserve the mismatch instead of fixing it
+
 ## Authorship preservation posture
 
 Authoritative source:
@@ -411,26 +424,29 @@ Current measured local size:
 
 Recommended migration posture:
 
-- keep the current working-files mirror lane for visible non-zip content
-- preserve the full local folder authority before any destructive cleanup
-- if the operator wants the backup zip history on the new VPS as well, store it
-  as a **separate cold archive lane**, not mixed into the normal incremental
-  working-files mirror lane
+- keep the full local folder authority before any destructive cleanup
+- include `.zip` backup history in the ongoing mirror lane on the new VPS
+- wire the scheduled Authorship mirror job so both the working files and the
+  backup zip history continue syncing automatically
 
 Reason:
 
-- that preserves the existing lightweight change-oriented mirror behavior for
-  active authorship work
-- while still allowing the new higher-capacity VPS to hold the backup zip
-  history after cleanup and one-time upload
+- the new VPS storage envelope now makes the larger continuous sync acceptable
+- the operator explicitly wants the backup zip history kept live on the new VPS,
+  not only retained as a one-shot cold archive
+- that increases sync volume, but it removes a second archive lane and keeps the
+  remote copy operationally complete
 
 ## Storage posture for the current local corpus
 
 Measured local sizes during this pass:
 
+- `C:\visual_studio_solutions\multi_project`: `0.74 GiB`
 - `C:\VectorShell`: `28.22 GiB`
 - `C:\ScriptoriumAI`: `15.86 GiB`
 - `C:\HyperTwist`: `14.69 GiB`
+- `C:\NyxOS`: `4.30 GiB`
+- `C:\Workspaces`: `80.74 GiB`
 - `C:\Users\Anthracite Ace\Desktop\Authorship`: `17.70 GiB`
 - `C:\VerticalTension`: `0.11 GiB`
 
@@ -449,9 +465,38 @@ Operational conclusion:
 
 - the current observed local corpus comfortably fits within the new VPS
   capacity envelope
+- the current measured remote-development seed set
+  (`multi_project`, `VectorShell`, `HyperTwist`, `ScriptoriumAI`,
+  `VerticalTension`, `NyxOS`, `Workspaces`) totals about `144.66 GiB`
+- adding the full local `Authorship` authority raises that current measured
+  working payload to about `162.36 GiB`
 - long-term repo growth is still real, so production retention policy should
   stay intentional rather than assuming the VPS is an infinite mirror warehouse
 
+## Expanded remote-development seed scope
+
+Confirmed additional remote-development payloads to seed onto the new VPS:
+
+- `C:\visual_studio_solutions\multi_project`
+- `C:\VectorShell`
+- `C:\HyperTwist`
+- `C:\ScriptoriumAI`
+- `C:\VerticalTension`
+- `C:\NyxOS`
+- `C:\Workspaces`
+
+Recommended target root on the new VPS:
+
+- `/srv/dev`
+
+Operational note:
+
+- these are best treated as a seeded remote-development workspace surface, not
+  as public web roots
+- the new helper script
+  `C:\ScriptoriumAI\ops\ssh\sync-vps-remote-dev-workspaces.ps1`
+  now codifies this seed set
+
 ## Rider remote-development setup
 
 Official source basis:
@@ -508,10 +553,24 @@ Do not change DNS yet.
 
 Next action is to complete the pre-cutover archive and reconstruction pass:
 
-1. archive the old VPS live surfaces and config
-2. restore the full selected role set on the new VPS
-3. validate NGINX/vhost/cert readiness there, including `www.verticaltension.com`
-4. only then perform the DNS record switch at IONOS
+1. restore working SSH access to `212.227.13.220`
+2. archive the old VPS live surfaces and config
+3. restore the full selected role set on the new VPS
+4. validate NGINX/vhost/cert readiness there, including `www.verticaltension.com`
+5. only then perform the DNS record switch at IONOS
+
+Current blocker:
+
+- the existing private key at
+  `C:\ScriptoriumAI\ops\ssh\scriptorium_vps_ed25519`
+  does **not** currently authenticate to the new VPS
+- the locally stored generated password also failed when tested against the new
+  VPS
+- practical resolution is either:
+  - provide the current root password for `212.227.13.220`
+  - or install
+    `C:\ScriptoriumAI\ops\ssh\scriptorium_vps_ed25519.pub`
+    into `/root/.ssh/authorized_keys` on the new VPS
 
 ## DNS record recommendations based on current findings