Delivery note / proof
The review card is the proof: headline, how to check, and what changed. Preview sits next to it.
A Request cannot sit in Review without a preview link and a complete delivery note. That note is the proof the owner checks, not a dump of developer commentary. The worker (or a developer) attaches it when they ask for review.
What the card shows
Headline
One short line for what is now true. Owners see it on the Review this change card. Keep it to a sentence, not a changelog.
How to check
A short list of steps. This stays visible on the card so the owner can try the preview without guessing. Two to six lines.
What changed
A few lines behind Show details. Always collapsed for owners. Two to four lines. Developer-only notes never land on this card.
What has to be complete
- A preview link.
- A headline.
- How to check (at least two steps).
- What changed (at least two lines).
The product rejects an over-long dump. If review is blocked, the delivery is incomplete, not a mystery status.
Looks good and Needs changes
- Open preview and follow How to check.
- If it is right, choose Looks good. That accepts the preview. It is not live yet.
- If it is wrong, choose Needs changes, write a short message, and Submit changes. Status goes back to Needs a reply.
Example delivery
Headline: "The contact form sends again." How to check: open Contact and send a test note; confirm the thank you line appears. What changed: submit on Contact now goes through; the thank you line shows after send.
Who writes the note
A worker or a developer attaches delivery next to the preview link. Owners do not fill this form. They only review it. Internal developer notes stay off the owner-shaped thread.