FlowDrop Workflow Specification 1.0-draft

An edge leaving a terminal node warns

A terminal node ends the run, so nothing downstream of it will execute. The edge is legal (the author may be mid-edit), but it is almost certainly not what they meant.

The rule

Normative: this is the rule
  1. Every edge whose source node is a terminal node yields one non-blocking warning at edge.{index}, naming the terminal source and the target it leads to.
  2. A terminal node with several outgoing edges therefore produces one warning per edge, and the workflow stays valid.
  3. Only sources are inspected, so a workflow with no edges looks nothing up, and the target's existence is not checked here: an edge from a terminal node to a deleted node produces both this warning and R8's missing-target error.
  4. An edge whose source is itself dangling produces no warning; R8 owns that.

What it means

The count is per edge, not per terminal node: a terminal node with several outgoing edges earns one warning for each of them, not one warning naming the node once. None of them blocks the save — the workflow stays valid, because the author may simply be mid-edit — and the check only ever looks at an edge's source. A dangling source produces no warning here at all; that belongs to R8.

Example

A terminal node wired to two other nodes:

Edges leaving the same terminal nodechecked
[
  { "id": "e1", "source": "stop1", "target": "after1" },
  { "id": "e2", "source": "stop1", "target": "after2" }
]
The locators of the two warnings this producesone each
["edge.0", "edge.1"]

The workflow is still reported valid; a save of it would go through with every one of these warnings attached.

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · W-T · changed in spec 1.0