## Problem FlowDrop's workflow language defines what a loop *does* — when it re-enters, what the loopback port means, what breaks it — but never what a loop *is*. There is no definition, in the spec or in the code, of which nodes belong to a given loop. Searching `modules/` for a membership computation returns nothing: no cycle detection, no strongly-connected-component pass, no membership set, no loop object. The phrase "loop body" appears only in port descriptions, docblocks and authoring help — text that tells a human author where to wire, not something the engine can act on. Membership is emergent at runtime instead. `StateGraphOrchestrator::shouldFollowLoopbackEdge()` (`:1890`) decides re-dispatch from the iterator state or from a per-node counter; the loop is discovered one step at a time and is never known as a whole. ## What the spec defines, and what it does not `SG-4`, `SG-5`, `SG-7`, `SG-9`, `SG-10`, `SG-14` and `ORC-10` all specify loop **behaviour**: initialisation, loopback port semantics, re-entry conditions, `data.condition` on loopback edges, iteration budgets, termination. None of them specifies loop **extent**. ## The consequence that matters Because extent is undefined, two very different inputs are indistinguishable in job metadata: 1. a node **outside** the loop, produced once and read every iteration — a config, reference or style-guide input; 2. a node **inside** the loop at iteration 0 — the original job, not yet a clone. Neither carries `is_loop_iteration` and neither carries `loop_iteration`. Only clones get those, stamped in `createLoopIterationJob()` (`:1235-1238`). Absence therefore means both "not in a loop" and "in a loop, first time round". That is why `logCrossIterationDataRead()` (`JobGenerationService.php:1202-1215`) has to treat an absent `loop_iteration` as `0`. It is also the concrete reason a readiness barrier looks impossible: a gate that waits for "a source job from my own iteration" cannot distinguish an input that will never re-fire (wait forever) from one that is inside the loop and simply has not re-fired yet (the case worth waiting for). ## Three symptoms already in the tree **1. Data-edge staleness cannot be gated — #3592390.** `BR-6` (`docs/development/specification-registry.md:607`) declines the barrier on the grounds that "making staleness universal would deadlock every loop". On the above, that deadlock is not a scheduling constraint — it is a direct consequence of the missing definition. The rule currently reads as a design decision, but it is better described as an accurate report of what is achievable without a loop object. **2. The iteration budget is per-node, not per-loop.** `shouldFollowLoopbackEdge()` compares `$nodeIterationCounts[$targetNodeId]` against `maxIterations` (`:1903`), with the map keyed by node id. `max_iterations: 100` over a five-node body is therefore five independent counters, not a loop that runs 100 times. There is no loop for a budget to attach to. **3. Nested loops are unmodelled.** One passing docblock reference ("the max-iterations guard on the outer loop is the final safety net") and nothing else — no rule, no representation. `loop_iteration` is a flat integer, so an inner round and an outer round have no way to be told apart. ## Proposed resolution Give a loop a defined extent, computed once and snapshotted: - Determine, at pipeline generation, the set of nodes on the cycle reachable from each loopback edge, and record it. Snapshotting matches the existing precedent in `declaredBranchesFor()` — a workflow edited mid-run must not change how an in-flight pipeline behaves. - Stamp every job with which loop it belongs to and which round, **including round 0**, so "inside this loop" and "outside it" become recorded facts rather than inferences drawn from absent metadata. - Add a registry rule stating the extent definition, alongside the existing behaviour rules. ## Why this is filed separately from #3592390 The definition is worth having whether or not the staleness barrier is ever built: it is what the iteration budget should attach to, and it is where nesting would live. It also changes #3592390 from a debate about `BR-6` into a dependent piece of work — the barrier becomes expressible, and can then be accepted or declined on its own merits rather than because the engine has no way to ask the question. ## Remaining tasks - Decide the representation: a per-loop id plus membership set on the pipeline, per-job stamps, or both. - Compute extent at generation and snapshot it. - Stamp round 0, not only clones. - Add the registry rule for extent, and revisit `BR-6`'s deadlock clause once extent exists. - Decide whether the iteration budget moves to the loop — a behaviour change, needs a release note. - Decide the nested-loop representation, or explicitly declare nesting unsupported. ## Notes Found while reviewing #3592390. Related prior art on the same underlying invariant — *per-execution identity must not cross a round boundary* — is the loop-clone hygiene and resume-ownership work in `createLoopIterationJob()` and `NodeRuntimeService::resolveResumeInterrupt()`, which solved it on the interrupt plane. That fix is what introduced the lineage stamping this issue proposes making complete and authoritative.