docs(tickets): completed tickets cleanup

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 する方針）

docs/plan/memory-prompts.md

@@ -17,7 +17,7 @@ memory 関連 prompt は種別を問わず、最低限以下を共有する:
 - **単純 append を優先しない**。既存 record に統合できるなら update を優先する
 - **session 固有の進行状態を書かない**。長期参照価値のある内容だけを memory に残す
 - **既存 docs と重複保存しない**。`AGENTS.md`、`docs/plan/*`、固定運用文書に既にある内容を再保存しない
-- **git で追える事実を memory に書かない**。ticket file の作成・編集、TODO 更新、branch / worktree 操作、commit / merge / push、「commit X で実装した」「ticket Y を作った」「worker Pod を spawn した」等は git diff / log が真実で、memory に写すと陳腐化する。commit ハッシュ・branch 名・worktree パス・ticket file 名・PR 番号と組み合わせないと意味を成さない記録は採用しない
+- **特定の project-management 手法を前提にしない**。既定 prompt は issue tracker / task board / planning doc / changelog / version-control history / generated report などを「正確な内容の authoritative record」として一般化して扱う。memory はそれらの本文・status 変化・短命 identifier をそのまま複製する parallel ledger にはしない。一方で、今後の作業に役立つ持続的な project-management 事実、workflow 制約、優先度判断の根拠、複数 item にまたがる学びは採用してよい
 - **空出力を許容**する。保存価値が無ければ「何も追加しない」を正当な結果として扱う
 
 ### Phase 1: 活動抽出 prompt
@@ -32,10 +32,10 @@ Phase 1 は「派生物を作る」段階ではなく、「起きたことを抽
 
 ノイズ防御として、抽出時点で以下を除外する:
 
-- `attempts`: git で追える操作 (ticket file / TODO 編集、branch / worktree 作成、commit / merge / push、既知 ticket への worker Pod spawn) は除外。残すのは git からは復元できない情報 (ビルド/テスト結果、外部 API 応答、観測されたバグ再現、後段の判断材料となる設計実験結果) に限る
-- `discussions`: 当日中に陳腐化する一過性 triage (「次に着手するチケットはどれか」「いま review すべきか後でか」など) は除外。session を越えて意味を持つ論点 (アーキテクチャの trade-off、恒常的な制約、再来する問い) のみ残す
-- `decisions`: rationale が「この session で X をした」になるものは除外。設計 / 方針 / 取り組み方の根拠でない記録は decision ではなく作業ログ
-- 本文中に commit ハッシュ・branch 名・worktree パス・ticket file 名・PR 番号など陳腐化する identifier を埋め込まない
+- `attempts`: authoritative record の保守や外部 lifecycle の移動そのものだけを表す操作は除外。残すのはその record 自体からは復元できない情報 (ビルド/テスト結果、外部 API 応答、観測されたバグ再現、後段の判断材料となる設計実験結果、持続的な process lesson) に限る
+- `discussions`: 当日中に陳腐化する一過性 triage (直近の scheduling、status 確認、短命な順序決めなど) は除外。session を越えて意味を持つ論点 (アーキテクチャの trade-off、恒常的な workflow 制約、再来する問い) のみ残す
+- `decisions`: rationale が「この session で X をした」になるものは除外。設計 / 方針 / process / 取り組み方の根拠でない記録は decision ではなく作業ログ。ただし、作業管理上の持続的な方針や抽象化は decision として扱える
+- authoritative project record の title / body / checklist / raw status / 短命 identifier を本文に複製しない。正確な status mirror や identifier と組み合わせないと意味を成さない記録は採用しない
 
 ### Phase 2: 統合 + 整理 prompt
 

resources/prompts/internal/memory_consolidation_system.md

@@ -19,7 +19,7 @@ Your initial user message contains the staging entries, the full memory records,
 - **Update over create.** If an existing slug fits, edit it. Only create a new slug when no existing record fits and you can articulate why.
 - **`replaced` over delete.** When a Decision is superseded by a different one, mark the old one `status: replaced` with `replaced_by: <new-slug>`. Do not silently drop it.
 - **Don't duplicate static docs.** Skip content that already lives in `AGENTS.md`, `docs/plan/*`, or other fixed project documents.
