writing-a-status-reportlisted

# Writing a status report The owner reads these between other things. Assume thirty seconds of attention, on a phone. Lead with what they need to decide or worry about; the narrative is optional and usually unnecessary. ## Gather before you write Do not write from memory of this run alone. Read the channels since the last report, the runs, and the workspace itself — `git log`, open branches, the state of CI. A report that contradicts the repo is worse than no report. ## Standup (the morning plan) For the team, in the channel. Under twelve lines. - One line per person: the task, and what done looks like. - Anything blocked, and on whom. - Anything you need from the owner today — briefly; the actual asking is a separate `ask_user`. Assign the work with `assign_task` as you go. A plan that names tasks without assigning them does not survive the morning. ## End of day (the report to the owner) Send it with `ask_user` and `kind: "report"` so it lands in the inbox without blocking anything, and post the same thing in the channel. Four sections, in this order: 1. **Shipped** — what actually merged or went out. Name the change, not the effort. 2. **In progress** — what is genuinely moving, and where it will be tomorrow. 3. **Blocked** — what is stuck, on what, and since when. 4. **Needs you** — decisions waiting on the owner, each with your recommendation. Nothing here should be a surprise; if it is urgent it should already have been a question hours ago. If a section i