@homeflare/alchemy 0.31.2 → 0.33.0

package/dist/proxmox/storage-form.d.ts

@@ -0,0 +1,54 @@
+/**
+ * `Proxmox.Storage`'s WRITE side: the locator bag, the create/update forms, and the translation
+ * into distilled's own typed request shape. Split out of storage-wire.ts (2026-09-24) to keep
+ * both files under the 250-line cap — the api-token.ts/api-token-form.ts seam, same reasoning.
+ */
+import type * as storage from '@distilled.cloud/proxmox/storage';
+import type { StorageProps } from './storage.ts';
+export declare const STORAGE_CREATE = "pve:POST /storage";
+export declare const STORAGE_UPDATE = "pve:PUT /storage/{storage}";
+/**
+ * The create-time, plugin-specific half of a storage: `dir` wants `path`, `nfs` `server`+`export`,
+ * `cifs` `server`+`share`, `pbs` `server`+`datastore`, `rbd` `pool`+`monhost`, `lvmthin`
+ * `vgname`+`thinpool`, `zfspool` `pool`. A bag rather than two dozen named fields, because PVE
+ * ships about that many plugins and each brings its own locator. ⚠️ Never diffed — see `matches`
+ * (storage-wire.ts).
+ *
+ * ⛔ `password`, `keyring` AND `encryption-key` ARE `never` ON PURPOSE — see the ⛔ in storage.ts's
+ *   header. POSITIVE-CONTROLLED rather than assumed: all three are a compile error, `TS2322: Type
+ *   'string' is not assignable to type 'undefined'`.
+ * ⚠️ EVERY KEY IN THIS BAG GOES THROUGH `underscored` (below) BEFORE IT REACHES DISTILLED — see
+ *   that function's own header. A caller writes PVE's own field names here (`fs-name`, matching
+ *   `pvesm`/pve-docs), never distilled's renamed ones.
+ */
+export type StorageLocator = Record<string, string> & {
+    password?: never;
+    keyring?: never;
+    'encryption-key'?: never;
+};
+/**
+ * ⚠️ THE BAG IS SPREAD FIRST SO NOTHING IN IT CAN SHADOW A FIELD THIS RESOURCE MANAGES. A stray
+ *   `storage` or `type` in a locator would otherwise rename the object being created, and PVE
+ *   would build the wrong thing under a name Alchemy then records as the declared one.
+ * ★ HYPHENATED, THE WIRE SHAPE — `guardWrite` (storage.ts) checks this form directly; see
+ *   `underscored`'s header for why translating it here would blind that check.
+ */
+export declare const createForm: (props: StorageProps) => Record<string, string>;
+/**
+ * ⚠️ `type` AND THE LOCATOR ARE NEVER SENT ON UPDATE — PVE's PUT refuses the create-only fields
+ *   (`PutStorageRequest` has no `type`, and the plugin locator fields it does carry are for a
+ *   different purpose: moving an existing volume, not re-pointing the definition), and comparing
+ *   either could only plan an update that no write can apply: a plan that reports work forever.
+ */
+export declare const updateForm: (props: StorageProps) => Record<string, string>;
+/**
+ * The actual `createStorage` call body — `createForm`, translated once. See `underscored`.
+ * ⚠️ `as unknown as` — same load-bearing cast as `locatorForm`'s own ⚠️: a plain
+ *   `Record<string,string>` does not structurally overlap a named-field interface enough for
+ *   TypeScript to accept a direct cast, even though every field it carries fits one of the
+ *   interface's own (all-optional-but-two) properties.
+ */
+export declare const toDistilledCreate: (props: StorageProps) => storage.CreateStorageRequest;
+/** The actual `putStorage` call body — `updateForm`, translated once. See `toDistilledCreate`. */
+export declare const toDistilledUpdate: (props: StorageProps) => storage.PutStorageRequest;
+//# sourceMappingURL=storage-form.d.ts.map

package/dist/proxmox/storage-form.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"storage-form.d.ts","sourceRoot":"","sources":["../../src/proxmox/storage-form.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AACH,OAAO,KAAK,KAAK,OAAO,MAAM,kCAAkC,CAAC;AACjE,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,cAAc,CAAC;AAGjD,eAAO,MAAM,cAAc,sBAAsB,CAAC;AAClD,eAAO,MAAM,cAAc,+BAA+B,CAAC;AAE3D;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,cAAc,GAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG;IACpD,QAAQ,CAAC,EAAE,KAAK,CAAC;IACjB,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,gBAAgB,CAAC,EAAE,KAAK,CAAC;CAC1B,CAAC;AA4EF;;;;;;GAMG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAKpE,CAAC;AAEH;;;;;GAKG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAGpE,CAAC;AAEH;;;;;;GAMG;AACH,eAAO,MAAM,iBAAiB,UAAW,YAAY,KAAG,OAAO,CAAC,oBACW,CAAC;AAE5E,kGAAkG;AAClG,eAAO,MAAM,iBAAiB,UAAW,YAAY,KAAG,OAAO,CAAC,iBACQ,CAAC"}

package/dist/proxmox/storage-wire.d.ts

