@homeflare/alchemy 0.1.0

package/dist/proxmox/pool.d.ts

@@ -0,0 +1,42 @@
+/**
+ * `Proxmox.Pool` — a PVE resource pool. Guests grouped for permissions and quota.
+ *
+ * ★ PROVEN END TO END AGAINST THE LIVE CLUSTER, 2026-09-13. create -> verified with `pvesh get
+ *   /pools` on the node rather than by believing Alchemy; second plan -> `no changes / noop`; then
+ *   the comment was edited ON THE CLUSTER and plan said `1 to update`, and a deploy repaired it.
+ *   That drift case is the one that matters: `diff` reads the LIVE pool, so a provider trusting
+ *   its own state would have reported noop straight past a hand-edit in the UI.
+ *
+ * ⚠️ IT 403'd UNTIL THE ROLE WAS WIDENED, AND THE HISTORY IS WORTH KEEPING. `hf-provision@pve`
+ *   held `LXCProvisioner` on `/` with no `Pool.Allocate`, so reconcile answered
+ *   "Permission check failed (/pool/house, Pool.Allocate)". The credential could not widen itself
+ *   — `PUT /access/roles` is 403 for it too — so the role was extended over SSH with
+ *   `pveum role modify LXCProvisioner --privs "<existing>,Pool.Allocate,Pool.Audit"`, preserving
+ *   every existing privilege. Each new resource in this package should state the privileges its
+ *   reconcile needs, so widening stays a deliberate act rather than a reaction to a 403.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import type { PoolsPoolidPutParams, PoolsPostParams } from './generated/pve.ts';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+export interface PoolProps extends WithTarget {
+    /** PVE's primary key for a pool. Changing it is a replace, not an update. */
+    poolid: string;
+    /** Free text shown in the UI — the only mutable field a pool has. */
+    comment?: string;
+}
+export interface PoolAttributes {
+    poolid: string;
+    comment: string;
+    /** Guests currently in the pool, so a plan can say what a delete would refuse to orphan. */
+    members: number;
+}
+export interface ProxmoxPool extends Resource<'Proxmox.Pool', PoolProps, PoolAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxPool: import("alchemy").ResourceClass<ProxmoxPool>;
+/** Form bodies this family sends — exported for the drift test in pool.test.ts. */
+export declare const poolCreateForm: (props: PoolProps) => PoolsPostParams;
+/** PUT body — only `comment`; path carries `poolid`. Matches deprecated `/pools/{poolid}`. */
+export declare const poolUpdateForm: (props: PoolProps) => Pick<PoolsPoolidPutParams, 'comment'>;
+export declare const ProxmoxPoolProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxPool>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=pool.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"pool.d.ts","sourceRoot":"","sources":["../../src/proxmox/pool.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAE7C,OAAO,KAAK,EAEV,oBAAoB,EACpB,eAAe,EAChB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EAAE,KAAK,eAAe,EAAE,KAAK,UAAU,EAAe,MAAM,eAAe,CAAC;AAEnF,MAAM,WAAW,SAAU,SAAQ,UAAU;IAC3C,6EAA6E;IAC7E,MAAM,EAAE,MAAM,CAAC;IACf,qEAAqE;IACrE,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED,MAAM,WAAW,cAAc;IAC7B,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,4FAA4F;IAC5F,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,WAAY,SAAQ,QAAQ,CAC3C,cAAc,EACd,SAAS,EACT,cAAc,EACd,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,WAAW,8CAAwC,CAAC;AAEjE,mFAAmF;AACnF,eAAO,MAAM,cAAc,UAAW,SAAS,KAAG,eAGhD,CAAC;AAEH,8FAA8F;AAC9F,eAAO,MAAM,cAAc,UAAW,SAAS,KAAG,IAAI,CAAC,oBAAoB,EAAE,SAAS,CAEpF,CAAC;AAkBH,eAAO,MAAM,mBAAmB,iIACiD,CAAC"}

package/dist/proxmox/qemu.d.ts

@@ -0,0 +1,46 @@
+/**
+ * `Proxmox.Vm` — a QEMU virtual machine, declared.
+ *
+ * ⚠️ THE SAME FOUR OPERATIONS AS AN LXC OVER A DIFFERENT PATH, which is the point of the factory:
+ *   `nodes/{node}/qemu` to create, `nodes/{node}/qemu/{vmid}/config` to read and update. A VM and a
+ *   container differ in what they carry, not in how they are reconciled.
+ *
+ * ⛔ `vmid` IS CLUSTER-WIDE AND SHARED WITH CONTAINERS. A VM and an LXC cannot hold the same id, so
+ *   these two resources compete for one number space. Declaring both with vmid 101 is not a
+ *   collision Alchemy can see -- they are different resource types -- and PVE refuses the second
+ *   with "already exists". Pick ids per cluster, not per kind.
+ *
+ * ⚠️ POWER STATE IS REPORTED, NEVER DECLARED. `status` is an attribute so a plan can show it; there
+ *   is no `running` prop. Starting and stopping a VM from a plan would make a deploy a maintenance
+ *   window, and the estate has one of those already.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+export interface VmProps extends WithTarget {
+    node: string;
+    /** ⛔ Cluster-wide, and shared with LXC. See the ⛔ above. */
+    vmid: number;
+    name?: string;
+    /** MiB. */
+    memory?: number;
+    cores?: number;
+    sockets?: number;
+    /** e.g. `virtio=<mac>,bridge=vmbr0`. */
+    net0?: string;
+    onboot?: boolean;
+}
+export interface VmAttributes {
+    vmid: number;
+    node: string;
+    name: string;
+    memory: number;
+    cores: number;
+    sockets: number;
+    onboot: boolean;
+}
+export interface ProxmoxVm extends Resource<'Proxmox.Vm', VmProps, VmAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxVm: import("alchemy").ResourceClass<ProxmoxVm>;
+export declare const ProxmoxVmProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxVm>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=qemu.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"qemu.d.ts","sourceRoot":"","sources":["../../src/proxmox/qemu.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;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,MAAM,WAAW,OAAQ,SAAQ,UAAU;IACzC,IAAI,EAAE,MAAM,CAAC;IACb,4DAA4D;IAC5D,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,WAAW;IACX,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,wCAAwC;IACxC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,OAAO,CAAC;CAClB;AAED,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,OAAO,CAAC;CACjB;AAED,MAAM,WAAW,SAAU,SAAQ,QAAQ,CACzC,YAAY,EACZ,OAAO,EACP,YAAY,EACZ,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,SAAS,4CAAoC,CAAC;AAiC3D,eAAO,MAAM,iBAAiB,+HAC+C,CAAC"}

