@esfaenza/flow-builder 20.3.2 → 20.3.3

package/README.md

@@ -202,6 +202,15 @@ qualsiasi.
 dalla mappa delle uscite invece di essere «ramo di errore» per tutti: su uno stage di
 orchestrazione quel ramo e' lo **step rifiutato**, non un guasto.
 
+Un tipo con un **discriminatore** compare come piu' voci, una per valore: il Collection
+Processor e' «Ordina» e «Filtra», non «ordina o filtra». Sono due gesti diversi — un `Sort`
+vuole `sortOptions`, un `Filter` vuole condizioni (§5.5) — e sceglierli dalla palette evita di
+sceglierli dopo, dentro il form. L'elemento nasce con il discriminatore già scritto, con la
+label della variante (da cui viene anche il nome tecnico) e con il glifo della variante, lo
+stesso che avra' sul canvas. `core/element-variants.ts` tiene la mappa tipo → campo del
+discriminatore; i valori restano nel dizionario del backend (`collectionProcessorTypes`), e
+senza quel dizionario il tipo torna a essere una voce sola.
+
 **Inspector.** Un form per ogni tipo supportato: Start, Screen, Assignment, Decision, Loop,
 Collection Processor, Get / Create / Update / Delete / Rollback Records, Action, Script,
 Subflow, Wait, Custom Error, Transform, Orchestrated Stage. Più l'intestazione comune con la
@@ -230,14 +239,21 @@ nome fuori catalogo viene segnalato subito, prima che il backend risponda `OBJEC
 aggiornabile" sono errori diversi. Restano `<select>` i dizionari chiusi — tipi di dato,
 operatori, enumerazioni — dove non c'e' niente da scrivere a mano.
 
-Lo stesso controllo, nella variante `<fb-name-picker>`, vale per i nomi che dipendono dal
-contesto e non da un catalogo di schema: il flow di uno step in background e dei suoi
-evaluation flow, il flow invocato da un Subflow, le variabili di input e output **del flow
-invocato**. Qui l'elenco arriva da chi ospita il picker (`listSubflowCandidates`, le variabili
-della definizione caricata), e un elenco vuoto resta "non lo so": il campo si scrive a mano e
-non si accusa nessun nome. Con l'elenco popolato, invece, un nome che non c'e' e' segnalato —
-ed e' la differenza rispetto al `datalist` che questi campi usavano prima, che accettava
-qualunque cosa in silenzio.
+Lo stesso controllo, nella variante `<fb-name-picker>`, vale per **ogni altro nome che il flow
+prende da fuori**: tipo di action e action, script, form, i nomi dei loro parametri di ingresso
+e di uscita, il flow di uno step in background e dei suoi evaluation flow, il flow invocato da
+un Subflow e le variabili di input e output **del flow invocato**. Qui l'elenco arriva da chi
+ospita il picker — il catalogo già caricato per altri motivi, `listSubflowCandidates`, le
+variabili della definizione caricata — perche' dipende dal contesto: le action dipendono dal
+tipo scelto, i parametri dall'action, le variabili dal subflow.
+
+Un elenco vuoto resta "non lo so": il campo si scrive a mano e non si accusa nessun nome. Con
+l'elenco popolato, un nome che non c'e' e' segnalato, e con la **gravita' giusta**: un'action,
+un form, uno script o un parametro inesistenti sono errori che bloccano l'attivazione
+(`ACTION_UNKNOWN`, `FORM_UNKNOWN`, `PARAMETER_UNKNOWN`) e si mostrano in rosso; un flow senza
+versione attiva e' un avviso. Prima questi campi erano `<select>` con un'opzione sintetica
+«(non nel catalogo)» per non perdere il valore, oppure un `datalist` che accettava qualunque
+cosa in silenzio: il primo non si poteva cercare, il secondo non diceva niente.
 
 **Problemi.** Pannello con filtro per gravita', navigazione all'elemento con un clic,
 validazione su pausa di digitazione (debounce 400 ms) e l'avvertenza che l'assenza di rilievi