flujo-ai 3.22.0 → 3.23.0

package/.next/server/chunks/5708.js

@@ -37,11 +37,15 @@ NODE TYPES:
     "errorStrategy": "collect-all" | "fail-fast",   // optional (parallel / mapOverList), default collect-all
     "inputMode": "full-history" | "latest-message" | "isolated",
     "allowCallerPrompt": true | false,             // optional, only with inputMode "isolated"; when true a routing step may pass a "prompt" via its handoff tool that overrides the subflow's "prompt" (default)
+    "allowCallerFanout": true | false,             // optional (subflow); when true a routing step may pass a "parallelFlows" array (+ optional "concurrencyLimit") via its handoff tool to CHOOSE the parallel fan-out set at runtime (rule 7c)
     "captureVariable": "NAME",                     // optional; save the subflow's output into a run variable other steps inject with \${var:NAME}
     "captureResource": "NAME",                     // optional; ALSO save the subflow's output as a tracked run resource (\${res:NAME}, rule 9b)
     "captureKv": "NAME",                           // optional; ALSO save the subflow's output to a PERSISTENT cross-run key (\${kv:NAME}, rule 9d)
     "outputMode": "steps" | "final-only" }
 - { "key": "...", "type": "finish", "label": "..." }
+- { "key": "...", "type": "signal", "label": "...",                // fire-and-forget event (rule 11): emits {topic, payload} then passes through unchanged
+    "topic": "<event topic other flows' triggers listen for>",     // REQUIRED — a signal with no topic emits nothing
+    "payloadTemplate": "event body, may use \${var:NAME}" }         // optional; defaults to the node prompt
 - { "key": "...", "type": "resource", "label": "...",              // OPTIONAL/advanced (rule 9c): a data artifact shown in the graph
     "server": "<server name>", "uri": "<resource uri>",            // EITHER a static MCP resource…
     "runName": "NAME" }                                            // …OR a run artifact steps produce/consume
@@ -61,9 +65,11 @@ RULES:
 6. A subflow node may have only ONE outgoing edge. Give it EITHER a "flow" (naming an existing flow) OR a "subflowSpec" (an inline nested FlowSpec that becomes its own child flow) — not both. A "subflowSpec" may itself contain subflow nodes with their own "subflowSpec" (bounded nesting), so you can author whole multi-level flows in one object.
 7. A subflow node may instead fan out to SEVERAL child flows CONCURRENTLY via "parallelFlows" (existing flows) or "parallelSubflowSpecs" (inline). These are STATIC (fixed at author time): the same input is sent to every lane and their outputs are joined. This is about multiple CHILDREN, not successors — the single-outgoing-edge rule (rule 6) still holds. Prefer "parallelFlows" for large fan-outs.
 7b. For DYNAMIC fan-out — when the set of target flows should be decided AT RUNTIME by an earlier step — use "parallelFlowsVariable": "NAME". An upstream process/subflow node captures a JSON array of flow ids/names (or a newline list) into run variable NAME via "captureVariable": "NAME"; this subflow node then fans out over exactly those flows. Unknown ids and a self-reference are dropped, the count is capped, and a non-empty resolution overrides any static "parallelFlows" (empty falls back to it). Mutually exclusive with "mapOverList". Still one outgoing edge (rule 6).
+7c. For AGENTIC fan-out — when the ROUTING MODEL itself should decide the parallel set at the very moment it hands off — set "allowCallerFanout": true on the target subflow node. Its handoff tool then exposes an optional "parallelFlows" (array of flow ids/names) argument plus an optional "concurrencyLimit"; the model passes them at call time to fan out over exactly those flows. A non-empty caller set overrides "parallelFlows"/"parallelFlowsVariable"; unknown ids and a self-reference are dropped and the count is capped. Mutually exclusive with "mapOverList". Still one outgoing edge (rule 6). Prefer 7b's "parallelFlowsVariable" when an EARLIER step computes the set; use 7c when the DECIDING (routing) step is the one that chooses it.
 8. A subflow node may instead run its SINGLE child flow ONCE PER ITEM via "mapOverList": true. The input is split into items by "itemSplit" ("json-array" default, or "lines"), each item is sent to its own child run, and the per-item outputs are joined (same pool/tuning as parallel). Use "sequential": true to run items in order. Mutually exclusive with "parallelFlows"/"parallelSubflowSpecs".
 9. Named variables (scratchpad): a step can save its output with "captureVariable": "NAME" (process or subflow) and any LATER step injects it with \${var:NAME} inside its "prompt" / "isolatedPrompt" / subflow prompt. This survives "latest-message"/"isolated" scoping, unlike conversation history — use it to carry a todo list, a file path, a diff, or a captured result across steps that don't share history. \${var:NAME} is run-scoped and plaintext; it is DISTINCT from \${global:VAR} (configured secrets/config, resolved only for tool args). Capture a subflow's output on the PARENT subflow node — a variable set inside a child flow is not visible to the parent.
 9b. Run resources (tracked data): "captureResource": "NAME" (process or subflow) ALSO saves the step's output as a run-scoped RESOURCE — an addressable artifact (flujo://run/... URI) with lineage (which step produced it, which steps read it), readable via the built-in "flujo" MCP server. A later step injects it with \${res:NAME} exactly like \${var:NAME}. Prefer "captureVariable" for short strings; use "captureResource" when the output is a large document/report/dataset worth tracking, or when other tools/agents should be able to read it back. Large or binary MCP tool results (screenshots, files) are auto-captured as run resources without any spec field.
 9c. Resource nodes are OPTIONAL/advanced — most flows should not use them; prefer rule 9b's captureResource/\${res:NAME}. Emit one only when the data artifact itself should be VISIBLE in the graph: an edge resource→process means the step READS the artifact (its contents are injected into the step's context); process→resource means the step's output is SAVED to it (run artifacts only, equivalent to captureResource with the node's runName). Resource edges are data wiring, not flow control — they never carry conditions and don't count as a step's successor.
 9d. Persistent state (cross-run): "captureKv": "NAME" (process or subflow) saves the step's output to a PERSISTENT key-value store that SURVIVES ACROSS RUNS, injected by any step with \${kv:NAME}. Unlike \${var:} / \${res:} (discarded when the run ends), \${kv:} is what a long-lived SCHEDULED flow uses to carry a loop counter, a pagination cursor, a last-seen id, or a flag to its NEXT run. By default a key lives on the flow's FOLDER board (flows in the same folder share it); prefix the name to change scope: "flow/NAME" (this flow only) or "global/NAME" (whole instance). Plaintext, never secrets (distinct from \${global:VAR}). A model can also read/update a key mid-run via the built-in "flujo" server's kv_get / kv_set tools.
-10. Keep flows minimal — only the steps the task needs. Write clear, specific prompts and labels; fill "description" on process nodes.`}};
+10. Keep flows minimal — only the steps the task needs. Write clear, specific prompts and labels; fill "description" on process nodes.
+11. Signals (fire-and-forget events): a "signal" node is a deterministic pass-through that, when the path reaches it, emits an event {topic, payload} onto the flow-run event bus and then continues to its successor unchanged (it never calls a model or touches the conversation). Use it when the flow should notify or kick off ANOTHER flow mid-run — a flow-event trigger configured elsewhere listens for the same "topic" (e.g. "when the review finds blockers, emit a review-blocked signal"). Always give it a "topic" (a signal with no topic emits nothing); "payloadTemplate" is the optional event body and may inject \${var:NAME}. Make emission conditional by putting a conditioned edge (rule 5b) INTO the signal node.`}};