Kaede AkinoandClaude Opus 5
d7029a0557
Context was decoration. Three defects, all reported from use. Session context followed the conversation. `ConversationModel` owned the chips and the remote system info, and `refreshAssistantContext` stamped the focused pane onto whichever chat the sidebar was showing — so sending from the sidebar carried a host and directory into the Assistant tab, which has no session to describe. It now lives on `WindowSidebarState` as a `SessionContext`, and `ComposerView` takes it as a parameter defaulting to `.none`. The Assistant tab passes nothing, so it cannot show or send a session it does not have. Two bugs fell out with it: leaving a Workspace clears the context instead of freezing the last value, and opening a chat in the sidebar no longer marks it. Nothing was sent. Only `RemoteSystemInfo` reached the model; host and cwd reached nothing, and `ContextChip` had no payload at all — the SSH-failure attachment was a label for a log pasted into the draft. `SessionContext.modelContext` now renders one fenced data-only block into the run's system prompt, chips carry their content, and `appendUserTurn` folds attachments into the turn it returns. What was uploaded is literally what the bubble shows. Titles were the first message. `ConversationTitleService` mirrors `CommandComposerService` — tool-free, strict JSON, validated — and resolves `.chat` rather than adding a Titler role, per the argument already written into `AIRole`. It runs once after the first reply and persists to the `title` column that existed but was never read back, so no migration. It reads `transcript`, not `messages`: a failed run writes its reason to the visible list alone, and that is not a name. `Pane.remoteSystemInfo` already withholds the probe when Shell Integration is off, so the second gate in `AppModel` is gone — the value sent is the value the chips were drawn from, and the two cannot disagree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>