yoi/.yoi/tickets/00001KXSHEWD1/item.md

title	state	created_at	updated_at	assignee	queued_by	queued_at
TUI backend runtime worker listを表面化する	closed	2026-07-18T02:39:04Z	2026-07-21T09:16:15Z	null	yoi ticket	2026-07-18T02:39:40Z

背景

TUI を backend runtime の client として接続する経路は基礎実装があるが、ユーザーが通常導線として worker を一覧し、既存 worker を選んで接続/確認する入口が表面化していない。

直近の調査では、backend/runtime の worker summary/detail は REST で取れる一方、会話内容は observation WebSocket snapshot を読む必要があり、CLI/TUI から人間向けに扱いづらいことも確認された。

この Ticket では、まず TUI backend runtime client 導線の worker list 実装から着手し、現行 staging/extract 実装が runtime/embedded 経路で破綻していないかの確認も含める。

実装要件

• TUI を backend runtime client として使う導線で、runtime worker list をユーザーに見える形にする。
• worker list は backend が公開している runtime/worker summary を authority とし、TUI 側で独自 scheduler や duplicate backend を作らない。
• list item には少なくとも runtime id、worker id、label/profile、status/state、working directory summary を表示できること。
• 既存 worker を選択して attach/read/inspect へ進めるための実装境界を整理する。今回の主作業は list で、attach/read の大規模実装は必要なら follow-up に分ける。
• backend/runtime は local/private boundary を維持し、frontend だけ外部 bind できる前提を壊さない。
• staging/extract 実装について、embedded/runtime 経路で staging write abstraction が破綻していないかを確認し、必要なら小修正する。

非目標

• worker scheduler を TUI に新設しない。
• backend/runtime REST API を無秩序に増やさない。必要な場合は bounded/read-only な endpoint として理由を明確にする。
• TUI の全面 redesign はしない。
• extract candidate tuning はこの Ticket の主目的ではない。

受け入れ条件

• backend runtime client mode で worker list が見える、またはそのための CLI/TUI 実装差分が明確に入る。
• list は backend/runtime authority 由来の worker identity を使う。
• 実装者が既存 worker arc/3 相当を確認し、動作確認結果を Ticket thread に残す。
• staging/extract の current implementation について、runtime/embedded 経路での確認結果を Ticket thread に残す。
• cargo fmt --check と relevant tests が通る。
• code/resource 変更がある場合は nix build .#yoi を通す。