@hostwebhook/node-types 1.76.0 → 1.78.0

package/dist/dispatch.js

@@ -39,31 +39,36 @@ exports.NODE_DISPATCH = {
     // ── Routing — custom dispatch ──
     router: { service: 'routersService', collection: 'routers', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'custom', downstreamPayload: 'result' },
     // ── Action nodes — fired in onDeliveryResult, excluded from webhook dispatch ──
-    emailAction: { service: 'emailActionsService', collection: 'emailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    gmailAction: { service: 'gmailActionsService', collection: 'gmailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    emailAction: { service: 'emailActionsService', collection: 'emailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    gmailAction: { service: 'gmailActionsService', collection: 'gmailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     httpAction: { service: 'httpActionsService', collection: 'httpactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     mongoAction: { service: 'mongoActionsService', collection: 'mongoactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     postgresAction: { service: 'postgresActionsService', collection: 'postgresactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    notificationAction: { service: 'notificationActionsService', collection: 'notificationactions', hasFilters: true, outputFields: [], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    notificationAction: { service: 'notificationActionsService', collection: 'notificationactions', hasFilters: true, outputFields: [], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     sheetsAction: { service: 'sheetsActionsService', collection: 'sheetsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     calendarAction: { service: 'calendarActionsService', collection: 'calendaractions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     docsAction: { service: 'docsActionsService', collection: 'docsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     driveAction: { service: 'driveActionsService', collection: 'driveactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     firecrawlAction: { service: 'firecrawlActionsService', collection: 'firecrawlactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    telegramAction: { service: 'telegramActionsService', collection: 'telegramactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    whatsappAction: { service: 'whatsappActionsService', collection: 'whatsappactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    discordAction: { service: 'discordActionsService', collection: 'discordactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    telegramAction: { service: 'telegramActionsService', collection: 'telegramactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    whatsappAction: { service: 'whatsappActionsService', collection: 'whatsappactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    /* `'result'` y no `'original'` por decisión del dueño: lo que tiene que bajar
+       de un Discord es SU acuse —`messageId`, `channelId`, `content`— y no el
+       evento que le entró. Ver `discord-actions.service.ts`, donde está el coste
+       escrito: un flujo que leyera `{{payload.<campo del evento>}}` después de un
+       Discord ahora lee el acuse. */
+    discordAction: { service: 'discordActionsService', collection: 'discordactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     mailchimpAction: { service: 'mailchimpActionsService', collection: 'mailchimpactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     shopifyAction: { service: 'shopifyActionsService', collection: 'shopifyactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     githubAction: { service: 'githubActionsService', collection: 'githubactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     jiraAction: { service: 'jiraActionsService', collection: 'jiraactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     bucketAction: { service: 'bucketActionsService', collection: 'bucketactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    slackAction: { service: 'slackActionsService', collection: 'slackactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    slackAction: { service: 'slackActionsService', collection: 'slackactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     googleContactsAction: { service: 'googleContactsActionsService', collection: 'googlecontactsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     googleAnalyticsAction: { service: 'googleAnalyticsActionsService', collection: 'googleanalyticsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     notionAction: { service: 'notionActionsService', collection: 'notionactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     rssAction: { service: 'rssActionsService', collection: 'rssactions', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    socialMediaAction: { service: 'socialMediaActionsService', collection: 'socialmediaactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    socialMediaAction: { service: 'socialMediaActionsService', collection: 'socialmediaactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     // ── Sources — start the flow themselves, not dispatched ──
     webhook: { service: 'webhooksService', collection: 'webhooks', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     scheduledWorkflow: { service: 'scheduledWorkflowsService', collection: 'scheduledworkflows', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },

package/dist/esm/dispatch.js

@@ -33,31 +33,36 @@ export const NODE_DISPATCH = {
     // ── Routing — custom dispatch ──
     router: { service: 'routersService', collection: 'routers', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'custom', downstreamPayload: 'result' },
     // ── Action nodes — fired in onDeliveryResult, excluded from webhook dispatch ──
-    emailAction: { service: 'emailActionsService', collection: 'emailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    gmailAction: { service: 'gmailActionsService', collection: 'gmailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    emailAction: { service: 'emailActionsService', collection: 'emailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    gmailAction: { service: 'gmailActionsService', collection: 'gmailactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     httpAction: { service: 'httpActionsService', collection: 'httpactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     mongoAction: { service: 'mongoActionsService', collection: 'mongoactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     postgresAction: { service: 'postgresActionsService', collection: 'postgresactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    notificationAction: { service: 'notificationActionsService', collection: 'notificationactions', hasFilters: true, outputFields: [], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    notificationAction: { service: 'notificationActionsService', collection: 'notificationactions', hasFilters: true, outputFields: [], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     sheetsAction: { service: 'sheetsActionsService', collection: 'sheetsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     calendarAction: { service: 'calendarActionsService', collection: 'calendaractions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     docsAction: { service: 'docsActionsService', collection: 'docsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     driveAction: { service: 'driveActionsService', collection: 'driveactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     firecrawlAction: { service: 'firecrawlActionsService', collection: 'firecrawlactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    telegramAction: { service: 'telegramActionsService', collection: 'telegramactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    whatsappAction: { service: 'whatsappActionsService', collection: 'whatsappactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
-    discordAction: { service: 'discordActionsService', collection: 'discordactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    telegramAction: { service: 'telegramActionsService', collection: 'telegramactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    whatsappAction: { service: 'whatsappActionsService', collection: 'whatsappactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
+    /* `'result'` y no `'original'` por decisión del dueño: lo que tiene que bajar
+       de un Discord es SU acuse —`messageId`, `channelId`, `content`— y no el
+       evento que le entró. Ver `discord-actions.service.ts`, donde está el coste
+       escrito: un flujo que leyera `{{payload.<campo del evento>}}` después de un
+       Discord ahora lee el acuse. */
+    discordAction: { service: 'discordActionsService', collection: 'discordactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     mailchimpAction: { service: 'mailchimpActionsService', collection: 'mailchimpactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     shopifyAction: { service: 'shopifyActionsService', collection: 'shopifyactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     githubAction: { service: 'githubActionsService', collection: 'githubactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     jiraAction: { service: 'jiraActionsService', collection: 'jiraactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     bucketAction: { service: 'bucketActionsService', collection: 'bucketactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    slackAction: { service: 'slackActionsService', collection: 'slackactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    slackAction: { service: 'slackActionsService', collection: 'slackactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     googleContactsAction: { service: 'googleContactsActionsService', collection: 'googlecontactsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     googleAnalyticsAction: { service: 'googleAnalyticsActionsService', collection: 'googleanalyticsactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     notionAction: { service: 'notionActionsService', collection: 'notionactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     rssAction: { service: 'rssActionsService', collection: 'rssactions', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
-    socialMediaAction: { service: 'socialMediaActionsService', collection: 'socialmediaactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'original' },
+    socialMediaAction: { service: 'socialMediaActionsService', collection: 'socialmediaactions', hasFilters: true, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     // ── Sources — start the flow themselves, not dispatched ──
     webhook: { service: 'webhooksService', collection: 'webhooks', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },
     scheduledWorkflow: { service: 'scheduledWorkflowsService', collection: 'scheduledworkflows', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded', downstreamPayload: 'result' },

package/dist/esm/index.d.ts

@@ -66,3 +66,5 @@ export type { ModeloDeOpenRouter, PrecioDeOpenRouter, RespuestaDeModelosDeOpenRo
 export { URL_DE_MODELOS_DE_OPENROUTER, opcionesDeModelosDeOpenRouter, ventanaDeContextoDeOpenRouter, } from './openrouter.js';
 export type { CredentialTypeRegistration, CredentialType } from './credentials.js';
 export { CREDENTIAL_TYPES, CREDENTIAL_TYPE_VALUES, credentialTypeValues, getCredentialType, isCredentialType, } from './credentials.js';
+export type { NodoQueContestaEnSync, ResultadoDelValidador, FalloDeValidacion, VeredictoDelValidador, NivelDeDetalle, ModoDePayload, SobreDeRespuesta, TopeDeNumero, RespuestaDelSync, RespuestaHttp, } from './respuesta-del-sync.js';
+export { NODOS_QUE_CONTESTAN_EN_SYNC, contestaEnSync, RESULTADOS_DEL_VALIDADOR, NIVELES_DE_DETALLE, MODOS_DE_PAYLOAD, SOBRES_DE_RESPUESTA, TOPES_DE_ESTADO, TOPE_DE_ESPERA_DEL_SYNC, RESPUESTA_DEL_SYNC_POR_DEFECTO, armarRespuestaDelSync, } from './respuesta-del-sync.js';

package/dist/esm/index.js

@@ -51,3 +51,4 @@ export { DOCS_TOOLKIT_SPECS, DOCS_TOOLKIT_BY_TOOL_NAME, DOCS_TOOLKIT_DEFAULTABLE
 export { LLM_PROVIDERS, LLM_MODELS, MODEL_CONTEXT_WINDOWS, getModelsFor, getDefaultModel, getModelLabel, } from './llm-models.js';
 export { URL_DE_MODELOS_DE_OPENROUTER, opcionesDeModelosDeOpenRouter, ventanaDeContextoDeOpenRouter, } from './openrouter.js';
 export { CREDENTIAL_TYPES, CREDENTIAL_TYPE_VALUES, credentialTypeValues, getCredentialType, isCredentialType, } from './credentials.js';
+export { NODOS_QUE_CONTESTAN_EN_SYNC, contestaEnSync, RESULTADOS_DEL_VALIDADOR, NIVELES_DE_DETALLE, MODOS_DE_PAYLOAD, SOBRES_DE_RESPUESTA, TOPES_DE_ESTADO, TOPE_DE_ESPERA_DEL_SYNC, RESPUESTA_DEL_SYNC_POR_DEFECTO, armarRespuestaDelSync, } from './respuesta-del-sync.js';

package/dist/esm/respuesta-del-sync.d.ts

@@ -0,0 +1,353 @@
+/**
+ * La respuesta que recibe quien llama a un webhook en modo `sync`, armada en
+ * UN solo sitio.
+ *
+ * ## Qué problema resuelve
+ *
+ * El dueño quiere unas pestañas para configurar qué recibe el cliente y una
+ * VISTA PREVIA que enseñe los bytes exactos. Una vista previa sólo vale si no
+ * puede desincronizarse del servidor: si son dos implementaciones, el día que
+ * difieran la pantalla miente con toda la confianza del mundo, y miente sobre
+ * lo único que el usuario no puede comprobar desde ahí.
+ *
+ * Ya hay un caso así en el dashboard —`FORMAT_OPTIONS`, cuatro formatos
+ * copiados a mano en `schema-validators/[id]/page.tsx` cuando el paquete
+ * publica dieciocho— y ahí se asume porque desincronizarse AVISA: el campo
+ * deja de ofrecer un formato que sí existe y alguien lo pide. Aquí no avisaría
+ * nada. La previa diría 422 con tres errores, el servidor mandaría otra cosa,
+ * y nadie se enteraría hasta que un cliente se quejara.
+ *
+ * Así que la función de abajo es la ÚNICA que sabe montar estos bytes. La
+ * llaman los tres: el handler del validador en hw-nodes, el endpoint de previa
+ * de la api, y el dashboard para pintarla.
+ *
+ * ## Por qué este paquete y no otro — medido el 2026-09-10
+ *
+ * Los tres candidatos, con los números delante:
+ *
+ * | | `platform-contracts` | `node-sdk` | **`node-types`** |
+ * |---|---|---|---|
+ * | lo pinea el dashboard | `^0.2.0` (0.2.0 instalada) | no es dependencia suya | `^1.74.0` (1.74.0 instalada) |
+ * | ¿el caret llega a lo nuevo? | **NO** — en `0.x` no cruza el minor: habría que subir a `^0.16` a mano | — | **SÍ** — en `1.x` sí lo cruza; basta refrescar el lock |
+ * | dependencias de ejecución | `dependencies: {}` **pero** su barril hace `require('@nestjs/common')` de verdad | mongoose, mongodb, express, re2 (binario nativo) | **ninguna: ni deps ni peers** |
+ * | ¿sirve en el navegador? | **NO** hoy | no | **sí** |
+ * | ficheros del dashboard que ya lo importan | 6 | 0 | **92** |
+ *
+ * ⚠️ Lo de `platform-contracts` conviene leerlo dos veces, porque la primera
+ * medición decía lo contrario. `dependencies: {}` es cierto, y por eso parecía
+ * servible en el navegador. Pero un PEER también se ejecuta: desde 0.3.0 el
+ * paquete trae `servicios/credenciales-del-gateway`, que importa
+ * `BadRequestException` como VALOR, y eso sale en el `dist` como un
+ * `require("@nestjs/common")` al que se llega desde `dist/index.js` —barril de
+ * CommonJS, sin mapa `exports` y sin `sideEffects`, o sea que no se sacude—.
+ * El dashboard entra por ese barril (`lib/store/hooks.ts` pide `tieneAddon`
+ * como valor, no como tipo), así que subirlo metería ~9,5 MB de framework de
+ * servidor —@nestjs/common 1,1 MB, rxjs 8,1 MB, reflect-metadata 265 kB— en un
+ * Next. Lo que NO es el problema, y también se midió: entre 0.2.0 y 0.15.0
+ * `addons.ts` y `operadores.ts` están byte a byte idénticos, así que de los 13
+ * minors de salto NO sale ni un breaking para lo que el dashboard usa hoy.
+ *
+ * Y aquí, además, cae en el sitio correcto por significado: la constante del
+ * gate es una lista de `NodeType`, y `NodeType` vive en este fichero de al
+ * lado. En cualquier otro paquete sería una lista de cadenas sueltas que nadie
+ * comprueba contra el catálogo de nodos.
+ */
+/**
+ * Los tipos de nodo que SABEN contestar en `sync`.
+ *
+ * Lo lee la api al guardar —para no dejar activar `responseMode: 'sync'` en un
+ * flujo que no lleva ninguno— y el dashboard para avisar antes de guardar.
+ *
+ * 🔥 Es una CONSTANTE y no el literal `'schemaValidator'` repartido por los dos
+ * sitios, y la razón no es estética: el día que un segundo nodo implemente
+ * `getSyncResult`, con literales el gate sigue compilando, sigue pasando los
+ * tests y **se queda mintiendo en silencio** —le dice al usuario que su flujo
+ * no puede contestar cuando sí puede—. Un fallo que no rompe nada es el que
+ * sobrevive años.
+ *
+ * ⚠️ Y lo que esta lista NO puede comprobar desde aquí: que sea la misma que
+ * la de los handlers que de verdad implementan `getSyncResult`. Esos viven en
+ * hw-nodes, que este paquete no ve ni debe ver. El guardián de esa atadura va
+ * ALLÍ, que es donde están los handlers — el mismo reparto que ya usa
+ * `pasaLoQueRecibe`: la tabla se fija aquí y
+ * `el-panel-lee-lo-mismo-que-el-handler.spec.ts` la ata en hw-nodes.
+ *
+ * ⚠️⚠️ Presencia no es paso. Que el flujo LLEVE un validador no garantiza que
+ * el evento pase por él: un conditional o un filter puede rutear alrededor. Por
+ * eso el gate es de producto y no de corrección, y por eso `'no-verdict'`
+ * existe ahí abajo — sin él, el flujo con el gate puesto se colgaría igual.
+ */
+export declare const NODOS_QUE_CONTESTAN_EN_SYNC: readonly ["schemaValidator"];
+/** Un tipo de nodo de los que saben contestar en `sync`. */
+export type NodoQueContestaEnSync = (typeof NODOS_QUE_CONTESTAN_EN_SYNC)[number];
+/**
+ * ¿Este tipo de nodo sabe contestar en `sync`?
+ *
+ * Acepta `string` y no `NodeType` a propósito: quien pregunta es la api con lo
+ * que trae un documento de mongo y el dashboard con lo que hay en el lienzo, y
+ * los dos manejan cadenas que todavía no han pasado por ningún tipo.
+ */
+export declare function contestaEnSync(tipo: string): boolean;
+/**
+ * Los cuatro finales posibles de una espera en `sync`. Son cuatro y no dos, y
+ * los dos de en medio son los que hoy faltan:
+ *
+ * - `valid` — el payload pasó. **Esto es lo que hoy no contesta nadie**: el
+ *   `getSyncResult` del validador devuelve `null` cuando todo está bien y el
+ *   paso 8.5 de `node-lifecycle.ts` sólo resuelve `if (syncResult)`. O sea que
+ *   el camino FELIZ es el que se cuelga 120 s y sale con un 408. Pasar la
+ *   validación era indistinguible de que no contestara nadie.
+ * - `invalid` — el payload no pasó. El único que funciona hoy.
+ * - `no-verdict` — la corrida TERMINÓ y ningún validador se pronunció (nadie
+ *   pasó por él, o el flujo no lleva ninguno). Hay que contestar igual, ahí
+ *   mismo, en vez de esperar el tope entero.
+ * - `timeout` — se acabó la espera de verdad.
+ */
+export declare const RESULTADOS_DEL_VALIDADOR: readonly ["valid", "invalid", "no-verdict", "timeout"];
+export type ResultadoDelValidador = (typeof RESULTADOS_DEL_VALIDADOR)[number];
+/**
+ * Un campo que no pasó.
+ *
+ * `path` y `message` son lo que `validateSchema` produce hoy
+ * (`@hostwebhook/node-sdk`, `schema-validator-utils.ts`). `rule` y `expected`
+ * son OPCIONALES porque hoy ese validador todavía no los emite: cuando no
+ * vienen, el nivel `full` sale exactamente igual que el cuerpo que ya se envía,
+ * o sea que nada empeora mientras tanto, y el día que los emita esta función no
+ * cambia una línea.
+ */
+export interface FalloDeValidacion {
+    /**
+     * La ruta del campo dentro del payload: `user.email`, `items[0].sku`.
+     *
+     * ⚠️ Se llama `path` y no `field` a propósito, aunque el hueco de la
+     * plantilla se llame `{{field}}`. `path` es lo que YA sale por el cable en el
+     * 422 de hoy, y renombrarlo rompería a todo el que lo esté parseando ahí
+     * fuera. El hueco se llama como lo pidió el dueño, que es quien lo escribe en
+     * una caja de texto; la clave del JSON se llama como siempre se llamó.
+     */
+    path: string;
+    /** El texto que produjo el validador: `must be a valid email`. */
+    message: string;
+    /** Qué regla falló: `format`, `minLength`, `required`, `type`… */
+    rule?: string;
+    /** Qué esperaba esa regla: `email`, `3`, `string`… */
+    expected?: string;
+}
+/**
+ * Lo que dictaminó el validador. Es la ENTRADA de la función pura, y va como
+ * unión porque los cuatro finales no llevan los mismos datos: un `valid` no
+ * tiene errores y un `timeout` tampoco tiene payload que devolver.
+ */
+export type VeredictoDelValidador = {
+    outcome: 'valid';
+    eventId?: string;
+    webhookName?: string;
+    nodeName?: string;
+} | {
+    outcome: 'invalid';
+    errors: FalloDeValidacion[];
+    /** Lo que ENTRÓ. Hace falta para `includePayload`. */
+    payload?: unknown;
+    eventId?: string;
+    webhookName?: string;
+    nodeName?: string;
+} | {
+    outcome: 'no-verdict';
+    eventId?: string;
+    webhookName?: string;
+    nodeName?: string;
+} | {
+    outcome: 'timeout';
+    eventId?: string;
+    webhookName?: string;
+    nodeName?: string;
+};
+/**
+ * Cuánto se le cuenta al cliente de POR QUÉ falló.
+ *
+ * Los valores van en inglés aunque el tipo se llame en español, por lo mismo
+ * que `FORMATOS_DEL_ESQUEMA`: acaban en un `enum` de mongoose, en un `@IsIn`
+ * de un DTO y en un `<select>`, y ninguno de esos tres sitios quiere una
+ * cadena en español dentro de un JSON que un cliente puede exportar.
+ *
+ * - `full` — ruta, regla y esperado. Lo que quiere quien integra con su propio
+ *   equipo detrás.
+ * - `fields-only` — QUÉ campos fallaron, sin el porqué. El término medio para
+ *   un formulario público: basta para señalar la casilla en rojo y no publica
+ *   las reglas.
+ * - `opaque` — «Invalid payload» y ya. **Ni una ruta de campo sale de aquí.**
+ *   Un esquema es un mapa de tu modelo de datos; repartirlo por un endpoint
+ *   público es regalar el trabajo de enumeración a quien lo quiera.
+ */
+export declare const NIVELES_DE_DETALLE: readonly ["full", "fields-only", "opaque"];
+export type NivelDeDetalle = (typeof NIVELES_DE_DETALLE)[number];
+/**
+ * Si se le devuelve al cliente lo que mandó, y cuánto.
+ *
+ * - `none` — no.
+ * - `full` — tal cual llegó. No revela nada: es SU payload.
+ * - `failed-fields` — sólo los campos que fallaron, **en plano**, con la ruta
+ *   completa como clave: `{ "user.email": "nope", "items[0].sku": 12 }`.
+ *   Plano y no reconstruido con su anidamiento por dos razones: reconstruirlo
+ *   añade una segunda lectura de rutas que puede discrepar de la del
+ *   validador, y porque quien está depurando quiere la lista de lo que falló
+ *   junto a lo que mandó, no un recorte del original con la misma forma.
+ */
+export declare const MODOS_DE_PAYLOAD: readonly ["none", "full", "failed-fields"];
+export type ModoDePayload = (typeof MODOS_DE_PAYLOAD)[number];
+/**
+ * La forma del sobre.
+ *
+ * - `hostwebhook` — el nuestro, el que ya sale hoy por el cable.
+ * - `problem+json` — RFC 7807, con su `content-type: application/problem+json`.
+ *   Lo piden los que meten esto detrás de un cliente generado.
+ */
+export declare const SOBRES_DE_RESPUESTA: readonly ["hostwebhook", "problem+json"];
+export type SobreDeRespuesta = (typeof SOBRES_DE_RESPUESTA)[number];
+/** Un tope: el mínimo, el máximo y con qué se rellena si se sale. */
+export interface TopeDeNumero {
+    min: number;
+    max: number;
+    defecto: number;
+}
+/**
+ * Los topes de los códigos de estado, exportados para que el dashboard ponga
+ * el `min`/`max` de cada caja desde AQUÍ y no a ojo.
+ *
+ * El del éxito acaba en 299 por lo que pidió el dueño: nada de un 500 en el
+ * éxito. Y no es una manía — un 5xx en la respuesta de «tu payload es válido»
+ * hace que el cliente reintente, y reintentar un webhook aceptado duplica el
+ * evento.
+ *
+ * El del error se queda en 4xx: la culpa del payload es de quien lo manda, y un
+ * 5xx ahí también invita al reintento de lo que nunca va a pasar.
+ *
+ * El del timeout llega hasta 599 porque ahí sí caben los dos: 408 (lo que sale
+ * hoy) y 504, que es lo que muchos proxies esperan.
+ */
+export declare const TOPES_DE_ESTADO: {
+    readonly success: {
+        readonly min: 200;
+        readonly max: 299;
+        readonly defecto: 200;
+    };
+    readonly error: {
+        readonly min: 400;
+        readonly max: 499;
+        readonly defecto: 422;
+    };
+    readonly timeout: {
+        readonly min: 400;
+        readonly max: 599;
+        readonly defecto: 408;
+    };
+};
+/**
+ * Cuánto se puede tener la conexión viva.
+ *
+ * ⚠️ El `max` es `SYNC_TIMEOUT_SECONDS` de `@hostwebhook/node-sdk`
+ * (`topes/plan.constants.ts`), que es el `setTimeout` real del `waitForSync`
+ * del gateway. Está copiado y no importado porque este paquete **no tiene ni
+ * una dependencia** —es justo lo que lo hace servible en el navegador— y
+ * traerse node-sdk arrastraría mongoose, express y un binario nativo.
+ *
+ * Que la copia no se despiste lo ata un test EN node-sdk, que sí puede ver los
+ * dos: `el-tope-de-la-espera-es-uno.test.ts`. Sin esa atadura, configurar 200 s
+ * aquí daría una pantalla que promete 200 y un gateway que corta a los 120.
+ */
+export declare const TOPE_DE_ESPERA_DEL_SYNC: {
+    readonly min: 1;
+    readonly max: 120;
+    readonly defecto: 120;
+};
+/**
+ * Cómo se quiere la respuesta del `sync`. Todo opcional: lo que no venga sale
+ * de `RESPUESTA_DEL_SYNC_POR_DEFECTO`, y así un webhook que nunca tocó estas
+ * pestañas se comporta exactamente como hoy.
+ */
+export interface RespuestaDelSync {
+    /** Estado del ÉXITO. 200–299; fuera de rango vuelve a 200. */
+    successStatus?: number;
+    /** Estado del ERROR de validación. 400–499; fuera de rango vuelve a 422. */
+    errorStatus?: number;
+    /** Cuánto se cuenta del porqué. */
+    detail?: NivelDeDetalle;
+    /**
+     * Plantilla del mensaje de cada fallo, con huecos `{{field}}`, `{{rule}}` y
+     * `{{expected}}`. Sin ella se usa el texto del validador tal cual.
+     */
+    messageTemplate?: string;
+    /**
+     * Plantilla propia para un campo concreto, por su ruta exacta. Gana sobre
+     * `messageTemplate`.
+     */
+    fieldTemplates?: Record<string, string>;
+    /** Si se le devuelve al cliente lo que mandó. */
+    includePayload?: ModoDePayload;
+    /** La forma del sobre. */
+    envelope?: SobreDeRespuesta;
+    /**
+     * El `type` de RFC 7807: un URI que describe el problema. Sólo se usa con el
+     * sobre `problem+json`.
+     *
+     * Por defecto `about:blank`, que es lo que manda el propio RFC cuando no hay
+     * un URI específico. Inventarse una URL de hostwebhook.com que da 404 es peor
+     * que no dar ninguna: el 7807 existe para que ese enlace se pueda seguir.
+     */
+    problemType?: string;
+    /** Segundos de conexión viva. 1–120; fuera de rango vuelve a 120. */
+    timeoutSeconds?: number;
+    /** Estado del timeout. 400–599; fuera de rango vuelve a 408. */
+    timeoutStatus?: number;
+    /** Cuerpo del timeout. Sin él, el de hoy: `{ error: 'Pipeline timeout' }`. */
+    timeoutBody?: Record<string, unknown>;
+}
+/**
+ * Lo que se usa cuando no se configuró nada.
+ *
+ * Están elegidos para que un webhook que no toque nada se comporte IGUAL que
+ * antes de todo esto: 422 al fallar, 120 s de espera, 408 al agotarse, el sobre
+ * de siempre y sin devolver el payload. Lo único que cambia respecto a hoy es
+ * que el camino feliz ahora contesta en vez de colgarse, que era el bug.
+ *
+ * `detail: 'full'` por lo mismo: es lo que sale hoy por el cable.
+ */
+export declare const RESPUESTA_DEL_SYNC_POR_DEFECTO: {
+    readonly successStatus: 200;
+    readonly errorStatus: 422;
+    readonly detail: "full";
+    readonly includePayload: "none";
+    readonly envelope: "hostwebhook";
+    readonly problemType: "about:blank";
+    readonly timeoutSeconds: 120;
+    readonly timeoutStatus: 408;
+};
+/**
+ * La respuesta HTTP, entera.
+ *
+ * Lleva `headers` y no sólo `{status, body}` porque el sobre RFC 7807 SON las
+ * cabeceras tanto como el cuerpo: mandar ese JSON con `application/json` no es
+ * un 7807, es un JSON que se le parece, y el cliente generado que lo espera no
+ * lo reconoce. `{status, body}` sigue siendo un subconjunto de esto, así que
+ * el `getSyncResult` de hoy encaja sin tocar nada.
+ */
+export interface RespuestaHttp {
+    status: number;
+    headers: Record<string, string>;
+    /**
+     * ⚠️ El orden de inserción de las claves ES el orden en el que salen por el
+     * cable: `JSON.stringify` respeta el orden de inserción de las claves de
+     * texto. La vista previa enseña esto mismo, así que el orden de abajo está
+     * escrito a mano y no por casualidad.
+     */
+    body: Record<string, unknown>;
+}
+/**
+ * Arma la respuesta que recibe quien llamó en `sync`.
+ *
+ * PURA: sin nestjs, sin mongoose, sin `Date.now()`, sin nada de servidor. Entra
+ * un veredicto y una configuración, sale la respuesta. Por eso puede correr
+ * igual en el handler de hw-nodes y en el navegador del dashboard, y por eso la
+ * vista previa no puede desincronizarse: es literalmente la misma llamada.
+ */
+export declare function armarRespuestaDelSync(veredicto: VeredictoDelValidador, config?: RespuestaDelSync): RespuestaHttp;