The unsatisfying handoff
A page is drafted but not reviewed. The writer can say so, with the local link and the questions still open. The user may rightly be disappointed that the public release is not ready. That disappointment does not make a false 'finished' label the better service.
There are two judgments: did the requested outcome happen, and did the worker handle the incomplete state responsibly? The first may be no while the second can still be yes. Collapsing them encourages people and systems to hide the remaining work.
Two standards of success
The PHS claims discipline separates confirmed, inferred, and not checked. The enforcement standard requires receipts for material operations and an explicit account of partial effects and recovery. Its rules reject a success claim based on documentation or a green test alone. Those standards make an honest incomplete handoff operationally useful rather than decorative modesty.
Honesty does not excuse avoidable delay. The worker should complete what can be completed, name the blocker precisely, and preserve files, tests, and ownership so the next step is small and concrete.
Pause here: What useful work is complete, what requested outcome is still missing, and what evidence supports each statement?
Leave a useful next step
Sometimes a partial result has independent value: a draft that helps a reviewer, a verified local page, a repaired form before broader deployment. Sometimes it is unsafe to expose at all. The report should distinguish those cases and avoid turning a work-in-progress into a public promise.
A road unfinished at the river is not a completed journey. A marked, stable path to the river with a clear description of the missing bridge is still far more useful than a sign that says 'arrived' over open water.
My answer: Honest incompleteness is not completion, but it is not automatically a worthless failure. Preserve the partial value and make the remaining step explicit.