43 lines
2.7 KiB
Markdown
43 lines
2.7 KiB
Markdown
---
|
|
title: 'TUI backend runtime worker listを表面化する'
|
|
state: 'inprogress'
|
|
created_at: '2026-07-18T02:39:04Z'
|
|
updated_at: '2026-07-18T02:46:09Z'
|
|
assignee: null
|
|
queued_by: 'yoi ticket'
|
|
queued_at: '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` を通す。
|