WorkHub Coordination transcript is replayed in full on every open and every reconnect

[Astro-Han]

createDesktopWorkHubCoordinationPort reads the WorkHub Coordination transcript back to its first message before the panel can emit:

while (!disposed && generation === historyGeneration && store.range().hasOlder) {
  const before = store.range().oldestSequence;
  await handle.loadBefore(before);
  const after = store.range();
  if (after.hasOlder && after.oldestSequence === before) {
    throw new Error('WorkHub Coordination transcript history did not advance');
  }
}

apps/desktop/src/renderer/workhub-coordination-port.ts:132-139

Three things make that cost grow without bound.

The Coordination transcript is a singleton and append-only. WORKHUB_COORDINATION_SESSION_ID is a constant, and every delegation request, supersession and replacement appends to it (workhub-coordination-coordinator.ts:273, :354, :399). Nothing rotates or truncates it, so it grows for the lifetime of the install.

The full replay is not once per process. rebuildCompleteHistory runs at open (:151) and again on every batch.reset (:99-103), so each reconnect or replay pays for the whole history again.

It gates readiness. historyReady guards emit(), so WorkHub stays unusable until the last page lands.

What the projection keeps out of that replay is one message type:

for (const { sequence, message } of store.durableEntries()) {
  if (message.type === 'workhub_coordination') {
    coordinationMessagesBySequence.set(sequence, message);
  }
}

So the question I cannot answer from outside: does the projection genuinely need every historical coordination message, or only enough to resolve the live delegation state?

If it is the latter, this wants a bound rather than a full walk — a page budget, or a Host-side read filtered by message type so the renderer stops paging through unrelated transcript entries to find its own.

If it is the former, the growth is still real and the transcript needs a retention story. #4439 made readWorkHubActionClaim the replay authority, so the write rate on this session only goes up from here.

Not proposing an implementation, since whoever owns the coordination projection knows which of the two it is. Filing it because the cost is invisible today and scales with how long someone has used WorkHub, which is the kind of thing that shows up as "WorkHub got slow" long after the cause.

@ARE404 you built this surface, so assigning it to you and to me.