The starting point
A task is finished. Doing it, you found a workaround, a constraint, or a question that deserves a follow-up.
The update says only: “Done.”
The move
Ship the task, and report what doing it taught you. If the discovery calls the requested work into question, say so before carrying on.
Why it works
Whoever does the work sees what the framing could not. In support, a request comes back after every refund. In a sales team, three customers read the same offer three different ways. In engineering, the fix touches a part nobody planned for. That information exists only with you, and only while it is fresh.
You are asked to fix how a form displays on mobile. Checking, you see that some sign-ups also fail after submission. “Done” is true. It is also the sentence that leaves the real problem in place. And if reporting a find reads as refusing the task, nobody reports one again.
Separate the fact you observed, what you make of it, and the follow-up you propose. That is what sets a builder apart from someone who just executes: they ship the task, and they ship what it revealed.
If carrying on wastes effort or causes damage, stop and say so. Otherwise, finish what was planned and propose what comes next.
Try this
Before you close a task, add two lines to the update:
What I saw doing it: …
What that changes, or what needs checking: …
Propose a follow-up and name who can take it. At the next review, check whether the observation changed a decision.
To discuss
Which recent observation changed how we handle a task?