Twenty-eight features. None is shipped.
Credits work. Refunds reverse. The console is live and the mailing list takes
subscriptions. All of it is serving real traffic, and all of it is marked
building.
What shipped requires
The definition of done is enforced by the gate, not by a convention:
PAC-900 shipped feature has no links.prs
PAC-901 shipped feature has no links.code
PAC-902 acceptance criterion's test ref does not resolve
PAC-903 shipped feature has no deployment manifest
PAC-904 shipped feature has no monitor probe
The last one is the one that bites. PAC-904 requires a monitor: label that
resolves to a named probe in scripts/check_endpoints.py. Not a promise to
monitor it — a probe that exists, with that name, that something runs.
Why the monitor and not the deploy
Deployed and working are different claims, and the second is not observable from the first.
We know this specifically. A deploy reported success, the files were on the server, and the site served the previous build for a day — a bind mount follows the inode, and renaming the directory left Caddy holding the old one. Every container healthy, every check green, wrong content.
If shipped meant "deployed", that feature would have been marked shipped and
been wrong, and the marking would have been the last time anybody looked.
shipped therefore means: somebody will find out if this stops working
without a person noticing. That is a stronger claim than "it is running", and
it is the claim that matters when you are deciding whether to build the next
thing on top of it.
The uncomfortable consequence
It means the roadmap looks less finished than the product is. Somebody reading
/product sees twenty-eight features in progress and nothing done, which
undersells the state of things.
We keep it, because the alternative is a status field that means "we think this is fine", and every project has one of those. It stops being information approximately immediately — the moment marking something done is a judgement call, the field records optimism rather than state.
A gate that can refuse the label is what makes the label worth reading.
What it does to sequencing
It changes the order you build in, and this is the practical effect rather than the philosophical one.
The obvious sequence is: build the feature, deploy it, add monitoring later when
there is time. PAC-904 makes "later" the thing standing between you and being
able to say the feature is done — so the probe gets written while the feature is
still fresh, by the person who knows what its failure looks like.
That person is also the only one who knows the interesting failure. The uptime check for routing does not assert that the service responds; it asserts that a money-path request still eliminates the vendor model on residency. Anyone can write the first. Only somebody who just built the residency filter thinks to write the second.
The one that would fail today
site-analytics is deployed and counting. It has no probe.
So it is building, and will stay building until something checks that the
counter is still counting — which is a real gap, because an analytics endpoint
that silently stops recording looks exactly like a site nobody is visiting.
That is a useful thing for a status field to be telling us, and it is only telling us because it is not allowed to say otherwise.