package/dist/proxmox/replication-job-form.d.ts

@@ -0,0 +1,71 @@
+/**
+ * A replication job's props, as the id and the forms PVE wants.
+ *
+ * ★ SPLIT OUT OF replication-job.ts TO KEEP BOTH FILES UNDER THE 250-LINE CAP, on the same seam
+ *   metric-server-form.ts uses and for the same reason: this file answers "how does a declaration
+ *   become a PVE write", and replication-job.ts answers "what is a replication job and when has it
+ *   changed". Nothing here reads the cluster and nothing here decides a diff.
+ *
+ * ⚠️ THE `import type` BACK TO replication-job.ts IS A CYCLE ON PAPER ONLY. It is type-only, so it
+ *   is erased before anything runs, and `ReplicationJobProps` stays the resource's public shape in
+ *   the file that declares the resource rather than being moved somewhere odd to dodge the arrow.
+ */
+import type { ReplicationJobProps } from './replication-job.ts';
+/**
+ * PVE's own documented default for `schedule`, applied on BOTH sides of the comparison.
+ *
+ * ⚠️ IT LIVES HERE BECAUSE BOTH HALVES NEED THE SAME STRING. `shape` sends it and `attributes`
+ *   falls back to it; two copies of that literal in two files is exactly the drift that makes a
+ *   plan report an update over a value nobody set.
+ * ⚠️ AND IT IS NEVER SPELLED OUT IN A COMMENT, because the string PVE chose ENDS A BLOCK COMMENT:
+ *   the two characters before the `15` are the comment terminator, and tsc says so loudly. It is
+ *   referred to by name everywhere else in these two files for that reason, not for style.
+ */
+export declare const DEFAULT_SCHEDULE = "*/15";
+/**
+ * `{guest, jobnum}` -> `100-0`, the id in the only spelling PVE ever answers with.
+ *
+ * ⚠️ NUMBERS IN, SO CANONICAL OUT. PVE runs both halves of a job id through `int()` on parse — see
+ *   the ⛔ in replication-job.ts — and a JavaScript number has no leading-zero spelling to lose.
+ *   That is the whole reason this resource is keyed on two numbers instead of one string.
+ */
+export declare const jobId: (props: ReplicationJobProps) => string;
+/**
+ * ⚠️ `type` IS A CONSTANT RATHER THAN A PROP: `local` is the only section type PVE registers, and
+ *   an enum of one value is a prop that can only ever be wrong. `id` and `target` are both required
+ *   by the create schema and neither belongs in `shape` — `target` because PUT will not take it.
+ * ⛔ THIS LINE IS THE ONLY PLACE PVE'S KEY `target` IS SPELLED, and the value beside it comes from
+ *   `targetNode`. The two words are different objects — a node name here, the whole cluster in
+ *   `WithTarget.target` — and the ⛔ in replication-job.ts explains why the rename was forced.
+ */
+export declare const createBody: (props: ReplicationJobProps) => {
+    comment: string;
+    disable: string;
+    schedule: string;
+    rate?: string;
+    id: string;
+    target: string;
+    type: string;
+};
+/**
+ * ⛔ `delete=remove_job` ON EVERY UPDATE IS THE DELIBERATE PART. PVE's PUT merges the form into the
+ *   section and cannot unset anything, so without this the removal marker a DELETE wrote would
+ *   survive every reconcile and `matches` would report an update that never lands. MEASURED as
+ *   legal: the update handler refuses `delete` only for required or `fixed` options, and
+ *   `remove_job => { optional => 1 }` is neither; deleting a key that is not set is a no-op, so
+ *   this is safe to send unconditionally.
+ * ⛔ AND THE DELETE LIST IS THIS ONE CONSTANT KEY, NEVER A COMPUTED "everything you did not
+ *   declare". backup-job.ts spells out why the computed form is dangerous — it strips settings the
+ *   resource does not even model off a job adopted from the UI. `remove_job` cannot be declared
+ *   here at all, so clearing it can only ever undo a removal this stack did not ask for.
+ *   ⚠️ IT CANCELS A REMOVAL SOMEBODY STARTED, WHICH IS THE POINT AND IS STILL WORTH KNOWING. If the
+ *     removal pass already ran its local-snapshot half, the revived job re-sends in full.
+ */
+export declare const updateBody: (props: ReplicationJobProps) => {
+    comment: string;
+    disable: string;
+    schedule: string;
+    rate?: string;
+    delete: string;
+};
+//# sourceMappingURL=replication-job-form.d.ts.map

package/dist/proxmox/replication-job-form.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"replication-job-form.d.ts","sourceRoot":"","sources":["../../src/proxmox/replication-job-form.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,mBAAmB,EAAE,MAAM,sBAAsB,CAAC;AAEhE;;;;;;;;;GASG;AACH,eAAO,MAAM,gBAAgB,SAAS,CAAC;AAEvC;;;;;;GAMG;AACH,eAAO,MAAM,KAAK,UAAW,mBAAmB,WACE,CAAC;AAsBnD;;;;;;;GAOG;AACH,eAAO,MAAM,UAAU,UAAW,mBAAmB;;;;;;;;CAKnD,CAAC;AAEH;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,UAAU,UAAW,mBAAmB;;;;;;CAGnD,CAAC"}

