Integrazioni & nodi pronti all'uso

Innesco manuale enterprise pensato per il ciclo developer/operatore di sviluppo, debug, validazione di un workflow prima della messa in produzione automatica — l'equivalent del bottone "Run" di n8n, "Test pipeline" di Make/Integromat, o "Execute SQL" di un editor database. Il workflow resta in stato idle (nessun consumo di risorse) finché l'utente non clicca esplicitamente il bottone "Esegui" del Topbar dell'editor FlowForge (oppure equivalente shortcut da tastiera Ctrl+Enter / Cmd+Enter). Una volta avviato, il run procede come qualsiasi altro: stessi nodi esecutori reali, scrive su SQLite runs/steps come al solito (NO modalità sandbox o dry-run separata — il side effect REAL), audit_log tracciato come trigger_type='manual' nell'analytics dashboard del tenant per separazione dei run manuali (test, one-shot operativi) dai run automatici (produzione). Input al workflow downstream: il caller può passare un payload JSON arbitrario tramite il modal di test dell'editor (form rich con autocomplete dai run history precedenti — pattern velocità del developer che vuole rieseguire test con varianti minime), oppure semplicemente lanciare con input vuoto se il workflow non richiede dati di ingresso. Il triggeredBy del run viene popolato con lo user_id loggato — utile per audit "chi ha lanciato manualmente questa pipeline" in caso di incident review. NO trigger automatico: questo nodo non parte mai da solo, niente cron interno, niente webhook listener, niente file watch — è strettamente reactive a click utente. Per workflow di produzione che devono partire automatically usa trigger_cron (schedulato a tempi fissi), trigger_webhook (POST esterno), trigger_imap (email ricezione), trigger_form (web form embed), trigger_file_watch (filesystem drop), trigger_db_change (mutation database), trigger_rss_feed (feed update), trigger_odoo_polling (ERP). Use case: testing rapido durante editing iterativo (modifica config → click Esegui → verifica output → aggiusta → click Esegui → ...); dry-run con input mock prima di propagare in produzione il workflow reale (es. testare email_send con destinatario "[email protected]" prima di puntare alla lista cliente di 500 persone); esecuzione one-shot di workflow scheduled (es. il workflow di chiusura conti mensile è normalmente cron 1° del mese 03:00, ma il commercialista vuole rilanciarlo oggi pomeriggio dopo aver corretto un dato nei conti — click Esegui invece di aspettare il prossimo cron tick); execution su demand di workflow di reporting custom per produrre l'export richiesto al volo dal CEO; debug interactive di workflow falliti con replay manuale step-by-step.

Scheduler enterprise per esecuzione pianificata di workflow su base cron — l'innesco di tutte le pipeline di automation ricorrente tempo-based che dominano i workflow business (reporting giornaliero, cleanup notturno, sync periodici, email settimanali, alerting orario). Implementa il modello cron Unix classico (sintassi posizionale "min hour day month dow") esteso con builder visuale no-code per non-developer commercialisti/marketer che vogliono "ogni lunedì alle 09:00" senza dover ricordare la sintassi `0 9 * * 1`. Builder UI con tre modalità complementari: frequenza preset (ogni N minuti/ore/giorni/settimane con spinner numerico — pattern "ogni 15 minuti", "ogni 6 ore", "ogni 3 giorni"), regolazione fine (combinator visuale di minute+hour+day_of_week+day_of_month+month con dropdown selettivi), expressione cron string libera per power user che conoscono la sintassi ("0 9 1-15 * *" = "ore 9:00 dei giorni 1-15 di ogni mese"). Anteprima umana sempre visibile sotto il widget ("Ogni lunedì alle 09:00 UTC", "Il 1 di ogni mese alle 03:00 Europe/Rome") per confidence-check dell'utente prima del save. Timezone-aware: default UTC ma il tenant può configurare timezone preferita (Europe/Rome standard per business italiano) — il cron è valutato secondo quella timezone, gestendo correttamente DST transition (ora legale/ora solare 2x l'anno) per evitare il classico bug "il report delle 09:00 oggi è arrivato alle 10:00 perché è cambiata l'ora legale". Architettura distribuita: lo scheduler vive nel portal centrale (non nel container tenant) — questo significa che cron continuano a partire anche con container in pausa (lifecycle sweeper sospende i container idle), e il portal fa wake-up automatico del container quando arriva l'ora di execution (no sleep penalty su piano Free). Il portal mantiene il last_fired_at di ogni cron e gestisce missed_runs detection (se il container era down per > 1 schedule, il portal sa quanti runs sono stati persi e può decidere catch-up o skip in base a policy configurable). Input al workflow downstream: { triggeredAt (ISO timestamp del firing), scheduledFor (l'orario nominale configurato — può differire da triggeredAt per pochi secondi su scheduler delay), missedRuns? (count se sono stati saltati run precedenti), timezone, cronExpression }. Use case: report giornaliero KPI mattina inviato al CEO via email/Telegram con summary del business precedente (cron "0 8 * * 1-5" = ore 8 dei giorni feriali); polling cron orario su API third-party che non hanno webhook (controllo nuovi ordini su marketplace, cambi di tasso di cambio per pricing dinamico, updates da gestionale legacy); cleanup periodico DB del tenant per rimozione record obsoleti GDPR compliance (cron daily 03:00); sync nightly CRM bidirezionale tra Pipedrive e Salesforce/HubSpot per multi-CRM strategy; email summary settimanale del team performance ogni domenica sera per i manager.

Avvia il workflow quando una richiesta HTTP arriva all'URL del webhook. URL pubblico generato automaticamente (path = workflow_id + token random) e mostrato nel pannello "Webhook URL" del nodo. Path custom opzionale via customPath per URL leggibili (es. /webhooks/c/stripe/event invece di /webhooks/<uuid>). Differenza con i sibling: trigger_webhook = endpoint always-on, request-response. Per sospensione mid-workflow con resume su callback vedi logic_wait_signal. Per ingest email usa trigger_imap. Per polling DB usa trigger_db_change. Per scheduled jobs usa trigger_cron. Auth modes: none (pubblico, signed token nel URL), bearer (Authorization header), HMAC-SHA256 (firma body con secret condiviso — pattern Stripe/PayPal/Slack), basic auth (RFC 7617), JWT verify (issuer/audience/exp check). HMAC e\` raccomandato per integrazioni B2B production — il token nel URL e\` log-leak vulnerable mentre la firma HMAC valida ogni request anche se URL e\` intercettata. Response modes: (a) use-respond-node = workflow finale termina con action_webhook_respond che decide status+body+headers (caso generale, API REST custom), (b) fire-and-forget = ritorna 202 Accepted subito + workflow continua async (per webhook ad alta frequenza Stripe/SDI dove il chiamante non vuole bloccarsi su tua elaborazione lenta), (c) sync-200 = sempre 200 con echo del body trigger (debug/test endpoints). Features production-grade: raw body capture (per HMAC verify byte-perfect senza JSON re-serialization che spaccherebbe la firma), CORS configurabile per integrazioni browser (origin allowlist, preflight handled), idempotency-key via header Idempotency-Key (pattern Stripe — dedup chiamate duplicate su retry), upload binari fino a 50 MB con streaming a disk (no memory bloat). Use case: (1) callback Stripe/PayPal/SDI post-pagamento con HMAC verify e branching su event type, (2) endpoint API REST custom per integrazioni vendor B2B con auth Bearer, (3) submit form landing page (response HTML redirect post-success), (4) inbound webhook da CRM esterno con dedup Idempotency-Key per retry safe. Safety budget: rate limit per-host configurabile (default 100 req/min), max body 50 MB stream-to-disk, timeout response 30s (oltre si chiude connection ma workflow continua se fire-and-forget), audit log su ogni hit con ip + headers + body_hash per forensics.

Generatore di form HTML pubblico no-code enterprise — il classico "drop a form on your website" feature che rende possibile collezionare input da audience esterna (clienti, prospect, candidati, segnalanti) senza richiedere account FlowForge né uno sviluppatore frontend per costruire HTML/JS form a mano. Il drag&drop fields builder dell'editor permette al business user (commercialista, marketing manager, HR recruiter) di comporre il form in 2 minuti scegliendo tipi di campo con configurazione visuale (label, placeholder, required, validation regex, default, opzioni select), preview real-time del risultato HTML finale, e l'expression di pubblicazione genera un URL univoco di tipo https://<tenant>.app.automazionezeli.com/forms/<workflowId>/<publicToken> che può essere embedded in iframe sul sito esterno, condiviso come link sui social, allegato in email marketing, stampato su volantini come QR code. Ogni submission completata triggera un nuovo run del workflow con un input strutturato { fieldKey: value (mapping di tutti i field secondo il config), _meta: { ip (anonimizzato per GDPR per gli ultimi 16 bit IPv4 o 80 bit IPv6), userAgent (normalizzato a famiglia browser per analytics non-PII), submittedAt (ISO 8601 UTC), referer (URL referrer pagina origine del traffic), country (GeoIP-derived dal Cloudflare CF-IPCountry header), formVersion (per A/B testing) } }. Field types supportati copertura completa: text (single line, max length config), textarea (multi-line con limite caratteri visible), email (validation HTML5 + DNS MX lookup opt-in via integrazione action_email_validate_mx downstream), number (with min/max, step decimale), date (datepicker browser nativo con range cap), select (dropdown con opzioni statiche o dinamiche da DB query), checkbox (multi selection), file (upload con allowlist MIME e cap dimensione default 10MB), hidden (passthrough di parametri injected via query string per tracking source/campaign). Validation a doppio strato: client-side HTML5 native + JavaScript per UX immediata, server-side rigorosa per security (NIENTE trust al client malevolo che bypassa il JS). Anti-spam multi-layer: honeypot field (campo invisible che solo i bot riempono — il workflow rigetta le submission che lo hanno valorizzato), rate-limit per IP (default 5 submission/min stessa IP, configurable), Sentinel WAF integration per detection di pattern brute-force, opzionale reCAPTCHA v3 invisibile per submission ad alto-volume. Use case: lead capture da landing page marketing — il form embedded sul sito raccoglie nome+email+azienda e il workflow downstream fa upsert in HubSpot + invio email benvenuto + creazione card Trello per follow-up commerciale; ticketing customer support — form con priority+category+description triggera workflow di creazione issue GitHub + notifica Slack al team competente; sondaggi audience per market research con multi-step form e logica condizionale; data-collection da non-utenti FlowForge (candidati di una posizione lavorativa, clienti che chiedono preventivo, partecipanti a evento webinar); registrazione utenti a community con verifica email automatica downstream.

Watcher filesystem enterprise basato su chokidar (battle-tested in Webpack, Parcel, Vite e altri 100M+ downloads/anno) che firma il workflow quando un file viene creato (add), modificato (change), o cancellato (unlink) in una directory monitorata del volume persistente del tenant — il modulo "Drop folder" tipico di gestionali Italiani, dove un operatore "lascia cadere" un PDF/CSV/XLS nella cartella di rete e il sistema lo processa automaticamente entro pochi secondi senza richiedere upload via UI. Implementazione: chokidar usa fs.watch nativo di Node.js con fallback su polling per filesystem che non supportano inotify (es. mount NFS, container Docker overlay2 in alcune config Kubernetes), garantendo cross-platform consistency (Linux inotify, macOS FSEvents, Windows ReadDirectoryChangesW). Debounce configurabile (default 300ms) per evitare event flood quando un'applicazione scrive il file a chunks (es. SFTP upload progressivo, browser drag-drop multi-MB) — il trigger attende stabilità della dimensione prima di firmare il workflow, evitando di processare file half-written. Sicurezza: path allowlist obbligatorio (root path della cartella + descendant), NO escape verso /etc o /proc, NO symlink resolution (se la cartella contiene link simbolici, vengono ignorati per evitare path traversal); ownership check verifica che il file appartenga al tenant utente; cap su dimensione massima configurabile (default 100MB) per evitare DoS via upload di file GB. Filtri: pattern glob standard (*.csv, *.pdf, **/contracts/*.docx, !temp/*), eventi sottoscritti (add+change+unlink in combinazioni). Input al workflow downstream: { path (absolute path da root), name (basename), extension, sizeBytes, mtime (ISO 8601), event (add|change|unlink), checksumSha256? (utile per dedup di file rinominati) }. Use case: ingest automatico di CSV uploadati via SFTP dal commercialista esterno alle 23:00 nella cartella drop/ → workflow parse + INSERT in db_query bulk; monitoraggio della cartella shared/pec-fatture-2026/ → ogni nuovo PDF triggers OCR via action_vision_extract + creazione fattura Odoo via action_odoo_create_lead; processing immediato di video caricati dall'utente in dropbox/ → action_video_metadata per estrarre durata e codec → action_ffmpeg_thumbnail per genere preview JPG; data ingestion sistema SAP che esporta giornalmente CSV in formato fixed-width nella cartella di scambio.

Innesco enterprise IMAP che monitora periodicamente una inbox email e attiva il workflow alla ricezione di nuovi messaggi che corrispondono ai filtri configurati — il backbone di tutte le pipeline email-driven business critical: triage automatic email customer support, ingest PEC con allegato fattura per studio commercialista, parse ordini cliente legacy ricevuti via email, archiviazione legale a norma di messaggi contrattuali. Implementazione robusta su protocollo IMAP standard RFC 3501 + estensioni IMAP4 IDLE per push real-time (quando supportato dal server email — Gmail/Outlook/Exchange Online/iCloud) e fallback graceful su polling temporizzato (pattern per server IMAP legacy come Aruba, Register.it, Microsoft Exchange On-Premise di vecchia generazione che non supportano IDLE persistent connection). Due modalità di configurazione complementari per coprire i pattern enterprise: (1) selezione di un Account Email di Sistema dal vault centralizzato del tenant (Settings → Email Accounts), pattern preferito per multi-workflow share dello stesso account senza duplicare credentials in N nodi diversi — un singolo "Inbox Studio" config riusato da workflow PEC + workflow customer support; (2) compilazione inline diretta dei campi (IMAP host, port, username, password) per use case one-off senza vault touch — pattern dev/test o quando ogni workflow ha sua mailbox dedicata. Filtri rich: oggetto (substring o regex match — per workflow specifici dedicati a soggetti pattern come "FATTURA*" o "ORDINE*"), mittente (whitelist email/domain o blocklist per noise reduction), presenza allegato (boolean has_attachment + filter per MIME type ".pdf"/".xml"), etichetta IMAP/folder (filtra solo email in folder "INBOX/Importanti" o flagged \Seen=false per processing solo unread), header custom matching per identificare PEC ufficiali con X-Ricevuta. Polling configurable: 30s default per real-time-ish responsive, fino a 30min per inbox low-volume + cost-conscious — il trigger scheduler centrale del portal orchestra il polling senza tenere il container sveglio inutilmente. Dedup intelligent via Message-ID header persistito nel tenant DB — anche con IMAP IDLE + polling overlap, ogni email è processata esattamente UNA volta (exactly-once delivery semantics cruciale per workflow legali con effetto fiscale). Retry automatic su connection errors (network timeout, server down 5xx, auth expired) con exponential backoff + alert al tenant admin dopo 3 falli consecutivi. Use case: trigger automation alla ricezione PEC con allegato fattura per studio commercialista (filter has_attachment=true + sender_domain in PEC provider list — il workflow parsa il pdf con vision_extract, crea fattura in Odoo, archivia legale via action_pec_legal_archive); parsing automatico ordini email cliente B2B verso ERP (PMI italiani che ancora ricevono ordini via email tradizionale non EDI); reply-handling triage AI per support inbox (agent_email_triage classifica intent → routing al team competente); archiviazione legale automatic delle email contrattuali per compliance.

Innesco reattivo enterprise per change data capture su tabelle del database integrato FlowForge — il modulo "database low-code" del tenant che permette di definire schemi e tabelle dalla UI senza scrivere SQL, alimentato downstream da workflow di automation. Esegue il workflow tutte le volte che una riga corrispondente al filtro configurato viene INSERTed (nuovo record creato), UPDATEd (modifica a un record esistente, con detection del campo specifico cambiato per evitare loop infiniti), DELETEd (eliminazione, logica o fisica). Implementazione: dual-mode hot-swappable senza redeploy — modalità polling (default, safe per qualsiasi tabella, cursor su id + updated_at con frequenza configurabile 5s-1h, exactly-once semantics garantita dallo state store del trigger), oppure modalità real-time via trigger SQL nativo PostgreSQL/SQLite (LISTEN/NOTIFY pubblicato da AFTER INSERT/UPDATE/DELETE FOR EACH ROW, latency sotto i 50ms ma richiede privilegi DBA per CREATE TRIGGER — usabile quando il tenant ha schema isolato). Filtri configurabili: where clause SQL-like su uno o più campi (es. "status = 'pending' AND amount > 1000" — solo gli ordini grossi attendono pagamento triggera il flow), watch su una SPECIFICA colonna per UPDATE (es. "scatena solo se cambia il campo `delivery_status`, ignora aggiornamenti su `last_login`" — fondamentale per evitare loop quando il workflow stesso scrive in altre colonne della stessa tabella). Input al workflow downstream: { event: 'insert'|'update'|'delete', row (oggetto completo della riga corrente), oldRow? (snapshot pre-modifica per UPDATE, utile per audit log "campo X passato da Y a Z"), table (nome della tabella per multi-tabella workflow di logging), changedColumns? (lista delle colonne effettivamente cambiate nell'UPDATE), timestamp (ISO 8601 dell'evento DB) }. Use case: notifica admin via action_email_send_tracked quando insert in ordini_pending con importo > €500 (escalation EU "Codice del Consumatore" rimborsi); sync esterno verso HubSpot CRM tramite action_http post update di customers.email per allineare il marketing pipeline; audit trigger su tabella users per cambio di role/status con append automatico su audit_log immutable; workflow ETL che esporta verso data warehouse Snowflake ogni nuovo record di analytics_events; alerting su account.move Odoo quando una fattura viene cancellata da utente non autorizzato (signal anti-fraud per il controllo di gestione).

Esegue una richiesta HTTP/HTTPS verso API esterne. Coltellino svizzero per qualunque integrazione vendor non gia\` coperta da un nodo dedicato (action_send_email, community_*, integration_*). Differenza con i sibling: action_http = REST/RPC generico full-feature (auth multipla, body 5 forme, pagination 4 strategie, retry/breaker). Per scraping HTML usa action_web_fetch_advanced (header browser preset, cookie jar, anti-bot light). Per orchestrazione adaptive con AI extract usa action_scrape_smart (fetch→render→stealth→vision pipeline). Auth supportata: Basic (user:pass base64), Bearer (token in header), API Key (header o query), OAuth1 (RFC 5849 signed), OAuth2 (token via vault tenant), Custom (header arbitrari). Body: JSON serializzato (con merge di key-value editor), Form url-encoded, Multipart (file upload + campi misti), Raw (string custom Content-Type), Binary (base64 da nodo upstream). Pagination automatica con 4 strategie: page-number (?page=N), offset/limit (?offset=N&limit=M), cursor opaco (?cursor=X from response), Link header RFC 5988 (Link: <url>; rel="next"). Walker bounded — maxPages cap protegge da loop infiniti se il vendor implementa Link male. Resilienza enterprise: retry con backoff configurabile (count + delay base + jitter exponential), follow redirects con limit, response format selezionabile (auto-detect via Content-Type / json / text / binary base64), timeout per-request. Wrap automatico con circuit breaker per-host (shared con tutti i nodi che colpiscono lo stesso host — se il vendor e\` giu\`, tutti i workflow si fermano insieme prima di accumulare timeout). Telemetry OpenTelemetry: span per request con method/host/status/duration per dashboard SRE. Use case: (1) chiamata API vendor non coperto da community_* (es. ERP italiano custom), (2) integrazione SaaS interno con auth Bearer + retry idempotente, (3) sync periodico catalogo prodotti con pagination cursor su API REST esterna, (4) webhook outbound notify verso CRM partner con telemetry SLA per audit. Safety budget: SSRF guard via safeOutboundFetch (blocca 127.0.0.1, 10.x/172.16.x/192.168.x, link-local), max response size 50 MB (override per-call), timeout default 30s, retry max 5 attempts, circuit breaker apre su 5 fail consecutivi/30s. Audit log su ogni call con request_id + duration.

Nodo di lettura file enterprise dal filesystem persistente del container tenant FlowForge — controparte inversa di action_file_write, condivide le stesse guardrail di sicurezza zero-trust. Legge il contenuto di un file all'interno della cartella sandbox del tenant (/data per il container Docker corrispondente), con allowlist enforcement server-side: no escape ../, no symlink resolution (link simbolici a file fuori sandbox rifiutati prima del read), no accesso a directory di sistema /etc /proc /sys, ownership check sul UID del processo runtime, cap di sicurezza su dimensione file leggibile (default 100MB per evitare OOM su read di file giganti via expression maligna). Encoding multi-formato configurabili in base al tipo di payload contenuto: utf8 (default, per testo/JSON/CSV/XML/YAML che sono il 90% degli use case workflow business), utf16le (per file Windows legacy con BOM FF FE generati da Notepad o sistemi mainframe), base64 (per binari PDF/JPG/PNG/MP3 da passare a action_send_email come attachment senza necessità di file system intermedio, o per ingest in db come TEXT field), hex (per debug binari low-level di file corruption — visualizza i raw bytes), binary (raw buffer pass-through per binary processing downstream tipo action_ffmpeg). Output: { content (string nel formato encoding richiesto), sizeBytes (per quota tracking + analytics), mtime (ISO 8601 per detection di file aggiornato vs cached version), path (absolute resolved), sha256? (hash crittografico opzionale per integrity check su backup/restore workflow), mimeType? (rilevato automaticamente da magic bytes per file binari), lineCount? (per file testuali, conteggio newline per quick stats) }. Error semantics esplicito: path fuori sandbox → SANDBOX_VIOLATION 403 con audit log + reason; file non esistente → ENOENT 404 (use case workflow tipico: trigger_file_watch firma su file in fase di upload progressivo SFTP → action_file_read fallisce con ENOENT → retry con logic_delay 5s gestisce gracefully); file > cap dimensione → FILE_TOO_LARGE 413. Use case: caricare file di configurazione statici (config.json, mappe lookup, blocklist) per uso lungo l'intero workflow batch; leggere CSV uploaded dal cliente via SFTP nella cartella drop/ + parsing tramite logic_convert per ingest in db_query bulk insert; lettura di template documenti markdown pre-creati dal customer (es. "template_offerta_v3.md") per generation downstream tramite action_pdf_generate con expression substitution dei placeholder cliente-specifici; ingest di file droppati da action_file_write upstream nello stesso workflow (pattern pipeline ETL: write JSON intermedio → process → read finale); re-read in successive run tramite trigger_cron del file di state cross-run (alternativa al memory_note per state JSON > 1MB).

Nodo di scrittura file enterprise sul filesystem persistente del container tenant FlowForge — l'equivalente managed-cloud di un fs.writeFile Node.js con guard-rail di sicurezza multipli + audit + expression templating. Scrive il contenuto fornito (string, JSON serializzato, output di altri nodi via expression {{$node.X.json.body}}) in un file all'interno della cartella sandbox del tenant (/data per il container Docker corrispondente, cap di 1GB per tenant FREE / 10GB PRO / 100GB TEAM). Sicurezza zero-trust: allowlist enforced server-side (no escape ../, no symlink resolution, no overwrite di file system del container tipo /etc, /usr, /var/run), validazione path canonicalizzato prima della apertura, ownership check (file scritti come UID 65532 del processo runtime, immutable bit non modificabile), cap su dimensione file singolo configurabile (default 100MB) per evitare DoS via fill-disk. Crea automaticamente le directory mancanti nel path (mkdir -p atomico) — niente errore "ENOENT no such file or directory" che richiede 2 nodi per fare la stessa cosa. Due modalità di scrittura: overwrite (default — sovrascrive completamente il file precedente, write+rename atomico per consistenza in caso di crash a metà write) oppure append (aggiunge il contenuto alla coda del file esistente — fondamentale per logfile incrementali che crescono nel tempo, per evitare race condition su concurrent write di workflow paralleli sullo stesso file il nodo usa O_APPEND atomico syscall-level). Supporta interamente il sistema di template FlowForge: {{espressioni}} nel contenuto vengono valutate dall'expression engine prima della scrittura (accesso a $node, $input, $vars, helpers come $date.now, $string.upper, $crypto.sha256). Output: { path (absolute resolved), bytesWritten (per audit + quota), mode (overwrite|append), mtimeIso, sha256? (computato se sha256 fornito come check di integrità) }. Use case: scrivere report mensili HTML/PDF generati da action_pdf_generate nella cartella /data/reports/ per download cliente; log eventi su file rotante /data/logs/audit-{{$date.today}}.log con mode=append (rotazione automatica daily); persist state cross-run del workflow tipo "ultimo timestamp processato" per pipeline incrementali (alternativa al memory_note per state JSON > 1MB); export CSV consumati da action_file_read downstream nello stesso workflow o in run successive; salvataggio temporaneo di file binari (uudecoded da base64) prima di processing tramite action_ffmpeg o action_vision_extract.

Parser enterprise per file Microsoft Excel formato .xlsx (Office Open XML SpreadsheetML, lo standard Excel 2007+ universalmente usato nei workflow business italiani: commercialisti, controlling, sales reporting, magazzino, ordini, fatturazione, riconciliazione bancaria, anagrafica clienti/fornitori). Trasforma il binario Excel in un dataset processabile come array di oggetti JavaScript pronto per loop, filter, sync, ingest in DB o pipeline downstream. La prima riga del foglio è interpretata di default come header (intestazioni colonne) e le righe successive diventano oggetti dove ogni cella corrisponde al valore del campo identificato dall'header — pattern naturale per non-developer che esportano CRM/ERP/gestionali in Excel e vogliono manipolare i dati programmaticamente. Input duale per coprire i pattern di provenienza file Excel reali in workflow business: input da disco (path nel sandbox del tenant, es. file uploadato via SFTP, scritto da action_file_write upstream, droppato da trigger_file_watch nella cartella shared) oppure input da base64 (la rappresentazione string-encoded del binario, formato canonico per attachment di trigger_imap email, body di webhook multipart upload via trigger_form, payload API con file embedded). Auto-detect del formato di input. Multi-foglio support: il workbook Excel può contenere N fogli (sheet) — il nodo permette di selezionare uno specifico per nome ("Ordini", "Listino", "Fatture") o per indice (0-based), oppure di iterare tutti i fogli ed emettere array consolidato (utile per Excel con multi-mese in fogli separati "2026-01", "2026-02", ecc.). HeaderRow configurabile: per file Excel "professionali" con titolo + logo aziendale + metadata nelle prime righe (pattern comune nei file da gestionali italiani come Sage, Zucchetti, TeamSystem), la riga di header è alla riga 5 o 7, non alla riga 1 — il parametro headerRow (default 1, 1-based) skippa le righe iniziali decorative. Type preservation: numeri restano numeric (non stringificati con perdita di precisione), date Excel serial number convertite in Date object JavaScript (con timezone corretta), booleani come true/false, celle vuote come null (consistenza per filter downstream). Cap di sicurezza: max 1M rows per evitare OOM su file enormi (l'Excel format supporta 1M+ righe ma lavorarci in JavaScript pratico < 100k), warning se headerRow > 100 (probabile sbaglio di config). Output: { rows: [{ ...fields_per_header }], totalRows, sheetName, headerRow, columnCount, truncated, emptyCellsCount }. Use case: ingest ordini da allegato Excel di una email IMAP cliente B2B (cliente legacy che ancora manda ordini via Excel anziché EDI) → parse → loop su rows → action_odoo_create_lead per ogni riga; import lead da export CRM xlsx caricato dall'utente via trigger_form upload → loop → upsert HubSpot; parse listino prezzi fornitore aggiornato periodicamente (trigger_file_watch + action_xlsx_parse + sync DB pricing); batch update di anagrafica clienti da spreadsheet di riconciliazione contabile mensile del commercialista; processing di export Salesforce SOQL salvato come Excel per dashboard custom; estrazione di righe specifiche da modulo F24 in formato Excel per tracking pagamenti tributi.

Generator enterprise di file Excel formato .xlsx (Office Open XML SpreadsheetML, lo standard Microsoft Excel 2007+ universalmente compatibile con Excel desktop Windows/Mac, Excel Web, LibreOffice Calc, OpenOffice Calc, Google Sheets import, Numbers Mac) — la controparte inversa di action_xlsx_parse, fondamentale per output di report del workflow business verso destinatari non-tecnici che usano Excel come ambiente nativo di consumo dati. Trasforma un array di oggetti JavaScript (pipe naturale da db_query, paginate, listScheduledEvents Calendly, queryDatabase Notion, qualsiasi data source upstream) in un file Excel pronto da scaricare, allegare a email transazionale, archiviare su S3 per long-term compliance, condividere via OneDrive con il team management. Output disponibile in due forme per coprire i pattern d'uso reali: base64 string (pronto per allegato in action_send_email tramite il campo attachments senza dover passare per il filesystem intermedio — il pattern più comune per report inviati via email) oppure save su disco nel sandbox del tenant (scrittura atomica write+rename, pattern per workflow di archivio long-term o per file destinati a download successivo via UI tenant). Customization rich del file output: header row personalizzabile (le intestazioni colonne possono differire dai field name JavaScript — es. "first_name" come field interno ma "Nome" come visualizzazione utente in Excel), formattazione colonne type-aware (numero con decimal places, percentage con simbolo %, valuta con simbolo € e separator italiano "1.234,56", data con formato locale "DD/MM/YYYY", text plain), foglio nominato (default "Sheet1", configurable a "Ordini", "Cedolini", "Riconciliazione" per self-documenting workbook), auto-width colonne basato sul contenuto massimo per evitare il classico "#####" su numeri grossi che non entrano, freeze panes per la prima riga (header always visibile in scroll). Type preservation reverse del parse: number JavaScript → numeric cell Excel (con precision), Date → Excel serial number con timezone preservation, boolean → "TRUE"/"FALSE" string canonica Excel, null → empty cell (no string "null" che inquinerebbe), array/object → JSON serialized in singola cell come string. Cap di sicurezza: max 1M rows per workbook (limit hard Excel), cap su dimensione file output 50MB per evitare OOM su workflow generando file giganti. Output: { base64 (stringa pronta per attachments), size_bytes, path? (se salvato su disco), rowCount, columnCount, sheetName, fileName, mimeType: "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" }. Use case: report settimanale vendite allegato a email management ogni lunedì 09:00 (trigger_cron + db_query + xlsx_build + send_email con base64 attachment); export ordini CRM HubSpot verso fornitore B2B EDI-less in formato xlsx settimanale con calcolo prezzi netti+IVA; backup quotidiano di tabella DB critica in spreadsheet archiviato su S3 con retention 7 anni per compliance fiscale; generazione di template fattura/preventivo riempito con dati cliente da Odoo per stampa controllo prima emissione SDI; analytics dashboard "scaricabile" per CEO che preferisce Excel a Looker con drill-down formule pivotabili.

Estrazione testo da PDF con cascata 2-stage qualità-prima: pdf-parse libreria gratuita (~50ms, zero cost, no API) come tentativo veloce → fallback automatico a Claude Sonnet vision (cost ~$0.003-0.015/PDF, latency 2-5s) quando pdf-parse ritorna testo scarno o gibberish da PDF scannerizzato. La heuristica fallback usa confidence score basato su densità caratteri leggibili + presenza glifi standard latini. Differenza con i sibling: action_pdf_parse = text extraction OUT (PDF → string). Per generare PDF IN partendo da titolo+sezioni+tabella vedi action_pdf_generate (pdfkit, fatture/cataloghi). Per immagini generiche con AI vedi action_vision_extract (Qwen2.5-VL-7B locale, no Claude cost). Modalità configurabili: auto (default — cascata pdf-parse → Claude se low confidence), pdf-parse-only (zero cost, accetta fallimenti su scan), llm-only (massima qualità, sempre Claude — usare quando sai a priori che i PDF sono scan). La modalità auto e\` consigliata: il 70-80% dei PDF moderni hanno text layer estraibile gratis, il fallback Claude paga solo per i casi reali (vecchi scan, ricevute fotografate). Input flessibile: file da disco (path nel sandbox tenant, file-picker UI) OPPURE base64 da nodo upstream (tipico: allegato trigger_imap senza salvare su disco). Max 32 MB hard cap per evitare OOM, 100 pagine cap su modalità Claude per cost control. Use case: (1) ingest fatture PEC ricevute via trigger_imap → estrarre IBAN + importo + scadenza per inserimento contabile automatico, (2) parsing contratti firmati per archiviazione searchable con full-text index, (3) categorizzazione spese da ricevute scannerizzate (Claude vision riconosce anche grafica/logo), (4) corpus PDF per pipeline RAG con embedding BGE-M3. Safety budget: SSRF non applicabile (nessun fetch outbound), file I/O sandboxato su tenant data dir, cost cap configurabile per workflow (max N call Claude/run), audit log con sha256 input + mode used + tokens consumed.

Risponde alla richiesta HTTP del trigger_webhook con body, status code e headers personalizzati. Da posizionare ALLA FINE del ramo workflow quando il chiamante aspetta una response sincrona — senza questo nodo (e con responseMode="use-respond-node" nel trigger) il runtime restituisce JSON fallback `{runId, status}`, non quello che vuole il vendor partner B2B che ti sta chiamando. Differenza con i sibling: action_webhook_respond = response sincrona allo stesso request del trigger_webhook (1-1 pairing). Se vuoi rispondere SUBITO + continuare workflow async usa responseMode="fire-and-forget" sul trigger (no respond node necessario). Per redirect senza body usa modalità "Redirect" qui invece di costruire location header a mano. Modalità predefinite (zero-config per il caso comune): (a) JSON — body=auto-stringify del JSON config o expression upstream, content-type application/json + charset utf-8, (b) Testo plain, (c) HTML — content-type text/html + charset utf-8 (per SSR detail pages tipo Streammy/cataloghi), (d) Redirect 302/303/307 — solo Location header (preserva method o forza GET secondo status), (e) File binario — body base64 + Content-Disposition attachment con filename, (f) 204 No Content — risposta vuota per ack-only, (g) Custom — full control su body+status+headersJson. Features production: interpolation espressioni nel customBody ({{$node.upstream.json.X}} per dati dinamici da step precedenti), headersJson per CORS/Cache-Control/X-* custom, status preset comuni (200 OK / 201 Created / 202 Accepted / 204 No Content / 302/303 / 400/401/403/404 / 500), supporto streaming download grandi via base64 + bodyIsBase64=true (sentinel runtime decode lazy). Use case: (1) API REST custom che restituisce JSON dopo elaborazione DB (Liara/agent_extractor → DB → respond), (2) endpoint Stripe/PayPal webhook che deve restituire 200 OK ack entro 5s (use fire-and-forget invece se elaborazione lenta), (3) servire HTML SSR dinamico (detail page Streammy + asset signed proxy URL), (4) download fattura PDF generato dal workflow con filename per-customer. Safety budget: max body 50 MB (oltre conviene S3 redirect), interpolation espressioni timeoutate 1s, header iniezione bloccata (no CRLF in valori).

Invia un'email transazionale via SMTP RFC 5321. Compatibile con qualunque server conforme: Gmail/Workspace (XOAUTH2 supportato via Gmail OAuth node), SendGrid, Mailgun, Postmark, IONOS, Aruba PEC, Office 365, Amazon SES, server self-hosted (Postfix/Exim). Differenza con i sibling: action_send_email = invio singolo con full feature set (CC/BCC, threading, allegati, inline images, DKIM). Per invio TRACKED (open/click) usa action_email_send_tracked; per BATCH mass-mailing usa action_email_send_tracked_batch (worker pool + rate limit). Per Gmail OAuth dedicato vedi pipeline Gmail OAuth XOAUTH2. Feature complete: threading via In-Reply-To/References (reply email ricomincia il thread Gmail/Outlook), priorità X-Priority header, header custom, allegati base64/URL/path (max 25 MB combinati), immagini inline via Content-ID (CID), firma DKIM inline opzionale per dominio terzo (se SMTP non firma). Sicurezza + deliverability: credenziali cifrate via Settings → Email Accounts (vault per-tenant). Pre-flight check SPF/DKIM/DMARC selezionabile (strict/lenient/off) — modalità strict consigliata per cold outreach (senza autenticazione DNS ~60% finisce spam Gmail/Outlook). Header X-FlowForge NON aggiunto (privacy-by-default, nessuna telemetria leak). Audit log su ogni invio con messageId per trace e bounce attribution. Use case: (1) ricevuta acquisto post-checkout PayPal/Stripe con PDF fattura allegato, (2) notifica password reset con link signed expires-2h, (3) reply automatico su PEC ricevuta con threading In-Reply-To corretto, (4) digest settimanale management con dati DB embedded inline. Safety budget: timeout connect 30s, send 60s, ricezione bounce async via IMAP separato (non blocca run), retry 3x exponential backoff su 4xx temporanei + 5xx, NO retry su 5xx permanenti (550 mailbox not found = fail definitivo).

Composizione stringhe da template con segnaposti `{{var}}` interpolati con dati runtime del workflow. È il nodo glue-code per qualunque pipeline che debba COSTRUIRE testo dinamico: oggetto email per ogni destinatario di una campagna, prompt LLM contestualizzato sui dati del trigger, messaggio alert Slack/Telegram con valori da DB, body PDF generato per fattura cliente. Senza questo nodo il workflow autore deve fare string concatenation a mano dentro ogni expression `{{$node...}}` — illeggibile, non riutilizzabile, soggetto a typo. Differenza con i sibling: action_text_template = sostituzione di placeholder in stringa OUTPUT (string in → string out). Per generare struttura JSON output da template usa action_json_extract con jsonpath. Per trasformazione semantica JSON con DSL completo usa logic_transform (JSONata). Per generare HTML/PDF strutturato non text-only usa action_pdf_generate o action_catalog_page. Pensa a action_text_template come al "printf" del workflow. Sintassi template completa: (a) variabile semplice `{{nome}}` pesca da input root; (b) path nested `{{cliente.indirizzo.citta}}` traversa oggetti annidati con dot-notation (gestisce undefined sicuro — un nodo non si schianta su path mancante, restituisce stringa vuota o fallback); (c) fallback inline `{{nome|default Anonimo}}` = stringa "Anonimo" se nome è undefined/null/empty (pattern Mustache); (d) coalescing nested `{{cliente.nome|cliente.username|default Utente}}` = prova in ordine, usa il primo non-vuoto; (e) escape HTML on/off per output destinato a email HTML body (XSS protection) vs prompt LLM (raw). Niente loop o condition inline by design (Cappella Sistina rule: una responsabilità per nodo — per loop usa logic_loop, per condition usa logic_if). Anti-injection: il template è scritto dall'autore workflow (trusted), le variabili pescano da input (possibly untrusted). Quando escapeHtml=true, ogni variabile interpolata passa per `&`/`<`/`>`/`"`/`'` escape → safe per email body HTML che andra\` in client tipo Outlook. Quando escapeHtml=false (default per prompt LLM), nessun escape — l'autore sa cosa fa. Niente escape JavaScript/SQL by design: se serve quello, ci sono nodi dedicati downstream (action_run_js sandboxed, db_query parametrizzato). Performance: parser template compilato lazily al primo run e cachato per (workflow_id, node_id) → run successivi 0.1ms invece di ~2ms parse. Idempotente: lo stesso input produce sempre lo stesso output (no random, no Date.now() — se serve quello usa action_date_format + intermedio). Use case Cappella-Sistina-grade: (1) **personalizzazione oggetto email B2B cold outreach** — template `"{{cliente.nome|cliente.azienda|default Imprenditore}}, abbiamo notato {{evidence_quote|default un'opportunita\` interessante}} sul suo cantiere"` consumato da action_email_send_tracked per personalize-at-scale senza chiamare LLM ogni volta; (2) **prompt LLM dinamico** per agent_classifier che richiede contesto specifico per ogni trigger PEC — `"Classifica questa email del commercialista. Mittente: {{from}}. Subject: {{subject}}. Body primi 500 char: {{body|truncate 500}}. Categorie attese: f24, ricevute, oneri."` (truncate filter futuro); (3) **messaggio Telegram alert SRE** post-workflow-error con context — `"Workflow {{workflow.name}} run #{{run.id}} fallito su step {{failed_node.id}}. Errore: {{failed_node.error.message}}. {{$signedRunUrl}}"` per consentire one-click access al dettaglio run; (4) **body fattura PDF** per action_pdf_generate sections, con interpolazione voci numerate `"Voce {{i}}: {{descrizione}}, importo EUR {{importo|number 2}}"` dentro logic_loop su `righe[]`. Safety budget: timeout parse 100ms per render (anti-ReDoS su template malicious-by-config), profondità nested max 16 livelli (anti-stack-overflow), output cap 1 MB per render (oltre → warning + truncate sicuro), audit log nodeId + template hash + N variabili interpolate (no logging del rendered output per privacy — un template email contiene PII).

Estrazione query-style di valori da oggetti JSON usando JSONPath (Stefan Goessner spec, de-facto standard supportato anche da MongoDB/AWS Lambda/Kubernetes JSON tooling). Pesca campi nested, filtra array via predicate, dedupe wildcard match — tutto senza scrivere codice JavaScript dentro un nodo run-js sandbox. È il "SELECT WHERE" del JSON: un nodo dedicato che rimpiazza decine di righe di traversal manuale. Differenza con i sibling: action_json_extract = SELECT-style con JSONPath (string in → value/array out). Per trasformazioni semantiche complete (map/reduce/group/aggregate inline) usa logic_transform JSONata che è un DSL Turing-complete. Per costruire stringhe template da JSON usa action_text_template. Per filtrare array stream usa logic_loop + filter inline o action_distinct dedicato. Per parsing CSV → JSON pre-extract usa logic_convert. Sintassi JSONPath completa supportata: (a) **root + dot path** — `$.user.email`, `$.items[0].name` (index numerico), `$["chiavi-con-trattino"]` (bracket per key non-identifier); (b) **wildcard** — `$..price` (recursive descent: tutti i campi "price" a qualunque livello), `$.items[*].name` (tutti gli elementi); (c) **slice** — `$.items[0:3]` (primi 3), `$.items[-2:]` (ultimi 2), `$.items[::2]` (step 2 — pari indici); (d) **filter predicate** — `$.items[?(@.qty>0)]` (righe con quantità positiva), `$.items[?(@.price>100 && @.category=="premium")]` (AND boolean), `$.items[?(@.tags.includes("hot"))]` (method chain JS sintaxa); (e) **union** — `$.items[0,2,5]` (cherry-pick indici), `$..["name","title"]` (multipli field name); (f) **expression compute** — `$.items.length` (lunghezza array nativa). Output semantica: se la query matcha 0 risultati → output `null` (NON throw, downstream può branchare con logic_if su null check). Se matcha 1 → output del valore scalare/oggetto. Se matcha N → output array. Modalità configurabile "always-array" forza wrap in array anche per match singolo (utile a valle di logic_loop che pretende array). Performance: parser JSONPath compilato e cachato per (workflow_id, node_id) — run successivi 50µs. Su payload >10 MB il parser usa streaming JSON (Oboe-like) per evitare full parse in memoria — un sync ERP che ritorna 100k righe non OOM il container. Use case Cappella-Sistina-grade: (1) **estrazione dati API utente** dopo trigger webhook OAuth callback — query `$.data.user.email` su response provider per persistere in DB users, (2) **filtro righe import Excel** dopo action_xlsx_parse — query `$.rows[?(@.qty>0 && @.totale_eur<10000)]` per selezionare ordini validi prima di logic_loop downstream, (3) **estrazione prezzi nested** payload e-commerce vendor che restituisce JSON con varianti annidate per colore/taglia — query `$..varianti[*].price` per audit listino completo cross-categoria, (4) **pre-processing payload webhook Stripe** prima di logic_switch su event type — query `$.type` per chiavi top-level + `$.data.object.id` per business key, evita JSONata overkill per single-field pick. Safety budget: timeout esecuzione query 100ms (anti-malicious-JSONPath con backtracking esponenziale), max recursion depth 32 livelli, max output size 10 MB (oltre → truncate con warning), input JSON parse failure → null + audit error (no crash).

Formatter enterprise multi-locale per date e timestamp con focus sul formato italiano standard usato in fatturazione, comunicazioni cliente, generazione documenti contrattuali. Accetta input in formati eterogenei (la realtà dei sistemi business mai puliti): timestamp ISO 8601 strict ("2026-05-23T10:30:00Z" con timezone esplicita, formato preferito dei DB modern + REST API), Date object JavaScript nativo (passato da nodi upstream come $date.now), formato italiano comune "23/05/2026" o "23-05-2026" anche con ora "23/05/2026 10:30:00" (formato che arriva da spreadsheet Excel italiani con configurazione locale default), formato US "05/23/2026" (rilevato per separator e contesto), stringa speciale "now" per la data corrente al momento dell'esecuzione del nodo. Parsing fallback intelligente: se nessun pattern matcha, prova ad usare new Date(input) di JavaScript come last resort (parser permissivo che gestisce casi inattesi come "May 23 2026 10:30 AM"). Output con doppia struttura per massima flessibilità downstream: { formatted (stringa nel formato target configurato), iso (sempre ISO 8601 normalizzato per audit + storage DB), components: { day, month, year, hour, minute, second, dayOfWeek (1-7), dayOfWeekName ("lunedì", "martedì", ...), monthName ("gennaio", "febbraio", ...), quarter (1-4), weekIso (settimana ISO 1-53) }, timezone (IANA tz database), isWeekend, isPast, isFuture, daysFromNow (signed integer per ordering + ranking) }. Locale-aware Intl.DateTimeFormat: supporto pieno per "it-IT" (default — "23 maggio 2026", "lunedì 23 maggio"), "en-US", "en-GB", "de-DE", "fr-FR", "es-ES". Custom format string via tokens stile Moment.js (DD/MM/YYYY, dddd D MMMM YYYY, HH:mm:ss, ecc.) per pattern specifici di documento legale o corrispondenza istituzionale. Use case classici della pipeline italiana: convertire timestamp DB (created_at UTC) in stringa italiana "23 maggio 2026" per generazione email transazionale "Il suo ordine del {{date}}"; calcolare scadenze fatturazione enterprise da emissione +30/60/90 giorni con verifica weekend (sposta a lunedì successivo in alcuni casi); raggruppare eventi per giorno/settimana/mese in summary cron per dashboard analytics; generare nomi file con data per backup quotidiani ("backup-2026-05-23.tar.gz"); estrazione campi separati (year, quarter) per fiscalizzazione (esercizio amministrativo italiano 1/1-31/12 ma con lookback 18 mesi per dichiarazioni IVA).

Arricchitore enterprise specializzato per righe ordine estratte da PDF fornitore, che gestisce il pattern semantico "descrizione su due righe" tipico dei documenti di fornitura B2B italiani: la prima riga contiene il codice articolo + descrizione principale ("ROT-COIL-220V Bobina elettrica"), la seconda riga sottostante porta dettagli tecnici specifici dell'item ("Voltaggio 220V AC 50Hz, IP65, certificata CE") che NON appartengono ad una nuova riga ordine ma sono qualificazione del codice precedente. Senza questo arricchimento, il parsing PDF naïve crea N+1 righe (1 per codice + 1 per descrizione) confondendo il downstream ERP import. Il nodo applica le regole configurate per identificare quali codici beneficiano di sub-description e li fonde nella product_description del corretto record line, eliminando le righe descrizione spurious. Logica intelligente di matching: solo i codici che corrispondono ai pattern regex configurati ottengono enrichment (es. "^ROT-[A-Z]+-[0-9]+V$" per matchare codici della famiglia ROT-COIL-220V/ROT-VALVE-380V/ ROT-MOTOR-110V), gli altri restano invariati. Esclude esplicitamente note generiche commerciali tipo "A saldo Vs. ordine n.X", "Spese accessorie", "Pagamento a 60gg fine mese", "IVA esposta" — testi che non sono descrizioni di prodotto ma metadata fiscali/commerciali. Customization rich delle regole: il customer admin definisce N pattern di matching con relativa policy di merge (concatenazione con separator " - ", append parentesi "(...) ", overwrite condizionato se la sub-description è più informativa, skip per pattern blocklist note generiche). Output: stesse lines del input ma con product_description arricchita per export downstream + lines.removed[] che traccia le righe descrizione fuse + audit log delle merge applicate per debug. Use case business reali da clienti enterprise: arricchire righe ordine estratte da PDF fornitore prima dell'export ERP (es. Sage X3, TeamSystem Polyedro, Zucchetti Ad Hoc) per evitare cleanup manuale del controller); integrare codici prodotto specifici per vertical industriale (Rotork bobine, voltage spec, IP rating per impiantistica), automazione automotive (codici OEM), elettromedicale (CND+ATC code); normalizzare descrizioni multi-riga di fornitori legacy in singolo campo searchable per data warehouse analytics (es. "fornitore X usa 2 righe descrizione, fornitore Y usa 3, fornitore Z usa 1 — normalizzo tutti a 1"); pre-processare ordini Excel ricevuti da clienti che mantengono ancora il "modello a due righe Excel" cartaceo migrato a digitale; harmonization di anagrafica prodotti tra subsidiary di gruppi multinazionali che ognuno ha format suo.

Scarica una pagina web e ne estrae SOLO il testo leggibile come stringa pulita per pipeline AI. Strip aggressivo via cheerio: rimuove <script>, <style>, <nav>, <footer>, <aside>, commenti HTML, white-space ridondante. Output ottimizzato per LLM prompt (token economy) o storage searchable, non per parsing strutturato. Differenza con i sibling: action_fetch_url = quick text-only extraction zero-config (1 URL → 1 stringa). Per HTML completo con header browser-like + cookie jar usa action_web_fetch_advanced (più opzioni, più verbose). Per parsing strutturato con CSS selector usa action_html_select. Per scraping SPA JS-heavy usa action_browser_render (BYO). Per orchestrazione multi-stage adaptive con AI extract usa action_scrape_smart. Limiti by-design (no surprise pricing/abuse): max 100 KB output (~25k token Claude — oltre il quale conviene split + summarize), timeout 10s connect+read, follow redirect max 5 hop, content-type filter (accetta solo text/html, application/xhtml — un binary mascherato da HTML viene rifiutato). Sicurezza: SSRF-guarded via @flowforge/safe-fetch (blocca 127.0.0.1, 10.x/172.16-31/192.168.x, link-local 169.254.x, IPv6 fc00::/7), User-Agent identifica FlowForge per audit-friendly upstream (rispetta robots.txt — un sito può bloccarci by-design). Audit log su ogni fetch con url + status + bytes per forensics e cost monitoring. Use case: (1) iniettare contenuto landing-page competitor in prompt LLM per analisi posizionamento, (2) pre-processare FAQ pubblica della propria docs per indicizzazione RAG con embedding BGE-M3, (3) raccogliere testo articolo news per pipeline agent_summarizer + agent_classifier, (4) verifica SEO che la propria pagina prodotto contenga keyword target (text density check). Safety budget: cap 100 KB protegge da abuso bandwidth, timeout 10s previene workflow hang, SSRF cap previene attacchi internal-network reconnaissance.

Ricerca sul web con cascata 2-provider per high-availability senza vendor lock-in. Primary: Brave Search API (free tier 2k query/mese, ottima qualità per IT/EU SERP — richiede env BRAVE_SEARCH_API_KEY in vault tenant). Fallback: DuckDuckGo HTML scraping (gratis always-on, nessuna key, qualità leggermente inferiore ma sempre disponibile). Switch automatico su 429/5xx Brave. Differenza con i sibling: action_web_search = SERP-style {title, url, snippet} structured (entry point discovery). Per cercare aziende verticali con LLM query expansion + anti-directory blocklist usa action_company_search (lead-gen). Per cercare email su un dominio già noto usa action_contact_discovery (crawler multi-path). Output unificato indipendente dal provider: array di {title, url, snippet} normalizzato — un workflow downstream non deve sapere se sta consumando Brave o DDG. Cache LRU in-memory 5min per query identiche evita doppi hit su workflow batch ripetitivi (es. monitor giornaliero su 100 keyword). Locale-aware: parametro country (IT/US/DE/...) influenza ranking (Brave) e localized HTML (DDG). Lingua auto-derivata dal locale tenant. Safe-search configurabile (off/moderate/strict). Use case: (1) discovery siti vendor per cold outreach B2B con keyword verticali (input a action_company_search downstream), (2) raccolta news settimanale su parole chiave brand per digest management, (3) verifica menzioni competitor su SERP (alert se ranking scende), (4) primo step di pipeline RAG che poi fetcha top-N pagine con action_fetch_url + indicizza. Safety budget: cap 50 risultati per query, timeout 10s per provider con fallback istantaneo, audit log con provider used + query hash + result count per cost monitoring Brave.

Estrattore enterprise di indirizzi email da HTML — il pattern è universalmente noto come "email harvesting" ma in versione legitimate-only per use case authorized: lead generation B2B da siti aziendali pubblici, contact discovery di referenti commerciali dichiarati pubblicamente sui siti corporate, verifica del proprio sito che renda contatti accessibili senza JavaScript per accessibility, audit di siti cliente per compliance privacy (pre-GDPR pages che leakano email non protected). Cinque strategie parallele di parsing che coprono il 95%+ dei modi in cui le email sono encoded nel HTML reale: (1) mailto: links — il pattern canonico HTML <a href="mailto:[email protected]">, semplice da parsare via querySelector ma rappresenta solo il 40% dei casi reali perché gli admin web tipicamente nascondono le email per anti-spam; (2) Cloudflare anti-spam decoder — Cloudflare offre la feature "Email Address Obfuscation" che sostituisce le email con span data-cfemail="abc123" e un JavaScript runtime che decodifica al caricamento — il nodo implementa il decoder XOR algorithm di Cloudflare per leggere le email server-side senza eseguire JS; (3) HTML entities decode — l'admin sostituisce @ con &#64; e . con &#46; per evitare crawler naïve (es. mario&#64;acme&#46;com) — il nodo decoda le entities e poi applica regex match; (4) Regex plain — match standard RFC 5322 simplified su testo plain decoded (vari pattern fallback per edge case come email con plus addressing [email protected]); (5) Obfuscation testuale humano — "mario [at] acme [dot] com", "mario AT acme DOT com", "mario(@)acme(.)com" — pattern usato da admin che pensano "i bot non sanno parsare questo" ma il nodo li riconosce. Filtri noise enterprise per evitare false positive che inquinerebbero il dataset: blocklist di domini noti non-deliverable (example.com, test.com, localhost, domain.tld template placeholder), prefix blocklist (noreply@, no-reply@, donotreply@, mailer-daemon@, postmaster@ — generic non-personal endpoint), regex pattern blocklist per UUID-like local parts (es. 0a1b2c@... che è tipicamente tracking ID non email reale). Output: email primaria (la più probabile da contattare — ranking euristico basato su position nel documento header > body, presence in section "Contatti" vs footer generic, length del local-part) + lista completa con confidence score 0-1 per ognuna (mailto = 1.0, regex plain = 0.7, obfuscation = 0.85, entities = 0.95, cloudflare = 0.92). Use case: lead-gen B2B con contact discovery sistematico da siti aziendali (loop su sitemap_crawler URL → fetch pagina /contatti or /chi-siamo → harvest emails); raccolta indirizzi pubblici per import CRM autorizzato (es. la lista pubblica dei broker assicurativi del proprio settore); verifica del proprio sito contatti che renda email leggibile senza JavaScript per audit accessibility WCAG 2.2; deduplica email da pagine staff/team enterprise prima di outreach per evitare di scrivere al CEO + CTO + HR + Operations Manager dello stesso azienda con stessa proposta; signal di "is this still active" pre-outreach (se il dominio non risponde con email = candidato per skip senza sprecare token cold email).

Validatore enterprise di deliverability email che esegue DNS-level checks per stabilire se un indirizzo email è plausibilmente deliverable PRIMA di inviare un messaggio reale che sarebbe bouncato — pattern critico per protezione reputation IP SMTP del tenant (provider SaaS come Mailchimp/SendGrid/Mailgun/SES penalizzano le account che bouncano > 2-5% del traffic con throttling, sospensione, ban del subdomain sending). Verifica multi-livello complementari per coverage completa: (1) MX record lookup via DNS query asincrona — il record MX (Mail eXchanger) del dominio dichiara i server SMTP autoritativi del dominio per la ricezione email (es. acme.com MX points a 10 mail.acme.com); l'assenza di MX record è strong signal di dominio non email-capable; (2) Fallback A record check (RFC 5321 compliance) — se MX manca, il client SMTP è tenuto da specifica a tentare il A record (IP del dominio) — il nodo replica questa logica per parità di comportamento col mailer reale; (3) Disposable email detection — match contro blacklist di 250+ provider noti di temporary email (mailinator.com, tempmail.org, 10minutemail.com, guerrillamail.com, throwaway.email, ecc. inclusi i pattern italiani come e4ward.com e mail-temporaire.com) che gli utenti usano per signup form per evitare spam — lead da questi domini sono generalmente low-quality con conversion rate < 1% e LTV trascurabile; (4) Role-based vs person email detection — distingue tra email "personali" ([email protected], firstname.lastname@ pattern enterprise) e email "ruolo" (info@, support@, sales@, admin@, contact@, noreply@, postmaster@) — utili per use case sales outreach (preferiamo person email per personal connection) ma anche per use case ticketing (preferiamo role email per garantire ricezione anche se la persona specifica è in ferie). Output rich: { isValid (bool composite finale), confidence (score 0-100 derivato da signal weighting), hasMx, hasA, mxRecords (lista di server SMTP risolti per audit), isDisposable, disposableProvider?, isRoleBased, rolePrefix?, deliverableConfidence, recommendations? (suggerimenti azionabili come "questa email è role-based, considera contact person") }. Cache LRU 5min × 5000 domini per evitare DNS query ripetute su stesso dominio (workflow batch su 1000 lead di 100 aziende diverse → solo 100 DNS query, non 1000) — overhead trascurabile in batch. Use case: filtrare lead di bassa qualità prima di una campagna outreach commerciale (filter isValid=true AND isDisposable=false AND isRoleBased=false → focus su persone reali); validare email signup form per ridurre bounce rate Mailchimp/SendGrid/SES (rifiutare submission con isValid=false o isDisposable=true al moment del POST per non inserire mai in DB); flaggare domini disposable in registrazione tenant SaaS (red flag per fraud detection — trial fraudsters tipicamente registrano con disposable email); audit mensile della propria lista mailing per pulizia indirizzi morti accumulati nel tempo (loop su lista + validate_mx + delete o flag i dead → recupera reputation score IP); pre-flight check su importazione CSV anagrafica cliente da altro sistema legacy.

Lead scorer deterministico enterprise — calcola un punteggio normalizzato 0-100 di qualifica per un lead B2B basato sull'analisi del contenuto testuale della pagina web target (la home, about, products page del prospect tipicamente). NO LLM nel core scoring: pure function rule-based che pesa keyword positive (industry match, signal di product fit, tier value della company), penalizza keyword negative off-topic (settori che non sono il nostro target), bonus per criteri demografici (tier country EU/USA più valore vs tier emerging market, dimensione company stimata da signal della pagina). Stesso input → SEMPRE stesso score (deterministica, audit-friendly, no LLM drift su run successive) — pattern critico per clienti enterprise che richiedono explainability del scoring per compliance (GDPR art. 22 dichiara che individui hanno il diritto di non essere oggetto di decisioni automated che li affectano significantly senza explainability), e per QA che vogliono testare il scoring senza flakiness. Profili pre-set per industry vertical (configurazione del weighting via keyword positive + negative + country tier mapping): marine-thrusters (default per il customer pilot Arifin/HYSY che usa il nodo per scoring di buyer marine thrusters), real-estate (positive: villas, properties, deals; negative: short-term-rental), tech-saas-buyer (positive: enterprise, integration, API, automation; negative: consumer mobile games), e ulteriori 8 verticals pre-configurati. Override completo dei pesi possibile da config per personalizzazione tenant-specific. Algoritmo del scoring (transparent): base score 50, + N punti per ogni keyword positive matched (weighting per importance: brand names = 15, category keywords = 8, generic positive = 3), - N punti per ogni negative match (off-topic categorical = 20, secondary negative = 5), bonus country tier (tier1 EU/US/UK/CA = +10, tier2 ANZ/JP = +5, tier3 emerging = 0, blocklist countries con compliance issue = -30), final clamp [0, 100]. Output rich con audit trail: { score (0-100 final), matchedPositiveKeywords (list specifica per debug + transparency), matchedNegativeKeywords, countryTier, countryDetected, profileUsed, breakdown: { base, positives, negatives, countryBonus, total } }. Use case: qualificare lead inbound prima di assegnare a un sales rep (score < 50 → archive cold; 50-69 → nurture marketing track; 70-100 → high-priority assigned to senior AE); priorizzare la queue di cold outreach mostrando solo score ≥ 70 (no spending di tokens per email personalizzate su low-quality lead); filtrare lead da scraping pubblico (sitemap_crawler + harvest + score → filter per non sprecare email outreach su off-topic detected); audit-friendly scoring richiesto da clienti enterprise per non-AI black-box GDPR-compliant; A/B testing di criteri di qualifica con changeover profile rapido senza retrain ML model.

Generatore enterprise di personalizzazioni email AI-powered per cold outreach commerciale — la primitiva che trasforma sequence di email mass-mailing fredde "Ciao, abbiamo un prodotto per te" in messaggi 1-to-1 che fanno apparire la comunicazione manuale e cura del prospect specifico (reply rate aumentano 3-5x rispetto a template generico in studi A/B di sales outbound enterprise). Genera 1-2 frasi personalizzate da iniettare nell'opening del messaggio cold che CITINO una caratteristica REALE e specifica dell'azienda destinataria — estratta dal content del loro sito web reale che il workflow ha scaricato upstream (action_web_fetch_advanced sulla home/about/products del prospect). Anti-hallucination check obbligatorio enterprise: l'evidence_quote (la frase originale dal sito che ha ispirato la personalizzazione) DEVE essere substring esatta del content originale fornito al nodo — se il LLM provasse a inventare ("la vostra certificazione ISO 9001 ottenuta nel 2024" quando NON è nel sito), il check fallisce e il nodo ritorna fallback graceful (saluto generico safe-default) invece di mentire al prospect. Pattern di tutela reputational vs LLM hallucination noto, critico per B2B sales dove un dato sbagliato distrugge la deal pipeline. Multi-lingua native (14 supportate): italiano, inglese, spagnolo, francese, tedesco, portoghese, olandese, danese, svedese, norvegese, finlandese, polacco, ceco, rumeno — auto-detect dalla lingua del content website oppure override esplicito per outreach internazionale targeted (es. cold outreach a distributori italiani che vendono prodotti tedeschi, language=de per matching il vendor expectation). Cache 1h per content_hash per evitare LLM calls ridondanti su stesso target: se il workflow itera su 100 lead della stessa azienda (es. team Sales Outreach che colpiscono CTO+CFO+CEO stesso prospect), il LLM call avviene UNA volta e tutti i 3 messaggi riusano la same personalization base — risparmio 90%+ sui token Liara/BYOK. Fallback gracioso multi-livello: LLM fail (timeout, rate limit, content moderation) → opener generico safe-default "Salve {{firstName}}, le scrivo perché credo {{company}} potrebbe..."; content troppo corto (< 100 char) → skip personalization e usa opener default; content > 4000 char auto-truncate mantenendo i primi 2000 + ultimi 2000 (capture intro + footer aziendale che contiene tipicamente la signal value). Output: { personalizedOpener (1-2 frasi pronte da iniettare nel template email), evidenceQuote (la frase originale del sito che ha ispirato — utile per debug + audit), language, contentHash, cacheUsed, fallbackReason? }. Use case: cold outreach B2B con apertura personalizzata da fatto vero del sito target (3-5x reply rate vs template generic); follow-up post-form con riferimento a sezione del sito visitata che il lead ha mostrato interesse (tracked dal form analytics); reply-handling che cita prodotto specifico chiesto dal lead in reply precedente; multi-lingua automatic per outreach internazionale targeted di settori specifici (es. outreach a buyer tedeschi del settore food italiano export); ABM (Account Based Marketing) per high-value enterprise account con messaggi totally tailored.

Mini-agente enterprise di contact discovery che parte da un URL homepage di una azienda e NAVIGA sistematicamente il sito web alla ricerca della email business più probabile, simulando il pattern di ricerca manuale che un sales rep usa quando esamina il prospect per identificare il contact point. Pipeline di navigation strutturata multi-fase: (1) crawl della homepage primaria con extraction di tutte le link visibili nel header/footer, (2) ricerca automatic delle "smart pages" tipiche per contact information — /contatti /contact /contact-us /chi-siamo /about /about-us /team /staff /impressum (la pagina obbligatoria per legge tedesca con dati aziendali) /contattaci /legal /privacy con varianti multi-lingua del path, (3) parse del sitemap.xml ufficiale per discovery pagine dedicate non linkate dalla home, (4) fallback strategy via DuckDuckGo search restricted al dominio "site:acme.com contact email" per trovare pagine nascoste dalla navigation principale. Vocabolario multi-lingua nativo per riconoscere le label di pagine "contatti" in 14 lingue diverse: italiano (Contatti, Contattaci, Chi siamo, Lavora con noi), inglese (Contact, Contact Us, About, Team), tedesco (Kontakt, Impressum — obbligatorio per legge DE, Über uns, Team), francese (Contact, À propos, Équipe), spagnolo (Contacto, Acerca de, Equipo), portoghese (Contato, Sobre, Equipa), olandese (Contact, Over ons), greco (Επικοινωνία, Σχετικά), scandinavi svedese/norvegese/danese/finlandese/islandese, croato (Kontakt). Coverage tipica EU + USA + qualche emerging market. Rispetta robots.txt scrupolosamente (un publisher può escludere /admin/ /login/ e qualsiasi path che NON vuole sia crawlato — il nodo skipa quei path), rate-limit 2 req/sec per host (good-citizen standard per non risultare aggressive scanner che il publisher considererebbe abuse), cache LRU 7 giorni per host normalizzato (workflow batch su 1000 lead della stessa azienda non ricrawlano la stessa azienda 1000 volte). Zero LLM dependency nel core algorithm — questo è un IMPORTANTE feature: il crawl è deterministico (stesso input → SEMPRE stesso output per audit + reproducibility), no costo per-token, no exposure di dati PII del prospect a provider LLM esterni (GDPR-friendly), no dipendenza da API rate-limit di LLM esterni. Il LLM si può aggiungere downstream per personalization come opt-in. Output: email primaria (la più probabile da contattare — typically person email > role-based info@), tutte le email trovate con confidence score, pagina specifica dove trovata (per audit trail), lista di path tentati (per debug se non trovate). Use case: lead-gen B2B con discovery deterministica zero-LLM-cost (loop su 1000 company URL → contact discovery → email validation MX → personalization → outreach); arricchimento CRM partendo solo dal dominio aziendale (un sales rep ha solo "@acme.com" → workflow → email reale del decision-maker); verifica audit-friendly che la propria pagina /contatti renda email crawlable per accessibility e SEO; outreach internazionale multi-lingua senza traduzioni manuali (German DACH market via Impressum detection); pre-flight check di lead lists comprate da broker (verifica che gli URL aziendali del lead db hanno effettivamente contact reali → cleansing del dataset acquistato).

Discovery enterprise di URL di AZIENDE REALI per cold outreach B2B — la primitiva per costruire seed list di prospect target da zero senza dover comprare database statici come ZoomInfo/Apollo/SalesNavigator. Risolve il problema #1 del cold outreach moderno: trovare le aziende right-fit per il proprio prodotto nel territorio target, evitando il rumore di directory aggregatori (yellowpages, paginegialle, similarsites), blog content marketing che parlano del settore ma non ne sono parte attiva, link farm SEO che inquinano i risultati Google. Pipeline multi-stage avanzata: (1) LLM query expansion — l'utente passa una query high-level "cantieri navali Croazia 20-50m" e il LLM espande in 5-10 query specialized che catturano sinonimi industry ("shipyard Hrvatska", "yacht builders Croatia", "boat manufacturers Dalmatian coast", "production lines vessel 20m"), pattern per coverage che pura keyword search miss; (2) multi-source search parallel su 4 search engine indipendenti (Exa.ai per semantic neural search optimized per discovery, Tavily AI per recente fresh content, Brave Search per anti-Google bias, DuckDuckGo per privacy + independent results) — l'unione dei result set dei 4 sources è più completa di qualsiasi singolo; (3) anti-directory blocklist — filter post-processing che rimuove i top 200 directory/aggregator noti (yelp.com, yelp.it, paginegialle.it, europages.com, kompass.com, ecc.) che otherwise inquinano i result; (4) HEAD validation — quick HEAD request per ogni URL trovato per verificare che il sito risponde 200 (no 404/410 dead links, no 5xx down servers); (5) de-dup intelligente che matcha URL paths simili e domini canonical (www.acme.com vs acme.com). Output: array di { url, domain, title (dalla SERP), description (snippet), boost_factors (lista dei signal positivi che hanno ranked questo result), source (quale dei 4 search engines lo ha trovato), confidence } — ranking finale weighted per source di trust + match strength + freshness. LLM-agnostic per query expansion: lo step LLM usa il provider configurato del tenant (Liara Qwen3 self-hosted default zero-cost, oppure Anthropic Claude/OpenAI GPT/Gemini via BYOK). Use case: lead-gen B2B su nicchia verticale specifica (es. "produttori di pannelli fotovoltaici Sicilia 20MW+", "studi commercialisti specializzati in cripto-asset Milano"); discovery competitor nel mercato target prima di un lancio prodotto (mapping landscape competitivo); seed list per campagne ABM (account-based marketing) high-touch con messaggi ultra-customizzati per ogni account; prima fase di una pipeline downstream che poi arricchisce con contact-discovery (chi sono i decision-maker?) + email-validate-mx (sono email deliverable?) + personalization AI; analisi competitiva con scoring comparativo (chi sono i top 50 player del nostro mercato e dove sono attivi).

Eseguito enterprise di una regola del sistema "Salute Dati" (Janitor) come step di un workflow business — il pattern data-quality-as-code di FlowForge che permette di automatizzare le pulizie ricorrenti del database del cliente (dedup duplicati, normalizzazione campi, anonimizzazione GDPR, rimozione record obsoleti, consolidamento anagrafica) senza dover scrivere SQL manualmente né rischiare errori distruttivi su tabelle di produzione. Le regole Janitor sono definite dall'admin del tenant nell'interfaccia "Salute Dati" dell'editor (UI no-code con builder visuale di trasformazione) e queste sono semplicemente eseguite da questo nodo come step di un workflow più ampio. Funziona su QUALUNQUE database collegato al sistema FlowForge — supporta i 5 dialetti SQL principali usati in produzione: SQLite (default del runtime tenant + databases del cliente locali), PostgreSQL (il preferred per produzione enterprise, supporta features avanzate come window functions e CTE), MySQL/MariaDB (l'altro tier-1 RDBMS open-source comune in legacy LAMP stack), Microsoft SQL Server (per integrazione con enterprise Windows infrastructure), DuckDB (analytic columnar in-process database per workflow di analytics ETL pesanti). Il nodo astrae le differenze di syntax SQL tra i dialetti — l'admin definisce la regola UNA volta e funziona su qualsiasi DB collegato. Due modalità operative complementari per coprire i pattern d'uso: (1) singola — applica una specifica regola identificata per nome o id, utile quando il workflow è focused su una pulizia specifica (es. "dedup_customers" eseguito post-import bulk); (2) ciclo — itera ed esegue TUTTE le regole abilitate del database target nell'ordine definito dall'admin (priority-based), pattern per workflow di "pulizia generale notturna" che fa healthcheck completo. Report dettagliato per audit + compliance enterprise: ogni execution produce un report strutturato di cosa è stato fatto (record affected, righe inserted/updated/deleted, byte freed) salvabile come allegato email al CFO/DPO/admin per traceability; opzionale rollback transaction (tutte le modifiche in una transaction SQL — se qualcosa va male il rollback automatico ripristina lo stato pre-execution evitando dati corrotti). Use case business reali: pulizia notturna duplicati clienti CRM via trigger_cron daily 03:00 + action_janitor_cleanup mode=cycle (rilevamento duplicati per email/VAT + consolidamento campi nel master record + soft-delete dei duplicati con audit log); consolidamento contatti dopo import bulk da CSV legacy con anagrafica sporca (run manuale post-import del workflow di onboarding cliente); job scheduled di anonimizzazione record GDPR scaduti (10 anni di retention superati per dati fiscali, 12 anni per atti societari — la regola Janitor sostituisce campi PII con hash deterministic preservando la chiave per analytics aggregati); audit-friendly cleanup con report scritto per compliance ISO 27001 che richiede documentazione delle data quality operations periodiche.

Recupero HTTP enterprise-grade per web scraping LEGITTIMO (monitoraggio propri siti, news aggregation, price comparison sui tuoi prodotti, integrazione siti aziendali). Differenze vs HTTP Request standard: header preset browser-like (un click per "Chrome desktop"/"iPhone Safari"), Referer/Origin auto-derivati, cookie jar persistente, retry exponential su 408/429/5xx, response format auto-detect (HTML/JSON/Binary). NON USARE per: scraping siti di terzi senza autorizzazione, evasione paywall, accumulazione contenuti copyright. Block-list domini noti pirateria attiva. Tutti i request loggati in audit_log. Use case: (1) monitoraggio uptime propri endpoint con cookie session, (2) integrazione API vendor partner che richiede browser headers + Referer, (3) ingest pagine news per aggregator interno, (4) price comparison del proprio catalog su marketplace autorizzati.

Parser dichiarativo enterprise di HTML usando selettori CSS standard — l'estrattore "scraper-friendly" che permette al business user di definire una mapping semplice "fieldName → CSS selector" e ottenere in output un object JavaScript strutturato con tutti i campi richiesti, evitando il dover scrivere codice JavaScript imperative con querySelector chain + manual error handling. Il pattern è analogo a quello di Jsoup (Java), Cheerio (Node.js), Beautiful Soup (Python con CSS support) — tutti utilizzati in produzione da progetti enterprise di scraping responsabile per parsing di HTML payload già scaricato da fetch upstream o action_web_fetch_advanced. Coverage piena dei selettori CSS3 specification: tag selector (h1, p, article), id selector (#main-content, #checkout-form), class selector (.product-card, .price-tag), attribute selector ([data-sku], [href*="amazon"], [type="email"]), pseudo-class selector (:nth-child(2n), :first-child, :last-child, :not(.disabled), :has(.discount)), combinator complessi (descendant " ", child >, adjacent sibling +, general sibling ~) — l'utente può copy-paste qualsiasi selettore dal DevTools del browser e funziona. Per ogni campo configurabile la strategia di extraction del valore: (1) "text" default — extract solo il textContent visibile (HTML stripped, gli spazi normalizzati), pattern per estrarre testo human-readable; (2) "html" — extract il innerHTML del element matchato (preserva il markup interno per cases come "description con tag <strong> da preservare"); (3) "attr" con parametro attrName — extract il valore di uno specifico attribute HTML (es. attr=href per link URL, attr=src per immagini, attr=data-sku per identifier nascosti in data-attribute, attr=value per form input default value); (4) "list" — extract un array con il valore (testo o attr) di TUTTI i match del selector invece di solo il primo, pattern per liste enumerabili tipo tutti i titoli di un'archivio blog o tutti i prezzi in una pagina di confronto product. Sicurezza enterprise: NO JavaScript execution sul HTML (il parser è pure HTML — no DOM-level events, no fetch, no XHR), completely safe per processing di HTML untrusted da source web arbitrari senza rischio di XSS o code injection. Output strutturato: { extracted: { fieldName1: "value", fieldName2: ["arr", "of", "values"], ... }, totalFieldsExtracted, totalFieldsMissing, performance: { selectorsMatched, processingTime } }. Use case: parse listing prodotti proprio e-commerce per export Excel quotidiano (cron daily + fetch del catalog page + html_select per scraping di SKU+name+price+stock+image_url → xlsx_build → send_email al merchandising team); estrazione di titolo/prezzo/disponibilità da pagine prodotto competitor monitorate per pricing intelligence; raccolta sistematica di righe da tabella HTML di report istituzionale (es. ISTAT, AGENAS, Banca d'Italia che pubblicano stats in tabelle senza open data CSV equivalent); ingest content blog per RAG/embedding pipeline partendo dalla homepage del blog (extract title+author+date+content_html di ogni post per indicizzazione knowledge base AI); parsing di SERP page (Google/Bing search result) per analisi SEO competitive intelligence.

Estrattore enterprise specializzato per il pattern moderno di reverse-engineering web: parsing di variabili JavaScript inline embedded direttamente nei blocchi <script> del HTML server-rendered, senza eseguire il JS — pattern fondamentale per accedere ai dati strutturati che molte SPA, framework SSR (Next.js, Nuxt, SvelteKit, Remix), CMS embedded player (YouTube, Vimeo, Streammy, Twitch embeds), piattaforma sport (DAZN, Sky, ESPN) e similar mettono come state pre-popolato in window.X = {...} per consumo client-side, anziché esporre un'API REST/GraphQL pubblica documentata. Questi dati sono "pubblici" nel HTML response del server ma non in JSON proper, e parsarli con browser+JS execution (via Puppeteer/Playwright) sarebbe overkill e 100× più lento + più costoso. Esempio canonico di use case: pagina video player con il tag <script>window.player = { src: "https://cdn.example.com/segments/master.m3u8", expires: 1730000000, drm: false, region: "EU" }</script> → il nodo estrae programmatic src + expires + drm + region senza dover lanciare Chrome headless + parse di DOM events. Robust contro le varianti di sintassi JavaScript reale (codice JS scritto da developer veri ha format eterogenei tra publisher e a volte tra deploy del stesso publisher): quote singole o doppie intercambiabili (\"src\" vs \'src\'), chiavi object con o senza virgolette (var = { src: ... } vs var = { \"src\": ... }), valori numerici o stringa o boolean o null, trailing comma permessi (style JS modern), commenti inline ignorati safely, espressioni semplici tipo Date.now() o {a: b} nested object. Il parser è AST-style con context window per evitare false match. Critical security feature: NON esegue mai il JavaScript estratto (no eval, no Function(), no vm) — il parsing è puramente lexical/syntactic stile SAX parser, completamente safe per processing di HTML untrusted da source web arbitrari senza rischio di code injection o sandbox escape. Output: { extracted: { variableName1: { value, type (object|array|string|number|boolean|null), scriptIndex } }, totalExtracted, scriptsAnalyzed }. Use case: estrarre URL video reali da player embed di service streaming come Streammy/vixcloud/sweetpixel che mettono lo stream URL in window.config = {} prima di costruire il player visuale; ingest del state SSR (window.__INITIAL_STATE__ del Redux pre-popolato, window.__APOLLO_STATE__ di Apollo Client) di pagine React/Vue server-rendered per scraping di e-commerce moderni; recovery di dati config da landing pubbliche di company sites (es. <script>window.analyticsConfig = {apiKey:"...", endpoint:"..."}); reverse-engineering di payload Inertia.js (used dai siti Laravel modern) o Next.js __NEXT_DATA__ (il payload server-side che React idrata client-side — contiene tipicamente tutti i dati della pagina pronti per consumo); ingest dati da broadcaster sport che fanno embed di player con metadata evento/lineup/stat in window.payload.

Estrattore enterprise di dati strutturati da testo non strutturato usando regex con FALLBACK CHAIN — il pattern critical per parsing robusto di pagine HTML/JSON/log/PDF che cambiano formato leggermente nel tempo (cambi di quote single→double, variazioni spacing, ordine random degli attributi). La tipica fragilità del regex singolo che funziona oggi e si rompe domani al primo deploy del publisher viene mitigata permettendo di definire 2-5 pattern alternativi per ogni campo target: il primo regex che matcha vince la priorità, gli altri sono fallback se il primo fallisce. Esempio canonico di estrazione di token da pagina web con fallback chain robusta: pattern 1 token:\\s*"([^"]+)" (formato JS object con virgolette doppie), pattern 2 token:\\s*\'([^\']+)\' (formato JS object con virgolette singole — variant comune per i developer che preferiscono single quote in JavaScript), pattern 3 "token":\\s*"([^"]+)" (formato JSON proper con key tra virgolette come standard RFC), pattern 4 \\btoken\\s*=\\s*([a-z0-9_-]{20,})\\b (formato URL query string o env var assignment senza virgolette per i token di formato Crockford-base32) — questa coverage 4× gestisce praticamente tutti gli scenari real-world dove un publisher potrebbe cambiare il formato del proprio output nel deploy successivo. Transform pipeline opzionale per ogni campo estratto: trim (elimina whitespace leading/trailing), lowercase/uppercase (normalize case per matching downstream), number (cast a numeric con parsing localized "1.234,56" italiano + "1,234.56" inglese), json (parse del valore come JSON nested object), none (raw passthrough senza modifica). Multi-field in singola invocation: l'utente definisce un dictionary di N field → ognuno con la sua fallback chain di regex, e il nodo li estrae tutti in singolo pass del testo (pattern efficiente vs invocare N nodi separati per N field). Cap di sicurezza: max 50 field per invocation, max 10 pattern per field, max 100KB di testo input per evitare regex catastrophic backtracking su input maligno. Output: { extracted: { fieldName1: { value, matchedPatternIndex, transform_applied }, fieldName2: {...}, ... }, totalFieldsExtracted, totalFieldsMissing, durationMs }. Use case: parsing di token JWT/CSRF/session_id da response HTML/JS di API non documentate (workflow di automation che simula login programmatic su sistemi legacy senza API REST disponibili); estrarre prezzo da HTML di e-commerce con multiple quote variants tra mobile/desktop version dello stesso sito; recovery di numero fattura/data fattura/totale da PDF testuale di vendor eterogenei (ogni fornitore ha format leggermente diverso → fallback chain copre tutti); capture pattern specifici da log applicativi per alert SLA (es. error code, response time, customer_id per detection di anomalie + pattern di failure analytics); migration di dati da export legacy text/CSV con format incomerente.

Costruisce URL dinamici da template `${var}` + query params + flag condizionali. Pattern enterprise per costruire URL finali (playlist HLS, API endpoint, signed URLs) dopo aver estratto token/id/params da pagine HTML. Esempio: estrai videoId e token da pagina embed, poi costruisci https://${host}/playlist/${videoId}?token=${token}&expires=${expires}&language=it. Sintassi: ${input.path.to.value} pesca da output del nodo precedente. ${customVar} pesca da Vars custom. Encoding URI automatico sui query params. Conditional flags: aggiungi query parametri solo se condizione vera. Use case: (1) costruire URL HLS playlist con token + expires dopo extraction, (2) signed URL API per webhook callback, (3) deep-link mobile app con UTM tracking dinamico, (4) URL paginazione condizionale (page=N solo se >1).

Renderizza una pagina con browser headless (Chrome) per scraping di SPA / siti JavaScript-heavy (React/Vue/Angular). Aspetta che il selettore appaia, poi ritorna HTML completo + cookies + screenshot opzionale. Usa quando: action_web_fetch_advanced ritorna HTML scarno perché il contenuto viene generato da JS post-load (es. listing prodotti SPA, dashboard che carica dati via fetch). Architettura BYO (Bring Your Own Browser): per non far esplodere ogni container con 300MB di Chromium, il nodo chiama un endpoint Playwright esterno (browserless.io self-host, Playwright Server, o managed Zeli add-on). Configura l'endpoint in Settings → Integrazioni → Browser Render. Use case: (1) scraping listing prodotti SPA con prezzi caricati via fetch, (2) audit propria dashboard con screenshot SLA-grade, (3) ingest pagina React-based che action_fetch_url restituirebbe vuota, (4) screenshot per archivio legale di una landing competitor (snapshot dated).

Risolve Cloudflare/DDoS-Guard JavaScript challenge via FlareSolverr (https://github.com/FlareSolverr/FlareSolverr). Ritorna il cookie `cf_clearance` + User-Agent da usare nei fetch successivi al sito Cloudflare-protected. Setup: il tenant self-hosta FlareSolverr (1 docker container leggero) e configura qui l'endpoint. Bring Your Own — Zeli non gestisce solver pubblici per evitare abusi. USA SOLO per: accesso a PROPRI siti protetti da CF, monitoraggio uptime, integrazione partner B2B. NON usare per: evasione paywall/protezione siti di terzi (TOS violation, potenziale liability legale del tenant). Workflow tipico: 1) cloudflare_solver(url) → cookies+UA, 2) web_fetch_advanced(url, cookies=output.cookieHeader, UA=output.userAgent) → HTML reale. Use case: (1) monitoraggio uptime di propria pagina dietro CF, (2) audit periodico content proprio sito Cloudflare-protected, (3) integrazione partner B2B che usa CF managed challenge, (4) scraping pricing pages proprie multi-region.

Selettore enterprise di User-Agent string da un pool curato organizzato per categoria — utility per testing del proprio sito sotto diversi browser/device contesti, A/B testing della response server in base al UA, monitoring del comportamento del proprio bot detection. Il pool predefinito è organizzato in 5 categorie semanticamente meaningful: desktop (Chrome/Firefox/Safari/Edge versioni recenti 2024-2026 per le tre piattaforme major Windows/macOS/Linux), mobile (iPhone Safari iOS 17+, Android Chrome 12x recent, Samsung Internet, Opera Mobile), tablet (iPad Safari per landscape orientation, Android tablet Chrome), bot (le UA dei crawler legittimi famosi: Googlebot/2.1, bingbot/2.0, DuckDuckBot, FacebookBot, Twitterbot, LinkedInBot, Slackbot, Telegrambot — utile per testare il proprio social embed cards), custom (pool definito dal customer per use case specifici aziendali). Tre strategie di selezione complementari per coprire i pattern d'uso: (1) random — pesca uniforme dalla pool selezionata, ogni invocazione del nodo restituisce un UA diverso (pattern naturale per test di breadth coverage); (2) deterministic — seed-based, prende un input field (es. user_id, session_id, transaction_id) come seed per il deterministic hash → garantisce che la stessa key produca SEMPRE lo stesso UA tra invocazioni multiple del workflow (pattern per testing reproducibile + A/B testing user-stable); (3) sequential — round-robin time-based, ruota il pool su una sliding window per garantire uniform distribution del UA usage nel tempo (pattern per monitoring distributo del proprio sito senza skew). Politica etica enterprise: questo nodo è progettato per testing del PROPRIO sito o servizio cliente authorized — il pool include FlowForge/1.0 RFC-compliant UA per dichiarare onestamente l'identità del crawler. NON usarlo per spoof identità di browser legittimi verso siti di terzi che potrebbero considerarlo violazione ToS — il SaaS multi-tenant FlowForge non garantisce protezione legale per questo abuse case. Output: { userAgent (string completa da passare in input al nodo downstream), category, strategyUsed, seedUsed?, poolIndex }. Use case: testare il proprio sito e-commerce con diversi UA per verificare che il responsive design funziona su tutti i form-factor (loop su category=mobile + verifica che la checkout button è visibile above-the-fold); A/B testing della response server (HTML/JSON/different) in base al UA pattern; monitoring del proprio bot detection comportamento (passare un UA "bot" e verificare se il sito serve la versione semplificata SEO-optimized); generazione di dataset di test per QA del proprio sito; integrazione con action_web_fetch_advanced come userAgentCustom per testing reproducibile della response server in workflow di regression test.

Parser inspector di playlist HLS (HTTP Live Streaming) — lo standard di streaming adaptive sviluppato da Apple nel 2009 e diventato dominante sia su iOS/Safari nativi che cross-platform via player tipo hls.js (utilizzato da Twitch, Disney+, Apple TV+, Disney Hotstar, Amazon Prime Video legacy, Mediaset Infinity, RAI Play, Sky Go, e centinaia di altri broadcaster italiani ed europei). Scarica il file .m3u8 di playlist e ne fa il parse RFC 8216 (HLS draft-pantos-hls-rfc8216bis-13 + estensioni Apple LL-HLS Low Latency 2025): rileva automaticamente se è una playlist master (parent che enumera le varianti di qualità via tag #EXT-X-STREAM-INF — la "ricetta" del ABR adaptive bitrate ladder, tipicamente 240p/480p/720p/1080p/4K) oppure una media playlist (child che enumera i segmenti TS o fMP4 via tag #EXTINF — la lista concreta dei chunk da scaricare in sequenza). Output rich per master: { type: "master", variants: [{ bandwidth (bit/s), resolution (WxH), codecs (avc1.4D401F per H.264 main profile, hev1.1.6.L120.B0 per HEVC, av01.0.04M.08 per AV1, mp4a.40.2 per AAC-LC, ec-3 per Dolby Digital Plus), frameRate, audioCodecs, captions, subtitles, url (assoluto o relativo alla baseUrl) }], iframePlaylists?, sessionData?, contentSteering?, drmSchemes? }. Output per media: { type: "media", segments: [{ duration (decimal seconds), uri, byteRange?, dateTime?, discontinuity? }], targetDuration (max single segment duration), mediaSequence (incremental counter), endlist (true=VOD playlist statica con #EXT-X-ENDLIST / false=live con sliding window di N segmenti), playlistType? (VOD|EVENT), keys? (chiavi di encryption AES-128 ClearKey o sample-aes DRM) }. Operazione READ-ONLY pura: parsa SOLO il manifest text (tipicamente 5-50KB), zero traffico sui segmenti video reali (che sarebbero centinaia di MB-GB), zero decryption (le DRM chiavi sono solo enumerate, non usate per estrarre contenuto). Sicuro per monitoring continuativo 24/7 anche su 100+ stream simultaneamente, traffic footprint minimo. Use case: monitoring CDN streaming proprio "la nostra master ha sempre le 3 varianti aspettate (360p+720p+1080p)? oggi 23 maggio ne vede solo 2 = alarm encoder produzione TV down"; quality assurance post-encoding "il nuovo asset upload ha tutti i bitrate target +/- 5% tolleranza"; uptime check live stream "il live HLS è ancora effettivamente live? endlist=false + segmenti aggiornati negli ultimi 30s = sì, altrimenti = stream interrotto"; detection di encoding evolution (migrazione progressiva da AVC a HEVC a AV1 per ridurre bandwidth CDN del 40-60%); validation di stream gratuit di terze parti (sport rights monitoring, broadcaster legali vs piratato) prima di aggregarlo nel catalogo streaming come Streammy; setup automatic di player JavaScript (hls.js, video.js) — il client legge le varianti disponibili e seleziona quella migliore in base a bandwidth misurato real-time.

Parser inspector di manifest MPEG-DASH (Dynamic Adaptive Streaming over HTTP) — l'altro grande standard di streaming video adaptive accanto a Apple HLS, dominante su YouTube, Twitch (parziale), broadcaster europei tipo France.tv, BBC iPlayer, Mediaset Infinity, Sky, e tutti i servizi DRM-protetti con Widevine o PlayReady (Netflix, Disney+, Amazon Prime Video). Scarica il file .mpd (Media Presentation Description, XML) dall'URL fornito e ne fa il parse semantico estraendo l'inventario completo dell'asset: AdaptationSets separati per tipologia (video, audio multitraccia con lingua identificata via @lang BCP-47, subtitle/caption con formato WebVTT/TTML), Representations all'interno di ogni AdaptationSet con tutti i dettagli tecnici (bandwidth target in bit/s, codec FourCC come avc1.640028 H.264 High Profile L4.0 oppure hev1.1.6.L150.B0 HEVC Main10 oppure av01.0.05M.08 AV1, risoluzione width×height, frameRate computato), durata totale dell'asset come ISO 8601 PT1H32M15S (riconvertibile in secondi per programmi di scheduling), profili DASH dichiarati (ISO Live, ISO On-Demand, DASH-IF IOP 2024), tipo di presentation (static=VOD tradizionale con time-shift permesso e seekable / dynamic=live con time-shift buffer configurabile e window di availability). Output: { adaptationSets: [...], totalDurationSeconds, presentationType, profiles, mpdVersion, minBufferTime, mediaPresentationDuration }. Operazione READ-ONLY pura: scarica e parsa SOLO il manifest XML (tipicamente 50-200KB), zero traffico sui segmenti video reali (che sarebbero centinaia di MB-GB). Sicuro per monitoring continuativo. Use case: monitoring 24/7 del CDN proprio che serve DASH streaming (allarme se 1 AdaptationSet video scompare improvvisamente — l'encoder è giù); verifica encoding profile ABR (Adaptive Bit-Rate) di qualità per detect di regressioni post-deploy nuovo encoder ladder (es. "ci aspettiamo 6 bitrate da 240p a 2160p, oggi ne troviamo 4 = alarm"); compliance audio multilingua dichiarata vs effettiva per servizi broadcasting EU che hanno obblighi di accessibilità BCP-47 (it, en, fr, de track contractually required); detection di codec evolution (es. migrazione progressiva H.264 → HEVC → AV1 per ridurre bandwidth CDN del 50%); pre-flight check prima di pubblicare un nuovo asset Live (la "vetrina" che la pubblicazione lavora correttamente).

Estrattore enterprise di metadata da file video — basato su ffprobe (il tool companion di ffmpeg, l'industry standard de-facto per video processing usato da YouTube, Netflix, Twitch, broadcaster TV mondiali per probe del media payload). Analizza qualsiasi file video supportato dal vasto codec library di ffmpeg (300+ formati incluso MP4, MKV, MOV, AVI, FLV, WMV, MTS, M2TS, MXF per broadcast professional, WebM per web modern) e ne estrae l'inventario completo dei metadata tecnici essenziali per QA pre-publish, indicizzazione media library, compliance broadcast: codec video (H.264/AVC più diffuso, HEVC/H.265 per high-efficiency, VP9 per WebM YouTube, AV1 royalty-free per next-gen streaming, ProRes per editing professional), bitrate avg/max in Mbps, fps frame rate (24 standard cinematografico, 25 PAL europeo, 30 NTSC americano, 50 PAL slow-mo, 60 NTSC slow-mo), risoluzione width×height (480p, 720p HD, 1080p Full HD, 2160p 4K UHD, 4320p 8K), traccia audio multipla con codec (AAC più comune, AC3 Dolby Digital broadcast, EAC3 Dolby Digital Plus streaming, DTS Blu-ray, MP3 legacy), language tag per ogni traccia (it, en, fr, de... BCP-47), bit depth (8-bit standard, 10-bit HDR), channel layout (mono, stereo, 5.1 surround, 7.1), sample rate (44.1/48/96 kHz); traccia sottotitoli con codec (subrip, WebVTT, ASS) + language; durata totale (secondi + human-readable HH:MM:SS); container format (mp4, mkv, mov, mts), metadata fields generici (title, artist, creation_time, encoder usato per generation). Pattern deployment specifico enterprise: ffprobe binary + dipendenze codec (libx264, libx265, libvpx, libav1) pesano ~50-100MB totale → NON viene bundlato nel container runtime FlowForge per evitare bloat inutile alla maggior parte dei tenant che non usano video. Pattern microservice: il tenant deploya un wrapper HTTP separato (immagine docker pre-pronta `jrottenberg/ffmpeg` + Express HTTP, oppure Cloud Run/Lambda con custom container, oppure self-hosted dedicated server) e configura l'endpoint qui o via env FLOWFORGE_FFPROBE_ENDPOINT condivisa. Pattern SSRF-safe sempre: quando l'URL del video da analizzare proviene da config user-driven o input esterno, il request passa per @flowforge/safe-fetch che blocca URL privati 192.168/127.* per security. Use case: indicizzazione media library di una piattaforma streaming/VOD con catalogazione automatic di tutti i file caricati dal content team in metadata schema searchable; QA pre-publish per verifica compliance dei requirements editoriali (es. broadcaster italiano richiede 1080p min + traccia audio italiana obbligatoria + subtitle stereo per accessibilità); check size pre-CDN upload con cap budget (se file > 10GB → reject prima di consumare bandwidth/storage); compliance broadcast FCC USA/AGCOM Italia che richiede metadata standardizzati nel container per ingest nei sistemi broadcast.

Innesco enterprise di polling per feed RSS/Atom che esegue il workflow ad ogni nuovo item rilevato — il pattern monitoraggio continuativo "push-style" della pubblicazione di contenuti dei publisher che espongono feed standard. Auto-detect intelligente del formato (RSS 2.0 vs Atom 1.0) leggendo l'XML root namespace — pattern necessario perché i due standard sono mutualmente incompatibili a livello di schema ma semanticamente equivalenti per il use case workflow, e il publisher può cambiare format sotto le scarpe senza avvisare. Implementazione robusta: il trigger scheduler del runtime FlowForge invoca questo trigger ogni pollIntervalMin (default 15min, range configurable 1min-24h), il nodo fetch del feed URL, parse XML completo, e per ogni item nuovo non-ancora processato fire un new run del workflow con il content del item come trigger input. Dedup importante via guid/id del item (gli item RSS hanno guid univoco — spec RFC 4287 lo richiede) + persisted di un cursor lastSeenGuid nel state store del trigger per guarantee exactly-once delivery anche su restart container o crash recovery — pattern cruciale per evitare il classico bug "ogni mattina ricevo 50 email di alert duplicate sui post di ieri" all'restart del workflow. Schedulazione complementare: il polling può essere config su questo trigger directly (pattern preferito per workflow dedicato a singolo feed) oppure combinare con trigger_cron che chiama questo nodo come action (es. cron 15min globale che processa 10 feed in singolo workflow batch — più efficient di 10 trigger separati ognuno con suo polling indipendente). Input al workflow downstream per ogni nuovo item: { item: { title, link, pubDate, content, snippet, author, categories, enclosure? }, feedMetadata: { feedTitle, feedDescription, feedUrl, feedLanguage, totalItemsInFeed, polledAt } }. Use case enterprise di monitoring continuativo: news aggregator azienda con monitor di 10+ testate (Repubblica, Corriere, Sole24Ore, Il Foglio, Il Post, ANSA, Reuters Italia) + AI summary downstream via agent_business_summarizer + post su Slack canale #news della company; monitoraggio sistematico di comunicati stampa istituzionali (RSS feed di Camera dei Deputati, Senato della Repubblica, Gazzetta Ufficiale italiana, AgID, Garante Privacy — tutti expongono RSS feed ufficiale); sync di nuovi articoli del proprio blog su CRM HubSpot/Salesforce per il marketing team (post nuovo → contact rilevanti segmented → email digest); alert su nuovi articoli pubblicati dai principali concorrenti su loro blog corporate (10+ competitor monitored simultaneously); GitHub releases feed dei vendor di dependency critiche (postgres, nginx, kubernetes, node) per security patches notification.

Crawler enterprise specializzato per sitemap.xml — il file XML standard sitemaps.org che ogni sito web rispettabile espone (default /sitemap.xml o riferito da robots.txt) per dichiarare ai search engine tutto il proprio universo URL navigabili con metadata di update freshness, change frequency, priority. Scarica il sitemap dall'URL fornito e parsa l'XML estraendo l'elenco di tutte le URL dichiarate, con supporto completo allo standard plus extensions: sitemap-index ricorsivo (un singolo sitemap.xml padre che linka N child sitemap separati, pattern usato dai siti grossi con > 50k URL — il limite hard di un singolo sitemap file — come Amazon, Wikipedia, CNN, RAI, Mediaset), elementi <url> con <loc> obbligatorio + <lastmod> (timestamp ultimo aggiornamento del documento), <changefreq> hint (always/hourly/daily/weekly/monthly/yearly/never), <priority> da 0.0 a 1.0 (importance relativa nel ranking), estensioni xmlns Image (img:image), Video (video:video), News (news:news). Filtri rich applicati lato-client per ridurre traffico downstream e focus sui URL rilevanti: regex include (whitelist — "ritorna solo URL che matchano /products/", per scraping mirato), regex exclude (blacklist — "salta URL di /admin/ /login/ /search/" per evitare di hammer endpoint non utili), filtro lastmod minimo (date threshold — "solo URL aggiornati dopo 2026-01-01", pattern incrementale per evitare di riprocessare pagine immutate dalla last run del workflow). Sicurezza & resilienza: safeFetchWithRedirects (anti-SSRF su URL privati 192.168.* 127.* 10.*), timeout configurabile (default 30s — alcuni sitemap grossi di e-commerce italiani superano 5MB di XML), retry su 5xx con exponential backoff + jitter, decompressione automatica gzip se il server invia Content-Encoding: gzip (pratica comune per sitemap > 1MB), parsing streaming SAX-based per evitare memory bloat su sitemap monster. Cap default per safety: max 1000 URL ritornati per evitare di intasare il workflow downstream con risultati enormi, max recursion depth 3 livelli sitemap-index per evitare loop infiniti su sitemap malformati (un sitemap-index che si autorefferenzia, situazione rara ma capitata su CMS bugged). Output: { urls: [{ loc, lastmod?, changefreq?, priority?, sourceSitemap }], totalUrls, sitemapsTraversed, depth, truncated (true se cap raggiunto), timing }. Use case: audit SEO del proprio sito ("quante pagine ho indicizzate? mancano i nuovi prodotti?"); detection di nuove pagine pubblicate confrontando current vs last-run cached (pattern ETL incrementale: "oggi 1500 URL totali vs ieri 1485 → 15 nuovi URL → scrape immediato"); sync URL su crawler interno per indicizzazione search engine privato o RAG retrieval index aggiornato; bulk price-check pagine prodotto e-commerce competitor (catalogo URL → loop → action_web_fetch_advanced → estrazione prezzo); SEO compliance per agency che monitora 50 siti cliente in batch per detection di pagine 404 o orfane.

Browser headless con anti-detection enterprise (Puppeteer-stealth). Bypassa Cloudflare Turnstile, Akamai Bot Manager, DataDome, PerimeterX, hCaptcha-soft. Applica ~20 contromisure: navigator.webdriver hide, canvas/WebGL fingerprint spoof, chrome.runtime fake, plugins.length match, languages/vendor consistency, iframe.contentWindow patch, font enumeration block, hairline detection, permission.query overwrite. Features avanzate: fingerprint preset pool (desktop/mobile, IT/EN), auto-scroll lazy-load (per Infinite scroll), human-like delays (mouse jitter, typing pause), HAR capture, resource blocking (immagini/font per velocità). Architettura BYO (Bring Your Own Browser): il nodo chiama un endpoint Playwright/Puppeteer con plugin stealth installato. Setup: docker run -p 3000:3000 ghcr.io/browserless/chromium:stealth oppure managed Zeli endpoint. Use case: (1) monitoraggio prezzi su propri marketplace dietro CF/Akamai, (2) audit competitor pricing pages CF-protected con autorizzazione, (3) sync dati internal SPA che usa anti-bot a livello service, (4) snapshot legale di pagine sotto challenge browser-side.

Spider crawler distribuito enterprise per indicizzazione massiva di siti web — orchestra una pipeline di N worker paralleli che processano una queue Redis condivisa di URL da visitare, con tutti i guardrail di crawling professionale: depth-limit configurable per evitare runaway su siti con loop circolari, dedup tramite bloom filter (memory-efficient probabilistic data structure che evita di rivisitare URL già processate senza dover keep in RAM un Set di milioni di URL), respect del robots.txt del sito target con parsing semantico Allow/Disallow/Crawl-delay/User-agent, sitemap-first seed strategy (parte dal sitemap.xml ufficiale invece di crawl dalla home + follow link — più efficiente e copre meglio i deep page), parallel workers configurable da 1 a 100 per scaling horizontale del throughput, checkpoint resume robusto per riprendere dopo crash o interruzione volontaria senza dover ricominciare daccapo. Architettura BYO (Bring Your Own — il servizio crawler gira separato dal runtime FlowForge per scaling indipendente): supporta come backend Heritrix (il crawler della Wayback Machine di archive.org), Scrapy-cluster (lo standard Python distributed scraping), oppure custom Rust crawler per use case performance-critical. Setup tipico: docker-compose con Redis Stack (per queue + bloom filter) + N crawler worker container + flowforge-bridge HTTP che espone API standard al runtime. Lifecycle 4-action: action=start (lancia un nuovo job di crawl con seed URL + config — ritorna jobId opaque univoco per tracking + handoff async), action=status (metrics live del job in corso: URL processed, queued, errored, current depth, ETA — utile per progress monitoring dashboard), action=stop (termina graceful il job preservando lo state checkpoint per future resume), action=results (paginated retrieval dei result batch con cursor — pattern naturale per workflow downstream che consumano i risultati a chunks). Pattern di callback webhook opzionale: invece di poll periodico con action=results, il caller può fornire un webhook URL e il crawler service pusha batch automatic quando hanno completed N pagine. Use case: indicizzazione completa di sito proprio per generation di interno search engine private + RAG retrieval index per knowledge base AI; competitor analysis (con respect del robots.txt — sempre, per evitare ToS issue legali); archivio storico di pagine prima di redesign per detection di changes future; monitoraggio modifiche periodiche di un sito (re-crawl settimanale + diff con previous run); link audit complessivo per individuazione 404 broken link + redirect chain inefficienti; data collection per training di LLM/NLP model su corpus dominio-specifico autorizzato.

Estrae dati strutturati JSON da uno SCREENSHOT di pagina web usando vision LLM (Qwen2.5-VL-7B self-hosted Zeli, porta 5004). Resiliente a redesign sito: non usa CSS selectors. "Vede" la pagina come un umano e estrae i dati che gli chiedi in linguaggio naturale. Use case killer: scraping di siti SPA che cambiano DOM ogni release, monitoraggio competitor che modifica layout, estrazione tabelle da PDF screenshot, reverse-engineering form UI senza inspector. Pipeline: screenshot → prompt + schema JSON target → vision LLM → parse JSON (fence/trailing-commas tollerati) → schema validation → output strutturato. Retry: exponential backoff + jitter su 5xx (3 attempts). Cache: hash(image+prompt) → Redis TTL 24h (se Redis configurato). Tipico pairing: action_browser_stealth → action_vision_extract (chain).

Orchestratore intelligente di scraping: combina fetch + browser + stealth + vision + LLM extract in UN nodo. Risparmia 5-10 nodi di workflow manuale. Pipeline adaptive 4-stage (heuristic-driven): 1. fetch_simple → HTML quick 2. browser_render se HTML scarno (SPA shell) 3. browser_stealth se anti-bot challenge (Cloudflare/Akamai/DataDome/PerimeterX) 4. vision_extract se contenuto visually-only (canvas/PDF/SVG) Estrazione: Liara LLM riceve HTML + prompt naturale ("estrai prezzo, titolo, immagine") + schema JSON target → ritorna oggetto strutturato. No CSS selectors. Pagination: auto-detect rel="next", aria-label "Next", text "Successivo/Avanti/›", URL pattern page=N → page=N+1. Follow fino a maxPages. Observability: ogni request espone pipelineSteps con stage usato + duration + evidence + errore. Setup BYO: configura FLOWFORGE_BROWSER_ENDPOINT + FLOWFORGE_STEALTH_ENDPOINT (browserless self-host o managed Zeli). LLM = Liara locale porta 3003 default. Use case: (1) scraping listing prodotti e-commerce con pagination + extract JSON strutturato, (2) ingest dati pubblici (registri/anagrafiche) con fallback adaptive, (3) monitoring concorrenti con AI extract di prezzi e stock, (4) onboarding cliente B2B che chiede "scarica i miei dati da X" senza scrivere CSS selectors.

Crawler ricorsivo in-process per discovery URL e mirror sito SENZA hostare un servizio esterno (a differenza di action_crawler_distributed BYO). Esegue una BFS bounded sui seed con dedup Set, depth limit, max-pages hard cap, concurrency worker pool, rate-limit per-host (token bucket) e rispetto robots.txt cache-once-per-host. Output per-pagina: HTML completo (solo text/html), links extracted same-origin filtrabili via allow/deny, status HTTP, content-type, bytes, durata, error. Use case: (1) mirror del proprio sito + asset (combinato con action_asset_batch_download), (2) audit SEO interno (broken links + orphan pages), (3) discovery URL per RAG/embedding internal docs, (4) competitor catalog monitor (USA SOLO su siti propri o con autorizzazione). Safety: hard cap 5000 pagine/run, SSRF guard, robots.txt rispettato di default, identifica come "FlowForge-Spider/1.0" RFC-compliant (override consentito).

Scarica in parallelo array di URL binari (immagini, PDF, video, CSS, JS) e salva su disco preservando il path-tree del sito. Companion di action_recursive_spider per fare un mirror offline. Features: SHA-256 dedup + resume (skip se file esiste con stesso hash), atomic write tmp+rename (no file mezzi-scritti), worker pool bounded, rate-limit per-host, hard cap bytes totali + per-asset (default 1 GiB / 50 MiB), path traversal-safe (rifiuta "..", null bytes, escapes basePath). Output `assetMap` (url→savePath) consumabile direttamente da action_html_mirror_rewrite per riscrivere i link nel HTML offline. Use case: (1) mirror immagini/PDF di un proprio catalogo prodotti, (2) backup di un proprio sito statico, (3) ingest asset per CDN privato, (4) snapshot legale di una pagina (con audit). Safety: SSRF guard, basePath obbligatoriamente assoluto, traversal-safe, hard caps anti-runaway.

Riscrive un HTML per la navigazione offline come fa wget --mirror: trasforma URL assoluti di asset (img/css/js/video/iframe) in path locali relativi, in base alla mappa assetMap (output di action_asset_batch_download). Riscrive: a[href], link[href], img[src+srcset], script[src], source[src+srcset], video[src+poster], audio[src], iframe[src], embed[src], object[data], CSS url(...) inline (<style> blocks + style attribute). NON riscrive: data:/mailto:/tel:/javascript:/blob: URIs, fragment-only links (#anchor), URL non presenti in assetMap (preservati assoluti — utile per link "external" verso il web live). Use case: pipeline mirror completo (spider → asset download → mirror rewrite → file_write), backup statico navigabile, snapshot legale di una pagina. Output: html riscritto + stats {rewritten, unchanged, skippedScheme} per audit.

Parser meta tag SEO completo da HTML — estrae title, description, canonical, lang, robots, viewport, Open Graph (og:title/og:description/og:image/og:type/ og:url), Twitter Card (twitter:card/title/description/image/site/creator), JSON-LD strutturato (Schema.org Article/Product/Organization/BreadcrumbList /FAQPage/HowTo/Recipe), favicon, hreflang multi-language, og:locale, theme-color. Output strutturato schema-uniforme per scoring SEO automatico, alimentare DB audit, generare report email, AI agent suggestion rewriting. Differenza con i sibling: action_meta_extract = parsing PURE locale (HTML → object structured, no network). Per scoring SEO completo con weight rules usa action_seo_audit downstream. Per analisi keyword density specifica usa action_keyword_density. Per audit broken links su pagina usa action_link_audit. Per redirect chain analysis usa action_redirect_chain. Pipeline tipico: action_web_fetch_advanced (fetch HTML) → action_meta_extract (parse meta) → action_seo_audit (score) → action_send_email (digest report). Zero network in questo nodo: parsing locale via cheerio + regex robust. Tollerante a HTML malformato (tag chiusi male, attributi senza quote, encoding inconsistent UTF-8/Latin-1). Output: `{ title, description, canonical, lang, robots, viewport, openGraph: {...}, twitter: {...}, jsonLd: [{...}], favicon, hreflang: [{lang, href}], meta_extra: { theme-color, generator, application-name, ... } }`. JSON-LD normalizzato a array (anche se HTML ne ha 1 solo blocco) per uniformare il downstream loop. hreflang validato (lang code ISO 639-1 + region ISO 3166-1). Use case Cappella-Sistina-grade: (1) **SEO audit mensile** propri 100 landing pages — cron loop su sitemap → fetch + meta_extract + seo_audit → digest email con red flag (description mancante / canonical wrong / og:image broken); (2) **OpenGraph preview tester** — utente incolla URL nel form, workflow fetch + meta_extract → render preview FB/Twitter/LinkedIn come si vedrebbe → permette editor di iterare prima di publish; (3) **Schema.org validation** per propri prodotti e-commerce — verifica JSON-LD Product schema completo (price/availability/aggregateRating) per Google Rich Results; (4) **competitor SERP monitoring** — settimanale fetch 50 landing competitor, estrai title/description, alert se cambiano (= nuova strategia keyword). Safety budget: HTML parse max 5 MB (oltre → truncate), regex robust con timeout 100ms (anti-ReDoS), JSON-LD parse safe (no crash su malformed), audit log con URL hash + meta count per cost monitoring.

Audit SEO completo on-page con scoring deterministico 0-100 e grade A-F. Valuta 30+ criteri: title length (target 50-60 char), description length (150-160), H1 count (esattamente 1), heading hierarchy (no skip livelli), canonical presente + assoluto, lang attribute, robots directive, alt immagini (count + missing list), conteggio link interni vs esterni con nofollow ratio, Open Graph completo (5 tag minimi), Twitter Card type, Schema.org JSON-LD type detection, hreflang validity ISO 639-1, viewport meta mobile-friendly, theme-color presente, favicon dichiarato. Zero network — parsing locale via cheerio. Differenza con i sibling: action_seo_audit = scoring + issues list (HTML in → score + grade + report). Per parsing meta tag senza scoring usa action_meta_extract (raw structured data). Per density specifica keyword usa action_keyword_density. Per link broken check usa action_link_audit (con HTTP HEAD probe). Per redirect chain audit usa action_redirect_chain. Scoring deterministico (NO LLM drift): peso per criterio configurabile, lo stesso HTML → SEMPRE lo stesso score (audit-friendly per cliente enterprise che vuole prove riproducibili). Issues classificati per severity: **critical** (title mancante / no canonical / H1 mancante = -10 punti ognuno), **warning** (description fuori range 150-160 / og:image mancante = -3), **info** (alt immagine vuoto / link count > 100 = -1). Codici issue machine-readable tipo `SEO_TITLE_TOO_SHORT`, `SEO_NO_CANONICAL`, `SEO_H1_DUPLICATE` per filtering downstream. Output: `{ score: 0-100, grade: "A"|"B"|"C"|"D"|"F", issues: [{ code, severity, message, evidence }], meta: { title: { value, length, ok }, description: {...}, h1: { count, ok }, links: { internal, external, nofollow }, ... } }`. Grading scale: A 90-100 / B 80-89 / C 70-79 / D 60-69 / F <60 — soglie configurabili. Use case Cappella-Sistina-grade: (1) **audit SEO settimanale** propri 50 landing — cron loop fetch → seo_audit → store score in DB → trend chart dashboard (score migliora nel tempo? regressioni dopo deploy?); (2) **gate CI/CD pre-deploy** — il workflow build chiama seo_audit su pagina nuova, se score < 80 blocca deploy con report PR comment GitHub; (3) **client reporting agenzia SEO** — mensile fetch + audit, PDF report con grade + top 10 issues + raccomandazioni testuali → email cliente; (4) **A/B test SEO impact** — variant A con tag attuali, variant B con title rewritten, audit entrambi → confronto deterministico score. Safety budget: HTML parse max 5 MB, regex parser timeout 100ms anti-ReDoS, image count cap 1000 (alt check), link count cap 5000, audit log con URL hash + score + issues count.

Tracciatore di redirect chain HTTP — segue ogni hop manualmente (NO follow automatico) e restituisce array completo di redirect con status code, Location header, latency, body bytes (HEAD-mode default), URL finale. Rileva loop circolari, redirect cross-protocol (http→https), redirect cross-domain, e flag catene "troppo lunghe" (>3 hop) per impatto SEO link juice. Differenza con i sibling: action_redirect_chain = traccia chain HTTP (URL → array hops). Per audit broken links su pagina HTML usa action_link_audit. Per parsing meta tag dopo aver risolto il redirect finale usa action_meta_extract. Per fetch HTML auto-follow (per scraping) usa action_web_fetch_advanced. Status codes gestiti: 301 Permanent (canonical SEO juice transfer), 302 Found (temporary — no SEO transfer), 303 See Other (POST → GET conversion), 307/308 (method preservation), Refresh meta tag (HTML `<meta http-equiv="refresh">`) estratto se presente (browser segue, crawler ignora — flag come "weak redirect"). Detection canonical mismatch: URL finale != og:url / canonical = red flag SEO. Output: `{ chain: [{ url, status, location, latencyMs, server, contentType }], finalUrl, hopCount, loopDetected, crossDomainCount, totalLatencyMs, seoImpact: "good"|"warning"|"bad" }`. seoImpact deterministico: good (1-2 hop), warning (3-4 hop o cross-domain), bad (5+ hop o loop). Use case Cappella-Sistina-grade: (1) **audit post-migrazione sito** — fetch sitemap vecchia, per ogni URL → redirect_chain → verify che redirige a URL nuova in 1 hop con 301 (no juice loss). Alert se 302 (settato per sbaglio); (2) **vanity URL verifier** — bit.ly/short.io/custom domain — segui chain fino al final URL per detection malicious redirect (advertiser frode); (3) **canonical URL audit propri prodotti** — il canonical e\` raggiungibile in 1 hop? O passa per 3 redirect? Google CMM penalizza chain > 3; (4) **debug cookie-redirect login flow** — per debug SSO flow custom, tracci ogni 302 con il cookie state passato. Safety budget: SSRF guard via @flowforge/safe-fetch (no fetch a 127/10/192/ link-local), timeout 8s per hop, max 20 hop totali (oltre → loop break), audit log con startUrl + finalUrl + hopCount per SEO traceability.

Audit link su pagina HTML — classifica ogni link in internal (same-origin) / external (cross-domain) / anchor (#frag) / mailto: / tel: / javascript: / data: con dedup canonical URL. Opzionalmente esegue HEAD probe parallelo per identificare link rotti (status >= 400 / DNS fail / timeout / TLS error) con severity classification (404 critical / 5xx warning / 3xx info). Differenza con i sibling: action_link_audit = inventory + probe link su pagina (HTML in → links classified + broken list). Per scoring SEO complessivo che incorpora link health usa action_seo_audit (link ratio nei criteri). Per redirect chain audit del singolo link (multi-hop) usa action_redirect_chain. Per estrazione plain text dei link senza probe usa action_html_select. Probing intelligente: HEAD-first (zero bytes downloaded), fallback automatico a GET no-body se server ritorna 405 Method Not Allowed (alcuni vendor mal- configurati). Concorrenza bounded (default 5, max 20) per non DoS-are il proprio server target durante audit. Cap link probati 200 default (config fino a 1000) — un sito con 10k link in 1 pagina e\` un anti-pattern + audit preferisce campionare random invece di tutto. Classification SEO-relevant: rel="nofollow" / rel="sponsored" / rel="ugc" tag separately (Google li tratta diverso per link juice). target="_blank" detect (UX warning: senza rel="noopener" e\` vulnerabile a reverse tabnabbing). Anchor link with same-page target detection. mailto/tel come "non-web" skip probe ma counted separately. Output: `{ summary: { total, internal, external, anchor, mailto, tel, nofollow, broken }, links: [{ href, text, type, rel, target, status, redirected, latencyMs }], broken: [{ href, status, reason }], stats: { probedCount, probedDurationMs } }`. broken list pronta per email digest settimanale a content manager. Use case Cappella-Sistina-grade: (1) **audit settimanale broken links** su sito aziendale 100 pagine — cron loop fetch + link_audit con probe → aggregate broken list → email content team con responsabilita\` per fix; (2) **post-migrazione check** — confronto link inventory pre vs post migration, alert su link che hanno cambiato URL senza redirect; (3) **monitor affiliate/sponsored link** — il partner advertiser cambia URL senza notifica, detect 404 → revenue impact; (4) **rel="noopener" security audit** — target="_blank" senza noopener = XS-Leaks vulnerability, fix automatico in CMS via webhook. Safety budget: SSRF guard, concorrenza max 20, timeout 8s per probe, hard cap 200 link probati (config 1000), audit log con linksTotal + broken count per detect site degradation trends.

Analizzatore di densità keyword da testo o HTML — estrae testo pulito (strip script/style/nav/footer), tokenizza Unicode-aware (italiano completo incluso accenti perfetti, supporta EN/DE/FR/ES/PT/NL/EL/scandinave), rimuove stopwords built-in IT+EN (300+ termini di rumore per ognuna) + custom blocklist user-supplied. Calcola frequenza per unigrammi, bigrammi (2 parole), trigrammi (3 parole). Bonus: campo `keywordTarget` per misurare DIRETTAMENTE densità di 1+ frasi specifiche da monitorare ("piano marketing 2026" → 8 occorrenze / 1.2% densita\`). Differenza con i sibling: action_keyword_density = frequency analysis (text → top-N keywords + custom target check). Per scoring SEO complessivo usa action_seo_audit (incorpora density nei criteri). Per estrarre solo meta tag senza analisi testo usa action_meta_extract. Per estrazione AI semantic (invece di frequency stat) usa agent_extractor. Tokenization Unicode-aware: split su `\p{L}\p{N}` boundary RFC, lowercase NFC normalized (NFD accent stripping configurabile per match approssimato caffe\` vs caffe vs cafe). Stemming italiano opzionale (snowball algorithm) per merge "marketing/marketings/marketingo" in single root. Lunghezza minima token 3 char (anti rumore "in/di/le"). Output: `{ unigrams: [{ token, count, density: % }], bigrams: [...], trigrams: [...], totalWords, uniqueWords, keywordTargets: [{ target, count, density }], topN: 20 }`. Density formula: count / totalWords * 100 (range 0-100%). Target SEO sano: keyword principale 1-3% (oltre = stuffing penalty). Use case Cappella-Sistina-grade: (1) **audit on-page SEO post-publish** — verifico che la mia landing "piano marketing 2026" abbia density 1-3% sul target keyword, alert se under-optimized; (2) **content-gap analysis vs competitor** — scrap 5 SERP top + keyword_density su ognuno → media keyword usato + delta vs mia pagina = lista keyword da aggiungere; (3) **AI suggestion semantic expansion** — top-20 keyword density usato come input a LLM per suggerire bigrami correlati che mancano (LSI keywords); (4) **analytics editoriale** mensile — tutti articoli blog → trend keyword nel tempo (quale topic dominante questo trimestre?). Safety budget: max text input 10 MB, max token cap 1M (oltre = truncate), regex tokenizer timeout 200ms, audit log con totalWords + density top-3 per cost monitoring.

Risolve un titolo Streammy-like (StreamingCommunity, CB01, AnimeUnity, GuardaSerie, GuardaFlix, StreamingITA, AnimeSaturn, AnimeWorld, AltaDefinizione01) da `titleId` + `episodeId` a URL HLS master playlist direttamente eseguibile da VLC, web player Video.js/hls.js, o proxy server-side per IP-lock bypass. È il workhorse della pipeline Streammy: senza questo nodo serve scrivere ~150 righe di reverse-engineering Inertia.js + iframe parsing + JS unpack ogni volta che il vendor cambia hostname. Differenza con i sibling: action_streammy_resolve = pipeline 4-stage che ritorna URL HLS singolo (1 titolo → 1 URL). Per discovery del catalogo paginato (sfoglia tutti i titoli di un canale) usa action_streammy_catalog. Per rendering HTML detail-page con metadata estratti usa action_streammy_detail_page. Per search cross-canale (10+ provider in parallelo) usa action_streammy_search_multichannel. Per stream proxy con HMAC token + rewrite m3u8 → URL signed usa action_stream_proxy. Per packaging finale in M3U wrapper con EXTVLCOPT usa action_vlc_playlist. Pipeline 4-stage adaptive (ogni stage e\` osservabile via `pipelineSteps` output): (1) **Inertia decode** — fetch della pagina titolo con header `X-Inertia: true` per ottenere JSON `__INITIAL_STATE__` invece di HTML SSR. Estrae embedId, mirror host, tipo provider (sc/cb01/animeunity/...). (2) **Embed iframe fetch** — risolve l'iframe vixcloud/sweetpixel/streamingunity con host pattern matching (supporta wildcard TLD `https://hostprefix.*` per resilienza ai cambi `.company` → `.loans` → `.fund` settimanali). (3) **JS globals parsing** — extract `window.video` / `window.masterPlaylist` con regex multi-pattern fallback chain (quote variants, key con/senza virgolette). (4) **Playback headers build** — assembla Referer + User-Agent corretti per upstream che bloccano hotlink (Referer del mirror, UA Chrome desktop). Resilienza host: la trust list embedHostBase accetta wildcard TLD (vedi compileTrustEntries in host-pattern.ts) — il pattern `https://vixcloud.*` matcha qualunque TLD futuro senza redeploy. Detection automatica del provider type → branching downstream con logic_switch puo\` differenziare gestione per anime (sub italiano) vs film (full HD multi-language). Output: `{ streamUrl, type: "hls", headers: { Referer, User-Agent }, video: {...}, masterPlaylist: "<m3u8 content>", pipelineSteps: [{stage, durationMs, evidence}] }`. pipelineSteps espone OGNI hop per observability — un workflow che fallisce mostra esattamente dove (Inertia decode? embed not found? regex no match?). Use case Cappella-Sistina-grade: (1) **Streammy detail page WF1** — utente clicca su card prodotto, workflow chiama resolve + assembla detail HTML con metadata + bottone "Play VLC" che genera M3U signed proxy via action_stream_proxy seed mode; (2) **Catalog health check** — cron giornaliero che resolve 10 titoli campione su ogni provider per detect downtime/rotation TLD prima che gli utenti se ne accorgano (alert Telegram se pipeline fail >50% su un provider); (3) **VLC playlist batch** — utente esporta una playlist M3U di N stagioni di una serie → loop resolve per ogni episodio + action_vlc_playlist multi-entry final; (4) **Stream proxy seed mode** per IP-locked vixcloud — l'utente naviga da un IP, il server fetcha da un altro: il resolve ottiene URL + headers, stream_proxy crea wrapper M3U con URL signed locked al token tenant. Safety budget: SSRF guard via safeFetchWithRedirects (tutti i fetch verso vendor mirror), host-circuit-breaker per dominio (vendor down 30s → blocca pipeline downstream invece di accumulare timeout), timeout 15s per stage, max iframe redirect depth 5, telemetry OTel con span per stage + evidence per audit forensic. Uso responsabile: il nodo e\` tooling generico — applicabilita\` legale dipende dalla licenza del contenuto (catalog pubblico open vs paywall protected) e dalle TOS del provider; rispetto robots.txt opt-in.

Walker paginato del catalogo di un provider Streammy-like (StreamingCommunity, CB01, AnimeUnity, GuardaSerie, GuardaFlix, StreamingITA, AnimeSaturn, AnimeWorld, AltaDefinizione01) — restituisce array titoli normalizzati schema-uniforme indipendente dal vendor. È il workhorse della discovery layer: senza questo nodo ogni provider richiede 100+ righe di Inertia.js decode + pagination handler custom (page-number vs cursor vs infinite-scroll JSON). Differenza con i sibling: action_streammy_catalog = sfoglia catalogo paginato con mode (browse/newest/top/search/genre). Per cercare uno specifico titolo cross-provider (10 canali in parallelo) usa action_streammy_search_multichannel. Per renderizzare il catalogo in HTML griglia Netflix-style consumabile da webhook_respond usa action_catalog_page. Per estrarre URL HLS dato un titolo risolto qui usa action_streammy_resolve. Mode disponibili (con semantica vendor-aware): (a) **browse** — paginazione sfoglia tutto il catalogo dalla prima pagina, utile per snapshot completo (cron mensile). (b) **newest** — ordinamento per data inserimento, utile per " aggiunti negli ultimi 7 giorni" detection (delta vs run precedente). (c) **top** — ordinamento per score/popolarita\`, utile per dashboard "i piu\` visti". (d) **search** — full-text query, supporta uniglossa IT/EN. (e) **genre** — filtro categoria (azione/comedy/anime/...) per cataloghi verticali. Pagination intelligente: il walker rileva automaticamente lo schema (page-number tipo `?page=N` per CB01 / cursor opaco `?after=X` per AnimeUnity v2 / infinite-scroll JSON con offset per StreamingCommunity) e itera fino a `maxPages` o `maxTitles` cap (anti-runaway: il vendor potrebbe servire infinite "next" link per errore). Ogni pagina genera un log entry consultabile in `paginationLog[]` per troubleshooting. Output schema normalizzato (uniforme cross-provider): `{ titles: [{ id, slug, name, plot, year, score, type: "movie"|"tv"|"anime", genres: string[], posterUrl, scwsId, provider }], paginationLog: [...], pageCount, totalTitlesFound, stoppedReason: "cap" | "no-next" | "error" }`. Un workflow downstream non deve sapere se sta consumando StreamingCommunity o AnimeUnity — il loop su `titles[].slug` funziona identico. Use case Cappella-Sistina-grade: (1) **catalog snapshot mensile** per data-driven content discovery — cron 1° del mese che chiama browse su tutti i provider, salva snapshot DB, calcola delta vs mese precedente (titoli aggiunti/ rimossi); (2) **alert nuovi titoli serie cult** — cron giornaliero che chiama newest + filter genres in ['crime', 'thriller'], notifica Telegram quando compaiono nuove uscite; (3) **catalog page SSR Netflix-grid** per dashboard cliente — webhook trigger → catalog browse limit 60 → action_catalog_page render HTML responsive con poster grid; (4) **search aggregator multi-canale** — invece di colpire ogni canale singolarmente usa search_multichannel; questo nodo serve per single-channel search con paginazione completa quando vuoi tutti i match (non solo top 10 per canale). Safety budget: SSRF guard per ogni fetch, host-circuit-breaker per provider (un mirror down non blocca scan altri provider), cap maxPages 100 default (override fino a 1000 per snapshot), cap maxTitles 10k per run, timeout 10s per pagina, telemetry OTel con span per pagina + count titoli + cumulative duration. Rispetto robots.txt opt-in. Audit-friendly: ogni run logga url + pageCount + titoli estratti per traceability.

Renderizza la pagina di dettaglio di un titolo Streammy (StreamingCommunity, CB01, AnimeUnity) come HTML completo pronto al browser tramite action_webhook_respond. Estrae poster + trama + cast + anno + score dalla source vendor, e per le SERIE costruisce una tab-strip stagioni interattiva con griglia episodi cliccabili che puntano al workflow "Play VLC" del tenant; per i FILM mostra un singolo bottone PLAY con link signed proxy. È il "detail UX" della stack Streammy: senza questo nodo il workflow autore deve scrivere ~400 righe di JSX SSR + media query CSS + season-tab JavaScript. Differenza con i sibling: action_streammy_detail_page = HTML SSR pronto-browser per UN titolo specifico con tab stagioni. Per griglia Netflix-style di N titoli (catalog home) usa action_catalog_page. Per estrarre dati grezzi senza render usa action_streammy_catalog mode=search per ottenere il titolo singolo. Per ottenere l'URL HLS dato titleId+episodeId usa action_streammy_resolve. Routing parameters: `titleId` (numerico provider) e `season` (1-N per serie) arrivano da query-string del webhook trigger (`?titleId=60265&season=2`) OPPURE da config statica se il workflow gestisce un singolo titolo permanente. Default season=1 se assente. Per film il season e\` ignorato. Template HTML responsive built-in: hero section full-width con poster portrait + metadata overlay (titolo + tagline + anno + duration + score TMDb-like). Per serie: tab-strip orizzontale season-selector con highlight active + episode grid 4-col desktop / 2-col tablet / 1-col mobile. Bottone "Play VLC" per ogni episodio con link `cardLinkTemplate` configurabile (placeholder `{titleId}`/`{episodeId}`/ `{slug}`/`{season}`/`{episode}` interpolati). Per film: singolo CTA "Play VLC" centrale full-width. Customizzazione: il `cardLinkTemplate` punta tipicamente a `/webhooks/c/streammy/ play-vlc/<token>?titleId={titleId}&episodeId={episodeId}&slug={slug}` — quel workflow esterno chiamera\` action_streammy_resolve + action_stream_proxy + action_vlc_playlist per produrre il file .m3u finale download. Theme color override + footer copy custom per branding tenant. Use case Cappella-Sistina-grade: (1) **Streammy detail page WF1** consumer-facing — webhook `/webhooks/c/streammy/title/<token>?titleId=N&season=M` triggera detail_page render → webhook_respond HTML. L'utente vede serie episodi cliccabili. (2) **share link via Telegram bot** — bot riceve titleId, costruisce URL detail + invia link preview con poster. (3) **embed iframe blog vendor partner** — il partner mostra catalogo Streammy dentro la propria UI via iframe pointing al detail_page url. (4) **player web hls.js standalone** — il bottone Play VLC e\` rimpiazzato con modal hls.js player browser-native (no download M3U richiesto, tutto in-page). Safety budget: SSRF guard sui fetch vendor, host-circuit-breaker per provider, timeout 12s, max poster bytes 5 MB, HTML output max 500 KB (oltre → warning), audit log con titleId + season + render duration. XSS-safe: tutti i campi metadata estratti vendor-side passano per escape HTML prima del render (un poster_alt malicious non puo\` iniettare script).

Cerca la stessa query in parallelo su N provider Streammy (StreamingCommunity, CB01, AnimeUnity, GuardaSerie, GuardaFlix, StreamingITA, AnimeSaturn, AnimeWorld, AltaDefinizione01) — restituisce array titoli mergiato pronto per action_catalog_page renderer con groupByProvider=true. È il "fan-out + merge" pattern enterprise: il workflow autore non scrive boilerplate Promise.allSettled. Differenza con i sibling: action_streammy_search_multichannel = N provider in parallelo con merge unificato (1 query → N risultati taggati). Per single-provider con paginazione completa usa action_streammy_catalog mode=search. Per rendering HTML del risultato usa action_catalog_page groupByProvider=true (raggruppa per sezione provider con header). Resilient by design: ogni provider gira in fan-out con AbortController separato — un canale lento (>15s) o morto (HTTP 5xx) NON blocca gli altri (anti-pattern n8n che farebbe loop sequenziale con 9 fail = 90s timeout). I provider OK contribuiscono i loro hit, i fail finiscono in `pipelineLog[].errors` per audit + alert. Wall-clock cap totale `totalTimeoutMs` (default 45s) chiude tutti i provider ancora in-flight. Schema output unificato cross-provider: `{ titles: [{ id, slug, name, year, poster, provider, score, type }], errors: [...], stats: { providersOK, providersFail, titlesTotal, durationMsTotal }, pipelineLog: [{ provider, status, durationMs, count }] }`. Il downstream consuma `titles[]` cieco al provider, ma `provider` tag e\` disponibile per branching (es. "filtra solo SC" downstream). Anti-rate-limit per-provider: max 1 query/sec per provider (configurabile per chi ha account VIP), retry 1x su 429 con backoff 2s, NO retry su 5xx (provider down non si recupera in 5s). Cache LRU 5min sulla query stessa per evitare double-hit quando lo stesso utente cambia idea + ricarica. Use case Cappella-Sistina-grade: (1) **search bar Streammy** consumer-facing — form GET trigger → search_multichannel su 6 provider → catalog_page render con groupByProvider, l'utente vede risultati raggruppati "StreamingCommunity (12)", "CB01 (3)", "AnimeUnity (8)" senza dover sapere cosa sono; (2) **deduplicate cross-provider** — pipeline che cerca "Inception", trova 3 hit (SC + CB01 + AnimeUnity), il workflow downstream applica fuzzy-match su `name+year` → sceglie il provider con score migliore + fallback al secondo se resolve fail; (3) **autocompletamento search bar** — webhook chiamato as-you-type con debounce 300ms, ritorna top-5 per provider, UI mostra suggestion list; (4) **monitoring catalog parity** — cron che cerca 100 titoli campione su tutti i provider, calcola Jaccard similarity tra cataloghi, alert se un provider scende sotto soglia (= rotazione contenuti o downtime parziale). Safety budget: SSRF guard, host-circuit-breaker per provider (vendor down → skip invece di accumulare timeout), maxTotalTitles cap 2k, maxPerProvider cap 500, perProviderTimeoutMs default 15s, totalTimeoutMs default 45s wall-clock, telemetry OTel con span fan-out + per-provider + merge. Audit log con query hash + providersOK/Fail + titlesTotal per detect query suspect (es. "best of" che butta 10k titoli = AI-abuse pattern).

Stream proxy enterprise per CDN HLS che emettono token IP-locked (vixcloud, vidplay, similar) — risolve il dual problem "il token e\` legato all'IP del server che l'ha richiesto, ma VLC del client gira da IP diverso → 403 Forbidden". Il proxy inietta server-side Referer + User-Agent corretti verso l'upstream + firma HMAC ogni hop per prevenire signed-URL leak. Differenza con i sibling: action_stream_proxy = proxy HLS bidirezionale (seed + serve modes) con rewrite m3u8 ricorsivo. Per ottenere l'URL HLS master dato un titolo usa action_streammy_resolve. Per packaging finale in wrapper M3U file scaricabile da VLC usa action_vlc_playlist. Stream proxy si interpone tra l'utente VLC e l'upstream CDN — gli altri nodi sono pipeline-side (resolve = discovery, vlc_playlist = packaging). Due modes simmetrici: (a) **seed** — workflow Play step. Input: `upstreamUrl` (master playlist URL fresca da resolve). Output: body M3U wrapper con singolo URL signed `?u=<base64>&e=<exp>&sig=<hmac>` puntante a `/webhooks/c/stream/proxy.m3u8/<token>`. Il client VLC scarica il wrapper, segue il link signed che va al nostro server, che a sua volta fetcha l'upstream con Referer corretto. (b) **serve** — webhook handler. Riceve request VLC con `u/e/sig` query string, verifica HMAC + non-expired, fetcha upstream con header iniettati, se la response e\` m3u8 (master/media) riscrive RICORSIVAMENTE ogni URI interno (variant playlist, audio track, subtitle, encryption key, init segment, video segments .ts) con URL signed puntanti di nuovo a noi → la catena fino al singolo segment .ts e\` tutta proxata, niente leak del CDN reale verso il client. Path naming `.m3u8` nel route: il customPath del trigger e\` `/stream/proxy.m3u8` invece di `/stream/proxy` per workaround bug VLC 3.0.23 Mac (con demux=any non onora Content-Type per scegliere demuxer, usa extension nel URL path). VLC Linux/Windows funziona con entrambi. HMAC signing scheme: signature = HMAC-SHA256(secret, `${u}|${e}`), exp 7200s default (2h — sufficiente per finire visione 1080p), secret per-tenant rotabile via Settings → Streammy. Anti-replay: dopo `e` il proxy rifiuta 410 Gone. Range header pass-through (RFC 7233) per VLC seek (drag scrubber su minuto X → range bytes=START-END verso upstream → 206 Partial Content mirroring Content-Range). Use case Cappella-Sistina-grade: (1) **Play VLC workflow** consumer-facing — utente clicca su episodio → resolve master playlist → seed mode emette wrapper M3U → action_webhook_respond download .m3u → VLC apre + chiama serve mode per ogni hop → playback fluido anche da rete del client; (2) **VLC seek su rete mobile lenta** — utente skippa a minuto 45 di un film 2h → Range header forwarded → CDN serve 206 partial → buffering minimo (no full-segment download); (3) **anti-leak signed URL** — se un utente condivide il file .m3u (es. Telegram link), il link funziona solo finche\` exp non scade + il secret HMAC tenant non viene ruotato; (4) **multi-quality variant switching** — il master playlist contiene variant 480p/720p/1080p, VLC sceglie la qualita\` in base a bandwidth, il proxy non blocca: rewrite del variant URI mantiene la stessa logica di firma per ogni quality. Safety budget: SSRF guard su upstream fetch, host-circuit-breaker per CDN (vixcloud down → 502 immediato invece di accumulare timeout), max body streaming infinito (binary pass-through) ma rate-limit per token (1 sessione attiva per token per IP), timeoutMs default 30s connect, audit log su ogni serve mode hit con token + IP client + bytes transferred per cost monitoring.

Renderer HTML Netflix-style griglia poster per cataloghi titoli — SSR completo senza React runtime, output stringa pronta per action_webhook_respond. Consuma array di titoli normalizzati (da action_streammy_catalog o action_streammy_search_multichannel) e produce griglia responsive auto-fit con design system inline (zero CSS file servito, tutto inline → first paint < 100ms anche su mobile 3G). Differenza con i sibling: action_catalog_page = griglia LISTING di N titoli (home/search/genre view). Per la pagina DETAIL di un singolo titolo con tab stagioni + episode grid usa action_streammy_detail_page. Per il packaging M3U del singolo titolo selezionato usa action_vlc_playlist. Design system inline production-grade: griglia CSS Grid auto-fit minmax(140px, 1fr) → mobile 2-col, tablet 4-col, desktop 6-col, 4K 8-col senza JS resize handler. Performance hints HTML5: `loading="lazy"` su poster N+1 (eagerCount configurabile per LCP), `decoding="async"`, `fetchpriority="high"` su poster 1-4. SEO: meta og:image, og:title, twitter:card, schema.org Movie/TVSeries JSON-LD per ogni card. WCAG AA: contrast checked, focus visible, alt text on poster (auto-derivato dal name). Features: search bar opzionale (con `searchUrl` config) — produce form GET che chiama altro workflow downstream (tipicamente streammy_search_multichannel + render again). GroupByProvider opzionale (per search multi-canale) — invece di griglia piatta mostra sezioni `<h2>StreamingCommunity (12)</h2>` + griglia per ogni provider con icona riconoscibile. Theme override (palette swappable via data-theme="emerald|violet|amber" su <html>). Anti-XSS by-construction: ogni stringa interpolata (name/plot/posterUrl/genres) passa per `escapeHtml` che neutralizza `&<>"'` → un titolo malevolo con `<script>` non puo\` iniettare JS nel browser dell'utente. cardLinkTemplate placeholder (`{titleId}`, `{slug}`, `{provider}`) NON sono escaped (sono controllati dall'autore workflow), ma il rendering li passa attraverso encodeURIComponent prima di costruire href. Use case Cappella-Sistina-grade: (1) **Streammy home page** consumer-facing — webhook trigger → streammy_catalog browse limit 60 → catalog_page render → webhook_respond HTML. L'utente vede griglia Netflix-style con search bar; (2) **Search result page multi-canale** — search_multichannel → catalog_page groupByProvider=true → render sections con ogni provider header; (3) **dashboard B2B vendor partner** — il partner consuma il nostro catalogo via iframe pointing al webhook che restituisce catalog_page custom-themed (palette partner brand); (4) **SEO landing page** prodotti per acquisition organic — catalog_page genera HTML statico con JSON-LD Movie schema → Google index → traffico organico SERP. Safety budget: max 500 cards per render (oltre → truncate con "Mostra altro" link), max HTML output 2 MB, anti-XSS automatico, anti-DoS via cap cardsRendered, audit log con titoli count + render duration. CSP-friendly: zero `style=""` inline (tutto in `<style>` block), zero `onClick=""` (link puri).

Packager M3U/M3U8 VLC-compatibile per uno (mode=single) o piu\` (mode=multi) stream URL, con direttive `#EXTVLCOPT:http-referrer` e `#EXTVLCOPT:http-user-agent` iniettate per bypass del Referer/UA check upstream. Output stringa pronta per action_webhook_respond come file download (`Content-Disposition: attachment`). Differenza con i sibling: action_vlc_playlist = builder M3U OUTBOUND (URL → file .m3u client-downloadable). Per leggere/parsare un M3U INBOUND (file → URL extraction) usa action_iptv_m3u. Per il proxy server-side che VLC chiama dopo aver aperto il .m3u usa action_stream_proxy. Per IL singolo URL HLS dato un titolo usa action_streammy_resolve. Sintassi M3U builder: emette `#EXTM3U` header → per ogni entry `#EXTINF:N,title` (N=0 live marker preferito da VLC su wrapper / N=-1 RFC 8216 unknown duration / N>0 durata VOD), `#EXTVLCOPT:http-referrer=<url>`, `#EXTVLCOPT:http-user-agent=<UA>`, poi la URL stream. Multi-mode emette un blocco per ogni entry (fino a 500 entry, utili per playlist intere stagioni serie TV). Estensione filename critica per VLC Mac (gotcha noto 2026-06-05): VLC parsa `.m3u8` come HLS strict RFC 8216 + IGNORA `#EXTVLCOPT` → senza Referer upstream rifiuta 403 → black video. `.m3u` invece e\` parsato come stream-list VLC-style con `EXTVLCOPT` onorato. Default filename `.m3u` quindi (era `.m3u8` pre-2026-06-05, fix in dedicate sprint). `omitExtinf=true` per software che non parsa EXTINF (mpv/ffmpeg bare). Output sentinel `__webhookResponse` (raccolto da action_webhook_respond runtime): `{ m3u: "<content>", contentType: "application/vnd.apple.mpegurl", downloadHeaders: { Content-Disposition: attachment; filename="..." }, base64?, filename }`. Il filename supporta placeholder `{titleId}/{episodeId}/{slug}` per nomi file business-friendly tipo `streammy-cape-fear-60265-346967.m3u`. Use case Cappella-Sistina-grade: (1) **Play VLC button** consumer-facing — utente clicca → resolve master playlist → stream_proxy seed → vlc_playlist packaging → webhook_respond download .m3u. VLC apre + va via proxy. (2) **Bulk playlist stagione TV** — utente vuole intera S03 di una serie → loop su 10 episodi → ognuno via resolve → vlc_playlist multi-mode produce singolo .m3u con 10 entry, doppio click in VLC apre playlist con auto-next. (3) **VLC playlist IPTV M3U** — riusabile per broadcasting canali live (input array N canali con Referer custom per ognuno). (4) **export per smart TV** — il .m3u funziona anche su VLC Android TV / IPTV Smarters con stesse EXTVLCOPT directives. Safety budget: anti-injection nelle directive (CR/LF/null/leading-# sanitizzati su ogni stringa user-supplied), filename sanitization (no path traversal), max 500 entry per playlist, output max 10 MB. Audit log con count entries + filename per identificazione playlist abuse-prone.

Estrattore generico stream URL (HLS/MP4/DASH) da pagine embed arbitrarie — cascata di 6 strategie pure parsing applicate in ordine configurabile, primo match vince + log evidence per audit. È il fallback resilient quando action_streammy_resolve non e\` applicabile (vendor non-Streammy) o quando serve estrazione da player embed standalone (YouTube-like, JWPlayer hosted). Differenza con i sibling: action_generic_extractor = parser stateless HTML → URL stream (1 page → 1 URL extracted). Per pipeline Streammy-specific con 4-stage Inertia decode usa action_streammy_resolve (piu\` strutturato). Per esecuzione JS completa (SPA + browser headless) usa action_browser_render → poi questo. Per orchestratore AI adaptive che sceglie strategia da solo usa action_scrape_smart. Sei strategie cascade-fallback (ordine configurabile via priority): (1) **JWPlayer setup** — cerca `jwplayer().setup({ file: "..." })` JS literal (standard JWPlayer 7+); (2) **<video><source>** — HTML5 nativo, supporta multi-source per quality; (3) **JSON-LD VideoObject** — schema.org metadata embedded (`contentUrl` field), affidabile su siti SEO-friendly; (4) **og:video meta** — OpenGraph header tag, usato da Facebook/ Twitter share preview; (5) **<iframe src=*.m3u8>** — embed iframe nested che punta direttamente a master playlist; (6) **JS string literal regex multi-pattern** — cerca `"file": "https://...m3u8"` / `videoUrl: "..."` / `src: "..."` con quote variants, ultima spiaggia. Output: `{ streamUrl, type: "hls"|"mp4"|"dash"|"unknown", source: "<strategy>", headers: { Referer, User-Agent? }, attempts: [{ strategy, matched: boolean, evidence }] }`. `attempts[]` per troubleshooting: se nessuna strategia matcha, mostra cosa ognuna ha trovato (o non trovato) → autore workflow capisce dove aggiungere fallback custom. Use case Cappella-Sistina-grade: (1) **fallback Streammy** quando resolve fail su un provider nuovo non-mappato — generic_extractor cerca pattern universal; (2) **ingest broadcaster** che fornisce embed iframe per spot pubblicitario (JWPlayer hosted) — estrae direttamente HLS, packaging vlc_playlist per download archivio legale; (3) **monitor uptime video pubblicato** — cron che estrae URL + fa HEAD su master playlist per check 200 OK (alert se 404 → contenuto rimosso); (4) **archive social media** — pagina Twitter/Instagram con video embedded, og:video meta presente → estrai URL per archivio cold storage. Safety budget: SSRF guard via safeFetch, host-circuit-breaker per vendor, timeout 10s, max HTML parse 5 MB, audit log con strategy matched + source URL per detect pattern abuse-prone.

Parser M3U/M3U8 IPTV INBOUND — decodifica playlist esistenti (file da disco o URL fetched o string config) in array di entry strutturate, schema uniforme pronto per logic_loop/db_insert downstream. È l'inverso di action_vlc_playlist: round-trip parse(build(x)) === x garantito da test contract. Differenza con i sibling: action_iptv_m3u = M3U → array structured (parsing inbound). Per array → M3U file download usa action_vlc_playlist (builder). Per estrarre URL stream da pagina embed HTML (non M3U) usa action_generic_extractor. Estrazione direttive M3U complete: per ogni entry parsa `#EXTINF:duration,title`, attributi `tvg-id`, `tvg-name`, `tvg-logo`, `group-title` (gruppi IPTV broadcaster), `channel-id`, e tutte le direttive `#EXTVLCOPT:` (http-referrer, http-user-agent, network-caching, cookies custom). Direttive non-standard preservate in `raw` per pass-through senza loss. Features production: filtri groupFilter (regex match su group-title — es. `"^Sport"` per estrarre solo canali sportivi), titleFilter (regex su title — es. `"HD$"` per solo canali HD), allowlist schemi URL (http/https/rtmp/rtsp — blocca file:/// e dav:// per safety), cap entry (default 10k anti-DoS — un .m3u da 100k canali del black market = workflow crash) e cap righe totali (default 500k). Output: `{ entries: [{ url, title, durationSec, attrs: { tvg_id, tvg_name, tvg_logo, group_title }, vlcOpts: { http_referrer, http_user_agent, ... }, raw }], stats: { total, filtered, schemes: { https: N, rtmp: M } } }`. Format consumabile da logic_loop per applicare azione per-canale (db_insert per import CRM IPTV provider, action_send_email per notify nuovi canali aggiunti, ecc.). Use case Cappella-Sistina-grade: (1) **import bouquet IPTV** del proprio account broadcaster — fetch .m3u dal vendor → parse 500 canali → db_insert su tabella `canali` per dashboard interna (chi guarda cosa, qual\` il piu\` popolare); (2) **filtro family-safe** per playlist condivise — parse + applica deny-list group-title (no adult/gambling) → rebuild con vlc_playlist filtered → distribuzione a sub-account aziendali; (3) **monitor uptime canali** — cron quotidiano che parse playlist + per ogni URL fa HEAD check → alert se >10% canali down; (4) **migrazione vendor IPTV** — parse playlist vendor A + transform schema → rebuild vlc_playlist per vendor B (es. cambio provider mantenendo group structure). Safety budget: cap entry 10k, cap righe 500k, sanitization su title/attrs (no CR/LF injection), schema allowlist configurabile, audit log con file size + entries parsed + filtered_out count.

Resolve del primo host raggiungibile in una lista di candidati ordinati, con probe HTTP HEAD/GET + opzionale `markerRegex` su body per content-aware match (no falsi positivi su parking page). Pensato per siti che cambiano TLD settimanalmente per ban registrar (StreamingCommunity `.company` → `.loans` → `.fund` → `.cash`): il workflow non hardcoda mai un TLD specifico, mette questo nodo come primo step e usa `output.liveHost` come `baseUrl` per ogni nodo Streammy* successivo. Differenza con i sibling: action_domain_rotator = HEAD/GET probe rapido per selezione host (1 probe → 1 host scelto). Per HTTP completo verso host noto usa action_http. Per fetch con header browser preset usa action_web_fetch_advanced. Per multi-provider search-style (cerca lo stesso titolo su N provider, no selezione single) usa action_streammy_search_multichannel. Probe strategy: sequenziale con first-success-wins (vs Promise.race parallel che sprecca request a hostname che poi non userai). Ogni candidato passa per safeFetchWithRedirects (SSRF guard) con HEAD `/` (zero bytes scaricati) o GET `/` con markerRegex (per discriminare parking page vs vero sito — utile quando un registrar fa parking + redirect ad ads). HEAD/GET timeout configurabile default 5s per candidato, wall-clock budget totale `maxAttemptsMs` (default 25s) per evitare runaway su lista lunga di 50 TLD futuri. Cache LRU in-process: per (tenant_id, primary_candidate) memorizza il host vinto per `cacheTtlMs` (default 5min). Workflow batch (es. resolve 100 titoli in fila) probano una sola volta a inizio batch invece di 100 volte. Cache hit mostrato in `output.cacheHit: true` per audit. Output: `{ liveHost: "https://...", attemptsLog: [{ host, status, durationMs, markerMatched }], cacheHit, totalDurationMs }`. attemptsLog espone OGNI hop per troubleshooting — quando "no host live" emerge in produzione, gli attempts mostrano se i candidati nuovi sono pure 404 o solo timeout / DNS fail. Use case Cappella-Sistina-grade: (1) **resilienza Streammy** — primo step workflow Catalog/Resolve sceglie il TLD live di StreamingCommunity tra 8 candidati noti, dynamic vendor monitor riempie la lista nuovi TLD trovati; (2) **multi-CDN failover** per propri asset — primary CloudFront → fallback Cloudflare R2 → fallback DigitalOcean Spaces, ogni probe verifica markerRegex "X-Custom-Header"; (3) **mirror Wikipedia/archive.org** per ingest content high-availability — probe en./it./de./fr. + archive.org wayback; (4) **monitoring IP rotation propri server pool** — health check pre-request per evitare di colpire pod down. Safety budget: SSRF guard, host-circuit-breaker (host marked-bad evitato 30s), maxAttemptsMs wall-clock cap, per-candidate timeout, cache TTL bounded, max candidates list 50 (oltre = pattern abuse), audit log con liveHost + cacheHit + attempts count per cost monitoring.

Connettore enterprise per Odoo Community ed Enterprise (versioni 14, 15, 16, 17, 18) via protocollo XML-RPC nativo sugli endpoint /xmlrpc/2/common e /xmlrpc/2/object. Cinque operazioni atomiche coprono il ciclo CRUD completo: search_read leggi record con domain filter (SELECT con WHERE Odoo-style), create per inserire una nuova istanza di un modello (INSERT), write per aggiornare record esistenti (UPDATE), unlink per la cancellazione logica (DELETE rispettando i record rules), call_method per invocare qualsiasi metodo Python esposto dal modello (action_confirm, message_post, action_invoice_create, ecc.). Tutte le chiamate transitano sempre attraverso l'ORM Odoo: rispettano i record rules per-utente, le ACL, i validatori server-side (api.constrains), le compute fields, gli automated actions e popolano il chatter + audit log Odoo come se l'azione fosse fatta da un utente reale dell'interfaccia web. NESSUNA esecuzione SQL diretta sul Postgres backend: zero rischio di bypass di sicurezza o corruzione di dati derivati. Cache automatica dell'uid di sessione per ridurre i due roundtrip authenticate iniziali al primo call (TTL 15 minuti, invalidata su 401). Supporta API Key Odoo 14+ raccomandata in produzione (bypass 2FA, revocabile, non scade). Use case: sincronizzazione contatti tra form web e res.partner Odoo, creazione automatica di lead CRM da email PEC dello studio commercialista, aggiornamento stato fattura account.move via call_method action_post, lookup anagrafica fiscale partita IVA per matching cliente nella pipeline di onboarding, batch reporting estraendo report Qweb in PDF per controllo di gestione mensile.

Invia messaggi WhatsApp Business via Meta Cloud API ufficiale (Graph v18+) usando i due regimi del protocollo: messaggi text in finestra di conversazione (validi solo nelle 24 ore successive a un messaggio in ingresso del cliente, secondo le policy Customer Service di WhatsApp Business) oppure messaggi template pre-approvati nel Business Manager (UTILITY, MARKETING, AUTHENTICATION) inviabili in qualsiasi momento. Supporta header media (immagine, video, documento, location), placeholder body con sostituzione posizionale (variabili numerate {{1}}, {{2}}, ...), bottoni quick-reply/url/call e lingua multipla. Validazione formato numero E.164 obbligatoria (+393331234567) con conversione automatica dai formati nazionali comuni. Rate limit Meta rispettato con backoff esponenziale e jitter. Errori semantici espliciti: 132xxx (template), 131xxx (numero), 80007 (rate). Output: { messageId, recipient, mode, response, billable, conversationCategory }. L'integrazione passa SOLO per Phone Number ID assegnato dall'app WhatsApp Business dedicata — nessun accesso al numero personale del proprietario. Costi conversazione visibili in Insights Meta. Use case: notifica spedizione e-commerce con tracking number via template UTILITY, conferma appuntamento studio commercialista 24h prima con template AUTHENTICATION, ricezione documento via media header (cliente invia foto fattura → workflow estrae con OCR e crea fattura in Odoo), broadcast newsletter MARKETING con opt-out tracciato, escalation supporto tecnico real-time durante la finestra 24h con messaggi text plain.

Classificatore PEC (Posta Elettronica Certificata) conforme allo standard italiano AgID DPCM 02/11/2005 + Linee guida 2024. Ispeziona gli header tecnici della busta MIME (X-Ricevuta, X-Riferimento-Message-ID, X-TipoRicevuta, X-Trasporto, X-Mittente) e instrada il workflow su una sola delle 4 branch uscenti: received_message (PEC ordinaria in ingresso da un altro mittente certificato — va processata e archiviata per legge), acceptance_receipt (ricevuta di accettazione dal gestore mittente che conferma la presa in carico, valore legale come timbro postale), delivery_receipt (ricevuta di consegna dal gestore destinatario che attesta il deposito nella casella ricevente, equivalente alla raccomandata A/R), rejection (avviso di mancata consegna, mailbox piena, dominio non PEC, virus — tracciabile per riprovare o escalation). Pattern branching: l'engine FlowForge segue SOLO l'edge della branch scelta (chosenBranch), evitando fan-out errato sulle altre 3 branch downstream. Vincolo: usare SUBITO dopo trigger_imap_pec come primo step dispatcher — l'ordine errato porterebbe a classificare email non-PEC con header generici (falso positivo). Output: { branch, headersParsed, messageRef, originalMessageId, transportInfo, gestoreCertificato }. Use case: studio commercialista riceve 200 PEC/giorno — separare le ricevute (archivio passive) dai veri messaggi cliente (workflow di lavorazione), conformità Codice CAD art. 48 per evidenza legale invio fattura, dashboard amministrativo che mostra solo "PEC inevase" filtrando ricevute automatiche, riconciliazione PEC in uscita (find acceptance + delivery matching tramite X-Riferimento-Message-ID), alerting su rejection che ferma uno scadenziario fiscale (es. consegna fattura SDI scaduta).

Normalizzatore email pre-LLM enterprise: trasforma un oggetto RawEmail (subject, body, headers, attachments) in un payload denso e token-efficient pronto per un classifier downstream a base di prompting o agent LLM. Estrae mittente normalizzato (lowercase, validazione RFC 5321), dominio del sender per matching domain allowlist/blocklist enterprise, soggetto pulito da prefissi noise tipo "Re:", "Fwd:", "AW:", "Tr:", "R:", "Risp:" (multilingua) e suffix marketing "[Newsletter]". Tronca il body a una soglia configurabile (default 4000 char) preservando la prima parte del messaggio dove l'umano ha più probabilmente messo la richiesta chiave. Riassume gli allegati raggruppandoli per MIME type (3 PDF, 1 XLSX, 2 immagini) invece di passare metadati granulari. Indovina la lingua via euristica fast (it/en/es/fr/de) sulla porzione di testo. Calcola signals euristici: urgenza (parole come "urgente", "scadenza", "ASAP", presenza di "!!" multiple), PEC (dominio nell'allowlist provider certificati + header X-Riferimento), newsletter (List-Unsubscribe header, mittente noreply@, footer "se non vuoi più ricevere"). Output: { senderEmail, senderDomain, subjectClean, bodyTextShort, attachments, languageGuess, urgencySignals, isPec, isNewsletter, messageId, headers }. Riduzione token osservata: 70-90% rispetto al passare la RawEmail al LLM. Use case: pre-step di un agent LLM di classificazione per studio commercialista (riduce costo Liara per email cliente da 800 a 80 token in input), filtro newsletter prima di un flow human-review (skip se isNewsletter=true), routing dinamico via switch per PEC vs ordinaria, alerting su signal urgency per inoltro al titolare studio, pre-validazione dominio mittente contro blocklist anti-phishing.

Sanitizer enterprise per il body di email destinate a un LLM downstream. Rimuove deterministicamente quattro classi di rumore che gonfiano i token senza aggiungere valore semantico al messaggio originale dell'utente: (1) reply quotata multilingua — riconosce "On 2026-01-15, X wrote:" (EN), "Il giorno X ha scritto:" (IT), "Le DD/MM, X a écrit:" (FR), "Am DD.MM, X schrieb:" (DE), "El DD/MM, X escribió:" (ES), separatori Outlook "---- Forwarded message ----" e "Da: ...", catene "Re: Re: Re:" annidate, e tagli su 4+ righe prefissate ">" consecutive (quoting RFC 3676); (2) firme email — pattern RFC 3676 "-- " (dash dash space) + signature mobile "Inviato da iPhone/Android/Mail per Windows", blocchi contatto Nome/Ruolo/Telefono/Email separati da newline doppi alla fine messaggio; (3) disclaimer legali GDPR-IT, privacy-EN, "questo messaggio e i suoi allegati sono confidenziali...", "if you are not the intended recipient please delete...", banner aziendali standard con link sito web/sede legale/codice fiscale; (4) tracking URL — rimuove query string UTM (utm_source, utm_medium, utm_campaign, utm_content, utm_term) + parametri pixel proprietari (gclid Google, fbclid Facebook, msclkid Bing, mc_cid Mailchimp, oly_anon_id Oracle) senza toccare URL puliti. Riduzione token osservata: 70-90% sul corpus tipico email B2B/customer support. Effetti collaterali sull'accuratezza LLM downstream: +12-18% di accuratezza nel classifier perché il contesto resta focalizzato sul testo originale e non è diluito da firme/disclaimer ricorrenti. Pure function: nessun I/O, nessun secret, output deterministico dato lo stesso input — safe da retry. Use case: pre-step di un workflow customer support che usa LLM per detection sentiment + reply suggestion, normalizzazione di archivio email storico prima di indicizzazione vettoriale per RAG retrieval, riduzione costo Liara/Anthropic per cliente con 500 email/giorno, defense-in-depth contro prompt injection nascosto nei disclaimer (alcuni attaccanti li usano come carrier), preparazione corpus per fine-tuning interno.

Router di confidence enterprise che implementa il pattern Human-in-the-Loop per workflow AI-assisted production-ready. Confronta una metrica numerica di confidence (tipicamente 0.0 → 1.0) prodotta upstream da classifier LLM (agent_email_triage, agent_email_triage_commercialista, agent_summarizer), modelli computer vision (action_vision_extract), scraper AI (action_scrape_smart) o pipeline OCR, contro una soglia minima configurabile (default 0.70) abbinata a una lista di label "sensitive" che forzano comunque il branch review indipendentemente dalla confidence (es. label "legal_dispute", "fraud_suspected", "regulatory_complaint", "vip_customer", "executive_request" — categorie dove il rischio di errore costa più del ritardo umano). Emette uno dei due output branch del contratto: "auto" quando confidence ≥ soglia AND label non sensitive (il workflow prosegue senza intervento — bassa latenza, zero overhead operativo), "review" quando confidence < soglia OR label sensitive (il flusso si ferma e l'operatore umano riceve un task in coda con tutto il contesto della decisione AI per validare, correggere o sovrascrivere). Audit reason esplicito nell'output: { branch, confidence, threshold, triggeringLabel?, autoApproved? }. Pattern di composizione: la branch "review" si lega tipicamente a action_send_email / action_whatsapp_send / action_email_send_tracked per notificare l'operatore (con link al record da revisionare) + logic_wait_signal per sospendere il run fino al callback umano (un'API HTTP segnata dal trigger_form della dashboard tenant), poi resume con la decisione finale; il branch "auto" prosegue direttamente al downstream. Vantaggio vs implementazione manuale n8n/Zapier: 3-4 nodi (if + switch + set + log) incapsulati in un unico nodo dedicato con audit + GDPR-safe reason code + UI hint per l'operatore. Use case: triage email cliente con confidence < 0.6 va a operatore (evita rispondere male a un cliente arrabbiato), classificazione fattura SDI con label "anomalia_iva" sempre revisionata da contabile, OCR fattura cartacea con confidence < 0.85 → human review per integrazione campi mancanti, sentiment analysis social con label "crisis_signal" sempre escalata al PR manager, decisione di erogazione bonus B2B sopra una soglia di importo sempre con review CFO indipendentemente dalla confidence dell'agent commerciale.

Archivia messaggi PEC (Posta Elettronica Certificata) in conformità alla normativa italiana sulla conservazione a norma di legge dei documenti informatici fiscali e amministrativi: DPR 445/2000 (testo unico documentazione amministrativa), DM 17/06/2014 (regole tecniche conservazione), AgID Linee Guida 2020 + aggiornamento 2024 (formato + metadati + impronta crittografica). Salva l'eml raw sul volume persistente del tenant in modalità append-only con umask 0600 (lettura/scrittura solo per il processo runtime proprietario, nessun accesso ad altri utenti del container — defense-in-depth contro lateral movement). Calcola tre digest crittografici dell'intero messaggio originale (SHA-256 minimum normativo, SHA-384 + SHA-512 per future-proof contro deprecation futura SHA-256 sopra 2030), li serializza in un sidecar JSON firmato. Registra timestamp ISO 8601 UTC certo (clock NTP del server) e durata conservazione configurabile (default 10 anni = 3650 giorni come da art. 2220 Codice Civile per documenti contabili, ma estendibile a 15 anni per atti societari o fatture immobiliari). Append a manifest.jsonl globale del tenant per audit di integrità e ricerca cronologica veloce O(1) senza listing fs. ArchiveId deterministico (SHA-256 di messageId + receivedAt ISO) → operazione idempotente: ricevere due volte la stessa PEC (es. retry IMAP dopo crash) produce lo stesso archiveId e NON duplica i file sul disco. Output: { archiveId, archivePath, hashes, manifestEntry, retentionExpiresAt, verifyHookUrl }. La ricevuta è verificabile crittograficamente in qualsiasi momento via hook action_pec_legal_archive_verify che ricalcola SHA dal file e confronta col manifest — utile per perizia legale o ispezione GdF. Per delegare la conservazione sostitutiva a un conservatore accreditato AgID (Aruba Doc, InfoCert, Namirial, Postel), concatenare un action_http verso la loro API REST passando archivePath + hash SHA-256 computati qui — il conservatore appone marca temporale eIDAS qualificata e firma TSL. Use case: studio commercialista archivia 200 PEC/giorno con conservazione 10 anni per contestazioni AdE, fattura ricevuta da fornitore B2B con conservazione 11 anni (5 + 6 prescrizione ordinaria), atti societari di una S.r.l. cliente con conservazione 15 anni, integrazione automatica con Aruba Doc per delega legale, forensic export di tutte le PEC ricevute in un mese per audit auditor esterno.

Wrapper enterprise specializzato sopra action_odoo_rpc che incapsula la ricerca di una res.partner in Odoo con strategia multi-campo deterministica nel rispetto della cascata di affidabilità tipica di un'anagrafica commerciale italiana: cerca prima per Partita IVA (univoco per legge, formato IT99999999999 con validazione checksum), poi per codice fiscale persona fisica (16 char alphanumeric con check), poi per email business (univoca nel 95% dei casi), poi per numero di telefono normalizzato E.164 (rimuovendo spazi e prefissi duplicati), infine per nome aziendale con similarity matching ilike (last resort, sensibile a typos). Riduce drasticamente la complessità di configurazione del nodo generico action_odoo_rpc: dai 15+ campi tecnici (model, operation, domain JSON con triple [campo, operatore, valore], fields array, limit, order, ecc.) a soli 4-5 campi human-readable inseribili in 30 secondi da un commercialista non-developer. Opzione createIfMissing: se la ricerca non produce match, crea atomicamente il partner con i dati forniti in input (1 chiamata RPC aggiuntiva nell'esecuzione, transazione atomica server-side Odoo — nessun rischio di partial state); senza questa opzione semplicemente ritorna found=false per gestione downstream esplicita. Output strutturato pronto per workflow downstream: { found, partnerId, name, email, phone, vat, fiscalCode, companyId, customerRank, supplierRank, isCompany, createdNow, matchedBy }. Vantaggio vs n8n/Make/Zapier: in quelle piattaforme servono un SET node che costruisce il domain JSON + un Odoo node configurato a mano con sintassi domain complessa + un IF node per createIfMissing branch — totale 3-4 nodi ingestibili da un commercialista. Qui è un nodo singolo con audit del campo che ha matchato. Use case: lookup automatico cliente da PEC ricevuta (parse mittente → cerca P.IVA in firma PEC → match in Odoo o crea nuovo prospect), normalizzazione anagrafica da form web e-commerce verso CRM Odoo, lookup partner per associare una fattura elettronica SDI in ingresso al cliente corretto via Codice Destinatario, dedup contatti tra Pipedrive imported e Odoo nativo (match per email + check ulteriore per VAT), arricchimento email entry-form prima di trasferimento contabile (recupera storico ordini precedenti).

Crea una opportunità nel pipeline CRM di Odoo (modello crm.lead) abbattendo la complessità tipica della sintassi XML-RPC many2many sui tag. Il modello crm.lead di Odoo richiede per i campi relazionali (tag_ids, user_id, team_id, partner_id) la sintassi "command Odoo" — array di tuple [(6, 0, [id1, id2])] dove 6 significa "replace all relations" e 0 è un placeholder posizionale — sintassi notoriamente ostica anche per developer esperti e completamente fuori portata per un commercialista che vuole solo "aggiungere un lead da una PEC ricevuta". Questo nodo nasconde tutto: accetta i tag come array di stringhe leggibili (["interessato_fattura_elettronica", "studio_torino"]) e li risolve idempotentemente lato Odoo via crm.tag name_create — i tag esistenti vengono riutilizzati, quelli mai visti prima vengono creati ON THE FLY senza fallire il workflow per "tag inesistente". user_id (commerciale assegnato) e team_id (team di vendita) accettano sia ID numerico sia email/nome — la risoluzione avviene server-side con search per email in res.users. Bug noto fixato 2026-06-04: prima versione del name_create non era idempotente sotto race condition (due workflow concurrent con stesso tag → 2 record duplicati) — ora con SAVEPOINT + ON CONFLICT. Output: { leadId, success, lead: { name, email, phone, partnerId, tagIds, userId, teamId, expectedRevenue, probability, description, stageId, createDate } }. Campi coperti dal wrapper: name (titolo opportunità), email/phone/mobile, description (rich text Qweb), tagIdsByName (array stringhe), userIdByEmail, teamIdByName, expectedRevenue (decimal € EUR), probability (0-100), source (sorgente lead per analytics CRM: "PEC", "WhatsApp", "Web form"). Use case reali: input da action_pec_classify branch received_message → crea lead "Richiesta info da X" con tag "pec_inbound" e source="PEC" assegnato al commercialista in turno (round-robin via team_id); webhook from Calendly meeting booking → crea lead con expectedRevenue stimato da pacchetto selezionato; reazione a agent_email_triage_b2b_sales label "qualified_prospect" → lead in stage "Qualifying" con probability 30; integration LinkedIn Sales Navigator export → bulk create lead con tag "linkedin_outbound" e team_id "BDR".

Pianifica una mail.activity in Odoo — il meccanismo nativo di task assignment con scadenza che alimenta il pannello "Le mie attività" della sidebar Odoo e genera notifiche automatiche al responsabile. La attività va legata a un record arbitrario tramite il pattern res_model + res_id (polymorphic association): partner di anagrafica per follow-up commerciale, opportunità crm.lead per call di qualificazione, ordine sale.order per controllo pagamento, fattura account.move per rispondere a contestazione, ticket helpdesk.ticket per SLA escalation. Il campo activity_type_id richiede di sapere a memoria gli ID numerici delle activity types configurate nel tenant Odoo (4=To Do, 1=Email, 2=Call, 3=Meeting, ...) — informazione opaca per un utente non-tecnico. Questo nodo sblocca il lookup BY NAME: si passa "Da Fare", "Telefonata", "Verifica documenti" e il nodo risolve l'ID tramite ricerca exact-match su mail.activity.type (caching del risultato per workflow successivi nello stesso run). Date_deadline accetta sia ISO 8601 (2026-06-15) sia espressioni relative ("+3d", "+1w", "+2M") parsate localmente prima dell'invocazione RPC. User_id supporta sia ID che email per assegnazione a commerciale in vacanza con backup automatico al supervisor (lookup user_id con fallback su company.user_id parent). Output: { success, activityId, resolvedActivityType, assignedToEmail, dueDate, summary }. Le attività create alimentano il widget "Attività in scadenza" della dashboard Odoo e generano email automatica al user_id se attiva la configurazione Odoo "Send activity overdue notification". Use case: post agent_email_triage_commercialista con label "anomalia_iva" e confidence < 0.7 → crea mail.activity tipo "Da Fare" su crm.lead corrispondente con deadline oggi+2gg e summary "Controllo manuale classificazione IVA dichiarata"; post scadenza fattura B2B 30gg senza pagamento → activity "Telefonata" su account.move "Sollecito pagamento fattura n.X"; ingaggio nuovo cliente firma contratto → activity "Da Fare" su res.partner "Onboarding kit + accesso area riservata"; rinnovo abbonamento annuale 30gg prima della scadenza → activity tipo "Email" su sale.order parent "Invio offerta rinnovo".

Classifier rule-based specializzato per studi commercialisti italiani, knowledge embedded del lessico tributario italiano 2025-2026 (riforma fiscale, regime forfettario adeguato, F24 nuovo modello, fatturazione elettronica SDI 1.2.1, certificazione unica, comunicazione liquidazioni IVA, esterometro). Tag con 9 categorie di dominio mutuamente esclusive: fiscale (questioni IRPEF, deduzioni, detrazioni, dichiarazione redditi 730/Modello Redditi), iva (liquidazioni periodiche, esterometro, autofattura, reverse charge, split payment), f24 (deleghe di pagamento, F24 elide, ravvedimento operoso, compensazioni), forfettario (regime forfettario L. 190/2014, soglie 85k, contributi INPS gestione separata, fattura elettronica obbligatoria), sollecito (clienti morosi, mancato pagamento parcella, contestazione importo), pec_legal (PEC contenenti notifiche legali, decreti ingiuntivi, ricorsi tributari, atti AdE/Equitalia), payment (comunicazioni dirette su bonifici ricevuti, conferma pagamento parcella, richiesta IBAN), bilancio (chiusura bilancio annuale, nota integrativa, deposito CCIAA, revisione, certificazione), altro (catch-all per email non-pertinenti al dominio fiscale). Output: { label, confidence (0-1 derivata dal numero e specificità delle keyword matched), matchedKeywords (array di termini italiani specifici trovati, utile per audit + debug), suggestedOperator (default mapping: fiscale→commercialista_senior, iva→specialista_iva, forfettario→junior, ecc., overridabile via operatorsJson), suggestedReplyTemplate (placeholder reply context-aware: "Buongiorno {{nome}}, abbiamo ricevuto la sua richiesta sull'argomento {{label}}. La presa in carico è confermata, le risponderemo entro {{urgency_sla}} ore." con variabili pronte per nodemailer), urgencyTier (low/medium/high/critical derivato da signal "scadenza", "AdE", "termine", "ravvedimento", "ricorso") }. Pure function: nessun LLM call, nessuna chiamata di rete, deterministica con latenza < 5ms — eseguibile tranquillamente in pipeline real-time anche su 1000 email/giorno senza saturare il gateway LLM né incidere sui costi BYOK Anthropic/OpenAI del cliente. Pattern di composizione raccomandato: collegare l'output a flow_human_review_decision sulla confidence (soglia 0.7) — basso confidence o label "altro" routing alla coda umana del titolare studio; sull'altra branch auto-approved, agganciare action_email_send_tracked usando {{$node.triage.json.suggestedReplyTemplate}} come body e operatore assegnato da suggestedOperator. Use case: studio commercialista a Milano riceve 80 email/giorno — il triage automatizza 70% di smistamento verso il commercialista giusto senza interventi della segreteria; alerting su urgencyTier=critical per email da PEC AdE con "ricorso" o "ravvedimento" (notifica WhatsApp al titolare entro 5 minuti); riduzione costo risposta tipica da 12 minuti operatore a 2 minuti (read+conferma); arricchimento CRM Odoo con label come tag su crm.lead per analytics business; pre-step a un agent LLM più costoso quando confidence bassa.

Estende action_send_email con tracking comportamentale GDPR-safe: ogni email in uscita viene arricchita con un pixel di apertura 1x1 PNG trasparente servito da un endpoint HTTP del tenant (URL univoco per messaggio, no cookie) e tutti i link cliccabili nel body HTML vengono riscritti in URL di redirect tracciato /email-tracking/r/<token>?u=<dest> che logga il click e poi 302 verso la destinazione originale. Apertura e click finiscono nella tabella interactions del database tenant con timestamp, IP truncato (ultimi 64 bit zerati per GDPR pseudonimizzazione), user-agent normalizzato (categoria browser/email-client invece di string completa), e contesto del workflow (workflow_id, run_id, recipient_email_hash). Il dataset è immediatamente pronto come signal di lead-scoring: chi apre più volte = engagement alto; chi clicca su un link specifico di tariffario = intent commerciale forte; chi non apre dopo 7 giorni = candidato follow-up. Sicurezza: token HMAC-SHA256 firmato con chiave del tenant — impossibile per terzi forgiare apri/click fittizi anche con accesso all'URL; URL di click validati prima del redirect contro una whitelist di host derivata dal body originale (defense-in-depth contro open-redirect injection da workflow malformato); bot-UA noti (Googlebot, Slack Linkbot, Twitter Cardbot, OutlookOWASafelink, Microsoft Safelinks, Mimecast, Proofpoint) filtrati lato endpoint per evitare di contare "aperture" automatiche di security gateway nelle metriche reali. GDPR (artt. 6 + 7 e-Privacy): se requireConsent=true (default) e l'input upstream non porta esplicitamente consentVerified=true (bool), il nodo RIFIUTA l'invio con errore "MISSING_TRACKING_CONSENT" prevenendo invio inadvertente che esporrebbe a sanzioni Garante; consentEvidence (es. "form_signup_2026-01-15") può essere passato per audit log GDPR. Per email transazionali (conferma ordine, fattura, password reset) il consenso non è richiesto per legge (Considerando 47) ma il tracking sì — disable requireConsent solo per communications transazionali; per marketing newsletter MAI farlo. Output: { ok, messageId, trackingIds: { open, click }, pixelUrl, openTokens, clickTokens, recipients, consentEvidence }. Use case: studio commercialista invia preventivo personalizzato a 30 prospect — il dashboard mostra chi ha aperto due volte e cliccato il link al pacchetto, candidati ideali per follow-up telefonico nelle 24h successive; SaaS B2B invia drip campaign di onboarding e identifica utenti "dormienti" (zero apertura dopo email 3 di 5) per intervento sales; e-commerce dopo richiesta info → tracking apertura conferma + click sul link prodotto, dato che alimenta abandoned-cart workflow successivo; servizio professionale invia ricordo scadenza appuntamento, alerting se non aperto entro 4h dalla data prenotata (probabile no-show).

Variante batch di action_email_send_tracked progettata per outreach commerciali a volume controllato rispettando le policy anti-spam dei provider SMTP enterprise (Gmail/Workspace, Outlook 365, Yahoo, transactional ESP come Mailgun/Postmark/SES). Accetta una lista di destinatari dove ogni elemento porta il proprio leadId univoco (per tracking analytics differenziato), i propri valori di sostituzione template (es. { "nome": "Mario", "azienda": "ACME", "settore": "Edilizia" }) e opzionalmente un proprio override di subject — utile per A/B testing del soggetto su sottoinsiemi della lista. Il loop di invio è serializzato con throttling configurabile in mail/ora (default 60, sotto la soglia Gmail di 100/h per evitare flag reputation IP) e jitter random ±20% sul delay tra invii (defense contro detection pattern automation di Gmail Postmaster Tools). Backoff esponenziale (5s → 30s → 2m → 10m) su HTTP 429 oppure SMTP 421 (Service not available, troppe connessioni), con retry budget configurabile (default 3 retry per destinatario). Budget temporale globale: se l'esecuzione supera maxRunMinutes (default 50 minuti per stare sotto al timeout 60min default di nginx/Cloudflare), i destinatari non ancora processati vengono restituiti nel response array con flag requeued=true + last_error per essere ripresi dal cron upstream nel run successivo — pattern resumable enterprise vs all-or-nothing che blocca su grosse liste. GDPR gate identico al sibling singolo: requireConsent=true (default) richiede consentVerified=true per OGNI singolo destinatario della lista, non solo globale; un destinatario senza consenso viene saltato e segnato come { status: "skipped", reason: "missing_consent" } senza fallire l'intero batch. Output: { stats: { sent, failed, retried, skipped, requeued, totalMs, effectiveRatePerHour, avgLatencyMs }, results: [{ recipient, leadId, status, messageId?, trackingIds?, error?, attempts }] }. Use case: SaaS B2B drip campaign onboarding con 500 trial new signup/settimana → invio 60/h × 8h/giorno distribuiti su 2 giorni rispettando Gmail SLA; cold outreach lead scraped da LinkedIn con personalizzazione per settore — utile A/B test sul subject "Ciao Mario" vs "ACME — proposta per settore Edilizia"; newsletter mensile a 2000 iscritti con sottoinsiemi geografici (jitter randomizza l'ordine per non triggerare antispam su pattern "tutti gli @libero.it nei primi 30 minuti"); recall pre-scadenza abbonamenti con tracking apertura per identificare candidati lapsus alla cancellazione e prepare retention sales call.

Classificatore di risposte email B2B per cold-outreach commerciali (sales sequence automation) e campagne export multilingua. Quando un agente di vendita lancia una sequence outbound a 200 prospect, le risposte ricevute si concentrano in 8 archetipi prevedibili che richiedono azioni follow-up nettamente diverse — automatizzare la classificazione e la prossima azione liberare il SDR/AE dalle 4-6 ore/settimana di triage manuale e migliora il tempo di risposta (oggi: 8h medio → con questo nodo: 2 minuti). Le 8 categorie classificate sono: interested_buy (segnale di acquisto immediato: "quanto costa?", "manda preventivo", "siamo interessati a acquistare 50 unità"), interested_info (vuole più info ma non è ancora comprato: "manda catalogo", "cosa includete", "posso avere una demo"), interested_tasting (richiesta di prova/degustazione/sample — case food&beverage, software trial, sample fisico), not_interested ("attualmente non ci serve", "abbiamo già un fornitore"), wrong_recipient ("non sono io il responsabile, rivolgiti a Maria di acquisti maria@..."), complaint (lamentela: "non scrivere più", "abbiamo segnalato la vostra azienda al Garante"), out_of_office (auto-reply OOO: "sono in ferie fino al 15/07, contatta x@..." — da gestire con scheduled re-send), spam (false positive ricevuti su email che NON era un prospect: ricevuti di consegna inattesi, response a marketing aziende generiche tipo "ho visto la vostra newsletter"). Multilingua native con rilevamento automatico via euristica letterale: italiano, inglese, tedesco, francese — spagnolo e portoghese supportati ma con confidence ridotta del 10% (corpus training minore). Output rich: { label, confidence (0-1), matchedKeywords (per audit del PERCHÉ è stata data quella label, utile in dispute con AE che contesta "ma era interessato!"), language, suggestedAction (mappa label → azione concreta del workflow: send_catalog, send_quote, book_tasting_calendar, archive_silent, forward_to_human_inbox, send_unsubscribe_confirm), replyDraft (bozza di risposta pre-tradotta nella stessa lingua del prospect, tono professionale + customizzabile con templating downstream) }. Confidence sotto la soglia (default 0.7) viene declassata a needs_human_review per evitare azioni automatiche imbarazzanti su email ambigue — l'AE conferma manualmente la categoria, e il signal feedback può alimentare retraining della pipeline. Pattern di composizione: collegare l'output a logic_switch sul campo label con 8+1 (review) branch — ogni branch ha una catena di azioni diversa (interested_buy → action_send_email con quote PDF + create lead in crm.lead Odoo; not_interested → archive + decrement engagement score; OOO → schedule re-send tra +14 giorni). Use case: azienda food italiana fa export Germania, riceve 80 risposte/giorno a campagna outreach buyer tedeschi e l'agent classifica automaticamente; SaaS B2B europeo gestisce inbound demo request in 5 lingue senza traduzioni manuali; vinaio piccolo invia outreach a importatori UK e categoria interested_tasting attiva automaticamente la spedizione del kit assaggio con tracking corriere; consulenza enterprise riceve risposte VP/C-level e wrong_recipient instrada SDR al referente corretto entro 5 minuti.

Innesco di polling enterprise che firma un nuovo run del workflow ogni volta che compare un nuovo record in un modello Odoo specificato — sostituisce l'assenza di webhook nativi del core Odoo Community (su Enterprise esiste il modulo automation ma richiede l'installazione e setup non sempre fattibile in tenant cliente). Architettura: il trigger scheduler del runtime FlowForge invoca questo trigger ogni pollIntervalSec (default 60s, range 15s-3600s in base alla criticità — 15s per ordini e-commerce, 5min per nuovi lead, 1h per anagrafica), autentica via /xmlrpc/2/common, esegue search_read sul modello configurato con domain filter dell'utente + un cursor implicito [("id", ">", lastSeenId)] che garantisce EXACTLY-ONCE delivery anche in presenza di crash del runtime, recovery, network blip o spostamento di container tra host (lastSeenId è persisto nello state store del trigger, non in memoria volatile). Per ogni nuovo record trovato, parte un singolo run del workflow con il record completo come trigger input — i tuoi nodi downstream possono leggere fields["name"], fields["email"], ecc. direttamente. Dopo ogni batch processato, lastSeenId è aggiornato al MAX(id) del batch in un'unica transazione atomica per evitare race-condition tra polling overlap (es. polling interval più breve della latency del run). Edge case: se un workflow downstream è lento (es. fa LLM call), un nuovo polling parte comunque (non c'è mutex globale sul trigger) ma il cursor protegge da duplicate processing — la peggiore cosa che può succedere è una micro-latency extra sul DB Odoo, non un duplicate run. Rispetta i record rules dell'utente di login (che vede solo i record permessi dalla sua security group), quindi creare un utente Odoo dedicato "Workflow Bot FlowForge" con accessi minimi è raccomandato per limitare l'esposizione. Esempi tipici di modelli pollati: crm.lead per nuovi lead da form web Odoo (alimenta sales sequence), mail.message per nuovi messaggi nel chatter (utile per audit di interazioni cliente), res.partner per nuove anagrafiche aggiunte manualmente da segreteria (sincronizza con MailChimp/HubSpot), sale.order per nuovi ordini in stato draft (revisione automatica), helpdesk.ticket per nuovi ticket assegnati da frontoffice (alerting whatsapp al team tecnico), account.move per fatture appena emesse (export verso gestionale esterno o sistema banca per anticipo fattura). Use case operativi: studio commercialista polleha crm.lead ogni 5min — ogni nuovo lead da Google Ads form lancia un workflow che fa scoring, manda email benvenuto e crea attività su mail.activity per il junior; e-commerce wine.it polleha sale.order ogni 60s — nuovo ordine triggera workflow di verifica giacenza magazzino + email conferma + creazione spedizione GLS; SaaS B2B polleha res.partner solo dei contatti creati negli ultimi 7gg per active_customer_rank > 0 — sync verso HubSpot CRM per il team marketing.

Esegue codice Python in sandbox Docker isolata (memoria 512MB, CPU 1 core, no privileges, read-only FS). Libreria stdlib disponibile: matplotlib/numpy/pandas/scipy/plotly/pillow/sympy/openpyxl/tabulate + requests/httpx (quando allowNetwork=true). Output: { stdout, stderr, exitCode, durationMs, files[] (grafici/CSV salvati in output/ ritornati base64) }. Timeout configurabile (max 120s). Input/ctx esposti come dict Python via env var FLOWFORGE_INPUT. Network policy: • allowNetwork=false (default, raccomandato) → ZERO egress, sicurezza massima. Per chiamate HTTP, usa action_http_request come step separato (più ergonomico + audit nativo). • allowNetwork=true (opt-in) → egress Internet abilitato MA con SSRF block: cloud metadata 169.254.169.254 + RFC1918 (10/8, 172.16/12, 192.168/16) + loopback + Docker internal BLOCCATI a livello iptables. Audit log scrive ogni esecuzione con allowNetwork=true. Quota: 10 esec/min per tenant. Use case: data analysis su CSV, generazione grafici matplotlib per report, calcoli statistici/finanziari complessi, ML inference one-shot, manipolazione immagini PIL, API HTTP custom non coperte dai 216 nodi stdlib (allowNetwork=true), conversioni formati custom.

Esecutore enterprise di codice JavaScript custom in sandbox isolated-vm in-process — la primitiva di escape hatch per qualsiasi trasformazione di business logic NON coperta dai nodi specifici stdlib o logic_transform. Usa isolated-vm (lib battle-tested usata in produzione da Cloudflare Workers, Discord bot eval, Replit, Algolia per allow user code execution) che fornisce isolation a livello V8 (process-level VM con context separato) — il codice user-provided NON può vedere né interferire con il main runtime process del tenant, evitando classic Node.js eval vulnerabilities (process.exit, fs.access, require di moduli arbitrari come "child_process"). Sandboxing rigoroso multi-livello: NO accesso al filesystem (fs module assente), NO accesso di rete (fetch/http/https assenti), NO require/import di moduli (limitato strict alla standard JavaScript std: Math, JSON, Array, Object, Date, String, RegExp, Number, Map, Set, Promise — il subset safe-by-construction); cap di memoria configurable (default 128MB, max 512MB per workflow heavy-compute); timeout configurable (default 5s, max 30s per evitare workflow stuck su infinite loop bug); deep stack depth cap a 1000 frame per protezione recursion-bomb. Performance enterprise: latenza tipica < 5ms per script piccoli (overhead di context entry/exit + snapshot creation è minimo), throughput sustained 1000+ exec/sec single-thread su CPU moderno — pattern OK per high-volume workflow batch dove ogni iter richiede un piccolo bit of custom JS. Variabili globali disponibili nel script: input (output JSON del nodo precedente — la fonte primaria di dati da processare), vars (workflow variables persistenti — ricordo cross-step), ctx (run metadata come runId, tenantId, workflowId, currentTime per timestamp embedding). Output: il valore return-ato dallo script diventa l'output del nodo (deve essere JSON-serializable — no functions, no circular references, no Symbol — il check è automatic e fail con error semantic esplicito se viola la regola). Use case: trasformazione dati custom non coperta da logic_transform (es. complex map+filter+reduce multi-pass su array nested); calcoli business logic specifici del cliente (es. provvigione tier-based con scaglioni di importo + bonus YoY + override regola country); validation custom multi-field con rule complex (es. "if amount > 1000 AND country != billing_country AND timestamp < user.created_at + 7days → fraud_signal"); mapping/reshape input prima di chiamata API downstream con format esotic non mappabile dichiarativamente; generazione di id deterministici via hash semplice (sha256(email + company)); compute di statistiche aggregate custom (median, percentiles, weighted average con peso configurable); algoritmi proprietari del cliente (lead scoring custom, churn risk score, NPS adjusted) che NON vuole esporre come logica in template visuale ma come black-box pura function.

Auditor enterprise di security posture di un dominio web — esegue una batteria di controlli deterministici read-only che valutano la "salute" di sicurezza del sito target su 4 dimensioni critiche dell'IT security 2026 secondo CIS/OWASP/NIST best practices, ritornando uno score normalizzato 0-100 con findings prioritizzati actionable per remediation. Le 4 categorie analizzate: (1) DNS Email Authentication — lookup SPF record (Sender Policy Framework, dichiara quali server SMTP sono autorizzati a inviare email per il dominio, presenza richiesta per non finire in spam folder di Google/Microsoft mailbox), DKIM (DomainKeys Identified Mail, firma crittografica delle email outbound), DMARC (Domain-based Message Authentication, Reporting and Conformance — la policy che dice ai mailbox come gestire le email che falliscono SPF/DKIM check); assenza/misconfiguration di questi 3 = signal red flag per email security; (2) SSL/TLS Certificate Inspection — ispezione del certificato HTTPS del dominio: issuer (CA emittente, Let's Encrypt è OK ma se aspettiamo enterprise tier ci aspettiamo Digicert/Comodo/Sectigo), expiry date (warning < 30gg residui, critical < 7gg), SAN (Subject Alternative Names — il dominio matcha sul certificato), protocol version (TLS 1.2+ obbligatorio enterprise, TLS 1.0/1.1 deprecati 2020+), cipher suite strength (no SHA-1, no RC4, no MD5); (3) Redirect Chain Analysis — HEAD request seguendo redirect fino a max 10 hop, detect di open-redirect vulnerability (redirect verso domini esterni che non corrispondono al target — pattern di phishing preparation), detect di catene troppo lunghe (UX problem + SEO penalty), terminazione su HTTPS vs HTTP (downgrade attack risk); (4) HTTP Security Headers — verifica presenza di HSTS (HTTP Strict Transport Security per forzare HTTPS browser-side), CSP (Content Security Policy contro XSS), X-Frame-Options o frame-ancestors (anti-clickjacking), X-Content-Type-Options nosniff, Referrer-Policy, Permissions-Policy — l'enterprise standard 2025-2026 che dovrebbe essere presente su ogni sito. Score finale weighted: critical findings (-30 ognuno), high (-15), medium (-5), low (-2). Range risultante 0-100 con bandi 90-100=eccellente, 70-89=buono, 50-69=da migliorare, < 50=critico. Output: { score (0-100), findings: [{ severity, category, description, recommendation }], spf: { present, valid, includes, mechanisms }, dkim: { selector?, present, key_size }, dmarc: { present, policy (none|quarantine|reject), rua }, ssl: { issuer, expires_at, days_to_expiry, sans, protocol }, redirects: [{ from, to, status }], headers: { hsts, csp, frame_options, ... }, analyzedAt }. Use case: pre-onboarding due diligence security per cliente B2B enterprise (sales team del cliente richiede compliance attestation per data processing agreement); monitoring cron settimanale con alert su drop score (es. il cert SSL scade tra 28 giorni → notify ops via Telegram); compliance check pre-migrazione DNS per evitare regression dopo cambio nameserver; report PDF stakeholder non-tecnici tradotto in linguaggio business "il vostro sito ha 85/100 di security score, ecco i 3 fix prioritari"; audit posture post-incident di sicurezza per documentare cause-effect remediation.

Pipeline multimodale enterprise video-to-summary strutturato — l'AI-powered processor che trasforma un video raw (caricato dall'utente, fetched da URL pubblico YouTube/Vimeo/CDN, output di un meeting Zoom recording) in un riassunto strutturato gerarchico pronto per consumo umano (TL;DR esecutivo) + consumo machine (chapter timestamped per navigazione + transcript completo per search). Architettura multi-stage che combina 3 modelli AI specializzati orchestrati: (1) ffmpeg extract — extraction temporale del video grezzo in 2 streams paralleli: audio mono 16kHz PCM raw (formato di input ottimale per ASR), frames JPEG sampling 1fps (un frame per secondo per analysis vision senza saturare context window dei vision model); (2) Whisper ASR transcript — il modello speech-to-text OpenAI open-source self-hosted on-premise EU (Hetzner Falkenstein GEX131 RTX PRO 6000 Blackwell 96GB) elabora l'audio producendo transcript parola-per-parola con timestamp millisecond-level di ogni token + speaker diarization (chi parla — speaker_0, speaker_1 fino a 8 partecipanti distinguibili per voce timbre), language auto-detection con supporto a 99 lingue compreso italiano alta accuracy; (3) Vision Qwen2.5-VL describe scenes — il modello multimodal vision Qwen2.5-VL-7B INT4 self-hosted analizza i frame estratti applicando scene-change detection (similarity-based clustering dei frame consecutive — quando passa una soglia di differenza visiva si dichiara nuova scena) e descrive ogni scena identificata con caption rich (es. "Slide 3 mostra grafico fatturato Q4 con bar chart e label "+23% YoY""); (4) Liara LLM fusion stage — il LLM principale fonde i 2 stream (transcript Whisper + scenes Vision) producendo l'output finale gerarchico TL;DR + bullets + chapters timestamped, pattern che cattura sia il content auditive (parole spoken) sia visual (slide, demo screen, persone identificate dal volto). Backend interamente self-hosted Hetzner (no costi per-token sui pipeline component AI, no transferimento dati extra-UE GDPR-compliant — pattern enterprise critical per casi tipo studio medico che processa meeting con dati sanitari sensibili o studio legale con materiale confidenziale cliente). Output rich strutturato: { transcript (full text concatenated con [00:00:12] timestamps), scenes: [{ startTime, endTime, description, confidence }], summary: { tldr (200-400 char executive summary), bullets (5-10 key points), chapters: [{ title, startTime, summary }] }, durationSec, processedAt, detectedLanguage, speakerCount }. Use case: indicizzazione media library (corsi online, webinar registered, meeting recording per institutional knowledge base searchable); highlight reel automatic per social media marketing (top 3-5 chapters più engaging clip per LinkedIn/Twitter/YouTube Shorts); accessibility WCAG 2.2 compliance (caption + audio description per persone non udenti + non vedenti); search-in-video capability tramite scene timestamps (l'utente cerca "fatturato Q4" nella library e va direttamente al chapter relativo del video); briefing post-meeting con chapter cliccabili distribuito al team che non ha potuto partecipare; documentation di demo prodotto con auto-generated transcript per dev team reference.

Agente AI enterprise specializzato in compliance legale di documenti italiani ed europei — analizza contratti, privacy policy, Terms of Service (ToS), Data Processing Agreement (DPA), cookie banner, normative interne aziendali, verificando la conformità contro la batteria completa dei principali framework normativi che si applicano al business digitale italiano nel 2025-2026: GDPR (Regolamento UE 2016/679 sul trattamento dati personali), eIDAS 2.0 (Regolamento UE 910/2014 + aggiornamento 2024 sulla identità digitale europea + firma elettronica qualificata), AI Act (Regolamento UE 2024/1689 in vigore agosto 2024 sulla classificazione dei sistemi AI in 4 livelli rischio + obblighi per fornitori e utilizzatori), DPR 445/2000 (testo unico documentazione amministrativa per archiviazione a norma), Codice del Consumo (D.lgs. 206/2005 con tutti i diritti del consumatore B2C), Direttiva e-Privacy 2002/58/EC (regola tracciamento cookie e marketing communications). Pipeline AI multi-stage che combina retrieval e generation per garantire ANTI-HALLUCINATION rigorosa — pattern critical per use case legali dove un erroneo cite di articolo non esistente sarebbe professionalmente damaging: (1) chunking semantico del documento input in segment manageable dal LLM context window, preservando i confini logici di paragrafi/sezioni; (2) ai_rag_search su una KB normative pre-indicizzata via embedding BGE-M3 1024-dim dei testi ufficiali AgID/EUR-Lex con i 1500+ articoli rilevanti dei 6 framework supportati; (3) Liara LLM analizza ogni chunk con il context normativo retrieved e produce findings strutturati con CITAZIONE ESPLICITA dell'articolo violato + reasoning step-by-step; (4) fusion finale dei findings con severity ranking (critical → high → medium → low → info) e dedup di issue duplicate. Output rich strutturato per consumo umano + machine: { score (0-100 normalizzato di compliance, < 50 critical, 50-70 da migliorare, 70-90 buono, > 90 eccellente), findings: [{ severity, framework (es. "GDPR"), articleNumber (es. "art. 5(1)(c)"), description (cosa è il problema in italiano leggibile), evidenceQuote (la frase originale del documento che ha triggered il finding), remediation (azione concrete per fix), confidence }], frameworksAnalyzed, summary (executive summary 200-400 char), recommendations (top 5 azioni prioritizzate by impact), analyzedAt, modelVersion }. Use case enterprise critical italiani: pre-firma contratto B2B per red flag clausole vessatorie e derogatorie dello consumer code (pattern delle clausole limitanti di responsabilità del fornitore verso il cliente B2B finance/services); audit privacy policy sito web pre-pubblicazione (verifica GDPR art.13 informativa completa + ePrivacy cookie banner + eIDAS link identità del titolare); DPIA (Data Protection Impact Assessment) art.35 GDPR per nuovo trattamento dati sensibili (richiesto before-launch di feature che processa dati sanitari o biometrici); compliance gate pre-launch di feature AI-powered con classifica rischio AI Act (es. "il nostro sistema di selezione candidati rientra in high-risk Annex III del AI Act → obblighi di documentazione tecnica + audit periodico"); review cookie banner per consenso valido art.7 GDPR + Linee Guida Garante 2024 (no pre-ticked checkbox, opt-in granular per category, dark pattern detection).

Connettore enterprise per Google Sheets — il SaaS spreadsheet di Google con 900M+ MAU integrato in Workspace, alternativa cloud-native a Excel desktop ampiamente usato in startup, agency, team B2B che preferiscono la collaboration real-time + sharing semplificato a un DB enterprise — via Sheets API v4 ufficiale OAuth2. Quattro operazioni atomiche coprono il ciclo read/write completo: getValues (legge un range A1 notation tipo "Foglio1!A1:D100" oppure "Vendite!A:E" range aperto fino in fondo, ritorna array 2D di valori), updateValues (sovrascrive idempotent un range specifico — pattern safe per sync dove vogliamo controllo esatto della destinazione), appendValues (insert in fondo allo sheet auto-detecting la prima riga libera — pattern naturale per logging incrementale di eventi), batchGet (multi-range in singola request per ridurre roundtrip su sheet con multipli area da leggere contemporaneamente). Auth via OAuth2 portal-centric pattern di FlowForge: l'utente fa OAuth consent flow una sola volta da Settings → Integrations → Google Sheets, e il portal centrale (NON il container tenant) gestisce il refresh token + emette access token short-lived (3600s default Google OAuth) al runtime via JWE handoff 5min — questo pattern enterprise (vedi memory project_oauth_multi_tenant_portal_centric) evita di richiedere consent ad ogni run e centralizza il vault credenziali. Auto-refresh dell'access_token su 401 con 1 retry trasparente — l'utente non vede mai expire né deve fare manual re-auth. Schema cell types: il nodo preserva i tipi nativi Google Sheets — numeri restano numeric (non stringificati), date in formato Excel serial number convertite a Date object JavaScript, formule (es. "=SUM(A1:A10)") preservate come formule durante updateValues (la cella resta formula, non valore calcolato), formatting (currency €, percent, date format) preservato server-side da Google. Rate limit Google Sheets API v4: 100 req/100sec per project/user (quota generosa per uso interattivo, condivisa col resto delle Google APIs dello stesso project), 60 RPM per user — il nodo gestisce 429 con Retry-After header + backoff exponential automatico. Output: { rows (array 2D di [row][col] string|number|null), range (A1 notation finale), updatedCells? (count per operazioni write), spreadsheetId, sheetTitle, sheetGid?, lastModifiedTime }. Use case: ingest CSV → Google Sheet per analisi business dal team marketing (CSV upload via trigger_file_watch → parse → batchUpdate del Sheet target "Marketing_Leads_Master"); sync KPI dashboard real-time dove i numeri vengono calcolati da workflow trigger_cron + aggregate + updateValues su sheet visualized in Looker Studio; logging eventi workflow su sheet condiviso col team (audit trail soft-light, non-DB grade ma sufficiente per use case operativi); ETL semplice senza data warehouse pesante (sync da N source come Stripe/HubSpot/Calendly → un Google Sheet "tutto in uno" che il CFO consulta via Web); backup leggero di record DB critici per audit consumabile da stakeholder non-tech che hanno solo Google account ma non accesso al DB diretto.

Connettore enterprise per Discord — la piattaforma di comunicazione real-time nata gaming e ora standard de-facto per community tech, open-source maintainer team, developer relations, web3/crypto project, e DevOps stack alternative a Slack (oltre 150M MAU, 19M server attivi). Due modalità operative: (1) Webhook mode — il modo SEMPLICE per inviare messaggi senza creare un bot; un webhook URL identifica univocamente il canale destinazione (l'admin Discord lo genera in Server Settings → Integrations → Create Webhook, scegliendo il channel target + icona + nome custom del sender), nessuna autenticazione OAuth/Bot Token richiesta, rate-limit 5 msg/sec per webhook che il nodo gestisce con backoff exponential automatico su 429; (2) Bot API mode — il modo AVANZATO con Bot Token (formato Bot xxxxxxxx con privileged intents) che sblocca features impossibili via webhook: aggiungere reactions a un messaggio esistente, creare reply in thread (i thread sono sub-conversation Discord 2022+), DM diretti ai user, slash commands custom, presence updates del bot, gestione voice channel join. Supporto pieno del payload Discord moderno: plain text con markdown subset (bold **, italic *, code `, codeblock ```, spoiler ||), embed cards (la feature kilattributo Discord — rich preview con title + description + color + thumbnail + fields strutturati + footer + author block), file attachments multi (fino a 10 file × 25MB per messaggio in Tier 0 Boost server, 50MB Tier 2, 100MB Tier 3), mentions (@user via user_id, @role via role_id, @here per online member del canale, @everyone con permission check). Output: { messageId (snowflake Discord unique), channelId, sentAt (ISO 8601), webhookOk, mentionedUsers, attachmentUrls? (per replay/log) }. Use case: notify team developer su run workflow CI falliti con embed color rosso + link al run viewer FlowForge dashboard; deploy alert nel canale #devops con embed status verde "✅ Deploy 20260606_123117 OK" e changelog inline; community announcement automatico nel canale #news post-pubblicazione blog post sul sito (sync MDX + webhook Discord); monitoraggio uptime con embed color-coded (rosso > 5xx, giallo p95 > 3s, verde sano) per il dashboard SRE; thread reply per discussion gruppo support: il bot apre un thread per ogni ticket nuovo Zendesk e linka nel thread l'update di status, evitando di intasare il canale principale con messaggi sparsi; gaming community che lancia eventi automatic con countdown timer e role mentions per @evento-mensile.

Connettore enterprise per Airtable — la piattaforma low-code database+spreadsheet ibrida nata 2012 a San Francisco con 300k+ paying customer di startup, agency, marketing team, education che la usano come rapid prototyping di applicazioni database-driven con UI native (grid, kanban, calendar, gallery view) senza dover scrivere codice né configurare uno schema PostgreSQL. Cinque operazioni atomiche CRUD via REST API v0 ufficiale: listRecords (read con filterByFormula in dialetto Airtable formula syntax stile spreadsheet "AND({Status}='Open',{Priority}>1)", sort multi-criteria, fields whitelist per ridurre payload, pagination cursor-based), getRecord (fetch puntuale by record_id rec0123456789ABC), createRecord (insert con typecast option che permette ad Airtable di coercere "Closed" string al select_field option corretto evitando errori), updateRecord (patch atomic dei field specificati, gli altri restano invariati — diverso da PUT che resetterebbe i field non-specificati), deleteRecord. Auto-pagination per listRecords: l'API Airtable cap a 100 record/page e usa offset opaque cursor — il nodo automaticamente itera fino a recuperare TUTTI i record corrispondenti al filtro (con safety cap default 10000 totali per evitare runaway su table giganti), unificando in un singolo array di output pronto per loop downstream. Auth via Personal Access Token (formato patxxxxxxxx.xxxxxxxx generato da admin in Settings → Developer Hub → Personal Access Tokens con scope schema.bases:read + data.records:read|write granular per base) stored nel vault integration FlowForge. Multi-base supportato (un tenant FlowForge che gestisce 3 base Airtable diverse per agency che serve N cliente). Rate limit Airtable: 5 req/sec per base in Plus/Pro plan, 50 req/sec in Enterprise — il nodo gestisce 429 con Retry-After header + backoff exponential automatico. Header X-Airtable-Application-ID tracked per debug attribuzione delle quote. Output: { records: [{ id, fields: { [name]: value }, createdTime }], record?, deleted?, recordsCount, pagesScanned }. Use case: lead capture da form web (Typeform/trigger_form) → createRecord nella base "CRM Leads" con campos Name+Email+Company+Source+CreatedAt, opzionale typecast=true se Source viene da dropdown opzioni pre-definite; sync inventory bidirezionale e-commerce↔Airtable per piccoli merchant che usano Airtable come stockmaster invece di un ERP completo (updateRecord di stock_qty quando arriva ordine Stripe); progetti Kanban automatico (move card by status — update record's Status field da "Todo" a "In Progress" quando un workflow event triggers, Airtable native auto-aggiorna la Kanban view); survey responses aggregate per analytics market research con listRecords + logic_aggregate (count per region, avg satisfaction score); media library con metadata + attachment field per asset management leggero (upload foto prodotto via API attachment + metadata strutturata).

Connettore enterprise per Trello (la piattaforma kanban di Atlassian con 50M+ utenti, semplicissima da usare per team non-tecnici che vogliono visual project management senza la complessità di Jira — Power-Up automation native + REST API stabile dal 2012 + Butler workflows interno) via REST API ufficiale v1. Cinque operazioni atomiche coprono il ciclo card+board: createCard (inserisce nuova card in una list specifica della board con title, description markdown, due date, label assignment, member assignment), updateCard (la più potente operazione — sposta tra list per movimento kanban "Open" → "In Progress" → "Done", cambia labels, cambia due date, aggiunge/rimuove members, archivia/disarchivia), addComment (markdown body con @mentions @username sintassi Trello che notificano il member, link embedded auto-rendered come preview card), listCards (paginated con filter su list specifica oppure tutta la board, utile per dashboard interne), getBoardLists (introspezione dello schema della board per discovery dinamico delle list disponibili — pattern auto-config per workflow che lavorano su board mutevoli). Auth via doppio token: API Key (formato 32 char hex public-safe, ottenuto dall'admin Trello in https://trello.com/app-key e referenziato come integration label nel vault FlowForge) + Token OAuth1 (generato dall'API Key con click su "Generate a Token" che apre l'OAuth flow di authorization e ritorna il bearer token user-specific). Stessa coppia (key, token) usata in tutte le request come query string `?key=K&token=T`. Multi-account supportato (un tenant FlowForge che orchestra 5 board di team diversi). Rate limiting Trello: 100 req/10sec per token + 300 req/10sec per API key (aggregati su tutti i token) — il nodo gestisce 429 con Retry-After exponential backoff + jitter, cache 30s delle listIds e boardIds discoverable per ridurre roundtrip ridondanti nel stesso workflow. Output: { card? (object completo Trello con id, idShort, name, desc, due, dueComplete, idList, idBoard, labels, members, shortUrl, dateLastActivity), cardId?, listId?, boardId?, cards[]? (array per listCards), commentId? (per addComment) }. Use case operativi reali: bug report → Trello card automatica nella board "Bug Tracking" list "Triage" da incident webhook Sentry con title summary + description markdown contenente stack trace + due date +3gg per SLA; lead form Typeform → card "New lead {{first_name}}" in board "Sales Pipeline" list "Da contattare" con due date +7gg per follow-up call e label color-coded per source ("linkedin", "google_ads", "referral"); CI fail webhook → comment automatic su card della feature corrispondente con log link e @mention del responsabile assegnato; PR merged GitHub event → move card "In Code Review" → "Done" + addComment "✅ PR #123 merged by @reviewer at {{timestamp}}"; daily standup async — listCards di tutte le card "In Progress" per generare summary report via agent_business_summarizer.

Connettore enterprise per Calendly — la piattaforma SaaS di booking di appuntamenti più diffusa per sales team B2B, consulenti, coach, recruiter, customer success (10M+ utenti, 100k+ paying customer business) che permette di pubblicare un pubblico booking link "trova uno slot libero con me" eliminando le 5-6 email back-and-forth di scheduling — via REST API v2 ufficiale. Cinque operazioni atomiche gestiscono l'intero lifecycle del booking: listScheduledEvents (recupera elenco di appuntamenti scheduled con filtri compound by user URI/organization URI/status active|cancelled/range di date min_start_time-max_start_time per dashboard analytics e sync incrementale), getEvent (fetch puntuale di un singolo event by URI univoco con metadata complete come location/duration/calendar_event_provider/invitee_questions_and_answers), listInvitees (gli invitee dell'evento — solitamente 1 per 1-to-1 meeting ma può essere N per group events), getInvitee (dettagli singolo invitee con email + nome + phone + answers ai prompt custom configurati dal Calendly admin nel form di booking), cancelEvent (cancellazione lato server con motivazione opzionale che notifica entrambe le parti via Calendly nativ). Auth via Personal Access Token formato eyJxxx (JWT generato da Calendly nell'admin dashboard Settings → Integrations → API & Webhooks → Personal Access Token, scope organization-wide o user-only), stored nel vault integration FlowForge accessibile via integrationLabel. Multi-account supportato per agenzie che gestiscono Calendly di N consulenti. Rate limit Calendly: 1000 req/h sustained per token (~16 RPS sustained, 30/sec burst), header X-RateLimit-Remaining trackato dal nodo per warning preventivo. Pagination automatica su listScheduledEvents (cursor-based "next_page_token") con cap default 500 events per workflow per evitare flood. Output: { events: [{ uri, name, start_time, end_time, status, location, invitees_counter, event_memberships }], invitees: [{ uri, email, name, phone?, status (active|canceled), questions_and_answers: [...], cancellation? }], event?, invitee?, cancelled? (boolean per cancelEvent operation) }. API docs ufficiali: developer.calendly.com/api-docs (v2 stable). Use case: sync new booking via webhook Calendly subscription → CRM lead automatic in HubSpot/Salesforce/Odoo con properties popolate dalle questions custom del form (es. "company_size", "budget_range", "main_challenge") e LeadSource=Calendly; reminder workflow 24h pre-meeting che parte da trigger_cron check daily + listScheduledEvents filter su tomorrow + email reminder personalizzato + WhatsApp message opzionale con link Zoom incluso; no-show detection per ricalibrare il forecasting (event passato + invitee status active non transitato a confirmed via webhook canceled = candidate no-show, marca contact in CRM per analytics conversion rate); aggregate weekly bookings nel sales dashboard del manager team commerciale con breakdown per consulente e source; trigger di onboarding workflow al primo meeting closed-won → invio kit benvenuto + creazione progetto in Asana + Slack channel dedicato al cliente.

Connettore enterprise per Typeform — la piattaforma di form conversational design-first nata in Barcellona 2012 (2M+ paying customer) preferita da marketer e UX designer per la one-question-at-a-time interaction che produce 40% higher completion rate vs form tradizionali, integrazione massiccia con CRM/marketing automation tool, librerie di template ricchissime per ogni vertical (NPS survey, lead capture, job application, customer feedback, evento registration) — via Responses API + Forms API ufficiali. Cinque operazioni atomiche coprono il ciclo completo: listForms (elenco di tutti i form dell'account/workspace con metadata e analytics aggregate), getForm (definition completa di un form specifico con tutti i field, branching logic, ending screens — utile per pre-validation o introspection dello schema), listResponses (filter compound by completion status partial/completed, range di date submitted_at, hidden fields query), getResponse (fetch puntuale di una singola response by response_id con tutte le answers e metadata calculated), deleteResponses (operazione di cancellazione GDPR-aware con audit trail). Auth via Personal Access Token (formato tfp_xxxxx generato dall'admin Typeform in Settings → Personal tokens → Generate token con scope responses:read|write + forms:read) stored nel vault integration FlowForge. Auto-pagination per listResponses: usa cursor "after" + page_size 1000 max — il nodo automaticamente itera fino a recuperare TUTTE le response che matchano il filtro (con cap default 50000 totali per safety + memory), pattern naturale per sync incrementale del data warehouse. Rate limit Typeform: 4 req/sec per access token sustained, 60 req/min con burst — il nodo gestisce 429 con Retry-After header + backoff exponential automatico. Hidden fields support nativo: i hidden field passati come query string al form URL (es. ?utm_source=google&customer_id=42) sono inclusi nelle response answers — pattern critico per attribuire la response al touchpoint marketing che ha generated il traffic e alla customer entity preesistente nel CRM. Output rich: { forms: [{ id, title, links, settings }], form?, responses: [{ response_id, submitted_at, landed_at, calculated, answers: [{ field, type, value, ref }], hidden, metadata }], total, page_count }. Use case operativi reali della pipeline marketing/HR: lead form Typeform "scopri quale piano fa per te" → CRM HubSpot auto-import + dedup per email + lead scoring based on answers + assignment al sales rep corretto del territorio; NPS survey trimestrale → analytics dashboard real-time con avg per segment (customer tier, regione, vintage) e detect drop trimestre-su-trimestre come signal di churn risk; job application form per HR → Slack notify nel canale #hr-newapps + upload CV allegato su Google Drive + create Trello card "Review {{candidate_name}}" assegnata al recruiter manager; GDPR right-to-erasure workflow customer-driven (customer chiede cancellazione dati personali → workflow trova tutte le response Typeform con email match → deleteResponses → audit log immutable della cancellazione per compliance + email conferma al customer); webinar registration → automatic add a HubSpot list "webinar_attendees" + email confirmation con zoom link.

Connettore enterprise per Shopify — la piattaforma e-commerce leader mondiale per SMB e mid-market (fondata 2006 a Ottawa, IPO 2015, 5M+ merchant attivi che processano $230B+ GMV annuo, base installata particolarmente forte in USA/EU/AUS per direct-to-consumer brands e drop-shipping store) via Admin REST API 2024-01 ufficiale. Quattro operazioni atomiche coprono il core retail flow: getOrder (recupera ordine specifico by orderId con tutti i line_items + customer + shipping_address + payment_status + fulfillment_status — pattern essenziale per ingest ordini downstream verso ERP/gestionale italiano); createOrder (crea ordine manualmente o conferma un draft order precedentemente preparato — utile per use case omnichannel B2B dove l'ordine arriva via email o telefono e va inserito in Shopify after-the-fact per consistency del data warehouse); listProducts (catalogo paginated fino a 250 item/request con cursor-based pagination per merchant con migliaia di SKU); createProduct (pubblica nuovo prodotto con multiple variants size/color, immagini galleria, metadata SEO, pricing tier-based per region o customer type, inventory tracking). Auth via Custom App Access Token (formato shpat_xxxxxxxx generato dall'admin Shopify in Apps → Develop apps → Configure Admin API scopes — granular permission read_orders, write_orders, read_products, write_products per least-privilege) usato come header X-Shopify-Access-Token stored nel vault integration FlowForge. Multi-shop supportato (agency che gestisce 10 store Shopify diversi di N customer brand). Validation enterprise pre-API: shopDomain validato sintatticamente come regex strict per matching solo *.myshopify.com (anti injection di dominio arbitrario nel URL builder, evita classic SSRF via user-controlled shopDomain). Pipeline standard FlowForge: SSRF-safe gateway, circuit-breaker per-host dedicato (un outage su un shop NON blocca workflow di altri shop), retry exponential backoff su 5xx e 429 transitori. Rate limit Shopify: 2 req/sec sustained for Basic/Shopify plan, 4 req/sec for Advanced/Plus — il nodo gestisce header X-Shopify-Shop-Api-Call-Limit con throttle anticipato a 80% del cap per evitare hard 429. Output: { orderId?, order? (con full object structure Shopify), products? (array paginated con cursor next_page_info), productId?, count? (totalCount when available), pageCursor? }. Use case enterprise italiani: sincronizza ordini Shopify verso gestionale italiano o Odoo per contabilità + magazzino unified (webhook order.created → workflow → action_odoo_create_lead in sale.order); crea automatic prodotti da feed XML fornitore (RSS o sftp drop → parse → loop → createProduct con immagini); notifica team su nuovo ordine via Slack/email con order summary + link al admin Shopify; popola CRM HubSpot/Salesforce con customer al checkout per nurturing post-acquisto; genera fattura elettronica italiana SDI all'evasione dell'ordine (collega con il modulo SDI/PEC del workflow stack); dashboard vendite real-time con metriche aggregate (cron orario + listProducts + per-product analytics + push su Google Sheets management).

Connettore enterprise per Mailchimp — la piattaforma email marketing & marketing automation pioniere del settore (fondata 2001, acquisita da Intuit 2021 per $12B, 13M+ utenti registered + 2.5M+ paying customer business soprattutto SMB e creator) leader globale del consumer email marketing con feature rich per campagne ricorrenti, automation workflow, audience segmentation, analytics dettagliata, A/B testing — via Marketing API v3.0 ufficiale. Tre operazioni atomiche coprono il pattern di sync principale tra workflow business e Mailchimp audience: addMember (upsert idempotent del subscriber nella audience target — Mailchimp API richiede di passare il MD5 hash lowercase dell'email come identifier per le operazioni member-level, il nodo computa automatic questo hash e lo usa per accesso PUT che è naturally idempotent — pattern critico per evitare duplicati su re-run del workflow), getMember (fetch dello stato iscrizione di un subscriber: subscribed, unsubscribed, pending, cleaned, transactional + valori dei merge fields custom come FNAME, LNAME, COMPANY, BIRTHDAY), addTag (applicazione di tag al subscriber per segmentation downstream nelle campagne — i tag sono il modo principale di Mailchimp di categorizzare audience oltre alle group/list-level fields). Auth via API Key formato unique 32-hex con suffix -us17 / -us12 / -eu1 / etc. che identifica il datacenter geografico del account Mailchimp (il nodo parse il suffix e construct correttamente l'URL base API tipo https://us17.api.mailchimp.com/3.0/ — pattern Mailchimp che molti developer sbagliano), usato come HTTP Basic Auth username "anystring" + password=apiKey. Stored nel vault integration FlowForge. Multi-account supportato (un tenant FlowForge che gestisce 10 audience Mailchimp di N customer separati). Pipeline standard FlowForge: SSRF-safe gateway, circuit-breaker per-host dedicato (importante per multi-datacenter — un outage su us17 NON deve bloccare workflow di altro account su eu1), retry exponential backoff su 5xx + 429. Rate limit Mailchimp: 10 concurrent connection per API key + soft limit per minute (varies per account tier — Pro/Premium hanno cap più alti). Output: { memberId? (MD5 hash dell'email, sempre presente perché derivable), status? (subscription state), member? (object completo per getMember), tagged? (boolean per addTag), email, datacenterUsed }. Use case: aggiungi lead da form/scraping alla newsletter aziendale (trigger_form submit → community_mailchimp addMember nella audience "Newsletter generale" con FNAME/LNAME merge fields mapped); sincronizza CRM HubSpot bidirezionale con audience Mailchimp (cron nightly + paginate dei contact HubSpot + upsert in Mailchimp audience corrispondente); tagga automatic contatti per comportamento (es. ordine pagato Stripe webhook → addTag "customer_paid_2026" per uso in trigger di campagna post-acquisto); double opt-in GDPR-compliant da workflow (subscriber status=pending → email di confirmation con link signed → su click → updateMember status=subscribed); nurturing automatico post-evento (webinar attendee → addTag "webinar_xyz_attended" che triggera drip campaign 7-day follow-up); sync iscritti bidirezionale con database tenant per analytics consolidata.

Connettore enterprise per Twilio — la piattaforma comunicazioni programmabili #1 al mondo (Software API leader fondato 2008, $20B valuation pre-IPO con 250k+ developer customer, copre il 90% degli SMS+voice+WhatsApp use case enterprise di tier-1 brand) via REST API ufficiale. Tre operazioni atomiche coprono il main feature set: sendSms (invia SMS classico su qualsiasi rete mobile mondiale, body fino a 1600 char con automatic segmentation in N parti se eccede 160 char standard GSM o 70 char Unicode, supporta concatenated SMS UDH per delivery come singolo messaggio sul dispositivo cliente), sendWhatsapp (invia messaggi WhatsApp Business via il sandbox Twilio o numero approvato in WhatsApp Business Manager, con prefix sintattico "whatsapp:+393331234567" che distingue il channel — supporta messaggi text + media attachment + template approvati), getMessage (lookup status delivery + error code di un messaggio precedentemente inviato by SID). Auth via Account SID (formato AC + 32 hex chars univoco del Twilio account) + Auth Token (secret rotabile per security incident response) entrambi stored nel vault integration FlowForge. Validation pre-call enterprise: accountSid validato sintatticamente (AC + 32 hex per anti-typo che produrrebbe 404 dopo network roundtrip), numeri E.164 validation rigorosa (+393331234567 format obbligatorio + country code detection per auto-prepend del "+" se mancante in input italiano "3331234567"). Pipeline anti-vulnerability standard del connector enterprise FlowForge: SSRF-safe gateway HTTP per evitare chiamate a endpoint privati, body form-urlencoded come Twilio API richiede (NON JSON come la maggior parte degli altri provider — pattern unico che molti developer sbagliano), circuit-breaker dedicato per evitare hammer durante upstream outage Twilio (rare ma succedono), retry exponential backoff con jitter su 5xx transient e 429 rate-limit. Rate limit Twilio: 1 SMS/sec per numero sender (capacity expandable a 10 SMS/sec con request approval in Twilio Console — pattern critical per high-volume marketing campaign), WhatsApp 80 msg/sec per numero, voice unlimited concurrent. Errori semantici espliciti: 30003 (delivery failed unreachable destination), 30004 (filtered da carrier per spam), 30005 (numero invalid), 21408 (numero blocked dal customer) — il nodo li parsa e restituisce semantic error code al workflow downstream per gestione differenziata. Output: { messageSid? (univoco Twilio per tracking), status? (queued|sending|sent|delivered|failed), errorCode? (semantic), to, from, segmentsCount?, billingCost? }. Use case: notifica OTP/2FA al cliente per login multi-factor sicurezza accounts SaaS; alert critici al team di SRE/ops via SMS per incident production (pattern PagerDuty-lite); conferma ordine/appuntamento tramite SMS subito post-checkout con tracking number e link customer area; promemoria scadenza fattura via WhatsApp 7gg pre-scadenza per ridurre DSO (Days Sales Outstanding) e improve cash flow; recupero crediti automatic multi-step con escalation (1° SMS gentile 30gg + 2° WhatsApp formale 60gg + 3° voicemail automatic 90gg → handoff legale); follow-up lead commerciale multicanale (email + SMS + WhatsApp coordinati per maximize touch reach).

Connettore enterprise per SendGrid (la piattaforma email transazionale acquisita da Twilio nel 2019, 80k+ paying customer, leader della categoria insieme a Postmark/Mailgun/SES per ESP managed cloud) via Mail Send API v3 ufficiale. Due operazioni atomiche coprono i pattern principali di sending: sendEmail (invio diretto con to+from+subject+body sia text plain sia HTML rich con embedded CSS), sendTemplate (usa Dynamic Template SendGrid creato nella web UI con Handlebars syntax + passa dynamic_template_data JSON per substitution dei placeholder server-side — pattern recommended enterprise per separare logic invio dal template design che è managed dal marketing team senza dover deploy codice). Auth via API Key Bearer (formato SG.xxxxx generato dall'admin SendGrid in Settings → API Keys con scope mail.send.full o granular permission slug) stored nel vault integration FlowForge. Multi-key supportato per separazione production vs dev environment o per agency con N customer subaccount. Validation pre-send enterprise: email destinatario validato sintatticamente con regex RFC 5322 simplified per detect typo ([email protected] → flag warning typo "did you mean gmail.com?"), supporto reply-to header indipendente dal from (pattern critico per "no-reply@" sender ma reply al support box), nome mittente custom ("Acme Customer Service <[email protected]>" → friendly UI display per ricevente). Pipeline anti-vulnerability: tutte le request transitano via il SSRF-safe gateway HTTP del runtime (safeFetchWithRedirects) per evitare di chiamare endpoint interni privati 192.168.* per misconfig; circuit-breaker dedicato per SendGrid evita di hammer l'API durante upstream outage (stato open dopo 8 fail in 60s → cooldown 30s → half-open probe); retry exponential backoff su 5xx e 429 transitori. Gestione semantica robusta della response 202: SendGrid ritorna HTTP 202 Accepted SENZA body (Mail Send è asincrono server-side, il delivery vero avviene minuti dopo) — il nodo NON tenta di parsare response body inesistente e ritorna success se status=202. Output: { accepted (bool), to, from, operation (sendEmail|sendTemplate), messageId? (header X-Message-Id se SendGrid lo ritorna), durationMs }. Use case enterprise transazionali standard: conferma ordine/registrazione user post-signup; reset password con link UUID firmato + TTL 1h; ricevuta pagamento Stripe webhook → invio receipt PDF allegato al cliente; newsletter transazionale (non marketing — solo update operativi del servizio); notifica scadenza abbonamento +30/+7gg con template brandizzato Dynamic Template; onboarding drip campaign multi-step (giorno 1, giorno 3, giorno 7, giorno 14) con sequence configurabile; alert sistema agli amministratori del cliente customer-facing per monitoraggio operativo.

Connettore enterprise per Asana — la piattaforma di project management leader di mercato per team mid-market enterprise (130k+ paying customer dal 2008, IPO 2020 con valutazione $5B+, base installata particolarmente forte nel marketing/sales/operations team distribuiti dove serve workflow visibility cross-functional) via REST API 1.0 ufficiale. Tre operazioni atomiche coprono il ciclo task management: createTask (inserisce nuovo task con titolo, note markdown rich, project_id target nel workspace, assignee_id del responsabile, due_on per scadenza, tags per categorization, parent_task per sub-task nidificate, custom_fields per workflow custom-tailored), getTask (fetch puntuale di un task by GID con tutti i field completi incluso stories timeline + memberships per multi-project task + custom_fields), addComment (story sul task — Asana chiama "stories" tutti i log events del task: comments, status updates, assignment changes, completion ticks — ognuna è una story con author + timestamp + content). Auth via Personal Access Token (formato 1/xxxxxxxx generato dall'admin Asana in Settings → Apps → Manage Developer Apps → + New Access Token) stored nel vault integration FlowForge. Multi-workspace supportato (un tenant FlowForge che gestisce N workspace Asana diversi per agency che serve N customer). Validation enterprise pre-API call: due_on scadenza validata formato YYYY-MM-DD strict (anti-errore di passing ISO 8601 con time component che Asana rigetterebbe 400), supporto multi-progetto (un task può essere assigned a multipli project simultaneamente — pattern per shared cross-team initiative), assignee_id risolto by email (lookup contro team membership cache) per pattern friendly. Pipeline anti-vulnerability enterprise: tutte le request via SSRF-safe gateway (evita di chiamare endpoint interni privati per misconfig); circuit-breaker dedicato per Asana evita hammer durante upstream outage; retry exponential backoff su 5xx e 429 transitori; body request wrappato nel formato { data: { ... } } che Asana API richiede (the envelope JSON pattern che molti developer sbagliano). Rate limit Asana: 150 req/min sustained per token (3 RPS comfortable per use case interactive), header X-RateLimit-Remaining trackato per warning preventivo. Output: { taskId? (GID Asana), url? (permalink al task nel Asana web app per click direct), task? (object completo per getTask), commentId? (story GID), createdAt, modifiedAt }. Use case: crea task automatic da email customer support in arrivo (trigger_imap + agent_email_triage + createTask nel project "Support Queue" con title cliente subject + body in note); apri ticket da errore workflow runtime (catch error handler → createTask in project "Bugs" con stack trace + run link); assegna follow-up commerciale automatic post-meeting Calendly closed-won (createTask "Send thank-you email to {{customer_name}}" assigned to AE responsabile, due +1day); sincronizzazione bidirezionale CRM Salesforce → Asana project management (lead Salesforce passa a stage "Discovery" → crea task in Asana per il consultant); genera checklist di onboarding cliente automatic (create 10 sub-task standard per ogni new customer da master template); commenta avanzamento step-by-step da sistema esterno (CI build complete → addComment su task corrispondente "✅ deploy OK at {{time}}").

Connettore enterprise per Dropbox — la piattaforma di file sharing/sync cloud pioniere del settore (fondata 2007 nel garage del MIT, IPO 2018, 700M+ utenti registered + 18M+ paying customer business — di cui particolarmente forte penetration in smb e creative agency che la usano per asset sharing) via API v2 ufficiale REST. Cinque operazioni atomiche coprono il file/folder lifecycle: listFolder (enumera contenuto di una cartella con opzionale ricorsivo deep + filter cursor-based per cartelle con migliaia di item), createFolder (crea nuova cartella nested fino a profondità arbitraria), getMetadata (info di file/cartella specifico: name, path, size, modified_time, content_hash per integrity check), createSharedLink (genera URL di condivisione pubblico con visibilità configurable + scadenza opzionale per delivery temporanea), deletePath (cancella file o cartella con soft-delete in Trash 30gg per recovery accidentale). Auth via OAuth2 Access Token Bearer (long-lived token generato dall'admin Dropbox via OAuth2 authorization code flow, oppure short-lived con refresh-token per security più stringente) stored nel vault integration FlowForge accessibile via integrationLabel — pattern portal-centric multi-tenant enterprise FlowForge per condividere refresh-token tra workflow del stesso tenant. Multi-account supportato (un tenant FlowForge che gestisce Dropbox di N customer differenti). Path normalization automatic: l'API Dropbox usa una sintassi specifica per i path (es. "" per root, "/Documents/Reports" per sub-folder con leading slash) — il nodo astrae questa convention e accetta pattern friendly come "Documents/Reports" auto-fixing il leading slash + handling del case-sensitivity. Pipeline standard FlowForge: SSRF-safe gateway, circuit-breaker dedicato per Dropbox per evitare hammer durante upstream outage, retry exponential backoff su 5xx e 429 transitori. Rate limit Dropbox: quota-based per token + endpoint (varies, alcuni endpoint hanno 25 req/min, altri 1000 req/min — il nodo gestisce 429 automaticamente). Output: { entries? (per listFolder, array di { name, path, size, type=file|folder, modified, content_hash }), count?, id? (per createFolder), sharedUrl? + accessLevel? + visibility? (per createSharedLink), metadata? (per getMetadata), deleted? (boolean per deletePath), cursor? per pagination continue }. Use case: archivia automatic fatture/documenti generati da workflow di billing (al closing di ogni fattura → save PDF nella cartella "Fatture/2026/05/" con naming convention sortable); backup file di workflow su cloud per long-term retention senza consumare disk space del runtime tenant; genera link condivisione per consegna asset cliente con scadenza 7gg (createSharedLink + invio per email via action_send_email); organizza upload per cartelle datate auto (createFolder per ogni giorno solare + save degli ingest del giorno lì); sincronizza output report mensile management su Dropbox team shared workspace per cross-team visibility; pulizia automatica di file temporanei più vecchi di 30gg (cron mensile + listFolder + filter modified < now - 30d + deletePath).

Connettore enterprise per Box.com — la piattaforma di Enterprise Content Management cloud nata nel 2005 (IPO 2015, $3B+ valuation, 100k+ customer enterprise tier-1 inclusi GE, Coca-Cola, Toyota, Bank of America) — alternativa enterprise-focused a Dropbox/Google Drive con feature dedicate per governance documentale, compliance HIPAA/SOC2/FedRAMP, granular permission con accessi role-based, workflow approvals nativi, content classification & retention policies — via API 2.0 ufficiale. Cinque operazioni atomiche coprono il file/folder lifecycle: listFolder (enumera items di una cartella identificata by folder_id, root cartella tenant ha sempre id="0" — pattern di discovery contenuto), createFolder (crea nuova cartella sotto un parent specifico), getItem (metadata di un file o cartella specifico — tipo, size, creation date, owner, version_count), createSharedLink (genera shared URL per file/folder con livello visibilità configurable: open=URL pubblico chiunque conosca il link può accedere, company=solo membri del Box enterprise account, collaborators=solo utenti esplicitamente shared del file), deleteFile (cancellazione con soft-delete in trash 30gg default per recovery). Auth via Access Token Bearer (formato OAuth2 stored nel vault — il token short-lived 60min richiede refresh-token flow gestito dal portal-centric OAuth2 service per multi-tenant SaaS pattern enterprise). Multi-account supportato (un tenant FlowForge che gestisce N Box account distinti per agenzie che servono multiple customer enterprise). Validation enterprise pre-API: file/folder ID validati numerici (anti-typo che produrrebbe 404), shared link access level enum-strict, name length cap 255 char (limite Box). Pipeline anti-vulnerability standard FlowForge: tutte le request via SSRF-safe gateway, circuit-breaker dedicato per Box, retry exponential backoff su 5xx/429. Rate limit Box: 5000 req/min sustained per app + token combination (83 RPS, comfortable per use case enterprise), header X-Box-Endpoint-Request tracked. Output: { entries? (per listFolder), count?, id? (per createFolder/createSharedLink), sharedUrl? + accessLevel? + expiresAt?, item? (per getItem), deleted? (boolean per deleteFile), totalSize? per folder summary }. Use case enterprise content management: archivio documentale aziendale governato (workflow di ingest documents → classification → store nella corretta cartella subdivision per dipartimento + tag con metadata custom); condivisione controllata file con clienti/partner B2B (createSharedLink con access=company per limitare visibility); gestione contenuti compliance-ready per audit ISO 27001/SOC2 con retention policy automated; automazione cartelle progetto (al closing di un new deal Salesforce → createFolder "Projects/{{customer_name}}/{{project_id}}" + setup default sub-structure); distribuzione report mensile management con permessi company-only; retention automatica documenti fiscali (10 anni dal createdAt → workflow cron mensile + delete o move to archive cartella).

Connettore enterprise per Google Cloud Storage (GCS) — il blob storage service di Google Cloud Platform che è la base dell'object storage per Google itself + 6M+ paying GCP customer (alternativa a AWS S3 e Azure Blob Storage, particolarmente strong su prezzo per cold archive Coldline/Archive storage class, integrazione native con BigQuery per data lake analytics, e dual-region/multi-region per GDPR-compliant EU residency) via JSON API v1 ufficiale. Tre operazioni atomiche coprono i pattern principali del object lifecycle: listObjects (enumera object di un bucket con prefix filtering opzionale "logs/2026-" per scoping, paginazione cursor-based per bucket con milioni di object, pattern di discovery batch processing), getObjectMetadata (info dettagliata di un object specifico compreso content-type, size, md5Hash + crc32cHash per integrity check, generationNumber per versioning, mediaLink che è l'URL signed da usare per il download del payload binary), deleteObject (cancellazione con soft-delete configurabile se versioning enabled sul bucket — recovery 7gg default). Auth via OAuth2 access token con scope devstorage.read_write (oppure devstorage.read_only per use case lista-only), stored nel vault integration FlowForge tramite portal-centric OAuth2 multi-tenant pattern — refresh-token gestito centralmente, runtime tenant riceve access_token short-lived (1h TTL Google) via JWE handoff 5min. Validation enterprise pre-API: bucket name validato sintatticamente come RFC GCS strict (3-63 char lowercase + numeri + - + . without leading/trailing dash + not IP-like — Google rifiuterebbe 400 altrimenti); object name validato senza control characters; ID validati numerici per generationNumber. Pipeline standard FlowForge: SSRF-safe gateway, circuit-breaker dedicato per GCS, retry exponential backoff su 5xx Google transient (rare ma succedono soprattutto su region migration eventi) + 429. Rate limit GCS: 5000 read req/sec per bucket (generoso, no concern usual use case), 1 RPS write/bucket per same-named object (anti-thrashing, raramente hit). Output: { objects? (per listObjects, array of [{ name, size, contentType, updated, md5Hash, generation }]), count?, metadata? (per getObjectMetadata), mediaLink? (per download signed URL), deleted? (per deleteObject), bucket, nextPageToken?, totalSize? }. Use case: archivia output workflow su bucket GCS per long-term retention (workflow genera PDF report → upload su GCS con storage class "Coldline" per ottimizzare costo); lista file per elaborazione batch nightly (cron orario + listObjects su prefix "incoming/" + per ogni file processa + sposta in "processed/" + delete original); pulizia automatic oggetti scaduti (lifecycle policy lato GCS + workflow di audit settimanale di verifica); genera link download signed per consegna client di file temporanei (TTL 24h dopo workflow di delivery completion); pipeline ETL da data lake GCS verso BigQuery downstream o Snowflake export; backup documenti enterprise con retention 7 anni per compliance fiscale italiana.

Agente AI enterprise specializzato nel debug post-mortem di workflow run falliti — sfrutta il LLM Liara per analizzare i dati granular di una run errored (steps json + outputs + error stack + config dei nodi coinvolti) e produrre raccomandazioni actionable di fix con confidence score, riducendo il tempo mean-time-to-resolution da ore-giorni (debug manuale) a minuti (AI-assisted triage). Pattern di AIOps copilot per workflow orchestration analogo a Datadog Watchdog o New Relic AI per i monitoring tool tradizionali. Pipeline multi-stage gestita end-to-end dall'agent: (1) Fetch run JSON completo dal SQLite runtime tenant — recupera tutti i steps eseguiti con il loro input/output, la error stack del step fallito, la config completa del nodo che ha generated l'errore, il context delle env vars rilevanti; (2) Diagnose root cause via LLM analysis del context con 5 categorie di errore canoniche enterprise: transient (network blip, rate-limit 429 temporaneo, upstream 5xx — pattern auto-recoverable con retry), config (parametro mal-configurato, URL errato, schema mismatch — richiede edit dell'utente), payload (input data malformato, type coercion failed, JSON parse error — issue upstream nei dati), auth (credenziali scadute, token revoked, scope insufficienti — richiede rotation/re-auth dell'integration vault), quota (esauriti i limiti del piano o dell'API upstream — richiede upgrade o ottimizzazione); (3) Genera 3-5 suggestedFixes ordinati per confidence + impact: config patch (modifica diff-friendly del config del nodo offendente), retry policy adjustment (aggiungi exponential backoff + max_retries=5 per transient), nodo replace (suggerimento di sostituire con un altro nodo più adatto al pattern), input guard (aggiungi logic_if upstream per validare il payload prima di processarlo); (4) Genera suggestedTests automaticamente Zod-validated — il LLM crea test case JSON che expose il bug specifico fixato, pattern TDD reverse per prevenire regressioni future. Output: { diagnosis: { rootCause (narrative description del cosa è andato storto), category (transient|config|payload|auth|quota), confidence (0-1 dell'AI sul suo verdetto) }, suggestedFixes: [{ description, type, configPatch?, confidence, expectedImpact }], suggestedTests: [{ input, expected, reason }], replayCommand (one-click apply del top fix + relaunch del workflow per validation) }. Use case: debugging assist post-incident enterprise (il workflow di chiusura conti mensile è fallito la notte → al risveglio l'admin vede direttamente la diagnosi AI + fix proposto, applica con un click invece di indagare 2 ore); suggestions DX per junior workflow author che imparano gradualmente i pattern enterprise (AI come "rubber duck" intelligente); auto-recovery cron su workflow critici (workflow di production che ha catch error handler che chiama agent_debug + auto-apply del fix se confidence > 0.9); training dataset per fine-tune del Liara su pattern errori reali specifici del workspace customer per personalization (i Liara LoRA del cliente che imparano nel tempo cosa è "fine" vs "broken" nel suo contesto specifico).

Generatore enterprise di documenti PDF stampabili partendo da componenti structured (titolo, sezioni testuali multi-paragrafo, tabella dati opzionale, intestazione/piè di pagina branded, immagini logo) — la primitiva di tutti i workflow che producono output cartaceo/print-ready destinati a clienti, partner, team interno, archivio compliance. Built su libreria pdfkit Node.js (battle-tested 12M+ downloads/anno, genera PDF 1.7 valid e compatibile con qualsiasi reader: Adobe Acrobat, Preview macOS, Foxit, browser embedded viewer, mobile reader). Componenti del documento configurabili dall'editor visuale: titolo principale (heading 24pt, centrato di default, customizable font + size + color), sezioni testuali multi-paragrafo con support a markdown subset (bold, italic, underline, link cliccabili), tabella optional con colonne configurate da header array + righe da array di array (column auto-width oppure fixed width esplicito per controllo layout, alternating row color zebra-stripe per readability, header bold + colored background per separation visiva), intestazione/piè di pagina ricorrente con logo aziendale (caricato come base64 da action_file_read upstream), paginazione automatica con conteggio "Pagina X di Y", marche di separazione tra sezioni. Layout pulito di default Helvetica (cross-platform standard, no font embed required = file size piccolo); override possibile con font custom embeddable (Roboto, OpenSans, Inter, Times New Roman per documenti legali) — il customer può uploadare TTF/OTF nel vault asset del tenant e referenziarlo nel config. Output: base64 string (pronta da collegare direttamente al campo attachmentsJson di action_send_email per inviarlo come allegato senza passare per filesystem intermedio) oppure save su disco nel sandbox del tenant (per documenti destinati a download UI later). Output structure: { base64, size_bytes, page_count, path?, fileName, mimeType: "application/pdf" }. Compliance enterprise: i PDF generati sono PDF/A-2u valid quando enableArchive=true (subset PDF/A per long-term archival con embed di tutti i font necessari + no encryption + metadata XMP standard), pattern critico per archivio fiscale italiano dove la conservazione a norma DPCM 2014 richiede PDF/A — abbinato con action_pec_legal_archive completa il flow legale. Use case: catalogo prodotti settimanale spedito via email ai venditori del territorio con foto, descrizione, prezzo netto, sconto applicabile per categoria cliente; fattura/preventivo generato post-checkout PayPal/Stripe con i dettagli ordine + dati fiscali + footer con condizioni di vendita; report mensile metriche business allegato a riunione management con chart embedded (generati da generateChart upstream + embed come immagine PNG nel PDF); ricevuta automatic dopo registrazione form/evento (Calendly, Typeform, trigger_form) con QR code embed per check-in scanning all'evento; contratto pre-compilato con dati cliente per onboarding nuovi clienti SaaS (pdf prepared, customer firma con DocuSign downstream); certificato di partecipazione corso formazione con nome + data + firma CEO embedded per training programs aziendali.

Nodo generico LLM (Large Language Model) per generazione open-ended di testo o JSON strutturato, da qualsiasi prompt e con il provider configurato — la primitiva atomic di accesso alle capacità AI sottostanti la quale sono costruiti gli agent_* specializzati. Default: Liara Qwen3-32B FP8 self-hosted on-prem (vLLM su Hetzner Blackwell GEX131 RTX PRO 6000 96GB Falkenstein DE — zero trasferimento dati extra-UE, latenza p50 800ms, costo zero per il cliente nelle quote del piano). Override via BYOK con uno dei 9 provider esterni: Anthropic Claude Sonnet 4 (state-of-art reasoning, $3/MTok input), OpenAI GPT-4o ($2.5/MTok input), Google Gemini 1.5 Pro ($1.25/MTok input long-context 1M token), DeepSeek-V3 ($0.27/MTok input, sweet spot prezzo/qualità), xAI Grok-2, OpenRouter (aggregator multi-modello), Perplexity Sonar (con web search built-in), Mistral Large, Groq (LPU inference ultra-veloce su Llama-3 e Mixtral). Routing automatico via header X-FF-Provider gestito dal gateway LLM portal con quota mensile dedicata BYOK separata da Liara. Modalità output: testo plain (default — generazione discorsiva libera) oppure JSON structured (prompt include schema target + response_format json_object per Anthropic/OpenAI, fallback parsing per altri provider — validation downstream con Zod schema raccomandata). Temperature configurabile (0.0 deterministic per classifier, 0.7 default balanced, 1.0 creative per copywriting). max_tokens cap per controllo costo. Use case: scrittura di risposta email personalizzata multilingua per customer support B2B che integra context del cliente da memory_note (ordini precedenti, ticket aperti, preferenze comunicazione); generazione di descrizioni prodotto e-commerce SEO-friendly a partire dalla scheda tecnica raw del fornitore; classificazione di testo libero in categorie business custom non coperte da agent_* pre-tunati (es. classifier su 50 categorie merceologiche del settore agroalimentare); estrazione di entità strutturate da unstructured text (es. parse di paragrafi PEC ricevuti per estrarre partita_iva+importo+data_scadenza in JSON pronto per ingest contabile); brainstorming di idee marketing su brief ridotto per content creator. IMPORTANTE: se hai un task specifico ricorrente (triage email, sales reply, summarizer, translation, classifier ufficiale, intent routing), preferisci gli agent_* dedicati — sono pre-tunati con prompt engineering ottimizzato per quel task specifico, hanno output schema fisso testato, error handling specializzato, e tipicamente 2-3× più accurate vs prompt generico al action_llm_complete.

Nodo meteo enterprise che recupera condizioni atmosferiche correnti e forecast 7 giorni per qualsiasi località del mondo, usando l'API pubblica Open-Meteo (servizio europeo gratuito senza API key, basato su modelli ECMWF + DWD + GFS + ICON e altri 8 modelli meteorologici nazionali, dati licenziati CC-BY 4.0 per uso commerciale libero) — alternativa a OpenWeatherMap (richiede API key con quota), WeatherAPI (paid tier oltre il free 1M req/month), AccuWeather (API molto costoso) o Tomorrow.io. Il sourcing europeo è particolarmente accurato per Italia + Europa con risoluzione 1-3 km grid + update 6× al giorno. Reverse-geocoding incluso nativo: l'utente passa il nome città in linguaggio naturale italiano (es. "Roma", "Milano", "Bari Vecchia", "Termoli", "San Giovanni Rotondo") e il nodo risolve automatic le coordinate lat/lon via Open-Meteo geocoding API che ha copertura di città + paesi + frazioni con matching fuzzy + disambiguation su omonimi (es. "Cesena" vs "Cesenatico"); supporta anche lat/lon diretti per power user che già hanno le coordinate da GPS o altri sistemi. Cache in-memory smart: TTL 1h per chiave (lat, lon rounded a 0.1° per merge di richieste vicine) — workflow batch che colpiscono la stessa città N volte (es. cron orario di 50 negozi di Roma) NON spammano l'API Open-Meteo che è generously rate-limited ma comunque non infinita. Output structured consumabile direttamente da dashboard SSR/email digest/IoT automation: { current: { temperature, humidity, wind_speed, wind_direction, weather_code, is_day, time }, forecast: [{ date, temp_max, temp_min, precipitation_sum, precipitation_probability, weather_code, uv_index_max }], location: { name, country, lat, lon, timezone }, meta: { units, model_source, generated_at } }. Weather code mapping a italiano per UI-friendly display: 0=sereno, 1=poco nuvoloso, 2=parzialmente nuvoloso, 3=coperto, 45=nebbia, 48=nebbia gelata, 51=pioggerellina leggera, 53=pioggerellina, 55=pioggerellina intensa, 61=pioggia leggera, 63=pioggia, 65=pioggia intensa, ecc. (codici WMO 4677). Use case: digest meteo giornaliero per agenzia turistica italiana inviato via email ai propri clienti con previsioni delle località del pacchetto vacanza; alert temperatura per monitoraggio magazzino refrigerato (cron 30min + check temp < 2°C → notify ops se prevista grandinata che potrebbe danneggiare sistemi); automazione IoT spegni-AC se outdoor temperature < 20°C (workflow che integra weather + sensor temperature interno + relay control via webhook smart-home Aqara/Shelly); widget meteo embedded in dashboard tenant agency travel che mostra il meteo per destinazioni preferite del customer; optimization logistica trasporti pesanti (autotreno) che evita le rotte con maltempo previsto +24h.

Reader enterprise di feed RSS/Atom — il formato standard sindacato da decenni che ogni blog, news site, podcast, GitHub releases, YouTube channel, e in generale ogni publisher serio espone come meccanismo di distribuzione dei contenuti push-friendly per i subscriber. Scarica il feed dall'URL fornito (esempi tipici: feeds.feedburner.com/HackerNews, googlenews.com/news/rss, github.com/repo/releases.atom, qualsiasi blog WordPress espone /feed/) e ne fa il parse semantico secondo i due standard dominanti: RSS 2.0 (il format storico più diffuso, supporta channel + item + enclosure per podcast audio) e Atom 1.0 (lo standard moderno IETF RFC 4287 con namespace XML rigoroso e features rich come content type detection — preferred dai publisher tecnici come blogger.com e GitHub). Estrazione strutturata degli ultimi N items (default 10, configurable 1-100): title (titolo del post), link (URL canonical dell'article), pubDate/updated (timestamp ISO 8601 dell'pubblicazione/update), snippet (description o summary del content, plain text con HTML stripped per readability), author (when declared nel feed), categories (array di tag/categorie dichiarati dal publisher per filtering downstream), enclosure (per podcast/multimedia: URL del file audio + content-type + size). Output opzionale rendering pronto per consumo umano: markdown (per Telegram bot, Slack message, README aggregation), HTML (per email digest con CSS inline, dashboard SSR widget embed), plain text (per minimal logging). Cache in-memory smart: TTL 5min per feedUrl normalizzato — workflow batch che colpiscono lo stesso feed N volte in burst (es. 10 workflow del tenant interessati allo stesso Hacker News feed) NON spammano la sorgente facendo Ddos accidentale del publisher — ovviamente questo riduce anche carico sul publisher (pattern good citizenship della rete). Bot-friendly enterprise: User-Agent identifica esplicitamente "FlowForge-NewsReader/1.0 (+https://flowforge.automazionezeli.com/bot)" per consentire al publisher di identificare il bot legittimo e opzionalmente whitelist o rate-limit; rispetta robots.txt del dominio target evitando di crawlare feed esplicitamente denied. Esempi famosi di feed processabili: Google News RSS per news topic-specific ("Italy" "fintech" "climate"), sitemap blog di qualsiasi WordPress site, Hacker News top stories, GitHub releases del dependency che il customer monitora per security updates, YouTube channel feed per detection nuovo video pubblicato. Use case: (1) digest news quotidiano email per team marketing, (2) widget Hacker News su dashboard interna, (3) broadcast Slack/Telegram al rilascio di nuove versioni vendor tracked via GitHub releases, (4) ingest content per pipeline AI summarization.

Storage enterprise chiave-valore persistente scoped per workflow — la primitiva per implementare workflow stateful che devono ricordare dati cross-run tra esecuzioni successive del stesso workflow (cursor di paginazione di sync incrementali, contatori di retry, flag di "già processato" per idempotency, baseline KPI per detection di drift, timestamp di "ultima esecuzione" per cron skip-if-recent logic). Implementazione robusta su SQLite per-tenant del runtime, table dedicata `workflow_memory` con isolation rigorosa per workflow_id — workflow diversi NON si vedono tra loro (gli engineer principle di least privilege + memoria privata per workflow per evitare leak di state tra contesti separati e comportamenti emergenti debugging-difficili). Cinque operazioni atomiche coprono tutti i pattern stateful necessari: (1) get — legge il valore associato a una key, restituisce null se la key non esiste (pattern safe check-before-use), default value configurable per fallback automatic; (2) set — scrive (o sovrascrive se esiste) il valore della key, valore può essere qualsiasi JSON serializzabile (string, number, boolean, array, object nested fino a 1MB cap per safety); (3) append — operazione atomic specifica per array di valori: appende un nuovo item alla fine dell'array esistente, crea l'array se la key non esiste (pattern naturale per log accumulato di eventi); (4) delete — rimuove la key (idempotent: delete su key inesistente = no-op); (5) list — restituisce elenco di tutte le key esistenti per il workflow corrente con filter pattern opzionale (es. list("cursor:*") per tutte le key che iniziano con "cursor:"). TTL opzionale per auto-cleanup: ogni key può avere expiresAt configurato, il janitor del runtime rimuove periodicamente le key scadute — pattern utile per cache time-limited (es. "deduplica notify per 24h" → key con TTL 86400s) senza dover gestire manualmente cleanup logic. Concurrency: le operazioni sono atomic (SQLite transaction per write), in caso di concurrent run dello stesso workflow (es. due trigger_webhook simultanei), le scritture sono serialized — no race condition su counter increment (l'idiom get → modify → set è race-prone, raccomandato pattern dedicated atomic increment se servisse). Output: { value (per get/set), exists (boolean), expiresAt? (timestamp), keys[] (per list), changed (boolean per detect modify), oldValue? (per set, per audit del cambio) }. Use case: memorizzare cursor di paginazione di una sync incrementale (es. "last_synced_at" per next iteration del cron, evita ri-fetch dei dati già processati); contatore tentativi retry distribuito su run cron schedulati (retry_count++ ogni fail, reset al success); flag "già notificato" per evitare doppi alert su stesso evento ricorrente (key "alerted:incident:XYZ" con TTL 24h); timestamp ultima esecuzione per cron skip-if-recent logic (se < 5min fa, skip questo tick); budget spese API mensili (cumulative cost tracking per quota enforcement custom oltre quelle del piano); accumulo di list di errori per batch summary email digest a fine giornata.

Helper enterprise specializzato per generare deep-link URL canonici verso la view "Run History" dell'editor FlowForge — il pannello slide-out che mostra l'elenco paginato di run di un workflow con filtri rich (status, date range, error type, triggered_by, search nel JSON di input/output), pre-pronto da incorporare in qualunque output testuale del workflow downstream che andrà letto da un essere umano (email, notifica chat, SMS, dashboard print, PDF report) per consentirgli un single-click "vai a vedere i dettagli concreti senza dover navigare manualmente nell'editor". Il workflow target è configurabile: il workflow corrente (self-link, default — il pattern più comune per email di errore: "questo workflow ha avuto X errori oggi, vedi dettagli") oppure un workflow target arbitrario via workflowId (utile per workflow di alerting/orchestration che fanno report cross-workflow). Filtri opzionali query string pre-applicati al link generato che selezionano automaticamente la view nel caricamento: stato (success | partial | error | running | paused | all), dateFrom/dateTo (ISO 8601 oppure espressioni relative tipo "today", "-7d", "last_month"), query search (full-text su input/output JSON content), triggerType (manual, webhook, cron, subworkflow), errorContains (filtro su error_message). URL generato è relativo al baseUrl pubblico del tenant FlowForge (deriva dalla env FLOWFORGE_PUBLIC_BASE_URL del container, tipicamente https://<slug>.app.automazionezeli.com) oppure assoluto se baseUrl override è impostato — il second'use case è quando si vuole forzare il link verso la dashboard portal centrale (https://flowforge.automazionezeli.com) invece del subdomain tenant per casi di multi-tenancy reporting. Output: { url (string completo encoded), workflowId, queryString, isRelative }. Use case principali della pipeline notification: email digest serale "il workflow X ha avuto Y errori oggi → [vedi dettagli]" con click sul link che apre direttamente Run History filtrato per status=error date=today — l'operatore vede subito le 5 run errored senza navigare 4 click; report admin daily inviato via PEC o email che linka cross-workflow gli incident del giorno; notifica Slack/Telegram/Discord automatica con embed che include il link diretto al run history per consentire al team developer di triagare velocemente; alerting su SLO degraded (latency p99 > 10s) con embedded link al history filtrato per i run che hanno triggerato l'alarm; client-portal share token che restituisce un URL preventivamente firmato per consentire al cliente esterno (senza login tenant) di vedere l'history del SUO workflow ordinabile.

Connettore enterprise per GitHub.com (la piattaforma DevOps Microsoft con 100M+ developer attivi, standard de-facto per code hosting open-source e privato, alimentata da una solida API REST stabilizzata dal 2008 e ora estesa con GraphQL v4 per query rich) via API REST v3 ufficiale. Sette operazioni atomiche gestiscono il ciclo di vita issue+PR+commit: createIssue (apertura nuova segnalazione con title, body markdown, labels array, assignees array, milestone, reactions iniziali), listIssues (paginated con filtri compound state/labels/assignee/since per dashboard interne), createPullRequest (apertura PR con head→base branch, draft mode optional, body markdown con auto-link a issue tramite "Closes #N", reviewers + team_reviewers assegnati), listCommits (storico commit di un branch/path per audit/changelog auto), getIssue (fetch puntuale con full body + comments + timeline events), closeIssue (con motivazione "completed" o "not planned" GitHub 2023+), addComment (markdown body con embedded link e mentioni @user/@team che triggerano notify GitHub). Auth via Personal Access Token classico (formato ghp_xxxxxxxx, scopes: repo, workflow) o fine-grained (formato github_pat_xxxxxxxx, scopes per-repository granular: contents read/write, issues read/write, pull_requests read/write, metadata read — raccomandato per security minima esposizione 2024+). Token stored nel vault integration FlowForge con label leggibile (es. "github-org-acme-prod-bot"). Rate limiting GitHub: 5000 req/h authenticated (1.4 RPS sustained) per user/PAT, 15000 req/h per GitHub App, 60 req/h anonymous (mai usato in produzione). Header X-RateLimit-Remaining tracked dal nodo, auto-backoff quando < 100 remaining per evitare burst saturation, retry exponential su 429 con header Retry-After. Conditional requests (ETag + If-None-Match) usate quando possibile per non consumare rate limit su risorse invariate (es. listCommits del mainstream). GraphQL API NON usata da questo nodo (più powerful per query annidate ma 5× più complessa da configurare per non-developer — disponibile via action_http custom per power user). API docs: docs.github.com/en/rest (REST API v3 stable). Use case: bug report automatico da error handler workflow → createIssue su repo "support" con title "{{error.code}}: {{summary}}" body markdown con stack trace + run_id link al run viewer dashboard tenant; PR auto-creation post-commit successful tramite CI workflow del flow upgrade automatic; sync bidirezionale issue tra Linear workspace e GitHub repository (label sync, status sync, assignee sync con OAuth user mapping); monitoraggio commit storia su mainstream per audit di compliance ISO 27001 (chi ha committato cosa quando); creation automatic di changelog markdown da listCommits filtrati per merge commit del release branch tra due tag.

Connettore enterprise per HubSpot CRM (la piattaforma marketing+sales+service di Cambridge MA con 200k+ customer paganti, dominante nel B2B mid-market US/EMEA, gestisce il funnel completo dal MQL al revenue) via API REST v3 ufficiale. Sette operazioni atomiche coprono il flusso CRM standard: createContact (lead capture da form web/Calendly/Typeform), updateContact (post-engagement: update lifecycle_stage MQL→SQL, sync da gestionale esterno), getContact (lookup per email, vid, o by_property), listContacts (paginated export filtrato per segmentation), createDeal (opportunità con pipeline+stage assegnati, expected_close_date, amount in € EUR), updateDeal (movimentazione kanban tra stage: Appointment Scheduled → Qualified to Buy → Closed Won), createCompany (account record per ABM B2B con domain dedup automatico HubSpot). Pattern UPSERT idempotente: il nodo cerca contact by email (con cache 60s per richieste consecutive nel stesso workflow), crea se assente, aggiorna se presente — evita duplicati che intasano il database CRM e confondono i sales rep ("perché Mario compare 3 volte?"). Auth via Private App Access Token (formato pat-eu1-xxxxxxxx oppure pat-na1-xxxxxxxx in base alla regione hosting HubSpot del customer) generato dall'admin nella sezione Settings → Integrations → Private Apps, con scopes minimum: crm.objects.contacts.read/write, crm.objects.deals.read/write, crm.objects.companies.read/write. Il token è stored nel vault integration FlowForge e referenziato via integrationLabel — multi-account HubSpot supportato (un tenant FlowForge che gestisce 5 portali HubSpot come MSP). Rate limit HubSpot v3: 100 req/10sec per token (10 RPS sustained), 250k req/giorno per token Professional, unlimited per Enterprise — il nodo gestisce 429 con Retry-After exponential backoff + jitter, fallback su 5xx gateway error con 3 retry distribuiti. Custom properties: il nodo supporta automaticamente le proprietà custom del tenant HubSpot (fino a 1000 properties/object), validation tipo (string, number, datetime, enumeration, bool, date) prima dell'invio per evitare 400 BadRequest. API docs: developers.hubspot.com/docs/api/crm — versione API v3 (2023+), v1 legacy deprecato. Use case: lead capture da Typeform → contact con properties {{first_name}}, {{company}}, {{interest_area}} + lifecycle_stage=lead; ordine pagato Stripe webhook → upsert contact + create deal con amount=order.total e stage=Closed Won + associazione contact↔deal; registrazione azienda B2B da SignUp form con dominio aziendale → create company con domain+industry + create contact admin associato; nightly sync da Odoo res.partner verso HubSpot contact per allineare il CRM marketing con la base clienti contabile.

Connettore enterprise per Notion (la piattaforma di knowledge management cresciuta a 30M+ utenti, oggi usata massivamente da startup e team distribuiti per docs, OKR tracking, project planning, wikipedia interne, CRM lightweight, intranet sostitutiva di Confluence) via API REST ufficiale Notion v1. Quattro operazioni atomiche coprono il 95% degli use case workflow: createPage per inserire una nuova pagina sotto un parent (database con properties schema oppure pagina libera con block content), queryDatabase per filtri rich con cursors paginati e ordering compound, updatePage per modificare properties di un record già esistente in database (case classico per kanban move tra status), getPage per fetch puntuale con blocks (paragraph, heading_1/2/3, bulleted_list_item, numbered_list_item, callout, code, image, embed, divider, table, child_database). Auth via Internal Integration Token (formato secret_xxxxxxxx) creato dal workspace admin nella sezione Integrations del Settings — il token va aggiunto al vault integration FlowForge con label leggibile (es. "notion-marketing-team-token") e referenziato via integrationLabel nel nodo. Critical: dopo aver creato il token, ricordare di "Share" esplicitamente la pagina/database con l'integration dall'UI Notion (menu ⋯ → Add connections), altrimenti l'API ritornerà 404 "object_not_found" anche con token valido. Pagination automatica via has_more + next_cursor (il nodo accumula tutti i record fino al limite di 100 pagine totali di sicurezza, configurable). Rate-limit Notion: 3 req/s media per integration, enforcing 429 con Retry-After header — gestito con backoff esponenziale automatico nel nodo. Schema validation: i campi properties devono matchare lo schema del database target — il nodo verifica la coerenza Type prima dell'invio (rich_text accetta array di rich_text, title accetta plain_text + rich_text, number accetta numeric, status/select accetta name esistenti, multi_select array). API docs ufficiali: developers.notion.com — versione API correntemente targata 2022-06-28 (la più stable). Use case: knowledge base auto-popolata dai workflow di customer support (ogni ticket Zendesk risolto → pagina sotto "/Customer Lessons" con summary AI e tags); log meeting Calendly → row nuovo nel database Meetings con date, partecipanti, link Zoom, action_items estratti dall'AI summarizer; dashboard sync da Postgres a database Notion che il management consulta giornalmente (replace Looker per metriche leggere); data collection da form Typeform → row in CRM Notion con tag auto da agent_email_triage_b2b per qualifica lead; documentazione PR auto-generata da GitHub merge events con link diff e breaking_changes notice.

Connettore enterprise per Salesforce — la piattaforma CRM mondiale leader (150k+ customer paganti, dominante nel B2B enterprise US/EMEA con il 23% di market share globale del CRM, base installata di sales+service+marketing+industrie cloud) via REST API ufficiale. Sei operazioni atomiche coprono il ciclo completo CRUD + SOQL: query (esegue una stringa SOQL Salesforce Object Query Language — il dialetto SQL-like proprietario di Salesforce con relationship traversal nested "SELECT Name, Owner.Email, (SELECT Subject FROM Tasks) FROM Account WHERE BillingCountry = 'Italy'"), create (insert nuovo record con field validation server-side), update (modify esistente by Id), upsert (cruciale per integration idempotente — match per external_id field designato, crea se assente, aggiorna se presente in una sola chiamata atomica = pattern di sync da sistema esterno verso Salesforce), delete (logical/physical), get (retrieve puntuale by Id con field selection). Auth via OAuth2 con refresh-token flow — il pattern enterprise standard per integration server-side: l'admin Salesforce crea una Connected App nella sezione Setup → App Manager con scope api+refresh_token, l'utente FlowForge completa il consent flow una sola volta nell'editor Settings → Integrations e il sistema salva il refresh_token nel vault del tenant. Il nodo ottiene access_token short-lived (15 min TTL Salesforce default) da cache local + refresh automatico sul 401/INVALID_SESSION_ID con 1 retry trasparente — l'utente non vede mai expire né deve fare manual re-auth. Multi-environment support: Salesforce ha sandbox (test environments isolati) e production (real environment); l'integration vault FlowForge supporta integrationLabel separati per pointing a instanceUrl diversi (sandbox: cs99.salesforce.com / production: ap25.salesforce.com / EU regional cluster: eu46.salesforce.com), prevenendo il classico incident "test contro production by mistake". Rate limit Salesforce: API limit aggregato per giorno è quota-based (15k req/giorno Developer Edition, 5M req/giorno Enterprise Edition) — il nodo monitora consumption via Sforce-Limit-Info response header e logga warning quando > 80% usage per consentire forecast prima del hard cap. API docs ufficiali: developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest (REST API v62.0+ Summer '24 release). Bulk API v2 non gestita da questo nodo (richiede async polling pattern — usabile via action_http custom). Use case: lead from web form Typeform → upsert Lead in Salesforce by email (External_Id__c) con LeadSource=Web e Status=Open-Not Contacted per il sales team italiano; opportunity update post-pagamento Stripe webhook → update Opportunity Stage='Closed Won' Amount={{order.total}} CloseDate={{today}}; contact sync bidirezionale da HubSpot CRM verso Salesforce per multi-CRM strategy (i marketing usano HubSpot, il sales team usa Salesforce — sync notturno via query → upsert); reporting SOQL custom per export forecast pipeline mensile in PDF tramite action_pdf_generate; integration con sistema gestionale italiano legacy che esporta ordini in CSV → bulk upsert come Custom_Order__c.

Wrapper enterprise high-level per il modulo integration_slack_post (Slack Web API chat.postMessage) che unifica i tre regimi di messaggistica sotto un'unica interfaccia coerente con il pattern community_* del dataset AI scaffold di FlowForge: invio di messaggi plain text con mrkdwn slack-flavored, invio rich con Block Kit JSON (lo standard Slack 2025 per layout interattivi con header section, divider, buttons, image blocks, fields, accessory elements come datepicker e multi_static_select), e reply in thread esistente via thread_ts per consolidare le conversazioni del flow nello stesso topic invece di spammare il canale. Auth via OAuth2 token bot delegato dal Slack workspace owner — il token viene risolto dal vault integration tramite integrationLabel (multi-token support: un singolo tenant FlowForge può gestire 10+ workspace Slack come MSP), MAI hardcoded nei workflow per security. Supporta target canali pubblici (#general), privati (privatamente joined dal bot), DM diretti tramite user ID U0123456 e canali multi-channel guest. Fallback notification: se il canale ha "Slow mode" attivo o il bot non è membro, il nodo restituisce un errore semantico esplicito invece di silently fail. Anti-flood: respect del Slack rate limit Tier 1-4 (60 RPM, 600 RPM, 1200 RPM, 6000 RPM in base al tipo di workspace Plus/Enterprise), con backoff esponenziale automatico su 429 retry-after. Output: { ok, channel, ts (timestamp Slack del messaggio = thread_id univoco per replies successivi), permalink, threadParent? }. Use case: notifica completamento workflow critico al canale #ops-alerts con block "🟢 Backup OK \n size: 4.2GB \n duration: 12min" e button "View dashboard" → click apre Grafana; daily standup automatico in #daily-standup alle 9:00 con riepilogo dei task chiusi ieri; notifica sales pipeline a #sales-room quando crm.lead Odoo passa a "Won" con valore expectedRevenue; alerting Sentinel WAF ban a #security con dettaglio IP/ASN/country/reason in section block formattato; pre-meeting reminder thread sotto un messaggio Calendly invece di creare noise nel canale.

Wrapper enterprise high-level per il modulo integration_telegram_send (Telegram Bot API ufficiale) che unifica i pattern di messaggistica più usati in workflow business sotto un'unica interfaccia coerente con il pattern community_* del dataset AI scaffold FlowForge. Telegram è la piattaforma di messaging con 900M+ MAU usata massivamente in Italia/Russia/Iran/Brasile per community real-time, alert ops/devops team, bot di customer service, channel broadcast verso audience grosse (broadcast unidirezionale al canale, nessun limite di destinatari come WhatsApp Business — è il use case principale del Telegram bot in contesto enterprise EU). Operations supportate via Bot API: invio di messaggio testuale (sendMessage), invio di foto (sendPhoto con file upload o URL remoto), invio di documento (sendDocument per PDF/XLS allegati), invio di location (sendLocation per geolocation point), invio di voice/audio (sendVoice). Supporto pieno per parse mode MarkdownV2 (l'incarnazione moderna di Telegram con escape stringente di tutti i caratteri speciali *_~`>#+-=|{}.!() per evitare 400 BadRequest, gestito automaticamente dal nodo) e HTML (subset sicuro <b><i><u><s><code><pre><a> più <span class="tg-spoiler"> per spoiler effect). Caption support per foto/video: testo descrittivo che appare sotto il media con stesso parse mode + formatting + emoji. Notifiche silenziose via disable_notification: il messaggio arriva nella chat ma NON triggera la notifica push del dispositivo destinatario, utile per low-priority updates che vuoi tracciare ma non disturbare l'utente di notte ("backup completato OK alle 03:00", "report generato"). Auth via Bot Token (formato 123456789:AAExxxxxxx) ottenuto da @BotFather di Telegram quando si crea il bot. Token stored nel vault integration FlowForge. Multi-bot supportato (un tenant FlowForge che orchestra 5 bot Telegram diversi via integrationLabel). Target chat_id: numerico univoco identificante una chat 1-to-1 con uno user, oppure un group, oppure un channel. Per chat 1-to-1 l'utente DEVE prima aver scritto al bot (limite anti-spam di Telegram, non possiamo iniziare la conversazione cold), per group/channel il bot DEVE essere stato aggiunto come member dall'admin. Rate limit Telegram Bot API: 30 messaggi al secondo per bot in totale, 1 messaggio al secondo per chat individuale, 20 messaggi al minuto per group (cap automatic gestito dal nodo con 429 + retry exponential). Use case: broadcast alert critici a canale ops/sre quando workflow di produzione falliscono o sentinel rileva attacco (formato MarkdownV2 con bot icon custom); notifica end-user su esito ordine e-commerce ("✅ Il tuo ordine #12345 è stato spedito con tracking GLS 9871234567"); invio quotidiano alle 08:00 di report metrico aziendale con foto chart embedded (generata da generateChart upstream) + caption con i top KPI del giorno precedente; notify silent al manager per low-priority updates senza il bip notifica che disturba durante una call ("processo notturno OK alle 02:30, no anomalie"); customer support bidirezionale dove il cliente scrive al bot e un workflow risponde con knowledge base AI suggested + fallback handoff umano via human_review_decision.

Wrapper enterprise high-level per il modulo integration_linear_create_issue (Linear GraphQL API createIssue mutation) che unifica il pattern community_* del dataset AI scaffold FlowForge per creare issue Linear. Linear è la piattaforma di project management built nell'industry per startup tech moderne che vogliono velocità e UX cura (cresciuta a 10k+ paying customer dal 2020, popolarissima tra YC company e dev team distribuiti), alternativa moderna a Jira/Asana con keyboard-first UX, cycle-based planning, auto-archive completate, integration nativa GitHub/Slack/Figma. Crea issue completi via GraphQL API ufficiale Linear con tutti i campi principali del project management standard: team key (identificatore univoco del team destinatario, es. "ENG" per engineering, "DSGN" per design, "SUP" per support — Linear richiede team scope obbligatorio), title (oneline summary chiaro e concreto < 100 char), description markdown rich (Linear supporta GFM markdown completo + Linear-specific extensions tipo /collapse per collapsible sections, @user mention con autocomplete, link a altri issue con sintassi LIN-123), priority (1-4: urgent/high/medium/low — UI Linear lo mostra con icone color-coded per quick triage del team), assignee by email (l'API Linear richiede assignee_id UUID, questo wrapper risolve automaticamente l'email del responsabile al user_id corretto via team membership lookup — pattern friendly per non-tecnici che conoscono email ma non UUID), labels (array di label names come "bug", "feature_request", "documentation", "p0_critical" — il nodo risolve gli ID label dal name string contro la knowledge base del team), state (backlog/todo/in_progress/done — il default è il workflow_state default del team configurato in Settings Linear). Auth via Personal API Key (formato lin_api_xxxxxxxx generato dall'admin in Settings → API → Personal API Keys) o OAuth2 per integration multi-user — stored nel vault integration FlowForge accessibile via integrationLabel. Rate limit: Linear non documenta hard limit ma il nodo usa 10 RPS sustained con backoff exponential su errori. Use case: creare bug Linear automatically da error tracker (webhook Sentry/Bugsnag/Datadog parsa l'evento di errore e crea issue ENG-XXX con stack trace in description + priority urgent se affecting > 100 users); opening ticket support automatic da agent_email_triage_b2b_sales che classifica una email cliente come "support_request" → crea issue SUP-XXX con full body email + customer email come metadata per il customer success team; backlog auto-generato da customer feedback form (typeform/trigger_form) dove la categoria del feedback ("feature_request", "bug_report", "ui_complaint") mappa a team Linear diverso; handoff workflow → engineering con assignee email-resolved del lead engineer del team corrispondente al modulo affected, evitando ping manuale.

Connettore canonico Slack via Web API ufficiale chat.postMessage — l'endpoint scaffold di tutta la famiglia Slack messaging del workflow stack, utilizzato dal wrapper community_slack che incapsula pattern community-friendly per il dataset AI scaffold. Posta un messaggio in un canale Slack del workspace autorizzato con supporto pieno alle tre features avanzate della piattaforma: (1) Plain text con emoji (sintassi shortcode :rocket: :heart: :tada: che Slack converte server-side in emoji visuali + supporto a custom emoji aziendali :it_team: caricate dall'admin del workspace), (2) Block Kit (lo standard Slack 2018+ per layout rich JSON-defined: header section per titoli grandi, section blocks con accessory (button, multi_static_select, datepicker, image), divider per separazione logica, image blocks con alt_text per accessibility, fields array a 2-colonne per metadata strutturati, context block per metadata small + author, actions row con multi-button per interactive payload back), (3) Thread reply via thread_ts (passa il ts del messaggio parent come thread_ts → la response appare come reply nel thread invece di nuovo messaggio standalone — fondamentale per consolidare conversazioni su un topic specifico ed evitare di spammare il canale principale con N messaggi disgiunti). Auth via OAuth Bot Token (formato xoxb-* generato durante l'install della Slack App nel workspace, con scopes minimum chat:write + chat:write.public + chat:write.customize per posting con username/icon custom). Token stored nel vault integration FlowForge accessibile da Settings → Integrations → Slack nell'editor tenant, mai hardcoded nel workflow per security. Channel resolution: il channel può essere passato come "#general" (humanReadable), "C0123456789" (ID channel univoco Slack — più robusto perché un canale rinominato preserva l'ID), oppure user ID U0123456789 per DM diretto al singolo membro. Il bot deve essere stato esplicitamente "added" al canale privato per posting (errore canonico not_in_channel se manca). Idempotency: Idempotency-Key generata automaticamente da runId:nodeId della run corrente del workflow → in caso di retry del nodo per network blip o crash recovery, Slack non duplica il messaggio (il pattern più importante per evitare il #1 incident customer support "il bot ha postato 5 volte lo stesso alert"). Rate limit Slack Tier 1 (default per Bot Token): 1 req/sec sustained con burst di 10/sec — il nodo rispetta header X-RateLimit-Remaining e usa Retry-After su 429 con jitter. Block Kit reference completo: api.slack.com/block-kit/building (l'admin Slack del workspace può sperimentare layouts via Block Kit Builder visual no-code). Use case: alert run workflow falliti nel canale #ops con block kit "🔴 Workflow {{name}} ha fallito" + context block "run_id: {{runId}} | error: {{error.message}}" + button "Open dashboard" che linka a ui_open_history; deploy report enterprise post-CI con embed completo (commit author, changes count, test results, deploy duration); daily digest delle 08:00 con riassunto KPI del giorno precedente generato da agent_business_summarizer e formattato in Block Kit ricco; AI agent reply automatic nel canale #support quando un customer scrive una domanda ricorrente (knowledge base match + AI completion restituita come messaggio thread).

Connettore canonico Telegram via Bot API ufficiale (sendMessage + sendPhoto) — l'endpoint primitivo su cui il wrapper community_telegram costruisce esperienza user-friendly per il dataset AI scaffold. Invia messaggi testo o foto in qualsiasi chat Telegram a cui il bot ha accesso (chat 1-to-1 con utente che ha già scritto al bot per primo, group dove il bot è stato aggiunto dall'admin, canale broadcast dove il bot ha permessi di posting). Telegram è la piattaforma di messaging cross-platform con 900M+ MAU particolarmente dominante in Italia, Russia, Iran, Brasile, India per community real-time e bot automation enterprise. Operations: sendMessage (messaggio testuale puro con length cap 4096 char, splitting automatico in più chunk se eccede), sendPhoto (foto inline con caption optional 1024 char, URL remoto o local path file — NO upload binario diretto in questo nodo per semplicità, l'upload di binary va via integration_http multipart custom). Parse modes: MarkdownV2 (the modern Telegram dialect 2017+, escape stringente di *_~`>#+-=|{}.!() per evitare 400 BadRequest — gestito automaticamente dal nodo che pre-escapa i caratteri pericolosi), HTML (subset sicuro <b>bold</b>, <i>italic</i>, <u>underline</u>, <s>strike</s>, <code>inline_code</code>, <pre>code_block</pre>, <a href="url">link</a>, <span class="tg-spoiler">spoiler</span>), Markdown legacy (per back-compat con sistemi antichi — sconsigliato in favore di MarkdownV2 più predictable). Auth via Bot Token (formato 123456789:AAExxxxxxxx ottenuto da @BotFather durante la creazione del bot) stored nel vault integration FlowForge. Multi-bot supportato (un tenant FlowForge che gestisce 5 bot Telegram diversi via integrationLabel — es. uno per ops alert, uno per customer service, uno per marketing broadcast). Resilienza: auto-retry su 429 (rate-limit Telegram con header Retry-After) con exponential backoff + jitter; auto-retry su 5xx upstream Telegram con 3 retry distribuiti; timeout configurabile (default 15s) per evitare workflow stuck su network slow. Disable notification flag: il messaggio arriva nella chat ma non triggera notification push sul dispositivo destinatario — pattern per low-priority notify che vuoi tracciare ma non disturbare. Reply_to_message_id per rispondere in thread a messaggio specifico. Use case: alert workflow runtime nei canali ops/sre con MarkdownV2 rich + emoji status indicators; bot reply automatico nel chat 1-to-1 con utente che ha scritto al bot (echo, knowledge base lookup, AI completion via action_llm_complete + send risposta); notifica utente end-customer al completamento di un processo asincrono ("✅ Il tuo file è stato processato, scarica qui {{download_url}}"); push monitoraggio metriche infrastructure con foto chart generata da generateChart upstream + caption con percentuali KPI; broadcast in canale community Telegram quando blog post pubblicato sul sito (sync via webhook CMS); reminder appuntamento Calendly 24h prima con counter countdown formatato.

Connettore canonico Linear via GraphQL API ufficiale (issueCreate mutation) — l'endpoint primitivo su cui il wrapper community_linear costruisce esperienza user-friendly per il dataset AI scaffold. Linear è la piattaforma di project management modern preferita dai dev team distribuiti tech (10k+ paying customer dal 2020) per la sua UX keyboard-first ultra-veloce, cycle-based planning sostitutivo dello scrum classico, integration nativa GitHub/Slack/Figma/Sentry — alternativa moderna a Jira/Asana. Crea issue completi con tutti i field di project management canonici: title (oneline summary < 100 char), description markdown rich (GFM completo + Linear-specific extensions tipo /collapse, @user mention con autocomplete user del team, link a issue esistenti con LIN-123 sintassi auto-renderizzata), team (target del team destinatario passato come team_key string tipo "ENG"/"DSGN"/"SUP" — l'API richiede team_id UUID, il nodo risolve automaticamente da key + cache 60s per i workflow burst), assignee (passato come email che il nodo risolve a user_id via team membership lookup — pattern friendly per workflow che lavorano con email naturali invece di UUID opaque), priority (numerico 0-4 dove 0=no priority, 1=urgent, 2=high, 3=medium, 4=low — UI Linear mostra con icona color-coded per quick visual triage), labels (array di label names "bug", "feature_request", "p0_critical" — risoluzione name → label_id automatica), state iniziale (Triage default per nuove issue non-prioritizzate, Todo per pronte da iniziare, In Progress per pre-assegnate, Done per import storici), parent_issue_id opzionale per creare sub-task agganciate a una issue padre (utile per breakdown di epic). Auth via Personal API Key (formato lin_api_xxxxxxxx generato dall'admin in Settings → API → Personal API Keys con scope organization-wide oppure OAuth2 per integration multi-utente) stored nel vault. Resilienza: auto-retry su 5xx upstream con exponential backoff + jitter (3 retry max), retry su 429 rate-limit con Retry-After header (Linear non documenta hard limit ufficiale, ma raccomandiamo < 10 RPS sustained), GraphQL error parsing semantico (l'errore non viene in HTTP status ma nel body JSON errors[] del GraphQL — il nodo li parsa e ritorna a workflow downstream errore tipizzato). Use case: bug-report automatic da workflow error handler global del tenant (catch errors → create issue in Linear team ENG con stack trace + run_id link al run viewer dashboard FlowForge); lead high-priority da form HubSpot/Typeform → ticket Linear nel team SUP con priority basata sulla company size; auto-creation di follow-up task dopo customer reply su Zendesk (webhook → action_email_triage → branch "needs_followup" → integration_linear_create_issue per task all'AE responsabile); sync da error tracker Sentry/Bugsnag con issue Linear automatic dedup per fingerprint hash; engineering handoff da workflow di review compliance al team product per implementare nuovi requisiti normativi.

Operatore di branching binario condizionale enterprise — il control flow primitive di qualsiasi pipeline che ha bisogno di prendere una decisione "questo va a sinistra, quest'altro a destra" e che corrisponde concettualmente all'if-else dei linguaggi di programmazione classici. Valuta una condizione e instrada il workflow lungo il ramo "true" (yes) oppure il ramo "false" (no) — l'engine FlowForge esegue SOLO il ramo scelto (vedere chosenBranch + workflow-engine strategy logic-if), evitando fan-out su entrambi e sprecando risorse + side effects indesiderati. Due modalità di definizione della condizione mutuamente esclusive per coprire spettro complete dei case: (1) Builder visuale multi-regola — l'interfaccia no-code per non-developer commercialisti/marketing/amministrativi: aggiungi una o più regole composabili con combinatori AND/OR (logical operator scelto top-level), ogni regola consiste di un field path (dot-notation come "$node.triage.json.label"), un operatore type-aware (per stringhe: equals, not_equals, contains, starts_with, ends_with, matches_regex, is_empty; per numeri: greater_than, less_than, between, greater_than_or_equal; per array/collezioni: in, not_in, contains_any, contains_all, size_equals; per booleani: is_true, is_false; universal: exists, not_exists per null/undefined check), e un valore di confronto (può essere literal o expression {{$node.config.threshold}} valutata runtime); (2) Espressione JavaScript libera — back-compat con l'engine v1 e fallback per condizioni veramente complesse non esprimibili nel builder (es. "input.amount > input.user.tier_limit && Date.parse(input.due) < Date.now()") — l'expression viene valutata in sandbox VM2 con accesso a $node, $input, $vars + helpers tipo $date, $string. Use case canonici: routing email triagata (è un ordine cliente? → ramo Salesforce updateOrder, altrimenti → ramo notifications agli operatori); gate su soglia di confidence di un classifier ML (confidence > 0.8 → ramo auto-processed, altrimenti → ramo human_review); permission check pre-action (user.role === 'admin' → ramo dangerous_action allowed, altrimenti → ramo deny + audit log); A/B routing utenti su feature flag (user.experiment_cohort === 'B' → ramo new_experience, altrimenti → ramo control); validazione amount per workflow finanziari (amount > 10000 → ramo approval_workflow CFO, altrimenti → ramo auto_approve immediato).

Operatore di branching N-way enterprise — l'equivalent del switch/case dei linguaggi di programmazione classici (Java, C#, JavaScript, Python match) applicato al workflow orchestration. Mentre logic_if è binario (true/false), logic_switch instrada il flusso su uno tra molti rami in base al valore di un'espressione discriminante — pattern fondamentale per routing a dispatcher basato su tipo di evento, categoria, status, regione, customer tier, e centinaia di altri campi categorical che richiedono "se è A vai qui, se è B vai là, se è C ancora altrove, altrimenti gestisci come default". Ogni "case" è una porta di output dedicata del nodo nel grafo del workflow editor, etichettata con il valore matched (es. "order_confirmed", "refund_requested", "subscription_cancelled") — l'utente collega visualmente ogni porta a una catena di azioni diversa, e l'engine FlowForge esegue SOLO il ramo scelto in base alla chosenBranch decision (vedere workflow-engine strategy logic-switch) evitando fan-out su tutti i rami e sprecando risorse + side effects indesiderati. Modalità di matching per case: (1) Literal match (default) — comparison esatto value === case_value (con type coercion intelligente: "42" matcha 42 number, "true" matcha boolean true) — il pattern più semplice e più comune che copre 90% degli use case enum-like; (2) Condition-rules sidecar — per case con logica complessa che NON è esprimibile come singolo literal (es. "matcha questo case se amount > 1000 AND country in ['IT', 'ES']"), ogni case può avere un condition-rules array opzionale che fa override del literal match con AND/OR builder visuale identico a logic_if — pattern hybrid per ottenere il visual N-way switch con la potenza condizionale del if. Ramo di fallback "default" obbligatorio attivabile: quando nessun case matcha, il flusso prosegue sull'output "default" — pattern safety per non lasciare workflow stuck su input inatteso (es. nuovo tipo di evento aggiunto upstream che il nostro switch non conosce ancora — vogliamo gestirlo gracefully con log + escalation invece di crash silenzioso). Il flag strictMode può rendere obbligatorio match (throw error se nessun case + no default) — pattern per workflow critici dove un fallthrough è bug. Use case: routing per tipo evento webhook (Stripe webhook può avere 50+ type — order.created → ramo fulfillment, charge.refunded → ramo customer success, subscription.deleted → ramo retention, ecc.); classificazione status di un ordine (pending → ramo "in attesa pagamento email cliente", paid → ramo "trigger fulfillment", failed → ramo "alert ops e retry pagamento", refunded → ramo "audit + recupero merce"); multi-tenant routing per workflow super-admin che processa eventi da N tenant diversi e li instrada al subprocess giusto del tenant target; routing per language (it → email italiano, en → inglese, de → tedesco, ecc. per workflow internazionali); dispatching per region geografica con SLA differenziati per cluster di server (EU → ramo Frankfurt, US → ramo Virginia, APAC → ramo Singapore).

Operatore di iterazione enterprise — il workhorse di tutte le pipeline batch del workflow business. Itera una collezione (array di oggetti, object con key=>value, string split per character/word/line) attraverso il ramo "body" del workflow editor, applicando per ogni item la stessa sequenza di azioni configurate downstream. Equivalente concettuale del `for-each` dei linguaggi di programmazione classici ma con cinque strategie di esecuzione configurabili per coprire spettro completo dei use case da 10 item a 10M item: (1) naive — 1-at-a-time sequenziale, semplice e prevedibile, default per dataset < 100 item dove la latency totale del workflow non è blocker e ogni step può essere debugged singolarmente; (2) batch — chunk di N item alla volta (es. 50 per batch), pattern bilanciato per dataset 1k-10k item dove il throughput è importante ma vogliamo ancora controllo granular dei chunks per error handling; (3) bulk — UNA singola call downstream con l'array intero come input, pattern critico quando il nodo downstream supporta operazioni bulk (es. action_email_send_tracked_batch, db_insert bulk) — riduce overhead di N invocazioni separate; (4) queue — processing asincrono via BullMQ-style job queue Redis (Dragonfly), pattern obbligatorio per dataset > 10k item dove il singolo workflow run sarebbe troppo lungo — il loop ritorna immediatamente lasciando worker async processare le job in background; (5) aggregate — modalità riduzione senza body (no iteration steps), equivalente a passare l'array a logic_aggregate downstream senza per-item processing; (6) auto — l'engine FlowForge sceglie automaticamente la strategy migliore basata su array size + downstream node capabilities introspection. Scope expression per ogni iteration espone variabili context al body: {{loop.item}} (l'item corrente dell'iterazione), {{loop.index}} (0-based position), {{loop.total}} (size della collezione), {{loop.first}} (boolean true per il primo item, utile per email header decoration "Ciao {{name}}!" solo la prima volta), {{loop.last}} (boolean true per l'ultimo, per email footer "fine elenco"), {{loop.percentage}} (per progress reporting). Branch outputs del nodo per error handling: "done" (success aggregato — tutti gli iter completati senza error), "error" (almeno 1 iteration ha fallito — il caller può vedere quali in failedItems). Cap configurable maxIterations (default 10000) per safety anti-runaway. Use case: process batch ordini Stripe webhook ricevuti via paginate → loop con strategy=batch per gestire 500 ordini in batch 50; parse righe CSV/Excel uploaded → loop su rows dell'output xlsx_parse con strategy=naive per debug step-by-step; enrich N lead CRM con dati esterni via action_company_search + action_lead_score (strategy=batch 10 per gestire rate-limit upstream); multi-recipient email con personalization per ogni destinatario; bulk insert in DB di analytics events con strategy=bulk per one-shot db_insert atomic.

Operatore di fan-in/join enterprise che combina gli output di N nodi paralleli upstream in un singolo output strutturato — la primitiva fondamentale di tutte le architetture fan-out + fan-in del workflow orchestration moderno (Airflow XCom, Temporal Workflow, AWS Step Functions Parallel). Quando hai 3-10 rami che girano in parallelo per ottimizzare il tempo totale dell'esecuzione (es. 3 search API simultanei invece di sequenziali = 3× speedup), prima del passo successivo devi necessariamente unire i risultati in una struttura unica processabile — questo nodo lo fa con strategia configurabile per i 4 pattern di merge più comuni nei workflow business. Strategia "all" — mappa output di ogni branch alla sua nodeId di provenienza: { "search_google": [...], "search_bing": [...], "search_duckduckgo": [...] } — il pattern più strutturato che preserva origin per debug e attribuzione. Strategia "concat-arrays" — assume che ogni branch ritorni un array (o sub-property di un object configurable), concatena tutti gli array in uno solo: utile quando il valore semantico è "tutti i risultati uniti senza importare da quale fonte vengono". Strategia "any/first" — aspetta solo il PRIMO branch a completare e usa quel risultato, abortendo gli altri (pattern racing fallback: chiama 3 API concorrenti, prendi quella più veloce, killa le altre per risparmiare quota). Strategia "last" — aspetta tutti i branch ma usa solo l'output dell'ULTIMO completato (utile per override pattern: il branch lento è quello più autorevole, gli altri pre-warm la cache). Sourcing dei branch: auto-discover dei nodi upstream (auto-detection dei direct predecessors nel grafo del workflow — pattern dichiarativo) oppure lista CSV esplicita di nodeId (pattern imperativo per workflow complessi dove l'auto-discover ambigua è da evitare). Validation: se uno dei branch dichiarati non è eseguito (es. condizionale skipato da logic_switch), il merge gestisce gracefully con strategy "all" (missing entry → null) oppure "concat-arrays" (skip silente). Output: { merged (l'output combinato secondo la strategia), strategy, branchesContributed, totalDurationMs, slowestBranch?, fastestBranch? }. Use case ricchi della pipeline business: 3 web search paralleli (Google + Bing + DuckDuckGo) → 60 risultati uniti per dedup downstream + lead scoring; multi-API enrichment di un lead B2B (lookup CRM Odoo + social media LinkedIn + geo location da IP) in parallelo → object enriched complete per il sales team; ensemble AI agent voting su task di classificazione difficile (3 LLM provider diversi votano la stessa label, majority vote dello strategia "all" con post-processing); aggregazione status monitoring (uptime check su 5 endpoint concurrent) in unica dashboard view; fan-out su multi-channel notification (Slack + Telegram + Email + WhatsApp) con merge per audit di delivery status complessivo.

Operatore di pausa controllata enterprise — sospende l'esecuzione del workflow per una durata configurabile in millisecondi senza occupare risorse CPU/RAM con un setTimeout naïve. Il run state completo viene serializzato in checkpoint persistente (workflow_runs.checkpoint_json del SQLite runtime tenant) e il workflow va in stato `paused` fino allo scadere del delay; al wake-up un job scheduler interno (Bull-like queue con priority + delayedJobs) re-idrata lo state e riprende esattamente dallo step successivo come se il tempo non fosse passato — pattern resumable critico per workflow di durata 1+ ora che altrimenti morirebbero al primo restart container per deploy o crash, con perdita di tutto il processing già fatto. Cap di sicurezza: 24h per delay singolo (oltre, considera trigger_cron esterno che lancia il second-stage del workflow — più resiliente e più visibile in audit). Il run paused continua a contare nelle quote workflow_running ma non consuma CPU. Use case: rate-limit manuale tra chiamate API esterne quando l'upstream NON espone header Retry-After standard (es. legacy SOAP web service con cap 5 req/min hardcoded — delay 12s tra chiamate consecutive); wait deterministico per propagazione DNS dopo create record (es. 30s per A record DNS reload via Cloudflare) o propagazione cache CDN dopo invalidation; pacing su workflow batch outbound (es. spedire 1 email al secondo per stare sotto le soglie reputation Gmail/SES); debounce su rapid trigger consecutivi (es. webhook che parte 3 volte in 2s da retry upstream — il primo workflow fa delay 5s e POI verifica se è il più recente run aggiornato, altrimenti skip — pattern "wait for quiet"); pause intenzionale prima di azione costosa per dare tempo all'operatore umano di intervenire (es. delay 60s prima di cancellare 500 record da database con notify Telegram per cancel manuale se errore).

Operatore enterprise di composizione workflow-as-function — il pattern fondamentale di modularizzazione che permette di chiamare un altro workflow del tenant come fosse uno step del workflow corrente, l'equivalente di una funzione nella programmazione classica. Invoca un sub-workflow target (identificato via workflowId selezionato dal picker della UI editor) passando l'output dello step upstream come input al sub, ed il return value del sub-workflow diventa l'output del nodo logic_subworkflow nel parent — pattern transparent che permette di astrarre logica condivisa in un mini-workflow riusabile in N posti. Esecuzione sincrona di default (await fino al completamento del sub) — il workflow parent blocca su questo step finché il sub non ritorna (anche se gira per ore per task long-running come ETL nightly). Opzione asincrona fire-and-forget configurable: lancia il sub e prosegue immediatamente con runId del sub come output — pattern per orchestrazione di N children parallel senza dover aspettarli tutti (es. master workflow che lancia 50 children "process customer" in parallelo e prosegue alla aggregation step dopo che tutti hanno emit signal completed). Anti-loop guard enterprise multi-livello: self-recursion detection (workflow A che chiama A → block immediato con errore semantico esplicito "self-recursion detected"), depth-cap configurable via env FLOWFORGE_MAX_SUBWORKFLOW_DEPTH (default 10 — il valore comfortable per il pattern enterprise di nesting ragionevole; oltre serve override esplicito operatore per evitare resource exhaustion); propagation della depth via X-Subworkflow-Depth header tra parent→child HTTP run dispatch — l'engine incrementa di +1 ad ogni nested call e block se cap raggiunto, prevenendo recursion-bomb attack o workflow malformati con cycle indiretto. Tenant isolation: il sub-workflow DEVE appartenere allo stesso tenant del parent (non possiamo chiamare workflow di altri tenant — multi-tenant security boundary), enforce a livello del runtime via tenantId check. Use case classici di modularizzazione: estrarre logica condivisa "send-notification-email" usata da 20 workflow diversi del tenant — invece di copy-paste della sequence Sentinel + audit + render + send in ognuno, creo un sub "notification" riusato in tutti; orchestrare workflow gerarchici master → children (es. master nightly batch che lancia 10 children paralleli per ognuno dei tenant del SaaS managed); modularizzare workflow grossi in mini-workflow indipendenti (un workflow "onboarding cliente" decomposto in 5 sub: validate_form, create_user, provision_resources, send_welcome_email, schedule_followup_call — ciascuno testabile e maintainable separatamente); pattern Strategy programmation con sub-workflow configurati dinamicamente in base al tipo di evento upstream (logic_switch → 5 logic_subworkflow diversi per 5 type di evento gestiti); DRY refactoring di workflow legacy con duplicazione enorme di logica in un canonical sub.

Convertitore universale enterprise tra i tre formati di interscambio dati più comuni nei workflow business: JSON (la lingua franca delle API REST moderne e dei database NoSQL), CSV (lo standard de-facto per Excel/Google Sheets/SAP/SAGE/gestionali italiani e per l'export verso commercialisti e analisti che non programmano), plain text (semplice testo unstructured con delimitatori configurabili — utile per feed legacy a sistemi mainframe o flat-file processing). Conversioni bidirezionali complete (6 paths: JSON→CSV, JSON→text, CSV→JSON, CSV→text, text→JSON, text→CSV) con preservation dei tipi quando possibile (numeri stringa "42" diventano numeric 42 in JSON, date ISO 8601 restano stringa per safety, boolean gestiti come "true"/"false" in CSV). XML e YAML pianificati per v2 (richiedono parser xmldom + js-yaml). CSV: auto-detect del delimiter (analizza la prima riga e conta occorrenze di virgola, punto-e-virgola che è lo standard CSV italiano per locale che usa virgola come decimal separator, tab per TSV), header row opzionale (primo riga come field names o disabilitato), escape RFC 4180 di virgolette doppie nei valori, gestione di newline LF/CRLF coerente all'OS target di esportazione, encoding UTF-8 con BOM opzionale per compatibilità Excel 2016 italiano (senza BOM, Excel apre il CSV con encoding sistema → caratteri accentati rotti). JSON: pretty-print opzionale (indent 2 per debug + git diff leggibili / minified per network transmission), parsing strict (rifiuta JSON5 con commenti per safety), depth-limit a 32 per protezione stack overflow su input maliziosi profondi. Output: { data (string risultato), format (formato dichiarato), sizeBytes (utile per quota stats), sourceRowCount?, sourceColumnCount? }. Use case: trasformare risposta paginata JSON da API REST in CSV scaricabile dal cliente nella dashboard tenant (export "tutti i miei ordini ultimi 90gg"); normalizzare upload CSV di anagrafica clienti da commercialista in JSON per ingest in res.partner Odoo via action_odoo_rpc; export logs strutturati JSON da audit_log in CSV per analytics in Excel/Google Sheets del CFO; conversione legacy COBOL fixed-width text in JSON per ingest in stream di workflow modern; data interchange tra B2B partner che parlano CSV (il partner) e modern internal APIs (JSON).

Operatore enterprise di sospensione del workflow flessibile che combina i pattern timer-based (delay temporizzato) e signal-based (wait-for-webhook-callback) in un'unica primitiva configurable. Sospende l'esecuzione fino a uno dei tre scenari: timer scaduto (mode=timer, configurazione durationMs identica a logic_delay), arrivo di una callback HTTP esterna (mode=webhook, configurazione signalName + authToken, identico semantically a logic_wait_signal), oppure la combinazione "either" early-exit (mode=either — riprende al PRIMO dei due eventi che accade, pattern hybrid timeout + signal critical per use case real-world dove "se l'utente non conferma entro 24h prendiamo decisione automatica"). Il workflow è completamente suspended durante l'attesa: zero consumo CPU/RAM, lo state è persistito in checkpoint del SQLite runtime, sopravvive a restart container per deploy o crash, scheduler centrale del portal riprende il workflow quando il timer scade o il webhook arriva. Cap di sicurezza configurable maxTimeoutMs default 30 giorni — pattern di safety per evitare workflow zombie che restano paused per sempre per signal mai arrivato. Mode timer — simple, deterministic, prevedibile: durationMs (range 1ms-30giorni), resume al expire esatto, output con ms effettivi attesi (può differire micro-secondi da nominal per scheduler precision); Mode webhook — signal_name come endpoint POST /signals/<name> con auth_token validation, payload JSON del POST disponibile nel resume output; Mode either — early-exit racing: timer + webhook armati simultanei, primo che firma fa resume + log di chi ha vinto, pattern critico per "approval con timeout business default" (esempio canonico: wait_for_approval_or_24h). Output al resume: { resumedBy ("timer" | "webhook"), durationMs effettivo, signalPayload? (se webhook), timeoutReached (bool se timer ha vinto in mode either) }. Use case: aspettare conferma utente prima di proseguire (mode=webhook → invia link conferma + aspetta click), pausa anti-rate-limit prima di chiamata API successiva (mode=timer 1s tra 100 chiamate batch), wait per propagazione DNS/cache CDN (mode=timer 30s prima di check post-invalidate), attesa di esecuzione async esterna con callback notify (mode=webhook per "il processing OCR di Vision Extract è completed e invia signal"), pattern approval con default (mode=either con webhook + 24h timer per "se il manager non risponde entro 24h auto-approva" in workflow finance enterprise).

Operatore enterprise di trasformazione JSON dichiarativo basato su JSONata — il Domain-Specific Language standard IETF 2015 specializzato in trasformazione di documenti JSON arbitrari, alternativa più potente e leggibile a JSON Path/JMESPath/jq adottata da molte enterprise (IBM API Connect, Camel Quarkus, Logic App di Azure usano JSONata o varianti) per le sue capability di functional composable transformation in singolo espressione one-liner che equivarrebbero a 30+ righe di JavaScript imperativo. JSONata combina selectors XPath-like ($.users[role=admin].email), funzioni higher-order built-in (map, filter, reduce, sort, groupBy, distinct, sum, count, count, avg), template literal con string interpolation (\'Hello \\(name)\'), date arithmetic ($millis() - $toMillis(created_at)), conditional ternario potente (price > 100 ? "expensive" : "cheap"), object construction con projection ({"name": full_name, "totalSpent": $sum(orders.total)}), nested traversal con preservation di context (parent.{child.{name, count(child.items)}}). Pattern d'uso enterprise tipico: ristrutturare il JSON di response di un'API esterna nel formato atteso dal nodo downstream, evitando di scrivere logic_run_js custom che sarebbe più verbose + meno auditable. Sandboxed enterprise execution: l'engine JSONata è isolato via timeout 5s configurable (kill automatic di espressioni infinite con while loop accidentali — molto comune in espressioni recursive complicate scritte male) + max depth recursion cap 100 (per protection da stack overflow su expression maligna), pure function semantics (no side effect: no fetch HTTP, no fs access, no process.exit reachable), output sempre JSON-serializable. Documentazione e playground ufficiale completi a https://jsonata.org dove l'utente può sperimentare expression complesse con preview live prima di paste nel nodo FlowForge. Cheatsheet quick reference: $count(items) per conta, items[price>100].name per filter+select, $sum(orders.total) per aggregate sum, $reduce(nums, function($a,$b){$a+$b}) per custom reducer, $groupBy(orders, "customer_id") per gruppi, $sort(items, function($x,$y){$x.price < $y.price}) per ordering custom, items{$.category: $count($)} per object construction con dynamic keys. Use case: pulire payload di un webhook removendo campi inutili che inquinerebbero il context downstream (es. metadata, debug_info, internal_id); unificare formati eterogenei di provider diversi in una struttura comune (Stripe webhook + PayPal webhook + bonifico bancario → schema canonical { amount, currency, customer_email, payment_method, paid_at }); aggregare array con filter+map+reduce in singola expression chained vs N nodi logic_loop + logic_aggregate; rename di campi (snake_case da REST API legacy → camelCase per ingest in DB del cliente che usa camelCase convention).

Iteratore enterprise per REST API paginate che gestisce automaticamente la complessità del looping attraverso N pagine fino al recupero completo del dataset, aggregando tutti i risultati in un singolo array unificato. Le REST API moderne implementano almeno 4 schemi di paginazione mutuamente incompatibili (causa di frustrazione storica per chi le integra a mano): (1) cursor-based — la più moderna e scalabile, usata da Shopify, Stripe, GitHub v4 GraphQL — la response contiene un opaque cursor "abc123" che va passato come query string `?cursor=abc123` nella next request, fino a quando il cursor è null/missing; (2) page-number — il più semplice e usato da CMS WordPress, Magento, e legacy enterprise — la response porta total_pages oppure has_more, e si itera `?page=1`, `?page=2`, ..., `?page=N`; (3) offset-limit — il classico SQL OFFSET/LIMIT esposto come `?offset=0&limit=50`, `?offset=50&limit=50`, semplice ma inefficace su dataset grossi (offset 100k è O(N) sul server); (4) link-header — il pattern RFC 5988 usato da GitHub v3 REST e altri — la response header `Link: <url>; rel="next"` punta esplicitamente al next URL senza dover costruirlo manualmente. Strategia di iteration: auto-detect intelligente — il nodo guarda lo shape della response e gli header per identificare quale dei 4 pattern è in uso (default in 80% dei casi reali), oppure override manuale esplicito per le API non-standard custom. Path JSON configurable per dove trovare gli items nell'envelope response (default "data" o "items", configurable "results.records" per API nested). Safety cap obbligatorio: max pagine totali (default 1000 — anti-runaway su API mal-configurate che never-terminating ritornano sempre "ci sono altre pagine"), max items totali (default 50k — protezione memoria del processo runtime tenant), max durata totale (default 5min — anti-stuck workflow). Rate limit aware: rispetta header Retry-After 429, throttle naturale 10 req/s default per non saturare le API upstream. Output: { items (array unificato di TUTTI i record), pages (numero pagine effettivamente scaricate), totalCount? (se l'API espone X-Total-Count), durationMs, finalCursor?, truncated (true se cap raggiunto — il caller sa che mancano dati), requestsCount }. Use case: scarica TUTTI gli ordini Shopify delle ultime 24h via cursor-based pagination con filtro updated_at_min (3000+ ordini su un sabato sera black friday → 60 pagine × 50 record → 4-6 minuti); tutti i contatti HubSpot del workspace (offset 100k+ record di customer database B2B per esportazione mensile); tutta la lista commenti GitHub di un repository per analytics community engagement (link-header); bulk export CRM Pipedrive senza scrivere il loop manuale a mano col rischio di off-by-one o cursor-stuck-in-loop; sync incremental Notion database dove vogliamo tutti i record cambiati dall'ultimo cursor salvato in memory_note.

Operatore di raggruppamento enterprise stile SQL GROUP BY ma applicato in-memory a un array di oggetti JavaScript proveniente da uno step upstream del workflow — fondamento di tutte le pipeline di analytics, reporting, batch processing che lavorano su dataset rappresentati come array di records (output di action_db_query, action_csv_parse, listCommits, queryDatabase Notion, ecc.). Accetta un'espressione di path/key per identificare il campo di raggruppamento — supporto nativo per path nested con notazione dot/bracket JavaScript-style: "user.country" (group per country del nested user), "customer.address[0].city" (primo indirizzo del cliente), espressioni Liquid/Handlebars-like {{order.metadata.region}} valutate dall'expression engine FlowForge. Handling robusto dei valori mancanti: null e undefined finiscono in un gruppo speciale chiamato "_other_" invece di essere silenziosamente droppati (questo evita il bug subtile di dataset analytics che sembrano completi ma hanno il 30% di record orfani non contati); empty string "" è gruppo separato da null per preservare la semantica del dato originale; per chiavi numeriche float, normalizza la rappresentazione a stringa con sprintf "%.4f" per evitare grouping disperso 1.0 vs 1.00 vs 1. Output con doppia structure utile downstream: { groups: { [valore_chiave_stringificato]: [item1, item2, ...] }, counts: { [key]: N }, totalGroups, totalItems, largestGroup, smallestGroup }. Use case classici della pipeline business: raggruppare 200 ordini in pipeline per cliente prima di emettere fatture mensili consolidate via action_pdf_generate (1 fattura per cliente invece di 200 singole); aggregare 100k righe di audit_log per ora/giorno per popolare dashboard analytics tenant; raggruppare 5000 lead CRM per source ("google_ads", "linkedin_organic", "referral_partner") per il report ROI per source del marketing manager; raggruppare email triage per categoria per generare metriche di customer support per il monthly business review; pre-processing prima di logic_aggregate (group + sum/avg/min/max/count) — la coppia group_by → aggregate è il workhorse delle pipeline ETL leggere senza dover scendere a SQL diretto.

Operatore enterprise di aggregazione (reducer) che collassa un array di N oggetti in un singolo valore aggregato secondo una funzione di reduce configurabile — l'equivalent della funzione SQL aggregate (SUM, COUNT, AVG, MIN, MAX, GROUP_CONCAT) applicato in-memory ai workflow business. Sette funzioni di aggregazione coprono il 95% dei use case business analytics e reporting: (1) sum — somma totale dei valori numerici di un campo (es. expectedRevenue di crm.lead per il forecast di pipeline del mese), (2) count — conteggio degli item (con filtro opzionale "count where status=open"), (3) avg — media aritmetica con gestione precision (default 2 decimal places), (4) min/max — estremi del dataset (utile per trovare l'ordine più alto/basso, la fattura più recente/vecchia), (5) concat — concatenazione di stringhe con separator configurabile (es. concat di tutti i nomi cliente del segmento separati da virgola per email digest), (6) collect — raccolta in array di tutti i valori di un campo (es. tutti gli email del segmento per bulk send), (7) median — mediana statistica più robusta dell'avg in presenza di outlier che distorcono la media. Group-by opzionale potentissimo: oltre all'aggregazione globale sull'intero array, è possibile aggregare PER GRUPPO sulla base di un campo discriminante (es. somma amount per customer_id, count orders per region, avg sentiment per source) — l'output diventa una Map { group_key: aggregatedValue, ... } che è pronta per essere serializzata come tabella di summary report nell'email cliente o nel PDF mensile del controlling. Pattern composto group_by + aggregate è il workhorse delle pipeline ETL leggere che evitano di dover scrivere SQL diretto al database. Gestione robusta dei valori non-numeric: per sum/avg/min/max, gli item con valore null/undefined/stringa-non-parsabile vengono skipati (non droppano il workflow) e tracciati in skippedNonNumeric output — pattern fail-safe vs naïve Math.sum() che esploderebbe su NaN. Type coercion intelligente: stringhe numerich "42.5" → 42.5, stringhe formato italiano "1.234,56" → 1234.56 (gestisce locale italiano con virgola decimale), boolean true/false → 1/0 per sum semantico. Output: { value (single value per aggregazione globale, o Map per group-by), inputCount (size array di partenza), processedCount (effettivamente aggregati dopo skip non-numeric), skippedNonNumeric (count item skipati con motivazione esplicita) }. Use case: KPI dashboard del business (somma fatturato giorno-corrente, count ordini settimanali, avg order value, max ordine del mese) tramite trigger_cron daily + db_query + aggregate; rollup analytics multi-tenant per super_admin che vede aggregato dei KPI per workspace_id; calcoli statistici post-query DB pre-visualizzazione (es. compute della percentile 95th senza dover writing SQL window functions); aggregare result di una loop iteration prima del send-email summary (loop processa 100 ordini → aggregate dei flag success/failed → email digest "85 successful, 15 failed, total amount €12.5k").

Operatore di deduplicazione enterprise che rimuove voci duplicate da un array di oggetti — la primitiva fondamentale di tutte le pipeline ETL e analytics dove si aggregano dati da fonti multiple (webhook retry, scraping multi-pagina, merge CRM+marketing+social, ingest legacy CSV) e ci si trova inevitabilmente con record fantasma duplicati che inquinano analytics, popolano email a stesso cliente più volte, generano notifiche multiple del stesso evento, gonfiano i counter di KPI. Due modalità complementari per coprire tutti i pattern di equality semantic: (1) Mode senza key (deep equality structural) — compara l'intero oggetto serializzato come JSON canonical-form (ordering deterministico dei field per evitare false positive su { name: "A", city: "X" } vs { city: "X", name: "A" } che son lo stesso oggetto), match esatto bit-perfect tra item considerati duplicati, drop dei subsequent occurrences preservando il PRIMO inserito (preserve order originale array che è semantica naturale per LRU-like behavior); (2) Mode con key field — l'utente specifica uno o più campi (es. ["email"], oppure ["vat", "country"] per dedup composta), item con stesso valore (concatenato per multi-key) restano solo il primo, gli altri vengono droppati anche se diversi in altri campi (use case: dedup per email_address di un merge di N sorgenti CRM dove la stessa persona compare con nomi formattati diversamente — "Mario Rossi" vs "M. Rossi" vs "MARIO ROSSI" tutti via email [email protected] → tieni solo il primo, scarta gli altri 2). Performance: l'algoritmo usa Set/Map per O(N) lookup invece di O(N²) naïve double-loop — gestisce array di 100k+ item senza saturare CPU del runtime tenant. Strategia hash-based su valori chiave stringificati con normalizzazione (lowercase + trim opzionale per email pattern). Output: { items (array dedupped preservando order originale), originalCount, deduplicatedCount, duplicatesRemoved, removalPercent, exampleDuplicates? (sample 3-5 esempi di duplicati rimossi per debug + audit) }. Use case operativi: dedup lista email/contatti dopo merge di N sorgenti CRM (Pipedrive imported + Mailchimp + Odoo res.partner) prima di un mass-mailing per evitare di spedire 3× allo stesso indirizzo (GDPR fastidio + reputation IP); unique URL da scraping multi-pagina/multi-spider perché lo stesso URL può comparire come link in 10 pagine diverse del sito ma vogliamo crawlarlo solo 1×; rimuovere ordini duplicati ricevuti via webhook retry (Stripe/PayPal con at-least-once delivery garantita riprovano webhook fino a 3-7 volte in caso di timeout — gestione idempotency); normalize result list pre-loop per evitare lavorazione doppia di stesso item in logic_loop body (es. per fiscal_code dei clienti ricevuti da PEC, per messageId Slack già processati, per event_id audit_log per ingest analytics warehouse).

Aggregatore time-series enterprise che raggruppa elementi di un array in finestre temporali fisse non sovrapposte (tumbling window — il modello di windowing usato da Apache Flink, Kafka Streams, Spark Structured Streaming, e tutti i sistemi di stream processing modern). Riceve un dataset con timestamp su ciascun item (es. event_time, created_at, occurred_at) e produce N finestre del tipo "tutti gli eventi tra start e end" — la primitiva per costruire dashboard time-series, calcolo di KPI rolling, analytics per cohort temporali, alerting su anomalie rispetto a baseline storica. Granularity configurabile multi-livello: minute (1 finestra per ogni minuto solare — utile per alerting real-time, es. "throughput minuto sopra soglia"), hour (per dashboard operative tipiche dove l'ora è la risoluzione naturale del business), day (per analytics generali del giorno solare, KPI giornaliero), week (settimana ISO 8601 con start lunedì standard EU oppure domenica US configurable), month (mese solare con gestione corretta dei mesi a 28/29/30/31 giorni e cambio anno). Timezone-aware: il timestamp di input viene parsato come UTC se non porta timezone explicit, oppure convertito alla timezone dichiarata (es. "Europe/Rome") prima del bucketing — fondamentale per reporting accurato in contesti italiani dove "vendite del 31 marzo 2026" include eventi entro le 23:59 CEST (= 21:59 UTC), mai gli eventi delle 22:00 UTC = 00:00 del 1 aprile CEST. DST handling corretto (ora legale/ora solare) durante le finestre di transizione bi-annuale. Output: { windows: [{ start (ISO 8601 timezone-aware), end, items: [...], count, durationMs }], totalWindows, totalItems, span (range temporale coperto), bucketSize }. Item privi di timestamp finiscono nel gruppo "_undated_" — visibile per debug invece di silenziosamente droppati. Use case: bucket eventi error_log per dashboard hourly "errori/ora delle ultime 24h" con detection di spike anomali rispetto al baseline; aggregazione di account.move Odoo per giorno per il report fatturato del mese tramite agent_business_summarizer; count di sessioni utenti distinte per settimana per il MAU/WAU/DAU del business dashboard B2B SaaS; rolling KPI con window deslizante (es. "media mobile su 7 giorni della conversion rate") per smussare il rumore daily; aggregazione di chiamate LLM gateway per ora per il forecast costi mensili e capacity planning vLLM.

Coltellino svizzero crittografico enterprise basato esclusivamente su `node:crypto` (zero dipendenze esterne, nessuna superficie d'attacco supply-chain) per tutte le operazioni di integrità, autenticazione e codifica dei dati nei workflow. Cinque operazioni in un solo nodo, ognuna selezionabile da dropdown con i parametri che appaiono/scompaiono in UI in base alla scelta (zero campi inutili a schermo): (1) HASH — digest a senso unico (SHA-256/384/512, SHA-1, MD5) di qualsiasi stringa o dell'input del nodo, output in hex o base64, per fingerprint di documenti, idempotency-key deterministiche da payload, ETag, integrity check di file scaricati, deduplica per contenuto; (2) HMAC — hash autenticato con chiave segreta, l'operazione fondamentale per VERIFICARE le firme dei webhook in arrivo (Stripe `Stripe-Signature`, GitHub `X-Hub-Signature-256`, Shopify, PayPal) e per FIRMARE le proprie callback in uscita — confronto a tempo costante (timing-safe) implementato a valle per evitare timing attack sulla verifica; (3) ENCODE / (4) DECODE — conversione tra utf8 ↔ base64 / hex / base64url, per preparare Basic Auth headers, data-URI, payload binari in JSON, token; (5) RANDOM — bytes crittograficamente sicuri (CSPRNG) per generare secret, salt, nonce, token di reset, state OAuth anti-CSRF. Output: { result, operation, algorithm, encoding } — sempre osservabile e loggabile. Use case: verifica firma webhook Stripe prima di processare il pagamento (HMAC-SHA256 del raw body con il signing secret, confronto con l'header); idempotency key SHA-256 del payload ordine per non creare fatture duplicate sui retry; generazione token di reset password sicuro (RANDOM 32 byte → hex); Basic Auth header (ENCODE "user:pass" → base64); fingerprint deduplica articoli scraped (HASH del titolo+url).

Generatore di identificatori unici enterprise per ogni esigenza di chiavi, correlation-id, idempotency e ordinamento, con cinque formati selezionabili da dropdown — perché non tutti gli ID sono uguali e usare quello giusto evita bug sottili e indici di database lenti: (1) UUID v4 — 122 bit casuali, lo standard universale per chiavi primarie, request-id, token opachi; (2) UUID v7 — timestamp-ordered (i primi 48 bit sono il millisecondo di creazione): ORDINABILE cronologicamente, ideale come PRIMARY KEY su Postgres/MySQL perché mantiene la località dell'indice B-tree (gli insert vanno sempre "in coda" invece di frammentare l'indice come fa il v4 random) → 2-3× più veloce su tabelle grandi; (3) ULID — 26 char Crockford-base32, lessicograficamente ordinabile e URL-safe, alternativa compatta al v7; (4) SHORT — 10 char, per slug/codici brevi human-shareable dove la collisione è tollerabile; (5) NANOID — 21 char URL-safe, compatto e collision-resistant per URL pubblici. Genera da 1 a 10.000 ID in un colpo (campo count) con opzione maiuscolo/minuscolo. Tutti generati con CSPRNG (`node:crypto`), mai `Math.random()` (predicibile). Output: { id, ids } (singolo) oppure { ids } (batch). Use case: chiave idempotency per chiamata API a valle; correlation-id per tracciare una richiesta attraverso più nodi/log; primary key v7 per i record creati dal workflow (insert veloci); token di condivisione pubblico URL-safe (nanoid); batch di N codici coupon univoci.

Nodo JWT (JSON Web Token) completo — firma, verifica e decodifica — implementato su `node:crypto` HMAC (HS256/384/512) senza dipendenze esterne, con verifica della firma a TEMPO COSTANTE (timingSafeEqual) per neutralizzare i timing attack e controllo automatico della scadenza (claim `exp`). Tre operazioni da dropdown, campi condizionali in UI: (1) SIGN — crea un token firmato da un payload JSON: aggiunge automaticamente `iat` (issued-at) e, se specifichi una durata, `exp` (scadenza) — per emettere token di sessione, magic-link di accesso, inviti, API key temporanee a servizi a valle, handoff sicuro tra sistemi; (2) VERIFY — valida un token in arrivo: controlla la firma con il secret E la scadenza, restituendo `{ verified, signatureValid, expired, payload }` — il check da fare SEMPRE prima di fidarsi del contenuto di un token (es. webhook firmati JWT, callback OAuth, richieste autenticate da un altro tenant); (3) DECODE — legge header e payload SENZA verificare la firma (output `verified:false` esplicito per non illudere) — utile solo per ispezione/debug o per leggere claim non sensibili (es. quale `kid` usare). NB: il decode NON è una verifica — non fidarti mai del payload di un token non verificato. Output: token firmato, oppure { verified, payload, ... }. Use case: verifica un JWT in arrivo da un partner prima di accettare la richiesta (VERIFY); emetti un magic-link di accesso valido 15 minuti (SIGN con exp=900); ispeziona un token per estrarre il claim `sub`/`email` in debug (DECODE); genera un service-token per chiamare un'API interna.

Nodo CSV bidirezionale conforme a RFC 4180, in JavaScript puro (zero dipendenze, nessuna superficie supply-chain), per convertire tra il formato tabellare universale dei dati aziendali e gli array di oggetti che attraversano il workflow. Due operazioni da dropdown: (1) PARSE — da testo CSV ad array di oggetti: gestisce CORRETTAMENTE i casi che rompono i parser ingenui — campi tra virgolette contenenti il delimitatore, virgolette escapate raddoppiate (""), a-capo dentro un campo quotato, terminatori di riga Windows (\r\n) e Unix (\n); con la prima riga come intestazione mappa ogni colonna sul nome del campo (output array di { colonna: valore }), altrimenti restituisce righe come array di celle; (2) STRINGIFY — da array di oggetti a testo CSV: deduce automaticamente le intestazioni dall'unione di tutte le chiavi presenti negli oggetti (nessun campo perso anche se gli oggetti hanno chiavi diverse), quota automaticamente solo le celle che lo richiedono ed escapa le virgolette interne. Delimitatore configurabile (virgola, punto e virgola — standard EU/Excel italiano —, tab \t, pipe). Output PARSE: { rows, headers, count } · STRINGIFY: { csv, count }. Use case: importa il CSV export di un gestionale/banca e processane le righe; trasforma il risultato di una query DB nel CSV da allegare a un'email; converti il file caricato da un cliente (punto e virgola, Excel IT) in JSON per l'elaborazione; genera il report CSV settimanale di ordini per la contabilità.

Coltellino svizzero per collezioni — otto operazioni su array di elementi in JavaScript puro (zero dipendenze), tutte con supporto al dot-path per lavorare su campi annidati ("cliente.indirizzo.città"). Sostituisce il nodo Item Lists di n8n e l'uso del nodo Code per le manipolazioni più comuni: (1) UNIQUE — rimuove i duplicati, opzionalmente per un campo-chiave (deduplica gli ordini per email cliente, gli articoli per URL); (2) SORT — ordina per campo e direzione, con confronto numerico-aware (10 dopo 9, non dopo 1) e locale-aware per le stringhe; (3) GROUP — raggruppa per campo restituendo { valore: [elementi] } (ordini per stato, transazioni per mese, lead per fonte); (4) CHUNK — spezza in blocchi di N elementi (per batch API rate-limited, paginazione, invii a lotti); (5) FLATTEN — appiattisce array annidati fino alla profondità scelta; (6) PICK — proietta solo i campi indicati di ogni elemento (riduce il payload, seleziona le colonne); (7) SLICE — estrae una porzione (start/end, indici negativi supportati per "ultimi N"); (8) REVERSE — inverte l'ordine. L'input può essere un array nativo o una stringa JSON (parsata automaticamente). Output: { result, count, operation }. Use case: deduplica i lead importati prima di inserirli nel CRM (UNIQUE by email); raggruppa le righe fattura per aliquota IVA (GROUP); spezza 5.000 contatti in blocchi da 100 per l'API di invio (CHUNK); ordina i prodotti per prezzo decrescente nella newsletter (SORT desc); tieni solo nome+email per il CSV export (PICK).

Manipolatore di oggetti JSON via dot-path, in JavaScript puro (zero dipendenze) — ciò che in n8n richiede il nodo Set / Edit Fields o sistematicamente il nodo Code. Otto operazioni da dropdown che lavorano su percorsi annidati con la notazione a punti ("cliente.indirizzo.città", "righe.0.totale"): (1) GET — estrae il valore a un percorso (naviga oggetti e array, undefined se assente, mai crash su percorso inesistente); (2) SET — imposta un valore a un percorso creando automaticamente gli oggetti intermedi, in modo immutabile (non muta l'input); il valore è interpretato come JSON se possibile (numeri, bool, oggetti), altrimenti come stringa; (3) PICK — costruisce un nuovo oggetto con SOLO i percorsi indicati (whitelist di campi, riduzione payload prima di inviarlo a un'API o loggarlo); (4) OMIT — rimuove i campi indicati (blacklist: togli `password`, `token`, PII prima di un log/webhook); (5) MERGE — fonde in profondità un secondo oggetto su quello in ingresso (i campi annidati si combinano, non si sovrascrivono in blocco) — per applicare default o patch parziali; (6) FLATTEN — appiattisce un oggetto annidato in chiavi dot ({a:{b:1}} → {"a.b":1}) per CSV/colonne DB; (7) KEYS / (8) VALUES — estrae le chiavi o i valori di primo livello. Output: { result, operation }. Use case: estrai `data.user.email` dalla risposta annidata di un'API (GET); rimuovi i campi sensibili prima di loggare un payload webhook (OMIT password,token); applica valori di default a un oggetto di configurazione parziale (MERGE); appiattisci un ordine annidato per scriverlo come riga DB/CSV (FLATTEN); imposta `status="processed"` su un record senza mutare l'originale (SET).

Coltellino svizzero per le stringhe — nove operazioni di manipolazione testo in JavaScript puro (zero dipendenze), per non dover più scrivere nodi Code per ogni piccola trasformazione. Operazione da dropdown con solo i suoi parametri visibili: (1) MAIUSCOLO / (2) minuscolo / (3) Capitalizza (prima lettera) / (4) Titolo (Ogni Parola) — normalizzazione di nomi, città, intestazioni; (5) TRIM — rimuove spazi iniziali/finali (pulizia di input da form e import); (6) SLUGIFY — trasforma in slug URL-safe rimuovendo accenti (à→a) e caratteri speciali ("Caffè à gogò" → "caffe-a-gogo"), per permalink, nomi file, anchor; (7) TRUNCATE — tronca a N caratteri aggiungendo un suffisso (…), senza tagliare a metà parola dove possibile, per anteprime ed estratti; (8) REPLACE — sostituzione letterale (tutte le occorrenze) o tramite espressione regolare con flag, per normalizzare formati, mascherare dati, ripulire testo; (9) EXTRACT — estrae con regex tutti i match e i gruppi di cattura (email, partite IVA, importi, codici da un testo libero) restituendo { matches, groups, first, count }; più SPLIT (testo → array per delimitatore, con trim opzionale delle parti) e PAD (allinea a lunghezza fissa con riempimento, per codici/numeri zero-padded). Output: { result, length, operation } (o { matches, groups, ... } per EXTRACT). Use case: normalizza i nomi cliente in Titolo prima di salvarli; genera lo slug SEO da un titolo articolo; estrai tutte le email da un corpo di testo (EXTRACT); maschera le cifre di una carta (REPLACE regex); tronca la descrizione prodotto a 160 caratteri per la meta-description.

Motore di template testuale in JavaScript puro (zero dipendenze) per comporre stringhe dinamiche — email, messaggi, URL, query, corpi di richiesta — interpolando i dati del workflow dentro un testo fisso con la sintassi a doppie graffe `{{ percorso }}`. I segnaposto supportano il dot-path annidato (`{{ cliente.indirizzo.città }}`, `{{ ordine.righe.0.totale }}`) e un valore di default con `||` (`{{ nome || "Cliente" }}` → usa "Cliente" se nome è assente/vuoto) — niente più "undefined" o buchi nei messaggi quando un campo manca. Il contesto dei dati viene dall'input del nodo (oggetto o JSON) o da un campo dedicato. Modalità ESCAPE HTML opzionale: quando attiva, i valori interpolati vengono automaticamente neutralizzati (`<`, `>`, `&`, `"`, `'`) — fondamentale quando il template genera HTML con dati utente, per prevenire XSS/injection (a differenza del nodo Code dove l'escape è a carico tuo). Il nodo segnala anche quali segnaposto non hanno trovato un valore (output `missing` + `hasMissing`), così puoi accorgerti dei dati mancanti invece di inviare un messaggio rotto. Output: { result, missing, hasMissing }. Use case: componi il corpo di un'email di conferma ordine con nome cliente e dettagli (escape HTML on); costruisci un URL di callback con parametri dinamici; genera un messaggio Telegram/Slack personalizzato; prepara il body JSON di una chiamata API interpolando i valori; crea un SMS con default per i campi opzionali. NB: solo interpolazione di valori (no logica/cicli) — per la logica usa i nodi IF/Loop a monte.

Nodo data/ora completo in JavaScript puro (solo Date + Intl, zero dipendenze) con supporto NATIVO a fuso orario e locale italiano — risolve il dolore numero uno dell'automazione: lavorare con le date senza sbagliare timezone o formato. Cinque operazioni da dropdown: (1) NOW — istante corrente in tutti i formati utili (ISO 8601, epoch in millisecondi e secondi) per timestamp, idempotency, log; (2) FORMAT — formatta una data nel modo giusto per gli umani con preset (data breve, data estesa, solo ora, completo, ISO) E in formato RELATIVO ("3 ore fa", "tra 2 giorni") tramite Intl.RelativeTimeFormat, tutto rispettando fuso orario (default Europe/Rome) e lingua (default it-IT) — niente più date in inglese o in UTC nelle email ai clienti; restituisce anche il giorno della settimana; (3) ADD / (4) SUBTRACT — aggiunge o sottrae un intervallo (secondi, minuti, ore, giorni, settimane, mesi, anni) gestendo correttamente i mesi di lunghezza diversa e gli anni bisestili (scadenze fattura a +30 giorni, promemoria, date di rinnovo, finestre temporali); (5) DIFF — calcola la differenza tra due date nell'unità scelta (giorni di ritardo di un pagamento, età di un lead, durata tra due eventi), con valore esatto e troncato. Accetta in ingresso ISO, epoch (secondi o ms, riconosciuti automaticamente), stringhe di data comuni o "now". Output a seconda dell'operazione: { iso, epochMs, epochSec } / { formatted, weekday, ... } / { value, rounded, unit }. Use case: scadenza fattura = oggi + 30 giorni (ADD); "ordine ricevuto 2 ore fa" in un alert (FORMAT relative); giorni di ritardo di un pagamento (DIFF); data di consegna formattata in italiano nell'email (FORMAT full it-IT); timestamp ISO per un record (NOW).

Coltellino svizzero numerico in JavaScript puro (Math + Intl, zero dipendenze) con formattazione monetaria e numerica ITALIANA/europea nativa — per non sbagliare mai un arrotondamento o un formato prezzo nei workflow di fatturazione, e-commerce, contabilità. Nove operazioni da dropdown: (1) ROUND — arrotonda a N decimali (totali fattura, prezzi) senza gli errori di virgola mobile; (2) FLOOR / (3) CEIL / (4) ABS — troncamento per difetto/eccesso e valore assoluto; (5) CLAMP — vincola un valore tra un minimo e un massimo (limita sconti, quantità, punteggi); (6) PERCENT — calcola la percentuale di un totale (IVA, sconto, provvigione) o converte una frazione in %; (7) CURRENCY — formatta come valuta con simbolo, separatori e decimali corretti per il locale (1234.5 → "1.234,50 €" in it-IT, "$1,234.50" in en-US) — il formato giusto per email, fatture, UI; (8) FORMAT — formatta un numero con separatore delle migliaia e decimali secondo il locale; (9) PARSE — interpreta una stringa numerica in QUALSIASI formato ("1.234,56 €", "1,234.56", "€ 99") e la normalizza in un numero pulito — fondamentale per importare prezzi da CSV/scraping/form senza rompersi sul separatore decimale. Il parser di ingresso riconosce automaticamente il formato IT (punto migliaia, virgola decimale) e US. Output: { result, raw, operation }. Use case: arrotonda il totale carrello a 2 decimali (ROUND); formatta il prezzo in "1.234,50 €" per l'email ordine (CURRENCY); calcola il 22% di IVA su un imponibile (PERCENT); importa i prezzi dal CSV fornitore in formato italiano (PARSE); limita lo sconto applicabile a max 50% (CLAMP).

Calcola statistiche aggregate su un array di numeri (o su un campo numerico di un array di oggetti) in JavaScript puro (zero dipendenze) — ciò che in n8n richiede il nodo Code o Summarize. In un colpo solo restituisce conteggio, somma, media, minimo, massimo, MEDIANA (più robusta della media verso gli outlier) e DEVIAZIONE STANDARD (dispersione dei dati). Puoi richiederle tutte insieme (operazione "all") o selezionarne una sola. Lavora con il dot-path per aggregare un campo annidato di oggetti ("ordini[].totale"). Il parser numerico riconosce i formati italiano/US e ignora i valori non numerici (non si rompe su celle vuote o testo). Output: { result, count, sum, avg, min, max, median, stddev }. Use case: totale e media del fatturato mensile dagli ordini (sum/avg su "totale"); valore massimo e minimo di una serie di prezzi; mediana dei tempi di risposta per ignorare i picchi; deviazione standard per rilevare anomalie; conteggio di righe valide importate da un CSV.

Validatore enterprise di formati con CHECKSUM REALI — non le solite regex ingenue che accettano un Codice Fiscale o una Partita IVA sintatticamente plausibili ma matematicamente falsi. JavaScript puro (zero dipendenze). Sette tipi da dropdown, ognuno con la sua logica corretta: (1) EMAIL — formato valido, normalizzata in minuscolo; (2) URL — schema http/https valido, normalizzato; (3) PARTITA IVA (IT) — 11 cifre con verifica dell'algoritmo di Luhn ministeriale (la cifra di controllo deve quadrare, non basta che siano 11 numeri); (4) CODICE FISCALE (IT) — 16 caratteri con calcolo del CARATTERE DI CONTROLLO ufficiale (tabelle pari/dispari del Ministero): individua i codici inventati che passerebbero una regex; (5) IBAN — validazione ISO 13616 mod-97 (sposta i primi 4 caratteri, converte le lettere, resto su 97 = 1): scarta gli IBAN con una cifra sbagliata, prima di tentare un bonifico; (6) TELEFONO (IT) — normalizza qualsiasi formato (spazi, prefissi, 00/+) in E.164 (+39…), distinguendo mobile e fisso; (7) JSON — verifica che una stringa sia JSON parsabile. Il nodo è anche RAMIFICATO: espone due uscite "valid" e "invalid" così puoi instradare il flusso senza un nodo IF aggiuntivo. Output: { valid, normalized, type, value } + branch. Use case: valida la Partita IVA inserita in un form prima di creare la fattura (scarta le false); verifica l'IBAN del fornitore prima del bonifico (anti-errore di battitura); normalizza i telefoni dei lead in E.164 per l'invio SMS; controlla il Codice Fiscale in onboarding cliente; instrada le email non valide a un ramo di correzione.

Nodo per costruire, analizzare e modificare URL e query string in modo SICURO, basato sull'oggetto URL nativo (zero dipendenze) invece delle fragili concatenazioni di stringhe che rompono l'encoding. Sei operazioni da dropdown: (1) PARSE — scompone un URL in tutte le sue parti (protocollo, host, porta, percorso, query come oggetto chiave/valore, hash, origin) per ispezionare callback, webhook, redirect; (2) BUILD — compone un URL da una base, un percorso e parametri di query, con l'encoding automatico e corretto di ogni valore (spazi, accenti, simboli) — niente più "&" e "%20" sbagliati a mano; (3) SET QUERY — aggiunge o sovrascrive parametri di query su un URL esistente (aggiungi un token, un utm_source, un parametro di tracciamento); (4) REMOVE QUERY — rimuove parametri (togli i tracking param prima di salvare/condividere un link); (5) ENCODE / (6) DECODE — codifica/decodifica percent-encoding di un singolo valore per inserirlo in un URL o estrarlo. I parametri si passano come oggetto JSON, ognuno viene codificato correttamente. Output PARSE: { protocol, host, pathname, query, hash, origin, href } · altri: { href, query } o { result }. Use case: costruisci l'URL di una chiamata API con parametri dinamici e sicuri (BUILD); estrai il parametro "code" dal redirect OAuth (PARSE → query.code); aggiungi un token di firma a un link webhook (SET QUERY); rimuovi gli utm_* da un URL prima di salvarlo nel CRM (REMOVE QUERY); codifica un termine di ricerca per una query (ENCODE).

Modella un oggetto impostando, rinominando e rimuovendo PIÙ campi in un solo nodo — l'equivalente del nodo Set / Edit Fields di n8n, in JavaScript puro (zero dipendenze) e con il dot-path per i campi annidati. Quattro leve, tutte in UI: (1) IMPOSTA — un editor chiave/valore dove ogni riga è "percorso → valore": crea o sovrascrive campi anche annidati ("cliente.stato" → "attivo"), creando automaticamente gli oggetti intermedi; con la conversione di tipo opzionale i valori "42", "true", "{\"a\":1}" diventano numero/booleano/oggetto invece di restare stringhe; (2) RINOMINA — un editor che sposta un campo da un percorso a un altro (allinea i nomi dei campi tra sistemi: "Email" → "email", "user.mail" → "contatto.email"); (3) RIMUOVI — elenca i campi da eliminare (togli PII, campi tecnici, rumore prima di inviare a un'API o salvare); (4) SOLO QUESTI — quando attivo, parte da un oggetto vuoto e tiene esclusivamente i campi che imposti (whitelist totale, payload pulito e prevedibile). Opera su una copia (non muta l'input). Output: { result, fieldCount }. Use case: normalizza un lead dal form (rinomina i campi, imposta source="web", rimuovi i campi nascosti); prepara il body esatto per un'API a valle tenendo solo i campi attesi ("solo questi"); aggiungi metadati (timestamp, stato) a un record; ripulisci un payload webhook dai campi sensibili prima di loggarlo.

Restituisce il PRIMO valore presente tra più sorgenti, con un valore di default finale — il pattern "fallback a catena" (coalesce) che in SQL è COALESCE() e nel codice sono i ?? concatenati, qui in un nodo a prova di idiota (JavaScript puro, zero dipendenze). Indichi un elenco ordinato di percorsi (dot-path) dell'oggetto in ingresso e il nodo prova il primo, se manca passa al secondo, e così via, fermandosi al primo che ha un valore. Con l'opzione "stringa vuota = mancante" (attiva di default) anche i campi presenti ma vuoti vengono saltati — così non propaghi mai un "" dove ti serviva un dato reale. Se nessuna sorgente ha un valore, usa il default che fornisci. Restituisce anche da QUALE sorgente è arrivato il valore (campo "from"), utile per il debug e l'audit. Output: { result, from, found }. Use case: nome visualizzato = primo tra nickname, nome+cognome, email, "Cliente" (default); email di contatto = primo tra email_aziendale, email_personale, email_fatturazione; prezzo = primo tra prezzo_scontato e prezzo_listino; lingua = primo tra preferenza_utente, header_accept_language, "it".

Filtra un array di elementi secondo una o più condizioni combinate con AND/OR, in JavaScript puro (zero dipendenze) — il nodo Filter di n8n, ma con un costruttore visuale di regole "a prova di idiota" e quindici operatori, e con DUE uscite ("kept" = passati, "removed" = scartati) così instradi entrambi i gruppi senza duplicare la logica. Ogni regola è "campo (dot-path) · operatore · valore"; le regole si combinano con TUTTE (AND) o ALMENO UNA (OR). Operatori disponibili: uguale / diverso, contiene / non contiene, inizia con / finisce con, maggiore / minore (e ≥ ≤, con confronto numerico), esiste, vuoto / non vuoto, corrisponde a regex, è tra (lista di valori). Lavora su campi annidati grazie al dot-path. Restituisce i due gruppi con i rispettivi conteggi, così sai subito quanti elementi hai tenuto e scartato. Output: { kept, removed, keptCount, removedCount, total } + branch. Use case: tieni solo gli ordini sopra 100€ e instrada gli altri a un ramo diverso (gt); separa i lead con email aziendale da quelli con email generica (regex / not_contains gmail); filtra i prodotti in stock (exists/gt su quantità); scarta le righe importate senza un campo obbligatorio (empty); seleziona i contatti di una regione (in: "Lazio,Lombardia").

Estrae dati strutturati da una pagina/frammento HTML in JavaScript puro (zero dipendenze) — il nodo HTML Extract di n8n senza dover usare un nodo Code con cheerio. Sei modalità da dropdown: (1) TESTO — rimuove tutti i tag (e i blocchi script/style) restituendo il testo leggibile, con gli a-capo preservati nei punti giusti (paragrafi, liste, heading) e le entità HTML decodificate (&amp; → &): per indicizzare, riassumere via AI, fare analisi del contenuto; (2) LINK — tutti i collegamenti come { href, text } (mappa i link di una pagina, estrai gli URL di un risultato di ricerca, trova i download); (3) IMMAGINI — tutti gli src delle immagini; (4) TITOLO — il contenuto del tag <title>; (5) META — tutti i meta tag come oggetto { name/property: content }, inclusi gli Open Graph (og:title, og:image, description) per anteprime social, SEO, schede prodotto; (6) HEADING — tutti i titoli H1-H6 con il loro livello, per ricostruire la struttura/sommario di un documento. Le entità HTML vengono sempre decodificate e i blocchi script/style esclusi dal testo. Output a seconda della modalità: { result } (testo/titolo) o { result, count } (link/immagini/meta/heading). Use case: estrai il testo pulito di un articolo prima di passarlo a un nodo AI; raccogli tutti i link di una pagina indice per il crawling; leggi i meta Open Graph per generare un'anteprima; ricava il sommario dai heading di una pagina di documentazione.

Converte testo Markdown in HTML SICURO, in JavaScript puro (zero dipendenze) — utile soprattutto per trasformare l'output di un nodo AI (che spesso produce Markdown) in HTML pronto per un'email o una pagina. La cosa fondamentale: ogni contenuto testuale viene ESCAPATO (anti-XSS) prima di applicare la formattazione, e sono supportati solo gli elementi di una whitelist sicura — niente HTML grezzo dell'utente che passa inosservato (a differenza di molte librerie Markdown con opzioni "html: true" pericolose). Supporta: titoli (#…######), grassetto (**), corsivo (*), codice inline (`) e blocchi di codice (```), liste puntate (- / *), citazioni (>), linee orizzontali (---) e link [testo](https://…) — con rel="noopener noreferrer" automatico e SOLO schemi http/https (no javascript:). Output: { html, length }. Use case: trasforma la risposta Markdown di un agente AI nel corpo HTML di un'email; pubblica una nota scritta in Markdown come HTML; genera il contenuto formattato di un messaggio da un template Markdown; converti le note di rilascio Markdown in HTML per una pagina di changelog.

Confronta due valori e rileva ESATTAMENTE cosa è cambiato, in JavaScript puro (zero dipendenze) — ciò che altrimenti richiede un nodo Code con logica ricorsiva. Due modalità da dropdown: (1) OGGETTO — confronto profondo (deep diff) tra due oggetti/JSON: restituisce i campi AGGIUNTI, quelli RIMOSSI e quelli MODIFICATI (con valore "from" e "to"), ognuno identificato dal suo percorso dot-path anche se annidato — per capire cosa è cambiato tra il record vecchio e quello nuovo (audit, change-detection, sincronizzazioni); (2) TESTO — confronto riga per riga tra due testi: marca ogni riga come aggiunta, rimossa o invariata, per evidenziare le differenze tra due versioni di un documento, una configurazione, una risposta. Il nodo è RAMIFICATO ("equal" / "different") così attivi un flusso solo quando qualcosa è effettivamente cambiato, evitando lavoro inutile. Entrambi gli input accettano oggetti nativi o stringhe JSON/testo. Output OGGETTO: { added, removed, changed, equal, changeCount } · TESTO: { changes, added, removed, equal }. Use case: rileva quali campi di un cliente sono cambiati per aggiornare solo quelli sul CRM (deep diff); attiva un alert solo se la configurazione monitorata è cambiata (branch different); confronta la risposta di un'API con quella precedente per change-detection; mostra le differenze tra due versioni di un testo.

Genera dati di test realistici con dataset ITALIANO (nomi, cognomi, città, aziende verosimili) in JavaScript puro (zero dipendenze) — per sviluppare e collaudare un workflow senza dipendere da dati di produzione o da un servizio esterno ancora non pronto. Definisci uno schema (editor chiave/valore: "nomeCampo" → "tipo") e il nodo produce N record coerenti. Tipi disponibili: firstName, lastName, fullName, email, phone (formato +39 italiano), company, city (città italiane), word, sentence, paragraph (testo lorem), integer, number, boolean, uuid (v4), date, pastDate, futureDate (in ISO 8601). Fondamentale: con un SEED (qualsiasi stringa) l'output è RIPRODUCIBILE — gli stessi dati a ogni esecuzione, così i test sono deterministici e ripetibili; senza seed i dati sono casuali a ogni run. Da 1 a 1.000 record per chiamata. Se non definisci uno schema, ne usa uno di default (id, nome, email, città). Output: { items, count, seed }. Use case: popola un workflow in sviluppo con 50 finti lead per testare il ramo di elaborazione; genera dati riproducibili (seed) per un test automatico che deve dare sempre lo stesso risultato; crea un dataset di esempio da inviare a un'API in staging; produci righe finte per provare un nodo CSV/email senza usare clienti reali.

Trasforma il tuo workflow in una vera API REST con risposta STRUTTURATA e coerente, in JavaScript puro (zero dipendenze). Si posiziona alla fine di un workflow che parte da `trigger_webhook` (responseMode = "use-respond-node"): il trigger riceve la chiamata HTTP, il workflow elabora, e questo nodo costruisce la risposta nel formato REST standard 2026 — così chi consuma la tua API riceve SEMPRE una struttura prevedibile, non un JSON improvvisato. Due modalità da dropdown: (1) SUCCESS — avvolge i dati in un envelope coerente `{ ok: true, data: <payload>, meta?: {…} }` con uno status di successo semantico (200 OK / 201 Created / 202 Accepted / 204 No Content) e un blocco meta opzionale per paginazione, totali, versione; (2) ERROR — produce `{ ok: false, error: { code, message, details? } }` con il CODICE D'ERRORE REST standard che mappa automaticamente sullo status HTTP corretto (bad_request→400, unauthorized→401, forbidden→403, not_found→404, conflict→409, validation_error→422, rate_limited→429, server_error→500) — niente più status sbagliati o messaggi d'errore incoerenti tra un endpoint e l'altro. Gestione CORS integrata (origin, metodi, header, credentials) per essere chiamato direttamente dal browser di una SPA senza configurare nulla a mano, header personalizzati con guardia anti-injection (no CRLF), e modalità "envelope off" se preferisci restituire i dati grezzi. Content-Type sempre application/json; charset=utf-8. Output: sentinel `__webhookResponse` raccolto dal runtime (status + body + headers). Use case: esponi un endpoint pubblico che restituisce i dati di un ordine in formato REST pulito (SUCCESS + envelope + meta paginazione); rispondi 404 strutturato quando una risorsa non esiste (ERROR not_found); valida l'input e rispondi 422 con i dettagli dei campi sbagliati (ERROR validation_error + details); crea una micro-API consumata da una SPA browser (CORS on); webhook che risponde 200 con un ack strutturato a un partner B2B.

Operatore di pausa event-driven enterprise che sospende l'esecuzione del workflow fino all'arrivo di un segnale esterno via HTTP — il pattern signal-and-wait classico di Temporal/Cadence Workflows e workflow orchestration enterprise, fondamento di tutti i processi long-running con interazione umana o coordinamento asincrono con sistemi esterni dove il tempo di attesa è ore-giorni-settimane (non secondi come logic_delay). Implementazione resilient: il run state completo (variables, step history, expression context) viene persistito nel checkpoint del SQLite runtime tenant in stato `paused_waiting_signal`, il workflow continua a contare nelle quote dei workflow attivi ma non consuma CPU/RAM mentre attende. Il signal arriva via POST `<tenant>.app.automazionezeli.com/signals/<signal_name>` con payload JSON opzionale — il portal scheduler intercetta, verifica permessi (signal_token segreto del workflow se signalRequiresAuth) e firma il resume del workflow da dove era stato sospeso. Sopravvive a TUTTO: restart container per deploy, crash del runtime, migrazione tra host fisici, pausa idle del container con wake-on-signal automatico, upgrade major version del runtime image. La pausa può durare letteralmente settimane senza degradation perché lo state vive in disco persistente, non in memoria volatile. Cap di sicurezza: timeoutMs configurabile (default 30 giorni, max 90gg) dopo il quale il workflow riprende con status `signal_timeout` e branch fallback eventualmente collegato. Match opzionale su payload via expression: invece di accettare CUALQUIER signal con name matching, è possibile filtrare ulteriormente con un'expression JavaScript-like (es. "$.payload.userId === currentUser && $.payload.action === 'approve'") che decide se questo signal è quello "giusto" per questo specifico run sospeso — pattern critico in scenari multi-run sospesi simultaneamente sullo stesso signal name dove serve discriminare. Output al resume: { signal_payload (intera JSON del POST body del signal), receivedAt (ISO timestamp), pausedDuration (ms tra pause e resume per metrics SLA) }. Use case: workflow approvazione fattura sopra una certa soglia (€10k+) che attende click del manager su pulsante "Approve" o "Reject" nell'inbox email (il button è un link al endpoint signal con UUID firmato embedded), pausa media 24-48h business hours; onboarding multi-step di un nuovo cliente B2B con conferma email (envia email link → user click link → signal received → workflow continua con setup automatic workspace + access provisioning), pausa media 1-3 giorni; processo legale con SLA giorni-settimane di attesa controfirme contratto da multiple parti via DocuSign webhook signal; pipeline ETL che attende batch downstream completed da sistema legacy mainframe che invia signal HTTP al termine; human-in-the-loop ML review dove il modello AI è incerto (confidence < soglia) e l'operatore deve validare prima della propagazione downstream alla produzione.

Esegue una SELECT su tabella di un database FlowForge-managed con filtri visuali (WHERE), colonne, ordinamento e limit. I filtri vengono combinati in AND (operatori per tipo: eq/neq/gt/lt/contains/in/is-null). Supporta paginazione via limit + offset. Output: array di rows. Use case: lookup record per ID/email, scan filtrato per cron, report KPI dashboard, join soft-coded in JS post-query. Per query complesse (JOIN/CTE/GROUP BY) usa db_sql_query.

INSERT di una riga in una tabella. Dati passati via config key-value (con {{espressioni}}) o piped dal nodo precedente. Supporta onConflict policy: "fail" (default, raise error su PK/UNIQUE collision — protegge da duplicati indesiderati) o "ignore" (skip silente — utile per dedup table marker idempotenti come processed_emails/processed_webhooks). Output: { id, inserted: true } o { skipped: true } se onConflict=ignore + collision. Use case: log eventi, salvare lead/contatti, marker idempotenti, inserimento dati da form/CSV.

Inserisce in modo ATOMICO un header (es. ordine) + N righe figlie (es. order_lines), tutto in una transazione singola. Se l'inserzione delle righe fallisce, anche l'header viene rollbackato — niente ordini fantasma in DB. Tipico per: orders+order_lines, invoices+invoice_lines, deliveries+delivery_items.

UPDATE righe matching un where clause (key-value). Patch via campi key-value con supporto {{espressioni}}. TUTTE le condizioni WHERE in AND (anti-update accidentale di tabella intera). Se where vuoto → errore (safety). Output: { updatedCount, rows? }. Use case: aggiornare status ordine (paid/shipped), mark email as read, increment counter, sync field da API esterna.

DELETE righe matching un where clause. OPERAZIONE DISTRUTTIVA: richiede flag confirmDelete=true per evitare misclick. TUTTE le condizioni WHERE in AND. Where vuoto → errore (safety, anti-truncate). Output: { deletedCount }. Use case: cleanup expired sessions, soft-delete con flag invece di DELETE fisica (consigliato), purga dati scaduti GDPR. ATTENZIONE: per audit_log usa il sistema cold-storage (DELETE bloccato da trigger).

Esegue il workflow quando una riga viene insert/update/delete in una tabella FlowForge DB (real-time subscribe). Filtri opzionali per condition match (es. status=active AND amount>100 — trigger solo per righe interessanti). Input al workflow: { event: insert|update|delete, row, oldRow?, table }. Use case: notifica admin su nuovi ordini, sync esterno post-update CRM, audit trail su tabelle sensibili, dashboard real-time KPI senza polling.

Esegue una SELECT custom SQL (con JOIN, GROUP BY, CTE WITH, aggregations, subquery) e ritorna le righe. SOLO LETTURA: guard server-side rejecta INSERT/UPDATE/DELETE/DDL (per mutazioni usa db_insert/db_update/db_delete). Row limit configurabile (default 5000, hard cap anti-runaway). Parametrizzato anti-SQLi via Drizzle. Output: { rows: object[], rowCount, durationMs }. Use case: report multi-tabella per dashboard, analytics aggregati pre-Excel, query complesse da legacy SIGLA/Odoo.

Invia un messaggio PEC tramite casella Aruba. Default: SMTP standard (smtps.pec.aruba.it:465) con supporto allegati. Modalità SOAP legacy disponibile per workflow esistenti.

Esegue il workflow alla ricezione di una nuova PEC su account Aruba (polling IMAP imaps.pec.aruba.it:993 SSL). Filtri opzionali: from regex, oggetto contains, allegati required, classify tramite action_pec_classify downstream. Input al workflow: { messageId, from, to, subject, body, attachments[], pecHeaders, pecType (received/acceptance/delivery/reject) }. Use case: archivio legale automatico PEC ricevute, triage studio commercialista (parse fatture/cartelle/notifiche), forward selettivo PEC clienti su CRM, audit trail compliance art. 2710 c.c.

Crea una nuova fattura su Fatture in Cloud (REST API + OAuth2 scope invoices.write). Input: clientId (lookup upstream), righe articoli (qty/unit/price/vat%), payment method codici SDI standard, codice destinatario SDI o PEC. Output: { invoiceId, number, pdfUrl, sdiStatus }. Invio SDI separato (PEC o Aruba). Use case: fatturazione automatica post-ordine e-commerce, fatturazione ricorrente abbonamenti, fatturazione massiva fine mese per studio commercialista, integrazione checkout B2B.

Cerca un cliente Fatture in Cloud per partita IVA o codice fiscale; opzionalmente lo crea se non esiste (idempotent upsert). Lookup VAT 11 cifre (con/senza prefisso IT) o CF 16 char (persona fisica). Output: { clientId, found: bool, created: bool, fullData }. Pair con italia_fatture_in_cloud_invoice downstream. Use case: onboarding lead → cliente FIC prima di emettere fattura, dedup clienti da import CSV, lookup automatico da form contact.

Trasmette una fattura elettronica FatturaPA (XML standard SDI v1.2.2) al Sistema di Interscambio Agenzia delle Entrate. Channel via PEC accreditato o SDIcoop/ADEL (canale diretto SOAP autenticato). Validazione XSD pre-invio + firma XAdES-BES opzionale. Output: { sdiId, status (sent/accepted/rejected), notificationFile, deliveryTimestamp }. Use case: invio automatico fatture B2B/B2G post-emissione Fatture in Cloud, invio massivo fine ciclo fatturazione, integrazione con ERP legacy via canale FlowForge.

Recupera lo stato di una fattura inviata al SDI (RC = ricevuta committente, NS = notifica scarto, MC = mancata consegna, NE = notifica esito, DT = decorrenza termini).

Avvia un job di elaborazione cedolini su Zucchetti HR Go (payroll API REST + OAuth2). Input: periodo (YYYY-MM), filtro dipendenti opzionale (per codice/dipartimento), modalità (preview/finale). Output: { jobId, status, estimatedMinutes, employeeCount }. Polling status via secondo nodo recommended (job async). Use case: chiusura mensile payroll automatica (cron giorno 28), preview cedolini per HR review, on-demand recalculation post-correzione, batch cedolini multi-società per gruppi.

Aggiorna un record DNS su un dominio gestito Register.it (REST API + apiKey). Supporta record: A/AAAA/CNAME/MX/TXT/SRV/CAA. Upsert: crea se non esiste, update se esistente (idempotent). TTL configurabile (default 3600s). Output: { recordId, propagated: bool, ttlSeconds }. Use case: switch dinamico IP A-record per failover infrastruttura, gestione automatica MX records post-migrazione mailbox, TXT record per verifica domain ownership (SPF/DKIM/DMARC), aggiornamento subdomain wildcard CNAME.

CRUD universale su qualsiasi modello Odoo (res.partner, sale.order, account.move, ...) + esecuzione metodi custom del modulo proprietario. JSON-RPC su /jsonrpc (Odoo 12+). Domain syntax polish notation. Authenticate cached 30min per connection. UI con progressive disclosure: vedi solo i campi che servono per l'action scelta.

CRUD universale su WordPress REST API v2. Posts, pages, media, users, categories, tags, comments. Auth via Application Password (Users → Profile → Application Passwords, WordPress 5.6+). 43% del web gira WP — ideale per cliente con sito vetrina, blog, magazine, landing pages.

CRUD universale su WooCommerce REST API v3. Products, orders, customers, coupons, refunds, taxes, shipping zones, batch endpoint (100 ops/req). 30% e-commerce market share — cliente con shop online ne ha probabilmente uno. Auth: consumer_key + consumer_secret da WooCommerce → Settings → Advanced → REST API.

Chiama AI: Anthropic Claude con la tua API key. Opus = potenza massima (costoso). Sonnet = bilanciato (default). Haiku = economico, veloce.

Chiama AI: OpenAI GPT con la tua API key. gpt-4o = top quality. gpt-4o-mini = veloce/economico (default). gpt-3.5-turbo = legacy.

Chiama AI: Google Gemini con la tua API key. gemini-2.0-flash = nuovo, veloce (default). 1.5-pro = qualità più alta.

Chiama AI: OpenRouter (100+ models) con la tua API key. OpenRouter dà accesso a 100+ modelli con una sola key. Formato: vendor/model.

Chiama AI: Ollama (local) con la tua API key. Modelli devi averli pull-ati localmente con `ollama pull <nome>` prima.

Agent LLM senior security engineer: audita codice/config contro OWASP Top 10, injection vector (SQLi/XSS/SSRF/CSRF), secret leakage in plaintext, weak crypto (MD5/SHA1/DES), supply-chain risks (deprecated deps, typosquat). Output JSON: { findings: [{ severity, title, line, remediation }], summary }. Severity: critical/high/medium/low. Use case: pre-merge PR review automatico, audit periodico repo legacy, CI gate su pattern vietati, due diligence code acquisition.

Agent LLM senior code reviewer: rileva bug, anti-pattern, perf issue, missing error handling, miglioramenti idiomatici lingua-specifici. Output JSON: { issues: [{ severity (blocker/major/minor), file, line, message, suggestion }], overall_grade (A-F), summary }. Use case: PR review automatico pre-merge GitHub/GitLab, training junior dev con feedback dettagliato, audit refactoring legacy, gate CI per blocker severity, code quality dashboard team.

Agent LLM data analyst: analizza dati tabulari (JSON/CSV) ed estrae distribuzioni per colonna, outlier (metodo IQR), correlazioni tra colonne (Pearson r), missing-value pattern, trend chiave. Output JSON: { columns: [{ name, type, missing, stats }], correlations: [{ a, b, r }], anomalies, insights }. Use case: EDA preliminare su CSV uploaded, anomaly detection metriche business, pre-processing dataset per ML, audit qualità dati post-import legacy.

Agent LLM (Liara/Anthropic) che produce un summary strutturato 3-tier: TL;DR (1 frase), 5 bullet point, paragrafo (~150 word). Preserva named entities (people/orgs/dates/amounts/tech terms) verbatim — no parafrasi. Output JSON typed. Use case: digest email lunghe, riassunto articoli RSS per newsletter, brief meeting notes, abstract documenti legali/PDF. Token budget controllato. Compatibile output→input chain per filter/route downstream.

Agent LLM translator professionale: traduce input nella lingua target (config.targetLanguage IT/EN/DE/FR/ES/PT/...). Preserva markdown, code blocks, URL, named entities, tone (formal/informal). Input misto-lingua → traduce solo source language. Output text plain (no JSON wrapper). Engine sceglie modello cheaper per token budget. Use case: i18n contenuti email/website, traduzione ticket support multi-lingua, localizzazione descrizioni prodotto, traduzione documenti legali (con disclaimer).

Agent LLM classifier: assegna l'input a una delle label custom (config.labels). Output: { label, confidence 0-1, alternatives[] }. Se nessuna label matcha → fallback "other" con score basso. Confidence usable in if/switch downstream per threshold gating. Use case: triage email (lead/support/spam/ordine), classificazione ticket per team, routing per categoria prodotto e-commerce, content moderation pre-pubblicazione, tagging automatico documenti per archivio.

Agent LLM entity extractor: dato testo non strutturato + JSON schema (config.schema), estrae fields conformi. Campi mancanti → null. Campi multi-value → array. Output JSON typed direttamente usabile downstream. Use case: parse email ordine (importo/cliente/sku/qty), estrazione anagrafica da CV, invoice extraction (numero/data/importo/IVA/righe), contatti da firma email, parametri da messaggio chat (date/luoghi/persone) per scheduling/CRM.

Agent LLM intent router per workflow customer-facing: classifica user message contro lista intents (config.intents), output { intent, confidence, reasoning }. Se nessun match → "fallback". Pair with logic_switch downstream: ogni intent diventa una branch separata del workflow. Use case: chatbot multi-intent (order/refund/info/cancel → 4 rami), routing email per dipartimento, voice assistant action dispatcher, ticket support priority/category auto-tag.

Estrai dati strutturati da HTML descrivendo in linguaggio naturale cosa vuoi (NO selettori CSS). L'AI legge il DOM + l'instruction → ritorna JSON conforme allo schema specificato. Top 2026: scraping AI-powered che resiste a cambi di layout (selettori CSS si rompono, l'AI no).

Genera selettori CSS/XPath automaticamente da 1-2 esempi label-value. Tu fornisci HTML + esempi tipo {"price": "€42.50"} → l'AI genera selettori robusti che catturano gli stessi valori. Output usabile direttamente in action_html_select. Self-healing scraping (rigenera quando il sito cambia).

Validate structured input against JSON Schema + business rules. Returns valid/errors/normalized. Top 2026: schema, custom rules, strict mode, error path, normalize-on-fix.

Agente con tool-calling nativo Anthropic Claude. Cicla finché il modello non risponde senza richiedere altri tool. Tool disponibili: http_request, flowforge_invoke, get_time, rag_search.

Leggi e invia email via Gmail con OAuth 2.0. Filtra per query Gmail (label, sender, unread), supporta allegati fino a 25MB, MIME parsing automatico, auto-refresh dei token entro 5 minuti dalla scadenza.

Invia messaggi via WhatsApp Business Cloud API (Meta Graph v19+). Template approvati per outbound, free-form solo entro la finestra 24h dalla risposta utente. Media supportati (image, document, audio, video).

Crea checkout sessions, fatture, retrieve payment intent, lista subscriptions via Stripe API. Idempotency keys derivate da runId:nodeId:action per safe retry. Listener webhook eventi separato (in arrivo).

Upload, download, list file con OAuth Google. Scope drive.file (solo file creati dall'app — privacy-friendly). Crea cartelle, condividi file, multipart upload fino a 5MB. Resumable upload per file più grandi in arrivo.

Estrae testo da immagini e PDF scansionati usando Tesseract.js (pure JS, no native binary, no API key). Lingue: italiano + inglese di default, configurabile. Output con bounding boxes, confidence score per blocco, threshold filter.