@homeflare/alchemy 0.1.0

package/dist/proxmox/pbs-prune-job.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pbs-prune-job.d.ts","sourceRoot":"","sources":["../../src/proxmox/pbs-prune-job.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAE7C,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAElD,OAAO,EAAE,KAAK,eAAe,EAAE,KAAK,aAAa,EAAe,MAAM,eAAe,CAAC;AAGtF;;;;;GAKG;AACH,MAAM,WAAW,aAAc,SAAQ,aAAa;IAClD,uFAAuF;IACvF,MAAM,EAAE,SAAS,CAAC;IAClB;;;;OAIG;IACH,EAAE,EAAE,MAAM,CAAC;IACX;+FAC2F;IAC3F,KAAK,EAAE,MAAM,CAAC;IACd;;;;;;OAMG;IACH,QAAQ,EAAE,MAAM,CAAC;IACjB,iGAAiG;IACjG,EAAE,CAAC,EAAE,MAAM,CAAC;IACZ,yFAAyF;IACzF,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;gGAC4F;IAC5F,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,uFAAuF;IACvF,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,aAAa,CAAC,EAAE,MAAM,CAAC;CACxB;AAED,MAAM,WAAW,kBAAkB;IACjC,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,EAAE,MAAM,CAAC;IACjB,EAAE,EAAE,MAAM,CAAC;IACX,mGAAmG;IACnG,WAAW,EAAE,MAAM,CAAC;IACpB,OAAO,EAAE,OAAO,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB,8FAA8F;IAC9F,WAAW,EAAE,MAAM,CAAC;IACpB,aAAa,EAAE,MAAM,CAAC;IACtB,YAAY,EAAE,MAAM,CAAC;IACrB,aAAa,EAAE,MAAM,CAAC;IACtB,cAAc,EAAE,MAAM,CAAC;IACvB,aAAa,EAAE,MAAM,CAAC;CACvB;AAED,MAAM,WAAW,WAAY,SAAQ,QAAQ,CAC3C,cAAc,EACd,aAAa,EACb,kBAAkB,EAClB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ;;;;GAIG;AACH,eAAO,MAAM,WAAW,8CAAwC,CAAC;AAgDjE;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,mBAAmB,iIACiD,CAAC"}

package/dist/proxmox/pbs-sync-job-form.d.ts

@@ -0,0 +1,83 @@
+import type { SyncJobAttributes, SyncJobProps } from './pbs-sync-job.ts';
+/**
+ * The marker for "PBS has no value for this number".
+ *
+ * ⚠️ `-1` RATHER THAN `0`, AND metric-server.ts's `UNSET = -1` IS THE PRECEDENT. `max-depth` has a
+ *   legal value of 0 — sync this namespace and no child of it — which is a completely different
+ *   instruction from the absent field, where PBS recurses as deep as it is allowed. Using 0 as the
+ *   marker would make "no recursion" and "full recursion" the same attribute. `rate-in` and
+ *   `transfer-last` take the same marker for uniformity rather than because 0 is legal for them:
+ *   depending on a schema minimum I could not measure is exactly the kind of guess that becomes a
+ *   forever-diff.
+ */
+export declare const UNSET = -1;
+/**
+ * A PBS rate limit off the wire, as a plain byte count.
+ *
+ * ⛔ THE VALUE GOES OUT AS A NUMBER AND COMES BACK AS PROSE. PBS types `rate-in` as a `HumanByte`,
+ *   which parses `10485760` on the way in and prints something like `10.00 MiB` on the way out, so
+ *   the two sides of a comparison are never the same string. Flattening both to bytes is what makes
+ *   the field comparable at all. REASONED from the type's parse/print asymmetry, NOT measured —
+ *   there was no credential to round-trip one with.
+ * ⚠️ IT ROUNDS, AND A RATE THAT DOES NOT DIVIDE EVENLY WILL NEVER SETTLE. `10.00 MiB` carries two
+ *   decimals, so a declared 10485761 reads back as 10485760, `matches` reports an update, the PUT
+ *   writes the same rounded value, and the next plan reports it again — forever. Declare a whole
+ *   multiple of a binary unit. This is the likeliest forever-diff in the family and the first thing
+ *   to check on the first plan against a live PBS.
+ * ⚠️ AN UNPARSEABLE ANSWER READS AS `UNSET`, which for a DECLARED rate means "not equal" and so an
+ *   update rather than a silent noop. Wrong-but-loud is the right way round here.
+ */
+export declare const bytes: (value: unknown) => number;
+/**
+ * The live group filters, joined for a human.
+ *
+ * ⚠️ DISPLAY ONLY — NEVER SENT, NEVER COMPARED. The ⛔ on the `group-filter` prop says why the field
+ *   is not declarable; this exists so that a plan against an adopted job SHOWS the filters this
+ *   resource is deliberately leaving alone, rather than making them invisible.
+ * ⚠️ THE SEPARATOR IS ` | `, NOT A COMMA: a `regex:` filter may contain either, so no join here is
+ *   unambiguous — and a comma is the one that would invite somebody to parse this back.
+ */
+export declare const filters: (value: unknown) => string;
+/**
+ * ⛔ `id` IS SENT AND IS NOT OPTIONAL. PBS's create takes it rather than inventing one, so this
+ *   family avoids backup-job.ts's worst failure by construction — but only while the id is here.
+ *   A POST without one would be refused rather than silently duplicating the job, which is the
+ *   better failure, and it is still not a reason to leave it out.
+ * ⛔ `sync-direction` IS THE ONE FIELD SENT ONLY ON CREATE. It decides which side `remove-vanished`
+ *   deletes from, it is not compared (see `matches`), and on a PBS old enough to have no push
+ *   support it is an unknown parameter — so sending it on every update would turn every deploy
+ *   against such a server into a 400 over a field nobody was changing.
+ */
+export declare const createBody: (props: SyncJobProps) => Record<string, string>;
+/**
+ * ⚠️ THE UPDATE IS THE SHARED HALF AND NOTHING ELSE — no `id` (it is the path), no
+ *   `sync-direction`, no `delete` list. The factory only PUTs when `matches` is false and the form
+ *   is non-empty, and this form is never empty because `remove-vanished` and the two store names
+ *   are always present. That is fine here: reconcile reaches this line only when something really
+ *   does differ, and re-sending the two store names it just compared is a write of what is already
+ *   there rather than a change.
+ */
+export declare const updateBody: (props: SyncJobProps) => Record<string, string>;
+export declare const handlers: {
+    list: () => import("effect/Effect").Effect<never[], never, never>;
+    read: ({ olds }: {
+        olds: SyncJobProps;
+    }) => import("effect/Effect").Effect<SyncJobAttributes | undefined, never, import("effect/unstable/http/HttpClient").HttpClient>;
+    diff: ({ news, output }: {
+        news: import("alchemy").Input<SyncJobProps>;
+        output: SyncJobAttributes | undefined;
+    }) => import("effect/Effect").Effect<{
+        readonly action: 'update';
+    } | {
+        readonly action: 'noop';
+    } | {
+        readonly action: 'replace';
+    } | undefined, never, import("effect/unstable/http/HttpClient").HttpClient>;
+    reconcile: ({ news }: {
+        news: SyncJobProps;
+    }) => import("effect/Effect").Effect<SyncJobAttributes, Error, import("effect/unstable/http/HttpClient").HttpClient>;
+    delete: ({ olds }: {
+        olds: SyncJobProps;
+    }) => import("effect/Effect").Effect<unknown, Error, import("effect/unstable/http/HttpClient").HttpClient>;
+};
+//# sourceMappingURL=pbs-sync-job-form.d.ts.map

