@homeflare/alchemy 0.11.0 → 0.13.0

package/src/proxmox/alertmanager-body.ts

@@ -0,0 +1,125 @@
+/**
+ * A PBS webhook body that posts one Alertmanager v2 alert — `POST /api/v2/alerts` takes a JSON
+ * ARRAY of `postableAlert`, each with a required `labels` map and an optional `annotations` map,
+ * every value a string (Alertmanager's api/v2/openapi.yaml, read at main 2026-09-22).
+ *
+ * ★ PURE TEXT, NOT A RENDERER. PBS renders it, with Handlebars, at send time: `{{ severity }}`,
+ *   `{{ title }}`, `{{ message }}`, `{{ timestamp }}` and `{{ fields.<name> }}` are the
+ *   notification, and `json`, `escape` and `url-encode` are the only helpers
+ *   (proxmox-notify endpoints/webhook.rs `setup_handlebars`, read at HEAD 2026-09-22).
+ *
+ * ⛔ THERE IS NO ESCAPING UNLESS THE TEMPLATE ASKS FOR IT. The webhook's Handlebars registers
+ *   `no_escape` ("There is no escape."), so `"{{ message }}"` breaks the JSON the first time a
+ *   task log holds a quote or a newline — and a failed job's message is exactly a task log. Every
+ *   value below goes through `json`, which emits a complete, quoted JSON string.
+ * ⛔ A FIELD THE NOTIFICATION DOES NOT CARRY MUST NOT BE REACHED FOR BARE. `escape` on a missing
+ *   field fails the whole render, and the notification is then lost — not degraded. MEASURED
+ *   (2026-09-22) with handlebars-rust 5.1.2 and the webhook's three helpers restated from source:
+ *   `{{ escape fields.job-id }}` over no fields errors "param at index 0 required but not found";
+ *   `{{ json fields.job-id }}` renders `null`, valid JSON but not a label value. Garbage
+ *   collection has no `job-id`, and the UI's "Test" button sends a notification with NO fields at
+ *   all (lib.rs `test_target`). So every field-derived label sits inside
+ *   `{{#if}}`, ends with its own comma, and the labels after them are always there: whichever
+ *   fields are present, the object stays valid JSON.
+ *
+ * ⚠️ ALERTMANAGER RESOLVES IT BY ITSELF. With no `endsAt` it sets `now + resolve_timeout` (5m by
+ *   default, api/v2/api.go `postAlertsHandler`), and PBS never sends a resolve — so a receiver
+ *   with `send_resolved: true` reports "resolved" five minutes after a failure that nobody fixed.
+ *   Page on the firing notification; do not read the resolve as a recovery.
+ * ⚠️ `severity` IS PBS'S WORD, not Alertmanager convention: `info`, `notice`, `warning`, `error`,
+ *   `unknown`. Route on `severity="error"`, or relabel it in the Alertmanager config.
+ */
+
+export interface AlertmanagerBodyOptions {
+  /** The `alertname` label. Default `PbsNotification`; `job_type` says which job it was. */
+  readonly alertname?: string;
+  /** The `source` label. Default `pbs`. */
+  readonly source?: string;
+  /** Optional `generatorURL` — an absolute link back to the PBS UI. */
+  readonly generatorURL?: string;
+}
+
+/**
+ * ⛔ AN OPTION IS PASTED INTO THE TEMPLATE, SO IT MAY NOT CARRY TEMPLATE SYNTAX. A `{{` in an
+ *   alert name would be rendered by PBS as an expression; a brace or backslash is refused here
+ *   rather than escaped, because Handlebars' escape rules are the renderer's, not this file's.
+ */
+const literal = (label: string, value: string): string => {
+  if (/[{}\\]/.test(value) || value === '') {
+    throw new Error(
+      `alertmanagerAlertBody: ${label} must be non-empty and hold no '{', '}' or '\\'`,
+    );
+  }
+  return JSON.stringify(value);
+};
+
+/**
+ * ⛔ AN ABSOLUTE http(s) URL OR NOTHING. Alertmanager validates `generatorURL` as `format: uri`
+ *   (api/v2/openapi.yaml) and answers 422 for the WHOLE post — so a typo here would not degrade
+ *   one field, it would lose every notification, and only at send time.
+ */
+const absoluteUrl = (value: string): string => {
+  const text = literal('generatorURL', value);
+  let protocol = '';
+  try {
+    protocol = new URL(value).protocol;
+  } catch {
+    // not a URL at all: refused below, like a relative one
+  }
+  if (protocol !== 'https:' && protocol !== 'http:') {
+    throw new Error('alertmanagerAlertBody: generatorURL must be an absolute http(s) URL');
+  }
+  return text;
+};
+
+/** Label name → notification field. ⚠️ Label names must match `[a-zA-Z_][a-zA-Z0-9_]*`. */
+const FIELD_LABELS: readonly (readonly [label: string, field: string])[] = [
+  ['job_type', 'type'],
+  ['job_id', 'job-id'],
+  ['datastore', 'datastore'],
+  ['hostname', 'hostname'],
+];
+
+/**
+ * The body template. Declare it on a webhook target together with `Content-Type:
+ * application/json`, method `post`, and the URL `<alertmanager>/api/v2/alerts`.
+ *
+ * ★ `fields.job-id` IS A VALID PATH: Handlebars-rust 5 (the version proxmox-notify pins) allows
+ *   `-` in an identifier (grammar.pest `symbol_char`), as handlebars.js does. The same scratch
+ *   build rendered this template for a GC failure, a verify failure and a field-less test
+ *   notification, and each parsed as JSON with string-only labels. The adversarial review re-ran
+ *   it over the test file's whole matrix — every PBS event's fields x five severities x hostile
+ *   text, 840 renders with and without `generatorURL` — and every one parsed (2026-09-22).
+ * ⚠️ THAT BUILD IS NOT PBS. The first real notification is the measurement that counts: send one
+ *   with the target's "Test" button and read what Alertmanager received.
+ */
+export const alertmanagerAlertBody = (options: AlertmanagerBodyOptions = {}): string => {
+  const alertname = literal('alertname', options.alertname ?? 'PbsNotification');
+  const source = literal('source', options.source ?? 'pbs');
+  const labels = FIELD_LABELS.map(
+    ([label, field]) =>
+      `      {{#if fields.${field}}}"${label}": {{ json fields.${field} }},{{/if}}`,
+  );
+  const link =
+    options.generatorURL === undefined
+      ? ''
+      : `,\n    "generatorURL": ${absoluteUrl(options.generatorURL)}`;
+  return [
+    '[',
+    '  {',
+    '    "labels": {',
+    ...labels,
+    '      "severity": {{ json severity }},',
+    `      "alertname": ${alertname},`,
+    `      "source": ${source}`,
+    '    },',
+    '    "annotations": {',
+    '      "summary": {{ json title }},',
+    '      "description": {{ json message }},',
+    '      "timestamp": "{{ timestamp }}"',
+    `    }${link}`,
+    '  }',
+    ']',
+    '',
+  ].join('\n');
+};

