[Juliusolsson05]

What this is

Diagnostic instrumentation for #283 — not the fix. This is the "separate PR" the issue's own Status section calls for: every on-paper ordering preserves the session id, so the stuck-at-loading interleaving needs a runtime timeline before fixing at source.

Background (#283)

On startup (rehydrate) and on resuming a killed session, a pane can stay stuck at transcriptStatus: 'loading' forever; a manual reload unsticks it. Two write paths can each silently drop an in-flight initial-history load's terminal status write:

1. loadInitialHistoryForSession writes 'loading' unconditionally (prev[id] ?? emptyRuntime()) but writes the terminal 'ready'/'error' only inside if (!current) return prev. If the runtime entry is dropped or re-keyed (idMap remap) while the load awaits IPC, the terminal write hits a missing key and is thrown away — the surviving runtime stays 'loading'.
2. commitRehydratedState rebuilds the runtimes map from a fresh out = {} and forces any non-ready/error status back to 'loading' for sessions with a providerSessionId. If no loader then drives it to 'ready', the pane is parked — exactly "stuck until manual reload" (reload re-invokes the loader under a stable id).

What it adds

• transcriptStatusTrace.ts (new): traceTranscriptStatus appends a STATE / transcript_status entry (from -> to @ site) per transition into the existing per-session feed-debug.jsonl — the channel the issue reporter already reads. No parallel log system (consistent with Consolidate debug infrastructure into one home, remove ad-hoc console.* scatter, enforce a typed logger boundary #102's "one debug home"). Two console warns tag the discard and force-to-loading paths with greppable [transcript-stuck][283].
• initialHistory.ts: trace all four status writes; warn on both !current bails before they swallow the terminal write.
• rehydrate.ts: warn when the rebuild drops a still-loading old key on re-key, or forces a providerSessionId session back to loading.

Safety

Diagnostic only — no behavior change. Renderer-only; typechecks clean (tsconfig.web.json, 0 errors in touched files). Reproduce once, read the timeline (feed-debug.jsonl transcript_status series + [transcript-stuck][283] console lines), then fix at source and delete this instrumentation.

🤖 Generated with Claude Code

[Juliusolsson05]

Closing as superseded. While this was in flight, #284 (diag(#283): instrument transcript-load lifecycle) merged to main with the same drop-point detection (RESOLVE-DROPPED / ERROR-DROPPED / loading-set / ready-set). Stacking a second overlapping diagnostic isn't worth it. The two genuinely-additive pieces here — a durable transcript_status series in feed-debug.jsonl (vs #284's console-only warns) and rehydrate-rebuild coverage — can be folded into the eventual #283 fix PR if still useful. #283 stays open for the actual fix.