@homeflare/alchemy 0.1.0

package/dist/proxmox/sdn-zone.d.ts

@@ -0,0 +1,126 @@
+/**
+ * `Proxmox.SdnZone` — the network a declared guest sits on, finally declared too.
+ *
+ * ★ WHY THIS ONE MATTERS MORE THAN IT LOOKS. Every guest NIC here names a bridge —
+ *   `net0=name=eth0,bridge=vmbr0` — that nothing in this package declares: a hand-built interface,
+ *   repeated per node, that a container silently depends on. A zone is the first piece of that
+ *   dependency PVE will let a plan own.
+ *
+ * ⛔ SDN WRITES ARE STAGED, NOT APPLIED, AND THAT DEFEATS THE FACTORY'S READ-BACK GUARANTEE.
+ *   POST and PUT under `cluster/sdn/zones` edit `/etc/pve/sdn/zones.cfg` and change NOTHING on any
+ *   node. The plain GET reads that same staged file back, so `pveOperations` sees its own write,
+ *   finds the object present, and reports a success in which no node gained an interface. The
+ *   applied state is a different document — `.running-config` beside it — and `?pending=1` is the
+ *   read that tells them apart: it returns a merged view with a `state` of new/changed/deleted.
+ *
+ * ⛔ THE APPLY CANNOT LIVE IN THIS RECONCILE, so it is absent rather than forgotten.
+ *   `PUT /cluster/sdn` is the atomic pending-to-apply and it applies the WHOLE staged config —
+ *   every zone, vnet and subnet, on every node. Called from a per-resource reconcile it would push
+ *   some OTHER resource's half-written zone out to the cluster at whatever point the plan ordering
+ *   reached this one, and PVE has no pre-apply hook to veto that. The apply belongs to ONE object
+ *   that depends on all of them — a sibling `Proxmox.SdnApply` over `cluster/sdn`, or a stack-level
+ *   hook that runs last — so that "declared" and "live on the nodes" stay two visible steps.
+ *
+ * ⚠️ SO THESE ATTRIBUTES DESCRIBE THE STAGED ZONE, and there is deliberately no `applied` flag:
+ *   the factory uses ONE path for GET, PUT and DELETE, and PVE's parameter schemas are closed, so
+ *   an unexpected `pending` on the PUT is a 400 rather than an ignored hint. Reading `?pending=1`
+ *   means re-implementing the operations this file exists to share, and an `applied: true` that
+ *   was never measured is worse than an absent one. Deploying this resource does not change the
+ *   network; it changes what the next apply will do.
+ *
+ * ⛔ THE READ THIS RESOURCE PERFORMS NEEDS SDN.Allocate, NOT SDN.Audit, AND AN EARLIER DRAFT OF
+ *   THIS COMMENT SAID OTHERWISE. Read off the cluster's own schema on 2026-09-13:
+ *
+ *     GET /cluster/sdn/zones          -> "list entries where you have SDN.Audit or SDN.Allocate"
+ *     GET /cluster/sdn/zones/{zone}   -> {"check": ["perm", "/sdn/zones/{zone}", ["SDN.Allocate"]]}
+ *
+ *   `pveOperations.read` calls the ITEM endpoint, so an auditor-shaped `read` lease is REFUSED —
+ *   and the refusal does not surface as a 403. `read` folds every failure into `undefined`, which
+ *   the factory reads as "absent", so the plan says create, the POST goes out, and PVE answers
+ *   that the zone already exists. This is the same class as Proxmox.Storage; see
+ *   docs/privileges.md, "The failure that does not look like a permission problem".
+ *
+ * ⚠️ THE REST OF THE PRIVILEGES. Writes need SDN.Allocate (`/sdn/zones` to create,
+ *   `/sdn/zones/{zone}` to update or delete); the apply — `Proxmox.SdnApply`, which is what
+ *   actually publishes any of this — needs SDN.Allocate on `/sdn` itself. SDN.Use is NOT among
+ *   them: it permits attaching a guest to an existing vnet and nothing else.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+/** PVE's zone plugins. Which one a zone is decides which fields below it will even accept. */
+export type SdnZoneType = 'evpn' | 'qinq' | 'simple' | 'vlan' | 'vxlan';
+export interface SdnZoneProps extends WithTarget {
+    /**
+     * PVE's primary key. ⚠️ AT MOST EIGHT LOWERCASE ALPHANUMERICS, first one a letter: the id lands
+     *   in generated interface names, so PVE enforces it with a regex whose rejection reads as
+     *   "value does not match the regex pattern" rather than as "your name is too long".
+     */
+    zone: string;
+    /**
+     * ⛔ CREATE-TIME ONLY. `PUT /cluster/sdn/zones/{zone}` has no `type` parameter at all — a
+     *   section's type is fixed when it is written. Changing it here is not an update PVE can
+     *   perform; the ⛔ in `attributes` turns that edit into a refusal instead of a silent no-op.
+     */
+    type: SdnZoneType;
+    /** Accepted by every zone type. Unset means the zone inherits the underlying bridge's MTU. */
+    mtu?: number;
+    /** ⚠️ WHICH NODES THE ZONE IS DEPLOYED TO. Unset means EVERY node, not none. */
+    nodes?: string[];
+    /** IPAM plugin id. Unset is the built-in `pve` one — the two are one zone, see `sameIpam`. */
+    ipam?: string;
+    /** DNS plugin id used to register guest records. */
+    dns?: string;
+    /** The domain those records are registered under, e.g. `example.internal`. */
+    dnszone?: string;
+    /** vxlan only, and REQUIRED there: the peer addresses the tunnel mesh is built from. */
+    peers?: string[];
+    /** evpn only, and required there. PVE's own hyphenated name, so no mapping to get wrong. */
+    'vrf-vxlan'?: number;
+    /** qinq only, and required there: the service VLAN tag the zone's vnets are stacked inside. */
+    tag?: number;
+    /** vlan and qinq only, and required in both: the existing bridge the zone is carved out of. */
+    bridge?: string;
+}
+/**
+ * ⛔ NO `digest` HERE, ON PURPOSE. PVE returns one, but it is the digest of the WHOLE zones.cfg
+ *   file rather than of this section — declaring a SECOND zone would rewrite this one's stored
+ *   attributes, and comparing it would report an update on a zone nobody touched.
+ */
+export interface SdnZoneAttributes {
+    zone: string;
+    type: SdnZoneType;
+    /** 0 when unset, which is PVE's "inherit from the bridge" rather than an MTU of zero. */
+    mtu: number;
+    /** Normalised: split, sorted, rejoined. Never compare a raw PVE string to it — see `csv`. */
+    nodes: string;
+    /** The EFFECTIVE ipam: an absent one is reported as `pve`, because that is what will be used. */
+    ipam: string;
+    dns: string;
+    dnszone: string;
+    peers: string;
+    'vrf-vxlan': number;
+    tag: number;
+    bridge: string;
+    /** ⚠️ THE REMINDER IN THE STATE ITSELF: staged config. No value here says a node has the zone. */
+    readonly staged: true;
+}
+export interface ProxmoxSdnZone extends Resource<'Proxmox.SdnZone', SdnZoneProps, SdnZoneAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxSdnZone: import("alchemy").ResourceClass<ProxmoxSdnZone>;
+/**
+* ⛔ Empty for the same reason as every other resource here, and with extra force for SDN:
+*   `GET /cluster/sdn/zones` answers with the zones the cluster's whole network already
+*   runs on. Adopting those would make a later `alchemy destroy` a cluster-wide outage.
+ 
+ *
+* ⛔ A DELETE IS STAGED TOO, AND THAT IS THE HALF PEOPLE FORGET. The section leaves
+*   zones.cfg and Alchemy drops the resource, but the zone KEEPS RUNNING on every node
+*   until something applies `PUT /cluster/sdn`: a destroy nobody applies reads as complete
+*   in the plan and has not happened on the cluster.
+* ⚠️ PVE also refuses to remove a zone that still holds vnets. That refusal is kept — it is
+*   the cluster declining to orphan a network because a line left a file.
+ 
+ */
+export declare const ProxmoxSdnZoneProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxSdnZone>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=sdn-zone.d.ts.map

