ChatRunStatusResponse = { runId, status } to match the implemented endpoint (chat#1813)
Follow-up to docs#249: reconcile the documented GET /api/chat/runs/{runId} response with the api implementation (api#704).
What
ChatRunStatusResponse → { runId, status } (dropped chatId / sessionId / startedAt / completedAt / error).
Why
The endpoint wraps the durable workflow's getRun(runId).status, which exposes only status. There is no durable runId → chat mapping today, and the caller already receives chatId / sessionId in the 202 start response — so echoing them on status is redundant. Returning { runId, status } is the cheap, correct "is it done?" contract.
A future chats.last_run_id column would let the status endpoint also return chatId/sessionId and enforce per-run ownership — a separate database+api follow-up if needed.
Verified
The status enum (queued | running | completed | failed | cancelled) is confirmed against real preview runs — observed running then completed end-to-end.
🤖 Generated with Claude Code
Summary by cubic
Aligned GET /api/chat/runs/{runId} docs with the implemented API: ChatRunStatusResponse now returns only { runId, status }.
Removed chatId, sessionId, startedAt, completedAt, and error; use the chatId from the 202 start response to fetch produced content.