package/src/proxmox/api-token-form.ts

@@ -12,7 +12,7 @@ import type { ApiTokenAttributes, ApiTokenProps } from './api-token.ts';
  *
  * ⛔ THE WRITE SEMANTICS BELOW ARE READ FROM THE CLUSTER'S OWN PERL RATHER THAN INFERRED FROM THE
  *   API SCHEMA — `/usr/share/perl5/PVE/API2/User.pm`, subs `generate_token` and
- *   `update_token_info`, read over SSH on n2 on 2026-09-13. The two disagree in exactly the place
+ *   `update_token_info`, read over SSH on node-b on 2026-09-13. The two disagree in exactly the place
  *   that costs a forever-diff: the schema gives `expire` the default "same as user", and the code
  *   never implements it. api-token.ts records what that means.
  */
@@ -26,7 +26,7 @@ import { bool, int, text } from './values.ts';
  *   `ugid`, so reporting it as an attribute is what lets a privilege-separated token be granted
  *   anything at all without somebody retyping the join by hand.
  *
- * ⚠️ DERIVED, NOT READ. MEASURED: `GET /access/users/monitoring@pve/token/exporter` answers
+ * ⚠️ DERIVED, NOT READ. MEASURED: `GET /access/users/metrics@pve/token/exporter` answers
  *   `{"expire":0,"privsep":0}` and echoes back neither half of its own identity. So this is built
  *   from props, cannot disagree with the path the read used, and is therefore true by
  *   construction — which is why it is reported and never compared.