package/dist/proxmox/pbs-sync-job-form.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pbs-sync-job-form.d.ts","sourceRoot":"","sources":["../../src/proxmox/pbs-sync-job-form.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,mBAAmB,CAAC;AAsBzE;;;;;;;;;;GAUG;AACH,eAAO,MAAM,KAAK,KAAK,CAAC;AAgBxB;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,KAAK,UAAW,OAAO,KAAG,MAOtC,CAAC;AAEF;;;;;;;;GAQG;AACH,eAAO,MAAM,OAAO,UAAW,OAAO,KAAG,MACsD,CAAC;AA0ChG;;;;;;;;;GASG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAIpE,CAAC;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,UAAU,UAAW,YAAY,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAAiB,CAAC;AAExF,eAAO,MAAM,QAAQ;;;;;;;;;;;;;;;;;;;;;CAiFnB,CAAC"}

package/dist/proxmox/pbs-sync-job.d.ts

@@ -0,0 +1,246 @@
+/**
+ * `Pbs.SyncJob` — one section of Proxmox Backup Server's `sync.cfg`, declared: a remote datastore's
+ * snapshots pulled into a local one on a schedule.
+ *
+ * ★ IT USES THE SHARED PVE CLIENT, AND THE TYPES STOP THE TWO HOSTS BEING SWAPPED. An earlier
+ *   draft imported a `./pbs-client.ts` that never existed, arguing that reusing the PVE machinery
+ *   would COMPILE and that this was the danger — a PBS host accepted wherever a PVE one belongs,
+ *   every call 401ing, `read` folding that into "absent". The argument was right and the fix is
+ *   the discriminant rather than a second client: `scheme` is REQUIRED on a target, so a PBS host
+ *   is not assignable to a PVE resource or the reverse, and the mistake is a compile error. See
+ *   the ⛔ on `scheme` in credentials.ts.
+ *
+ * ⛔ THE CREDENTIAL IS A PBS TOKEN AND IT DOES NOT EXIST YET; NO MOUNT NAME IS INVENTED IN THIS
+ *   FILE. PBS wants `user@realm!tokenname` plus a UUID secret, issued by PBS — a PVE token is not
+ *   one, whatever it is spelled like. MEASURED from this machine on 2026-09-13: the `claude-code`
+ *   approle cannot enumerate mounts (`bao secrets list` -> 403) and
+ *   `bao token capabilities kv/infra/proxmox/pbs` -> `deny`, so I could not confirm from here what
+ *   does or does not exist. What credentials.ts records is that every PBS token on the kv shelf is
+ *   READ-ONLY (`Audit`, as `monitoring@pve`) and STATIC — too narrow to create a sync job, and
+ *   exactly the kind of credential this provider exists to avoid writing with.
+ *   ★ SO THE MOUNT IS A `PbsTarget.mount` THE STACK SUPPLIES, and somebody has to build it first:
+ *     a dynamic PBS mount with `read` and `provision` roles mirroring `proxmox-tb4`. Until it
+ *     exists this family can be declared and cannot be deployed. `permission denied` means the
+ *     grant is missing — say which mount and role you needed; do not fall back to the shelf token.
+ *
+ * ⚠️ WHAT IS MEASURED AND WHAT IS NOT. MEASURED on 2026-09-13 from this machine, read-only and
+ *   under STRICT TLS (no `-k`; curl reports `ssl_verify_result` 0):
+ *   `GET https://pbs.example.com:8007/api2/json/ping` -> HTTP 200 `{"data":{"pong":true}}`. So
+ *   the host is real, its certificate validates, and PBS WRAPS ITS ANSWER IN THE SAME `{"data": …}`
+ *   ENVELOPE AS PVE — which is what lets the PVE-shaped client body be reused at all.
+ *   ⛔ EVERYTHING ELSE BELOW IS DOCUMENTED, FROM PBS'S PUBLISHED API SCHEMA, AND NOT MEASURED — the
+ *     field list, the parameter spellings, which of them a PUT accepts, the privileges. Without a
+ *     credential every other endpoint answers 401, and PBS answers 401 BEFORE it routes:
+ *     `/api2/json/config/nosuchthing` -> 401, not 404 (measured). So the 401 from
+ *     `/api2/json/config/sync` is not even evidence that the endpoint exists. THE FIRST PLAN
+ *     AGAINST A LIVE PBS IS THE MEASUREMENT. Read it; do not deploy it unseen.
+ *   ⚠️ AN ERROR BODY IS NOT WRAPPED: the 401 body is the bare text `authentication failed`, not
+ *     JSON. `pve()` checks `response.ok` before it parses, so a `pbs()` copied from it is safe —
+ *     provided the check stays in that order.
+ *
+ * ⚠️ `Proxmox.BackupJob` AND `Pbs.SyncJob` ARE NOT THE SAME FAMILY AND THE NAMES NEARLY COLLIDE.
+ *   The first is a PVE vzdump schedule; this is a Proxmox Backup SERVER sync job, on a different
+ *   host. The `Pbs.` prefix is what keeps them apart in a plan, so it is not shortened.
+ *
+ * ★ THE SEAM, SINCE IT IS NOT THE USUAL ONE. This file answers "what a sync job is and what it
+ *   costs to declare one": the props, the attributes, the resource. pbs-sync-job-form.ts answers
+ *   "how it meets PBS": the coercions, the create and update bodies, and — the part that normally
+ *   lives here — `matches`. `matches` went with the wire because it is DOWNSTREAM of the wire:
+ *   ha-rule.ts's rule is that only a field a write can actually set may be compared, so every line
+ *   of that predicate is an argument about what the PUT accepts. Splitting it from the forms would
+ *   have put the claim and its evidence in different files. `Provider.of(handlers)` stays HERE, for
+ *   resource.ts's ⛔: it is the one place the handlers are checked against the concrete resource
+ *   types, and a cast there would be a lie about whether they match.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import type { PveRequirements } from './resource.ts';
+import type { WithPbsTarget } from './resource.ts';
+/**
+ * ⚠️ THE PROPS ARE PBS'S OWN PARAMETER NAMES, DASHES INCLUDED, for backup-job.ts's reason: the form
+ *   builder is then a copy rather than a translation table, and a translation table is one more
+ *   place for a key to be renamed and silently never sent.
+ */
+export interface SyncJobProps extends WithPbsTarget {
+    /**
+     * ⛔ PBS'S SECTION ID AND THIS RESOURCE'S KEY, REQUIRED. Unlike a PVE vzdump job PBS does not
+     *   autogenerate one — `POST /config/sync` takes `id` — so the backup-job.ts failure of creating
+     *   a second job beside the first on every reconcile cannot happen here. It is still required
+     *   rather than derived: to adopt a job that exists, declare the id it already has.
+     * ⚠️ A PROXMOX SAFE ID — letters, digits, `_`, `.`, `-`, 3 to 32 characters — so there is nothing
+     *   in it for `path` below to encode.
+     */
+    id: string;
+    /** The LOCAL datastore the snapshots land in. Required by PBS at create. */
+    store: string;
+    /** Local namespace, e.g. `tenant/db`. Unset means the root namespace, which PBS spells `''`. */
+    ns?: string;
+    /**
+     * ⛔ A REMOTE BY NAME ONLY. THIS RESOURCE NEVER MODELS THE CREDENTIAL BEHIND IT, and a
+     *   `Pbs.Remote` family is OUT OF SCOPE for this package rather than merely unwritten:
+     *   `POST /config/remote` requires `password`, and Alchemy persists props and attributes to its
+     *   state store UNENCRYPTED (StateEncoding.ts tags Redacted values rather than encrypting them),
+     *   which here is the `alchemy` Postgres that pg-backup.sh dumps nightly to CT100. A remote's
+     *   password in a prop is that password in four places, for months. The only Remote resource that
+     *   could exist would refuse `password` the way storage.ts refuses it — as a `never` — and could
+     *   therefore never CREATE a remote, which is a resource that cannot do what its name promises.
+     *   Create remotes out of band (`proxmox-backup-manager remote create`) and name one here.
+     *   ⚠️ The fingerprint is not the problem: a certificate fingerprint is public. The password is.
+     * ⚠️ UNSET MEANS A LOCAL SYNC — datastore to datastore on this same PBS — which is a real and
+     *   supported mode, not an omission. See `matches`: an unset `remote` is NOT compared, so leaving
+     *   it out does not claim a job with a remote is local; it claims nothing at all.
+     */
+    remote?: string;
+    /** The datastore on that remote. Required by PBS at create. */
+    'remote-store': string;
+    /** Namespace on the remote. Unset means its root namespace. */
+    'remote-ns'?: string;
+    /**
+     * A PBS calendar event — `daily`, `hourly`, `mon..fri 02:30`. Unset means the job runs ONLY when
+     * somebody starts it by hand, which is a sync that is not happening; declare one.
+     * ⚠️ THIS COMPARES STRINGS, NOT MEANINGS. A calendar event has many equivalent spellings and PBS
+     *   stores the one it was handed, so declare the spelling the server echoes back.
+     */
+    schedule?: string;
+    /** Single line only — PBS's comment schema rejects a newline. */
+    comment?: string;
+    /**
+     * ⛔ THIS DELETES SNAPSHOTS. NOT "prunes", NOT "tidies" — DELETES, on a schedule, driven by
+     *   ANOTHER SERVER'S STATE. On a PULL job (the default), every backup group in the local `store`
+     *   and `ns` that is no longer on the remote is REMOVED LOCALLY the next time the job runs. The
+     *   remote decides; this side obeys. Somebody pruning hard on the remote, a remote datastore
+     *   restored from an older copy, a remote namespace renamed, or a remote that has simply lost
+     *   data — each of those becomes deletion HERE, and the local copy is usually the copy that was
+     *   supposed to survive the remote.
+     *   ⛔ AND ON A PUSH JOB IT DELETES ON THE REMOTE INSTEAD — same flag, opposite victim. Read
+     *     `sync-direction` before reading this one.
+     * ⚠️ IT IS COMPARED AND SENT EVEN WHEN UNDECLARED, unlike every other optional field here, and
+     *   that is deliberate: undeclared means `false`, so adopting a job somebody had switched this on
+     *   for plans as an UPDATE that switches it off — a real edit, and NOT a free one. It is the
+     *   direction that does not delete, but a job that was BOUNDING a datastore now grows it, and a
+     *   full PBS datastore fails every backup on it. The plan says only "update"; read the live job.
+     */
+    'remove-vanished'?: boolean;
+    /**
+     * The PBS Authid that owns the synced groups, e.g. `sync@pbs` or `sync@pbs!job1`. Unset leaves
+     * the config without one, which PBS reads as `root@pam` AT RUNTIME — so unset and `root@pam` are
+     * not the same value in the config even though they behave alike. Owning a group is what lets an
+     * Authid prune or delete it, so changing this is a permissions change, not a label.
+     * ⚠️ AN AUTHID IS AN IDENTIFIER, NEVER A SECRET — it may name an API token (`user@realm!name`),
+     *   and the token's VALUE is the secret. This resource stores the name and never the value.
+     */
+    owner?: string;
+    /**
+     * Incoming rate limit in BYTES PER SECOND. Unset means unlimited.
+     * ⚠️ DECLARED IN BYTES, STORED AS A HUMAN STRING. PBS types this as a `HumanByte`, so a written
+     *   `10485760` comes back as something like `10.00 MiB`; `bytes()` in the form file parses both
+     *   ends back to a byte count so the two can be compared at all. REASONED from the type, NOT
+     *   measured — I had no credential to round-trip one.
+     * ⛔ DECLARE A VALUE PBS CAN PRINT EXACTLY — a whole multiple of a binary unit. A rate that
+     *   rounds in the printed form (10485761) reads back as the rounded value, never equals what was
+     *   declared, and becomes an update reported on every plan forever. This is the single most
+     *   likely forever-diff in this file; it is the first thing to check on the first plan.
+     * ⚠️ `burst-in`, `rate-out` AND `burst-out` ARE NOT MODELLED. PBS's rate limit is four fields
+     *   flattened into the job; this resource manages one and leaves the others alone, which is safe
+     *   because PBS's update assigns only the parameters it was sent.
+     */
+    'rate-in'?: number;
+    /**
+     * How many namespace levels below `remote-ns` to sync, 0 (no recursion) upwards. Unset means PBS
+     * recurses as deep as it is allowed — which is MORE data, not less, so it is not a safe default
+     * to leave implicit on a job whose target namespace has children.
+     */
+    'max-depth'?: number;
+    /** Sync only the last N snapshots of each group. Unset means all of them. */
+    'transfer-last'?: number;
+    /**
+     * ⛔ NOT DECLARABLE, AND A COMPILE ERROR RATHER THAN A PROP THAT HALF WORKS — the storage.ts
+     *   `password` idiom, for two independent reasons, either of which alone would be enough.
+     *   1. THE WIRE FORM IS AN ARRAY. PBS takes `group-filter` as a repeated parameter
+     *      (`group-filter=type:ct&group-filter=regex:^web`), and `pve()`'s form is
+     *      `Record<string, string>` — one value per key — so a list cannot be expressed at all.
+     *   2. NARROWING A FILTER MAY BE A DELETE. Whether `remove-vanished` skips the groups a filter
+     *      excludes is NOT something I could measure without a credential. If it does not, then
+     *      editing this field on a job with `remove-vanished` set removes every local group the new
+     *      filter excludes. A field that MIGHT delete snapshots when changed does not get a
+     *      half-working prop.
+     *   ★ IT IS STILL REPORTED in the attributes, so a plan shows the filters a hand-made job carries
+     *     and this resource never strips them: undeclared is unmanaged, and PBS's update assigns only
+     *     what it was sent. To make it declarable, fix both halves — a form type that can repeat a
+     *     key, and a MEASURED answer to (2) — in that order.
+     */
+    'group-filter'?: never;
+    /**
+     * `pull` (default) or `push`. ⛔ IT DECIDES WHICH SIDE `remove-vanished` DELETES FROM. Push also
+     * needs a newer PBS: on a server that predates it the parameter is unknown and the create is
+     * refused, which is the honest failure.
+     * ⚠️ CREATE-ONLY HERE, SO A CHANGED DIRECTION PLANS AS NOOP — see `matches`. That is the
+     *   deliberately safe half of an unmeasured question: if PBS does accept it on PUT, the cost of
+     *   this choice is a noop; if PBS refuses it, comparing it would be an update the PUT can never
+     *   perform, on every plan, forever. Retire the declaration and add another, as user.ts says for
+     *   `userid`.
+     */
+    'sync-direction'?: 'pull' | 'push';
+    /**
+     * ⚠️ SYNC ONLY SNAPSHOTS THAT HAVE PASSED VERIFICATION. Present on 4.2 (`sync-job update
+     *   --verified-only <boolean>`, and in its `--delete` enum), and the estate sets it: the parked
+     *   `sync-all-to-dc` job carries `verified-only: true`, so without this prop that job cannot be
+     *   declared as it actually is.
+     * ⛔ IT PAIRS WITH A VERIFICATION JOB THAT ACTUALLY RUNS. With PBS's defaults a snapshot is
+     *   verified once and never again — see `rechecks` in pbs-verify-job-form.ts — so `verified-only`
+     *   on a datastore whose verify job is parked means "sync only what was checked once, long ago".
+     */
+    'verified-only'?: boolean;
+}
+export interface SyncJobAttributes {
+    /** From the props — it is the path this object was read by. */
+    id: string;
+    store: string;
+    /** `''` is the root namespace, which is also how PBS spells it. */
+    ns: string;
+    /** `''` means a LOCAL sync — datastore to datastore on this PBS. */
+    remote: string;
+    'remote-store': string;
+    'remote-ns': string;
+    /** `''` means the job runs only when somebody starts it. */
+    schedule: string;
+    comment: string;
+    'remove-vanished': boolean;
+    /** ⚠️ Absent on the wire means `false`, PBS's own default. */
+    'verified-only': boolean;
+    /** `''` means no owner in the config, i.e. `root@pam` at runtime. An identifier, never a secret. */
+    owner: string;
+    /** Bytes per second, or `UNSET` (-1). See `bytes()`. */
+    'rate-in': number;
+    /** `UNSET` (-1) means unset, which means full recursion. `0` is a real value meaning none. */
+    'max-depth': number;
+    /** `UNSET` (-1) means all snapshots. */
+    'transfer-last': number;
+    /**
+     * ⚠️ REPORTED, NEVER SENT, NEVER COMPARED — the live filter list joined for display only. See the
+     *   ⛔ on the prop for why it is not declarable.
+     */
+    'group-filter': string;
+    /** `pull` or `push`. Reported, never compared — create-only here. */
+    'sync-direction': string;
+}
+export interface PbsSyncJob extends Resource<'Pbs.SyncJob', SyncJobProps, SyncJobAttributes, never, PveRequirements> {
+}
+/**
+ * ⚠️ NO `defaultRemovalPolicy: 'retain'`, and the reasoning is replication-job.ts's. Deleting this
+ *   object removes a SCHEDULE, not data: every snapshot already synced stays in the local
+ *   datastore, and PBS's own pruning is a different job. What is lost is freshness — which is
+ *   destructive in six months rather than today, and is exactly why the plan line deserves reading.
+ */
+export declare const PbsSyncJob: import("alchemy").ResourceClass<PbsSyncJob>;
+/**
+ * ⛔ THE EMPTY `list` FROM THE FACTORY STANDS. `GET /config/sync` hands back every sync job an
+ *   operator ever made in the UI, and adopting one is how a later `alchemy destroy` silently stops
+ *   a second copy being refreshed. Adoption is an explicit act — declare the `id` you mean.
+ * ⚠️ DELETING THE JOB DOES NOT DELETE SNAPSHOTS, AND `remove-vanished` DOES. Those two sentences
+ *   are the whole risk model of this family and they point opposite ways: the DELETE plan line is
+ *   safe today and expensive in six months, while a single `remove-vanished: true` is a standing
+ *   instruction to delete local snapshots whenever another server loses them.
+ */
+export declare const PbsSyncJobProvider: () => import("effect/Layer").Layer<Provider.Provider<PbsSyncJob>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=pbs-sync-job.d.ts.map

