M23: pane summaries (activity, kind, project, previews) #37

Open
opened 2026-10-02 04:07:04 +00:00 by jhgaylor · 0 comments
Owner

Depends on: #36
Blocks: #39, #40

Swarm track. Each daemon gets a cheap, live summary of all its panes, enough to draw hundreds of them without attaching to any.


  • More per pane in PaneInfo (and PaneSummary, illogical ls --json):
    • activity: output bytes per second (an EMA) and last_output_ms, kept in the PTY reader;
    • project: the git root of the cwd and its name, worked out when the cwd changes (cached, never a git per frame);
    • kind: a classification from the foreground command and process tree (shell, build, test, agent, server, logs, editor), with blocks keeping their BlockType;
    • title: the OSC 0/2 title, when the program sets one.
  • A summary subscription: a client can ask for summaries only (no State per change, no pane output).
    • The daemon sends field-level deltas, batched to at most 2 Hz (or whatever S16 measured), plus a full snapshot on connect.
    • Pane open and close events arrive in order with the deltas.
  • Previews on demand: the client names the panes it is drawing big enough to read, and the daemon sends their last N rendered lines at up to 1 Hz.
    • The list changes as you zoom and pan; anything not on it gets nothing.
    • This uses the same rendering as /api/panes/{id}/capture.
  • Parked panes (M9) stay parked: summary and activity don't wake them, and a preview reads the parked snapshot.
  • Access (M12): a viewer gets summaries only for the sessions they can see.
  • Done when:
    • geek with 500 panes keeps a summary subscriber current at under 5% of one core and under 20 KB/s while 10% of panes are busy;
    • illogical ls --json shows kind, project and activity for every pane;
    • a test checks that project and kind are right for a fixture of real commands (cargo test, npm run dev, claude, nvim, tail -f, journalctl -f).
**Depends on:** #36 **Blocks:** #39, #40 *Swarm track. Each daemon gets a cheap, live summary of all its panes, enough to draw hundreds of them without attaching to any.* -------- - **More per pane** in `PaneInfo` (and `PaneSummary`, `illogical ls --json`): - `activity`: output bytes per second (an EMA) and `last_output_ms`, kept in the PTY reader; - `project`: the git root of the cwd and its name, worked out when the cwd changes (cached, never a `git` per frame); - `kind`: a classification from the foreground command and process tree (shell, build, test, agent, server, logs, editor), with blocks keeping their `BlockType`; - `title`: the OSC 0/2 title, when the program sets one. - **A summary subscription:** a client can ask for summaries only (no `State` per change, no pane output). - The daemon sends field-level deltas, batched to at most 2 Hz (or whatever S16 measured), plus a full snapshot on connect. - Pane open and close events arrive in order with the deltas. - **Previews on demand:** the client names the panes it is drawing big enough to read, and the daemon sends their last N rendered lines at up to 1 Hz. - The list changes as you zoom and pan; anything not on it gets nothing. - This uses the same rendering as `/api/panes/{id}/capture`. - **Parked panes (M9) stay parked:** summary and activity don't wake them, and a preview reads the parked snapshot. - **Access (M12):** a viewer gets summaries only for the sessions they can see. - **Done when:** - geek with 500 panes keeps a summary subscriber current at under 5% of one core and under 20 KB/s while 10% of panes are busy; - `illogical ls --json` shows kind, project and activity for every pane; - a test checks that project and kind are right for a fixture of real commands (`cargo test`, `npm run dev`, `claude`, `nvim`, `tail -f`, `journalctl -f`).
Sign in to join this conversation.
No description provided.