@zinn-digital/sdk 0.1.1368 → 0.1.1369

package/dist/generated/schema.d.ts

@@ -69806,10 +69806,16 @@ export interface components {
             note?: string;
         };
         BulkJobDetail: components["schemas"]["BulkJob"] & {
+            /** @description For a `find_file` job: the refusal key (e.g. `refusal.bulk.fileProtected`) a `delete_file` of the same path would get, so a report never offers a delete the engine will refuse. `null` when the delete is allowed, and for every other operation. */
+            delete_refusal: string | null;
             items: components["schemas"]["BulkJobItem"][];
         };
         BulkJobItem: {
             error_code: components["schemas"]["BulkErrorCode"] | null;
+            /** @description For a `find_file` or `delete_file` item that succeeded: the file's size and last modified time. `null` for every other item, and for a file item written before these facts were recorded. */
+            file: components["schemas"]["BulkJobItemFile"] | null;
+            /** @description Whether `retry-failed` would reopen this item: every `failed` item, and every `skipped` item whose code is not a final answer. A search that found no such file (`file_missing`, `file_not_regular`) has answered and is not retried. Count these to label a retry control; do not re-derive the rule from `status`. */
+            retryable: boolean;
             /** Format: date-time */
             settled_at: string | null;
             /** @description Carried on the row rather than joined, so the report survives the site being deleted mid-job — which, on a long run, is not hypothetical. */
@@ -69817,6 +69823,18 @@ export interface components {
             site_id: components["schemas"]["Uuid"];
             status: components["schemas"]["BulkItemStatus"];
         };
+        BulkJobItemFile: {
+            /**
+             * Format: date-time
+             * @description When the file was last modified, as the site's filesystem reports it.
+             */
+            modified_at: string;
+            /**
+             * Format: int64
+             * @description Size in bytes. Format it for the reader's locale.
+             */
+            size_bytes: number;
+        };
         /** @description The operation's arguments. Which keys are read depends on `operation`: `plugin_install` takes `slugs` + `activate`; `plugin_activate`, `plugin_deactivate` and `plugin_remove` take a single `slug`; `plugin_update` takes `slugs` and treats an empty list as *"everything with an update waiting"*, which is what a bulk update means in practice; `theme_install` takes `slug` + `activate`; `blueprint_apply` takes `blueprint_id`; `wp_search_replace` takes `search` + `replace`; `stack_apply`, `core_update` and `application_install` take nothing. ⛔ `application_install` deliberately accepts no `admin_email` or title: they come from the site's own blueprint and plan, exactly as they do for a single-site provision, because a bulk field for them is an account-takeover primitive with a form in front of it. */
         BulkJobParams: {
             /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zinn-digital/sdk",
-  "version": "0.1.1368",
+  "version": "0.1.1369",
   "description": "Typed TypeScript client for the Zinn Digital Platform API, generated from its OpenAPI spec.",
   "license": "MIT",
   "author": "Neil Lock \u2014 CEO, Zinn Digital\u00ae Ltd <office@zinndigital.com>",