package/dist/proxmox/pbs-sync-job.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pbs-sync-job.d.ts","sourceRoot":"","sources":["../../src/proxmox/pbs-sync-job.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqDG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAG7C,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,eAAe,CAAC;AACrD,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,eAAe,CAAC;AAEnD;;;;GAIG;AACH,MAAM,WAAW,YAAa,SAAQ,aAAa;IACjD;;;;;;;OAOG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,4EAA4E;IAC5E,KAAK,EAAE,MAAM,CAAC;IACd,gGAAgG;IAChG,EAAE,CAAC,EAAE,MAAM,CAAC;IACZ;;;;;;;;;;;;;;OAcG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,+DAA+D;IAC/D,cAAc,EAAE,MAAM,CAAC;IACvB,+DAA+D;IAC/D,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;OAKG;IACH,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,iEAAiE;IACjE,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;;;;;;;;;;;;;OAeG;IACH,iBAAiB,CAAC,EAAE,OAAO,CAAC;IAC5B;;;;;;;OAOG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;;;;;;;;;;;;OAaG;IACH,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;;;OAIG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,6EAA6E;IAC7E,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB;;;;;;;;;;;;;;;OAeG;IACH,cAAc,CAAC,EAAE,KAAK,CAAC;IACvB;;;;;;;;;OASG;IACH,gBAAgB,CAAC,EAAE,MAAM,GAAG,MAAM,CAAC;IACnC;;;;;;;;OAQG;IACH,eAAe,CAAC,EAAE,OAAO,CAAC;CAC3B;AAED,MAAM,WAAW,iBAAiB;IAChC,+DAA+D;IAC/D,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,mEAAmE;IACnE,EAAE,EAAE,MAAM,CAAC;IACX,oEAAoE;IACpE,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,EAAE,MAAM,CAAC;IACpB,4DAA4D;IAC5D,QAAQ,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB,iBAAiB,EAAE,OAAO,CAAC;IAC3B,8DAA8D;IAC9D,eAAe,EAAE,OAAO,CAAC;IACzB,oGAAoG;IACpG,KAAK,EAAE,MAAM,CAAC;IACd,wDAAwD;IACxD,SAAS,EAAE,MAAM,CAAC;IAClB,8FAA8F;IAC9F,WAAW,EAAE,MAAM,CAAC;IACpB,wCAAwC;IACxC,eAAe,EAAE,MAAM,CAAC;IACxB;;;OAGG;IACH,cAAc,EAAE,MAAM,CAAC;IACvB,qEAAqE;IACrE,gBAAgB,EAAE,MAAM,CAAC;CAC1B;AAED,MAAM,WAAW,UAAW,SAAQ,QAAQ,CAC1C,aAAa,EACb,YAAY,EACZ,iBAAiB,EACjB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ;;;;;GAKG;AACH,eAAO,MAAM,UAAU,6CAAsC,CAAC;AAE9D;;;;;;;;GAQG;AACH,eAAO,MAAM,kBAAkB,gIACgD,CAAC"}