package/dist/proxmox/replication-job.d.ts

@@ -0,0 +1,162 @@
+/**
+ * `Proxmox.ReplicationJob` — a guest's ZFS storage replication to a second node, declared.
+ *
+ * ⛔ NOTHING ON TB4 CAN USE THIS FAMILY, AND THAT IS SAID HERE RATHER THAN FOUND OUT LATER. PVE
+ *   storage replication is ZFS-only: `POST /cluster/replication` calls `get_replicatable_volumes`
+ *   and refuses a guest whose disks are anywhere else with "No replicatable volumes found". TB4 is
+ *   Ceph/RBD-backed — shared storage, where replication means nothing because every node already
+ *   sees the volume — so `GET /cluster/replication` answers `[]` (MEASURED on n2, 2026-09-13) and
+ *   on this cluster always will. The file is written for a ZFS cluster; against TB4 a declaration
+ *   is a create that fails with PVE's own sentence, not a plan that quietly does nothing.
+ *
+ * ★ WHAT IS MEASURED HERE AND WHAT IS REASONED. Measured on n2 (pve-manager 9.2.11), read-only:
+ *   the published schema for all five methods; `PVE/ReplicationConfig.pm` and
+ *   `PVE/API2/ReplicationConfig.pm` line by line; `GET /cluster/replication` -> `[]`; and the ACL
+ *   row `{"path":"/","propagate":1,"roleid":"PVEAuditor","ugid":"hf-read@pve"}`. NOT measured: any
+ *   round trip. There is no live job to adopt and none can be created on this cluster, so the
+ *   argument that a matching declaration plans as `noop` rests on the schema and on PVE's own
+ *   source — not on a plan anybody ran. Nobody should claim otherwise until a ZFS cluster exists.
+ *
+ * ⛔ THE ID IS STRUCTURED AND PVE RE-SPELLS IT, so this resource is keyed on the two numbers rather
+ *   than on the string — a deliberate break from `backup-job.ts`'s "props are PVE's own key names".
+ *   MEASURED: `parse_replication_job_id` matches `^(\d+)-(\d+)$`, runs BOTH halves through `int()`
+ *   and returns "$guest-$jobnum", and `parse_section_header` does the same when reading
+ *   replication.cfg. So a declared `100-007` is read back as `100-7`, and a provider holding the
+ *   raw string would compare two spellings of one id forever. Two numbers cannot be spelled two
+ *   ways. PVE also refuses `guest < 100` ("guest IDs < 100 are reserved") and the API pattern
+ *   `[1-9][0-9]{2,8}-\d{1,9}` caps both halves at nine digits.
+ *   ⛔ BOTH HALVES ARE REQUIRED AND NEITHER IS DEFAULTED, for `backup-job.ts`'s reason: a provider
+ *     that picks a job number picks a DIFFERENT job from the one a person meant, and then adopts or
+ *     creates beside the real one. Declare the numbers of the job you mean.
+ *
+ * ⛔ PVE'S `target` AND THIS PACKAGE'S `target` ARE DIFFERENT THINGS, AND THE COMPILER SAID SO
+ *   BEFORE A REVIEWER DID. Every resource here extends `WithTarget`, whose `target` is the CLUSTER
+ *   a call goes to (`PveTarget`, carrying the API base and the credential mount). PVE's replication
+ *   `target` is a NODE NAME. They cannot both be called `target` in one props interface — tsc:
+ *   "Interface 'ReplicationJobProps' incorrectly extends interface 'WithTarget'" — so the prop and
+ *   the attribute are `targetNode`, and PVE's spelling appears exactly once, in `createBody`, where
+ *   it is the wire key. That is the only safe shape: had the collision been resolvable by silence,
+ *   `createForm` would have serialised a whole `PveTarget` object into a form field called `target`
+ *   and PVE would have answered that the node does not exist.
+ *
+ * ⛔ ONE JOB PER (GUEST, TARGET), ENFORCED BY PVE AND NOT BY THIS FILE. MEASURED: `write_config`
+ *   dies "replication job for guest '$vmid' to target '$tid' already exists" where `$tid` is
+ *   `local/<target>`, and `parse_config` DELETES the loser on read if two ever reach the file. Two
+ *   declarations differing only in `jobnum` but naming the same target are not two jobs; the second
+ *   is a create that fails.
+ *
+ * ⚠️ RECONCILE NEEDS `VM.Replicate` ON `/vms/<guest>`, WHICH `LXCProvisioner` DOES NOT HOLD. All
+ *   three writes check it (MEASURED in API2/ReplicationConfig.pm: create, update and delete each
+ *   call `$rpcenv->check($authuser, "/vms/$vmid", ['VM.Replicate'])`), and the role's 27 privileges
+ *   include `VM.Allocate`, `VM.Audit`, `VM.Backup`, `VM.Config.*` and `VM.PowerMgmt` but not
+ *   `VM.Replicate`. Widen it deliberately over SSH, preserving what is there, as `pool.ts` records:
+ *   `pveum role modify LXCProvisioner --privs "<existing>,VM.Replicate"`.
+ *   ★ THE READ LANE NEEDS NOTHING EXTRA, which is why there is no `readRole` below. The ITEM read
+ *     checks `VM.Audit` on `/vms/<guest>`, `hf-read@pve` holds the built-in `PVEAuditor` at `/`
+ *     with propagate — both MEASURED — and `PVEAuditor` carries `VM.Audit`. This family is not a
+ *     fourth one that must borrow the provision lease.
+ *   ⚠️ A MISSING JOB IS A 500, NOT A 404 — "no such replication job '100-0'" — and the factory
+ *     folds any failed read into "absent", so a 403 reads as absent too. A plan insisting on
+ *     creating a job that plainly exists is a credential problem; the honest error arrives one step
+ *     later, from the create.
+ *
+ * ⛔ DELETE DOES NOT DELETE, AND A DESTROY IS NOT FREE. MEASURED: with neither `force` nor `keep` —
+ *   and the factory's `destroy` sends no form at all — the handler only sets `remove_job = 'full'`
+ *   on the job and writes the config back. The job stays in replication.cfg until the SOURCE node's
+ *   `pvesr` timer next runs it, at which point it removes the local replication snapshots, removes
+ *   the replicated volumes on the target, and finally removes itself. So a destroy costs the
+ *   standby copy and the incremental base: re-declaring the job afterwards is a FULL send, not a
+ *   resume. The guest's own disks are untouched, which is exactly why this family does NOT carry
+ *   `defaultRemovalPolicy: 'retain'` the way `ZfsPool` and `Storage` do — what it destroys is a
+ *   copy a re-sync rebuilds, expensively, rather than something irreplaceable.
+ *   ⚠️ AND IF THE SOURCE NODE IS DOWN THE REMOVAL NEVER RUNS. Alchemy drops the state row on a
+ *     DELETE that returned no error, so a destroy against a dead source leaves a marked job on the
+ *     cluster that nothing declares any more. `GET /cluster/replication` is where it shows up.
+ *
+ * ⚠️ THE RUNTIME STATUS IS NOT HERE, AND NOT BECAUSE IT WAS FORGOTTEN. `last_sync`, `last_try`,
+ *   `fail_count`, `error`, `duration` and `pid` come from the per-node replication STATE file and
+ *   are merged in by `GET /nodes/{node}/replication` (MEASURED: API2/Replication.pm line 179,
+ *   `foreach my $k (qw(last_sync last_try fail_count error duration))`). `GET
+ *   /cluster/replication/{id}` — the only endpoint this resource reads — returns not one of them.
+ *   Reporting them would mean a second, per-node call on the read path answering a different value
+ *   every fifteen minutes, and a plan whose output changes when nothing changed is a plan people
+ *   stop reading. Ask the node for status; ask the cluster for configuration.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+export interface ReplicationJobProps extends WithTarget {
+    /** ⛔ The guest being replicated. 100 or above — PVE reserves everything below. Identity. */
+    guest: number;
+    /** ⛔ The job number within that guest, 0 upwards. Identity. Never generated — see the header. */
+    jobnum: number;
+    /**
+     * ⛔ THE NODE THE COPY LANDS ON — PVE's `target`, RENAMED; see the ⛔ in the header — AND IT IS
+     *   CREATE-ONLY. MEASURED: the plugin declares `target => { fixed => 1, optional => 0 }`, so
+     *   `updateSchema()` omits it entirely — `PUT` has no `target` parameter at all, and
+     *   `delete=target` answers "unable to delete fixed option". It is therefore NOT compared; see
+     *   the ⚠️ on `matches`. Changing it in a declaration plans as NOOP. Retire the declaration and
+     *   add another, exactly as `user.ts` says for `userid`.
+     * ⚠️ PVE refuses a target equal to the guest's current node ("Source and target must not be
+     *   identical") and one that is not a cluster member. Neither is checkable from here.
+     */
+    targetNode: string;
+    /**
+     * A subset of systemd calendar events. Unset means PVE's own default — `DEFAULT_SCHEDULE`,
+     * every fifteen minutes — and that default is what gets SENT and compared, not silence.
+     * ⚠️ THIS COMPARES STRINGS, NOT MEANINGS. A calendar event has many equivalent spellings and
+     *   PVE stores the one it was handed, verbatim, so declare the spelling the cluster echoes.
+     */
+    schedule?: string;
+    /** Rate limit in mbps as a float, 1 or above. Unset sends nothing and compares nothing. */
+    rate?: number;
+    /** Keep the job but stop replicating. Unset is an ACTIVE job, and that is what is compared. */
+    disable?: boolean;
+    /** Free text shown in the UI. Round-trips through PVE's `encode_text`/`decode_text`. */
+    comment?: string;
+}
+export interface ReplicationJobAttributes {
+    /** `100-0`, in PVE's own int-parsed spelling. */
+    id: string;
+    /**
+     * ⚠️ REPORTED AS INTEGERS, NEVER COMPARED, AND THIS IS THE "id written as a name" TRAP. MEASURED:
+     *   `parse_config` sets both from the section header via `int()`, so they are the id re-spelled
+     *   as numbers and no write accepts either. Compared against anything they would be an update
+     *   forever; reported, they let a plan say which guest is about to lose a replica.
+     */
+    guest: number;
+    jobnum: number;
+    /** Always `local` — the only section type PVE registers. Create-only, reported, not compared. */
+    type: string;
+    /**
+     * ⚠️ REPORTED, NEVER COMPARED. Create-only AND rewritten by PVE — see `matches`. Named for the
+     *   prop rather than for PVE's wire key `target`, so that one file never means two things by one
+     *   word; the header says why the wire name could not be kept.
+     */
+    targetNode: string;
+    /** ⚠️ REPORTED, NEVER SENT. PVE's own bookkeeping — see the ⛔ in replication-job-form.ts. */
+    source: string;
+    schedule: string;
+    /** 0 when unset. See `rateOf`. */
+    rate: number;
+    disable: boolean;
+    comment: string;
+    /**
+     * `''`, `local` or `full`. ⛔ NOT COSMETIC: a non-empty value is a job that is deleting itself,
+     *   so `matches` refuses it and `updateBody` clears it. See both.
+     */
+    remove_job: string;
+}
+export interface ProxmoxReplicationJob extends Resource<'Proxmox.ReplicationJob', ReplicationJobProps, ReplicationJobAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxReplicationJob: import("alchemy").ResourceClass<ProxmoxReplicationJob>;
+/**
+ * ⛔ Empty `list` like every other resource here: `GET /cluster/replication` hands back every job an
+ *   operator ever made, and adopting one is how a later `alchemy destroy` takes away a standby copy
+ *   nobody declared. Adoption is an explicit act — declare the `guest` and `jobnum` you mean.
+ * ⚠️ NOTHING BRAKES THIS DESTROY. PVE refuses to delete a pool that still holds guests; it accepts
+ *   this without a word, because nothing depends on a replication job. Re-read the DELETE ⛔ at the
+ *   top of this file before approving a plan line that removes one.
+ */
+export declare const ProxmoxReplicationJobProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxReplicationJob>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=replication-job.d.ts.map

