A run waiting on you is not a hung run

Ninety seconds into every hand-off, our plan card asked the client "On it, stalled?" The teammate the work had gone to was busy the whole time.

The card judged whether work was moving from the main run's heartbeat. A run that hands a step to a teammate stops beating on purpose, because it is waiting for that teammate. So a working team looked like a frozen one, at exactly the moment the product was doing what it should.

7

Quiet has more than one meaning

We stopped asking whether a run is beating and started asking why it is quiet. A run now reports one of seven states: working, waiting on a teammate, waiting on a build, waiting on you, waiting, stopping, or stalled. Only a wait that has run past its own deadline reads as stalled. Everything else says what it is waiting for.

That is the core of the Work Card, which we shipped on 14 September. Each plan a person approves gets one card with a headline from a fixed vocabulary, a clock, the steps, and each hand-off drawn inside the step it belongs to. It is rolling out to client workspaces behind a switch.

Then our own test made the same mistake

To prove the card on production, we wrote a test that sends a real request, lets the team build a slide deck, and reads the card as the work moves.

The deck came back complete. The build reached ready and passed 39 of 39 checks. Then the test waited eight minutes for the run to finish, timed out, and skipped the five checks after it. It reported the product as broken.

The run was not stuck. One step needed a decision only the person could make, so the run stopped, asked, and parked itself to wait for the answer. That is the behaviour we had just shipped. Before it, the same step was refused and the model guessed.

Our test polled for runs that were still running, and a run waiting on a person counts as running. The product was right and the proof was wrong. The test now finishes when a run settles or when it is asking someone. It prints the question and skips the checks that depend on the answer by name, not by timeout.

We read the live card while diagnosing it. It said "Waiting on you", marked the second of five steps "Needs you", drew the hand-off inside its step, and showed no "stalled?" anywhere on the page.

A proof can pass while the product is broken

Two review passes over that test found five ways it could have passed on a broken product. The stall check scanned only the headline, and the headline can never contain a stall word. A hand-off drawn nowhere scored as clean, because the check only failed on a hand-off drawn twice. One step could never run at all, while the file's header said it did. Each is fixed. Where the test cannot prove something now, it says so instead of going green.

The rule we kept: when a change lets a run stop and wait for a person, every check that waits for "done" learns the new state in the same release.

What to ask any vendor

When your system goes quiet, how does it tell working from stuck? What does a run look like while it waits for a person, and does anything page someone by mistake? Can your end-to-end test fail, and have you watched it fail?

Good answers come with a demo. The insights are free. If you want this level of engineering pointed at your operation, start with the free audit. The plan is yours to keep either way.