Repository navigation
Read-only Fleet Sessions view: list hub sessions from a standalone client #779
Description
Important
Problem
When a fleet client goes standalone, its Sessions dropdown points at the empty local store and the ~130 canonical hub sessions become unlistable — the researcher cannot see, search, or reopen any prior work without reattaching by hand. During/after the 2026-09-03 outage this meant working blind from the MacBook.
Approach
A read-only Fleet Sessions view on the client that lists hub sessions fetched over the existing tunnel from the hub's session-list API — the same call the attach flow already makes to pin a session. Clicking an entry reattaches to the hub with that session pinned. No database mirroring: the canonical event store stays hub-side.
Approaches Considered
- Read-only hub view over the tunnel (chosen) — no copy, no conflicts, works whenever the tunnel does; smallest surface that restores visibility.
- Mirror/sync hub sessions into the client store — full offline history but a multi-GB, conflict-prone, long-running sync problem; rejected.
- Surface the vault session ledgers in the UI — zero server work but thin (no transcripts), already half-built, and the wrong source of truth for sessions.
- Honest pointer only (banner + reattach affordance) — truthful but leaves the researcher listless; kept as the degraded rendering inside the chosen view.
Scope
In: a client-side session list (tree view) fed by the hub API over the tunnel; click-to-reattach-and-pin; a degraded state when the hub is unreachable that says where sessions live; title + timestamp per entry.
Out: in-app (fork) listing inside the web app's Sessions panel — needs cross-origin work, filed as follow-up only, not committed; any write path to hub sessions from the list (view is strictly read-only); DB mirroring or offline transcripts; search beyond the API's listing.
Assumptions / Open Qs
- Assumed the hub session-list API is reachable whenever the tunnel is (the attach flow already depends on it).
- Open: should entries deep-link into the hub-hosted app for full transcripts when attached? Lean yes post-reattach; v1 only needs reattach-and-pin.
Acceptance Criteria
- On a fleet client, the view lists the hub's sessions (title, last-updated) for the server's project directory whenever the tunnel is up.
- Clicking an entry reattaches the panel to the hub with that session pinned and open.
- When the hub is unreachable, the view shows an explicit "sessions live on " degraded state — never an empty list implying there are no sessions.
- The list is read-only: no entry on it can create, rename, or delete a session.
- On a machine that has never been a fleet client, the view is absent (not an empty stub).
Key Decisions
- Fetch from the same hub endpoint the attach flow uses for session pinning; directory-scoped to the server's project directory.
- Refresh on view open and on hub state transitions (attach/regain) — not on a timer.
- Zero fork changes in v1; the vendored web app is untouched.
Constraints & Invariants
- Strictly read-only over the wire; no mutation endpoints called from this view.
- No session data is persisted client-side beyond the visible list cache.
Prior Art / Patterns
- The attach flow already fetches the hub's latest session to pin — reuse its endpoint, directory parameter, and auth path. - The chat panel already supports opening the app pinned to a specific session id — click-to-open rides that. - Vault: `sessions/session-20260903-fleet-improvements-brainstorm.md` §6 row B carries the code anchors.Source
- Durable record:
vault-aaron/sessions/session-20260903-fleet-improvements-brainstorm.md§3.4 + §6 - Related: fleet client: first-attach probe timeout (1500 ms) makes attach impossible on high-RTT links (plane wifi) — SSE override only covers post-attach #777 (attach protocol hardening — same tunnel/API assumptions)
Notes
- Part of the 2026-09-03 handoff bundle (B of E). The design piece of the bundle; A + C are mechanical.
Activity
aarontrowbridge commentedon Sep 7, 2026
Superseded by the native merged sessions view — recorded per spec
spec-20260905-193000-local-shell-data-planerev 2, D4.This issue's premise — hub sessions unlistable from a standalone/fleet client, bridged by a read-only tree view over the tunnel — is retired at the local-shell data plane's landing (Slice C, amicissimo#393):
Implementation: #848 (the Slice C view PR, referencing amicissimo#393).
Not closing this issue here — the disposition click stays with Aaron. The held implementation fork PR #794 is likewise recorded as superseded-by-design (never merged).
aarontrowbridge commentedon Sep 7, 2026
Superseded per D4 of spec-20260905-193000: the native merged sessions view shipped (amicode#848 + amicissimo#397, merged 2026-09-07) — both stores, one provenance-tagged list, posture-honest. The interim bridge this issue tracked is retired at landing, as planned. (With PR #794; Aaron's directive, 2026-09-07.)