@@ -106,8 +106,8 @@ export const apiTokenSpec: PveSpec<ApiTokenProps, ApiTokenAttributes> = {
   /**
    * ⚠️ EXACTLY THE THREE FIELDS A PUT CAN PUT BACK, WHICH IS ALSO EXACTLY WHAT THE GET REPORTS.
    *   MEASURED, by replaying these two functions over the live GET bodies of all four token
-   *   shapes this cluster has: `monitoring@pve!exporter` (no comment), `tofu@pve!apply` and
-   *   `sablier@pve!sablier` (commented), and a live OpenBao lease under `hf-read@pve` (a real
+   *   shapes this cluster has: `metrics@pve!exporter` (no comment), `iac@pve!apply` and
+   *   `app@pve!app` (commented), and a live OpenBao lease under `hf-read@pve` (a real
    *   non-zero `expire`, offered as both `1789327175` and `"1789327175"` since `int` must not care
    *   which). All four answer noop; flipping `privsep` answers update; an empty body answers
    *   absent. ⚠️ THAT IS THE COMPARISON, NOT THE ENGINE — no `alchemy plan` was run against this

package/src/proxmox/api-token.ts

@@ -2,11 +2,11 @@
  * `Proxmox.ApiToken` — a PVE API token: the thing a service actually authenticates as.
  *
  * ⛔ THE SECRET EXISTS FOR ONE HTTP RESPONSE AND THEN NOWHERE. MEASURED from the cluster's own
- *   schema (`/usr/share/pve-docs/api-viewer/apidoc.js` on n2, 2026-09-13): POST returns
+ *   schema (`/usr/share/pve-docs/api-viewer/apidoc.js` on node-b, 2026-09-13): POST returns
  *   `["full-tokenid","info","value"]`; PUT returns `["comment","expire","full-tokenid","privsep",
  *   "value"]` with `value` present ONLY when `regenerate` was set; GET returns
  *   `["comment","expire","privsep"]` and never the secret. A live token agrees —
- *   `GET /access/users/monitoring@pve/token/exporter` answers `{"expire":0,"privsep":0}`. PVE says
+ *   `GET /access/users/metrics@pve/token/exporter` answers `{"expire":0,"privsep":0}`. PVE says
  *   it plainly on the POST: the value "needs to be stored as it cannot be retrieved afterwards".
  *
  * ⛔ SO A TOKEN THIS RESOURCE CREATES IS UNUSABLE, AND SAYING SO IS THE POINT OF THIS BLOCK. The
@@ -19,7 +19,7 @@
  *   ★ SO POINT THIS FAMILY AT TOKENS THAT ALREADY EXIST. `comment`, `expire` and `privsep` are the
  *     whole of a token's policy, and declaring them is real work: it is how `expire` stops being
  *     whatever somebody typed in 2024. Mint NEW tokens where the secret can be caught — OpenBao's
- *     `proxmox-tb4` mount, or a human at `pveum user token add`.
+ *     `proxmox-c1` mount, or a human at `pveum user token add`.
  *   ⚠️ THE CREATE PATH IS LEFT REACHABLE RATHER THAN STUBBED. A create that silently did nothing
  *     would be the same lie as the stubbed delete resource.ts's ★ refuses; the honest arrangement
  *     is a create that works and a header that says what it produces.
@@ -31,8 +31,8 @@
  *   that owns the lease, or to a human who is watching.
  *
  * ⚠️ THERE IS A SECOND WRITER TO THESE OBJECTS AND IT IS THE ONE THIS PROVIDER RUNS ON. OpenBao's
- *   `proxmox-tb4` engine mints PVE tokens under `hf-read@pve` and `hf-provision@pve` — read from
- *   `house/platform/secrets/vault/plugin-proxmox/proxmox/`: `privsep=0` (client.go), `expire` set
+ *   `proxmox-c1` engine mints PVE tokens under `hf-read@pve` and `hf-provision@pve` — read from
+ *   `<estate>/platform/secrets/vault/plugin-proxmox/proxmox/`: `privsep=0` (client.go), `expire` set
  *   to the lease deadline, and an id the plugin CHOOSES,
  *   `hf-<role>-<actor>-<entity6>-<stamp>-<nonce>` (tokenname.go). Revocation and WAL rollback look
  *   up that one exact id (wal.go); neither sweeps a prefix. So the two systems cannot collide on
@@ -62,7 +62,7 @@ import { type PveRequirements, type WithTarget, pveHandlers, pveOperations } fro
 
 export interface ApiTokenProps extends WithTarget {
   /**
-   * The account that owns the token, realm-qualified: `tofu@pve`, `root@pam`. Identity.
+   * The account that owns the token, realm-qualified: `iac@pve`, `root@pam`. Identity.
    *
    * ⚠️ THE ACCOUNT MUST ALREADY EXIST. Every method here runs `check_user_exist` first, so a
    *   token named under a missing user fails the READ (folded to "absent") and then fails the
@@ -120,7 +120,7 @@ export interface ApiTokenProps extends WithTarget {
    *   — `$privsep = $privsep ? 1 : 0` (AccessControl.pm:1622), so there is no unset state to
    *   preserve. Were this optional, adopting a live token without mentioning `privsep` would plan
    *   an update to 1 and STRIP a working credential of every privilege it has, silently: PVE
-   *   returns 401/403 to the service, nothing errors here, and `tofu@pve!apply` simply stops
+   *   returns 401/403 to the service, nothing errors here, and `iac@pve!apply` simply stops
    *   working. Required, so adopting a token is a sentence that states what it is.
    * ⚠️ AND `false` IS NOT A SHRUG. It is a token with its owner's whole privilege set; under a
    *   provisioning account that is the account's full authority with a separate secret.
@@ -156,9 +156,9 @@ export interface ProxmoxApiToken extends Resource<
  * ★ `retain` BY DEFAULT, AND THIS IS THE PLAINEST CASE FOR IT IN THE PACKAGE. A token's contents
  *   are one irreplaceable secret: delete it and the value is gone, a replacement is a DIFFERENT
  *   value, and every holder loses access the instant `cfs_write_file` returns — with no error
- *   raised anywhere near them. The live cluster's tokens are `monitoring@pve!exporter` (the PVE
- *   exporter feeding VictoriaMetrics), `mcp@pve!executor`, `tofu@pve!apply`, `tofu@pve!ro`,
- *   `sablier@pve!sablier` and `vaultmint@pve!engine` — the last being the parent credential the
+ *   raised anywhere near them. The live cluster's tokens are `metrics@pve!exporter` (the PVE
+ *   exporter feeding VictoriaMetrics), `agent@pve!executor`, `iac@pve!apply`, `iac@pve!ro`,
+ *   `app@pve!app` and `mint@pve!engine` — the last being the parent credential the
  *   OpenBao mount itself authenticates with, so orphaning that one would stop every plan in this
  *   package, this resource included. `delete` is FULLY IMPLEMENTED (DELETE is a real method on
  *   this path, measured) and runs the moment a caller opts in with `.pipe(RemovalPolicy.destroy())`.
@@ -184,7 +184,7 @@ const ops = pveOperations(apiTokenSpec);
  *   `reconcile` refuses by name and says what to do instead.
  *
  * ★ EVERYTHING ELSE STILL WORKS, AND IT IS THE HALF WORTH HAVING. Adopting an existing token and
- *   converging its `comment`, `expire` and `privsep` are real operations: TB4 carries SEVEN tokens
+ *   converging its `comment`, `expire` and `privsep` are real operations: C1 carries SEVEN tokens
  *   with `expire=0` and `privsep=0` made by clicks nobody recorded. Declaring those freezes the
  *   set, and an eighth appearing shows up as drift.
  *
@@ -203,7 +203,7 @@ const handlers = {
             'the secret only in the create response and it cannot be stored, so a token made here ' +
             'would be a live credential nobody holds. Create it with `pveum user token add` and ' +
             'capture the value, or mint a short-lived one from the OpenBao proxmox mount ' +
-            '(`bao read proxmox-tb4/creds/<role>`) -- then declare it here to manage it.',
+            '(`bao read proxmox-c1/creds/<role>`) -- then declare it here to manage it.',
         ),
       );
     }
@@ -213,7 +213,7 @@ const handlers = {
 
 /**
  * ⛔ `list` IS EMPTY, AND FOR THIS FAMILY THAT MATTERS MORE THAN THE GENERIC ARGUMENT IN
- *   resource.ts. A token index handed to Alchemy would offer up `vaultmint@pve!engine` and every
+ *   resource.ts. A token index handed to Alchemy would offer up `mint@pve!engine` and every
  *   live OpenBao lease for adoption — and adoption is what makes a later plan willing to delete.
  *   The mount's leases in particular appear and vanish on their own; anything that adopted one
  *   would report drift against a credential that was never its to hold.

package/src/proxmox/ceph-daemon-form.ts

@@ -9,7 +9,7 @@
  *   here decides a diff; `findRow` picks a row out of an answer its caller already fetched.
  *
  * ⛔ THE TWO PATHS ARE DIFFERENT AND THAT IS THE WHOLE REASON THIS FILE HAS TWO OF THEM. MEASURED
- *   on n2, 2026-09-13: there is no GET on the id path — `pvesh get /nodes/n2/ceph/mon/n2` answers
+ *   on node-b, 2026-09-13: there is no GET on the id path — `pvesh get /nodes/node-b/ceph/mon/node-b` answers
  *   "No 'get' handler defined" — while POST and DELETE are registered ONLY there. So the read uses
  *   `collectionPath` and the two writes use `daemonPath`, and swapping either one is a silent
  *   501: a create that never lands, or a destroy that reports failure while the daemon runs on.
@@ -41,8 +41,8 @@ export const daemonId = (props: CephDaemonProps) => props.name ?? props.node;
 
 /**
  * The read path. ⚠️ `{node}` HERE IS ONLY THE NODE BEING ASKED, not a filter. MEASURED:
- *   `GET /nodes/n2/ceph/mon` returns n2, n3 AND n4, and `GET /nodes/n3/ceph/mon` returns the same
- *   three IN A DIFFERENT ORDER — [n4,n2,n3] from n2 against [n3,n2,n4] from n3. A caller that took
+ *   `GET /nodes/node-b/ceph/mon` returns node-b, node-c AND node-d, and `GET /nodes/node-c/ceph/mon` returns the same
+ *   three IN A DIFFERENT ORDER — [node-d,node-b,node-c] from node-b against [node-c,node-b,node-d] from node-c. A caller that took
  *   row zero, or assumed the list was this node's daemons, would be wrong on both counts.
  */
 export const collectionPath = (props: CephDaemonProps) => `nodes/${props.node}/ceph/${props.kind}`;

package/src/proxmox/ceph-daemon.ts

@@ -2,7 +2,7 @@
  * `Proxmox.CephDaemon` — a Ceph monitor, manager or metadata server on one node.
  *
  * ★ ONE RESOURCE FOR THREE KINDS, AND THE SCHEMAS WERE CHECKED BEFORE THAT WAS DECIDED. Parsed
- *   from `/usr/share/pve-docs/api-viewer/apidoc.js` on n2, 2026-09-13: mon, mgr and mds each
+ *   from `/usr/share/pve-docs/api-viewer/apidoc.js` on node-b, 2026-09-13: mon, mgr and mds each
  *   expose GET on the collection and POST + DELETE on the id below it, each returns
  *   name/host/state/addr/ceph_version*, and the only divergence is the create parameter
  *   (`mon-address` / none / `hotstandby`) and the read-only extras (mon: quorum, rank; mds: rank,
@@ -10,11 +10,11 @@
  *   times over and let them drift — the argument resource.ts already makes for the factory itself.
  *
  * ⛔ THE ONLY GET IS THE COLLECTION'S, AND IT ANSWERS FOR THE WHOLE CLUSTER. MEASURED:
- *   `GET /nodes/n2/ceph/mon` returns n2, n3 AND n4, and `GET /nodes/n3/ceph/mon` returns the same
- *   three IN A DIFFERENT ORDER — [n4,n2,n3] from n2, [n3,n2,n4] from n3 — so a row is found by
+ *   `GET /nodes/node-b/ceph/mon` returns node-b, node-c AND node-d, and `GET /nodes/node-c/ceph/mon` returns the same
+ *   three IN A DIFFERENT ORDER — [node-d,node-b,node-c] from node-b, [node-c,node-b,node-d] from node-c — so a row is found by
  *   `name` and NEVER by position, and the `{node}` in the path is only the node being ASKED.
- *   MEASURED too: there is no GET on the id path at all; `pvesh get /nodes/n2/ceph/mon/n2` answers
- *   "No 'get' handler defined for '/nodes/n2/ceph/mon/n2'", and mgr and mds answer the same.
+ *   MEASURED too: there is no GET on the id path at all; `pvesh get /nodes/node-b/ceph/mon/node-b` answers
+ *   "No 'get' handler defined for '/nodes/node-b/ceph/mon/node-b'", and mgr and mds answer the same.
  *   That is why `path()` below is the COLLECTION, and that in turn is why `delete` is the one
  *   handler this file writes by hand: `pveOperations.destroy` sends its DELETE to `spec.path`,
  *   which here would be the collection — a 501 reported as a failed destroy, with the daemon still
@@ -27,11 +27,11 @@
  *   strips its section from ceph.conf. THREE MONS TOLERATE ONE LOSS; TWO TOLERATE NONE. Removing
  *   two in one deploy — or removing the mon on the node whose API is serving the call — loses
  *   quorum, and a cluster without mon quorum BLOCKS every RBD and CephFS I/O rather than erroring
- *   it, so on this cluster every guest on `cephtb4` hangs.
+ *   it, so on this cluster every guest on `rbd-c1` hangs.
  *   `mds`: destroying a STANDBY is a non-event; destroying the ACTIVE one fails CephFS over,
- *   and with no standby left `cephfs-tb4` goes unavailable. `mgr`: no guest I/O depends on it, but
+ *   and with no standby left `cephfs-c1` goes unavailable. `mgr`: no guest I/O depends on it, but
  *   the last one takes the PG autoscaler, the dashboard and PVE's own Ceph status with it.
- *   Live on 2026-09-13: mon, mgr AND mds on each of n2, n3, n4.
+ *   Live on 2026-09-13: mon, mgr AND mds on each of node-b, node-c, node-d.
  *
  * ★ AND THE ONLY WAY TO REACH THAT DESTROY IS TO DELETE THE DECLARATION. `matches` is deliberately
  *   total (see its ⛔), so this resource CANNOT plan a `replace` — which is the one action that
@@ -41,7 +41,7 @@
  *   `Sys.Audit`/`Datastore.Audit` on `/`, and PVEAuditor holds both (MEASURED:
  *   `GET /access/roles/PVEAuditor`), so the mount's `read` role can see this family — unlike
  *   `Proxmox.Storage`, which 403s under that lease. POST and DELETE both check `Sys.Modify` on
- *   `/`, and MEASURED on this cluster `LXCProvisioner` already holds it, so the provision lane
+ *   `/`, and MEASURED on this cluster the provision role already held it (it is in `PROVISION_PRIVILEGES`), so the provision lane
  *   needs no widening for once. ⚠️ `Sys.Modify` on the ROOT path is broad — it also buys
  *   datacenter options and every other cluster-wide config write — so it is worth knowing that
  *   this credential already has it rather than discovering it the next time something is scoped.
@@ -86,9 +86,9 @@ export interface CephDaemonProps extends WithTarget {
   name?: string;
   /**
    * mon only. Overrides the autodetected monitor IP; must sit in Ceph's public network — on this
-   * cluster that is 10.20.11.0/24, carried by `vmbr1.11`.
+   * cluster that is 198.51.100.0/24, carried by `vmbr1.42`.
    * ⛔ CREATE-ONLY AND NEVER COMPARED. PVE takes a bare ip-list on write and hands back `addr` as
-   *   `10.20.11.12:6789/0` — an address, a port and a nonce. The two are not the same string and
+   *   `198.51.100.12:6789/0` — an address, a port and a nonce. The two are not the same string and
    *   never will be, so diffing them would report a mismatch on every plan; with no PUT on this
    *   family that mismatch becomes a REPLACE, and a replace of a mon is the quorum loss in the
    *   header. Left out of `matches` on purpose.
@@ -98,7 +98,7 @@ export interface CephDaemonProps extends WithTarget {
    * mds only. Makes this standby replay the active MDS's journal for a faster failover.
    * ⛔ CREATE-ONLY AND NEVER COMPARED, AND THE FIELD THAT LOOKS LIKE ITS READBACK IS NOT ONE.
    *   `standby_replay` in the list is the daemon's CURRENT state, not its configuration: MEASURED
-   *   2026-09-13, all three mds report `standby_replay: false`, n3 included — and n3 is the ACTIVE
+   *   2026-09-13, all three mds report `standby_replay: false`, node-c included — and node-c is the ACTIVE
    *   mds, which is not a standby at all and so can never report true however it was created.
    *   Comparing `hotstandby` to it would plan a replace against whichever mds Ceph happens to have
    *   elected, i.e. against a value no declaration controls.
@@ -128,22 +128,22 @@ export interface CephDaemonAttributes {
   host: string;
   /**
    * mon `running`/`stopped`/`unknown`, mgr `active`/`standby`, mds `up:active`/`up:standby`/…
-   * ⛔ CEPH ELECTS THIS AND REWRITES IT WITHOUT ANYONE DECLARING ANYTHING. MEASURED: mgr n2 is
-   *   `active` while n3 and n4 are `standby`; mds n3 is `up:active` while n2 and n4 are
+   * ⛔ CEPH ELECTS THIS AND REWRITES IT WITHOUT ANYONE DECLARING ANYTHING. MEASURED: mgr node-b is
+   *   `active` while node-c and node-d are `standby`; mds node-c is `up:active` while node-b and node-d are
    *   `up:standby`. Restart a daemon and the roles move. It is reported so a plan can show what is
    *   live and kept out of `matches` so that an election is never a diff.
    * ⚠️ IT ALSO MEANS THIS RESOURCE DOES NOT MANAGE WHETHER THE DAEMON IS RUNNING. A configured but
    *   stopped daemon is still a row in the list, so it reads as present and plans `noop`.
    */
   state: string;
-  /** Ceph-formatted, e.g. `10.20.11.12:6789/0`. Reported; see `mon-address` for why never compared. */
+  /** Ceph-formatted, e.g. `198.51.100.12:6789/0`. Reported; see `mon-address` for why never compared. */
   addr: string;
   /** `ceph_version_short`, e.g. `20.2.2`. Reported: a straggler after an upgrade is worth seeing. */
   version: string;
   /**
    * mon rank in the monmap, mds rank in the filesystem, `-1` when the daemon has neither.
-   * ⛔ CEPH ASSIGNS IT AND NOTHING DECLARES IT. MEASURED: the mons are ranked n4=0, n3=1, n2=2 —
-   *   monmap order, not declaration order — and the mds ranks are 0 for the active n3 and -1 for
+   * ⛔ CEPH ASSIGNS IT AND NOTHING DECLARES IT. MEASURED: the mons are ranked node-d=0, node-c=1, node-b=2 —
+   *   monmap order, not declaration order — and the mds ranks are 0 for the active node-c and -1 for
    *   the two standbys. Rank moves when a daemon is added, removed or restarted.
    */
   rank: number;
@@ -152,8 +152,8 @@ export interface CephDaemonAttributes {
   /** mds only, and NOT the readback of `hotstandby` — see the ⛔ on that prop. */
   standbyReplay: boolean;
   /**
-   * mds only: the CephFS this daemon currently serves — `cephfs-tb4` here.
-   * ⛔ PRESENT ONLY ON THE ACTIVE MDS. MEASURED: n3 carries `fs_name`, n2 and n4 have no such key
+   * mds only: the CephFS this daemon currently serves — `cephfs-c1` here.
+   * ⛔ PRESENT ONLY ON THE ACTIVE MDS. MEASURED: node-c carries `fs_name`, node-b and node-d have no such key
    *   at all. So it is empty for two of three identical declarations, and comparing it would
    *   report work on exactly the daemons that are healthy standbys.
    */
@@ -234,7 +234,7 @@ export const ProxmoxCephDaemonProvider = () =>
          *   problem. Everything else here is the factory's.
          * ⚠️ AND IT IS THE DANGEROUS ONE. Re-read the destroy ⛔ in the header before letting a
          *   plan that removes a mon run: two gone at once is a cluster with no quorum and every
-         *   guest on `cephtb4` blocked on I/O.
+         *   guest on `rbd-c1` blocked on I/O.
          */
         delete: ({ olds }: { olds: CephDaemonProps }) =>
           pve(olds.target, 'provision', 'DELETE', daemonPath(olds)),

package/src/proxmox/ceph-flag.ts

@@ -2,7 +2,7 @@
  * `Proxmox.CephFlag` — one cluster-wide Ceph OSD flag, declared: `noout`, `pause`, `norebalance`.
  *
  * ★ ONE RESOURCE PER FLAG, NOT ONE CARRYING ALL ELEVEN, AND THE CLUSTER'S OWN API DECIDED IT.
- *   MEASURED on TB4 2026-09-13 (pve-manager 9.2.11, ceph tentacle 20.2.2) by reading
+ *   MEASURED on C1 2026-09-13 (pve-manager 9.2.11, ceph tentacle 20.2.2) by reading
  *   `/usr/share/perl5/PVE/API2/Cluster/Ceph.pm` and the published schema in
  *   `/usr/share/pve-docs/api-viewer/apidoc.js`:
  *     · `PUT /cluster/ceph/flags` ends in `fork_worker('cephsetflags', ...)` and returns a STRING
@@ -30,7 +30,7 @@
  *     defaulting to false would make `CephFlag('noout', { flag: 'noout', target })` mean "clear
  *     it" — the dangerous direction, chosen by OMISSION. Here the dangerous sentence has to be
  *     typed out by a person. Do not add a default, and do not declare a flag merely to document
- *     that it is off: MEASURED 2026-09-13, all eleven flags on TB4 read 0, so eleven
+ *     that it is off: MEASURED 2026-09-13, all eleven flags on C1 read 0, so eleven
  *     `value: false` lines would plan green forever and do nothing except take the brake off
  *     whenever somebody happens to apply them.
  *
@@ -58,8 +58,8 @@
  *   and plans `noop` straight past it. It cannot express a half-pause, so never use it to prove
  *   one is gone; `ceph osd dump | head -1` can.
  *   ⛔ `pause` AND `noup` ARE ALSO THE TWO THAT TAKE THE CLUSTER DOWN FROM A TYPO. `pause: true`
- *     stops all reads and writes, so every guest on `cephtb4` — the cluster's only rbd pool,
- *     MEASURED 2026-09-13 — freezes on its root disk, and so does `cephfs-tb4`. `noup: true`
+ *     stops all reads and writes, so every guest on `rbd-c1` — the cluster's only rbd pool,
+ *     MEASURED 2026-09-13 — freezes on its root disk, and so does `cephfs-c1`. `noup: true`
  *     stops a rebooted OSD from ever rejoining. Neither is undone by deleting the line.
  *
  * ⚠️ PRIVILEGES, AND THE WRITE ONE IS A BIG ASK. Both GETs check `Sys.Audit` on `/`; both PUTs
@@ -83,7 +83,7 @@ import { bool, flag } from './values.ts';
  *
  * ⚠️ THE ENUM IS CLOSED AND A TYPO IS A 400, WHICH IS WHY THIS IS A UNION AND NOT `string`. Both
  *   the GET and the PUT declare `additionalProperties => 0` over exactly this list.
- * ⚠️ CEPH HAS FLAGS PVE DOES NOT MODEL, and four of them are always on. MEASURED on TB4:
+ * ⚠️ CEPH HAS FLAGS PVE DOES NOT MODEL, and four of them are always on. MEASURED on C1:
  *   `ceph osd dump` reports `flags sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit`.
  *   PVE reads that same string and answers only about its own eleven, so the others can neither
  *   leak in here nor be set from here — `noautoscale` and `nosnaptrim` included.
@@ -167,7 +167,7 @@ const handlers = pveHandlers<CephFlagProps, CephFlagAttributes>({
    *
    * ⛔ IT NEVER ANSWERS undefined, WHICH MAKES THE CREATE BRANCH UNREACHABLE, AND ITS ERROR WILL
    *   MISLEAD YOU. All eleven flags always exist; there is nothing for "absent" to mean. So a POST
-   *   to `collection` means the READ failed — an expired 300s lease, n2 down, or ceph simply not
+   *   to `collection` means the READ failed — an expired 300s lease, node-b down, or ceph simply not
    *   configured on the cluster (every one of these four handlers opens with
    *   `check_ceph_configured()`, which dies). Read the resulting "Method 'POST /cluster/ceph/flags'
    *   not implemented" as "the read failed" and go and look at the credential, not at ceph. Same
@@ -187,7 +187,7 @@ const handlers = pveHandlers<CephFlagProps, CephFlagAttributes>({
    *   and `name` exist only on the bulk GET, which this file does not read, so neither can be
    *   compared by accident. Nothing PVE returns here is rewritten, re-ordered or re-typed by the
    *   cluster, because all PVE returns here is one boolean.
-   *   ★ MEASURED: on TB4, `GET /cluster/ceph/flags` answers value 0 for all eleven flags, so a
+   *   ★ MEASURED: on C1, `GET /cluster/ceph/flags` answers value 0 for all eleven flags, so a
    *     declaration of `value: false` reads back false and plans `noop`.
    */
   matches: (attributes, props) => attributes.value === props.value,

package/src/proxmox/ceph-fs-wire.ts

@@ -16,7 +16,7 @@
  *
  * ⛔ POST AND DELETE ANSWER WITH A UPID, NOT A RESULT — THE WRITE IS ASYNCHRONOUS AND A FAILED ONE
  *   IS STILL HTTP 200. Read from the cluster's own source, /usr/share/perl5/PVE/API2/Ceph/FS.pm on
- *   n2: `createfs` and `destroyfs` both end `return $rpcenv->fork_worker(...)`. Two different lies
+ *   node-b: `createfs` and `destroyfs` both end `return $rpcenv->fork_worker(...)`. Two different lies
  *   come out of trusting that status code. A read-back straight after the POST reports "still
  *   absent" about a filesystem that is being built as it says so — which is precisely the message
  *   `pveOperations.reconcile` would print, pointing at the wrong cause. And a worker that dies
@@ -26,7 +26,7 @@
  *     has not been observed; only the `fork_worker` that guarantees it is there.
  *
  * ⛔ A DELETE BODY IS SILENTLY DISCARDED BY PVE, SO `remove-pools` GOES IN THE QUERY STRING.
- *   MEASURED in /usr/share/perl5/PVE/APIServer/AnyEvent.pm on n2: line 928 reads the request
+ *   MEASURED in /usr/share/perl5/PVE/APIServer/AnyEvent.pm on node-b: line 928 reads the request
  *   content into params only `if ($method eq 'PUT' || $method eq 'POST')`, and line 1653 sends
  *   every other method down a branch that parses `$request->url->query()` and nothing else. So
  *   `pve(target, role, 'DELETE', path, form)` would send a body PVE never looks at: the flags would
@@ -41,7 +41,7 @@
  * ⛔ THE POLLER IS NEVER THE TASK'S OWNER, WHICH COSTS A PRIVILEGE, AND THIS ONE IS MEASURED
  *   RATHER THAN FEARED. client.ts mints a fresh credential per call and the mount vends a NEW
  *   token id each time, so the token reading the status is never the token recorded in the UPID —
- *   and PVE compares them exactly. /usr/share/perl5/PVE/API2/Tasks.pm on n2, `$check_task_user`:
+ *   and PVE compares them exactly. /usr/share/perl5/PVE/API2/Tasks.pm on node-b, `$check_task_user`:
  *   `return $user eq $fulltoken || $user eq $task->{user};`, above it the comment "token only sees
  *   token tasks, user sees user + token tasks". Token B of the same user matches neither branch.
  *   So the fallback is the schema's other clause for `GET /nodes/{node}/tasks/{upid}/status`: "The
@@ -128,8 +128,8 @@ const destroyPath = (props: CephFsProps) => {
 /**
  * Wait for a forked PVE task, and fail loudly rather than quietly.
  *
- * ⚠️ THE UPID IS PERCENT-ENCODED BECAUSE IT IS FULL OF COLONS — `UPID:n2:00396D3A:…:root@pam:`
- *   (MEASURED shape, from `GET /nodes/n2/tasks`) is ONE path segment, not seven. Encoding is what
+ * ⚠️ THE UPID IS PERCENT-ENCODED BECAUSE IT IS FULL OF COLONS — `UPID:node-b:00396D3A:…:root@pam:`
+ *   (MEASURED shape, from `GET /nodes/node-b/tasks`) is ONE path segment, not seven. Encoding is what
  *   guarantees it arrives as one; PVE's router decodes each segment before matching. REASONED from
  *   the URI handling rather than measured — no task of this provider's has been polled yet.
  */
@@ -178,8 +178,8 @@ const settle = (target: PveTarget, node: string, upid: string, what: string) =>
  *
  * ⚠️ A CREATE NEEDS A RUNNING *AND* A STANDBY MDS, and refuses BEFORE it forks -- "no running
  *   Metadata Server (MDS) found!" / "no standby Metadata Server (MDS) found!" are synchronous, so
- *   they surface as a failed POST rather than as a silent worker. TB4 has three (MEASURED: n3
- *   `up:active` for cephfs-tb4, n2 and n4 `up:standby`), so this is a note for a smaller cluster.
+ *   they surface as a failed POST rather than as a silent worker. C1 has three (MEASURED: node-c
+ *   `up:active` for cephfs-c1, node-b and node-d `up:standby`), so this is a note for a smaller cluster.
  * ⚠️ BOTH WRITES CHECK `Sys.Modify` ON `/` -- the root, with the breadth metric-server.ts warns
  *   about: granting it buys datacenter options and every other cluster-wide config write too.
  */

package/src/proxmox/ceph-fs.ts

@@ -2,7 +2,7 @@
  * `Proxmox.CephFs` — a CephFS on the cluster's own Ceph. The filesystem a `cephfs` storage mounts.
  *
  * ⛔ A REPLACE OF THIS RESOURCE DESTROYS A LIVE FILESYSTEM, AND THERE IS NO PUT TO SAVE YOU FROM
- *   IT. MEASURED from the published schema on n2, 2026-09-13: `/nodes/{node}/ceph/fs/{name}` has
+ *   IT. MEASURED from the published schema on node-b, 2026-09-13: `/nodes/{node}/ceph/fs/{name}` has
  *   exactly two methods, POST and DELETE. A CephFS cannot be edited in place, so `updateForm` is
  *   left undefined and anything the factory can see as changed becomes a REPLACE — and Alchemy's
  *   replace is create-then-delete, where the delete is `destroyfs`: the entry leaves the MDS map,
@@ -12,9 +12,9 @@
  *     one it is a live filesystem destroyed on every deploy, forever, because a background daemon
  *     moved a number nobody declared.
  *
- * ⛔ THERE IS NO SINGLE-OBJECT READ, WHICH INVERTS `path` AND `collection`. MEASURED on n2:
- *     pvesh get /nodes/n2/ceph/fs/cephfs-tb4
- *       -> No 'get' handler defined for '/nodes/n2/ceph/fs/cephfs-tb4'
+ * ⛔ THERE IS NO SINGLE-OBJECT READ, WHICH INVERTS `path` AND `collection`. MEASURED on node-b:
+ *     pvesh get /nodes/node-b/ceph/fs/cephfs-c1
+ *       -> No 'get' handler defined for '/nodes/node-b/ceph/fs/cephfs-c1'
  *   `GET /nodes/{node}/ceph/fs` is a directory index and is the only read there is, so `path()`
  *   below returns the INDEX and `attributes` picks this filesystem out of the array client-side —
  *   the shape acl.ts uses for the one flat `GET /access/acl`. The POST goes to the `{name}` path,
@@ -28,9 +28,9 @@
  *
  * ⛔ CREATING A CephFS CREATES TWO CEPH POOLS, AND A `Proxmox.CephPool` MUST NOT ALSO DECLARE THEM.
  *   `createfs` builds `<name>_data` and `<name>_metadata` itself and refuses outright if either
- *   exists ("ceph pools '…_data' and/or '…_metadata' already exist"). MEASURED on TB4: the live
- *   `cephfs-tb4` owns `cephfs-tb4_data` (id 6) and `cephfs-tb4_metadata` (id 7), both of which
- *   `GET /nodes/n2/ceph/pool` lists like any other pool — and `/nodes/{node}/ceph/pool/{name}` DOES
+ *   exists ("ceph pools '…_data' and/or '…_metadata' already exist"). MEASURED on C1: the live
+ *   `cephfs-c1` owns `cephfs-c1_data` (id 6) and `cephfs-c1_metadata` (id 7), both of which
+ *   `GET /nodes/node-b/ceph/pool` lists like any other pool — and `/nodes/{node}/ceph/pool/{name}` DOES
  *   have GET, PUT and DELETE, so a pool resource would be a clean `pveHandlers` fit and would
  *   adopt them without noticing. Declaring both is double management of one object: whichever
  *   reconciles first wins, and the loser either fails its create or PUTs `size`/`pg_num` onto pools
@@ -38,16 +38,16 @@
  *
  * ⚠️ `add-storage` IS A SECOND SIDE EFFECT AND IT LANDS IN storage.cfg. Set, `createfs` also calls
  *   `PVE::API2::Storage::Config->create` with type `cephfs`, content `backup,iso,vztmpl` and
- *   `fs-name <name>`. MEASURED: /etc/pve/storage.cfg on n2 holds exactly that — `cephfs:
- *   cephfs-tb4` / `content backup,vztmpl,iso` / `fs-name cephfs-tb4`. So a `Proxmox.Storage`
- *   declaring `cephfs-tb4` would be managing an entry this resource created. Declare ONE of them:
+ *   `fs-name <name>`. MEASURED: /etc/pve/storage.cfg on node-b holds exactly that — `cephfs:
+ *   cephfs-c1` / `content backup,vztmpl,iso` / `fs-name cephfs-c1`. So a `Proxmox.Storage`
+ *   declaring `cephfs-c1` would be managing an entry this resource created. Declare ONE of them:
  *   either `add-storage` here and no storage resource, or `add-storage` off and a
  *   `Proxmox.Storage` that reads this resource's `name` attribute — which also gets the ordering
  *   right for free, because Alchemy orders by data flow.
  *
  * ⚠️ `node` IS A ROUTE, NOT IDENTITY, AND MUST NEVER BE DIFFED. A CephFS is cluster-wide; the node
- *   in the path only says which node PVE proxies the call to. MEASURED: `GET /nodes/n2/ceph/fs`,
- *   `…/n3/…` and `…/n4/…` returned the byte-identical array. So changing `node` plans `noop`, and
+ *   in the path only says which node PVE proxies the call to. MEASURED: `GET /nodes/node-b/ceph/fs`,
+ *   `…/node-c/…` and `…/node-d/…` returned the byte-identical array. So changing `node` plans `noop`, and
  *   two resources naming the same `name` on different nodes are the SAME filesystem — the vmid
  *   hazard from lxc.ts, with a filesystem on the end of it instead of a container.
  *
@@ -84,11 +84,11 @@ export interface CephFsProps extends WithTarget {
    * this is under 32. PVE's default is 128.
    *
    * ⛔ CREATE-TIME ONLY, UNREADABLE, AND OWNED BY THE AUTOSCALER FROM THE SECOND IT LANDS. It is
-   *   never compared — see the ⛔ on `matches` — and this is not caution, it is measured. TB4's
-   *   `cephfs-tb4` was created with the default 128 (the arithmetic proves it: `cephfs-tb4_metadata`
-   *   sits at 32, which is 128/4), and `cephfs-tb4_data` reads pg_num 32 TODAY. The autoscaler moved
+   *   never compared — see the ⛔ on `matches` — and this is not caution, it is measured. C1's
+   *   `cephfs-c1` was created with the default 128 (the arithmetic proves it: `cephfs-c1_metadata`
+   *   sits at 32, which is 128/4), and `cephfs-c1_data` reads pg_num 32 TODAY. The autoscaler moved
    *   it by a factor of four, and it is not finished: `pg_autoscale_mode` is `on` for every pool on
-   *   this cluster and `cephfs-tb4_metadata` already reports `pg_num_final: 16` against its live 32.
+   *   this cluster and `cephfs-c1_metadata` already reports `pg_num_final: 16` against its live 32.
    */
   pg_num?: number;
   /**
@@ -155,7 +155,7 @@ const ops = pveOperations<CephFsProps, CephFsAttributes>({
    *   only honest comparison is none at all.
    *   ⚠️ THE TEMPTING ADDITION IS `pg_num`, AND IT WOULD BE THE WORST BUG THIS PACKAGE HAS SHIPPED.
    *     It is not in the index at all, so it can only be read from the pool endpoint — where the
-   *     autoscaler owns it. MEASURED on TB4 today: created at 128, live at 32, with the metadata
+   *     autoscaler owns it. MEASURED on C1 today: created at 128, live at 32, with the metadata
    *     pool already scheduled down to 16. Compared, that is an eternal mismatch; and because
    *     `updateForm` is undefined, the action it produces is REPLACE. The plan would destroy and
    *     rebuild a live filesystem on every deploy, triggered by a daemon on its own schedule.
@@ -176,7 +176,7 @@ export const ProxmoxCephFsProvider = () =>
       ProxmoxCephFs.Provider.of({
         /**
          * ⛔ EMPTY, LIKE EVERY OTHER RESOURCE HERE. The index answers with every filesystem on the
-         *   cluster, `cephfs-tb4` included — the one holding this estate's ISOs and templates.
+         *   cluster, `cephfs-c1` included — the one holding this estate's ISOs and templates.
          *   Adopting it would put Alchemy one `destroy` away from it. Adoption stays explicit.
          */
         list: () => Effect.succeed([]),