2 Commits

Include renames

Author	SHA1	Message	Date
dguiducci	01b8a187b5	feat: let a background task ask the chat that started it, not just the Inbox ... An async sub-agent runs in a session of its own, so the rich per-session events that draw the inline approval card never reach the chat's socket — only the id-only inbox lifecycle ones do. A task blocked on an approval was therefore invisible in the conversation that started it, and the only way to unblock it was to notice the sidebar badge and go to the Inbox. The chat already shows what it handed off. This asks the same question of the pending items: `GET /{source}/inbox` joins them against the sessions of this conversation's running async jobs, so "whose is this" has one answer, in the same place `/{source}/tasks` answers it for a task. The client is left with a list to render, not a correlation to guess. The live path adds no event — the existing `approval_requested` / `clarification_*` broadcasts already reach every socket of the user, and re-reading the endpoint turns a nudge into something renderable and survives a reload for free. The card sits above the task strip rather than in the transcript: the task that is asking may have been started twenty messages ago, and a card that scrolls away is a card that gets missed. One at a time, with a count of what is behind it — a blocked task stays blocked whether or not its card is on screen, so stacking them would trade a readable chat for a queue nobody asked to see. And it closes: the ✕ hides the card without resolving anything, leaving the item in the Inbox, because a panel that cannot be moved takes the chat hostage. `InboxCardsMixin` is the cards and their resolve calls, split out of `InboxMixin` so the chat and the Inbox render the same approval rather than two drifting copies of it; `_afterInboxResolve` is the only thing they disagree on. Elicitations are left out: `PendingElicitationInfo` carries no `session_id`, so there is nothing to attribute one to a task with. Also: an async task's context label said "CronJob:", which sends whoever reads the approval looking on the wrong page — and now says so next to the task's real name.	2026-08-04 21:00:45 +01:00
dguiducci	daaceff6ba	feat: show a conversation its own background tasks, and give it back every outcome ... An `execute_task mode="async"` was invisible from the chat that started it. The only trace was the receipt in the transcript and a row on the Tasks page — which does not say *which* of those rows the assistant just spawned — so "is it still going?" had no answer where the question is asked. Worse, a task that did not simply succeed never came back at all. `run_job` branched on `Ok`/`Err` first and routed by `job.kind` only inside the `Ok` arm, so a failure or a kill left through the `Err` arm's unconditional `hub.notify` — the home source (`/sethome`), worded "Cron job … failed" — while the parent conversation sat waiting for a `task_completed` that would never arrive. The wrong chat, and a wedged one. The fix is a shape, not a branch: one `JobOutcome` classification, then one `match job.kind` delivery site for every ending. An async task now ends in its parent conversation whatever happened to it. The sink has a single channel deliberately — to the model reading it, "it broke" is a result like any other and must not be overlookable — so a failure is delivered as prose, carrying whatever partial output the run produced, which is usually the only clue about why. A cron job keeps the home notification: it belongs to nobody's conversation. Cancellation becomes a third outcome rather than a flavour of failure (`job_runs.status` has always had `'cancelled'` in its CHECK and nothing ever wrote it), classified off the new typed `TurnCancelled` error so nothing keys on a message string. The strip above the composer is the visible half. `ServerEvent::TaskUpdate` announces state to the source of the parent conversation only; the list is `renderTaskStrip` (shared by the desktop copilot and the mobile chat), fed by state on `ChatSession`. Each row links to `#session/{id}` — the page that already shows, live, what a background agent is doing, and without which "a task is running" is a fact you can do nothing with. Stopping is the existing kill endpoint. A finished row clears itself after 20 s (its result is in the conversation by then); a failed one stays until dismissed, and the dismissal is remembered across reloads. `GET /api/{source}/tasks` is what makes the strip survive a browser refresh: the event is a broadcast with no replay, so without a load-time read a reload would empty a chat that still has work running under it. It answers with the running tasks plus failures from the last 30 minutes — the two states a person can still act on. Successes are absent on purpose. Its window compares through `datetime()` on both sides: `completed_at` is RFC 3339 and the cutoff is SQLite-shaped, and `'T' > ' '` would let every same-day row through a window meant to exclude it. Not addressed, and worth doing next: a cron job's result should go where its creator says, not always to the home chat.	2026-08-04 19:13:30 +01:00