feat: restore tab layout + in-flight chunks on browser reopen; agents keep running in background

Implements the 'background-running agents + restore-layout-on-reopen'
feature. Full design and parallel-implementation plan in
`plan-bg-restore.md`; Gemini code review (SHIP verdict, no findings) in
`report.md`.

User-visible behaviors:

  1. Browser-close keeps agents alive. If an agent is mid-stream when
     the browser closes / reloads / loses the network, it continues
     processing on the backend. (This was already the case in code —
     agents run fire-and-forget in app.ts:77-79 — but it was previously
     pointless because the UI never restored the tab to receive the
     output.)
  2. Layout restore on browser reopen. Every tab that existed at the
     time the window was closed is restored, in original `position`
     order, with full persisted message history. Tabs whose agents
     finished while disconnected appear with the completed message.
     Tabs whose agents are still running appear streaming live — the
     in-flight assistant message is reconstructed from the backend's
     in-memory `currentChunks` (sent over the wire on connect) and
     accumulates new deltas as they arrive.
  3. Explicit tab-close cancels + forgets. Clicking the X still
     cancels the agent (existing `stopTab` in DELETE /tabs/:id) and
     archives the row (`is_open = 0`), so it is not restored. No
     change to that path.

The gap that the implementation closes: previously, App.svelte:onMount
unconditionally called `createNewTab()` with a fresh UUID, ignoring
every existing row in the `tabs` table. Every browser open was a
clean slate. The DB had the conversation history but no way for the
UI to discover it.

Implementation:

  • New `TabStatusSnapshot` interface in
    packages/core/src/types/index.ts (auto-exported via existing
    `export * from "./types"`):
        interface TabStatusSnapshot {
            status: AgentStatus;
            currentChunks?: Chunk[];          // present iff running
            currentAssistantId?: string;      // present iff running
        }
  • `agent-manager.ts:getAllStatuses()` rewritten to return
    `Record<string, TabStatusSnapshot>` (was
    `Record<string, AgentStatus>`). For running tabs only, attaches a
    defensive shallow copy of `tabAgent.currentChunks` (the live
    streaming array the per-message loop appends to) plus the DB id
    of the in-flight assistant message. The defensive copy is the
    consumer's to mutate. Idle / error tabs get `{ status }` only.
    `GET /status` and the WS `onOpen` snapshot both pick up the new
    shape automatically — neither call site changed.
  • Frontend mirror of `TabStatusSnapshot` in
    packages/frontend/src/lib/types.ts; `AgentEvent.statuses` variant
    updated to use `Record<string, TabStatusSnapshot>`.
  • New `hydrateFromBackend()` on the tab store
    (packages/frontend/src/lib/tabs.svelte.ts). Sequence on app
    mount:
        1. Bail with 0 if `tabs.length > 0` (hot-reload idempotency).
        2. GET /tabs           → list of `is_open=1` rows in
                                  `position` order.
        3. GET /status         → in-flight TabStatusSnapshot map.
        4. GET /tabs/:id/messages for each tab in parallel via
           Promise.all → persisted ChatMessage[].
        5. Build the Tab objects, splicing the snapshot's live
           chunks into the in-flight assistant message for every
           running tab (two paths: merge into the existing DB row
           with matching id, or append a fresh in-flight message
           if no row matches).
        6. `tabs = restored; activeTabId = restored[0]?.id ?? null;`
    Every fetch is wrapped in try/catch so one tab's failure can't
    destroy the whole restore pass.
  • WS `statuses` handler in `tabs.svelte.ts:handleEvent` rewritten
    for the new shape. Still fires `reloadTabMessagesFromApi` on the
    desync case (frontend thinks running, backend says idle — the
    pre-existing recovery path is preserved). When backend says
    running, seeds in-flight chunks into the assistant message
    matching `snap.currentAssistantId` (creating it if needed).
    When backend says non-running, clears `isStreaming` on the
    previous in-flight message and nulls `currentAssistantId`.
  • `App.svelte:onMount` now awaits `tabStore.hydrateFromBackend()`
    before deciding whether to fall back to `createNewTab()`.
    Fallback condition is the doubly-defensive
    `restored === 0 && tabStore.tabs.length === 0`. `wsClient.connect()`
    fires in parallel with hydration — the resulting WS `statuses`
    event is per-tab idempotent against the hydrated state, so there
    is no race even if it arrives mid-hydration.

What was NOT done (deliberately, deferred to wishlist):
  • Pre-existing inconsistency: core `AgentStatus` includes
    "waiting_for_key" but frontend `TabStatusSnapshot.status` uses
    only the existing 3-state pattern ("idle" | "running" | "error").
    Not introduced here; mirrored the existing precedent.
  • Restored tabs use defaults for `reasoningEffort`, `agentSlug`,
    `agentScope`, `agentModels`, `workingDirectory` — these are not
    in the DB `tabs` schema. Future schema expansion.
  • Per-delta DB flushing — not needed; the in-memory snapshot
    covers the gap between flushAssistant calls.
  • LocalStorage cache of tab ids — backend DB is the source of truth.

Process notes:
  • Implemented via parallel programmer subagents (flash agents were
    requested but unavailable in this environment — substituted with
    "programmer" agents, which share the "reads a plan, implements a
    single step" charter). Backend (Segment A: getAllStatuses + 5
    tests) and frontend (Segment B: types + hydrateFromBackend +
    statuses handler + onMount + 8 tests) ran disjoint-file-ownership
    in parallel.
  • Gemini code review (yolo mode for tool access, explicit
    prompt-level write restriction to `report.md` only) returned a
    SHIP verdict with no findings against the plan.
  • Self-review surfaced one followup gap that Gemini's earlier
    plan-mode pass also caught: no explicit test for
    `/tabs/:id/messages` failure isolation. Added a test covering
    both HTTP-500 and network-error variants alongside a healthy
    tab, asserting per-tab failures don't destroy the whole restore.

Tests:
  • api/tests/agent-manager.test.ts: +5 (snapshot empty record,
    idle-tab field omission, running-tab field inclusion, defensive
    copy invariant, omits chunks for running tab with null
    currentChunks). 31 total (was 26).
  • frontend/tests/chat-store.test.ts: +9 (restore-with-messages,
    in-flight seeding, /tabs failure → 0 returned, empty /tabs
    array, idempotency when tabs already exist, idle-status when
    /status omits, running-snapshot statuses handler seeding,
    idle-snapshot statuses handler clearing, per-tab failure
    isolation across HTTP-500 and network-error). 44 total (was 35).

Totals: 243 tests across 3 packages all green; typecheck clean on
core + api + frontend; biome clean across 124 files.

0 files changed, 0 insertions, 0 deletions