package/dist/proxmox/pbs-verify-job-form.d.ts

@@ -0,0 +1,114 @@
+/**
+ * A verification job's props as the form PBS wants, and the one derived string worth reporting.
+ *
+ * ★ SPLIT OUT OF pbs-verify-job.ts TO KEEP BOTH FILES UNDER THE 250-LINE CAP, on the seam
+ *   replication-job-form.ts and ha-rule-form.ts already cut: this file answers "how does a
+ *   declaration become a PBS write, and what do the two filter fields actually mean", and
+ *   pbs-verify-job.ts answers "what is a verification job and when has it changed". Nothing here
+ *   reads the host and nothing here decides a diff.
+ *
+ * ⚠️ THE `import type` BACK TO pbs-verify-job.ts IS A CYCLE ON PAPER ONLY — type-only, erased
+ *   before anything runs, and `PbsVerifyJobProps` stays public in the file declaring the resource.
+ *
+ * ⛔ THERE IS NO `disable` FIELD ON A PBS VERIFICATION JOB, AND SHIPPING A PROP FOR ONE WOULD HAVE
+ *   BEEN THE WORST BUG IN THIS FAMILY. Prune jobs have `disable` and sync jobs have `disable`;
+ *   `VerificationJobConfig` does not, in the struct, in the API schema, or in the update handler's
+ *   `DeletableProperty` enum — read at HEAD of pbs-api-types and src/api2/config/verify.rs on
+ *   2026-09-13. A `disable` prop would therefore be a prop that either does nothing or 400s the
+ *   whole call (the create schema has `additional_properties: false`, so an unknown key is
+ *   rejected with "schema does not allow additional properties"). Either way it would be a
+ *   declaration saying "verification is paused" that PBS never agreed to. The real off switch is
+ *   an absent `schedule`.
+ *   ★ NOW VERIFIED AGAINST THE RUNNING HOST, which this comment previously said it was not.
+ *     `proxmox-backup-manager verify-job update --help` on the live 4.2 server offers
+ *     `--comment --delete --digest --ignore-verified --max-depth --ns --outdated-after
+ *     --read-threads --schedule --store --verify-threads` — no `--disable` — and its `--delete`
+ *     enum contains `schedule`. Both halves of the claim hold on this estate's actual version.
+ *   ⚠️ `read-threads` AND `verify-threads` EXIST ON 4.2 AND ARE NOT PROPS HERE. Nothing on this
+ *     estate sets either, and a prop nobody uses is an abstraction with no user — the same reason
+ *     `PveSpec.immutable` was backed out. Add them when something needs them.
+ *
+ * ⛔ `withClears` FROM values.ts IS DELIBERATELY NOT USED HERE, AND USING IT WOULD BREAK EVERY
+ *   UPDATE. PVE's `delete` is ONE comma-separated string; PBS's is an ARRAY of an enum. MEASURED in
+ *   proxmox-schema's `do_parse_parameter_strings`: for an `Schema::Array` property each occurrence
+ *   of the key pushes ONE element, so a form body must REPEAT the key — `delete=ns&delete=comment`.
+ *   `withClears` emits `delete: 'ns,comment'`, which PBS parses as a single element `"ns,comment"`,
+ *   which is not a `DeletableProperty` variant, so the call fails with a parameter error. It fails
+ *   loudly rather than quietly, which is the only good news in it.
+ *   ★ AND IT COULD NOT BE FIXED IN THIS FILE ANYWAY. `client.ts` types a form as
+ *     `Record<string, string>` and builds it with `new URLSearchParams(form)`; neither a plain
+ *     object nor that constructor overload can express a repeated key. Clearing a PBS field needs
+ *     a client that takes entry pairs. Until one exists, this form SETS and never CLEARS — so an
+ *     undeclared field is left alone and, in pbs-verify-job.ts, is not compared either.
+ */
+import type { PbsVerifyJobProps } from './pbs-verify-job.ts';
+/**
+ * What the live pair actually causes, rendered for a plan line.
+ *
+ * ⛔ THE DEFAULTS MEAN "VERIFY EACH SNAPSHOT EXACTLY ONCE, EVER", AND THAT IS THE FAILURE THIS
+ *   WHOLE FAMILY EXISTS TO MAKE VISIBLE. Read from src/backup/verify.rs `verify_filter` and
+ *   src/server/verify_job.rs at HEAD on 2026-09-13, the filter is:
+ *
+ *     ignore_verified = ignore_verified.unwrap_or(true)      // absent means TRUE
+ *     if !ignore_verified                       -> verify
+ *     manifest has no verify state              -> verify
+ *     outdated_after is None                    -> SKIP, forever
+ *     days_since_last_verify > outdated_after   -> verify
+ *
+ *   So a job created with neither field set — the shape the PBS web UI produces when nobody
+ *   touches those two boxes — checks every snapshot once on the run after it is written and then
+ *   never looks at it again. Bit rot that appears a month later is never found. The job stays
+ *   green the entire time, because a job that verified nothing verified nothing badly.
+ *
+ * ⚠️ A FAILED PAST VERIFICATION IS SKIPPED TOO. `verify_filter` looks only at whether a verify
+ *   state EXISTS, never at whether it says Ok or Failed, so a snapshot that failed once is not
+ *   re-checked by a defaulted job either. Pair that with a prune job and the failure ages out
+ *   without anyone confirming it.
+ *
+ * ⛔ `outdated-after: 0` DOES NOT MEAN "NEVER", THOUGH PBS'S OWN STRUCT DOC SAYS IT DOES. That
+ *   comment — "Reverify snapshots after X days, never if 0" — contradicts the code beside it: the
+ *   test is `days_since_last_verify > max_age`, so `0` re-verifies everything checked more than a
+ *   day ago, i.e. very nearly every run. The schema text calls `0` deprecated and the minimum is
+ *   `0`, so it is accepted. "Never" is the ABSENT value, not the zero — and this resource cannot
+ *   get a job back to absent (see the ⛔ on `withClears` above), so a declaration that sets
+ *   `outdated-after` has made a one-way choice. Undo it by hand:
+ *   `proxmox-backup-manager verify-job update <id> --delete outdated-after`.
+ *
+ * ⚠️ THE COMPARISON IS INTEGER DAYS SINCE THE LAST RUN'S START, `(now - upid.starttime) / 86400`,
+ *   and it is strictly greater-than. `outdated-after: 30` therefore re-checks on day 31.
+ */
+export declare const rechecks: (ignoreVerified: boolean, outdatedAfter: number) => string;
+/**
+ * The form for create and update alike.
+ *
+ * ⛔ `schedule: null` OMITS THE KEY, AND ON AN UPDATE THAT DOES NOT CLEAR AN EXISTING ONE. This
+ *   form SETS and never CLEARS — the ⛔ on `withClears` above is why — so declaring `null` against
+ *   a job that already has a schedule plans an update that changes nothing, every time. Park a job
+ *   by hand once and the declaration then describes it truthfully:
+ *   `proxmox-backup-manager verify-job update <id> --delete schedule`. The honest failure is a
+ *   plan that keeps asking; the dishonest one would be a form that quietly reported success.
+ *
+ * ⚠️ `store` AND `ignore-verified` ARE ALWAYS SENT BECAUSE THEY ARE ALWAYS COMPARED.
+ *   A field compared against a default but not sent as that default is an update reported on every
+ *   plan that the write never performs — backup-job.ts and replication-job-form.ts both record the
+ *   same trade. `ignore-verified` is the only one of the three with a PBS-side default, and it is
+ *   TRUE, so an undeclared prop is sent as `1` rather than left out.
+ *
+ * ⚠️ THE BOOLEAN IS SPELLED INLINE RATHER THAN THROUGH `flag()` FROM values.ts, AND THAT IS A TYPE
+ *   FACT RATHER THAN A STYLE ONE. `flag` answers `'1' | '0' | undefined` so that an undeclared
+ *   field is dropped; here the field must never be dropped, and the `undefined` in its return type
+ *   is not assignable to a `Record<string, string>` form body.
+ *
+ * ⚠️ PBS ACCEPTS BOTH `application/x-www-form-urlencoded` AND `application/json` AND NOTHING ELSE —
+ *   any other content type is rejected outright with "unsupported content type", measured in
+ *   proxmox-rest-server's `get_request_parameters`. `client.ts` sends the form encoding whenever a
+ *   body is present, so it is already speaking one of the two. Numbers are stringified here for
+ *   that reason; PBS parses them back through the integer schema.
+ *
+ * ⛔ `ns` IS DROPPED WHEN IT IS EMPTY, NOT SENT AS `''`. The empty string IS a legal namespace
+ *   value — `BACKUP_NS_RE` is wrapped in `(?:…)?`, so it passes the schema and reaches the update
+ *   handler — and the handler then throws it away at `if !ns.is_root()`. Sending it would look like
+ *   a write that moves the job to the root namespace and would silently be nothing at all.
+ */
+export declare const shape: (props: PbsVerifyJobProps) => Record<string, string>;
+//# sourceMappingURL=pbs-verify-job-form.d.ts.map

