Merge branch 'develop' into work/workspace-panel-action-model

.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P2
 labels: [tui, composer, history, persistence]
 created_at: 2026-06-01T02:11:04Z
-updated_at: 2026-06-01T02:11:04Z
+updated_at: 2026-06-05T23:01:38Z
 assignee: null
 legacy_ticket: null
 ---
@@ -20,28 +20,36 @@ TUI composer では上下キーで過去に送信・queue した入力を recall
 
 ## Storage decision
 
-永続化先は workspace 配下の `./.insomnia/` ではなく、ユーザー data dir（既定では `~/.insomnia`、実装上は既存の data-dir 解決に従う）を使う方針とする。
+永続化先は workspace 配下の `./.yoi/` ではなく、ユーザー data dir（既定では `~/.yoi`、実装上は既存の data-dir 解決に従う）を使う方針とする。
+
+保存 layout は、canonical workspace path / pwd から作る path-safe key を使って workspace ごとに分ける。デフォルト表示としては次のような形にする。
+
+```text
+~/.yoi/<path-to-pwd>/composer-history.json
+```
+
+実際の `<path-to-pwd>` は path separator や衝突を安全に扱える encoded key / stable key にしてよいが、metadata には元の workspace path / display name を持たせる。
 
 理由:
 
 - composer input history は個人の操作履歴であり、project-authored asset ではない。
 - 入力には secret / private context が混ざり得るため、workspace に書くと git 追跡・共有・公開監査のリスクが上がる。
-- `./.insomnia/` は workflow / knowledge / manifest assets など project/workspace 側の明示的な資産に寄せ、生成された個人履歴は user data 側に置く方が境界が明確。
+- `./.yoi/` は workflow / knowledge / Ticket records / manifest assets など project/workspace 側の明示的な資産に寄せ、生成された個人履歴は user data 側に置く方が境界が明確。
 - 「どの workspace の履歴か」は、user data 側で workspace identity（canonical workspace root / git root などから作る stable key）と display metadata を持てば表現できる。
 
 ## Requirements
 
 - 上下キーで呼び出す composer input history を、TUI 再起動後も利用できるよう永続化すること。
 - 履歴は workspace ごとに分離すること。別 workspace の入力履歴が通常操作で混ざらないこと。
-- 保存先は既存の user data dir 配下にすること。デフォルト表示としては `~/.insomnia` 相当だが、実装は data-dir override / path resolution に従うこと。
+- 保存先は既存の user data dir 配下にすること。デフォルト表示としては `~/.yoi/<path-to-pwd>/composer-history.json` 相当だが、実装は data-dir override / path resolution に従うこと。
-- `./.insomnia/` には composer history を作成しないこと。
+- `./.yoi/` には composer history を作成しないこと。
 - 保存 record は、どの workspace の履歴か判別できる metadata / key を持つこと。
 - 既存の TUI-local / non-destructive recall semantics を維持すること。
   - Pod protocol を変えない。
   - transcript / session history を mutate しない。
   - recalled input は、ユーザーが再送信するまでは conversation state に影響しない。
 - 入力は typed `Segment` vector として保存し、structured input の recall を壊さないこと。
-- non-blank input のみ保存し、連続重複を抑止し、履歴件数は bounded にすること。既存挙動の 100 件 bound を尊重する。
+- non-blank input のみ保存し、連続重複を抑止し、履歴件数は workspace ごとに最大 30 件程度に bound すること。
 - secret 値が混ざり得る前提で、保存内容を diagnostics / logs / tickets / tests snapshot / model context に不用意に出さないこと。
 - 破損した履歴ファイルがあっても TUI startup を致命的に壊さず、必要なら warning と空履歴 fallback にすること。
 - 既存の multiline cursor navigation、Up/Down browse、draft restore、edit-on-recall の挙動を regression させないこと。
@@ -51,6 +59,7 @@ TUI composer では上下キーで過去に送信・queue した入力を recall
 - 同じ workspace で TUI を再起動しても、以前送信した composer input を上下キーで recall できる。
 - 別 workspace では履歴が分離される。
 - workspace 配下に新しい composer history file が作られない。
-- user data dir 配下に workspace-scoped な composer history が保存される。
+- user data dir 配下、既定では `~/.yoi/<path-to-pwd>/composer-history.json` 相当の workspace-scoped path に composer history が保存される。
+- 保存件数は workspace ごとに最大 30 件程度に bound される。
 - Pod session log / Worker history / transcript には、recall 操作だけでは何も追加されない。
 - focused test または明確な手動確認手順で、永続化・workspace 分離・既存 recall semantics を検証できる。

