docs(tickets): completed tickets cleanup
This commit is contained in:
parent
b7953b3d28
commit
d6f27f7c45
2
TODO.md
2
TODO.md
|
|
@ -15,7 +15,6 @@
|
|||
- ストリーム途中失敗時の継続 → [tickets/llm-worker-stream-continuation.md](tickets/llm-worker-stream-continuation.md)
|
||||
- llm-worker: Anthropic projection で assistant ターン内ブロックを 1 message に束ねる → [tickets/anthropic-assistant-burst-bundling.md](tickets/anthropic-assistant-burst-bundling.md)
|
||||
- ネイティブ GUI クライアント MVP → [tickets/native-gui-mvp.md](tickets/native-gui-mvp.md)
|
||||
- Client crate の切り出し（TUI/GUI/E2E 共通の protocol クライアント） → [tickets/client-crate.md](tickets/client-crate.md)
|
||||
- E2E テストハーネス（`tests/e2e/`、opt-in） → [tickets/e2e-harness.md](tickets/e2e-harness.md)
|
||||
- TUI 拡充
|
||||
- Run 中の入力キューイング → [tickets/tui-input-queue.md](tickets/tui-input-queue.md)
|
||||
|
|
@ -27,7 +26,6 @@
|
|||
- Prune: 保護境界を turn 数から末尾 token budget に置き換え → [tickets/prune-token-budget.md](tickets/prune-token-budget.md)
|
||||
- メモリ機構
|
||||
- 使用頻度メトリクス + Knowledge 化候補レポート → [tickets/memory-usage-metrics.md](tickets/memory-usage-metrics.md)
|
||||
- Prompt から project-specific ticket shadow policy を外す → [tickets/memory-prompts-remove-ticket-policy.md](tickets/memory-prompts-remove-ticket-policy.md)
|
||||
- セッション内 Task ツールの注意機構（無アクティビティで `<system-reminder>` ナッジ） → [tickets/session-todo-reminder.md](tickets/session-todo-reminder.md)
|
||||
- ワークスペースのメモリーをLintするヘッドレスCLI
|
||||
- system-reminder 注入機構の汎用化（2件目の利用者が出た時に検討。タグ形式 `<system-reminder>...</system-reminder>` の規約は session-todo-reminder で先行確立。注入された Item は worker.history に append する方針）
|
||||
|
|
|
|||
|
|
@ -1,56 +0,0 @@
|
|||
# Client crate の切り出し
|
||||
|
||||
## 背景
|
||||
|
||||
protocol を喋る socket クライアントは現在 `crates/tui/src/client.rs` に閉じている。今後の二つの方向で、TUI 内に閉じていることが障害になる:
|
||||
|
||||
- **GUI MVP** (`tickets/native-gui-mvp.md`): GUI バイナリも同じ protocol を喋る。チケット側の検討事項にも「socket client を別 crate に切り出して共有するか、GUI crate 内に閉じて持つか」が挙げられている (`native-gui-mvp.md:67`)。
|
||||
- **E2E ハーネス** (`tickets/e2e-harness.md`): TUI バイナリを PTY で叩くのは脆く、GUI バイナリは MVP 中。E2E から protocol を直接喋る入口として client crate が要る。
|
||||
|
||||
TUI 内に置いたまま GUI と E2E から再利用しようとすると、TUI のレンダリング都合と client の責務が混ざる。先に切り出しておく。
|
||||
|
||||
## 方針
|
||||
|
||||
- `crates/client/` を新設し、socket への接続・`Method` 送信・`Event` 受信・graceful shutdown までの低レベル機能を移す。
|
||||
- TUI / GUI / E2E は当 crate を依存先として呼び出す。Pod の subprocess 起動も client crate 側で扱うのが自然か、別 crate / 上位呼び出し側に残すかは設計で詰める（GUI が subprocess を直接 spawn する流儀との整合）。
|
||||
- 移行は機能等価で、TUI に regression を起こさないこと。
|
||||
|
||||
## 検討事項
|
||||
|
||||
- crate 名: `client` で良いか、より具体的な名前にするか（`pod-client` 等。`feedback_crate_naming.md` の方針に従いプレフィックスは付けない）。
|
||||
- subprocess spawn 責務: client crate に含めるか、呼び出し側に残すか。GUI MVP では「GUI から直接 pod を spawn」する流儀なので、spawn と connect を分離して両方公開しておくのが妥当そう。
|
||||
- 公開 API の境界: 生 socket / `JsonLineReader` までを露出するか、もう一段抽象化したリクエスト/サブスクライブ API にするか。
|
||||
- 非同期ランタイム: tokio 前提で良いか（GUI の GPUI executor との統合は GUI 側で吸収する）。
|
||||
- error 型: TUI の `client.rs` 内で持っている error をそのまま move するか、再設計するか。
|
||||
|
||||
## 要件
|
||||
|
||||
- `crates/client/` が新設され、現 `crates/tui/src/client.rs` 相当の機能を提供する。
|
||||
- TUI は新 crate に依存して動作し、既存テスト・既存挙動が通る。
|
||||
- API は GUI / E2E から呼べる粒度で公開されている（最低限: 接続、`Method` 送信、`Event` ストリーム購読、shutdown）。
|
||||
- pod subprocess を spawn する経路をどこに置くかが決まり、必要なら本 crate からも呼べる。
|
||||
|
||||
## 完了条件
|
||||
|
||||
- 上記要件が満たされる。
|
||||
- TUI が新 crate を使って従来通り動く（`cargo test -p tui` / TUI 手動起動で regression 無し）。
|
||||
- E2E ハーネス（`tickets/e2e-harness.md`）が本 crate に依存して protocol を喋れる状態になる。
|
||||
|
||||
## 範囲外
|
||||
|
||||
- GUI バイナリ実装そのもの（`tickets/native-gui-mvp.md`）。
|
||||
- protocol の拡張・互換破壊。
|
||||
- TUI のリファクタリングを切り出し以上にやること（責務移動だけに留める）。
|
||||
- daemon 層の導入。
|
||||
|
||||
## 依存 / 関連
|
||||
|
||||
- `tickets/native-gui-mvp.md`
|
||||
- `tickets/e2e-harness.md`
|
||||
- `crates/tui/src/client.rs`
|
||||
- `crates/protocol/`
|
||||
|
||||
## Review
|
||||
- 状態: Approve
|
||||
- レビュー詳細: [./client-crate.review.md](./client-crate.review.md)
|
||||
- 日付: 2026-05-09
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
# Review: Client crate の切り出し
|
||||
|
||||
## 前提・要件の確認
|
||||
|
||||
- `crates/client/` 新設、`crates/tui/src/client.rs` 相当の機能を提供 (`tickets/client-crate.md:28`)
|
||||
- 満たされている。`crates/tui/src/client.rs` は `crates/client/src/pod_client.rs` へ純粋 rename されており (`PodClient::{connect, send, try_next_event, next_event}` の 4 API は完全に同一)、`Drop` で reader タスクが mpsc 切断を契機に終了する graceful shutdown 挙動も同じ。
|
||||
- TUI が新 crate に依存して動作・既存テストが通る (`tickets/client-crate.md:29`)
|
||||
- 満たされている。`crates/tui/Cargo.toml:8` で `client = { workspace = true }` を追加、`crates/tui/src/main.rs:30` で `use client::PodClient`、`crates/tui/src/spawn.rs:19` で `use client::{SpawnConfig, spawn_pod}`。`cargo test -p tui` 91 件 pass、ローカルで `cargo build --workspace` も完走。
|
||||
- API は GUI / E2E から呼べる粒度で公開 (`tickets/client-crate.md:30`)
|
||||
- 満たされている。`crates/client/src/lib.rs:14-15` で `PodClient` と `spawn::{SpawnConfig, SpawnError, SpawnReady, spawn_pod}` が re-export されており、接続 / Method 送信 / Event 購読 (`next_event` / `try_next_event`) / shutdown (Drop) と subprocess spawn が独立して呼び出せる粒度で揃う。
|
||||
- pod subprocess を spawn する経路の決定 (`tickets/client-crate.md:31`)
|
||||
- 満たされている。client crate に同梱しつつ `spawn_pod` と `PodClient::connect` を分離。GUI が「自身で spawn せず attach する」「自身で spawn する」のいずれを選んでも一段の関数呼び出しで済む。
|
||||
|
||||
## 完了条件 (`tickets/client-crate.md:33-37`)
|
||||
|
||||
- 上記要件を満たす点は OK。
|
||||
- TUI 既存挙動・テスト通過は OK (`spawn::tests::*` 6 件含めて 91 件 pass)。
|
||||
- E2E ハーネス (`tickets/e2e-harness.md`) は本 crate に依存して protocol を喋れる状態 — 公開 API として `PodClient::connect(&Path) -> Result<Self, io::Error>` と `spawn_pod(SpawnConfig, FnMut(&str)) -> Result<SpawnReady, SpawnError>` が揃ったため、依存追加だけで E2E が protocol を直接駆動できる。OK。
|
||||
|
||||
## アーキテクチャ・スコープ
|
||||
|
||||
- 範囲外 (`tickets/client-crate.md:39-44`) を侵していない:
|
||||
- GUI バイナリ実装には踏み込んでいない。
|
||||
- protocol 互換破壊なし (`pod_client.rs` は `JsonLineReader/Writer` をそのまま使用)。
|
||||
- TUI のリファクタは責務移動のみ。`Form` / `draw_form` / `build_overlay_toml` / `load_resume_scope` 等の UI / manifest 解決ロジックは TUI に残置。`crates/tui/src/spawn.rs:541-653` の単体テストも手付かず。
|
||||
- daemon 層には触れていない。
|
||||
- crate 命名: `client` (プレフィックス無し)。`feedback_crate_naming.md` 方針に準拠。
|
||||
- 依存追加方法: `Cargo.toml` の `[workspace.dependencies]` への登録は workspace 規約上必須なため手動編集が正当 (`cargo add` の対象外)。`crates/client/Cargo.toml` も `protocol` / `manifest` / `tokio` / `uuid` を `workspace = true` 経由で取得しており方針通り。
|
||||
- レイヤ整合: `client` は `protocol` / `manifest` / `tokio` のみに依存し、`session-store` や上位レイヤを引きずり込んでいない。`session_store::StoreError` 関連の error は TUI 側の `SpawnError::{Store, MissingResumeScope}` に残置されており、責務分割が綺麗に出来ている (`crates/tui/src/spawn.rs:46-85`)。
|
||||
- `SpawnError` の Display 移送: 旧 TUI の `SpawnError` のうち `PodLaunchFailed` / `PodExitedEarly` / `Timeout` / runtime dir 解決失敗 / `Io` を `client::SpawnError` 側へ移動し、TUI 側は `Spawn(client::SpawnError)` でラップして `{e}` で透過表示。重複なくユーザー向けメッセージが保持されている。
|
||||
- 公開 API 境界: 生 socket / `JsonLineReader` を露出せず、薄いラッパーに留めた。チケットの検討事項 (`tickets/client-crate.md:22`) に対する妥当な選択で、既存挙動を壊さない最小範囲。
|
||||
|
||||
## 指摘事項
|
||||
|
||||
### Non-blocking / Follow-up
|
||||
|
||||
- `crates/client/src/spawn.rs` に単体テストが無い (`INSOMNIA_POD_COMMAND` で mock pod を差し込めば ready / timeout / 早期 exit の各パスをテスト可能)。E2E ハーネス側で間接的にカバーされる予定なら不要だが、E2E チケット先行よりこの crate の自己完結テストが入っていると将来回帰検出が容易。
|
||||
- `SpawnConfig::cwd` が `PathBuf` フィールドで強制される一方、TUI 側 `wait_for_ready` (`crates/tui/src/spawn.rs:275`) は `run()` の冒頭で取った cwd と独立にもう一度 `current_dir()` を呼んでいる。動作上は等価だが、責務切り出しの完了を機に `run()` で取得した cwd を form に持たせて一度だけ参照する形にできる (今回スコープ外でも可)。
|
||||
- `crates/client/src/spawn.rs:21-22` の `READY_PREFIX` / `READY_TIMEOUT` は pod 側 (`crates/pod/`) の出力フォーマットと結合した contract だが、両者の同期は型/定数共有でなく目視確認のまま。protocol crate に const として置く方が長期的に安全だが、これも今回の責務切り出しスコープを超える。
|
||||
|
||||
### Nits
|
||||
|
||||
- `crates/client/src/lib.rs:5` の docstring "pod バイナリをサブプロセスとして起動し" は OK だが、`spawn_pod` が `kill_on_drop = false` + `process_group(0)` で detach する点を 1 行追加するとライフサイクル不変条件が見えやすい (本体側 `crates/client/src/spawn.rs:9-11` には記載されているのでそちらへの参照でもよい)。
|
||||
- `SpawnReady` の同名構造体が `crates/tui/src/spawn.rs:35-38` にも残っており、`client::SpawnReady` を unwrap して TUI 側で再構築している (`crates/tui/src/spawn.rs:288-291`)。TUI 側の `SpawnReady` は外部公開されないため `pub use client::SpawnReady` に置換可能だが、TUI 内 API 表面の安定性に関わるので任意。
|
||||
|
||||
## 判断
|
||||
|
||||
Approve — 要件・完了条件・範囲外の規定に正しく収まっており、責務移動以上のリファクタは行われていない。新 crate は他 crate から再利用できる粒度で公開され、TUI 既存挙動は 91 件のテストで保たれている。Follow-up の指摘は本チケットの完了を妨げない。
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
# Memory prompts: project-specific ticket shadow policy を外す
|
||||
|
||||
## 背景
|
||||
|
||||
現在の bundled memory prompts は、INSOMNIA 自身の開発運用に由来する「ticket / TODO / worktree / commit は git が正本なので memory に記録しない」という規則を、一般ユーザーの workspace にも適用している。
|
||||
|
||||
特に `resources/prompts/internal/memory_extract_system.md` と `resources/prompts/internal/memory_consolidation_system.md` には、ticket file 作成・編集、TODO 更新、ticket 名、worker Pod spawn for ticket などを memory から落とす指示が明示されている。しかし ticket はこのプロジェクト固有の管理手法であり、insomnia の利用者に押し付けるほど汎用的・成熟した概念ではない。
|
||||
|
||||
このため、memory がユーザー workspace の実際の管理対象や作業文脈を過剰に捨てる可能性がある。デフォルト prompt は、INSOMNIA リポジトリ固有の ticket 運用ではなく、より一般的な「既存の正本をそのまま重複保存しない」程度の方針に留めるべきである。
|
||||
|
||||
## 要件
|
||||
|
||||
- bundled memory prompts から、INSOMNIA プロジェクト固有の ticket / TODO 運用を前提にした禁止文言を削除する
|
||||
- `ticket-file creation / edit`
|
||||
- `TODO updates`
|
||||
- `ticket Y was created`
|
||||
- `ticket file names`
|
||||
- `worker Pod was spawned for Z` が ticket 前提で語られている箇所
|
||||
- `git is authoritative` の扱いを、一般ユーザーに押し付けない表現へ弱める
|
||||
- git / VCS に残る単なるファイル操作ログを memory が逐語的に shadow しない、という原則は残してよい
|
||||
- ただし project management 上の出来事や管理ファイルの内容が、将来の作業判断に効くなら memory へ抽象化して残せる余地を残す
|
||||
- Phase 1 extract prompt と Phase 2 consolidation prompt の両方を整合させる
|
||||
- 必要なら `docs/plan/memory-prompts.md` または `docs/plan/memory.md` に、default prompt は特定プロジェクトの ticket 運用を前提にしないことを明記する
|
||||
- INSOMNIA 自身の運用で ticket shadow を避けたい場合は、bundled default ではなく workspace/user prompt override 側で表現できる状態にする
|
||||
|
||||
## 範囲外
|
||||
|
||||
- memory の file format / linter / Phase 1 / Phase 2 実行機構の変更
|
||||
- 使用頻度メトリクスや Knowledge 化 gate の実装
|
||||
- INSOMNIA プロジェクト自身の ticket 運用の再設計
|
||||
- prompt override 機構そのものの変更
|
||||
|
||||
## 完了条件
|
||||
|
||||
- `resources/prompts/internal/memory_extract_system.md` から ticket / TODO 固有の shadow 禁止が消えている
|
||||
- `resources/prompts/internal/memory_consolidation_system.md` から ticket / TODO 固有の shadow 禁止が消えている
|
||||
- 代替文言が、特定管理手法ではなく「既存の正本と重複しない」「将来の判断に効く抽象だけ残す」という一般原則になっている
|
||||
- default prompt が、ユーザー workspace の project management 手法を固定しない
|
||||
- 既存テスト / prompt catalog 検査が通る
|
||||
|
||||
## 参照
|
||||
|
||||
- `resources/prompts/internal/memory_extract_system.md`
|
||||
- `resources/prompts/internal/memory_consolidation_system.md`
|
||||
- `docs/plan/memory-prompts.md`
|
||||
- `docs/plan/memory.md`
|
||||
|
||||
## Review
|
||||
- 状態: Approve
|
||||
- レビュー詳細: [./memory-prompts-remove-ticket-policy.review.md](./memory-prompts-remove-ticket-policy.review.md)
|
||||
- 日付: 2026-05-09
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
# Review: Memory prompts: project-specific ticket shadow policy を外す
|
||||
|
||||
## 前提・要件の確認
|
||||
|
||||
- bundled memory prompts から ticket / TODO 固有の shadow 禁止を削除: OK。Phase 1 prompt は ticket / TODO / worktree / branch / commit 等の列挙を消し、authoritative project records 一般へ置き換えている（`.worktree/memory-prompts-remove-ticket-policy/resources/prompts/internal/memory_extract_system.md:27-32`）。Phase 2 prompt も `git is authoritative` と ticket/TODO 固有列挙を削除し、issue trackers / task boards / planning documents 等の一般表現へ置換している（`.worktree/memory-prompts-remove-ticket-policy/resources/prompts/internal/memory_consolidation_system.md:21-22`）。
|
||||
- `git is authoritative` の扱いを一般ユーザー向けに弱める: OK。正確な内容の authoritative record を memory が mirror しないという原則は残しつつ、durable project-management facts / workflow constraints / prioritisation rationale / process decisions / cross-item lessons は保存可能と明示している（`memory_extract_system.md:27-32`, `memory_consolidation_system.md:22`）。
|
||||
- Phase 1 / Phase 2 の整合: OK。Phase 1 の抽出除外条件と Phase 2 の統合時ルールがどちらも「raw status ledger は作らないが、持続的な抽象は採用可」という同じ方針になっている（`memory_extract_system.md:29-32`, `memory_consolidation_system.md:22`）。
|
||||
- default prompt が特定 project-management 手法を前提にしないことの文書化: OK。`docs/plan/memory-prompts.md` の共通原則に「特定の project-management 手法を前提にしない」が追加され、ticket / TODO 固有の旧記述が一般化されている（`.worktree/memory-prompts-remove-ticket-policy/docs/plan/memory-prompts.md:19-20`）。
|
||||
- 既存テスト / prompt catalog 検査: OK。`cargo test -p pod prompt::catalog` を実行し、11 tests passed。
|
||||
|
||||
## アーキテクチャ・スコープ
|
||||
|
||||
- 変更は bundled prompt 2 件と plan doc 1 件のみで、memory の file format / linter / Phase 1 / Phase 2 実行機構には触れていない。ticket の範囲外を守っている。
|
||||
- prompt 文言の責務分離は妥当。INSOMNIA 固有の ticket shadow 回避を default prompt から外し、workspace / user prompt override 側へ逃がせる状態にしている。
|
||||
- `docs/plan/memory-prompts.md` も同時に更新しており、実装 prompt と計画文書が乖離していない。
|
||||
|
||||
## 指摘事項
|
||||
|
||||
### Blocking
|
||||
|
||||
なし。
|
||||
|
||||
### Non-blocking / Follow-up
|
||||
|
||||
なし。
|
||||
|
||||
### Nits
|
||||
|
||||
- `docs/plan/memory-prompts.md:68` に「git で可逆」という表現が残っているが、これは tidy phase の drop 判断に関する一般的な VCS 可逆性の話で、ticket / TODO 固有の shadow policy ではないため本チケットの完了を妨げない。
|
||||
|
||||
## 判断
|
||||
|
||||
Approve — ticket / TODO 固有の bundled prompt 方針は削除され、一般的な authoritative record 非重複方針へ置き換わっている。変更範囲も prompt / plan に限定され、既存 prompt catalog tests も通っている。
|
||||
Loading…
Reference in New Issue
Block a user