Technical proof: a delivery where the sensor rejected what looked done

This case is born from a technical proof, not a client: it demonstrates how TriageCode behaves when “done” is submitted to a mechanical arbiter.

The reproducible scenario

A story claimed to deliver validation for a lead form with the fields name, email and message. The code compiled, the screen rendered and whoever implemented it was sure they had finished. The story’s “Done When” listed an integration-test sensor that exercised submission with an invalid email.

What the sensor found

When the command ran, the exit code came back non-zero: the invalid-email path accepted the submission instead of rejecting it. No discussion about “whether it’s good enough” — the story went back to IN_PROGRESS with the output of the failed sensor, and nothing else.

The correction loop

Whoever implemented received only the sensor output, without the “opinion” of whoever validated. They adjusted the validation, ran dev-baseline locally, and submitted again. On the second pass, all the “Done When” sensors returned success and only then was the story marked complete.

The evidence that remains

The value of the case isn’t the fix itself — it’s that the error was caught by a command, not by luck or by a tired-eyed review. “Done” meant the same thing for whoever implemented and whoever validated, because it was the same check for both.