package/dist/proxmox/sdn-zone.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sdn-zone.d.ts","sourceRoot":"","sources":["../../src/proxmox/sdn-zone.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;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,8FAA8F;AAC9F,MAAM,MAAM,WAAW,GAAG,MAAM,GAAG,MAAM,GAAG,QAAQ,GAAG,MAAM,GAAG,OAAO,CAAC;AAExE,MAAM,WAAW,YAAa,SAAQ,UAAU;IAC9C;;;;OAIG;IACH,IAAI,EAAE,MAAM,CAAC;IACb;;;;OAIG;IACH,IAAI,EAAE,WAAW,CAAC;IAClB,8FAA8F;IAC9F,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,gFAAgF;IAChF,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;IACjB,8FAA8F;IAC9F,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,oDAAoD;IACpD,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,8EAA8E;IAC9E,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,wFAAwF;IACxF,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;IACjB,4FAA4F;IAC5F,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,+FAA+F;IAC/F,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,+FAA+F;IAC/F,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED;;;;GAIG;AACH,MAAM,WAAW,iBAAiB;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,WAAW,CAAC;IAClB,yFAAyF;IACzF,GAAG,EAAE,MAAM,CAAC;IACZ,6FAA6F;IAC7F,KAAK,EAAE,MAAM,CAAC;IACd,iGAAiG;IACjG,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,EAAE,MAAM,CAAC;IACZ,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,MAAM,CAAC;IACf,kGAAkG;IAClG,QAAQ,CAAC,MAAM,EAAE,IAAI,CAAC;CACvB;AAED,MAAM,WAAW,cAAe,SAAQ,QAAQ,CAC9C,iBAAiB,EACjB,YAAY,EACZ,iBAAiB,EACjB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,cAAc,iDAA8C,CAAC;AA6G1E;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,sBAAsB,oIACoD,CAAC"}