package/dist/proxmox/pbs-verify-job-form.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pbs-verify-job-form.d.ts","sourceRoot":"","sources":["../../src/proxmox/pbs-verify-job-form.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0CG;AACH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAC;AAE7D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,eAAO,MAAM,QAAQ,mBAAoB,OAAO,iBAAiB,MAAM,KAAG,MAMzE,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,eAAO,MAAM,KAAK,UAAW,iBAAiB,KAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAUpE,CAAC"}

package/dist/proxmox/pbs-verify-job.d.ts

@@ -0,0 +1,145 @@
+/**
+ * `Pbs.VerifyJob` — one section of PBS's `verification.cfg`, declared.
+ *
+ * ★ THIS IS THE FAMILY THAT ANSWERS "ARE THE BACKUPS ACTUALLY GOOD", AND NOTHING ELSE IN THIS
+ *   PACKAGE DOES. A datastore reports free space, a prune job reports that it ran, and every
+ *   snapshot in the store can still be unreadable: PBS learns a chunk has rotted only when
+ *   something reads it back and checks its digest, and verification is the only thing that does
+ *   that on a schedule. An undeclared verify job is the reason nobody notices for months — and a
+ *   green `Proxmox.BackupJob` makes it worse rather than better, because a vzdump job that says
+ *   "OK" every night is exactly the evidence people stop at.
+ *
+ * ⛔ THIS FILE CANNOT AUTHENTICATE UNTIL TWO THINGS OUTSIDE IT CHANGE, AND IT IS SHIPPED SAYING SO
+ *   RATHER THAN SHIPPED LOOKING FINISHED. Both are recorded on `PbsTarget` below:
+ *     1. `credentials.ts` has no PBS mint. MEASURED 2026-09-13 from this Mac: the `claude-code`
+ *        approle is refused `sys/mounts`, `kv/infra/proxmox` and `proxmox-pbs/creds/read` alike —
+ *        403 permission denied on all three — so there is no mount to name and none is invented.
+ *     2. `client.ts`'s `authorization()` builds a PVE header, and PBS will not accept it. See the
+ *        ⛔ on `PbsTarget`.
+ *   Until both land, every call 401s, `pveOperations.read` folds that into "absent", and the plan
+ *   reports `create` for a job that is plainly there. The deploy then FAILS at the POST rather
+ *   than clobbering anything — an unauthenticated POST 401s, and an authenticated one is refused
+ *   because PBS will not take a duplicate section id — so the cost is a LYING PLAN and a broken
+ *   run, not a lost job. That is still reason enough not to wire it into a stack yet: a plan
+ *   nobody can trust is its own outage.
+ *
+ * ⚠️ THE SHAPES BELOW ARE READ FROM PUBLISHED SOURCE, NOT MEASURED ON THIS ESTATE. Everything is
+ *   taken from `pbs-api-types/src/jobs.rs`, `src/api2/config/verify.rs`, `src/server/verify_job.rs`
+ *   and `src/backup/verify.rs` at HEAD of the Proxmox git mirrors on 2026-09-13. What WAS measured
+ *   here: `pbs.example.com:8007` and `pbs.mgmt.example.com:8007` both answer HTTP 401 under
+ *   STRICT TLS (curl `ssl_verify_result=0`), so no `-k` is needed and `client.ts`'s plain `fetch`
+ *   reaches PBS unchanged. The running host's own schema was NOT read — no credential — so a PBS
+ *   older than HEAD may differ.
+ */
+import { Resource } from 'alchemy';
+import * as Provider from 'alchemy/Provider';
+import type { PbsTarget } from './credentials.ts';
+import { type PveRequirements } from './resource.ts';
+export interface PbsVerifyJobProps {
+    /** ⛔ A PBS host, never a PVE cluster. See `PbsTarget`. */
+    target: PbsTarget;
+    /**
+     * ⛔ The primary key, REQUIRED, and never left to PBS. 3–32 chars of
+     * `[A-Za-z0-9_][A-Za-z0-9._-]*`. PBS refuses a duplicate section id outright, which is the loud
+     * failure `Proxmox.BackupJob` had to engineer for itself — but only because the id is sent.
+     */
+    id: string;
+    /** Datastore name, 3–32 safe-id chars. ⚠️ MUTABLE — see the ⚠️ on `matches`. */
+    store: string;
+    /**
+     * ⛔ THE KEY IS REQUIRED AND THE VALUE MAY BE `null`. PBS makes the field optional; this family
+     * refuses to let you OMIT it, which is not the same thing. A verification job with no schedule
+     * never runs on its own and PBS reports it as perfectly healthy — and an absent schedule is also
+     * the only way to turn one off, because there is NO `disable` field on a verification job.
+     * ⛔ THAT LAST CLAIM IS NOW MEASURED, not read from source. `proxmox-backup-manager verify-job
+     *   update --help` on the live 4.2 host lists `--delete
+     *   ignore-verified|comment|schedule|outdated-after|ns|max-depth|read-threads|verify-threads`
+     *   and no `--disable` anywhere. So `schedule` is deletable — "parked" is a state PBS supports —
+     *   and `disable` genuinely does not exist. pbs-verify-job-form.ts said this was read off the
+     *   source and NOT verified against a running host; it is now verified, on this one.
+     * ★ SO `null` MEANS "DELIBERATELY PARKED" AND OMITTING IT IS STILL AN ERROR. The original
+     *   required-string kept you from declaring verification that never happens, which is right, but
+     *   it also made a genuinely parked job UNDECLARABLE — and the estate has one: `v-datacenter` is
+     *   parked because syno1 is powered off, comment and runbook and all. A resource that cannot
+     *   describe what is really there pushes the operator back to the CLI, which is the failure this
+     *   package exists to end. Writing `schedule: null` costs a word and says the quiet part out
+     *   loud; leaving the key out still will not compile.
+     * ⚠️ ADOPTING A SCHEDULELESS JOB WITH A SCHEDULE DECLARED GIVES IT ONE ON THE FIRST DEPLOY, which
+     *   is the intended direction and is still a write nobody asked for in words. `matches` compares
+     *   `schedule`, the live value reads `''`, so the first reconcile PUTs the declared one and
+     *   verification starts running that night. Read the first plan against an adopted job.
+     * ⚠️ A systemd calendar event. Spelled `daily`, `sat 02:00`, `mon..fri 23:00`. A step expression
+     *   is legal too and is not written out here: those two characters would close this comment.
+     */
+    schedule: string | null;
+    /**
+     * The namespace to verify, e.g. `tier1/prod`. Omitted means the datastore root.
+     * ⛔ NEVER SENT AS THE EMPTY STRING. MEASURED in the update handler: `if !ns.is_root()` — a root
+     *   namespace on a PUT is accepted by the schema, reaches the handler and is then SILENTLY
+     *   DISCARDED. A job cannot be moved back to the root namespace by this resource at all; that
+     *   needs `--delete ns` by hand. So an undeclared `ns` is neither sent nor compared.
+     */
+    ns?: string;
+    /**
+     * How many namespace levels below `ns` to descend. `0` is that level only; PBS's maximum is 7.
+     * ⚠️ PBS's own default is FULL recursion (7), not 0. Undeclared means undeclared here: not sent,
+     *   not compared, because "unset" and "7" are stored differently and only one is reachable.
+     */
+    'max-depth'?: number;
+    /**
+     * ⛔ THE HALF OF THE PAIR THAT DECIDES WHETHER THIS JOB EVER RE-CHECKS ANYTHING. Defaults to
+     *   TRUE. Read `rechecks` and the ⛔ in pbs-verify-job-form.ts before setting either of these.
+     */
+    'ignore-verified'?: boolean;
+    /** Days after which a past verification is stale. ⛔ See the pair's ⛔ in the form file. */
+    'outdated-after'?: number;
+    /** ⚠️ PBS TRIMS IT AND STORES AN EMPTY ONE AS ABSENT, so `'  '` reads back as `''`. */
+    comment?: string;
+}
+export interface PbsVerifyJobAttributes {
+    id: string;
+    store: string;
+    schedule: string;
+    ns: string;
+    /** ⚠️ `-1` means "no max-depth in the section". `0` is a real setting meaning no recursion. */
+    'max-depth': number;
+    'ignore-verified': boolean;
+    /** ⚠️ `-1` means "unset", which is NOT `0`. See the ⛔ in the form file. */
+    'outdated-after': number;
+    comment: string;
+    /**
+     * ★ WHAT THIS JOB ACTUALLY RE-CHECKS, IN ENGLISH, COMPUTED FROM THE LIVE PAIR. REPORTED, NEVER
+     *   COMPARED — it is derived from two fields `matches` already compares, so diffing it would
+     *   double-count them. It exists because the failure this family guards against is a job that
+     *   looks healthy in every column and verifies each snapshot exactly once, ever; that job reads
+     *   `never` here. A plan line is the only place anyone will see it.
+     */
+    rechecks: string;
+}
+export interface PbsVerifyJob extends Resource<'Pbs.VerifyJob', PbsVerifyJobProps, PbsVerifyJobAttributes, never, PveRequirements> {
+}
+/**
+ * ⚠️ NO `defaultRemovalPolicy: 'retain'`, DELIBERATELY, AND IT IS THE CLOSER CALL THAN IT LOOKS.
+ *   The section holds no data — deleting it destroys nothing, the way `Proxmox.BackupJob`'s delete
+ *   destroys no archives. What it destroys is the CHECKING, silently and permanently, and PBS will
+ *   not refuse it the way it refuses to remove a datastore in use. `retain` would hide that behind
+ *   a state-row drop instead of showing it as a plan line, and the plan line is the only warning
+ *   anyone gets. Pipe `RemovalPolicy.retain()` per declaration where the job must outlive the code.
+ */
+export declare const PbsVerifyJob: import("alchemy").ResourceClass<PbsVerifyJob>;
+/**
+ * ⛔ `list` IS EMPTY, INHERITED FROM `pveHandlers`, AND THE REASON IS SHARPER HERE THAN ELSEWHERE.
+ *   `GET /config/verify` returns every verification job the caller can see, including the
+ *   ones the PBS installer and a human made. Adopting those would put Alchemy one dropped line
+ *   away from DELETING a datastore's only verification schedule — and deleting it destroys nothing
+ *   visible, so the loss is discovered the day a restore fails and there is no verification history
+ *   to say when the rot started. Adoption stays explicit: declare the existing id.
+ *
+ * ⚠️ NO `digest` IS SENT ON UPDATE OR DELETE, SO THIS IS LAST-WRITER-WINS. PBS accepts an optional
+ *   `digest` on both and would refuse a write made against a stale read. Sending one would need a
+ *   read-then-write window this provider does not have — `pveOperations` reads and writes in two
+ *   separate calls with two separate mints — so a concurrent edit from the PBS UI is overwritten
+ *   rather than refused. Same behaviour as every PVE family here; stated because PBS offers better.
+ */
+export declare const PbsVerifyJobProvider: () => import("effect/Layer").Layer<Provider.Provider<PbsVerifyJob>, never, import("effect/unstable/http/HttpClient").HttpClient>;
+//# sourceMappingURL=pbs-verify-job.d.ts.map

