2 Commits

Author	SHA1	Message	Date
Arnas Donauskas	ed15493f95	feat(flows): templates + v1.5 nodes (collect_input/condition/set_tag) + run-history viewer (PR 4/4) ... Final feature PR before GA cleanup. Closes the gap between "flow runner works" (PR 2) and "users have everything they need to build real automation" — three new node types, plain-text sends actually sending, three starter templates, a run-history page for debugging. What landed: 1. engineSendText helper (src/lib/flows/meta-send.ts) — wraps sendTextMessage with the phone-variant retry + DB persistence pattern. Unblocks send_message + collect_input nodes that previously auto-advanced without sending. 2. Three new node types in the engine: - collect_input: sends a prompt, suspends, captures the next text reply into flow_runs.vars[var_key], advances. Supports {{vars.X}} interpolation in downstream prompts + handoff notes. - condition: branches on subject (var / tag / contact_field) with operators (equals / contains / present / absent). Auto-advancing, no Meta call. Pure predicate logic exported as evaluateConditionPredicate with 7 new unit tests. - set_tag: upsert/delete on contact_tags then advance. Non- fatal on write failure — logged + advances anyway so a tag glitch doesn't strand the customer. 3. Real send_message — calls engineSendText, logs the result, handles errors by ending the run with status='failed'. Same {{vars.X}} interpolation. 4. Three starter templates (src/lib/flows/templates.ts): - Welcome menu (the owner's brief example) - FAQ bot (keyword → list → answers → end) - Lead capture (first_inbound → collect_input chain → handoff with vars in the note) POST /api/flows now accepts {template_slug} to clone a template into a fresh draft. GET /api/flows/templates exposes the gallery shape (no nodes payload — fetched on actual clone). 5. Builder UI extensions: - NODE_META + config sub-forms for collect_input, condition, set_tag. - Template gallery on the /flows New-flow dialog (loads from /api/flows/templates, falls back gracefully if absent). - "Runs" button in the editor header → /flows/[id]/runs. 6. Run-history viewer at /flows/[id]/runs — newest-first list of the 50 most recent runs, with expandable per-run event timeline (started, node_entered, message_sent, reply_received, fallback_fired, handoff, timeout, error, completed). Useful for debugging "why didn't my flow advance?" from the brief's use case. 7. Validator updates: new error rules for each new node type (prompt_text required, var_key alphanumeric, operator valid, true_next/false_next exist, etc.). outgoingEdges helper now covers collect_input/condition/set_tag for reachability. All gated behind isFlowsEnabled(profile). Non-beta accounts see no change. Run-history API is also 404 for non-beta. Validation: 173/173 tests pass (added 7 new for the predicate); typecheck + lint + build all clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 14:27:01 +03:00
Arnas Donauskas	dc245d5914	feat(flows): foundation for interactive WhatsApp messages (PR 1/4) ... Foundation for the upcoming WhatsApp chatbot flow builder. No runner, no UI yet — just the plumbing that lets the codebase SEND interactive messages (button replies + lists) and RECEIVE the taps as structured message rows. Plan: ~/.claude/plans/understood-research-such-functionality-binary-lake.md ## What's in this PR ### Migration 010_flows.sql - New tables: flows, flow_nodes, flow_runs, flow_run_events - Linchpin partial unique index on flow_runs(user_id, contact_id) WHERE status='active' — at most one active run per contact, makes concurrent webhook deliveries idempotent at the DB layer - Widens messages.content_type CHECK to allow 'interactive' - New messages.interactive_reply_id column for the tapped button/row id - RLS on every table; flow_runs added to supabase_realtime publication - Idempotent throughout — matches the 009_message_actions.sql template ### Interactive Meta senders (src/lib/whatsapp/meta-api.ts) - sendInteractiveButtons: type='interactive', interactive.type='button', up to 3 reply buttons - sendInteractiveList: type='interactive', interactive.type='list', up to 10 rows across sections - Limits exported as INTERACTIVE_LIMITS so flow validation can share the constants - All Meta caps validated BEFORE the network call (button title ≤20 chars, list row title ≤24 chars, ≤10 total rows, no duplicate row ids, body ≤1024 chars, etc.) — misconfigured flows fail at save time instead of as a customer-facing 400 mid-conversation ### Webhook (src/app/api/whatsapp/webhook/route.ts) - Extends WhatsAppMessage interface with `interactive?: { type, button_reply?, list_reply? }` - parseMessageContent returns a new `interactiveReplyId` field; refactored to use a shared `empty` base so every return site picks up the new field without 9 explicit copies - New `case 'interactive'`: uses the tapped option's TITLE as content_text (so the inbox bubble reads "Existing customer", not a UUID) and stashes the id separately - 'interactive' added to ALLOWED_CONTENT_TYPES so the messages insert no longer coerces it to 'text' ### Inbox bubble (src/components/inbox/message-bubble.tsx) - New `case "interactive"` in MessageContent renders the tap with a small "↩ Button reply" affordance so agents reading the inbox can tell at a glance that this was a tap rather than the customer typing the same words ### Types (src/types/index.ts) - ContentType union extended with 'interactive' - Message.interactive_reply_id field ### Engine helpers (src/lib/flows/) - admin-client.ts: thin service-role client wrapper, mirrors automations/admin-client.ts - meta-send.ts: engineSendInteractiveButtons / engineSendInteractiveList — adapts the Meta senders for service-role use, persists messages with sender_type='bot' content_type='interactive', uses the same phone-variant retry as automations/meta-send.ts. Unused in PR #1; ready for the runner in PR #2 ### Tests - 13 new vitest cases in meta-api.test.ts covering Meta's limit validation + payload-shape assertions for both interactive senders ## Validation - npm test → 102/102 (was 89; 13 new) - npm run lint → 0 errors - npm run typecheck → clean - npm run build → clean ## What's NOT in this PR - The runner (dispatchInboundToFlows) — PR #2 - Builder UI / API surface — PR #3 - collect_input / condition / set_tag nodes + templates — PR #4 - react-flow canvas + http_fetch — v2 (PR #5) ## Risks tracked from the plan - messages.content_type CHECK widening: grep'd every consumer; message-bubble.tsx, reply-quote.tsx, send/route.ts, automations/meta-send.ts all handle the new variant correctly (or accept it as a defaulted fallthrough) - engineSendText / engineSendInteractive share ~80% of code; deliberately not pre-factored yet — let both stabilize, extract a shared base in PR #2 once the shape settles Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 13:12:27 +03:00