package/dist/proxmox/storage.d.ts

@@ -0,0 +1,120 @@
+/**
+ * `Proxmox.Storage` — one entry in `/etc/pve/storage.cfg`, declared. Cluster-scoped like a pool,
+ * which is why `path` and `collection` carry no node segment though a storage is used per node.
+ *
+ * ★ THIS IS THE OBJECT EVERY CONTAINER ALREADY DEPENDS ON AND NOTHING DECLARES. `LxcProps.storage`
+ *   and the prefix of `LxcProps.ostemplate` (`local:vztmpl/...`) are bare strings, so a container's
+ *   rootfs points at something outside the graph: rebuild a node and the plan still reads `noop`
+ *   right up to the create that fails because the storage is not there. Passing this resource's
+ *   `storage` attribute into `LxcProps.storage` makes the dependency real — Alchemy orders by data
+ *   flow, so the storage reconciles first because the container reads a value out of it.
+ *
+ * ⛔ 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 holds `Datastore.AllocateSpace` and
+ *     `Datastore.Audit`, and NEITHER IS IT — AllocateSpace writes volumes INTO a storage, Allocate
+ *     DEFINES one — so it 403s here until widened the way `Pool.Allocate` was for `Proxmox.Pool`.
+ *
+ * ⛔ 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
+ *   line away from being an attribute, and from there it is in the state store's nightly dump. So
+ *   `StorageLocator` types `password`, `keyring` and `encryption-key` as `never`: declaring one is
+ *   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.
+ */
+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;
+};
+export interface StorageProps extends WithTarget {
+    /** PVE's primary key, cluster-wide — the string an LXC's `storage` and `ostemplate` name. */
+    storage: string;
+    /**
+     * `dir` | `nfs` | `cifs` | `pbs` | `zfspool` | `lvmthin` | `rbd` | … ⚠️ CREATE-ONLY, so a changed
+     * `type` plans as `noop` (see `matches`). PVE cannot retype a storage: remove and redeclare.
+     */
+    type: string;
+    /** ⚠️ Create-only, one shape per plugin. See `StorageLocator`. */
+    locator?: StorageLocator;
+    /** `images,rootdir,vztmpl,iso,backup,snippets`. PVE reports `none` for an empty set. */
+    content?: string;
+    /**
+     * Node restriction, e.g. `n1,n2`. ⚠️ A STORAGE WITH A `nodes` LIST DOES NOT EXIST ANYWHERE ELSE:
+     * an LXC declared on a node outside it fails at create with "storage not available on node".
+     */
+    nodes?: string;
+    /** Keeps the definition but stops PVE using it. */
+    disable?: boolean;
+    /** Tells PVE the same volumes are visible from every node — a claim, not a mechanism. */
+    shared?: boolean;
+    /** `off` | `metadata` | `falloc` | `full`. File-based plugins only. */
+    preallocation?: string;
+    /**
+     * `keep-last=3,keep-daily=7,…`. ⚠️ THE WIRE NAME IS KEPT, HYPHEN AND ALL: a `pruneBackups` that
+     * quietly becomes `prune-backups` in the form body is a second name for one thing.
+     */
+    '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;
+}
+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