package/dist/proxmox/replication-job.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"replication-job.d.ts","sourceRoot":"","sources":["../../src/proxmox/replication-job.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmFG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAG7C,OAAO,EAAE,KAAK,eAAe,EAAE,KAAK,UAAU,EAAe,MAAM,eAAe,CAAC;AAGnF,MAAM,WAAW,mBAAoB,SAAQ,UAAU;IACrD,4FAA4F;IAC5F,KAAK,EAAE,MAAM,CAAC;IACd,iGAAiG;IACjG,MAAM,EAAE,MAAM,CAAC;IACf;;;;;;;;;OASG;IACH,UAAU,EAAE,MAAM,CAAC;IACnB;;;;;OAKG;IACH,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,2FAA2F;IAC3F,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,+FAA+F;IAC/F,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,wFAAwF;IACxF,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED,MAAM,WAAW,wBAAwB;IACvC,iDAAiD;IACjD,EAAE,EAAE,MAAM,CAAC;IACX;;;;;OAKG;IACH,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,iGAAiG;IACjG,IAAI,EAAE,MAAM,CAAC;IACb;;;;OAIG;IACH,UAAU,EAAE,MAAM,CAAC;IACnB,6FAA6F;IAC7F,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,kCAAkC;IAClC,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,OAAO,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB;;;OAGG;IACH,UAAU,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,qBAAsB,SAAQ,QAAQ,CACrD,wBAAwB,EACxB,mBAAmB,EACnB,wBAAwB,EACxB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,qBAAqB,wDAA4D,CAAC;AAwE/F;;;;;;;GAOG;AACH,eAAO,MAAM,6BAA6B,2IAIvC,CAAC"}

