The caller's approved writes, newest first, each with its outcome.

"My actions" (G-APPROVEOUT): every gated write of every copilot leaves a tool_confirmations row, so this is the one place that can answer "what did I do, and did it work?" — jobs are one kind of outcome, and most writes (queue, attach, remove) never dispatch one. Owner-scoped in the query, same contract as GET /{id}. A card the person cancelled is listed too (state "rejected"): with several decided at once from the rail (G-RAILDECIDE), a wrong reject has to be findable. A card the agent withdrew is not — the person decided nothing.

since (job result notice): only rows that CHANGED after it — decided after it, or whose job moved after it — plus notices, the conversation lines written after it. The browser's one watcher polls with it, so a poll costs the rows that moved, not the whole list. server_time is the clock the next since should use: this server's, not the browser's.

since is read as SINCE_OVERLAP earlier than it is given. A row's timestamp (created_at, resolved_at, last_polled_at) is the START of the transaction that wrote it, and server_time is this process's clock at the read: a row whose transaction began before server_time can commit after it, and a plain > since would never return it. The overlap makes the next poll return it. The same row can therefore come back in two polls: the consumer MUST dedupe by id (a row of actions and a notice each carry one).