irisandClaude Fable 5.1
73ee63bc1b
The pass condition was the same screen, from the same crate, running in a window with only the layout differing. desktop-app is a new workspace member: a session list (plain iris::widget::Span, rebuilt on selection) beside transcript_ui::build_tree's screen, talking to a real ai-server through client-core's ApiClient/UreqTransport/follow_session_events, with background network I/O on plain std::threads reporting back through winit's EventLoopProxy rather than iris's Tasks (which only redraws once per async closure, not once per SSE event). Both pass-condition proofs held against app/ui-sandbox.sh's real server: the list showed a spawned session, selecting it loaded its transcript, and a message sent from the composer streamed its reply back live. Along the way, a real bug: resuming the SSE stream from a folded item's seq (which for a still-open assistant message is its *first* delta's seq by design) replayed already-folded deltas and duplicated the tail of the reply -- found by a run-headless.sh screenshot, fixed by resuming from the raw wire seq instead, and covered by a regression test. Deliberately simple and said so in app.rs's module doc: every SSE event refolds the whole transcript and rebuilds the right-hand tree from scratch rather than reaching for TranscriptScreen::push_row's incremental append, since a streaming reply is a row whose text keeps changing after it appears and push_row can only add a new one. Fine at a desktop session's scale; the real fix needs transcript-ui to expose updating a row in place. Android is untouched by this step. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>