From 992a03a26659ca4bdbfe03fa8914ce9d29e0476e Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Fri, 29 May 2026 21:34:00 +0200 Subject: [PATCH] Clarify VPS full-host migration parity and storage posture --- ...OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md | 21 +- ...JO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md | 205 +++++++++++++++--- 2 files changed, 186 insertions(+), 40 deletions(-) diff --git a/docs/ops/HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md b/docs/ops/HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md index 1116897..1942fea 100644 --- a/docs/ops/HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md +++ b/docs/ops/HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md @@ -278,20 +278,25 @@ Confirmed: Not confirmed: - current production web artifacts are **not** identical to the currently - visible local build outputs for `ScriptoriumAI` and `VerticalTension` + visible tracked local build outputs for `ScriptoriumAI` +- `VerticalTension` no longer shares that same uncertainty because a fresh + detached `HEAD` build reproduced the live public asset hashes Observed mismatch examples: - production `scriptoriumai.io` serves asset `index-DKzZ39HF.js` - current local `ScriptoriumAI` build references `index-B2KwrMUv.js` - production `verticaltension.com` serves `index-CgVsNXoc.js` -- current local `VerticalTension` build references `index-ChYBuzHU.js` +- fresh detached `VerticalTension` build from repo `HEAD` also produced + `index-CgVsNXoc.js` and `index-ismjD07_.css` Reconstruction rule: -- if exact production continuity matters, migrate deployed artifacts from the - old server -- do not assume a local rebuild reproduces the current public state exactly +- for `ScriptoriumAI`, if exact production continuity matters, migrate deployed + artifacts from the old server and preserve repo `HEAD` separately +- for `VerticalTension`, the current live public site is reproducible from a + fresh `HEAD` build, but migrating the deployed web root is still prudent for + rollback and zero-surprise continuity ## Minimum reconstruction set for a control-plane-only cutover @@ -327,6 +332,12 @@ If the new VPS is replacing the old host completely, also reconstruct: - `/srv/verticaltension-web` - all matching certbot SAN certificates listed above +Additional full-host rule: + +- the new VPS should explicitly cover `www.verticaltension.com` in the final + NGINX/vhost/TLS shape because live inspection of the old host currently shows + a certificate-name mismatch on that host + ## Recommended next action Before live migration: diff --git a/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md b/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md index 2915d79..cc48dad 100644 --- a/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md +++ b/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md @@ -286,7 +286,7 @@ This is the key result for migration safety. Confirmed: - local `HyperTwist` app repo `HEAD` and remote `origin/main` match at: - - `19c8a78f92f6c5d84558cbb57d682288edb302b2` + - `0ea26569902f181ebeb7c9db2c14c2c0b59ae466` - local `ScriptoriumAI` repo `HEAD` and remote `origin/main` match at: - `118a85c0fee3fff34c071dd78d7cfe3eacc8ba95` - local `VerticalTension` repo `HEAD` and remote `origin/main` match at: @@ -307,37 +307,150 @@ Operational consequence: ### Production artifact parity -The live production web roots on the old VPS are **not** provably identical to -the current local built outputs. +The three important truths are: + +- source-control heads are safe +- `VerticalTension` production is now reproducible from a fresh `HEAD` build +- `ScriptoriumAI` production is **not** provably reconstructible from the + currently tracked clean source alone + +#### `ScriptoriumAI` Observed: -- production `scriptoriumai.io` `index.html` serves: +- latest repo `HEAD` is: + - `118a85c0fee3fff34c071dd78d7cfe3eacc8ba95` + - commit date: `2026-05-08 18:05:14 +0200` +- latest tracked frontend artifact update in git is older: + - `012fc396ea6eba826f27f4a0f0c9cc17a3354af8` + - commit date: `2026-04-23 14:56:12 +0200` +- production `scriptoriumai.io` currently serves: - `/assets/index-DKzZ39HF.js` -- current local `C:\ScriptoriumAI\scriptoriumai-ui\dist\index.html` references: + - `/assets/index-D8zU9W-S.css` +- those live assets report: + - `Last-Modified: Fri, 08 May 2026 16:20:04 GMT` + - which is `2026-05-08 18:20:04 +0200` +- current tracked/local + `C:\ScriptoriumAI\scriptoriumai-ui\dist\index.html` references: - `/assets/index-B2KwrMUv.js` -- production `verticaltension.com` `index.html` serves: - - `/assets/index-CgVsNXoc.js` - - `/assets/index-ismjD07_.css` -- current local `C:\VerticalTension\dist\index.html` references: - - `/assets/index-ChYBuzHU.js` - - `/assets/index-Ck8vgTXb.css` + - `/assets/index-D8zU9W-S.css` +- the production JS hash `DKzZ39HF` was not found in tracked + `scriptoriumai-ui/dist/index.html` history during local inspection Meaning: -- source-control heads are safe -- current production artifacts are not byte-for-byte the same as the currently - visible local build outputs -- therefore, if the goal is exact production continuity, migrate the currently - deployed web/app content from the old VPS instead of rebuilding from local - source during cutover +- the latest committed source-control state is the May 8 repo `HEAD` +- the latest known deployed public artifact state is the May 8 production web + root on the old VPS +- those are related in time, but not provably byte-identical +- the exact live `ScriptoriumAI` public surface should therefore be preserved + from the old VPS as deployed content, not re-derived from git alone during + the first cutover -Recommended safety rule: +Safety rule for `ScriptoriumAI`: -- for zero-surprise cutover, copy the live deployed content from the old VPS -- only do a fresh rebuild/deploy after the new VPS replacement is stable and - only when you intentionally want to refresh production to the current source - state +- preserve both: + - repo `HEAD` + - old VPS deployed state under `/var/www/scriptoriumai` and related app roots + +#### `VerticalTension` + +Observed: + +- production `verticaltension.com` currently serves: + - `/assets/index-CgVsNXoc.js` + - `/assets/index-ismjD07_.css` +- a fresh detached build from repo `HEAD` + `91bee21a7101ef08d3e91db9040f8a3ec8d3dd27` reproduced: + - `index-CgVsNXoc.js` + - `index-ismjD07_.css` + +Meaning: + +- `VerticalTension` production is aligned with a fresh `HEAD` build +- preserving the live deployed web root is still prudent for rollback, but the + current public site is not showing the same ambiguity seen in `ScriptoriumAI` + +Cross-product safety rule: + +- for zero-surprise cutover, archive and copy the live deployed content from + the old VPS for all public surfaces +- after the new VPS is stable, intentional rebuild/redeploy can then replace + those copied artifacts where desired + +## Confirmed operator decisions + +As of the current migration pass, these decisions are now treated as confirmed: + +- this is a **full-host replacement**, not only a control-plane-only move +- all current production domains should end up on the new VPS +- DNS stays hosted at IONOS +- nameserver delegation does **not** need to change for remote development +- remote development only depends on SSH reachability, Linux user/tooling + setup, and the host being stable + +Additional cutover rule: + +- `www.verticaltension.com` must receive explicit NGINX vhost coverage and a + certificate that matches that host on the new VPS +- this is necessary because live inspection of the old host currently shows a + certificate-name mismatch on `https://www.verticaltension.com` + +## Authorship preservation posture + +Authoritative source: + +- local Windows folder: + `C:\Users\Anthracite Ace\Desktop\Authorship` + +Current measured local size: + +- total: `17.70 GiB` +- `.zip` files: `11.78 GiB` across `459` files +- non-zip files: `5.93 GiB` + +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 + +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 + +## Storage posture for the current local corpus + +Measured local sizes during this pass: + +- `C:\VectorShell`: `28.22 GiB` +- `C:\ScriptoriumAI`: `15.86 GiB` +- `C:\HyperTwist`: `14.69 GiB` +- `C:\Users\Anthracite Ace\Desktop\Authorship`: `17.70 GiB` +- `C:\VerticalTension`: `0.11 GiB` + +Important nuance: + +- the current observed `C:\VectorShell` footprint is materially below the + operator's rough `~100 GiB` estimate +- inside `C:\VectorShell`, the largest current slices are: + - `mirrors`: `17.54 GiB` + - `UnrealVectorShell`: `6.51 GiB` + - `sentrux`: `3.11 GiB` +- if other large VectorShell-related stores exist outside `C:\VectorShell`, + they must be added separately to any final storage budget + +Operational conclusion: + +- the current observed local corpus comfortably fits within the new VPS + capacity envelope +- long-term repo growth is still real, so production retention policy should + stay intentional rather than assuming the VPS is an infinite mirror warehouse ## Rider remote-development setup @@ -391,17 +504,14 @@ Recommended use: ## Recommended next action -Do not start live server migration yet. +Do not change DNS yet. -Next action is to fill the pending-input section above with: +Next action is to complete the pre-cutover archive and reconstruction pass: -1. new VPS IP and access details -2. DNS/nameserver details -3. hostname cutover scope -4. preferred development username - -Once those are supplied, the live execution pass can begin from the new-host -bootstrap phase. +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 ## DNS record recommendations based on current findings @@ -456,8 +566,18 @@ Current observed public DNS already points to the old production VPS: - `A git -> 212.227.22.66` - `CNAME www -> scriptoriumai.io` -Do not change these yet unless the ScriptoriumAI production surfaces are part of -the same cutover window. +For the full-host cutover window, change all of these `A` records to: + +- `212.227.13.220` + +Keep unchanged: + +- `CNAME www -> scriptoriumai.io` +- current mail records +- `_domainconnect` +- `_dmarc` +- DKIM-related CNAMEs +- CAA records ### `verticaltension.com` @@ -470,8 +590,23 @@ Current observed public DNS already points to the old production VPS: - `A ci -> 212.227.22.66` - `A git -> 212.227.22.66` -Do not change these yet unless VerticalTension is included in the same cutover -window. +For the full-host cutover window, change all of these `A` records to: + +- `212.227.13.220` + +Keep unchanged: + +- the existing non-`A` `www` records +- current mail records +- `_domainconnect` +- `_dmarc` +- DKIM-related CNAMEs + +Important nuance: + +- do **not** convert `www.verticaltension.com` to `CNAME` in this pass +- simply update the existing `A www` target once the new VPS is ready +- the new VPS must explicitly serve `www.verticaltension.com` with matching TLS ## `www` guidance