@hostwebhook/node-types 1.74.0 → 1.75.1

package/dist/calendar-operations.js

@@ -58,8 +58,15 @@ const eventConfigParams = () => [
     { name: 'summaryTemplate', target: 'eventConfig', label: 'Summary', type: 'template', placeholder: '{{payload.title}}', execKey: 'summary' },
     { name: 'descriptionTemplate', target: 'eventConfig', label: 'Description', type: 'template', placeholder: 'Event description... (supports {{templates}})', execKey: 'description' },
     { name: 'locationTemplate', target: 'eventConfig', label: 'Location', type: 'template', placeholder: '{{payload.location}}', execKey: 'location' },
-    { name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', execKey: 'start' },
-    { name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', execKey: 'end' },
+    /* Los `description` de estos dos son la única pantalla donde el usuario se
+       entera de la regla de ambigüedad ANTES de mandar el payload. `05-06-2026`
+       se rechaza en ejecución (ver `normalizeDate`), y un rechazo que sólo
+       aparece en el log del run llega tarde: aquí se dice al lado del campo.
+       El de End Date dice además que es el ÚLTIMO DÍA INCLUIDO, porque el `+1`
+       de la exclusividad de Google lo pone HostWebhook y sin decirlo el usuario
+       lo escribiría dos veces. */
+    { name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', description: 'YYYY-MM-DD for an all-day event, or YYYY-MM-DDTHH:mm:ss for a timed one (interpreted in the Time Zone below). M-D-YYYY and D-M-YYYY work only when one part is above 12 — 05-06-2026 is rejected as ambiguous instead of guessed.', execKey: 'start' },
+    { name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', description: 'YYYY-MM-DD or YYYY-MM-DDTHH:mm:ss, same rules as Start Date. For all-day events this is the LAST DAY INCLUDED — HostWebhook adds the extra day Google needs, so a trip ending 2026-09-21 goes in as 2026-09-21.', execKey: 'end' },
     {
         name: 'attendeesTemplate',
         target: 'eventConfig',

package/dist/esm/calendar-operations.js

@@ -54,8 +54,15 @@ const eventConfigParams = () => [
     { name: 'summaryTemplate', target: 'eventConfig', label: 'Summary', type: 'template', placeholder: '{{payload.title}}', execKey: 'summary' },
     { name: 'descriptionTemplate', target: 'eventConfig', label: 'Description', type: 'template', placeholder: 'Event description... (supports {{templates}})', execKey: 'description' },
     { name: 'locationTemplate', target: 'eventConfig', label: 'Location', type: 'template', placeholder: '{{payload.location}}', execKey: 'location' },
-    { name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', execKey: 'start' },
-    { name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', execKey: 'end' },
+    /* Los `description` de estos dos son la única pantalla donde el usuario se
+       entera de la regla de ambigüedad ANTES de mandar el payload. `05-06-2026`
+       se rechaza en ejecución (ver `normalizeDate`), y un rechazo que sólo
+       aparece en el log del run llega tarde: aquí se dice al lado del campo.
+       El de End Date dice además que es el ÚLTIMO DÍA INCLUIDO, porque el `+1`
+       de la exclusividad de Google lo pone HostWebhook y sin decirlo el usuario
+       lo escribiría dos veces. */
+    { name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', description: 'YYYY-MM-DD for an all-day event, or YYYY-MM-DDTHH:mm:ss for a timed one (interpreted in the Time Zone below). M-D-YYYY and D-M-YYYY work only when one part is above 12 — 05-06-2026 is rejected as ambiguous instead of guessed.', execKey: 'start' },
+    { name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', description: 'YYYY-MM-DD or YYYY-MM-DDTHH:mm:ss, same rules as Start Date. For all-day events this is the LAST DAY INCLUDED — HostWebhook adds the extra day Google needs, so a trip ending 2026-09-21 goes in as 2026-09-21.', execKey: 'end' },
     {
         name: 'attendeesTemplate',
         target: 'eventConfig',

package/dist/esm/index.d.ts

@@ -30,8 +30,8 @@ export { DISCORD_TOOLKIT_SPECS, DISCORD_TOOLKIT_BY_TOOL_NAME, herramientasDeDisc
 export type { DiscordToolkitSpec, DiscordToolkitParameter, } from './discord-toolkit.js';
 export { MAILCHIMP_OPERATIONS, MAILCHIMP_OPERATION_SPECS, MAILCHIMP_CONTACT_STATUSES, isMailchimpOperation, } from './mailchimp-operations.js';
 export type { MailchimpOperation, MailchimpContactStatus, MailchimpParamSpec, MailchimpOperationSpec, } from './mailchimp-operations.js';
-export { SHOPIFY_OPERATIONS, SHOPIFY_OPERATION_SPECS, SHOPIFY_TAGGABLE_RESOURCES, SHOPIFY_SEARCHABLE_RESOURCES, isShopifyOperation, } from './shopify-operations.js';
-export type { ShopifyOperation, ShopifyTaggableResource, ShopifySearchableResource, ShopifyParamSpec, ShopifyOperationSpec, } from './shopify-operations.js';
+export { SHOPIFY_OPERATIONS, SHOPIFY_OPERATION_SPECS, SHOPIFY_OPERATION_SCOPES, SHOPIFY_TAGGABLE_RESOURCES, SHOPIFY_SEARCHABLE_RESOURCES, SHOPIFY_CANCEL_REASONS, SHOPIFY_PRODUCT_STATUSES, isShopifyOperation, scopesQueFaltanEnShopify, } from './shopify-operations.js';
+export type { ShopifyOperation, ShopifyTaggableResource, ShopifySearchableResource, ShopifyCancelReason, ShopifyProductStatus, ShopifyParamSpec, ShopifyOperationSpec, } from './shopify-operations.js';
 export { GITHUB_OPERATIONS, GITHUB_OPERATION_SPECS, GITHUB_DROPDOWN_OPERATIONS, GITHUB_ITERABLE_OPERATIONS, isGithubOperation, } from './github-operations.js';
 export type { GithubOperation, GithubParamType, GithubParamSpec, GithubOperationSpec, } from './github-operations.js';
 export { JIRA_OPERATIONS, JIRA_OPERATION_SPECS, JIRA_DROPDOWN_OPERATIONS, JIRA_ITERABLE_OPERATIONS, isJiraOperation, } from './jira-operations.js';

package/dist/esm/index.js

@@ -29,7 +29,7 @@ export { DISCORD_OPERATIONS, DISCORD_OPERATION_SPECS, DISCORD_CAPACIDADES_POR_CR
    ve el LLM. Es la misma pareja que ya tienen Telegram, Sheets y compañía. */
 export { DISCORD_TOOLKIT_SPECS, DISCORD_TOOLKIT_BY_TOOL_NAME, herramientasDeDiscordPara, } from './discord-toolkit.js';
 export { MAILCHIMP_OPERATIONS, MAILCHIMP_OPERATION_SPECS, MAILCHIMP_CONTACT_STATUSES, isMailchimpOperation, } from './mailchimp-operations.js';
-export { SHOPIFY_OPERATIONS, SHOPIFY_OPERATION_SPECS, SHOPIFY_TAGGABLE_RESOURCES, SHOPIFY_SEARCHABLE_RESOURCES, isShopifyOperation, } from './shopify-operations.js';
+export { SHOPIFY_OPERATIONS, SHOPIFY_OPERATION_SPECS, SHOPIFY_OPERATION_SCOPES, SHOPIFY_TAGGABLE_RESOURCES, SHOPIFY_SEARCHABLE_RESOURCES, SHOPIFY_CANCEL_REASONS, SHOPIFY_PRODUCT_STATUSES, isShopifyOperation, scopesQueFaltanEnShopify, } from './shopify-operations.js';
 export { GITHUB_OPERATIONS, GITHUB_OPERATION_SPECS, GITHUB_DROPDOWN_OPERATIONS, GITHUB_ITERABLE_OPERATIONS, isGithubOperation, } from './github-operations.js';
 export { JIRA_OPERATIONS, JIRA_OPERATION_SPECS, JIRA_DROPDOWN_OPERATIONS, JIRA_ITERABLE_OPERATIONS, isJiraOperation, } from './jira-operations.js';
 export { BUCKET_OPERATIONS, BUCKET_OPERATION_SPECS, BUCKET_ITERABLE_OPERATIONS, isBucketOperation, } from './bucket-operations.js';

package/dist/esm/shopify-operations.d.ts

@@ -2,18 +2,24 @@
  * Shopify Admin API operations — single source of truth across the api, the
  * dashboard and downstream consumers (MCP server).
  *
- * ## Four, out of several hundred
+ * ## Ten, out of several hundred
  *
- * The Admin API has hundreds of mutations. This node exposes four, and the
+ * The Admin API has hundreds of mutations. This node exposes ten, and the
  * choice is argued in `api/docs/ADR-0007-shopify.md`: a menu of everything is
- * how a node becomes unusable, and these four cover what people actually
- * automate — put a customer in the store, tag something, sync stock, and read
- * back what the store already knows.
+ * how a node becomes unusable.
  *
- * Product creation and order fulfilment were considered and left out of v1.
- * A product means variants, media and prices; a fulfilment means a location, a
- * fulfilment service and a state machine. Each is a configuration surface of
- * its own, not a field.
+ * The first four cover what people automate on day one — put a customer in the
+ * store, tag something, sync stock, and read back what the store already
+ * knows. The six added on 2026-09-08 cover what they ask for on day two: the
+ * order lifecycle (draft → complete → fulfil → cancel), custom data
+ * (metafields) and putting a product in the catalogue.
+ *
+ * ⚠️ **Every entry below carries the OAuth scope it needs**, in
+ * `SHOPIFY_OPERATION_SCOPES`. That is not documentation: a scope missing from
+ * the credential answers HTTP 403 on a call that looks perfectly formed, and
+ * on Shopify a scope is granted at INSTALL time — adding one to the app means
+ * every existing credential has to be reconnected before it can use the new
+ * operation.
  *
  * ## GraphQL only, and the version is not ours to drift on
  *
@@ -54,8 +60,35 @@
  * `inventoryAdjustQuantities` must be sent with the `@idempotent` directive
  * and an idempotency key. A stock adjustment is the one operation here where a
  * silent retry is a real inventory error, so this is not boilerplate.
+ *
+ * ## What was verified for the six added on 2026-09-08
+ *
+ * Read off the Admin GraphQL reference for the current version, not recalled.
+ * The pages, and the one fact from each that a from-memory version gets wrong:
+ *
+ * - `draftOrderCreate(input: DraftOrderInput!)` — `lineItems` is the only
+ *   required field of the input, and each item is `{ variantId, quantity }`
+ *   OR `{ title, originalUnitPrice, quantity }` for a custom line.
+ * - `draftOrderComplete(id: ID!, …)` — the id is a **sibling argument**, not
+ *   inside an input. `paymentPending` is deprecated and is not offered here.
+ * - `fulfillmentCreate(fulfillment: FulfillmentInput!)` — takes
+ *   `lineItemsByFulfillmentOrder`, NOT an order id. There is no mutation that
+ *   fulfils "an order": fulfilment hangs off FulfillmentOrder, so the
+ *   executor has to look them up first. That indirection is the whole reason
+ *   ADR-0007 left this out of v1.
+ * - `orderCancel(orderId:, reason:, restock:, …)` — `reason` and `restock` are
+ *   **required arguments**, and the payload's errors arrive in
+ *   `orderCancelUserErrors`; plain `userErrors` is deprecated there.
+ * - `metafieldsSet(metafields: [MetafieldsSetInput!]!)` — takes a LIST, and
+ *   each entry needs all of `ownerId`, `namespace`, `key`, `type`, `value`.
+ *   `type` is not guessable from the value: `single_line_text_field` and
+ *   `number_integer` are different metafields.
+ * - `productCreate(product: ProductCreateInput!)` — the argument is `product`,
+ *   not `input`; `input: ProductInput` is the deprecated spelling. It creates
+ *   ONE default variant; more variants are `productVariantsBulkCreate`, which
+ *   is a surface of its own and is not offered here.
  */
-export declare const SHOPIFY_OPERATIONS: readonly ["upsertCustomer", "setTags", "adjustInventory", "findRecords"];
+export declare const SHOPIFY_OPERATIONS: readonly ["upsertCustomer", "setTags", "adjustInventory", "findRecords", "createDraftOrder", "completeDraftOrder", "fulfillOrder", "cancelOrder", "setMetafield", "createProduct"];
 export type ShopifyOperation = (typeof SHOPIFY_OPERATIONS)[number];
 /** Type guard — for DTOs and AI tool calls, where the input is untrusted. */
 export declare function isShopifyOperation(value: unknown): value is ShopifyOperation;
@@ -72,6 +105,22 @@ export type ShopifyTaggableResource = (typeof SHOPIFY_TAGGABLE_RESOURCES)[number
 /** What `findRecords` can read back. */
 export declare const SHOPIFY_SEARCHABLE_RESOURCES: readonly ["orders", "customers", "products"];
 export type ShopifySearchableResource = (typeof SHOPIFY_SEARCHABLE_RESOURCES)[number];
+/**
+ * `OrderCancelReason`, the whole enum, in Shopify's own spelling.
+ *
+ * A dropdown and not free text — and that is the opposite of the call made for
+ * `adjustInventory`'s `reason`, on purpose. The difference is not taste: the
+ * inventory vocabulary was NOT verifiable from the reference (see the note
+ * above), so a dropdown there would have been a list of invented values. This
+ * one IS the enumeration, read off `enums/OrderCancelReason`, and an argument
+ * of type `OrderCancelReason!` rejects anything outside it — so free text here
+ * would only mean the user finds out by failing.
+ */
+export declare const SHOPIFY_CANCEL_REASONS: readonly ["CUSTOMER", "DECLINED", "FRAUD", "INVENTORY", "OTHER", "STAFF"];
+export type ShopifyCancelReason = (typeof SHOPIFY_CANCEL_REASONS)[number];
+/** `ProductStatus`, the whole enum. Same reasoning as the cancel reasons. */
+export declare const SHOPIFY_PRODUCT_STATUSES: readonly ["ACTIVE", "DRAFT", "ARCHIVED"];
+export type ShopifyProductStatus = (typeof SHOPIFY_PRODUCT_STATUSES)[number];
 export interface ShopifyParamSpec {
     /** Field key — also the property name on operationConfig. */
     name: string;
@@ -80,7 +129,7 @@ export interface ShopifyParamSpec {
      *  picker backed by a live lookup of the store's locations; `gid` is a
      *  Shopify global id, which is almost always templated from the payload
      *  rather than typed. */
-    type: 'gid' | 'location' | 'email' | 'string' | 'number' | 'tags' | 'taggableResource' | 'searchableResource' | 'json' | 'boolean';
+    type: 'gid' | 'location' | 'email' | 'string' | 'number' | 'tags' | 'taggableResource' | 'searchableResource' | 'cancelReason' | 'productStatus' | 'json' | 'boolean';
     required?: boolean;
     description: string;
     placeholder?: string;
@@ -93,3 +142,55 @@ export interface ShopifyOperationSpec {
     params: ShopifyParamSpec[];
 }
 export declare const SHOPIFY_OPERATION_SPECS: Record<ShopifyOperation, ShopifyOperationSpec>;
+/**
+ * The OAuth scope each operation needs, so a missing one is named BEFORE the
+ * call instead of arriving as an HTTP 403 on a request that looks fine.
+ *
+ * ## The list is "any one of", not "all of"
+ *
+ * That is `fulfillOrder`'s doing and it is not a generalisation for its own
+ * sake: which fulfilment-order scope applies depends on where the order is
+ * fulfilled from — the merchant's own locations, a third-party service, or the
+ * app itself acting as one. Shopify accepts the mutation if the token carries
+ * ANY of the three. Requiring all three would refuse a store that is correctly
+ * set up.
+ *
+ * ## An empty list means "not checkable from the operation alone"
+ *
+ * `setTags` tags an order, a customer or a product through the same mutation,
+ * and `setMetafield` writes onto whichever resource the owner id points at —
+ * so the scope depends on a FIELD, not on the operation. Guessing would be
+ * worse than not checking: a wrong guess blocks a call Shopify would have
+ * accepted, and a pre-flight check that produces false refusals gets deleted.
+ * Those fall through to Shopify's own 403, which `describeShopifyError`
+ * already explains.
+ *
+ * ⚠️ Read against `shopify.dev/docs/api/usage/access-scopes` and each
+ * mutation's own "Access requirements". Two things follow from that page and
+ * are relied on by `scopesQueFaltanEnShopify`:
+ *
+ *   - **A write scope includes read.** `write_orders` grants `read_orders`, so
+ *     a required `read_x` is satisfied by a granted `write_x`.
+ *   - **Scopes are granted at install.** Adding one to the app does not give
+ *     it to credentials that already exist; those have to be reconnected.
+ */
+export declare const SHOPIFY_OPERATION_SCOPES: Record<ShopifyOperation, readonly string[]>;
+/**
+ * Which of an operation's scopes the credential does NOT have.
+ *
+ * Empty means "nothing to say" — and it says that in three different
+ * situations, all of which have to fail OPEN:
+ *
+ *   1. The operation declares no scope (the resource-dependent ones).
+ *   2. The credential has a scope string and it covers one of the alternatives.
+ *   3. **The credential has no scope string at all.** Shopify returns the
+ *      granted scopes on the token exchange, but a credential stored before
+ *      that was read, or one whose metadata was pruned, has an empty string —
+ *      and refusing to run a node because we cannot see its permissions would
+ *      break working flows to prevent a maybe. Shopify is the authority here;
+ *      this check only saves the round trip when it can prove the answer.
+ *
+ * @param concedidos what Shopify granted, as it sends it: a comma-separated
+ *   string, or the already-split list.
+ */
+export declare function scopesQueFaltanEnShopify(concedidos: string | readonly string[] | null | undefined, requeridos: readonly string[]): string[];