@@ -0,0 +1 @@
+{"version":3,"file":"storage.d.ts","sourceRoot":"","sources":["../../src/proxmox/storage.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;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;AAgHH;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,sBAAsB,oIACoD,CAAC"}

package/dist/proxmox/user.d.ts

@@ -0,0 +1,107 @@
+/**
+ * `Proxmox.User` — a PVE account. The identity every other resource in this package borrows.
+ *
+ * ★ THIS IS THE ONE OBJECT THAT CAN CUT THE BRANCH IT SITS ON. The user the credential mount vends
+ *   tokens for, and the group whose members are allowed to mint, are what `src/credentials.ts`
+ *   ultimately asks OpenBao for. A cluster rebuilt without them cannot plan ANY resource here —
+ *   including the plan that would recreate them, which needs a credential to run. So this resource
+ *   is drift repair for an account that already exists (comment, email, enable, expire, groups),
+ *   not a bootstrap: the first mint user is made on a node with `pveum user add`, by a human, once.
+ *
+ * ⛔ THERE IS NO `password` PROP, AND ADDING ONE WOULD BE A LEAK RATHER THAN A FEATURE. Alchemy
+ *   writes resource state WITHOUT encryption — see the ⛔ in `credentials.ts` — so a password prop
+ *   would sit in clear in whatever database the stack points `state` at, and in every backup of it.
+ *   It is also unnecessary: `password` is accepted only by the CREATE call, changing one afterwards
+ *   is `PUT /access/password` (a different endpoint, a different privilege), and an account in a
+ *   realm such as `@pam`, `@ldap` or `@openid` has no PVE-side password at all — the realm holds
+ *   it. Out of scope by design. `keys` (TFA) is omitted for the same reason.
+ *
+ * ⚠️ `groups` COMES BACK AS AN ARRAY AND GOES OUT AS A COMMA STRING, and the asymmetry is the whole
+ *   trap. GET answers `["a","b"]`, POST/PUT want `a,b`, and PVE returns the list in ITS order, not
+ *   the declared one. Compared naively, `matches` reads ['b','a'] against 'a,b' and every plan for
+ *   the rest of time says "1 to update". Both sides are normalised to a sorted, deduplicated set
+ *   below. Joining is a safe comparison precisely because a group id cannot contain a comma — the
+ *   wire format is comma-separated, so PVE refuses one.
+ *
+ * ⚠️ `tokens` IS NESTED AND IS NOT SETTABLE THROUGH THIS ENDPOINT. The read hands back a map of the
+ *   account's API tokens; `PUT /access/users/{userid}` has no parameter for them, because they are
+ *   their own objects under `.../token/{tokenid}`. So they are reported as an attribute — a plan
+ *   can then say what a delete would take with it — and kept OUT of `matches`, exactly like
+ *   `pool.members`. Reported, never declared.
+ *
+ * ⚠️ RECONCILE NEEDS PRIVILEGES `LXCProvisioner` DOES NOT HOLD, so state them rather than meet a
+ *   403 in the middle of a deploy (pool.ts records how that went the last time):
+ *     · `Realm.AllocateUser` on `/access/realm/<realm>` — create and delete.
+ *     · `User.Modify` on `/access/groups`, and on `/access/groups/<group>` for EVERY group named in
+ *       `groups` — create, update and delete. PVE checks the groups you are granting, not just the
+ *       user, so a role wide enough to edit the account can still be refused for one group in the
+ *       list.
+ *     · `Sys.Audit` (or `User.Modify`) for the read, which the `read` role's auditor already has.
+ *   `Permissions.Modify` is NOT on this list: that governs ACL entries, which are a different PVE
+ *   object and would be a different resource here.
+ *
+ * ⚠️ A MISSING USER IS A 500, NOT A 404 — "no such user ('x@pve')" — and the factory turns any
+ *   failed read into "absent". A 403 therefore also reads as absent, and the honest error arrives
+ *   one step later, from the create: "Permission check failed (/access/groups, User.Modify)". That
+ *   string is the one to grep for when a plan insists on creating an account that plainly exists.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import { type PveRequirements, type WithTarget } from './resource.ts';
+export interface UserProps extends WithTarget {
+    /**
+     * ⛔ REALM-QUALIFIED, ALWAYS: `someone@pve`, `someone@pam`. The realm is part of PVE's primary
+     *   key, and a bare name is refused with "value does not look like a valid user id".
+     *
+     * ⚠️ PVE HAS NO RENAME. Editing this prop makes the path point at a DIFFERENT account, which
+     *   reads as absent and is then created — while the old one stays on the cluster with its tokens
+     *   and its ACL entries. Renaming is a delete and a create, and should be declared as one.
+     */
+    userid: string;
+    /** Free text shown in the UI. */
+    comment?: string;
+    /** PVE accepts the empty string here; that is how an address is cleared. */
+    email?: string;
+    /** Default true, matching PVE's own `enable=1`. False disables login without deleting anything. */
+    enable?: boolean;
+    /** Seconds since the epoch. 0 — the default — means the account never expires. */
+    expire?: number;
+    /** Group memberships. Order and duplicates carry no meaning — see the ⚠️ in the header. */
+    groups?: string[];
+    firstname?: string;
+    lastname?: string;
+}
+export interface UserAttributes {
+    userid: string;
+    comment: string;
+    email: string;
+    enable: boolean;
+    expire: number;
+    /** Normalised: sorted, deduplicated, whatever shape the cluster used on the wire. */
+    groups: string[];
+    firstname: string;
+    lastname: string;
+    /**
+     * API token names this account owns. Reported so a plan can show what a delete would revoke;
+     * never compared, because this endpoint cannot set them.
+     */
+    tokens: string[];
+}
+export interface ProxmoxUser extends Resource<'Proxmox.User', UserProps, UserAttributes, never, PveRequirements> {
+}
+export declare const ProxmoxUser: import("alchemy").ResourceClass<ProxmoxUser>;
+/**
+* ⛔ EMPTY, AND MORE POINTEDLY SO HERE THAN ANYWHERE ELSE. `GET /access/users` answers with
+*   every account on the cluster: `root@pam`, every human who logs in, every service
+*   identity someone made years ago. Handing that list to Alchemy would invite it to adopt
+*   — and therefore one day DELETE — people. Adoption is an explicit act.
+ 
+ *
+* ⛔ DELETING A USER TAKES ITS API TOKENS AND ITS ACL ENTRIES WITH IT, in one call and
+*   without a confirmation. For the identity a credential mount vends from, that revokes
+*   every outstanding lease at once and every plan in this package stops working — this one
+*   included. PVE refuses only for `root@pam`; for everyone else it simply obeys.
+ 
+ */
+export declare const ProxmoxUserProvider: () => import("effect/Layer").Layer<Provider.Provider<ProxmoxUser>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=user.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"user.d.ts","sourceRoot":"","sources":["../../src/proxmox/user.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;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,SAAU,SAAQ,UAAU;IAC3C;;;;;;;OAOG;IACH,MAAM,EAAE,MAAM,CAAC;IACf,iCAAiC;IACjC,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,4EAA4E;IAC5E,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,mGAAmG;IACnG,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,kFAAkF;IAClF,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,2FAA2F;IAC3F,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,cAAc;IAC7B,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,OAAO,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IACf,qFAAqF;IACrF,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,QAAQ,EAAE,MAAM,CAAC;IACjB;;;OAGG;IACH,MAAM,EAAE,MAAM,EAAE,CAAC;CAClB;AAED,MAAM,WAAW,WAAY,SAAQ,QAAQ,CAC3C,cAAc,EACd,SAAS,EACT,cAAc,EACd,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ,eAAO,MAAM,WAAW,8CAAwC,CAAC;AAiGjE;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,mBAAmB,iIACiD,CAAC"}