.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/thread.md

@@ -4,4 +4,19 @@
 
 Created by tickets.sh create.
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:01:38Z -->
+
+## Decision
+
+Updated based on user direction:
+
+- keep this as the existing `tui-composer-history-persistence` ticket rather than creating a duplicate;
+- default user-data shape should be like `~/.yoi/<path-to-pwd>/composer-history.json` using a path-safe/stable workspace key;
+- do not create composer history under workspace `./.yoi/`;
+- bound persisted recall history to about 30 entries per workspace instead of the older 100-entry note;
+- keep typed `Segment` storage, non-destructive recall semantics, and no Pod/session transcript mutation.
+
+
 ---

.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [tui, ticket, orchestration, panel]
 created_at: 2026-06-05T21:07:03Z
-updated_at: 2026-06-05T21:09:19Z
+updated_at: 2026-06-05T23:13:39Z
 assignee: null
 legacy_ticket: null
 ---

.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md

@@ -31,4 +31,67 @@ Implementation is split into child tickets:
 Existing `:ticket ...` commands remain as low-level fallback, not the main UX.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:05:06Z -->
+
+## Decision
+
+Decision/update from UI discussion:
+
+Do not preserve `--multi` as a separate long-term UI surface. The workspace panel should become the unified workspace view.
+
+`--multi`-style Pod list behavior remains useful, but should be treated as the panel's no-Ticket / Pod-centric route rather than a distinct architecture. In workspaces where Ticket config/storage is unavailable or Ticket usage is not desired, opening the panel should still provide the current multi-Pod discovery/attach/send affordances as a fallback view.
+
+Implications:
+- Implementation can reuse current `--multi` code/components as the first panel substrate.
+- The long-term command/launch model should prefer a panel view option; any existing `--multi` entry point can remain as a compatibility alias or shortcut into the Pod-centric panel route during migration.
+- The panel model should tolerate an empty/unavailable Ticket backend and still show useful Pod rows/actions.
+- Avoid designing two separate surfaces with duplicated selection, attach, send, and rendering logic.
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:08:49Z -->
+
+## Decision
+
+Decision/update from launch-route discussion:
+
+Current route is still `yoi --multi` -> `LaunchMode::Multi` -> `single_pod::run_multi(...)` -> current multi-Pod dashboard. There is no dedicated `yoi panel` command yet.
+
+Target route should be `yoi panel`: open the workspace panel for the current working directory/workspace. The panel should resolve the workspace from cwd using the same project/config/Ticket root conventions as the rest of Yoi, then:
+
+- show Ticket/action-centric mode when `.yoi/tickets` / Ticket config is available or Ticket use is active;
+- fall back to the Pod-centric route (current `--multi` behavior) when the workspace has no Ticket backend/config or no Ticket records;
+- keep current `--multi` as a temporary compatibility alias/shortcut into `yoi panel`'s Pod-centric route during migration, rather than a separate long-term surface.
+
+This keeps a single workspace control surface while preserving the existing multi-Pod affordances for non-Ticket workspaces.
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:13:39Z -->
+
+## Decision
+
+Decision/update from launch and no-Ticket workspace discussion:
+
+Remove `--multi` as a user-facing launch option rather than keeping it as a compatibility alias.
+
+Target launch model:
+
+- `yoi panel` opens the workspace panel for the current working directory/workspace.
+- The panel resolves Ticket config from the workspace.
+- If `.yoi/ticket.config.toml` / Ticket config is defined and usable, the panel shows Ticket/action-centric workspace UI.
+- If Ticket config is undefined, the panel suppresses Ticket-related UI entirely:
+  - no Ticket/action rows;
+  - no Ticket-specific Pod labels/actions;
+  - no Intake/Orchestrator/Ticket workflow affordances;
+  - no Ticket-related diagnostics unless needed to explain an explicitly requested Ticket action.
+- In that no-Ticket mode, `yoi panel` should provide the same functional surface as the current `--multi` view: Pod discovery/status, selection, attach/open, and direct send where currently supported.
+
+This keeps one panel implementation while avoiding a permanent `--multi` surface or confusing Ticket UI in workspaces that have not opted into Ticket config.
+
+
 ---