@@ -0,0 +1,56 @@
+import * as Effect from 'effect/Effect';
+import type { StorageProps } from './storage.ts';
+import { UNREADABLE, type Unreadable } from './unreadable-read.ts';
+export interface StorageAttributes {
+    storage: string;
+    /** Reported so a plan can show what it points at; never diffed — storage.ts's `type` doc. */
+    type: string;
+    content: string;
+    nodes: string;
+    disable: boolean;
+    shared: boolean;
+    preallocation: string;
+    'prune-backups': string;
+    comment: string;
+}
+export declare const sameList: (declared: string | undefined, live: string) => boolean;
+export declare const same: <T>(declared: T | undefined, live: T) => boolean;
+/**
+ * ★ Default `read` role WOULD READ 403 — see storage.ts's header on why this family reads with
+ *   `provision`, the same as acl.ts and unlike group.ts/user.ts.
+ * ⛔ `{ storage: props.storage }`, NEVER THE WHOLE `props` — user.ts/group.ts's own ⛔, the
+ *   kit 0.31.1 regression: `GetStorageRequest`'s schema declares only `storage` (a path label);
+ *   any OTHER key on the object passed to `storage.getStorage` is treated by distilled's
+ *   `buildRequest` as an "unknown key" and JSON-encoded onto this bodyless GET, which a stricter
+ *   fetch client refuses outright.
+ * ⛔ A MISSING STORAGE IS A 500, NOT A 404 — MEASURED against the live cluster (TB4, 2026-09-24,
+ *   admin lane, read-only probe): `GET /storage/hf-measure-nonexistent-probe` answers
+ *   `{"message":"storage 'hf-measure-nonexistent-probe' does not exist\n","data":null}` at HTTP
+ *   500 — the SAME shape as user.ts's and group.ts's own measured 500, not the clean
+ *   `{"data":null}` at 200 this file's pre-migration comment assumed for every read failure
+ *   (client.ts's `pveOperations.read` could not tell the two apart either way, folding both into
+ *   "absent"). `readStorage` below (used by `read`/`reconcile`) still folds it, exactly as
+ *   `readUser`/`readGroup` do, so a brand-new declaration can still be created; `readStorageOrFail`
+ *   (used by `diff`) does not.
+ */
+export declare const readStorageOrFail: (props: StorageProps) => Effect.Effect<typeof UNREADABLE | StorageAttributes, import("@distilled.cloud/caddy").BadGateway | import("@distilled.cloud/caddy").BadRequest | import("@distilled.cloud/caddy").ConfigError | Error | import("@distilled.cloud/caddy").GatewayTimeout | import("effect/unstable/http/HttpClientError").HttpClientError | import("@distilled.cloud/caddy").InternalServerError | import("@distilled.cloud/proxmox/Errors").ParameterVerificationFailed | import("@distilled.cloud/proxmox/Errors").ProxmoxParseError | import("./distilled-pve.ts").PveClusterExhausted | import("@distilled.cloud/caddy").ServiceUnavailable | import("effect/Cause").TimeoutError | import("@distilled.cloud/caddy").TooManyRequests | import("@distilled.cloud/caddy").Unauthorized | import("@distilled.cloud/proxmox/Errors").UnknownProxmoxError, import("effect/unstable/http/HttpClient").HttpClient>;
+/**
+ * ⛔ FOLDS A GENUINE READ FAILURE TO `undefined` TOO, AND ONLY `read`/`reconcile` MAY USE IT —
+ *   user.ts's `readUser` has the full reasoning. Safe here because a wrongful fold costs at most a
+ *   redundant `createStorage` POST, which PVE refuses loudly ("storage ID already exists") rather
+ *   than silently corrupting anything.
+ * ⛔ `storage.ts`'s `diff` does **NOT** use this — the SAME bug class as the credential denial fix:
+ *   folding a TRANSIENT failure into "absent" at PLAN TIME is what forced a false `update` with
+ *   nothing compared (the ORIGINAL cries-wolf bug this family shipped with, per unreadable-read.ts's
+ *   own header). `diff` calls `readStorageOrFail` directly, so a genuine failure there propagates
+ *   and fails the whole plan loudly instead.
+ */
+export declare const readStorage: (props: StorageProps) => Effect.Effect<typeof UNREADABLE | StorageAttributes | undefined, never, import("effect/unstable/http/HttpClient").HttpClient>;
+/** `read`/`reconcile` return `Attributes | undefined`; only `diff` tells `UNREADABLE` apart. */
+export declare const dropUnreadable: (live: StorageAttributes | Unreadable | undefined) => StorageAttributes | undefined;
+/**
+ * ⚠️ `type` IS NEVER COMPARED — CREATE-ONLY (`storage.ts`'s own `StorageProps.type` doc), so a
+ *   changed declaration plans `noop` on it, same as before the migration.
+ */
+export declare const matches: (attributes: StorageAttributes, props: StorageProps) => boolean;
+//# sourceMappingURL=storage-wire.d.ts.map

package/dist/proxmox/storage-wire.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"storage-wire.d.ts","sourceRoot":"","sources":["../../src/proxmox/storage-wire.ts"],"names":[],"mappings":"AAOA,OAAO,KAAK,MAAM,MAAM,eAAe,CAAC;AAExC,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,cAAc,CAAC;AACjD,OAAO,EAAE,UAAU,EAAE,KAAK,UAAU,EAAoB,MAAM,sBAAsB,CAAC;AAGrF,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,MAAM,CAAC;IAChB,6FAA6F;IAC7F,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,OAAO,CAAC;IAChB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,OAAO,EAAE,MAAM,CAAC;CACjB;AAmBD,eAAO,MAAM,QAAQ,aAAc,MAAM,GAAG,SAAS,QAAQ,MAAM,YACN,CAAC;AAE9D,eAAO,MAAM,IAAI,GAAI,CAAC,YAAY,CAAC,GAAG,SAAS,QAAQ,CAAC,YACX,CAAC;AAwB9C;;;;;;;;;;;;;;;;;GAiBG;AACH,eAAO,MAAM,iBAAiB,UAAW,YAAY,m2BAGyC,CAAC;AAE/F;;;;;;;;;;GAUG;AACH,eAAO,MAAM,WAAW,UAAW,YAAY,kIACuB,CAAC;AAEvE,gGAAgG;AAChG,eAAO,MAAM,cAAc,SAAU,iBAAiB,GAAG,UAAU,GAAG,SAAS,kCACvC,CAAC;AAEzC;;;GAGG;AACH,eAAO,MAAM,OAAO,eAAgB,iBAAiB,SAAS,YAAY,YAOjC,CAAC"}

package/dist/proxmox/storage.d.ts

@@ -12,19 +12,48 @@
  * ⛔ ONE PRIVILEGE COVERS THIS WHOLE FAMILY AND IT IS `Datastore.Allocate` ON `/storage`. Create,
  *   update, delete AND the single-object read all check it — `Datastore.Audit` is not enough for
  *   any of them. MEASURED: `GET /storage/local` under the auditor-scoped `read` lease answers 403