-- **git is authoritative.** Do not record facts that git already tracks: ticket-file creation / edit, TODO updates, branch / worktree operations, commit / merge / push events, "implementation landed as commit X", "ticket Y was created", "worker Pod was spawned for Z". Diff and commit log are the truth there; memory shadowing it just rots. If a candidate write only makes sense when paired with a commit hash, branch name, worktree path, or ticket filename, drop it.
+- **Respect authoritative project records.** Issue trackers, task boards, planning documents, changelogs, version-control history, and generated reports are authoritative for their exact contents. Do not mirror them verbatim, preserve raw status churn, or maintain a parallel ledger in memory. Durable project-management facts and abstractions are valid when they help future work: recurring workflow constraints, prioritisation rationale, long-lived ownership / process decisions, and stable lessons that cut across individual items. If a candidate write only makes sense as an exact status mirror or when paired with a transient identifier, drop it.
 - **Empty output is fine.** If a staging entry doesn't justify a memory write, skip it.
 - **Slug rules.** Slugs are kebab-case, short, recognisable, and must be unique within their kind. Same-slug create is a linter error — use Edit instead.
 - **Linter errors come back as tool errors.** When the memory linter rejects a write, read the error, fix the issue (missing frontmatter field, oversized body, unknown reference, etc.), and try again. Do not work around the rule.

resources/prompts/internal/memory_extract_system.md

@@ -24,11 +24,11 @@ Your single job: read the supplied conversation slice and emit a structured JSON
 
 # Anti-noise rules
 
-git is the source of truth for what happened to files, branches, commits, tickets, and worktrees. Memory must NOT shadow it.
+Authoritative project records (issue trackers, task boards, planning documents, changelogs, version-control history, generated reports) are the source of truth for their exact contents. Memory must not mirror those records verbatim or maintain a parallel status ledger, but it may capture durable project-management facts, workflow constraints, recurring patterns, and abstractions when they will help future work.
 
-- `attempts`: skip any action whose substance is a git-trackable operation — creating / editing a ticket file, adding a TODO entry, opening a branch / worktree, running `commit` / `merge` / `push`, spawning a worker Pod for a known ticket. The corresponding diff / commit log already records it. Keep `attempts` for things that are NOT recoverable from git: build / test outcomes, external API responses, observed bug reproductions, design experiments whose results inform later judgement.
-- `discussions`: skip transient triage that goes stale within the day — "which ticket to start next", "should we review now or later", checklist-style status reads. Keep discussions whose points outlive the session (architectural trade-offs, durable constraints, recurring questions).
-- `decisions`: the rationale must be a design / policy / approach reason, not "we did X in this session". Recording "a ticket was created for Y" or "implementation landed as commit Z" is NOT a decision — those belong to git, not memory.
-- Do not embed identifiers that age out of relevance: commit hashes, branch names, worktree paths, ticket file names, PR numbers. If a record is only meaningful with such an identifier, the record itself is probably session-local and should be skipped.
+- `attempts`: skip actions whose only substance is maintaining an authoritative record or moving an item through an external lifecycle. Keep attempts for outcomes that are not captured by that record itself: build / test outcomes, external API responses, observed bug reproductions, design experiments, and process lessons that inform later judgement.
+- `discussions`: skip transient triage that goes stale within the day — immediate scheduling, checklist-style status reads, or short-lived sequencing choices. Keep discussions whose points outlive the session (architectural trade-offs, durable process constraints, recurring workflow questions).
+- `decisions`: the rationale must be a design / policy / process / approach reason, not "we did X in this session". Recording that an item was filed, completed, or moved through a lifecycle is NOT a decision; recording the durable policy or abstraction behind that workflow can be.
+- Avoid copying titles, bodies, checklists, raw statuses, or short-lived identifiers from authoritative project records. If a record is only meaningful as an exact status mirror or with a transient identifier, the record itself is probably session-local and should be skipped.
 
 When you have produced the JSON, call `write_extracted` and end the turn. No follow-up text.

tickets/client-crate.md

@@ -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

tickets/client-crate.review.md

@@ -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 の指摘は本チケットの完了を妨げない。

tickets/memory-prompts-remove-ticket-policy.md

@@ -1,46 +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`