package/dist/proxmox/resource.d.ts

@@ -0,0 +1,157 @@
+import type { Input } from 'alchemy/Input';
+import * as Effect from 'effect/Effect';
+import type * as HttpClient from 'effect/unstable/http/HttpClient';
+import type { ApiTarget, PbsTarget, PveRole, PveTarget } from './credentials.ts';
+/**
+ * ★ WHY SEVERAL FAMILIES HERE DECLARE `defaultRemovalPolicy: 'retain'`, WRITTEN ONCE.
+ *
+ *   Alchemy's own convention: a few resource types default to retain "because their contents are
+ *   irreplaceable" — `GitHub.Repository` and `Cloudflare.Zone` do — and those opt into deletion
+ *   with `destroy()`. `retain` means the engine SKIPS `provider.delete` entirely when a resource
+ *   is orphaned or destroyed: the state row is dropped, the cluster object lives on.
+ *
+ *   So the PVE families whose contents cannot be rebuilt from a line of TypeScript — CephOsd,
+ *   CephPool, CephFs, CephDaemon, ZfsPool, Storage, NodeNetwork — carry that default. Their
+ *   `delete` is FULLY IMPLEMENTED and runs the moment a caller opts in with
+ *   `.pipe(RemovalPolicy.destroy())`. This is deliberately the Terraform `prevent_destroy` shape
+ *   rather than a stubbed-out operation: a `delete` that silently does nothing lies to whoever is
+ *   reading the plan, and the lie is discovered at the worst possible time.
+ *
+ * ⚠️ THE POLICY IS A DECORATION, NOT A PROP, so changing it produces NO DIFF — the resource plans
+ *   as a noop and the deploy re-commits the row's policy in place. A policy change therefore takes
+ *   effect from the very next deploy even though the plan shows nothing.
+ */
+/**
+ * ⛔ A RESOURCE IS PINNED TO ITS PRODUCT; ONLY THE FACTORY TAKES EITHER. The two hosts are the same
+ *   two strings, so without a required discriminant TypeScript would accept a PBS host wherever a
+ *   PVE one belongs — silently, with every call 401ing and `read` folding that into "absent". The
+ *   whole argument is on `scheme` in credentials.ts.
+ */
+/**
+ * ★ WHAT EVERY OPERATION IN THIS PACKAGE NEEDS FROM THE RUNTIME, NAMED ONCE.
+ *
+ *   `HttpClient`, for both halves of every call: the credential is minted from OpenBao's HTTP API
+ *   and the PVE call goes through the same client. That is what Alchemy's own providers do
+ *   (src/Hetzner/Providers.ts builds on `FetchHttpClient.layer`, and there is no bare `fetch` in
+ *   its Docker, Kubernetes or GitHub providers).
+ * ★ `ChildProcessSpawner` WAS HERE UNTIL 2026-09-14, while the mint shelled out to `bao`. The HTTP
+ *   client replaced that (credentials.ts), so the requirement went with it.
+ *
+ * ⚠️ SPELLED OUT AT EACH OF THE FORTY-ODD RESOURCES this would be a union nobody keeps in step —
+ *   one file left on the old shape is a type error at the stack, far from the cause. Named here,
+ *   adding a third service later is one edit.
+ */
+export type PveRequirements = HttpClient.HttpClient;
+export type WithTarget = {
+    target: PveTarget;
+};
+export type WithPbsTarget = {
+    target: PbsTarget;
+};
+export type WithApiTarget = {
+    target: ApiTarget;
+};
+export type PveSpec<Props extends WithApiTarget, Attributes> = {
+    /** `pools/house`, `nodes/n2/lxc/101` — where ONE object is read, updated and deleted. */
+    readonly path: (props: Props) => string;
+    /** `pools`, `nodes/n2/lxc` — where a NEW one is POSTed. */
+    readonly collection: (props: Props) => string;
+    /** Live JSON to attributes. Returning undefined means "this is not really there". */
+    readonly attributes: (live: Record<string, unknown>, props: Props) => Attributes | undefined;
+    /** The form PVE wants on create. ⚠️ PVE takes form encoding, not JSON. */
+    readonly createForm: (props: Props) => Record<string, string>;
+    /**
+     * The form for an update, or undefined when the object has no mutable fields.
+     *
+     * ⚠️ SOME PVE OBJECTS CANNOT BE UPDATED AT ALL. Returning undefined makes a changed prop a
+     *   REPLACE rather than a silent no-op, which is the honest answer for an immutable object.
+     */
+    readonly updateForm?: (props: Props) => Record<string, string>;
+    /** True when live already matches props. Decides noop vs update. */
+    readonly matches: (attributes: Attributes, props: Props) => boolean;
+    /**
+     * Which lease reads this family. Defaults to `read`, the 3600s auditor-shaped one.
+     *
+     * ⛔ THREE FAMILIES SET THIS TO `provision`, AND THE FAILURE IT AVOIDS IS SILENT. PVE gates some
+     *   SINGLE-OBJECT reads on the allocate privilege rather than the audit one — `/storage/{id}`,
+     *   `/cluster/sdn/zones/{zone}`, `/cluster/sdn/vnets/{vnet}` — while their COLLECTION reads
+     *   accept audit, so nothing looks wrong until a resource reads one object. `read` below folds
+     *   every failure into `undefined`, right for a 404 and wrong for a 403, so the plan says create
+     *   and PVE answers that the object already exists. Measured both ways on `local`, and written
+     *   up with the alternative that was rejected, in docs/privileges.md.
+     */
+    readonly readRole?: PveRole;
+};
+export declare const pveOperations: <Props extends WithApiTarget, Attributes>(spec: PveSpec<Props, Attributes>) => {
+    read: (props: Props) => Effect.Effect<Attributes | undefined, never, HttpClient.HttpClient>;
+    diff: (news: Input<Props>, output: Attributes | undefined) => Effect.Effect<{
+        readonly action: 'update';
+    } | {
+        readonly action: 'noop';
+    } | {
+        readonly action: 'replace';
+    } | undefined, never, HttpClient.HttpClient>;
+    reconcile: (news: Props) => Effect.Effect<Attributes & ({} | null), Error, HttpClient.HttpClient>;
+    /**
+     * ⚠️ PVE REFUSES TO DELETE THINGS THAT ARE STILL IN USE — a pool holding guests, a storage with
+     *   volumes. That refusal is the cluster declining to orphan something because a line left a
+     *   file, so it is surfaced as-is rather than retried with a force flag.
+     */
+    destroy: (olds: Props) => Effect.Effect<unknown, Error, HttpClient.HttpClient>;
+};
+/**
+ * The five provider handlers for a spec'd PVE object, wired once.
+ *
+ * ⛔ THIS BLOCK WAS WRITTEN TEN TIMES BEFORE IT WAS EXTRACTED, and every copy was character for
+ *   character identical apart from its comments: `list` answering empty, and four handlers whose
+ *   entire body was `yield* ops.<same name>(<same argument>)`. Ten copies of a delegation is ten
+ *   chances to delegate to the wrong one — `ops.read(olds)` inside `reconcile` typechecks, returns
+ *   a plausible value, and turns every deploy into a no-op that reports success.
+ *
+ * ★ IT TAKES THE SPEC, NOT THE OPERATIONS, so a resource declares its four spec functions and
+ *   stops. `pveOperations` stays exported for an object that genuinely needs a handler of its own;
+ *   nothing in this package does yet, and the day one does it should be visibly different from the
+ *   ten that are not.
+ *
+ * ⛔ IT STOPS AT THE HANDLERS AND DOES NOT RETURN THE LAYER, AND THAT IS NOT AN OVERSIGHT — it was
+ *   written the other way first and reverted. Wrapping `Provider.effect(cls, …)` here means naming
+ *   the resource class generically, and Alchemy's `Props<R>` and `R["Attributes"]` are not the
+ *   plain `Props` and `Attributes` this spec is written against: `Attributes` comes back as
+ *   `Attributes & AttrOutput<Attributes["Attributes"]>`. Against a free type variable TypeScript
+ *   cannot prove those line up — "could be instantiated with a different subtype" — so the only
+ *   way to compile a Layer-returning version is a cast, and a cast is a LIE ABOUT WHETHER THE
+ *   HANDLERS MATCH THE RESOURCE, which is the one thing the call site exists to check. Leaving
+ *   `Cls.Provider.of(...)` in each file keeps that check where the types are concrete and real.
+ *   One line per resource is the price of it, and it is worth paying.
+ *
+ * ⚠️ `list` IS OPTIONAL IN `ProviderServiceInput` AND IS PASSED ANYWAY. An empty list is a claim —
+ *   this provider adopts nothing — and it is made here for every PVE object at once, because the
+ *   reasoning is identical for all of them: every PVE index endpoint answers with the whole
+ *   cluster's objects, PVE's own built-ins included. `GET /pools` returns pools a human made years
+ *   ago; `GET /access/roles` returns `Administrator`. Returning any of them would invite Alchemy to
+ *   adopt an object it never created, and therefore one day to narrow or delete it. Adoption stays
+ *   an explicit act. A resource with a reason to differ passes its own `list` and says why.
+ */
+export declare const pveHandlers: <Props extends WithApiTarget, Attributes extends object>(spec: PveSpec<Props, Attributes>) => {
+    list: () => Effect.Effect<never[], never, never>;
+    read: ({ olds }: {
+        olds: Props;
+    }) => Effect.Effect<Attributes | undefined, never, HttpClient.HttpClient>;
+    diff: ({ news, output }: {
+        news: Input<Props>;
+        output: Attributes | undefined;
+    }) => Effect.Effect<{
+        readonly action: 'update';
+    } | {
+        readonly action: 'noop';
+    } | {
+        readonly action: 'replace';
+    } | undefined, never, HttpClient.HttpClient>;
+    reconcile: ({ news }: {
+        news: Props;
+    }) => Effect.Effect<Attributes, Error, HttpClient.HttpClient>;
+    delete: ({ olds }: {
+        olds: Props;
+    }) => Effect.Effect<unknown, Error, HttpClient.HttpClient>;
+};
+//# sourceMappingURL=resource.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"resource.d.ts","sourceRoot":"","sources":["../../src/proxmox/resource.ts"],"names":[],"mappings":"AAmBA,OAAO,KAAK,EAAE,KAAK,EAAE,MAAM,eAAe,CAAC;AAC3C,OAAO,KAAK,MAAM,MAAM,eAAe,CAAC;AACxC,OAAO,KAAK,KAAK,UAAU,MAAM,iCAAiC,CAAC;AAEnE,OAAO,KAAK,EAAE,SAAS,EAAE,SAAS,EAAE,OAAO,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAEjF;;;;;;;;;;;;;;;;;;GAkBG;AAEH;;;;;GAKG;AACH;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,eAAe,GAAG,UAAU,CAAC,UAAU,CAAC;AAEpD,MAAM,MAAM,UAAU,GAAG;IAAE,MAAM,EAAE,SAAS,CAAA;CAAE,CAAC;AAC/C,MAAM,MAAM,aAAa,GAAG;IAAE,MAAM,EAAE,SAAS,CAAA;CAAE,CAAC;AAClD,MAAM,MAAM,aAAa,GAAG;IAAE,MAAM,EAAE,SAAS,CAAA;CAAE,CAAC;AAElD,MAAM,MAAM,OAAO,CAAC,KAAK,SAAS,aAAa,EAAE,UAAU,IAAI;IAC7D,yFAAyF;IACzF,QAAQ,CAAC,IAAI,EAAE,CAAC,KAAK,EAAE,KAAK,KAAK,MAAM,CAAC;IACxC,2DAA2D;IAC3D,QAAQ,CAAC,UAAU,EAAE,CAAC,KAAK,EAAE,KAAK,KAAK,MAAM,CAAC;IAC9C,qFAAqF;IACrF,QAAQ,CAAC,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,KAAK,EAAE,KAAK,KAAK,UAAU,GAAG,SAAS,CAAC;IAC7F,0EAA0E;IAC1E,QAAQ,CAAC,UAAU,EAAE,CAAC,KAAK,EAAE,KAAK,KAAK,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAC9D;;;;;OAKG;IACH,QAAQ,CAAC,UAAU,CAAC,EAAE,CAAC,KAAK,EAAE,KAAK,KAAK,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAC/D,oEAAoE;IACpE,QAAQ,CAAC,OAAO,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,KAAK,EAAE,KAAK,KAAK,OAAO,CAAC;IACpE;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,QAAQ,CAAC,EAAE,OAAO,CAAC;CAC7B,CAAC;AAEF,eAAO,MAAM,aAAa,GAAI,KAAK,SAAS,aAAa,EAAE,UAAU,QAC7D,OAAO,CAAC,KAAK,EAAE,UAAU,CAAC;kBAGX,KAAK;iBAiBX,KAAK,CAAC,KAAK,CAAC,UAAU,UAAU,GAAG,SAAS;yBASZ,QAAQ;;yBACF,MAAM;;yBAGtC,SAAS;;sBAIV,KAAK;IA6DvB;;;;OAIG;oBACa,KAAK;CAExB,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,eAAO,MAAM,WAAW,GAAI,KAAK,SAAS,aAAa,EAAE,UAAU,SAAS,MAAM,QAC1E,OAAO,CAAC,KAAK,EAAE,UAAU,CAAC;IAI9B,IAAI;IACJ,IAAI,aAAa;QAAE,IAAI,EAAE,KAAK,CAAA;KAAE;IAChC,IAAI,qBAAqB;QAAE,IAAI,EAAE,KAAK,CAAC,KAAK,CAAC,CAAC;QAAC,MAAM,EAAE,UAAU,GAAG,SAAS,CAAA;KAAE;yBAtHlC,QAAQ;;yBACF,MAAM;;yBAGtC,SAAS;;IAoH5B,SAAS,aAAa;QAAE,IAAI,EAAE,KAAK,CAAA;KAAE;IACrC,MAAM,aAAa;QAAE,IAAI,EAAE,KAAK,CAAA;KAAE;CAErC,CAAC"}

