Trigger payload mapping UI and config validation

[serge-ivo]

Summary

Add first-class payload mapping for webhook/manual triggers so users can map incoming fields to task or knowledge fields without editing raw JSON or relying on fixed defaults.

Why

Current actions (create_task, add_knowledge, log_event) use simple conventions like title, description, content, and text. That is enough for MVP webhooks, but real sources vary (lead.name, body.message, document.text, etc.). Users need predictable mapping and validation.

Scope

• Add config schema for trigger action mappings.
• Support mappings for:
  • create_task: title, description
  • add_knowledge: title, content, sourceUrl
  • log_event: message or payload summary
• Add console UI controls in instance Settings -> Triggers.
• Add API validation/sanitization for mapping config.
• Preserve current default behavior when no mapping is configured.
• Include a small payload preview/test flow if feasible.

Acceptance Criteria

• A user can create/edit a webhook trigger and map payload paths to task/knowledge fields.
• Existing triggers without mappings continue to work.
• Invalid mapping paths/config return clear API errors.
• Manual run can test a payload and show success/failure in trigger events.
• E2E covers creating a mapped trigger in the console.
• Unit tests cover mapping extraction, default fallbacks, and invalid configs.

[serge-ivo]

Shipped in 2d9ca12.

Verified first — the ticket was accurate, and the underlying bug was worse than described. Trigger config was never validated at all: POST/PUT /v1/triggers stored safeJson(body.config) verbatim, parseConfig (lib/triggers.ts) is a whitelist that drops unlisted fields before dispatch, and presentTrigger echoed the raw stored JSON back. So a typo'd pipelin — or a correctly-spelled field belonging to a different action — was accepted, persisted, displayed in the console as configuration, and then silently ignored forever. The trigger looked configured and did nothing.

Shipped

• lib/trigger-config.ts — validateTriggerConfig(action, type, config). Create and update now 400 with the offending field named: unrecognised fields, recognised-but-wrong-action fields, timezone/jitterMinutes on a webhook, invalid mapping targets/paths, out-of-range limit/jitterMinutes.
• Required action config (pipeline, collection, url, connector provider/grantId) is enforced for cron only. A webhook or manual run may legitimately supply those in the payload (dispatch already prefers payload over config), so requiring them there would break a working pattern; a cron has no payload, so a cron missing them can only ever fail at 3am.
• GET /v1/triggers now returns the config through the whitelist parse, so what the console shows is what the dispatcher reads.
• POST /v1/triggers/preview returns the same problems non-throwing, so the console surfaces them live as you type rather than only at the save button.
• Payload mapping: config.mapping = target field → dotted payload path ({"title":"lead.name"}, array indices as segments). Mappable: create_task → title/description; add_knowledge → title/content/sourceUrl; log_event → message. A mapped path this payload lacks falls back to the existing convention, so adding a mapping can never make a working trigger produce less. Exposed over MCP too (create_instance_trigger config.mapping).
• Console: a collapsible "Payload mapping" block, shown only for actions that have mappable fields.

Deliberately not done

• No large mapping builder (payload picker / drag-and-drop). Per the brief, surfacing what the whitelist silently drops is worth more than a form; the mapping itself is three text inputs.
• No payload preview/test flow beyond "Run now" → the run history, which now shows the request payload and the result.
• Mapping is a dotted path, not an expression language — no defaults, transforms or concatenation.

Tests: 22 unit in trigger-config.test.ts, 5 dispatch-level mapping tests in triggers.test.ts, 2 e2e.