A parent lands with its children

A route breaks one item into nodes, and the item lands when its nodes have. An epic is different: it is broken into child items already, each with its own sled, its own band and its own route. Until now nothing stopped an epic from getting a route of its own as well.

When it did, two things went wrong. The epic's route repeated work its children were already doing, and it never closed them. And when the epic's own nodes landed, the epic landed with them. QW-5408 landed that way with six children still open, and its actual said the work was done when most of it was not.

A parent waits for its children

An item no longer lands while any of its children is open, whatever its route says. A child counts as open until it lands. An archived child is left out.

When the last node on such an item lands, the route says what it is waiting for, by key: Every node landed — Nothing is left to run on the route, but the item stays open until its children land: QW-5410, QW-5411. A seat reading the route over MCP gets the same line. A person can still land the item on purpose with actual.

An item with children gets no route

The children are the parent's nodes, so a route on the parent is one route too many. route now refuses to file or propose nodes on an item that has children, and says so in one line:

this item has children; set the order with blockedBy on them

The order between children lives in one place: each child's blockedBy. A child is ready when every item it is blocked by has landed, and each child gets its own route when it needs one. The engine already skips drafting a route for an item with children, so under Auto nothing changes there.

Why it matters

A band is only as good as the actual that lands against it. A parent that lands early writes an actual for work that is still running, the sled looks lighter than it is, and the next estimate learns from the wrong number. A parent that lands with its children lands once, when the work is done.