Found by the motir run of MOTIR-2888 on 2026-08-17, while writing MOTIR-2894's integration cases. The correction is already applied — 2894's body was amended on the record — so this holds nothing up.
MOTIR-2894 case 3 specified the expected sequence:
The in-review rung both ways: children
{ done, in_review }⇒in_review; adding atodochild ⇒todo; that child toin_progress⇒in_progress.
The middle step is false, and the story that defines the rule says so three cards earlier. in_review is an in_progress-CATEGORY status (lib/workflows/defaultWorkflow.ts:27; the ADR's §3 note "in_review shares the in_progress CATEGORY"). So with children { done, in_review, todo }, rung 3 — "≥ 1 child is in an in_progress-category status" — matches, and first-match-wins never reaches rung 4. Rung 4's own condition, quoted in MOTIR-2888's body, is "≥ 1 child in a todo-category status and none started", which a sibling sitting in review falsifies.
The real behaviour: adding an unstarted child to an in-review parent pulls it back one rung to in_progress — correct, and arguably the more interesting case, because it shows the recompute is a ladder position and not a binary.
As a red test, on the second attempt, costing two debug cycles. The card was written as the spec, so the first instinct was that the SERVICE was wrong — the ladder was re-read before the card was. It is only cheap to catch here because MOTIR-2888 carries the rung table in its own body; a card written against a rule that lived only in an ADR would have been argued about for longer.
A card's WORKED EXAMPLE is derived content, and it is not checked by anything. The rung table was correct in three places (the ADR amendment, the story body, the service card) and wrong in the fourth, because that fourth was the only one that instantiated it into concrete values. Prose restating a rule gets re-read against the rule; a sequence of expected values reads as ground truth and gets copied into an assertion.
How to apply — when a card enumerates expected VALUES for a rule stated elsewhere, evaluate the rule against each one at authoring time, in particular wherever the rule's clauses turn on a CATEGORY rather than a key (in_review ∈ in_progress, cancelled ∈ done, blocked ∈ todo). Those are exactly the steps where a plausible-reading example diverges from the predicate. A worked example that disagrees with its own rule is worse than no example, because it is what the test asserts.
tests/integration/workflows/statusDerivation.test.ts.