@hostwebhook/node-types 1.52.18 → 1.53.0

package/dist/connections.js

@@ -22,7 +22,7 @@ const PROCESSING_OUTPUTS = [
 ];
 /** Standard processing input sources */
 const STANDARD_INPUTS = [
-    'webhook', 'scheduledWorkflow', 'serviceTrigger', 'voiceAgent', 'router', 'filter', 'transform',
+    'webhook', 'scheduledWorkflow', 'trigger', 'voiceAgent', 'router', 'filter', 'transform',
     'cache', 'code', 'rateLimiter', 'aggregator', 'conditional', 'delay', 'schemaValidator', 'split', 'loop', 'markdown', 'fileTransform', 'limit',
 ];
 /** Action nodes that can chain (non-terminal) */
@@ -34,7 +34,7 @@ exports.NODE_CONNECTIONS = {
     webhook: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
     scheduledWorkflow: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
     chatTrigger: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
-    serviceTrigger: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
+    trigger: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
     voiceAgent: { acceptsInputFrom: [], canOutputTo: PROCESSING_OUTPUTS },
     // ── Pipeline processing nodes ──
     filter: { acceptsInputFrom: STANDARD_INPUTS, canOutputTo: PROCESSING_OUTPUTS },

package/dist/dispatch.js

@@ -59,7 +59,7 @@ exports.NODE_DISPATCH = {
     webhook: { service: 'webhooksService', collection: 'webhooks', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
     scheduledWorkflow: { service: 'scheduledWorkflowsService', collection: 'scheduledworkflows', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
     chatTrigger: { service: 'chatTriggersService', collection: 'chattriggers', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
-    serviceTrigger: { service: 'serviceTriggersService', collection: 'servicetriggers', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
+    trigger: { service: 'triggersService', collection: 'triggers', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
     voiceAgent: { service: 'voiceAgentsService', collection: 'voiceagents', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },
     // ── Annotation — never executed in pipeline ──
     stickyNote: { service: 'stickyNotesService', collection: 'stickynotes', hasFilters: false, outputFields: ['outputNodes'], customDispatch: true, pipelineDispatch: 'excluded' },

package/dist/docs-operations.d.ts

@@ -15,17 +15,24 @@
  * ejecutor lee `entity.documentId`, `entity.contentTemplate`… con esos mismos
  * nombres.
  *
- * ── Lo raro de Docs: el desplegable va EN MEDIO ──
- * En esta página el selector de operación **no** está arriba del todo. El orden
- * de pantalla es «qué documento» → «qué hacer» → «con qué»:
+ * ── El orden de pantalla, y por qué cambió ──
+ * Hoy es el mismo que en Sheets, Drive, Telegram, Mongo y Postgres — primero
+ * qué hacer, luego sobre qué:
  *
- *     DocumentPicker + pegar ID     (o el título, si es createDoc)
  *     ── selector de operación ──
+ *     DocumentPicker + pegar ID     (o el título, si es createDoc)
  *     Content / Search+Replace / Rows+Columns
  *
- * Por eso cada param lleva `slot`. Sin él, un bucle único empujaría la identidad
- * del documento por debajo del selector y cambiaría el orden en pantalla, que es
- * justo lo que este refactor no debe tocar.
+ * Estuvo al revés, con el desplegable EN MEDIO y el razonamiento «qué documento
+ * → qué hacer → con qué», y este comentario decía que un refactor no debía
+ * tocarlo. Se cambió a propósito el 2026-08-12 (dashboard#128) por dos motivos:
+ * la operación es la que decide QUÉ CAMPOS aparecen —`createDoc` ni siquiera
+ * pide documento, pide título—, y ser el único nodo con otro orden es una
+ * sorpresa por nodo.
+ *
+ * Los `slot` siguen haciendo falta: separan la identidad del documento de los
+ * campos de la operación, aunque ahora las dos vayan debajo del selector. Un
+ * bucle único ordenaría por el array de params y no por ese criterio.
  */
 export declare const DOCS_OPERATIONS: readonly ["readDoc", "createDoc", "appendText", "replaceText", "insertTable"];
 export type DocsOperation = (typeof DOCS_OPERATIONS)[number];

package/dist/docs-operations.js

@@ -16,17 +16,24 @@
  * ejecutor lee `entity.documentId`, `entity.contentTemplate`… con esos mismos
  * nombres.
  *
- * ── Lo raro de Docs: el desplegable va EN MEDIO ──
- * En esta página el selector de operación **no** está arriba del todo. El orden
- * de pantalla es «qué documento» → «qué hacer» → «con qué»:
+ * ── El orden de pantalla, y por qué cambió ──
+ * Hoy es el mismo que en Sheets, Drive, Telegram, Mongo y Postgres — primero
+ * qué hacer, luego sobre qué:
  *
- *     DocumentPicker + pegar ID     (o el título, si es createDoc)
  *     ── selector de operación ──
+ *     DocumentPicker + pegar ID     (o el título, si es createDoc)
  *     Content / Search+Replace / Rows+Columns
  *
- * Por eso cada param lleva `slot`. Sin él, un bucle único empujaría la identidad
- * del documento por debajo del selector y cambiaría el orden en pantalla, que es
- * justo lo que este refactor no debe tocar.
+ * Estuvo al revés, con el desplegable EN MEDIO y el razonamiento «qué documento
+ * → qué hacer → con qué», y este comentario decía que un refactor no debía
+ * tocarlo. Se cambió a propósito el 2026-08-12 (dashboard#128) por dos motivos:
+ * la operación es la que decide QUÉ CAMPOS aparecen —`createDoc` ni siquiera
+ * pide documento, pide título—, y ser el único nodo con otro orden es una
+ * sorpresa por nodo.
+ *
+ * Los `slot` siguen haciendo falta: separan la identidad del documento de los
+ * campos de la operación, aunque ahora las dos vayan debajo del selector. Un
+ * bucle único ordenaría por el array de params y no por ese criterio.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.DOCS_OPERATION_SPECS = exports.DOCS_OPERATIONS = void 0;

package/dist/gmail-operations.d.ts

@@ -4,7 +4,7 @@
  *   - emailAction entity / DTO (api): operation field + validation
  *   - dashboard EmailActionGmailOperation type
  *   - broker hostwebhook types + tool schemas
- *   - serviceTrigger / future Gmail-related nodes
+ *   - trigger / future Gmail-related nodes
  *
  * Adding a new Gmail operation = add it here, bump this package's
  * version, publish to npm, and re-install in the consuming repos.

package/dist/gmail-operations.js

@@ -9,7 +9,7 @@ exports.resolveGmailSendFields = resolveGmailSendFields;
  *   - emailAction entity / DTO (api): operation field + validation
  *   - dashboard EmailActionGmailOperation type
  *   - broker hostwebhook types + tool schemas
- *   - serviceTrigger / future Gmail-related nodes
+ *   - trigger / future Gmail-related nodes
  *
  * Adding a new Gmail operation = add it here, bump this package's
  * version, publish to npm, and re-install in the consuming repos.

package/dist/registry.d.ts

@@ -36,7 +36,7 @@ export interface NodeRegistryEntry {
      *
      * Lets new toolkit-style nodes opt-in without per-component hardcoding
      * in the dashboard. Currently only emailAction(aiEnabled=true) uses
-     * this; serviceTrigger or future Slack/Discord toolkits could too.
+     * this; trigger or future Slack/Discord toolkits could too.
      *
      * Predicate must be pure (no side effects) — called on every render.
      */

package/dist/registry.js

@@ -29,10 +29,10 @@ exports.NODE_REGISTRY = {
         stateKey: 'chatTriggers', allStateKey: 'allChatTriggers',
         color: '#06b6d4', testable: false,
     },
-    serviceTrigger: {
-        type: 'serviceTrigger', prefix: 'svc', label: 'Service Trigger',
-        group: 'Sources', detailPath: '/dashboard/service-triggers', apiPath: '/service-triggers',
-        stateKey: 'serviceTriggers', allStateKey: 'allServiceTriggers',
+    trigger: {
+        type: 'trigger', prefix: 'trg', label: 'Trigger',
+        group: 'Sources', detailPath: '/dashboard/triggers', apiPath: '/triggers',
+        stateKey: 'triggers', allStateKey: 'allTriggers',
         color: '#ef4444', testable: false,
     },
     voiceAgent: {

package/dist/telegram-operations.js

@@ -26,7 +26,7 @@ exports.TELEGRAM_OPERATIONS = [
     // tap one. When `allowFreeText` is on, a text reply in the same chat
     // also resolves the wait. Backed by the same shared PendingApproval +
     // send-and-wait infra emailAction uses, with a Telegram-specific
-    // resume path through service-triggers.processTelegramPush (intercepts
+    // resume path through triggers.processTelegramPush (intercepts
     // callback_query.data === "swat:{token}:a|r" before normal dispatch).
     // Output of the node carries `payload._waitResponse = { approved,
     // decidedAt, ipAddress, comment?, responseText?, timedOut? }` for

package/dist/telegram-toolkit.js

@@ -29,7 +29,7 @@ const p = (name, description, required = true, type = 'string') => ({ name, type
  * y por la vía de una herramienta no espera — el modelo recibe algo inmediato y
  * acaba diciendo que ya se aprobó. Se usa en modo single-op, con un Conditional
  * detrás leyendo `_waitResponse.approved`. La espera se resuelve por
- * `service-triggers.processTelegramPush`, donde el LLM no participa.
+ * `triggers.processTelegramPush`, donde el LLM no participa.
  *
  * Ninguna lleva `destructive`. `delete_telegram_message` lo merecería —el
  * toolkit de Drive marca sus borrados— pero hoy la spec de Telegram no tiene ese

package/dist/types.d.ts

@@ -1,5 +1,5 @@
 /** All valid node type identifiers */
-export type NodeType = 'webhook' | 'scheduledWorkflow' | 'chatTrigger' | 'serviceTrigger' | 'voiceAgent' | 'filter' | 'transform' | 'schemaValidator' | 'conditional' | 'delay' | 'rateLimiter' | 'aggregator' | 'cache' | 'code' | 'ai' | 'merge' | 'approval' | 'split' | 'loop' | 'markdown' | 'fileTransform' | 'limit' | 'router' | 'emailAction' | 'httpAction' | 'mongoAction' | 'postgresAction' | 'notificationAction' | 'sheetsAction' | 'calendarAction' | 'docsAction' | 'driveAction' | 'firecrawlAction' | 'telegramAction' | 'whatsappAction' | 'discordAction' | 'slackAction' | 'googleContactsAction' | 'vectorStore' | 'rssAction' | 'socialMediaAction' | 'stickyNote';
+export type NodeType = 'webhook' | 'scheduledWorkflow' | 'chatTrigger' | 'trigger' | 'voiceAgent' | 'filter' | 'transform' | 'schemaValidator' | 'conditional' | 'delay' | 'rateLimiter' | 'aggregator' | 'cache' | 'code' | 'ai' | 'merge' | 'approval' | 'split' | 'loop' | 'markdown' | 'fileTransform' | 'limit' | 'router' | 'emailAction' | 'httpAction' | 'mongoAction' | 'postgresAction' | 'notificationAction' | 'sheetsAction' | 'calendarAction' | 'docsAction' | 'driveAction' | 'firecrawlAction' | 'telegramAction' | 'whatsappAction' | 'discordAction' | 'slackAction' | 'googleContactsAction' | 'vectorStore' | 'rssAction' | 'socialMediaAction' | 'stickyNote';
 /** Node role in the pipeline */
 export type NodeRole = 'source' | 'processing' | 'flowControl' | 'routing' | 'action' | 'monitoring';
 /** Handle positions on the canvas node */
@@ -113,7 +113,7 @@ export interface NodeUIConfig {
  *   nodes (email/http/mongo/notification/sheets/calendar/docs/
  *   firecrawl) are fired post-delivery in onDeliveryResult with
  *   their own loops; ingress nodes (webhook/scheduledWorkflow/
- *   chatTrigger/serviceTrigger) start the flow themselves;
+ *   chatTrigger/trigger) start the flow themselves;
  *   stickyNote is purely visual.
  */
 export type PipelineDispatchKind = 'generic' | 'custom' | 'excluded';

package/dist/ui.js

@@ -11,7 +11,7 @@ exports.NODE_UI = {
     webhook: { fromNodes: true, toNodes: true, isSource: true },
     scheduledWorkflow: { fromNodes: false, toNodes: true, isSource: true, outputHandles: ['right', 'bottom'], dotHandles: { output: ['right-out', 'bottom-out'] } },
     chatTrigger: { fromNodes: false, toNodes: true, isSource: true, outputHandles: ['right'], dotHandles: { output: ['right-out'] } },
-    serviceTrigger: { fromNodes: false, toNodes: true, isSource: true, outputHandles: ['right', 'bottom'], dotHandles: { output: ['right-out', 'bottom-out'] } },
+    trigger: { fromNodes: false, toNodes: true, isSource: true, outputHandles: ['right', 'bottom'], dotHandles: { output: ['right-out', 'bottom-out'] } },
     // Voice Agent: dynamicOutputs=true tells NodeShell to derive ONE
     // output handle per non-disabled `entity.tools[i].name`. The
     // `right-out` fallback handle is rendered when the agent has zero
@@ -75,7 +75,7 @@ exports.PREFIX_TO_TYPE = [
     { prefix: 'wh-', type: 'webhook', canvasType: 'webhook' },
     { prefix: 'swf-', type: 'scheduledWorkflow', canvasType: 'scheduledWorkflow' },
     { prefix: 'chat-', type: 'chatTrigger', canvasType: 'chatTrigger' },
-    { prefix: 'svc-', type: 'serviceTrigger', canvasType: 'serviceTrigger' },
+    { prefix: 'trg-', type: 'trigger', canvasType: 'trigger' },
     { prefix: 'va-', type: 'voiceAgent', canvasType: 'voiceAgent' },
     { prefix: 'ea-', type: 'emailAction', canvasType: 'emailAction' },
     { prefix: 'tg-', type: 'telegramAction', canvasType: 'telegramAction' },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hostwebhook/node-types",
-  "version": "1.52.18",
+  "version": "1.53.0",
   "description": "Shared node type definitions, connection rules, and dispatch config for HostWebhook",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",