package/dist/proxmox/role.d.ts

@@ -0,0 +1,97 @@
+/**
+ * `Proxmox.Role` — a PVE role: one name, one set of privileges. The object every other resource
+ * in this package stands on, because a role is what the provision credential actually holds.
+ *
+ * ★ THIS IS WHERE pool.ts's ⚠️ STOPS BEING A MEMORY. That file records, in prose, that the
+ *   provision role lacked `Pool.Allocate`, that reconcile answered "Permission check failed", and
+ *   that a human widened the role over SSH with `pveum role modify`. Prose cannot be planned
+ *   against: it goes stale the first time somebody edits the role in the UI and tells nobody.
+ *   Declared here, the same fact is a diff — the privileges the role is SUPPOSED to hold are read
+ *   off the cluster on every plan, and a hand edit shows up as `1 to update` rather than as a 403
+ *   six weeks later in the middle of something else.
+ *
+ * ⛔ THE INDEX AND THE ITEM DISAGREE ABOUT WHAT `privs` IS, AND MISSING THAT COSTS A DIFF THAT
+ *   NEVER CONVERGES. `GET /access/roles` (the index) reports each role's privileges as a COMMA
+ *   STRING. `GET /access/roles/{roleid}` — the path this resource reads — returns a privilege MAP
+ *   instead, `{"VM.Allocate":1,"Sys.Audit":1,…}`, and its key order is a Perl hash's order, so it
+ *   is not stable between two calls to the same endpoint. Compare the raw string, or the raw
+ *   object, or the keys in the order they arrived, and every plan reports an update forever.
+ *   `canonical` below is the whole answer: both sides become a sorted, de-duplicated set before
+ *   anything is compared, and `attributes` STORES the sorted form so Alchemy's state does not
+ *   churn either.
+ *
+ * ⚠️ A DECLARATION REPLACES THE PRIVILEGE SET; IT DOES NOT ADD TO IT. `PUT /access/roles/{roleid}`
+ *   accepts an `append` flag and this resource deliberately never sends it — with append a role
+ *   could only ever grow, so `matches` would report an update forever whenever props were a subset
+ *   of live, which is the same perpetual diff by a different road. The consequence is the one that
+ *   bites: anything a human added by hand is REVOKED on the next deploy unless it is in `privs`.
+ *   Copy the live set out of `pveum role list` before declaring a role that already exists; do not
+ *   type it from memory.
+ *
+ * ⛔ A ROLE CAN LOCK ITS OWN PROVIDER OUT, AND NOTHING IN THIS PACKAGE CAN UNDO IT. Reconcile runs
+ *   as the provision credential, and that credential holds a role. Declare THAT role without the
+ *   privileges the provider needs — `Sys.Modify` on `/access` above all — and the write succeeds,
+ *   after which every later plan reads 403 and the repair has to happen out of band as `root@pam`
+ *   over SSH. It is a one-way door, which is why the privileges a reconcile needs are written
+ *   down at the bottom of this comment rather than left to be rediscovered from an error message.
+ *
+ * ⚠️ PVE REFUSES TO EDIT ITS OWN BUILT-IN ROLES (`Administrator`, `NoAccess`, the `PVE*` set), and
+ *   the item endpoint gives no sign of which those are — only the index carries the `special`
+ *   flag. A declaration aimed at a built-in role therefore READS BACK CLEANLY and fails at write
+ *   time, which reads like a broken provider rather than like a refusal. Declare roles you own.
+ *
+ * ★ PRIVILEGES A RECONCILE NEEDS: `Sys.Audit` on `/access` to read and diff, `Sys.Modify` on
+ *   `/access` to create, update or delete. Not `Permissions.Modify` — binding a role to a user is
+ *   `/access/acl`, a different object, and nothing here writes it. An auditor-shaped credential
+ *   can already PLAN this resource and cannot DEPLOY it, which is the honest failure: the plan is
+ *   true and the deploy says exactly which privilege is missing.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+export interface RoleProps extends WithTarget {
+    /**
+     * PVE's primary key for a role.
+     *
+     * ⚠️ THERE IS NO RENAME. `path` is built from this, so changing it makes the factory read
+     *   nothing live, create a role under the new name, and leave the old one on the cluster with
+     *   nobody managing it. Delete the resource and declare a new one rather than editing this.
+     */
+    roleid: string;
+    /**
+     * The COMPLETE privilege set, e.g. `['VM.Allocate', 'VM.Audit', 'Sys.Audit']`. Order and
+     * duplicates do not matter — see the ⛔ in the header — but completeness does: this list is the
+     * role, not an addition to it.
+     *
+     * ⚠️ DECLARE AT LEAST ONE. A role with no privileges grants nothing and reads back as an empty
+     *   document, which is the one shape the factory cannot tell apart from an object that is not
+     *   there — reconcile would then refuse with its "the write returned no error but the object is
+     *   still absent" message, which is true of the read and misleading about the cause.
+     */
+    privs: string[];
+}
+export interface RoleAttributes {
+    roleid: string;
+    /** Sorted and de-duplicated on the way in, so persisted state is identical across plans. */
+    privs: string[];
+}
+export interface ProxmoxRole extends Resource<'Proxmox.Role', RoleProps, RoleAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxRole: import("alchemy").ResourceClass<ProxmoxRole>;
+/**
+* ⛔ AN EMPTY LIST, AND NOWHERE DOES IT MATTER MORE. `GET /access/roles` returns every
+*   role on the cluster, PVE's own built-ins included. Returning them would invite Alchemy
+*   to adopt `Administrator` — and therefore one day to narrow or delete it. Adoption is
+*   an explicit act, here as everywhere else in this package.
+ 
+ *
+* ⛔ DO NOT CARRY THE FACTORY'S REASSURANCE OVER TO THIS ONE. `destroy` there notes that
+*   PVE refuses to delete things still in use — a pool holding guests, a storage with
+*   volumes — and a role is NOT protected that way. Whoever is bound to the role loses
+*   those privileges the moment it goes, and the credential this provider runs with is
+*   bound through exactly such a binding. Checking who holds a role before removing it is
+*   an operator's job, and it is not done here on their behalf while they read a diff.
+ 
+ */
+export declare const ProxmoxRoleProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxRole>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=role.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"role.d.ts","sourceRoot":"","sources":["../../src/proxmox/role.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+CG;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;AAEnF,MAAM,WAAW,SAAU,SAAQ,UAAU;IAC3C;;;;;;OAMG;IACH,MAAM,EAAE,MAAM,CAAC;IACf;;;;;;;;;OASG;IACH,KAAK,EAAE,MAAM,EAAE,CAAC;CACjB;AAED,MAAM,WAAW,cAAc;IAC7B,MAAM,EAAE,MAAM,CAAC;IACf,4FAA4F;IAC5F,KAAK,EAAE,MAAM,EAAE,CAAC;CACjB;AAED,MAAM,WAAW,WAAY,SAAQ,QAAQ,CAC3C,cAAc,EACd,SAAS,EACT,cAAc,EACd,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,WAAW,8CAAwC,CAAC;AAuDjE;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,mBAAmB,iIACiD,CAAC"}