- *   "Permission check failed (/storage/local, Datastore.Allocate)". `pveOperations.read` folds
- *   every failure into `undefined`, i.e. "absent", because a 404 is a legitimate answer there and
- *   it cannot tell the two apart — so under that lease this resource NEVER CONVERGES, in two
- *   directions: reconcile reads "absent" and POSTs a create over a storage that is already defined,
- *   and where a create does land the read-back is 403 too, so reconcile dies with "the write
- *   returned no error but the object is still absent" about an object it has just built. Both
- *   messages point away from the cause.
- *   ★ SO WIDEN OR RE-POINT BEFORE THE FIRST PLAN, outside this file: give the credential mount's
- *     `read` role `Datastore.Allocate` on `/storage`, or read this family with `provision`. The
- *     provision role in the estate this was written for held only `Datastore.AllocateSpace` and
- *     `Datastore.Audit`, and NEITHER IS IT — AllocateSpace writes volumes INTO a storage, Allocate
- *     DEFINES one — so it 403'd here until widened the way `Pool.Allocate` was for `Proxmox.Pool`.
- *     The provisioning baseline (`provision-baseline.ts`) carries `Datastore.Allocate`.
+ *   "Permission check failed (/storage/local, Datastore.Allocate)". So this family reads with
+ *   `provision`, same as acl.ts and unlike group.ts/user.ts — `provision-baseline.ts` carries
+ *   `Datastore.Allocate`.
+ *
+ * ⛔ ON A LANE WHOSE CREDENTIAL CANNOT MINT `provision` (the agent's `read`-role lane), THIS
+ *   FAMILY SHIPPED WITH THE ORIGINAL CRIES-WOLF BUG — measured live, 2026-09-24: `bun run plan`
+ *   showed all 5 storages (`cephfs-tb4`, `cephtb4`, `local`, `local-zfs`, `pbs`) as `update`, with
+ *   no warning, because `client.ts`'s `pveOperations.read` folded the REFUSED mint into `undefined`
+ *   the same way it folds a genuine absence — `unreadable-read.ts`'s own header names this family
+ *   by name as one of the two the fix was written for. Migrated here the way acl.ts/group.ts/
+ *   user.ts were (kit 0.31.1/0.31.2): a refused `provision` mint now reports `noop` with a logged
+ *   warning instead of forcing `update` with nothing compared.
+ *
+ * ⛔ A MISSING STORAGE IS A 500, NOT A 404 — MEASURED against the live cluster (TB4, 2026-09-24,
+ *   admin lane, read-only `GET /storage/hf-measure-nonexistent-probe`): `{"message":"storage
+ *   '...' does not exist\n"}` at HTTP 500. `storage-wire.ts`'s `readStorageOrFail`/`readStorage`
+ *   carry the same dual-path split as user.ts/group.ts for exactly this reason — see that file.
+ *
+ * ⛔ `maxfiles` IS GONE — A MEASURED `@distilled.cloud/proxmox` SDK GAP, NOT A SCOPE TRIM. The
+ *   vendor's generated `CreateStorageRequest`/`PutStorageRequest` (storage-wire.ts's `mutable`)
+ *   have no `maxfiles` field at all — grepped across the whole package, not just this endpoint —
+ *   where `prune-backups`, its documented replacement, is present and correctly wired
+ *   (`T.Body("prune-backups")` on the generated `prune_backups` property). Silently dropping a
+ *   declared `maxfiles` value would have been the same class of bug this whole migration exists to
+ *   close: a write that looks like it landed and did not. So `maxfiles?: never` below, the same
+ *   COMPILE-ERROR treatment `StorageLocator`'s `password`/`keyring`/`encryption-key` already get —
+ *   a declaration that sets it is refused before a plan ever runs, not silently ignored by one.
+ *   None of this cluster's 5 live storages set it (measured, live response bodies below). If a
+ *   consumer genuinely needs it, the fix belongs in `@distilled.cloud/proxmox`'s generator, not a
+ *   hand-rolled bypass here — see the provider-walk-down doctrine on vendor gaps.
+ *
+ * ⛔ EVERY HYPHENATED PVE FIELD NAME BECOMES AN UNDERSCORE IN DISTILLED'S GENERATED TYPESCRIPT —
+ *   MEASURED across the WHOLE generated `CreateStorageRequest`/`PutStorageRequest`, not one field:
+ *   `prune-backups` -> `prune_backups`, `fs-name` -> `fs_name`, `max-protected-backups` ->
+ *   `max_protected_backups`, and so on for every plugin field `StorageLocator`'s free-form bag can
+ *   carry (`cephfs-tb4`'s own live locator uses `fs-name`, measured below). No other family
+ *   migrated so far has a hyphenated field at all, so this is new here. `storage-wire.ts`'s
+ *   `underscored` translates a form BUILT with PVE's own names into distilled's shape, but ONLY
+ *   for the actual SDK call (`toDistilledCreate`/`toDistilledUpdate`) — never for the form
+ *   `guardWrite` checks (`createForm`/`updateForm`), which the generated vendor-constraint tables
+ *   key by PVE's own hyphenated names. Running the translation before that check would make it
+ *   silently stop inspecting the very fields it exists to catch.
  *
  * ⛔ THERE IS NO `password` PROP AND THERE MUST NEVER BE ONE. PBS and CIFS storages take one at
  *   create time, and Alchemy persists attributes UNENCRYPTED — a secret in props is one careless
@@ -33,25 +62,20 @@
  *   a COMPILE ERROR rather than a leak somebody finds in a backup months later. Set it once out of
  *   band (`pvesm set <id> --password`); PVE never returns it on read, so nothing here could diff it
  *   anyway.
+ *
+ * ★ MIGRATED OFF `client.ts`'s generic `pve()`/`pveHandlers` (`resource.ts`) ONTO
+ *   `@distilled.cloud/proxmox`'s typed `storage.getStorage`/`createStorage`/`putStorage`/
+ *   `deleteStorage` (2026-09-24, decision 43's proxmox walk-down, nodes/storage sub-area, first
+ *   resource). `distilled-pve.ts`'s `runPve` replaces `pve()`; the cries-wolf fix is wired the
+ *   same way as acl.ts/group.ts/user.ts.
  */
 import { Resource } from 'alchemy';
 import * as Provider from 'alchemy/Provider';
-import { type PveRequirements, type WithTarget } from './resource.ts';
-/**
- * The create-time, plugin-specific half of a storage: `dir` wants `path`, `nfs` `server`+`export`,
- * `cifs` `server`+`share`, `pbs` `server`+`datastore`, `rbd` `pool`+`monhost`, `lvmthin`
- * `vgname`+`thinpool`, `zfspool` `pool`. A bag rather than two dozen named fields, because PVE
- * ships about that many plugins and each brings its own locator. ⚠️ Never diffed — see `matches`.
- *
- * ⛔ `password`, `keyring` AND `encryption-key` ARE `never` ON PURPOSE — see the ⛔ in the header.
- *   POSITIVE-CONTROLLED rather than assumed: all three are a compile error, `TS2322: Type 'string'
- *   is not assignable to type 'undefined'`.
- */
-export type StorageLocator = Record<string, string> & {
-    password?: never;
-    keyring?: never;
-    'encryption-key'?: never;
-};
+import type { PveRequirements, WithTarget } from './resource-spec.ts';
+import type { StorageAttributes } from './storage-wire.ts';
+import type { StorageLocator } from './storage-form.ts';
+/** Re-exported so a caller of this file still finds them here, unchanged by the split below. */
+export type { StorageAttributes, StorageLocator };
 export interface StorageProps extends WithTarget {
     /** PVE's primary key, cluster-wide — the string an LXC's `storage` and `ostemplate` name. */
     storage: string;
@@ -81,41 +105,12 @@ export interface StorageProps extends WithTarget {
      */
     'prune-backups'?: string;
     comment?: string;
-    /**
-     * ⚠️ THE DEPRECATED PREDECESSOR OF `prune-backups`, and the two do not mix — declare one or the
-     *   other. `0` means UNLIMITED to PVE rather than "unset", hence the `-1` in the attribute.
-     */
-    maxfiles?: number;
-}
-export interface StorageAttributes {
-    storage: string;
-    /** Reported so a plan can show what it points at; never diffed — see `type` above. */
-    type: string;
-    content: string;
-    nodes: string;
-    disable: boolean;
-    shared: boolean;
-    preallocation: string;
-    'prune-backups': string;
-    comment: string;
-    /** ⚠️ `-1` means "no maxfiles in storage.cfg". `0` is a real setting meaning unlimited. */
-    maxfiles: number;
+    /** ⛔ REMOVED — a measured `@distilled.cloud/proxmox` gap, not a scope trim. See the header. */
+    maxfiles?: never;
 }
 export interface ProxmoxStorage extends Resource<'Proxmox.Storage', StorageProps, StorageAttributes, never, PveRequirements> {
 }
 /** ★ `retain` by default — a storage holding volumes cannot be rebuilt. See the ★ in resource.ts. */
 export declare const ProxmoxStorage: import("alchemy").ResourceClass<ProxmoxStorage>;
-/**
-* ⛔ EMPTY, AND HERE IT MATTERS MORE THAN ANYWHERE ELSE IN THIS PACKAGE. `GET /storage`
-*   returns every definition on the cluster, `local` and `local-lvm`/`local-zfs` included:
-*   the installer's own, that every guest's rootfs sits on. Adopting those would put
-*   Alchemy one `delete` away from the cluster's disks. Adoption is explicit, always.
- 
- *
-* ⚠️ THIS REMOVES THE DEFINITION, NOT THE DATA. PVE drops the section from storage.cfg and
-*   leaves the volumes on disk untouched — so the loss is not the bytes, it is that guests
-*   whose config still names this storage can no longer resolve their own disks.
- 
- */
 export declare const ProxmoxStorageProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxStorage>, never, import("effect/unstable/http/HttpClient").HttpClient>;
 //# sourceMappingURL=storage.d.ts.map

package/dist/proxmox/storage.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"storage.d.ts","sourceRoot":"","sources":["../../src/proxmox/storage.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAE7C,OAAO,EAAE,KAAK,eAAe,EAAE,KAAK,UAAU,EAAe,MAAM,eAAe,CAAC;AAGnF;;;;;;;;;GASG;AACH,MAAM,MAAM,cAAc,GAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG;IACpD,QAAQ,CAAC,EAAE,KAAK,CAAC;IACjB,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,gBAAgB,CAAC,EAAE,KAAK,CAAC;CAC1B,CAAC;AAEF,MAAM,WAAW,YAAa,SAAQ,UAAU;IAC9C,6FAA6F;IAC7F,OAAO,EAAE,MAAM,CAAC;IAChB;;;OAGG;IACH,IAAI,EAAE,MAAM,CAAC;IACb,kEAAkE;IAClE,OAAO,CAAC,EAAE,cAAc,CAAC;IACzB,wFAAwF;IACxF,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;OAGG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,mDAAmD;IACnD,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,yFAAyF;IACzF,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,uEAAuE;IACvE,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB;;;OAGG;IACH,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;OAGG;IACH,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,MAAM,CAAC;IAChB,sFAAsF;IACtF,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,OAAO,CAAC;IAChB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,OAAO,EAAE,MAAM,CAAC;IAChB,2FAA2F;IAC3F,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,MAAM,WAAW,cAAe,SAAQ,QAAQ,CAC9C,iBAAiB,EACjB,YAAY,EACZ,iBAAiB,EACjB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,qGAAqG;AACrG,eAAO,MAAM,cAAc,iDAEzB,CAAC;AAkHH;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,sBAAsB,oIACoD,CAAC"}
+{"version":3,"file":"storage.d.ts","sourceRoot":"","sources":["../../src/proxmox/storage.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsEG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AAEnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAI7C,OAAO,KAAK,EAAE,eAAe,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAC;AAYtE,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,mBAAmB,CAAC;AAC3D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AAExD,gGAAgG;AAChG,YAAY,EAAE,iBAAiB,EAAE,cAAc,EAAE,CAAC;AAElD,MAAM,WAAW,YAAa,SAAQ,UAAU;IAC9C,6FAA6F;IAC7F,OAAO,EAAE,MAAM,CAAC;IAChB;;;OAGG;IACH,IAAI,EAAE,MAAM,CAAC;IACb,kEAAkE;IAClE,OAAO,CAAC,EAAE,cAAc,CAAC;IACzB,wFAAwF;IACxF,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;OAGG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,mDAAmD;IACnD,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,yFAAyF;IACzF,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,uEAAuE;IACvE,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB;;;OAGG;IACH,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,+FAA+F;IAC/F,QAAQ,CAAC,EAAE,KAAK,CAAC;CAClB;AAED,MAAM,WAAW,cAAe,SAAQ,QAAQ,CAC9C,iBAAiB,EACjB,YAAY,EACZ,iBAAiB,EACjB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,qGAAqG;AACrG,eAAO,MAAM,cAAc,iDAEzB,CAAC;AAEH,eAAO,MAAM,sBAAsB,oIAgGhC,CAAC"}

package/dist/proxmox/zfs-pool-form.d.ts

@@ -0,0 +1,124 @@
+/**
+ * The create lane for `Proxmox.ZfsPool`: the form PVE wants, and the wait for the worker it forks.
+ * Split out of zfs-pool.ts (2026-09-24, the distilled migration) — same seam as before, now naming
+ * the write side the way storage.ts/storage-form.ts does.
+ *
+ * ⚠️ `createPool` TAKES THE READ AS A PARAMETER, GENERIC IN ITS ERROR AND REQUIREMENT CHANNELS,
+ *   rather than importing the read module and coupling to its exact effect shape here. This file
+ *   answers "how does a declaration become a pool on disks"; zfs-pool-wire.ts answers "what is a
+ *   zpool, and when has it changed" — the caller (zfs-pool.ts) is what ties the two together, so
+ *   this file cannot accidentally read the cluster differently from `diff`.
+ */
+import * as Effect from 'effect/Effect';
+import * as nodes from '@distilled.cloud/proxmox/nodes';
+import type { ZfsPoolAttributes, ZfsPoolProps } from './zfs-pool.ts';
+import type { NodesNodeDisksZfsPostParams } from './generated/pve.ts';
+export declare const ZFS_POOL_CREATE = "pve:POST /nodes/{node}/disks/zfs";
+/**
+ * PVE's layouts, generated (2026-09-23) from `NodesNodeDisksZfsPostParams['raidlevel']`
+ * (`generated/pve.ts`, manifest `pve-apidoc` pve-manager 9.2.11 sha256 9def8f13…) rather than
+ * hand-typed, per decision 9. ⚠️ Each has a minimum disk count PVE enforces, and `raid10` needs an
+ * even one. ⛔ THERE IS NO `stripe` IN THIS ENUM. n1's `speed` pool is one (decision 14 accepts it
+ * as-is): `ZfsPoolProps` (zfs-pool.ts) is why a stripe pool is declarable at all — as an
+ * ADOPT-ONLY declaration with no `raidlevel`, never as a full one.
+ */
+export type ZfsRaidLevel = NonNullable<NodesNodeDisksZfsPostParams['raidlevel']>;
+/** Generated the same way, from `NodesNodeDisksZfsPostParams['compression']`. */
+export type ZfsCompression = NonNullable<NodesNodeDisksZfsPostParams['compression']>;
+/**
+ * ★ CHECKED AGAINST THE VENDOR TABLE ONLY FOR A FULL DECLARATION — decision 9's adopt-only mode.
+ *   `guardCreate` (distilled-guard.ts's `guardWrite`) runs on the FIRST plan of ANY declaration and
+ *   checks the create form's REQUIRED fields whenever this resolves to the real endpoint key — and
+ *   PVE marks both `devices` and `raidlevel` required (codegen/constraints's `pve-nodes-disks`
+ *   row). An adopt-only declaration deliberately omits both, so checking it would refuse a MATCHING
+ *   adoption at plan time, before `read` ever ran. Returning `undefined` (no key) makes the guard a
+ *   no-op for an adopt-only declaration, while a FULL one (`devices` and `raidlevel` both present)
+ *   is checked exactly as before — zfs-pool.ts's `diff` passes this as the `guardWrite` endpoint.
+ * ⚠️ THE RUNTIME BACKSTOP IS `createPool` BELOW, NOT THIS FUNCTION. Skipping the plan-time guard
+ *   for an adopt-only declaration does not skip the check that the pool is actually there —
+ *   `createPool` refuses before any POST when the read comes back absent and either field is
+ *   undefined, which is what a genuinely absent adopt-only declaration hits at apply time.
+ */
+export declare const zfsPoolCreateEndpoint: (props: ZfsPoolProps) => "pve:POST /nodes/{node}/disks/zfs" | undefined;
+/**
+ * The wire form, PVE's own field names — what `guardWrite` (zfs-pool.ts) checks.
+ *
+ * ⚠️ `devices` IS JOINED IN DECLARED ORDER AND NOT PUT THROUGH `csv()` FROM values.ts. `csv` sorts,
+ *   and PVE walks this list two at a time to pair `raid10` mirrors — MEASURED in the node's own
+ *   `PVE::API2::Disks::ZFS` — so sorting it builds a different pool from the one declared. The list
+ *   is never compared against anything, so it needs no normalisation, only faithful order.
+ * ⚠️ AN OMITTED OPTIONAL IS NOT SENT. PVE's own defaults (ashift 12, compression on) are then
+ *   applied by the node. Sending a guessed default would be indistinguishable here — the values
+ *   are unreadable afterwards either way — but it would put a number in the request that no
+ *   declaration asked for, and this is the one call that writes to physical disks.
+ * ⚠️ `node` IS NOT IN THE FORM: it is the `nodes/{node}` path label, and a second copy could only
+ *   disagree with it.
+ * ⚠️ EVERY KEY IS OMITTED WHEN ABSENT, `devices` AND `raidlevel` INCLUDED — not just the optional
+ *   ones. An adopt-only declaration (both undefined, decision 9) must produce a form `createPool`'s
+ *   own guard can inspect for their absence, and one this function itself does not throw building.
+ */
+export declare const createForm: (props: ZfsPoolProps) => Record<string, string>;
+/**
+ * Create the pool if it is absent, and otherwise leave it completely alone.
+ *
+ * ⛔ THE POST ONLY FORKS A WORKER. MEASURED in `/usr/share/perl5/PVE/API2/Disks/ZFS.pm` on node-b:
+ *   the create handler ends in `$rpcenv->fork_worker('zfscreate', ...)` and its HTTP answer is a
+ *   UPID returned the instant the worker is forked — before `zpool create` has run, let alone
+ *   finished. A read-back taken immediately would report a successful create as the failure "the
+ *   write returned no error but the object is still absent". THAT is why this function polls.
+ *
+ * ⚠️ THERE IS NO UPDATE BRANCH BECAUSE PVE HAS NO PUT HERE. An existing pool is returned exactly as
+ *   read, unwritten: the only write this resource ever makes is the create of a pool that is not
+ *   there. Do not add a "repair" write; there is no field it could set.
+ *
+ * ⛔ AND IF THE READ IS WRONG, THE POST IS STILL SAFE — measured, not hoped for. `readPool` folds a
+ *   403 or an unreachable node into "absent", so a too-narrow lease would send this down the create
+ *   path over a live pool. PVE's handler calls `get_pool_data()` before it forks anything and dies
+ *   with "pool '<name>' already exists on node '<node>'", and `assert_disk_unused` refuses every
+ *   device that pool is holding. A create aimed at a pool that is really there fails loudly rather
+ *   than wiping it.
+ *
+ * ⚠️ SHORT POLLS WITH A HARD CAP, NOT ONE LONG WAIT, NOT `@distilled.cloud/proxmox`'s `awaitTask`.
+ *   `readPool` cannot tell "not yet" from "forbidden" — both fold to `undefined` — so the loop
+ *   gives up with the UPID rather than retrying forever, and the UPID is the only thing that leads
+ *   to the worker's real error. Distilled's own task-status poller exists (`Task.ts`) and would
+ *   remove this ambiguity, but swapping to it changes this resource's OBSERVABLE behaviour (what a
+ *   caller sees on a slow create) beyond a transport swap — left as a follow-up, not folded into a
+ *   migration PR silently.
+ *
+ * ⛔ THE SAME AMBIGUITY MAKES A RE-RUN AFTER THE GIVE-UP DIE GENUINELY UNSAFE, NOT MERELY SLOW TO
+ *   CONFIRM — FOUND BY ADVERSARIAL REVIEW, 2026-09-24, of THIS migration, though the shape is
+ *   unchanged from before it (`git blame` shows the same settle-poll pre-dates this PR). "If the
+ *   read is wrong, the POST is still safe" above is true for the FIRST call into this function —
+ *   PVE's own `get_pool_data()` refuses a create over a pool it can already see. It is NOT true
+ *   for a SECOND deploy attempt started while the FIRST worker is still mid-`zpool create`: that
+ *   worker has not yet made the pool visible to a read, so `existing = yield* read(props)` at the
+ *   top of THIS call can also fold to `undefined` — not because the pool is gone, but because the
+ *   first attempt has not finished — and this function would POST a SECOND `zpool create` at the
+ *   SAME devices while the first is still writing them. There is no lock or marker anywhere in
+ *   this package that would stop it. The give-up message below says so explicitly and names the
+ *   task log to check FIRST; that message, and an operator reading it, are the only safeguard.
+ *
+ * ⛔ THE ADOPT-ONLY GUARD, RIGHT AFTER THE READ AND BEFORE ANYTHING ELSE. Decision 9 (2026-09-23):
+ *   omitting `devices` and `raidlevel` declares a pool this resource may only ADOPT, for a pool
+ *   PVE's own schema cannot fully describe — n1's `speed` is a stripe, and `raidlevel`'s enum has
+ *   no stripe (zfs-pool.ts). `zfsPoolCreateEndpoint` above already keeps the vendor constraint
+ *   guard from refusing such a declaration at PLAN time; this is the matching refusal at APPLY
+ *   time, for the one case that guard cannot see — the pool genuinely is not there.
+ */
+export declare const createPool: <E, R>(props: ZfsPoolProps, read: (props: ZfsPoolProps) => Effect.Effect<ZfsPoolAttributes | undefined, E, R>) => Effect.Effect<ZfsPoolAttributes, E | Error | import("effect/unstable/http/HttpClientError").HttpClientError | import("./credential-errors.ts").PveCredentialDenied, R | import("effect/unstable/http/HttpClient").HttpClient>;
+/**
+ * ⛔ `DELETE /nodes/{node}/disks/zfs/{name}` RUNS `zpool destroy` AND THE DATASETS GO WITH IT. Per
+ *   S14 (alchemy-provider-standard), it is implemented rather than stubbed — a `delete` that
+ *   silently does nothing lies to whoever reads the plan — and what keeps an ordinary removed
+ *   declaration from reaching it is the resource's `defaultRemovalPolicy: 'retain'` (zfs-pool.ts):
+ *   an orphaned pool is forgotten, not destroyed, unless a caller opts in with
+ *   `.pipe(RemovalPolicy.destroy())`. See the corrected header in zfs-pool.ts.
+ *
+ * ⚠️ `cleanup-config`/`cleanup-disks` ARE NOT SENT. The first would additionally remove the PVE
+ *   storage entry pointing at this pool, which is a different object with its own resource
+ *   (`Proxmox.Storage`); one resource reaching over to delete another's is how a stack ends up with
+ *   state describing something that is gone. Neither is offered as a prop, for the same reason.
+ */
+export declare const destroyPool: (props: ZfsPoolProps) => Effect.Effect<string, Error | import("./distilled-pve.ts").PveClusterExhausted | import("./credential-errors.ts").PveCredentialDenied | import("effect/Cause").TimeoutError | nodes.ProxmoxOpError, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=zfs-pool-form.d.ts.map

package/dist/proxmox/zfs-pool-form.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"zfs-pool-form.d.ts","sourceRoot":"","sources":["../../src/proxmox/zfs-pool-form.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AACH,OAAO,KAAK,MAAM,MAAM,eAAe,CAAC;AACxC,OAAO,KAAK,KAAK,MAAM,gCAAgC,CAAC;AAKxD,OAAO,KAAK,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,eAAe,CAAC;AACrE,OAAO,KAAK,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AAEtE,eAAO,MAAM,eAAe,qCAAqC,CAAC;AAElE;;;;;;;GAOG;AACH,MAAM,MAAM,YAAY,GAAG,WAAW,CAAC,2BAA2B,CAAC,WAAW,CAAC,CAAC,CAAC;AAEjF,iFAAiF;AACjF,MAAM,MAAM,cAAc,GAAG,WAAW,CAAC,2BAA2B,CAAC,aAAa,CAAC,CAAC,CAAC;AAErF;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,qBAAqB,UAAW,YAAY,mDACmC,CAAC;AAE7F;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAOpE,CAAC;AA0BH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+CG;AACH,eAAO,MAAM,UAAU,GAAI,CAAC,EAAE,CAAC,SACtB,YAAY,QACb,CAAC,KAAK,EAAE,YAAY,KAAK,MAAM,CAAC,MAAM,CAAC,iBAAiB,GAAG,SAAS,EAAE,CAAC,EAAE,CAAC,CAAC,kOA8D/E,CAAC;AAEL;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,WAAW,UAAW,YAAY,8PAM5C,CAAC"}

package/dist/proxmox/zfs-pool-wire.d.ts

@@ -0,0 +1,78 @@
+import * as Effect from 'effect/Effect';
+import type { ZfsPoolProps } from './zfs-pool.ts';
+import { UNREADABLE, type Unreadable } from './unreadable-read.ts';
+/**
+ * ⚠️ EVERYTHING HERE IS REPORTED, NOTHING HERE IS COMPARED — see the ⛔ on `matches` below. These
+ *   exist so a plan and the state store can say what the pool actually is, on a family where the
+ *   declaration and the live object share no comparable field at all.
+ */
+export interface ZfsPoolAttributes {
+    /** ★ The value a `Proxmox.Storage` should read to order itself after this pool. */
+    name: string;
+    node: string;
+    /** `ONLINE` | `DEGRADED` | `FAULTED` | … Health, not configuration. */
+    state: string;
+    /** ZFS's own error summary, e.g. `No known data errors`. */
+    errors: string;
+    /**
+     * The leaf devices ZFS reports, in vdev order, comma-joined.
+     *
+     * ⚠️ THIS IS WHAT ZFS RESOLVED, NOT WHAT WAS DECLARED, and the two normally differ: PVE rewrites
+     *   a `/dev/sdb` into a by-id link before creating, and ZFS reports partition paths (`…-part3`)
+     *   for a pool built on partitions — MEASURED, that is exactly what node-b's `rpool` reports.
+     *   Never compare it with `props.devices`.
+     */
+    devices: string;
+}
+/**
+ * The device paths at the bottom of PVE's vdev tree, in the order ZFS reports them.
+ *
+ * ⚠️ "NO CHILDREN" IS THE LEAF TEST, AND IT IS NOT A GUESS — MEASURED in the node's `preparetree`,
+ *   which sets `leaf` to 0 when there are children and 1 otherwise. Reading the flag would work
+ *   equally well; recursing on `children` needs no second field to be present and is what makes
+ *   nested sections (mirrors inside a raid10, `spares`, `cache`) flatten correctly.
+ */
+export declare const leafDevices: (children: unknown) => string[];
+/**
+ * ★ Default `read` role — `Sys.Audit` on `/` is all this GET checks (zfs-pool.ts's header).
+ * ⛔ `{ node: props.node, name: props.name }`, NEVER THE WHOLE `props` — storage.ts's/user.ts's own
+ *   ⛔, the kit 0.31.1 regression: `GetNodeDiskZfsRequest`'s schema declares only `node` and `name`
+ *   (both path labels); any OTHER key on the object passed to `nodes.getNodeDiskZfs` is treated by
+ *   distilled's `buildRequest` as an "unknown key" and JSON-encoded onto this bodyless GET, which a
+ *   stricter fetch client refuses outright.
+ * ⛔ A MISSING POOL IS A 500, NOT A 404 — MEASURED against the live cluster (TB4 n2, 2026-09-24,
+ *   read-role, read-only probe): `GET /nodes/n2/disks/zfs/hf-measure-nonexistent-pool` answers
+ *   `{"message":"command '/sbin/zpool status -P hf-measure-nonexistent-pool' failed: exit code
+ *   1\n","data":null}` at HTTP 500 — PVE shells out to `zpool status` and reports its exit code
+ *   as a generic command failure, not a typed "not found". The same shape as user.ts's/group.ts's/
+ *   storage.ts's own measured 500s. `readPool` below (used by `createPool`'s settle-poll and by
+ *   `reconcile`/`read`) still folds it, exactly as `readUser`/`readGroup`/`readStorage` do — the
+ *   whole reason `createPool` can tell "not built yet" from "forbidden" only by giving up after
+ *   `SETTLE_ATTEMPTS` (zfs-pool-form.ts's own ⚠️ on that); `readPoolOrFail` (used by `diff`) does
+ *   not fold it, so a genuine transient failure there propagates and fails the plan loudly instead.
+ */
+export declare const readPoolOrFail: (props: ZfsPoolProps) => Effect.Effect<typeof UNREADABLE | ZfsPoolAttributes | undefined, import("@distilled.cloud/caddy").BadGateway | import("@distilled.cloud/caddy").BadRequest | import("@distilled.cloud/caddy").ConfigError | Error | import("@distilled.cloud/caddy").GatewayTimeout | import("effect/unstable/http/HttpClientError").HttpClientError | import("@distilled.cloud/caddy").InternalServerError | import("@distilled.cloud/proxmox/Errors").ParameterVerificationFailed | import("@distilled.cloud/proxmox/Errors").ProxmoxParseError | import("./distilled-pve.ts").PveClusterExhausted | import("@distilled.cloud/caddy").ServiceUnavailable | import("effect/Cause").TimeoutError | import("@distilled.cloud/caddy").TooManyRequests | import("@distilled.cloud/caddy").Unauthorized | import("@distilled.cloud/proxmox/Errors").UnknownProxmoxError, import("effect/unstable/http/HttpClient").HttpClient>;
+/**
+ * ⛔ FOLDS A GENUINE READ FAILURE TO `undefined` TOO, AND ONLY `createPool`'s settle-poll AND
+ *   `read`/`reconcile` MAY USE IT — user.ts's `readUser` has the full reasoning. Safe here because
+ *   a wrongful fold during create costs at most a redundant `createNodeDiskZfs` POST, which PVE
+ *   refuses loudly ("pool already exists") rather than silently corrupting anything — zfs-pool.ts's
+ *   own header, measured.
+ * ⛔ `zfs-pool.ts`'s `diff` does **NOT** use this — the same bug class as the credential denial fix:
+ *   folding a TRANSIENT failure into "absent" at PLAN TIME would force a false `update` with
+ *   nothing compared. `diff` calls `readPoolOrFail` directly, so a genuine failure there propagates
+ *   and fails the whole plan loudly instead.
+ */
+export declare const readPool: (props: ZfsPoolProps) => Effect.Effect<typeof UNREADABLE | ZfsPoolAttributes | undefined, never, import("effect/unstable/http/HttpClient").HttpClient>;
+/** `read`/`reconcile`/`createPool` return `Attributes | undefined`; only `diff` sees `UNREADABLE`. */
+export declare const dropUnreadable: (live: ZfsPoolAttributes | Unreadable | undefined) => ZfsPoolAttributes | undefined;
+/**
+ * ⛔ THERE IS NO `matches` FUNCTION HERE — UNLIKE EVERY OTHER MIGRATED FAMILY, AND DELIBERATELY.
+ *   Every create parameter on this family is write-only (this file's own `attributesOf`), so
+ *   there is nothing a declaration and a live pool can ever be compared on — a `matches` that
+ *   invented one would plan a replace (`zpool destroy`, since this family has no PUT) over a
+ *   difference it could never verify. `zfs-pool.ts`'s `diff` returns `noop` unconditionally once a
+ *   pool is found, rather than calling a function that would only ever return `true` — found by
+ *   adversarial review that an earlier draft exported one here anyway, unused by anything.
+ */
+//# sourceMappingURL=zfs-pool-wire.d.ts.map

package/dist/proxmox/zfs-pool-wire.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"zfs-pool-wire.d.ts","sourceRoot":"","sources":["../../src/proxmox/zfs-pool-wire.ts"],"names":[],"mappings":"AAMA,OAAO,KAAK,MAAM,MAAM,eAAe,CAAC;AAExC,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,eAAe,CAAC;AAClD,OAAO,EAAE,UAAU,EAAE,KAAK,UAAU,EAAoB,MAAM,sBAAsB,CAAC;AAGrF;;;;GAIG;AACH,MAAM,WAAW,iBAAiB;IAChC,mFAAmF;IACnF,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,uEAAuE;IACvE,KAAK,EAAE,MAAM,CAAC;IACd,4DAA4D;IAC5D,MAAM,EAAE,MAAM,CAAC;IACf;;;;;;;OAOG;IACH,OAAO,EAAE,MAAM,CAAC;CACjB;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,WAAW,aAAc,OAAO,KAAG,MAAM,EAO9C,CAAC;AAmBT;;;;;;;;;;;;;;;;;GAiBG;AACH,eAAO,MAAM,cAAc,UAAW,YAAY,+2BAe/C,CAAC;AAEJ;;;;;;;;;;GAUG;AACH,eAAO,MAAM,QAAQ,UAAW,YAAY,kIACuB,CAAC;AAEpE,sGAAsG;AACtG,eAAO,MAAM,cAAc,SAAU,iBAAiB,GAAG,UAAU,GAAG,SAAS,kCACvC,CAAC;AAEzC;;;;;;;;GAQG"}

package/dist/proxmox/zfs-pool.d.ts

@@ -26,14 +26,14 @@
  * ⛔ THERE IS NO PUT ON THIS FAMILY AT ALL. MEASURED from the cluster's own published schema
  *   (`/usr/share/pve-docs/api-viewer/apidoc.js`, read on node-b 2026-09-13): `/nodes/{node}/disks/zfs`
  *   has GET and POST, `/nodes/{node}/disks/zfs/{name}` has GET and DELETE, and that is the whole
- *   surface. So `updateForm` is omitted — which, per `resource.ts`, makes any `matches` = false a
- *   REPLACE. A replace is a delete followed by a create, and on this family the delete is the
- *   thing above. Read the ⛔ on `matches` before adding anything to it.
+ *   surface — CONFIRMED again in `@distilled.cloud/proxmox`'s generated `nodes.ts`, which declares
+ *   no `putNodeDiskZfs` at all. So `matches` (zfs-pool-wire.ts) always answers `true`: there is
+ *   nothing to plan a replace over, and the family's one write is the create below.
  *
  * ⛔ NOT ONE CREATE PARAMETER COMES BACK ON READ, SO `matches` COMPARES NOTHING. MEASURED against
- *   the live cluster: `GET /nodes/node-b/disks/zfs/rpool` answers exactly
- *   `{action, children, errors, leaf, name, scan, state, status}` — no `ashift`, no `compression`,
- *   no `raidlevel`, no `devices`, no `add_storage`. Every create parameter is write-only. There is
+ *   the live cluster: `GET /nodes/n2/disks/zfs/rpool` answers exactly
+ *   `{action?, children, errors, name, scan?, state, status?}` — no `ashift`, no `compression`, no
+ *   `raidlevel`, no `devices`, no `add_storage`. Every create parameter is write-only. There is
  *   therefore no field a declaration and a live pool can both be asked about, and a `matches` that
  *   invented one would plan a replace — i.e. a `zpool destroy` — over a difference it could never
  *   verify in the first place.
@@ -46,11 +46,20 @@
  *   is compared, and the three churning strings are kept out of the state store entirely rather
  *   than rewriting this resource's row every time somebody writes a file.
  *
- * ⚠️ TWO HANDLERS ARE OVERRIDDEN AND THE OTHER THREE COME FROM THE FACTORY — see the ★ above
- *   `handlers`. `delete` is the ⛔ above. `reconcile` is because the create is a FORKED WORKER, so
- *   the factory's immediate read-back would report a successful create as a failure; the measured
- *   detail, and the adopt-only refusal decision 9 adds, are both in `createPool` in
- *   zfs-pool-write.ts.
+ * ⛔ A MISSING POOL IS A 500, NOT A 404 — MEASURED against the live cluster (TB4 n2, 2026-09-24,
+ *   read-role, read-only probe): `GET /nodes/n2/disks/zfs/hf-measure-nonexistent-pool` answers a
+ *   generic shelled-out command failure at HTTP 500, the same shape as every other family this
+ *   package has migrated. `zfs-pool-wire.ts` carries the same dual-path read PR 239/243
+ *   established: `readPoolOrFail` (non-folding, used by `diff`) and `readPool` (folding, used by
+ *   `createPool`'s settle-poll and by `read`/`reconcile`).
+ *
+ * ★ MIGRATED OFF `client.ts`'s generic `pve()`/`pveOperations` ONTO `@distilled.cloud/proxmox`'s
+ *   typed `nodes.getNodeDiskZfs`/`createNodeDiskZfs`/`deleteNodeDiskZfs` (2026-09-24, decision
+ *   43's proxmox walk-down, nodes/storage sub-area). `distilled-pve.ts`'s `runPve` replaces
+ *   `pve()`; the cries-wolf fix is wired the same way as every other migrated family. `reconcile`
+ *   and `delete` are still hand-written (never the factory) for the SAME two reasons as before the
+ *   migration — the forked-worker settle-poll, and a DELETE that destroys data — now calling
+ *   `zfs-pool-form.ts`'s `createPool`/`destroyPool` directly instead of through `pveHandlers`.
  *
  * ⚠️ PRIVILEGES, FROM THE SCHEMA. Read and diff need `Sys.Audit` on `/` — both GETs check it.
  *   Reconcile needs `Sys.Modify` on `/` for the POST. `Datastore.Allocate` on `/storage` is NOT
@@ -60,26 +69,15 @@
  *   family checks it, not only the POST. MEASURED the same day as the rest of this paragraph:
  *   `ceph-osd.ts`'s own privilege comparison names `disks/zfs` as one of the sibling families
  *   whose write verbs DO carry a `Sys.Modify` check, unlike `ceph/osd`'s create and delete, which
- *   carry no permissions block at all and 403 for any identity but `root@pam`. This line
- *   previously said delete "needs nothing at all, since it calls nothing", which repeated the same
- *   mistake the header above corrects: `delete` calls the DELETE endpoint, so it needs whatever
- *   that endpoint checks.
+ *   carry no permissions block at all and 403 for any identity but `root@pam`.
  */
 import { Resource } from 'alchemy';
 import * as Provider from 'alchemy/Provider';
-import type { NodesNodeDisksZfsPostParams } from './generated/pve.ts';
-import { type PveRequirements, type WithTarget } from './resource.ts';
-/**
- * PVE's layouts, generated (2026-09-23) from `NodesNodeDisksZfsPostParams['raidlevel']`
- * (`generated/pve.ts`, manifest `pve-apidoc` pve-manager 9.2.11 sha256 9def8f13…) rather than
- * hand-typed, per decision 9. ⚠️ Each has a minimum disk count PVE enforces, and `raid10` needs an
- * even one. ⛔ THERE IS NO `stripe` IN THIS ENUM. n1's `speed` pool is one (decision 14 accepts it
- * as-is): `ZfsPoolProps` below is why a stripe pool is declarable at all — as an ADOPT-ONLY
- * declaration with no `raidlevel`, never as a full one.
- */
-export type ZfsRaidLevel = NonNullable<NodesNodeDisksZfsPostParams['raidlevel']>;
-/** Generated the same way, from `NodesNodeDisksZfsPostParams['compression']`. */
-export type ZfsCompression = NonNullable<NodesNodeDisksZfsPostParams['compression']>;
+import type { PveRequirements, WithTarget } from './resource-spec.ts';
+import type { ZfsPoolAttributes } from './zfs-pool-wire.ts';
+import type { ZfsCompression, ZfsRaidLevel } from './zfs-pool-form.ts';
+export type { ZfsPoolAttributes } from './zfs-pool-wire.ts';
+export type { ZfsCompression, ZfsRaidLevel } from './zfs-pool-form.ts';
 /**
  * ⛔ THERE IS NO `add_storage`, `cleanup-config` OR `cleanup-disks` PROP, AND THAT IS NOT AN
  *   OVERSIGHT. The last two belong to the DELETE this resource refuses to make. `add_storage=1`
@@ -116,7 +114,7 @@ export interface ZfsPoolProps extends WithTarget {
      *   both this and `raidlevel` undeclared declares an ADOPT-ONLY pool — one this resource may
      *   read and report but never build. That is the only shape available for a pool PVE's own POST
      *   schema cannot fully describe, such as n1's `speed`, whose layout is a stripe and whose
-     *   `raidlevel` enum (above) has no stripe to declare. `createForm` (zfs-pool-write.ts) omits
+     *   `raidlevel` enum (above) has no stripe to declare. `createForm` (zfs-pool-form.ts) omits
      *   both keys when they are absent, and `createPool` refuses before any POST if the pool it
      *   would need to build is not already there — an adopt-only declaration never creates. Declare
      *   both fields together for a pool this resource should build from scratch; declaring only one
@@ -145,29 +143,6 @@ export interface ZfsPoolProps extends WithTarget {
      */
     'draid-config'?: string;
 }
-/**
- * ⚠️ EVERYTHING HERE IS REPORTED, NOTHING HERE IS COMPARED — see the ⛔ on `matches`. These exist
- *   so a plan and the state store can say what the pool actually is, on a family where the
- *   declaration and the live object share no comparable field at all.
- */
-export interface ZfsPoolAttributes {
-    /** ★ The value a `Proxmox.Storage` should read to order itself after this pool. */
-    name: string;
-    node: string;
-    /** `ONLINE` | `DEGRADED` | `FAULTED` | … Health, not configuration. */
-    state: string;
-    /** ZFS's own error summary, e.g. `No known data errors`. */
-    errors: string;
-    /**
-     * The leaf devices ZFS reports, in vdev order, comma-joined.
-     *
-     * ⚠️ THIS IS WHAT ZFS RESOLVED, NOT WHAT WAS DECLARED, and the two normally differ: PVE rewrites
-     *   a `/dev/sdb` into a by-id link before creating, and ZFS reports partition paths (`…-part3`)
-     *   for a pool built on partitions — MEASURED, that is exactly what node-b's `rpool` reports. Never
-     *   compare it with `props.devices`.
-     */
-    devices: string;
-}
 export interface ProxmoxZfsPool extends Resource<'Proxmox.ZfsPool', ZfsPoolProps, ZfsPoolAttributes, never, PveRequirements> {
 }
 /** ★ `retain` by default — a pool holding datasets cannot be rebuilt. See the ★ in resource.ts. */