diff --git a/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/item.md b/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/item.md index 57de8ea9..20c36d3a 100644 --- a/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/item.md +++ b/.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//composer-history.json +``` + +実際の `` は 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 に従うこと。 -- `./.insomnia/` には composer history を作成しないこと。 +- 保存先は既存の user data dir 配下にすること。デフォルト表示としては `~/.yoi//composer-history.json` 相当だが、実装は data-dir override / path resolution に従うこと。 +- `./.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//composer-history.json` 相当の workspace-scoped path に composer history が保存される。 +- 保存件数は workspace ごとに最大 30 件程度に bound される。 - Pod session log / Worker history / transcript には、recall 操作だけでは何も追加されない。 - focused test または明確な手動確認手順で、永続化・workspace 分離・既存 recall semantics を検証できる。 diff --git a/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/thread.md b/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/thread.md index 7255e4d5..50f8e3f0 100644 --- a/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/thread.md +++ b/.yoi/tickets/open/20260601-021104-tui-composer-history-persistence/thread.md @@ -4,4 +4,19 @@ Created by tickets.sh create. +--- + + + +## 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//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. + + --- diff --git a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md b/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md index 256c56ba..4dc41945 100644 --- a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md +++ b/.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 --- diff --git a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md b/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md index ce252d9d..638e6e83 100644 --- a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md +++ b/.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. +--- + + + +## 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. + + +--- + + + +## 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. + + +--- + + + +## 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. + + ---