package/dist/proxmox/values.d.ts

@@ -0,0 +1,134 @@
+/**
+ * How PVE spells a value on the wire, and how to get it back to something comparable.
+ *
+ * ⛔ EVERY FUNCTION HERE WAS FOUND IN TWO OR MORE RESOURCE FILES, AND THE COPIES HAD DRIFTED.
+ *   `num` was byte-identical in three files, so merging it is free. The boolean was NOT: four
+ *   files declared `const flag` and meant four different things by it, including one that ran the
+ *   other way round. That is the whole reason this module exists — not to save lines, but because
+ *   a name that means four things is a bug waiting for the person who assumes it means the first
+ *   one they read.
+ *
+ * ★ THE TWO DIRECTIONS ARE NAMED APART, DELIBERATELY. `bool` reads the wire and answers a
+ *   TypeScript boolean; `flag` writes a form field and answers PVE's `'1'`/`'0'`. `storage.ts`
+ *   held both under one name — `flag` there was the write direction while `flag` in three other
+ *   files was the read direction — which typechecks in both files and is exactly the confusion
+ *   that survives review.
+ *
+ * ⚠️ NOTHING HERE IS RESOURCE-SPECIFIC. A coercion that only one PVE object needs belongs in that
+ *   object's file, where its reasoning sits next to the field it serves. `role.ts` keeps its own
+ *   `canonical` for the same reason: that one sorts a privilege SET, which is a different idea
+ *   from `canonicalToken` below however similar the names read.
+ */
+/** ⚠️ `typeof value === 'number'` and not `Number(value)`: PVE sends `null` for an unset field. */
+export declare const num: (value: unknown, fallback: number) => number;
+export declare const text: (value: unknown, fallback?: string) => string;
+/**
+ * A PVE boolean off the wire.
+ *
+ * ⛔ THE FOUR SPELLINGS THIS REPLACES, AND WHY THIS ONE IS A SUPERSET OF ALL OF THEM. Measured in
+ *   the files they came from: `backup-job` accepted `1 | true | '1'` with a caller's fallback;
+ *   `sdn-vnet` the same three with no fallback; `storage` accepted only `1 | true`; `user` ran the
+ *   value through `Number()` and asked `!== 0`. For the values PVE actually returns on these
+ *   endpoints — `0` and `1` — all four agree, so accepting the union changes no live answer.
+ *
+ * ⚠️ THE ONE REAL DIFFERENCE IS `2`. `user.ts` would have read any non-zero number as true; this
+ *   reads only `1`. No PVE field in this package is documented to return anything but 0 or 1, and
+ *   a field that did would be a flag with more than two states — which is not a boolean, and
+ *   should be read with `num` and named for what it is rather than quietly coerced here.
+ *
+ * ⚠️ `null`, `undefined` AND `''` ALL TAKE THE FALLBACK. An absent key means PVE's documented
+ *   default for that field, which is not always `false` — so the default is the CALLER's to state,
+ *   and `false` is only the fallback's own default for fields that really do default off.
+ *
+ * ⛔ THE EMPTY STRING IS ABSENT, NOT FALSE, AND GETTING THAT WRONG WRITES THE WRONG VALUE. A
+ *   metric server is a SectionConfig section and can hand back `''` for an unset flag. Read as
+ *   `false`, the two fields in this package that default ON — `backup-job.enabled` and
+ *   `user.enable` — would come back disabled, `matches` would report an update nobody asked for,
+ *   and the deploy would then WRITE `enabled=0` onto a live job. An empty string is not a
+ *   boolean; it is the absence of one.
+ */
+export declare const bool: (value: unknown, fallback?: boolean) => boolean;
+/**
+ * A boolean on its way INTO a PVE form.
+ *
+ * ⚠️ `undefined` IN, `undefined` OUT — an undeclared field must not be sent at all. Sending `'0'`
+ *   for a prop the caller never set would write PVE's default over whatever is live, turning an
+ *   omission into an edit.
+ */
+export declare const flag: (value?: boolean) => "0" | "1" | undefined;
+/**
+ * A comma list PVE does not promise to give back in the order it was handed.
+ *
+ * ⚠️ `nodes` IS A SET AND PVE DOES NOT PRESERVE ITS ORDER. The zone plugin decodes the list into a
+ *   hash and re-encodes it by joining that hash's keys, so the string you get back is not the one
+ *   you sent. Sorting both sides is what stops a plan reporting an update because two names came
+ *   back the other way round. `peers` gets the same treatment: it is a mesh, not a queue.
+ */
+export declare const csv: (value: readonly string[] | string | undefined) => string;
+/**
+ * A comma list of guest IDs, in numeric order.
+ *
+ * ⚠️ ORDER IS NOT MEANING IN A GUEST LIST, SO IT MUST NOT BE A DIFF. PVE stores `vmid` as the
+ *   comma-separated string it was handed and gives it back the same way, so a declaration listing
+ *   the same guests in another order would otherwise be an update that rewrites the job to say
+ *   exactly what it already said. Both sides are sorted numerically before they meet.
+ *
+ * ⚠️ NUMERIC, NOT LEXICAL — this is why it is not `csv`. Sorted as text, `101` precedes `99`.
+ */
+export declare const guestList: (value: unknown) => string;
+/** `yes`/`true`/`on` and their opposites are the same value as 1/0 to PVE; make them one string. */
+export declare const canonicalToken: (raw: string) => string;
+/**
+ * A PVE property string, flattened to one comparable form.
+ *
+ * ⚠️ A PROPERTY STRING AND ITS PARSED FORM ARE ONE VALUE IN TWO SHAPES, AND PVE HANDS BACK
+ *   WHICHEVER IT LIKES. MEASURED: `fleecing` is WRITTEN as the property string `fleecing=enabled=0`
+ *   and READ BACK as the nested object {"enabled":0}. Comparing raw values would report an update
+ *   on every plan for a job nobody touched — the same forever-diff a create-only field causes. So
+ *   both sides are flattened here, sorted, and only then compared. `prune-backups` goes through
+ *   the same funnel: same kind of value, the normalisation is free, and guessing which shape it
+ *   comes back in is exactly the guess that costs a permanent diff.
+ *
+ * ⚠️ `defaultKey` EXISTS BECAUSE `fleecing=1` IS SHORTHAND FOR `fleecing=enabled=1`. PVE's format
+ *   for it is written `[enabled=]<1|0>`, so a bare token is legal on write and comes back expanded
+ *   on read; unexpanded, the short and long spellings never compare equal. `prune-backups` has no
+ *   default key, so a bare token there is passed through as-is rather than invented into one.
+ */
+export declare const propertyString: (value: unknown, defaultKey?: string) => string;
+/**
+ * An integer PVE may have spelled as a string.
+ *
+ * ⚠️ PVE MAY HAND BACK EITHER `8086` OR `"8086"`. These objects are SectionConfig sections, and the
+ *   integer check VALIDATES the parsed string rather than converting it, so whether a number
+ *   arrives as a number is a property of the version you are talking to. `'8086' === 8086` is
+ *   false, and that is an update consisting of nothing, reported on every plan forever.
+ */
+export declare const int: (value: unknown, fallback: number) => number;
+/**
+ * A PVE update form with its clear-list attached, and the two guaranteed not to overlap.
+ *
+ * ⛔ PVE DIES IF A KEY IS SET AND DELETED IN ONE CALL, AND SIX FAMILIES HERE BUILT THAT FORM BY
+ *   HAND. Measured in the shipped Perl on n2 — `PVE::SectionConfig::delete_from_config`, line 1860:
+ *
+ *     die "cannot set and delete property '$k' at the same time!\n"
+ *         if defined($new_options->{$k});
+ *
+ *   `defined` is the test, not truth, so `strict=0` or `comment=''` in the body counts as SET. The
+ *   concrete failure: a live node-affinity rule with `strict 1` and a declaration carrying
+ *   `strict: false`. `matches` reports an update; the clear-list has to name `strict`, because a
+ *   PUT of `strict=0` merges a falsy value the plugin still stores; and if the body also emits
+ *   `strict: '0'` the PUT is refused. The update never lands, the next plan reports the same
+ *   update, and every deploy 500s — forever.
+ *
+ * ★ SO DISJOINTNESS IS ENFORCED HERE RATHER THAN REASONED ABOUT SIX TIMES. A cleared key is
+ *   dropped from the body: CLEAR WINS. That is the right way round because a clear-list entry is
+ *   computed from "this prop is absent, and absent means remove it", which is a deliberate
+ *   statement, while the body's value for the same key is the coercion of that same absence —
+ *   `flag(false)` is `'0'`, and `'0'` is exactly what must not be sent.
+ *
+ * ⚠️ UNDEFINED VALUES ARE DROPPED TOO, so a form builder may emit `undefined` for a field it does
+ *   not set without the caller filtering first. `new URLSearchParams` would otherwise stringify it
+ *   to the literal text "undefined".
+ */
+export declare const withClears: (fields: Record<string, string | undefined>, clear: readonly string[]) => Record<string, string>;
+//# sourceMappingURL=values.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"values.d.ts","sourceRoot":"","sources":["../../src/proxmox/values.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,mGAAmG;AACnG,eAAO,MAAM,GAAG,UAAW,OAAO,YAAY,MAAM,WACN,CAAC;AAE/C,eAAO,MAAM,IAAI,UAAW,OAAO,8BACW,CAAC;AAE/C;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,eAAO,MAAM,IAAI,UAAW,OAAO,gCAGiB,CAAC;AAErD;;;;;;GAMG;AACH,eAAO,MAAM,IAAI,WAAY,OAAO,0BAA0D,CAAC;AAE/F;;;;;;;GAOG;AACH,eAAO,MAAM,GAAG,UAAW,SAAS,MAAM,EAAE,GAAG,MAAM,GAAG,SAAS,WAKnD,CAAC;AAEf;;;;;;;;;GASG;AACH,eAAO,MAAM,SAAS,UAAW,OAAO,KAAG,MAa1C,CAAC;AAEF,oGAAoG;AACpG,eAAO,MAAM,cAAc,QAAS,MAAM,WAKzC,CAAC;AAEF;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,cAAc,UAAW,OAAO,eAAe,MAAM,KAAG,MAkBpE,CAAC;AAEF;;;;;;;GAOG;AACH,eAAO,MAAM,GAAG,UAAW,OAAO,YAAY,MAAM,WAInD,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,UAAU,WACb,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAC,SACnC,SAAS,MAAM,EAAE,KACvB,MAAM,CAAC,MAAM,EAAE,MAAM,CAOvB,CAAC"}

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

