a success status that lied

A venue's public page needed a small configuration payload — name, tagline, hours, delivery parameters — served as structured data. The route was added and did not work. It did not fail either. The static file handler had a catch-all that returned the page shell for anything not otherwise matched, so the configuration request came back with a success status and a body of markup. The client parsed it, failed, and kept the hardcoded demonstration defaults it had shipped with. The footer and delivery bar were simply wrong, and nothing anywhere reported an error until a manual quality pass read the contract instead of the screen.

The fix was partly ordering — the configuration route now sits ahead of the fallback — and partly a contract. The response has an exact shape, absence has defined defaults, a count that is unknown is omitted rather than invented so the interface hides the chip instead of displaying a fabricated number, and the tests assert the wire shape itself, not merely that a route exists. A genuinely missing path still falls back to the shell, deliberately.

The class matters because it is the mirror of a worse one flagged elsewhere in the same review: failure bodies that recited the database's own message back to the caller. One surface tells the outside world more than it should; the other tells it something false; both leave an operator with no signal. The invariant is narrower than either. A response body is part of the trust boundary, and it must be neither a confession nor a lie.

What it proves: this team can be caught by a silent fallback and can convert the catch into a contract rather than a patch.