# Re-read the workspace when an app window becomes active

- **Status**: Todo
- **Kind**: Feature
- **Authors**: jp
- **Date**: 2026-08-19
- **Implements**: 099
- **Label**: client=macos
- **Label**: type=enhancement

`jp_workspace_conversations` and `jp_workspace_events` re-read the conversation
index before answering, so a handle kept open across a concurrent `jp query`
reports that query's turns.
The app does not take advantage of it: it reads once when a window opens a
workspace and never asks again, so the transcript on screen is whatever was on
disk at that moment.

The gap this closes is small and the mechanism is already there.
A window that re-requests its conversation list and its open transcript when it
becomes the active window would show the result of a query the user just ran in
a terminal, which is the normal way this app is used alongside `jp`.

Scope is the app side only:

- Re-request on `NSApplication` activation, or on the window becoming key,
  whichever proves less noisy.
- Keep the current selection and scroll position across the refresh.
  A list that jumps because a conversation moved to the top is worse than a
  stale one.
- Do nothing when the payload is unchanged, so an activation that found no new
  work costs no redraw.

Not this ticket: watching the store.
Nothing notifies the app that something changed, so a window left in the
foreground still shows what it last read.
That is the Live Workspace View draft's problem, and it wants `refresh_index`
(reconcile by diff) rather than the reset-style reload the boundary uses today.