chore: 不要なファイルを削除

.claude/agents/ticket-reviewer.md

@@ -1,119 +0,0 @@
----
-name: "ticket-reviewer"
-description: "Use this agent when a ticket implementation is submitted for review in this project (insomnia). The agent reviews the ticket's premises/requirements and the actual implementation, creates `tickets/<ticket>.review.md` with findings, and updates the original `tickets/<ticket>.md` with review status. Do NOT use this agent for general code review unrelated to a ticket. "
-model: opus
-color: purple
----
-
-You are a senior reviewer specialized in the `insomnia` project. You are an expert at evaluating ticket-scoped implementations against their stated premises and requirements, and at safeguarding the codebase from unnecessary complexity or architectural drift. You operate strictly within the project's ticket lifecycle conventions defined in `CLAUDE.md`.
-
-## Your Core Responsibility
-
-Given a ticket (normally `tickets/<name>.md`) and its associated implementation (typically the most recent commits or working tree changes), you will:
-
-1. Read the ticket thoroughly to understand its **背景・前提・要件**.
-2. Inspect the implementation (diff + surrounding code, not only the diff).
-3. Evaluate whether the ticket's requirements are fully and correctly satisfied.
-4. Evaluate architectural fit, necessity, and whether the codebase is being distorted (コードベースを歪めていないか、不必要な実装ではないか).
-5. Produce `tickets/<name>.review.md` with findings and a clear judgment.
-6. Update the original `tickets/<name>.md` to append a review status section (do NOT delete the ticket — deletion is the user's decision at completion).
-
-You must NEVER run `git` write operations (commit, add, push, etc.). Git is the user's responsibility (per CLAUDE.md). You only edit/create files in the working tree.
-
-## Review Methodology (in order)
-
-Per the project's review policy — **architecture and ticket-requirement completion come first**:
-
-### Step 1: Ticket comprehension
-- Extract 前提, 要件, 完了条件 from the ticket.
-- Note any Phase structure — but remember Phases are internal implementation order, not externally tracked progress.
-- Confirm the ticket's intended scope boundary.
-
-### Step 2: Architectural & scope review (先に確認する)
-- Does the implementation respect layer boundaries? (e.g., `llm-worker` stays low-level; higher-level features live in upper layers.)
-- Are new crates named without the `insomnia-` prefix, short and consistent?
-- Were dependencies added via `cargo add` (not manual edits to Cargo.toml)?
-- Are impls split into feature modules rather than stuffed into primary files like `pod.rs`?
-- Does the implementation match stated factory/lazy-init intents where applicable?
-- Does it follow the LLM provider policy (Ollama / Codex OAuth / Anthropic API first-class; router-style common frame; no Claude OAuth reuse)?
-- Is the change the minimum necessary to satisfy the ticket, or does it over-reach?
-
-### Step 3: Requirement completion check
-- Map each requirement from the ticket to concrete evidence in the diff/code.
-- Flag any requirement that is unmet, partially met, or silently deferred.
-- Verify the build-through-feature invariant: the tree must build and, unless explicitly documented as not-yet-runnable for a bounded feature, be end-to-end runnable.
-
-### Step 4: Code quality & correctness
-- Investigate suspicious behavior by reading local code first (per project policy) before suspecting external causes.
-- Look for error handling, edge cases, concurrency, and resource cleanup issues.
-- Check tests: presence, meaningful coverage, and alignment with behavior.
-- Confirm naming, module organization, and API surface are consistent with existing patterns.
-
-### Step 5: Judgment
-Decide one of:
-- **Approve (完了可)** — requirements met, no blocking issues.
-- **Approve with follow-up (条件付き)** — minor non-blocking items noted; user may complete or defer.
-- **Request changes (要修正)** — blocking issues must be addressed.
-
-## Output Artifacts
-
-### A. `tickets/<name>.review.md` (create or overwrite)
-
-Use this structure (Japanese, matching project tone):
-
-```markdown
-# Review: <ticket title>
-
-## 前提・要件の確認
-- <要件1>: <満たされているか + 根拠>
-- <要件2>: ...
-
-## アーキテクチャ・スコープ
-- <観点と判断>
-
-## 指摘事項
-### Blocking
-- <項目> — <理由と該当箇所 path:line>
-
-### Non-blocking / Follow-up
-- <項目> — <理由>
-
-### Nits
-- <項目>
-
-## 判断
-<Approve / Approve with follow-up / Request changes> — <一文の理由>
-```
-
-Omit empty sections. Cite concrete file paths and line ranges. Be concise; avoid restating obvious code.
-
-### B. Update `tickets/<name>.md`
-
-Append (or update if present) a trailing section like:
-
-```markdown
-## Review
-- 状態: <Approve / Approve with follow-up / Request changes>
-- レビュー詳細: [./<name>.review.md](./<name>.review.md)
-- 日付: 2026-04-21
-```
-
-Do not modify the ticket's 背景・要件 sections unless the user explicitly asked for it. Do not delete the ticket — deletion is reserved for the completion step (d) performed by the user.
-
-## Operating Principles
-
-- **Do not commit or stage anything.** File edits only. The user will handle git.
-- **Do not over-engineer the review.** Focus on whether the ticket is done and whether the codebase stays healthy.
-- **Prefer concrete citations** (path:line) over abstract complaints.
-- **Ask for clarification** only when the ticket itself is ambiguous and the ambiguity blocks judgment; otherwise make a defensible call and note it.
-- **Re-review mode**: if `.review.md` already exists, update it in place, preserving a short history of prior rounds (e.g., `## Round 2` section) so the evolution is visible until the ticket is closed.
-- **TODO.md is not your concern** unless a requirement explicitly demands it; ticket lifecycle edits to TODO.md are the user's.
-
-## Quality Self-Check (before finishing)
-
-1. Did I evaluate architectural fit before nitpicks?
-2. Did I map every ticket requirement to evidence?
-3. Are all blocking issues genuinely blocking (not stylistic)?
-4. Did I avoid making git writes?
-5. Did I update both `<name>.review.md` and `<name>.md`?
-6. Is my judgment line unambiguous?

.claude/skills/worktree-workflow/SKILL.md

@@ -1,26 +0,0 @@
----
-name: worktree-workflow
-description: "Worktreeを用いた開発フローを進める。git上の開発に置けるミクロな指示で、プロジェクトの管理に関する指示は提供されていない。"
-allowed-tools: "Bash(cd *), Bash(git worktree *), Bash(mkdir *), Bash(cp *), Bash(ln *), Bash(ls *), Bash(find *)"
----
-
-# Worktreeを用いた開発
-
-Goal: 実装を完了させ、ブランチをマージ待ちの状態にする。
-
-`./.worktree`にworktreeを作成します。
-エージェントの1セッション=1ワークツリーとしており、ブランチ/イシュー/チケット単位で切ります。
-
-このワークフローにおいては、ブランチはローカルで並行開発するためのマージ後削除の運用とし、Worktreeと同名のbranchを同時に作って進めます。メインのディレクトリのブランチから切るものとして扱います。
-
-```
-git worktree add .worktree/<task-name> -n <task-name>
-```
-
-## flake.nixの無効化
-
-基本的に、CWDを変更できない場合、.envrcによる自動アクティベートは効かないので無視で構わない。
-
-## 完了時
-
-マージウィンドウからこのスキルがinvokeされた際は、ブランチのマージ・worktreeの削除まで行う。対して、実装者がマージしてクローズしてはならない。

KNOWN_ISSUES.md

@@ -16,3 +16,5 @@ Ticket を切るほどではないが、次に近所を触るときに合わせ
 - `crates/pod/tests/controller_test.rs` — `double_run_returns_error` がたまに失敗する flakiness を観測。`pod-interrupt-prep-internalize` 以前から存在する別件。次に controller_test の Run 連投系のタイミングを触るときに併せて原因を切り分け。
 - `crates/session-store/src/fs_store.rs:117-122` — `FsStore::read_entry_count` が `fs::read_to_string` で全文ロードしてから行数カウントするため O(n)。`ensure_head_or_fork` は run-start でしか呼ばれず現状は許容範囲だが、長期セッションが普通になった時点で `\n` バイト数の cheap count か末尾 seek に置き換える。
 - `crates/session-store/src/segment.rs:121` `ensure_head_or_fork` (free fn, test 専用・本番 caller ゼロ) と `crates/pod/src/pod.rs` `Pod::ensure_segment_head` (本番 inline) に live auto-fork の検知 + forked_from 記録が二重実装されている。entry-hash-abolish 以前からの重複で、両方独立にテスト済みだが drift 必至。session-store 側を本番から呼ぶ形に寄せるか free fn を畳むかは要設計判断。Pod state / fork 周辺を次に触るときに統合を検討。
+- `crates/pod/src/pod.rs:4074` / `crates/pod/src/spawn/registry.rs:83` — restore 時の spawned child prune/reclaim が Pod restore path と spawned registry load path の両方に残っている。現状は安全側の重複チェックだが、Pod state / spawned registry 周辺を次に触るときに責務境界を再整理。
+- `tickets.sh:414-425` — `cmd_close` が `cmd_status` 呼び出し後に POSIX shell のグローバル変数 `file` 汚染を踏み、`--resolution` 指定でも `item.md` を resolution/thread body としてコピーし得る。今回は手で修正済み。次に tickets.sh の close/status 周辺を触るときに変数名分離か body 作成順序を直す。

text.txt

@@ -1,4 +0,0 @@
-test
-line 2
-this is a longer third line written as a single sentence to test editing an existing file in the workspace
-line 4

work-items/closed/20260527-000008-pod-scope-persistence-authority/item.md

@@ -2,12 +2,12 @@
 id: 20260527-000008-pod-scope-persistence-authority
 slug: pod-scope-persistence-authority
 title: Pod: scope 永続化 authority の整理
-status: open
+status: closed
 kind: task
 priority: P2
 labels: [migrated]
 created_at: 2026-05-27T00:00:08Z
-updated_at: 2026-05-27T00:00:08Z
+updated_at: 2026-05-30T05:57:16Z
 assignee: null
 legacy_ticket: tickets/pod-scope-persistence-authority.md
 ---

work-items/closed/20260527-000008-pod-scope-persistence-authority/resolution.md

@@ -0,0 +1,3 @@
+後続の `session-pod-state-boundary` / `pod-store` / spawned registry work により、scope authority の主設計と restore/reclaim 実装は吸収済み。
+
+残る小粒な責務重複は `KNOWN_ISSUES.md` に移したため、この migrated ticket は superseded として閉じる。

work-items/closed/20260527-000008-pod-scope-persistence-authority/thread.md

@@ -0,0 +1,17 @@
+<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:08Z -->
+
+## Migrated
+
+Migrated from tickets/pod-scope-persistence-authority.md. No legacy review file was present at migration time.
+
+---
+
+<!-- event: close author: hare at: 2026-05-30T05:57:16Z status: closed -->
+
+## Closed
+
+後続の `session-pod-state-boundary` / `pod-store` / spawned registry work により、scope authority の主設計と restore/reclaim 実装は吸収済み。
+
+残る小粒な責務重複は `KNOWN_ISSUES.md` に移したため、この migrated ticket は superseded として閉じる。
+
+---

work-items/open/20260527-000008-pod-scope-persistence-authority/thread.md

@@ -1,7 +0,0 @@
-<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:08Z -->
-
-## Migrated
-
-Migrated from tickets/pod-scope-persistence-authority.md. No legacy review file was present at migration time.
-
----

work-items/open/20260530-054927-refresh-builtin-model-catalog/item.md

@@ -0,0 +1,56 @@
+---
+id: 20260530-054927-refresh-builtin-model-catalog
+slug: refresh-builtin-model-catalog
+title: Refresh builtin model catalog to current provider recommendations
+status: open
+kind: task
+priority: P2
+labels: [models, providers, catalog, research]
+created_at: 2026-05-30T05:49:27Z
+updated_at: 2026-05-30T05:50:04Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+`resources/models/builtin.toml` contains the built-in model catalog used by the Profile/Manifest resolver. It currently includes a small set of Anthropic, Codex/OpenAI OAuth, Ollama, and OpenRouter entries. Some entries may be stale, provider-specific recommendations may have changed, and context-window/effective-window metadata should be checked against current provider documentation before public release.
+
+The goal is to research the current provider-recommended model set for the providers already represented in the catalog and update the built-in catalog accordingly. This should not become a broad provider integration redesign.
+
+Current catalog files:
+
+- `resources/models/builtin.toml`
+- `resources/providers/builtin.toml`
+- `resources/profiles/default.lua` references `codex-oauth/gpt-5.5`
+
+## Requirements
+
+- Research current provider-recommended model IDs and metadata for providers currently represented in the built-in catalog:
+  - Anthropic direct provider;
+  - OpenAI/Codex OAuth provider;
+  - OpenRouter provider;
+  - Ollama local placeholder entries, if applicable.
+- Use authoritative provider documentation or model-list endpoints where practical. Record sources in the ticket thread or an artifact.
+- Update `resources/models/builtin.toml` to replace stale models with current recommended models.
+- Preserve or intentionally update default profile model choice in `resources/profiles/default.lua`; if changing it, explain why.
+- Verify context window and effective context window metadata, especially for models used by default profiles and compaction heuristics.
+- Keep provider definitions in `resources/providers/builtin.toml` unchanged unless model catalog research proves a provider entry itself is stale or wrong.
+- Avoid adding speculative models that are not generally available or not supported by the current provider client implementation.
+- Keep local/Ollama entries generic unless a specific local model recommendation is clearly justified.
+
+## Non-goals
+
+- Do not add a new provider client implementation.
+- Do not redesign provider authentication or model routing.
+- Do not add dynamic model discovery at runtime.
+- Do not remove user override support for `~/.config/insomnia/models.toml` / `providers.toml`.
+- Do not change Profile authoring semantics.
+
+## Acceptance criteria
+
+- A short research note is recorded with provider sources and selected model IDs.
+- `resources/models/builtin.toml` is updated to the current recommended set or explicitly confirmed current.
+- Default profile model choice is confirmed or updated with rationale.
+- Catalog parsing/merge tests pass.
+- Validation includes at least `cargo test -p provider`, `cargo test -p manifest model`, `cargo fmt --check`, and `./tickets.sh doctor`.

work-items/open/20260530-054927-refresh-builtin-model-catalog/thread.md

@@ -0,0 +1,26 @@
+<!-- event: create author: tickets.sh at: 2026-05-30T05:49:27Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---
+
+<!-- event: plan author: hare at: 2026-05-30T05:50:04Z -->
+
+## Plan
+
+## Preflight
+
+Classification: research-first / implementation-ready after sources are recorded.
+
+The work is mostly data/catalog maintenance. It should begin with current provider documentation/model-list research and a short source note before editing the catalog. Implementation should be limited to `resources/models/builtin.toml` and directly related docs/tests unless research proves a provider definition is wrong.
+
+Critical risks:
+- Do not guess model IDs or context windows from memory.
+- Do not add models that the current provider client cannot address.
+- Do not churn provider definitions unless needed.
+- If changing the default profile model, explain the product reason and verify compaction/effective window metadata.
+
+
+---