# HyperTwist platform taxonomy alias and rename plan

Created on `2026-05-30`.

## Status

This document is planning material only.

Current operator decision:

- taxonomy aliases are **deferred indefinitely**
- this is **not** current policy
- no instance should enact the alias strategy from this document unless the
  operator explicitly reopens and approves that lane

## Direct answer

Yes. The current `scriptorium` / `scriptoriumai` umbrella naming can be changed.
It is not impossible.

The real question is not possibility. The real question is blast radius versus
benefit.

## What is actually named `scriptorium*` today

The label is not confined to one folder. It currently spans:

- server paths such as `/srv/scriptorium-stack`, `/srv/scriptorium-live`,
  `/srv/scriptorium-app-api`, `/srv/backups/scriptorium`
- config paths such as `/etc/scriptorium`
- public hostnames such as `git.scriptoriumai.io` and `ci.scriptoriumai.io`
- local automation under `C:\ScriptoriumAI\ops\ssh`
- scheduled task names
- log/state directories under `%LOCALAPPDATA%`
- documentation language across multiple repos
- Docker object names and compose roots
- user-facing labels such as `scriptoriumai-new`

So a true rename is a cross-system migration, not a cosmetic text replace.

## Three viable strategies

### Strategy A: keep internals, add human-facing aliases

This changes human-facing labels without moving the internal substrate.

Examples:

- add neutral SSH aliases such as `platform-main-root`, `platform-main-dev`
- rename scheduled-task display names to neutral labels
- use neutral labels in docs, password manager entries, and operator checklists
- add wrapper scripts with neutral names that call the existing `scriptorium*`
  scripts underneath

Risk:

- low

Operational result:

- operators stop seeing `scriptorium*` everywhere
- existing paths, services, and automation remain intact

### Strategy B: partial rename of local-facing surfaces

This changes local script names, launcher names, task names, and docs, while
leaving server paths and public control-plane hostnames intact.

Risk:

- medium

Operational result:

- user-facing clutter drops materially
- server-side migration blast radius stays limited

### Strategy C: full internal rename

This changes the underlying server paths, local script roots, Docker/compose
roots, docs, and possibly public Git/CI hostnames.

Risk:

- high

Operational result:

- most aesthetically consistent
- also the easiest way to break a working setup if even one path is missed

## Recommendation

If the goal is clarity for outsourced operators, Strategy A or B is the correct
answer.

If the goal is absolute naming purity, Strategy C is possible, but it should be
treated as a dedicated migration packet with inventory, shim compatibility, and
validation.

That is the concrete answer to "can it be done or not":

- yes, it can be done
- no, it should not be done as an ad hoc text sweep
- the sensible implementation is an alias-first cleanup unless the naming issue
  is important enough to justify a second migration

## How human-facing aliases work without breaking internals

Human-facing aliases work by changing only the operator-facing entry points.

Examples:

1. SSH:
   - keep the real target as `212.227.13.220`
   - add new `Host` aliases in `~/.ssh/config`, for example:
     - `platform-main-root`
     - `platform-main-dev`
     - `platform-main-deploy`
   - do not change the real server paths or accounts

2. Scheduled tasks:
   - display name can be neutral
   - launcher script can be neutral
   - underlying script can still call existing `scriptorium*` assets

3. Docs:
   - introduce a glossary:
     - `Platform VPS` = current `scriptorium` control plane
     - `Platform backups` = current `/srv/backups/scriptorium`
   - keep exact path literals only where commands require them

4. Wrapper scripts:
   - `run-platform-remote-dev-seed.ps1`
   - `run-platform-authorship-sync.ps1`
   - `run-platform-remote-dev-reverse-sync.ps1`
   - internally call the current `scriptorium*` scripts

5. Password manager / credential registry:
   - relabel entries to neutral names
   - keep the actual usernames, URLs, and paths unchanged

This gives the clarity benefit without creating path churn.

## Example one-to-one alias map

If the alias strategy is ever reopened, each alias must have one explicit
target and that mapping must be recorded before anything is enacted.

Illustrative examples:

- `platform-main-root` -> `root@212.227.13.220`
- `platform-main-dev` -> `dev@212.227.13.220`
- `platform-main-deploy` -> `deploy@212.227.13.220`
- `Platform control plane` -> `/srv/scriptorium-stack`
- `Platform app backups` -> `/srv/backups/scriptorium`
- `Platform remote-dev seed` -> `/home/dev/src`
- `run-platform-authorship-sync.ps1` -> current
  `run-authorship-mirror-sync.ps1`
- `run-platform-remote-dev-seed.ps1` -> current
  `sync-vps-remote-dev-workspaces.ps1`
- `run-platform-remote-dev-reverse-sync.ps1` -> current
  `run-vps-remote-dev-reverse-sync.ps1`

Operational rule:

- each alias must point to exactly one canonical underlying object
- each canonical underlying object should list its supported aliases
- aliases must never be introduced as ambiguous synonyms without a recorded map

## Full rename blast radius inventory

A full rename packet must account for all of these:

1. server directory names
2. local script roots and file names
3. scheduled task names and launcher paths
4. `%LOCALAPPDATA%` log/state paths
5. docs across every affected repo
6. Docker compose project names, container names, volume names, network names
7. service environment variables and backup scripts
8. public hostnames if Git/CI branding is also being renamed
9. webhook, OAuth, and generated-link assumptions

If even one category is skipped, the rename is incomplete.

## If Strategy C is ever chosen

The safe sequence is:

1. freeze the current working state and record exact inventory
2. create alias wrappers first so there is a rollback-friendly compatibility
   layer
3. rename local user-facing scripts and task names
4. update docs and operator checklists
5. rename server paths and compose roots only after the wrappers exist
6. validate SSH, Forgejo, Woodpecker, cron, backups, Rider, and Visual Studio
7. keep compatibility shims until at least one full backup cycle and one real
   deployment cycle succeed

## Practical conclusion

The naming can be changed.

The best low-risk implementation is:

- keep the working internal substrate
- add neutral human-facing aliases and labels
- only perform a full internal rename if the aesthetics are worth paying for a
  second real migration

See also:

- `C:\HyperTwist\docs\ops\HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_VPS_TLS_CERTIFICATE_AND_IONOS_SEPARATION_GUIDE_2026-05-30.md`