@@ -0,0 +1,76 @@
+/**
+ * The create lane for `Proxmox.ZfsPool`: the form PVE wants, and the wait for the worker it forks.
+ *
+ * ★ SPLIT OUT OF zfs-pool.ts TO KEEP BOTH FILES UNDER THE 250-LINE CAP, and the seam is a real one
+ *   rather than a convenient line number. This file answers "how does a declaration become a pool
+ *   on disks, and how do we know it landed". zfs-pool.ts answers "what is a zpool, what can be
+ *   said about a live one, and when has it changed" — and on this family the answer to the last of
+ *   those is "never", which is why the two halves have so little to say to each other.
+ *
+ * ⚠️ THE `import type` BACK TO zfs-pool.ts IS A CYCLE ON PAPER ONLY — it is type-only, so it is
+ *   erased before anything runs, and the resource's public shape stays in the file that declares
+ *   the resource rather than being moved somewhere odd to dodge the arrow. Same as
+ *   metric-server-form.ts.
+ *
+ * ⚠️ `createPool` TAKES THE READ AS A PARAMETER, GENERIC IN ITS ERROR AND REQUIREMENT CHANNELS,
+ *   rather than importing `pveOperations` and rebuilding the spec here. Two `pveOperations` over
+ *   one spec would be two closures nobody can prove are the same; passing the one the resource
+ *   already built means this file cannot accidentally read the cluster differently from `diff`.
+ */
+import * as Effect from 'effect/Effect';
+import type { ZfsPoolAttributes, ZfsPoolProps } from './zfs-pool.ts';
+/**
+ * The POST body. Every field in it is write-only — nothing here is ever read back.
+ *
+ * ⚠️ `node` IS NOT IN THE BODY: it is already the `nodes/{node}` segment of the URL being POSTed
+ *   to, and a second copy can only disagree with it. Same reasoning as `id` in metric-server.ts.
+ * ⚠️ `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.
+ */
+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 n2: 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, as `pveOperations.reconcile` takes it, finds nothing and would
+ *   report a successful create as the failure "the write returned no error but the object is still
+ *   absent". THAT is why this function exists instead of the factory's reconcile.
+ *
+ * ⚠️ 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. `read` 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. `read` cannot tell "not yet" from "forbidden"
+ *   — both are `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.
+ */
+export declare const createPool: <E, R>(props: ZfsPoolProps, collection: string, path: string, read: (props: ZfsPoolProps) => Effect.Effect<ZfsPoolAttributes | undefined, E, R>) => Effect.Effect<ZfsPoolAttributes, E | Error, R | import("effect/unstable/http/HttpClient").HttpClient>;
+/**
+ * ⛔ `DELETE /nodes/{node}/disks/zfs/{name}` RUNS `zpool destroy` AND THE DATASETS GO WITH IT.
+ *   It is implemented rather than stubbed, because a `delete` that silently does nothing lies to
+ *   whoever reads the plan. What keeps a deleted line from destroying a pool is the resource's
+ *   `defaultRemovalPolicy: 'retain'` above — an orphaned pool is forgotten, not destroyed, and a
+ *   caller who means it says `.pipe(RemovalPolicy.destroy())`.
+ *
+ * ⚠️ `cleanup-config` IS NOT SENT. It 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.
+ */
+export declare const destroyPool: (olds: ZfsPoolProps, path: string) => Effect.Effect<unknown, Error, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=zfs-pool-write.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"zfs-pool-write.d.ts","sourceRoot":"","sources":["../../src/proxmox/zfs-pool-write.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,OAAO,KAAK,MAAM,MAAM,eAAe,CAAC;AAGxC,OAAO,KAAK,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,eAAe,CAAC;AAErE;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAOpE,CAAC;AAKH;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,eAAO,MAAM,UAAU,GAAI,CAAC,EAAE,CAAC,SACtB,YAAY,cACP,MAAM,QACZ,MAAM,QACN,CAAC,KAAK,EAAE,YAAY,KAAK,MAAM,CAAC,MAAM,CAAC,iBAAiB,GAAG,SAAS,EAAE,CAAC,EAAE,CAAC,CAAC,0GAmC/E,CAAC;AAEL;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,WAAW,SAAU,YAAY,QAAQ,MAAM,wFACb,CAAC"}