package/dist/proxmox/pbs-verify-job.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pbs-verify-job.d.ts","sourceRoot":"","sources":["../../src/proxmox/pbs-verify-job.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AACnC,OAAO,KAAK,QAAQ,MAAM,kBAAkB,CAAC;AAE7C,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAElD,OAAO,EAAE,KAAK,eAAe,EAAe,MAAM,eAAe,CAAC;AAGlE,MAAM,WAAW,iBAAiB;IAChC,0DAA0D;IAC1D,MAAM,EAAE,SAAS,CAAC;IAClB;;;;OAIG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,gFAAgF;IAChF,KAAK,EAAE,MAAM,CAAC;IACd;;;;;;;;;;;;;;;;;;;;;;;;OAwBG;IACH,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB;;;;;;OAMG;IACH,EAAE,CAAC,EAAE,MAAM,CAAC;IACZ;;;;OAIG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;OAGG;IACH,iBAAiB,CAAC,EAAE,OAAO,CAAC;IAC5B,0FAA0F;IAC1F,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,uFAAuF;IACvF,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED,MAAM,WAAW,sBAAsB;IACrC,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,EAAE,MAAM,CAAC;IACjB,EAAE,EAAE,MAAM,CAAC;IACX,+FAA+F;IAC/F,WAAW,EAAE,MAAM,CAAC;IACpB,iBAAiB,EAAE,OAAO,CAAC;IAC3B,2EAA2E;IAC3E,gBAAgB,EAAE,MAAM,CAAC;IACzB,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;;OAMG;IACH,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,MAAM,WAAW,YAAa,SAAQ,QAAQ,CAC5C,eAAe,EACf,iBAAiB,EACjB,sBAAsB,EACtB,KAAK,EACL,eAAe,CAChB;CAAG;AAEJ;;;;;;;GAOG;AACH,eAAO,MAAM,YAAY,+CAA0C,CAAC;AAuEpE;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,oBAAoB,kIACkD,CAAC"}