.yoi/objectives/20260609-070926-001/item.md

@@ -1,60 +0,0 @@
----
-title: "E2E テスト戦略"
-state: "active"
-created_at: "2026-06-09T07:09:26Z"
-updated_at: "2026-06-09T07:09:26Z"
-linked_tickets: ["20260527-000002-001"]
----
-
-## Goal
-
-Yoi の実プロセス・実 socket・実 provider 境界をまたぐ振る舞いを、通常の crate 内 unit / integration test だけに頼らず検証できる E2E テスト戦略を確立する。
-
-最初の到達点は、実 `pod` / product binary を spawn し、protocol 経由で最小シナリオを実行し、graceful shutdown まで確認できる opt-in E2E harness を持つこと。その上で、permission、resume/fork、spawned Pod、provider stream、TUI/Panel などの重要境界を段階的に増やせる状態にする。
-
-## Motivation / background
-
-現状のテストは crate 内の in-process coverage が厚い一方で、以下の性質は単体テストだけでは十分に確認しづらい。
-
-- 実プロセス spawn と runtime dir / socket / env の相互作用。
-- Pod controller / protocol client / session store / metadata / restore の統合挙動。
-- provider endpoint、streaming、auth/token、tool call、continuation、retry の実接続に近い振る舞い。
-- permission deny、scope、manifest/profile 解決、child Pod delegation など、複数 crate と実 runtime state をまたぐ policy。
-- TUI / Panel が前提にする Pod lifecycle や Ticket orchestration の外形。
-
-E2E は常時実行の軽いテストではなく、dogfooding 中に「この機能は実 runtime でも壊れていない」と確認するための opt-in 検証基盤として必要。
-
-## Strategy / design direction
-
-- E2E は通常の `cargo test --workspace` からは外し、明示 feature / 専用 package / 独立 job で opt-in 実行する。
-- まずはワークスペース直下の専用 E2E package / harness として設計し、個別 crate の unit test に押し込めない。
-- protocol を喋る側は TUI の PTY 操作ではなく、typed client / protocol client を使う方向を優先する。
-- provider 依存は最初から全部を対象にしない。
-  - 最小 harness では canned / fixture / mock HTTP server を使う。
-  - provider 差分は代表 provider から段階的に増やす。
-- env / runtime dir / socket path は test ごとに隔離し、並列実行方針を明示する。
-  - 必要なら最初は `--test-threads=1` 相当で安全側に倒す。
-  - 将来的には per-test runtime dir と typed launch config で並列性を上げる。
-- E2E は「全シナリオを大量に持つ」より、重要な runtime seam ごとに少数の高価値 scenario を置く。
-- 失敗時 diagnostics は、secret を出さずに process phase、socket path、session id、log path、provider fixture id を辿れる形にする。
-- E2E harness 自体が flaky にならないよう、network / time / external auth への依存は明示 opt-in に分ける。
-
-## Success criteria / exit conditions
-
-- `cargo test --workspace` では E2E が走らず、通常開発の feedback loop を重くしない。
-- 明示コマンドで E2E harness を実行できる。
-  - 例: `cargo test -p e2e --features e2e` または後続で決める同等コマンド。
-- 最小 scenario が実 `pod` / product binary を spawn し、protocol 経由で 1 turn 実行し、graceful shutdown まで通る。
-- E2E 実行は専用 runtime/data dir を使い、通常の user/workspace state を汚さない。
-- fixture / mock provider の設計があり、少なくとも 1 provider 相当の canned response を実 HTTP 経由で返せる。
-- failure diagnostics から、spawn 失敗・socket 接続失敗・provider fixture 失敗・protocol 失敗・shutdown 失敗を区別できる。
-- 後続 Ticket が permission / resume / fork / spawned Pod / provider streaming / Panel などを追加できる harness boundary がある。
-
-## Decision context
-
-- linked Ticket `20260527-000002-001` は、E2E harness の最初の concrete implementation Ticket として扱う。
-- この Objective は E2E 全体の中長期方針・判断軸を保持する。個別 scenario の実装や harness の細部は concrete Ticket に分ける。
-- TUI を直接 PTY で叩く方針は初期 harness では避け、protocol/client 経由を優先する。
-- provider 全対応は初期 scope にしない。fixture / mock HTTP server を基礎にし、代表 provider から段階的に広げる。
-- E2E は flakiness と実行コストが高いため、既定 CI / 既定 workspace test には入れず、opt-in 検証として始める。
-- Objective context は判断材料であり、実装 authority は各 Ticket の body/thread/artifacts と明示的な Ticket relation / OrchestrationPlan に置く。

.yoi/tickets/20260527-201313-001/item.md

@@ -1,14 +0,0 @@
----
-title: "OpenAI Responses 未対応 SSE event を破棄せず観測する"
-state: "closed"
-created_at: "2026-05-27T20:13:13Z"
-updated_at: "2026-05-27T20:44:19Z"
----
-
-## Background
-
-Created by tickets.sh.
-
-## Acceptance criteria
-
-- TBD

.yoi/tickets/20260601-021104-001/resolution.md

@@ -1,21 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added persistent TUI composer recall history per workspace.
-- Stores history under the user data dir at `composer-history/workspaces/<workspace-label>-<fnv64-key>/history.json`, not under workspace `.yoi/`.
-- Stores workspace metadata and typed `Segment` vectors, not flattened strings.
-- Persists only non-blank submissions, suppresses consecutive duplicates, and bounds history to 30 entries per workspace.
-- Preserves TUI-local/non-destructive recall semantics: recall does not mutate Pod protocol, worker history, session transcript, model context, or conversation state until explicit submit.
-- Corrupt history files fall back to empty history with a bounded generic warning.
-
-Implementation:
-- Coder commit: `64b7ff7 tui: persist composer history`
-- Reviewer approved with no blocking findings.
-- Merge commit: `b616420 merge: persist tui composer history`
-
-Validation after merge:
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`

.yoi/tickets/20260607-020215-001/resolution.md

@@ -1,13 +0,0 @@
-Closed as an obsolete umbrella/progress-container Ticket.
-
-This Ticket's original role was to collect the broad Panel Queue -> Orchestrator automation effort. That umbrella pattern is now deprecated: concrete work should live in implementable Tickets, medium-term context should live in Objectives, and Ticket relations should remain non-hierarchical.
-
-The concrete slices recorded in this Ticket thread were split out and handled separately:
-
-- `orchestrator-queued-ticket-routing`
-- `orchestrator-worktree-agent-routing`
-- `orchestrator-merge-completion`
-
-Remaining or follow-up concerns are tracked by concrete Tickets/Objectives instead of this umbrella, including active queued-work planning/re-kick, non-hierarchical Ticket relations, Objective records, and umbrella deprecation work.
-
-This close does not assert that every future Panel Queue -> Orchestrator concern is complete; it retires this Ticket as a broad container.

.yoi/tickets/20260607-095142-001/item.md

@@ -1,14 +0,0 @@
----
-title: "Keep workspace Orchestrator spawn diagnostics visible"
-state: "closed"
-created_at: "2026-06-07T09:51:42Z"
-updated_at: "2026-06-07T10:16:08Z"
----
-
-## Background
-
-Created by LocalTicketBackend.
-
-## Acceptance criteria
-
-- TBD

.yoi/tickets/20260607-213808-001/resolution.md

@@ -1,3 +0,0 @@
-Closed as completed.
-
-The workspace panel bare-letter shortcut issue was implemented and the Ticket was already in `state: done`. This close records final lifecycle completion; implementation details and review history remain in `thread.md`.

.yoi/tickets/20260607-223233-001/resolution.md

@@ -1,3 +0,0 @@
-Closed as completed.
-
-The YAML frontmatter parsing work was implemented and the Ticket was already in `state: done`. This close records final lifecycle completion; implementation details, validation, and review history remain in `thread.md`.

.yoi/tickets/20260607-230044-001/resolution.md

@@ -1,3 +0,0 @@
-Closed as completed.
-
-The implementation-planning readiness relaxation work was implemented and the Ticket was already in `state: done`. This close records final lifecycle completion; decisions and validation history remain in `thread.md`.

.yoi/tickets/20260608-071722-001/resolution.md

@@ -1,21 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Strengthened Orchestrator routing guidance so `ready` / `queued` Tickets are returned to `planning` only when a concrete missing decision/information remains after bounded project-context checks.
-- Clarified risk flags, risky domains, and authority-adjacent work as context lookup / reviewer-focus / escalation signals rather than automatic stop gates.
-- Added risky-but-specified guidance and an `allow-spawnpod-child-workspace-cwd`-style example for proceeding with reviewer focus when work is specified.
-- Aligned `ticket-preflight-workflow`, `multi-agent-workflow`, and work-item docs with the same policy.
-- Preserved workflow_state semantics and did not reintroduce preflight/readiness as a separate state or lane.
-
-Implementation:
-- Coder commit: `8576615 workflow: tighten orchestrator planning return policy`
-- Reviewer approved with no blocking findings.
-- Merge commit: `5af58b5 merge: tighten orchestrator planning return policy`
-
-Validation after merge:
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-`cargo check --workspace` was intentionally omitted because the merged implementation is workflow/docs text only and no Rust code/tests changed; Nix build covered resource/package integrity.

.yoi/tickets/20260608-071722-001/thread.md

@@ -1,295 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-08T07:17:22Z -->
-
-## Created
-
-Created by LocalTicketBackend create.
-
----
-
-<!-- event: plan author: intake at: 2026-06-08T10:58:22Z -->
-
-## Plan
-
-Intake refinement: implementation_ready
-
-Context checked:
-- Target Ticket body/thread.
-- `replace-intake-state-with-planning` resolution: planning-state model is settled and `ready|queued -> planning` now requires audited typed state-change reasons.
-- `allow-spawnpod-child-workspace-cwd` resolution: confirms the motivating authority-adjacent example was risky but sufficiently specified and should be treated as reviewer focus when binding decisions exist.
-- Current `.yoi/workflow/ticket-orchestrator-routing.md`: already contains the routing surface to refine, including `return_to_planning`, `implementation_ready`, `Evidence checked`, and IntentPacket sections.
-
-Binding decisions / invariants:
-- Returning a ready/queued Ticket to `planning` must require a concrete missing decision/information item after bounded relevant context checking.
-- Risk flags and risky domains are context lookup triggers and reviewer-focus signals, not stop gates.
-- If no concrete gap can be named after context checking, risky-but-specified Tickets should route as `implementation_ready` when other criteria are satisfied.
-- The routing decision record must expose checked evidence and explain why any gap cannot be safely handled as implementation latitude.
-- Do not reintroduce a separate readiness/preflight lane or operation.
-
-Implementation latitude:
-- Implementation may choose whether to refine only `.yoi/workflow/ticket-orchestrator-routing.md`, related prompt resources, focused tests, or all of those if the current code layout requires it.
-- Wording and test structure may be chosen locally as long as the policy is explicit and reviewer can verify the acceptance criteria.
-
-Escalation conditions:
-- Escalate if implementation would change the workflow-state graph or Ticket lifecycle semantics beyond the documented `planning -> ready -> queued -> inprogress -> done` model.
-- Escalate if enforcing evidence recording requires new public API/tool schema changes rather than workflow/prompt/test updates.
-- Escalate if the existing prompt/workflow guidance is already fully compliant and no meaningful code/resource change is needed; record a close-ready/no-op dossier instead of manufacturing churn.
-
-Validation:
-- `target/debug/yoi ticket doctor`
-- `git diff --check`
-- Focused prompt/workflow validation or tests covering: risky but specified Ticket -> implementation-ready; genuinely missing decision -> return to planning; risk flag alone is insufficient as the reason.
-- `nix build .#yoi` if runtime resources, prompts, code, or packaging inputs change.
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-08T10:58:29Z -->
-
-## Intake summary
-
-既存 Ticket を重複作成せず refinement した。`replace-intake-state-with-planning` の完了により前提は満たされており、対象 Ticket は Orchestrator routing guidance の bounded context check policy として implementation_ready。binding invariants、implementation latitude、escalation conditions、validation を thread に補足済み。未決定の blocking question はない。risk flags は workflow/prompt、orchestrator-routing、planning-state、authority-boundary/context-check。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-08T10:58:29Z from: planning to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake refinement completed. Ticket has enough intent, acceptance criteria, binding invariants, implementation latitude, escalation conditions, and validation guidance for Orchestrator routing.
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T00:04:21Z from: ready to: queued reason: queued field: workflow_state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T00:06:25Z from: queued to: inprogress reason: orchestrator_acceptance field: workflow_state -->
-
-## State changed
-
-Accepted queued implementation after reading the Ticket, current Orchestrator routing workflow guidance, workspace state, visible Pod/worktree state, and the recently merged orchestration-plan/tool changes. No active implementation worktree is present; the requested change is bounded to routing prompt/workflow guidance and tests/resources.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T00:06:25Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body and acceptance criteria for `orchestrator-return-to-planning-context-policy`.
-- Current `.yoi/workflow/ticket-orchestrator-routing.md`, including existing `return_to_planning`, `implementation_ready`, and queued acceptance sections.
-- Current workspace/worktree state after merging and cleaning up the previous TUI/composer work.
-- Visible Pod state: no active sibling coder/reviewer for earlier work remains.
-- Recent merged context: `replace-intake-state-with-planning`, `ticket-orchestration-plan-tool`, and queued-routing behavior already require explicit queued acceptance and durable evidence.
-- `TicketOrchestrationPlanQuery` is documented in the workflow, but this current orchestrator session's tool list does not expose the newly merged tool, so there was no callable plan-query surface to inspect for this Ticket.
-
-Reason:
-- The Ticket has concrete requirements and acceptance criteria.
-- The change is policy/prompt/workflow guidance, not a broad runtime redesign.
-- Current workflow text already contains some related clauses, so implementation should be a bounded tightening: make the evidence/context requirement explicit, ensure risky-but-specified Tickets can proceed, and add/adjust focused validation.
-
-IntentPacket:
-
-Intent:
-- Strengthen Orchestrator routing guidance so returning ready/queued Tickets to `planning` requires concrete missing information/decision evidence after bounded project-context checks, not just Ticket text or risk flags.
-
-Binding decisions / invariants:
-- Do not reintroduce a separate readiness/preflight state or lane.
-- Do not change Ticket workflow states or transition semantics.
-- Do not make every queued Ticket require broad repository archaeology.
-- Risk flags and risky domains are context lookup and reviewer-focus signals, not automatic stop gates.
-- If returning to planning, the routing record must include the concrete missing decision/information, context checked, why implementation latitude is insufficient, and the next planning question/action.
-- If no concrete missing item remains after bounded context checks, a risky-but-specified Ticket should proceed as implementation_ready with IntentPacket invariants, escalation conditions, and reviewer focus.
-- Keep the change in maintained routing workflow/prompt/resource docs and focused validation; avoid runtime scheduler/orchestration refactors.
-
-Implementation latitude:
-- Coder may update `.yoi/workflow/ticket-orchestrator-routing.md`, resource prompts/workflows, and tests that validate workflow/prompt guidance.
-- If there is no existing prompt-resource test harness, coder may add a narrow text validation test in the most appropriate existing crate, or document why focused grep/resource validation is the right evidence.
-- Include or reference an example equivalent to `allow-spawnpod-child-workspace-cwd`: authority-adjacent but specified work should proceed with reviewer focus rather than return to planning solely because it touches authority/scope/Pod concerns.
-
-Escalate if:
-- Implementation requires changing Ticket backend workflow_state semantics.
-- Existing tests/resources imply a conflicting policy that must be resolved by human decision.
-- A broad prompt/workflow templating redesign would be needed instead of a narrow guidance update.
-
-Validation:
-- Focused workflow/prompt validation or tests covering: risky but specified Ticket -> implementation-ready; genuinely missing decision -> return to planning; risk flag alone is insufficient.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor`.
-- `cargo check --workspace` if code/tests are touched.
-- `nix build .#yoi` if resources/tests/package inputs are touched.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T00:07:10Z -->
-
-## Implementation report
-
-Implementation routing started.
-
-Worktree/branch:
-- Worktree: `.worktree/orchestrator-return-to-planning-context-policy`
-- Branch: `orchestrator-return-to-planning-context-policy`
-- Base/routing commit: `9f35442 ticket: route return-to-planning policy`
-
-Spawned sibling Coder Pod:
-- `coder-orchestrator-return-to-planning-context-policy`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- The previous composer-history implementation was merged, validated, closed, and cleaned up before this new queued Ticket was accepted.
-- This Ticket is now the active routed implementation work.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T00:19:47Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-orchestrator-return-to-planning-context-policy`
-- Commit: `8576615 workflow: tighten orchestrator planning return policy`
-- Worktree status before review: clean branch `orchestrator-return-to-planning-context-policy`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Implementation summary:
-- Tightened Orchestrator routing workflow so returning `ready` / `queued` Tickets to `planning` requires concrete missing decision/information evidence after bounded project-context checks.
-- Clarified risk flags / risky domains / authority-adjacent work as context lookup, IntentPacket invariant, reviewer-focus, and escalation signals rather than automatic stop gates.
-- Added risky-but-specified guidance and an `allow-spawnpod-child-workspace-cwd`-style example for proceeding with reviewer focus when work is specified.
-- Updated related planning/preflight and multi-agent workflow wording plus work-item docs.
-
-Changed files:
-- `.yoi/workflow/ticket-orchestrator-routing.md`
-- `.yoi/workflow/ticket-preflight-workflow.md`
-- `.yoi/workflow/multi-agent-workflow.md`
-- `docs/development/work-items.md`
-
-Coder validation reported passed:
-- Focused workflow/prompt text validation for risky-but-specified -> implementation_ready, genuinely missing decision -> return_to_planning, and risk flag alone insufficient.
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-Coder did not run `cargo check --workspace` because only docs/workflow resources changed.
-
----
-
-<!-- event: review author: reviewer at: 2026-06-09T00:23:32Z status: approve -->
-
-## Review: approve
-
-Review result: approve
-
-Scope reviewed:
-- Commit `8576615` (`workflow: tighten orchestrator planning return policy`).
-- Changed files: `.yoi/workflow/ticket-orchestrator-routing.md`, `.yoi/workflow/ticket-preflight-workflow.md`, `.yoi/workflow/multi-agent-workflow.md`, `docs/development/work-items.md`.
-- Ticket body/thread and orchestration plan records for this Ticket (`TicketOrchestrationPlanQuery`: 0 records).
-- Targeted stale-guidance search across `.yoi/workflow`, `docs`, and `resources/prompts` for preflight/planning/risk/return-to-planning terminology.
-
-Findings:
-- No separate readiness/preflight state or lane is reintroduced. `ticket-orchestrator-routing.md` keeps workflow_state as `planning -> ready -> queued -> inprogress -> done` and describes `ticket-preflight-workflow` only as a legacy planning/requirements-sync slug; `ticket-preflight-workflow.md` explicitly says not to treat `preflight` as a state/lane/current metadata vocabulary.
-- Ticket workflow-state and queued acceptance semantics remain unchanged. The updated guidance still requires `queued -> inprogress` before worktree/spawn/implementation side effects and does not add a new transition.
-- Returning `ready`/`queued` Tickets to `planning` now requires concrete missing decision/information plus checked context, why implementation latitude is insufficient, and next planning question/action.
-- Risk flags/risky domains are consistently documented as bounded context lookup, IntentPacket/reviewer focus, and escalation signals rather than automatic stop gates.
-- The guidance stays bounded: it names targeted context sources and explicitly says the purpose is not broad repository archaeology.
-- Risky-but-specified work is allowed to proceed as `implementation_ready`; the routing examples include the required `allow-spawnpod-child-workspace-cwd`-equivalent authority/scope/Pod example with reviewer focus rather than planning return solely for risk category.
-- Maintained workflow/docs are aligned. I did not find conflicting authority-adjacent automatic-stop wording in `.yoi/workflow`, `docs`, or `resources/prompts` searches.
-
-Validation run in the worktree:
-- Focused text validation via grep assertions for risky-but-specified -> `implementation_ready`, concrete missing item requirements, risk-alone insufficiency, bounded context/non-archaeology wording, preflight compatibility wording, multi-agent proceed-with-reviewer-focus wording, and work-items docs alignment.
-- `git diff --check 8576615^ 8576615` passed.
-- `cargo run -q -p yoi -- ticket doctor` passed (`doctor: ok`).
-- `nix build .#yoi` passed.
-- Worktree remained clean after review.
-
-I did not run `cargo check --workspace`; the diff is workflow/docs text only, and `nix build .#yoi` plus Ticket doctor covered packaging/runtime-resource integrity for this change.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T00:24:31Z -->
-
-## Implementation report
-
-Merge-ready dossier for human/orchestrator approval.
-
-Status:
-- Implementation branch: `orchestrator-return-to-planning-context-policy`
-- Worktree: `.worktree/orchestrator-return-to-planning-context-policy`
-- Commit under review: `8576615 workflow: tighten orchestrator planning return policy`
-- Reviewer: `reviewer-orchestrator-return-to-planning-context-policy`
-- Review result: approved; no blocking findings.
-
-Intent / invariant check:
-- Strengthens Orchestrator routing guidance so `ready` / `queued` Tickets are returned to `planning` only when a concrete missing decision/information remains after bounded project-context checks.
-- Keeps workflow_state semantics unchanged: `planning -> ready -> queued -> inprogress -> done`.
-- Does not reintroduce preflight/readiness as a separate state/lane.
-- Keeps risk flags and authority-adjacent domains as context lookup / reviewer-focus / escalation signals, not automatic stop gates.
-- Allows risky-but-specified Tickets to proceed as `implementation_ready` with IntentPacket invariants, escalation conditions, and reviewer focus.
-
-Implementation summary:
-- Updated `ticket-orchestrator-routing` to require concrete missing-item evidence, checked context, implementation-latitude insufficiency, and next planning action before planning return.
-- Added an `allow-spawnpod-child-workspace-cwd`-style authority/scope/Pod example showing specified risky work proceeding with reviewer focus.
-- Aligned `ticket-preflight-workflow`, `multi-agent-workflow`, and work-item docs with the same policy.
-
-Validation evidence:
-- Coder reported pass:
-  - focused workflow/prompt text validation for risky-but-specified -> implementation_ready, genuinely missing decision -> return_to_planning, and risk flag alone insufficient
-  - `git diff --check`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - `nix build .#yoi`
-- Reviewer independently passed:
-  - focused grep/text validation across `.yoi/workflow`, `docs`, and `resources/prompts`
-  - `git diff --check 8576615^ 8576615`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - `nix build .#yoi`
-
-Residual risks / notes:
-- `cargo check --workspace` was intentionally not run by coder/reviewer because the implementation is workflow/docs text only; `nix build .#yoi` and Ticket doctor were used for packaging/resource integrity.
-- Final merge/close/cleanup is intentionally not performed here without explicit merge approval.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T01:18:52Z from: inprogress to: done reason: closed field: workflow_state -->
-
-## State changed
-
-Ticket closed; workflow_state を done に設定しました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T01:18:52Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Strengthened Orchestrator routing guidance so `ready` / `queued` Tickets are returned to `planning` only when a concrete missing decision/information remains after bounded project-context checks.
-- Clarified risk flags, risky domains, and authority-adjacent work as context lookup / reviewer-focus / escalation signals rather than automatic stop gates.
-- Added risky-but-specified guidance and an `allow-spawnpod-child-workspace-cwd`-style example for proceeding with reviewer focus when work is specified.
-- Aligned `ticket-preflight-workflow`, `multi-agent-workflow`, and work-item docs with the same policy.
-- Preserved workflow_state semantics and did not reintroduce preflight/readiness as a separate state or lane.
-
-Implementation:
-- Coder commit: `8576615 workflow: tighten orchestrator planning return policy`
-- Reviewer approved with no blocking findings.
-- Merge commit: `5af58b5 merge: tighten orchestrator planning return policy`
-
-Validation after merge:
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-`cargo check --workspace` was intentionally omitted because the merged implementation is workflow/docs text only and no Rust code/tests changed; Nix build covered resource/package integrity.
-
----

.yoi/tickets/20260608-072732-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-054243-1","ticket_id":"20260608-072732-001","kind":"before","related_ticket":"20260608-125430-001","note":"Route typed Ticket relation metadata before Objective records so Objective linking/design can target the stable canonical Ticket relation/reference surface after identity simplification.","author":"orchestrator","at":"2026-06-09T05:42:43Z"}

.yoi/tickets/20260608-072732-001/resolution.md

@@ -1,29 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added typed, durable, non-hierarchical Ticket relation metadata.
-- Stored forward project-level relations as typed JSON artifacts at `.yoi/tickets/<ticket-id>/artifacts/relations.json`.
-- Supported first-version relation kinds: `depends_on`, `blocks`, `related`, `supersedes`, and `duplicate_of`.
-- Derived inverse views such as `blocked_by`, `dependency_of`, `superseded_by`, and `duplicated_by` from forward relations rather than storing inverse relation kinds.
-- Added Ticket backend validation and `ticket doctor` diagnostics for relation artifacts, dangling references, self relations, duplicate relations, and bounded dependency/blocking cycles.
-- Added TicketRelation LLM tools, CLI relation add/list surfaces, TicketShow/List relation metadata, and workspace panel unresolved blocker hints.
-- Kept relation metadata distinct from OrchestrationPlan execution records and from Pod/session/worktree/runtime claims.
-
-Implementation:
-- Coder commit: `4601ad2 ticket: add typed relation metadata`
-- Reviewer approved with no blocking findings.
-- Merge commit: `2225311 merge: add typed ticket relation metadata`
-
-Validation after merge:
-- `cargo test -q -p ticket ticket_relations`
-- `cargo test -q -p ticket queue_gate_rejects`
-- `cargo test -q -p ticket doctor_validates_ticket_relations`
-- `cargo test -q -p ticket ticket_relation_tools_record`
-- `cargo test -q -p ticket ticket_tool_name_partitions_are_explicit`
-- `cargo test -q -p yoi ticket_cli_records_lists_and_shows_relations`
-- `cargo test -q -p tui workspace_panel_marks_ready_ticket_with_unresolved_relation_blocked`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`

.yoi/tickets/20260608-072732-001/thread.md

@@ -1,402 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-08T07:27:32Z -->
-
-## Created
-
-Created by LocalTicketBackend create.
-
----
-
-<!-- event: decision author: hare at: 2026-06-08T07:28:29Z -->
-
-## Decision
-
-## Design consideration: Queue gate should account for unresolved dependencies
-
-This relation metadata should be available before Orchestrator planning. That implies a stronger queue-time question:
-
-If a Ticket has a project-level dependency such as `depends_on: X`, and `X` is still in `planning` / not ready / not resolved, should the user be prevented or warned before Queueing the dependent Ticket?
-
-This needs explicit design before implementation.
-
-Considerations:
-
-- A dependency that is still `planning` likely means the dependent Ticket is not truly runnable yet.
-- Queue should probably reject or strongly warn when unresolved `depends_on` / blocking relations remain.
-- The behavior may differ by relation kind:
-  - `depends_on` unresolved: likely hard block or confirmation-required;
-  - `blocks`: informational for the blocked Ticket;
-  - `related`: never blocks;
-  - `parent` / `child`: depends on workflow semantics;
-  - `supersedes` / `duplicate_of`: may redirect or discourage Queue.
-- The Panel should be able to show why Queue is unavailable or risky before involving the Orchestrator.
-- CLI Queue/state transitions should enforce the same rule or at least expose the same diagnostics.
-- Orchestrator should still re-check relations at acceptance time, because relations may change between Queue and routing.
-
-The implementation should decide whether unresolved dependencies make Queue invalid, require confirmation, or allow Queue with a visible blocked state. The important requirement is that dependency relation metadata is not only an Orchestrator input; it should also inform the human Queue gate.
-
----
-
-<!-- event: decision author: hare at: 2026-06-08T13:22:42Z -->
-
-## Decision
-
-## Design consideration: avoid recreating umbrella Tickets through parent/child relations
-
-Umbrella Tickets are being deprecated as long-lived broad progress containers. This affects relation design.
-
-Parent/child relation kinds can easily recreate the umbrella pattern if they imply that one Ticket is a broad container whose close condition depends on manually inspecting child sufficiency. Therefore relation kinds such as `parent` / `child` should be reconsidered before implementation.
-
-Design guidance:
-
-- Keep concrete dependency/blocking relations distinct from broad grouping.
-- Prefer `Objective` records for medium-term goal/strategy grouping.
-- If decomposition needs to be represented, consider whether a relation such as `derived_from`, `split_from`, or `related` is safer than `parent` / `child`.
-- Do not make relation metadata imply that a broad umbrella Ticket should remain open as a progress container.
-- Any relation kind that approximates parent/child must define clear close semantics and avoid ambiguity around whether all child work is sufficient.
-
-This Ticket should explicitly decide whether to include parent/child relations at all in the first version.
-
----
-
-<!-- event: decision author: hare at: 2026-06-09T01:00:53Z -->
-
-## Decision
-
-## Decision: relation first version excludes hierarchy
-
-The first version of typed Ticket relations must not include hierarchy/container relation kinds. Exclude:
-
-- `parent` / `child`;
-- `sub-ticket`;
-- `umbrella`;
-- `part_of` / `contains`.
-
-This avoids recreating umbrella Tickets under another schema. The relation feature should focus on non-hierarchical direct relationships: dependency, blocking, related, supersedes, duplicate/replacement. Medium-term grouping belongs to Objective records, not Ticket hierarchy.
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T01:02:08Z -->
-
-## Decision
-
-## Intake refinement: ready にするための設計決定
-
-この Ticket は新規 Ticket ではなく、既存 Ticket の refinement として扱う。Orchestrator が routing できるよう、未決定だった relation kind / inverse / queue gate の境界を次の通り固定する。
-
-### Readiness
-
-- readiness: implementation_ready
-- risk_flags: [ticket-schema, workflow-state, panel, orchestrator-routing]
-
-### Binding decisions / invariants
-
-- first version の保存対象 relation kind は非階層 relation のみに限定する。
-  - `depends_on`: この Ticket が対象 Ticket の完了/解決を必要とする。
-  - `blocks`: この Ticket が対象 Ticket の実行/完了を妨げる。
-  - `related`: 非 blocking の関連。
-  - `supersedes`: この Ticket が対象 Ticket を置き換える。
-  - `duplicate_of`: この Ticket が対象 Ticket の duplicate である。
-- `blocked_by` / `superseded_by` / duplicate 逆一覧などの inverse view は保存済み forward relation から導出する。first version では inverse relation kind を別途保存して整合性を二重管理しない。
-- `parent` / `child` / `sub-ticket` / `umbrella` / `part_of` / `contains` は first version で扱わない。Ticket relation metadata で umbrella Ticket を再作成しない。
-- relation metadata は project-level Ticket record であり、Pod/session claim、worktree、branch ownership、coder/reviewer assignment、capacity、current planned order、`do_not_parallelize` を保存しない。これらは local role session registry / OrchestrationPlan / Pod metadata の責務に残す。
-- Queue gate は unresolved blocking relation を無視してはならない。
-  - 対象 Ticket の unresolved `depends_on` と incoming unresolved `blocks` は、Panel/CLI の `ready -> queued` 操作で visible reason 付きの block/diagnostic にする。
-  - `related` は queue を block しない。
-  - `supersedes` / `duplicate_of` は replacement/duplicate として visible diagnostic にする。自動的に全 relation を blocking 扱いしない。
-  - Orchestrator は `queued -> inprogress` acceptance 時に relation を再確認する。Queue gate の判定は Orchestrator の再確認を省略する根拠ではない。
-
-### Implementation latitude
-
-- durable storage の具体形は、typed backend が検証でき、git-trackable で、`TicketShow` / `ticket doctor` / Panel summary から読める限り実装側で選んでよい。例: `item.md` frontmatter の typed field、または Ticket artifacts 配下の typed record。
-- CLI の具体的な relation 操作名・オプション名、Panel 上の短い表示文言、cycle 検出の bounded な実装方式は実装側で選んでよい。
-- `depends_on` と `blocks` は利用者が自然な方向で記録できる relation kind として両方残すが、表示・validation では inverse view を導出して重複/矛盾を診断してよい。
-
-### Escalation conditions
-
-- hierarchy/container semantics を追加したくなった場合。
-- inverse relation を保存しないと実装できない設計にしたくなった場合。
-- queue gate を unresolved dependency でも通常 queue 可能にしたくなった場合。
-- relation metadata に Pod/session/worktree/assignment/capacity/current-batch order を保存したくなった場合。
-- public Ticket schema または role workflow guidance で relation kind 名を上記から変更したくなった場合。
-
-### Validation focus
-
-- `ticket doctor` が dangling reference、invalid kind、self relation、obvious dependency/blocking cycle を bounded diagnostic として検出すること。
-- `TicketShow` が forward relation と derived inverse view を理解できる形で表示すること。
-- Panel/CLI が unresolved dependency/blocker を queue 前に visible にすること。
-- Intake/Planning と Orchestrator guidance が project-level relation metadata と OrchestrationPlan runtime decision を混同しないこと。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T01:02:17Z -->
-
-## Intake summary
-
-既存 Ticket を refinement し、typed Ticket relation metadata の first version を非階層 relation に限定して implementation_ready にした。保存 relation kind は `depends_on` / `blocks` / `related` / `supersedes` / `duplicate_of`、inverse view は forward relation から導出し、`parent` / `child` / `sub-ticket` / `umbrella` / `part_of` / `contains` は扱わない。unresolved `depends_on` と incoming unresolved `blocks` は Panel/CLI queue gate で visible block/diagnostic にし、Orchestrator は acceptance 時に再確認する。runtime claims や OrchestrationPlan execution decisions は relation metadata に保存しない。blocking open questions はない。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T01:02:17Z from: planning to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake refinement により、relation kind、inverse relation の扱い、queue gate 境界、binding invariants、implementation latitude、escalation conditions が揃ったため ready に遷移する。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T02:27:31Z from: ready to: queued reason: queued field: workflow_state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T02:28:14Z -->
-
-## Decision
-
-Routing decision: defer_pending_ticket_identity_migration
-
-This Ticket is queued and appears implementation-ready, but I am intentionally not accepting it to `inprogress` yet.
-
-Reason:
-- `simplify-ticket-identity-fields` is already active, with Coder Pod `coder-simplify-ticket-identity-fields` running in `.worktree/simplify-ticket-identity-fields`.
-- This Ticket depends on the same Ticket backend/schema/API/panel/doctor surfaces and explicitly needs canonical Ticket references.
-- Implementing typed relations before the identity simplification lands would risk building relation storage and validation on soon-to-change identity/layout/state semantics.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T05:42:43Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
-
-## State changed
-
-Accepted queued implementation after identity simplification landed, was closed, and the workspace was verified clean on the flat Ticket layout. This Ticket is the lower-level project-level Ticket relation/reference surface, so it should run before Objective records, which may reference Tickets and relation concepts.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T05:42:43Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body/thread, including Intake refinement and explicit first-version relation decisions.
-- Current flat Ticket identity state after `simplify-ticket-identity-fields` landed and closed.
-- Current queued set: `typed-ticket-relation-metadata` and `objective-records-for-medium-term-goals`.
-- Orchestration plan records: none existed before this routing; I recorded that typed relations should run before Objective records.
-- Workspace/worktree state: main workspace clean enough to route, no active implementation worktree.
-
-Reason:
-- The Ticket has concrete binding decisions: non-hierarchical relation kinds only, forward stored relations with derived inverse views, queue-gate diagnostics for unresolved dependencies/blockers, and clear separation from OrchestrationPlan/runtime claims.
-- It is lower-level than Objective records because Objective links should target stable canonical Ticket IDs and relation/reference semantics.
-- No concrete missing decision remains that requires returning to planning.
-
-IntentPacket:
-
-Intent:
-- Add typed, durable, non-hierarchical project-level Ticket-to-Ticket relation metadata on top of the flat canonical Ticket ID/state model.
-
-Binding decisions / invariants:
-- Supported stored relation kinds for first version: `depends_on`, `blocks`, `related`, `supersedes`, `duplicate_of`.
-- Do not support hierarchy/container kinds: no `parent`, `child`, `sub-ticket`, `umbrella`, `part_of`, or `contains`.
-- Store forward relations only; derive inverse views such as blocked-by / superseded-by / duplicate inverse from forward records.
-- Relations are project-level Ticket metadata and must not store Pod/session claims, worktree paths, branch ownership, coder/reviewer assignments, capacity, current planned order, or `do_not_parallelize` execution-plan state.
-- Store relations durably under the Ticket backend in a typed, git-trackable, backend-validated form.
-- Use canonical opaque Ticket IDs only. Do not use title/slug words as relation authority.
-- `TicketShow` must display relation metadata including useful inverse view.
-- `ticket doctor` must validate dangling references, invalid kinds, self relations, and obvious dependency/blocking cycles with bounded diagnostics.
-- Panel/CLI queue gate should not ignore unresolved blocking relations: unresolved `depends_on` and incoming unresolved `blocks` must be visible as block/diagnostic before `ready -> queued` and rechecked by Orchestrator at acceptance.
-- `related` does not block queue; `supersedes` / `duplicate_of` produce visible replacement/duplicate diagnostics but are not automatically all blocking.
-- Orchestrator routing treats relations as input constraints distinct from OrchestrationPlan runtime decisions.
-- Do not implement Objective records here.
-- Do not implement a full scheduler/dependency graph solver.
-- Do not change Pod protocol/history/session semantics.
-
-Implementation latitude:
-- Coder may choose typed artifact vs current Ticket metadata field if it is validated, git-trackable, queryable, and works with flat IDs.
-- CLI/tool names and exact Panel hint wording are implementation latitude if acceptance criteria are met.
-- Cycle detection may be bounded and documented/test-covered.
-- If the queue gate cannot be fully enforced in Panel/CLI without broad UI redesign, implement visible diagnostics and escalate the exact remaining gap rather than silently skipping it.
-
-Reviewer focus:
-- Verify relation storage is typed/validated and does not rely only on Markdown thread prose.
-- Verify canonical ID references and local record migration/test fixtures use flat IDs.
-- Verify no hierarchy/container relation kind slips in as current behavior.
-- Verify OrchestrationPlan and Ticket relations remain distinct.
-- Verify doctor and queue/panel/list/show surfaces expose unresolved dependency/blocker information before Orchestrator starts work.
-
-Validation:
-- Focused Ticket backend/parser/writer/doctor tests for relations, dangling references, invalid kinds, self relation, cycles, derived inverse views.
-- Focused CLI/tool/schema tests for relation create/show/list/query or equivalent surfaces.
-- Focused panel/queue-gate tests for unresolved dependency/blocker visibility if touched.
-- Workflow/prompt/doc checks for Intake/Planning/Orchestrator relation guidance.
-- `cargo fmt --check`.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor`.
-- `cargo check --workspace`.
-- `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T05:43:42Z -->
-
-## Implementation report
-
-Implementation routing started.
-
-Worktree/branch:
-- Worktree: `.worktree/typed-ticket-relation-metadata`
-- Branch: `typed-ticket-relation-metadata`
-- Base/routing commit: `41a61d7 ticket: route typed relation metadata`
-
-Spawned sibling Coder Pod:
-- `coder-typed-ticket-relation-metadata`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- `simplify-ticket-identity-fields` is merged, closed, cleaned up, and the flat Ticket layout is active.
-- `objective-records-for-medium-term-goals` remains queued behind this work; durable orchestration plan records now encode that ordering.
-- This Ticket is the active lower-level Ticket relation/reference implementation work.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T06:19:32Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-typed-ticket-relation-metadata`
-- Commit: `4601ad2b41d6c51c9d445ca2291726a658c42ab5 ticket: add typed relation metadata`
-- Worktree status before review: clean branch `typed-ticket-relation-metadata`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Selected design:
-- Store forward project-level Ticket relation metadata per Ticket as typed JSON at `.yoi/tickets/<ticket-id>/artifacts/relations.json`.
-- Stored relation kinds: `depends_on`, `blocks`, `related`, `supersedes`, `duplicate_of`.
-- Derived inverse views are computed, not stored: `blocked_by`, `dependency_of`, `superseded_by`, `duplicated_by`.
-- Relation authority uses canonical opaque Ticket IDs only.
-- Unresolved `depends_on` and incoming unresolved `blocks` are treated as queue/acceptance blockers; `related` does not block; `supersedes` / `duplicate_of` are visible diagnostics only.
-
-Implementation summary:
-- Added typed relation structs, artifact read/write, backend relation query/view, and doctor validation in `crates/ticket`.
-- Added `TicketRelationRecord` / `TicketRelationQuery` tools and relation JSON in TicketShow/List-related output.
-- Added CLI relation commands: `yoi ticket relation add ...` and `yoi ticket relation list ...`.
-- Updated workspace panel to display unresolved relation blockers for ready Tickets.
-- Updated Orchestrator/work-item guidance to distinguish Ticket relations from OrchestrationPlan execution records.
-
-Changed files:
-- `.yoi/workflow/ticket-orchestrator-routing.md`
-- `crates/ticket/src/lib.rs`
-- `crates/ticket/src/tool.rs`
-- `crates/tui/src/workspace_panel.rs`
-- `crates/yoi/src/ticket_cli.rs`
-- `docs/development/work-items.md`
-
-Coder validation reported passed:
-- `cargo test -q -p ticket ticket_relations`
-- `cargo test -q -p ticket queue_gate_rejects`
-- `cargo test -q -p ticket doctor_validates_ticket_relations`
-- `cargo test -q -p ticket ticket_relation_tools_record`
-- `cargo test -q -p ticket ticket_tool_name_partitions_are_explicit`
-- `cargo test -q -p yoi ticket_cli_records_lists_and_shows_relations`
-- `cargo test -q -p tui workspace_panel_marks_ready_ticket_with_unresolved_relation_blocked`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Residual risks noted by coder:
-- No relation delete/update operation in this first version.
-- Derived inverse view scans relation artifacts; acceptable for current local scale but may need index/cache if Ticket counts grow.
-- Cycle detection is bounded and intentionally not a scheduler/dependency solver.
-- `supersedes` / `duplicate_of` do not automatically close/block/transition Tickets.
-
----
-
-<!-- event: review author: reviewer at: 2026-06-09T06:28:28Z status: approve -->
-
-## Review: approve
-
-Approved review for commit `4601ad2b41d6c51c9d445ca2291726a658c42ab5`.
-
-Evidence checked:
-- `TicketRelationKind` stores only `depends_on`, `blocks`, `related`, `supersedes`, and `duplicate_of`; hierarchy/container names are not supported as current relation kinds.
-- Relation storage is a typed `artifacts/relations.json` artifact with versioned JSON, `deny_unknown_fields`, owner-ticket validation, self/duplicate validation, and canonical Ticket-id lookup for targets.
-- Inverse relation views are derived through `TicketShow`/CLI output; only forward records are written.
-- Queue gates reject unresolved outgoing `depends_on` and incoming unresolved `blocks` at both `ready -> queued` and `queued -> inprogress`; Panel rows use the derived blocker view rather than silently offering Queue.
-- `TicketRelationQuery` is read-only and `TicketRelationRecord` is mutating in the ticket tool partitions.
-- Orchestrator guidance explicitly separates project-level relation metadata from OrchestrationPlan runtime ordering/capacity records.
-
-Validation run from the worktree:
-- `cargo test -q -p ticket ticket_relations`
-- `cargo test -q -p ticket queue_gate_rejects`
-- `cargo test -q -p ticket doctor_validates_ticket_relations`
-- `cargo test -q -p ticket ticket_relation_tools_record`
-- `cargo test -q -p ticket ticket_tool_name_partitions_are_explicit`
-- `cargo test -q -p yoi ticket_cli_records_lists_and_shows_relations`
-- `cargo test -q -p tui workspace_panel_marks_ready_ticket_with_unresolved_relation_blocked`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-Residual risk: `TicketShow` tool description still summarizes the old output shape and does not mention relations, but the returned JSON and CLI display include relation metadata; this is documentation polish rather than a correctness blocker.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T06:31:17Z from: inprogress to: closed reason: closed field: state -->
-
-## State changed
-
-Ticket を closed にしました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T06:31:17Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added typed, durable, non-hierarchical Ticket relation metadata.
-- Stored forward project-level relations as typed JSON artifacts at `.yoi/tickets/<ticket-id>/artifacts/relations.json`.
-- Supported first-version relation kinds: `depends_on`, `blocks`, `related`, `supersedes`, and `duplicate_of`.
-- Derived inverse views such as `blocked_by`, `dependency_of`, `superseded_by`, and `duplicated_by` from forward relations rather than storing inverse relation kinds.
-- Added Ticket backend validation and `ticket doctor` diagnostics for relation artifacts, dangling references, self relations, duplicate relations, and bounded dependency/blocking cycles.
-- Added TicketRelation LLM tools, CLI relation add/list surfaces, TicketShow/List relation metadata, and workspace panel unresolved blocker hints.
-- Kept relation metadata distinct from OrchestrationPlan execution records and from Pod/session/worktree/runtime claims.
-
-Implementation:
-- Coder commit: `4601ad2 ticket: add typed relation metadata`
-- Reviewer approved with no blocking findings.
-- Merge commit: `2225311 merge: add typed ticket relation metadata`
-
-Validation after merge:
-- `cargo test -q -p ticket ticket_relations`
-- `cargo test -q -p ticket queue_gate_rejects`
-- `cargo test -q -p ticket doctor_validates_ticket_relations`
-- `cargo test -q -p ticket ticket_relation_tools_record`
-- `cargo test -q -p ticket ticket_tool_name_partitions_are_explicit`
-- `cargo test -q -p yoi ticket_cli_records_lists_and_shows_relations`
-- `cargo test -q -p tui workspace_panel_marks_ready_ticket_with_unresolved_relation_blocked`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-
----

.yoi/tickets/20260608-110940-001/resolution.md

@@ -1,25 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Migrated current Ticket storage from `.yoi/tickets/{open,pending,closed}/<id-or-slug>/` buckets to flat `.yoi/tickets/<ticket-id>/` directories.
-- Simplified current Ticket identity to opaque path-derived canonical IDs such as `YYYYMMDD-HHMMSS-NNN`; title remains user-facing display/search text, but slug/title words are not canonical identity.
-- Simplified current frontmatter to use canonical `state` instead of independent `status` / `workflow_state` axes.
-- Removed current authority for frontmatter `id`, `slug`, `kind`, unmanaged `labels`, `status`, and `workflow_state`.
-- Preserved distinct `done` vs `closed` lifecycle semantics; close records `state: closed` and `resolution.md` without moving directories.
-- Updated Ticket backend, CLI, built-in tools, panel/TUI, role/session claims, orchestration-plan references, workflows, docs, tests, and local Ticket records to the flat ID/state model.
-- Migrated local Ticket records, including merge-boundary records created while the branch was under review.
-
-Implementation:
-- Coder commits included `191a875`, `591db3f`, `21114fd`, `8fe4b82`, `6ca27f3`, and `a6326a9`.
-- Reviewer approved after fix loops.
-- Merge commit: `634da5d merge: simplify ticket identity fields`.
-
-Validation:
-- Pre-merge and merge-boundary validation passed:
-  - `cargo fmt --check`
-  - `git diff --check`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - `cargo test -p ticket`
-  - `cargo check --workspace`
-  - `nix build .#yoi`
-- After runtime/tooling refresh, new tools also read the flat layout successfully and `cargo run -q -p yoi -- ticket doctor` reports `doctor: ok`.

.yoi/tickets/20260608-110940-001/thread.md

@@ -1,731 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-08T11:09:40Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: decision author: hare at: 2026-06-08T11:15:09Z -->
-
-## Decision
-
-## Scope expansion: simplify core Ticket frontmatter, not only identity
-
-Expand this Ticket beyond identity cleanup. The same simplification pass should also review and reduce the core Ticket frontmatter shape.
-
-### Unify `status` and `workflow_state`
-
-The current split between local `status` and `workflow_state` creates an invalid two-axis state model. Combinations such as `status: closed` with `workflow_state: inprogress` are not meaningful.
-
-Direction:
-
-- Use one canonical lifecycle state field.
-  - Final name can be `state` or retained as `workflow_state`, but there should not be both `status` and `workflow_state` as independent current fields.
-- Treat `open` as a derived range of states rather than a stored independent status.
-  - Example: `open = planning | ready | queued | inprogress | done`.
-  - Terminal closed state should be represented by the same lifecycle model, e.g. `closed` or equivalent.
-- Decide whether `done` and `closed` remain distinct.
-  - `done`: implementation/review/merge complete, close/resolution may still be pending.
-  - `closed`: resolution recorded and Ticket lifecycle ended.
-- Revisit or remove the `pending` bucket/status. If a concept is still needed, define it as a lifecycle state such as `deferred` / `parked`, not as a second axis.
-- Update path layout expectations if needed.
-  - Directory buckets may be derived caches or UI grouping, but frontmatter should not duplicate contradictory state.
-
-### Remove `kind`
-
-`kind` currently behaves like a single typed category but is a freeform string with unclear management and little semantic authority. Most Tickets are work items and can be described by their title/body.
-
-Direction:
-
-- Remove `kind` from the required/current schema unless a small typed enum with clear semantics is explicitly justified.
-- Do not keep required freeform `kind`.
-- If the title follows a convention such as `area: verb object`, it already communicates the work class better than an unconstrained `kind: task` field.
-
-### Remove `labels`
-
-`labels` are useful for search, but without a registry/canonical vocabulary they create inconsistent taxonomy and can be confused with state, relation, risk, component, or priority.
-
-Direction:
-
-- Remove `labels` from the core required/current schema in this simplification pass.
-- Do not use labels to represent state, dependency, blockers, risk, priority, or ownership.
-- If tag-like search is needed later, add it as a separate feature with a project-managed registry/canonicalization model.
-- Prefer descriptive titles and body content for search. A title convention such as `component: concise action` can carry much of the useful categorization without an unmanaged labels field.
-
-### Resulting target direction
-
-The target core Ticket identity/frontmatter may be as small as:
-
-```yaml
-id: 20260608-103842   # or path-derived primary key
-title: component: concise action
-state: planning
-created_at: ...
-updated_at: ...
-```
-
-Additional fields should justify a concrete behavior. Search/display hints without management authority should be removed or moved to separately designed features.
-
----
-
-<!-- event: plan author: intake at: 2026-06-09T00:16:54Z -->
-
-## Plan
-
-## Intake assessment: requirements sync needed
-
-この Ticket は既存 identity simplification に加えて、`status` / `workflow_state` / `kind` / `labels` を含む core Ticket frontmatter simplification へ scope が拡張されている。方向性は明確だが、実装前に schema/API/UX と移行方針として固定すべき判断が残っているため、現時点では `workflow_state: planning` のまま requirements sync が必要。
-
-### 既に決まっていること
-
-- canonical Ticket identity は title-derived slug words を含めない timestamp/counter primary key へ寄せる。
-- `slug` は required/current frontmatter および canonical lookup key から外す。
-- agents / Orchestrator は ID/title だけから意味を推測せず、routing/実装前に `TicketShow` の body/thread/artifacts を読む。
-- core frontmatter simplification は identity だけでなく lifecycle/kind/labels も対象に含める。
-- `kind` は required freeform field として残さない方向。
-- `labels` は unmanaged taxonomy として core required/current schema から外す方向。
-
-### 実装前に固定すべき open questions
-
-1. lifecycle field の最終名を `state` に変更するか、既存名 `workflow_state` を保持して single lifecycle field にするか。
-2. `done` と `closed` を distinct lifecycle states として残すか、close/resolution の表現をどう統合するか。
-3. `pending` bucket/status を完全に廃止するか、`deferred` / `parked` などの lifecycle state として置き換えるか。
-4. canonical ID を frontmatter に `id` として保持するか、directory name から derive するか。
-5. legacy slug/path lookup を migration-only としてどこまで読むか。unreleased local data として一括 migration し、current schema では permanent alias を作らない方針でよいか。
-6. `kind` / `labels` removal をこの Ticket の実装 scope に含めて同時 migration するか、identity/lifecycle の破壊的変更と分けるか。
-
-### Risk flags / reviewer focus
-
-- `ticket-schema`
-- `storage-migration`
-- `workflow-state`
-- `panel-actions`
-- `orchestrator-routing`
-- `backward-compatibility`
-- `typed-tool-api`
-
-Reviewer は diff だけでなく、CLI / typed Ticket tools / Panel / Orchestrator routing / local role-session claims / future relation metadata が、slug や two-axis state を authority として残していないことを確認する必要がある。
-
-### 次の Intake action
-
-上記 open questions に user/maintainer decision が入れば、Ticket を `implementation_ready` として `ready` にできる。未回答のまま進める場合は、先に design/spike として routing し、実装 Ticket とは分けるのが安全。
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T02:13:15Z -->
-
-## Decision
-
-## User decision: target Ticket schema and storage shape
-
-User/maintainer decision for this Ticket:
-
-- Lifecycle field は `state` に統一する。`status` と `workflow_state` の二軸 current state は廃止する。
-- `done` と `closed` は一旦 distinct states として分離したままにする。
-  - `done`: 実装・review・merge 等は完了しているが、resolution/close 処理前の状態。
-  - `closed`: resolution が記録され、Ticket lifecycle が終了した状態。
-- `pending` は不要。pending bucket/status は current model から削除する。
-- filesystem layout は状態 bucket を持たず、すべて平坦に `.yoi/tickets/<ticket-id>/` に置く。
-  - open/pending/closed directory bucket は authority ではなくなり、current layout からも外す。
-- canonical Ticket ID は directory name から derive し、frontmatter には `id` を重複保存しない。
-- `kind` / `labels` 等の core frontmatter 削除もこの Ticket の scope に含める。
-
-### Updated target direction
-
-Current frontmatter は少なくとも以下へ縮小する方向で実装する。
-
-```yaml
-title: component: concise action
-state: planning
-created_at: ...
-updated_at: ...
-```
-
-Canonical identity は `.yoi/tickets/<ticket-id>/` の `<ticket-id>`。`slug`、frontmatter `id`、directory bucket、freeform `kind`、unmanaged `labels` は current schema authority から外す。
-
-### Implementation latitude
-
-- Timestamp/counter ID の exact format、collision suffix、高解像度 timestamp のどれを使うかは、opaque ID・安定 lookup・testability を満たす範囲で実装側が選べる。
-- Existing local records は新 layout/schema に migration する。unreleased local data として扱い、明示的に必要にならない限り permanent slug alias や旧 bucket layout の長期互換層は作らない。
-- `priority`、`action_required`、`attention_required`、`queued_at` 等の周辺 field は、削除・置換・維持の判断を「具体的な現在動作を持つか」で監査し、core identity/lifecycle simplification を歪めない範囲で扱う。
-
-### Reviewer focus
-
-Reviewer は、CLI / typed Ticket tools / Panel / role-session claims / Orchestrator guidance / relation metadata が、旧 `slug`、frontmatter `id`、`status`/`workflow_state` 二軸、open/pending/closed bucket を authority として残していないことを重点確認する。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T02:13:23Z -->
-
-## Intake summary
-
-Ticket schema simplification の binding decisions が揃った。Lifecycle は `state` に統一し、`done` と `closed` は一旦分離、`pending` は廃止する。Filesystem layout は `.yoi/tickets/<ticket-id>/` の平坦構造にし、canonical ID は directory name から derive して frontmatter に重複保存しない。`slug`、frontmatter `id`、freeform `kind`、unmanaged `labels`、open/pending/closed bucket、`status`/`workflow_state` 二軸 state は current schema authority から外す。実装前に Orchestrator/Coder は CLI・typed tools・Panel・role-session claims・Orchestrator guidance・relation metadata の旧 identity/state 依存を監査し、local records を新 layout/schema に migrate すること。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T02:13:23Z from: planning to: ready reason: planning_ready field: workflow_state -->
-
-## State changed
-
-必要な schema/lifecycle/storage layout の判断が user decision として記録されたため、Orchestrator が実装 routing できる状態になった。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T02:13:30Z from: ready to: queued reason: queued field: workflow_state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T02:14:31Z from: queued to: inprogress reason: orchestrator_acceptance field: workflow_state -->
-
-## State changed
-
-Accepted queued implementation after reading the Ticket body/thread, binding user decisions from Intake, current workspace state, and visible worktree/Pod state. No active implementation worktree remains. This is high-risk/broad Ticket schema/storage migration, but the required decisions are explicit enough to proceed with strict implementation invariants, migration evidence, and reviewer focus rather than returning to planning.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T02:14:31Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body, expanded scope decision, Intake assessment, user binding decision, Intake summary, and queued event.
-- Current workspace state: clean after committing queued event.
-- Worktree list: only main workspace, no active implementation worktree.
-- Visible Pods: no active sibling coder/reviewer from previous work remains.
-
-Reason:
-- This is a broad and high-risk schema/storage migration, but the Ticket now contains explicit binding decisions for identity, lifecycle, path layout, and core frontmatter simplification.
-- Returning to planning would need a concrete missing decision; after reading the Ticket/thread, the main open questions have user decisions.
-- Proceed with a strict audit-first implementation and reviewer focus.
-
-IntentPacket:
-
-Intent:
-- Simplify current Ticket identity/storage/frontmatter around path-derived opaque timestamp/counter IDs, a single lifecycle `state`, and minimal current frontmatter, while migrating local Ticket records and updating all current Ticket surfaces.
-
-Binding decisions / invariants:
-- Canonical Ticket identity is the directory name under flat `.yoi/tickets/<ticket-id>/`.
-- The canonical ID must be opaque timestamp/counter style and must not include title/slug words.
-- Frontmatter must not duplicate canonical identity as current `id`.
-- `slug` is not a required/current field and is not a canonical lookup key.
-- `status` and `workflow_state` must not remain independent current state axes; use one canonical lifecycle field named `state`.
-- `done` and `closed` remain distinct states for now:
-  - `done`: implementation/review/merge complete but resolution/close handling not yet final;
-  - `closed`: resolution recorded and Ticket lifecycle ended.
-- `pending` bucket/status is removed from the current model.
-- Current filesystem layout is flat `.yoi/tickets/<ticket-id>/`, not `.yoi/tickets/{open,pending,closed}/...`.
-- `kind` and unmanaged `labels` are removed from current required/core frontmatter.
-- New Ticket records should use minimal current frontmatter, approximately `title`, `state`, `created_at`, `updated_at` plus only fields with concrete current behavior that survive audit.
-- Existing local `.yoi/tickets` records must be migrated to the new layout/schema.
-- Permanent slug aliases / long-term old bucket compatibility should not be added unless a concrete current requirement is discovered; this is unreleased local data.
-- Exact canonical ID lookup remains; title/search UX may be list/search-oriented but must not make slug canonical.
-- Panel actions, role/session claims, tool/API outputs, Ticket doctor, CLI, Orchestrator guidance, and future relation/orchestration-plan references must use canonical IDs, not slug/path-derived title words.
-- Agents/Orchestrator guidance must reinforce reading `TicketShow` body/thread/artifacts before routing/implementation; do not infer requirements from ID/title alone.
-- Do not implement full typed Ticket relation metadata here.
-- Do not remove `title`.
-- Do not change Pod protocol/history/session semantics except where Ticket storage references are legitimately updated.
-
-Implementation latitude:
-- Coder may choose timestamp collision strategy (counter suffix or higher-resolution timestamp) if deterministic/testable and ID remains opaque.
-- Coder may keep tightly scoped migration-only parser/lookup helpers if needed to read old local records during migration, but current writers/tools/docs must emit/use the new schema/layout.
-- Coder may split implementation internally into commits if useful, but should report a coherent final branch state.
-- Coder should stop and report if the change proves too large to keep the repository buildable or if a hidden external compatibility requirement requires long-term legacy aliases.
-
-Reviewer focus:
-- Verify there is no old authoritative dependency on slug, frontmatter id, open/pending/closed buckets, status/workflow_state two-axis state, freeform kind, or unmanaged labels in current CLI/tools/panel/backend/claims/docs.
-- Verify local record migration is complete and `ticket doctor` validates the new flat layout/schema.
-- Verify exact lookup and user-facing display remain usable with `id + title`.
-- Verify close/resolution semantics distinguish `done` vs `closed` as decided.
-- Verify legacy compatibility is migration-only and does not reintroduce permanent slug authority.
-
-Escalate if:
-- Implementation requires a broad backward-compatibility layer for old slug/bucket layouts.
-- The change cannot keep the repo in a buildable state while migrating records.
-- Existing code depends on old directory buckets in a way that requires a larger storage-provider redesign.
-- Tool schema changes would require external plugin/capability redesign beyond Ticket built-in tools.
-
-Validation:
-- Focused Ticket backend/parser/writer/doctor/create/list/show/query tests for flat layout, path-derived ID, `state`, collision handling, and migrated records.
-- Focused tool schema/output tests for TicketCreate/List/Show/WorkflowState/Close/Status-equivalent behavior.
-- Focused panel/role-session/orchestrator guidance tests where surfaces changed.
-- `cargo fmt --check`.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor` or the new equivalent if command behavior changes.
-- `cargo check --workspace`.
-- `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T02:15:46Z -->
-
-## Implementation report
-
-Implementation routing started.
-
-Worktree/branch:
-- Worktree: `.worktree/simplify-ticket-identity-fields`
-- Branch: `simplify-ticket-identity-fields`
-- Base/routing commit: `48efcc7 ticket: route identity simplification`
-
-Spawned sibling Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- The workspace was clean and no active implementation worktree existed before acceptance.
-- This is a broad/high-risk schema/storage migration, so the handoff emphasizes audit-first implementation, complete local Ticket record migration, buildable coherent stopping points, and escalation if permanent legacy compatibility or a larger storage-provider redesign is discovered.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T03:03:16Z -->
-
-## Decision
-
-Human completion-boundary decision for this Ticket:
-
-For `simplify-ticket-identity-fields`, stop at the merge-complete boundary.
-
-Reason:
-- The branch migrates local Ticket records from the old bucket layout to the new flat identity/state schema.
-- At merge time, the repository data layout changes, while the currently running Orchestrator/Ticket tools may still be the pre-merge binary/schema.
-
-Operational rule:
-- Continue coder fix-loop and reviewer workflow normally.
-- If reviewer approves and post-review checks are clean, merge the branch.
-- After the merge commit and immediate validation/build as appropriate, stop and report.
-- Do not close the Ticket, delete the worktree/branch, or continue queued routing until the runtime/tooling has been deliberately refreshed or the user gives explicit follow-up instructions for post-migration completion.
-
-This Ticket intentionally overrides the broader standing instruction to auto-close/cleanup reviewer-approved work, because the migration changes the Ticket storage schema used by those completion tools.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T03:17:20Z -->
-
-## Implementation report
-
-Coder fix-loop completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- Implementation commit: `191a875 ticket: simplify ticket identity fields`
-- Fix-loop commit: `591db3f test: update ticket schema expectations`
-- Worktree status before review: clean branch `simplify-ticket-identity-fields`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Fix-loop summary:
-- Updated Ticket crate tests from stale bucket/status/workflow_state/slug expectations to the new flat layout, canonical ID, and `state` schema.
-- Updated close tests to distinguish `done` vs `closed` and assert `state: closed` plus `resolution.md`.
-- Updated doctor/tool tests for legacy bucket detection, obsolete frontmatter field detection, invalid `state`, canonical ID lookup, `state` filters, and orchestration-plan canonical-ID references.
-- No unresolved design conflict was reported.
-
-Coder validation reported passed:
-- `cargo test -p ticket` -> 59 passed, 0 failed
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Completion boundary reminder:
-- Per human instruction, if review approves and the branch merges cleanly, stop at merge-complete/validation boundary. Do not close this Ticket or clean up the worktree/branch until runtime/tooling is refreshed or explicit follow-up is given, because the merge changes the Ticket storage schema/layout.
-
----
-
-<!-- event: review author: reviewer-simplify-ticket-identity-fields at: 2026-06-09T03:27:14Z status: request_changes -->
-
-## Review: request changes
-
-Review result: request_changes
-
-The core direction is aligned, but current authoritative surfaces still expose old `status` / `pending` / `slug` / bucket-model behavior, and focused CLI/panel tests fail.
-
-Blocking issues:
-
-1. Ticket tool/backend surface still exposes `TicketStatus` / `pending`.
-   - `crates/ticket/src/tool.rs` still registers `TicketStatus` as a mutating tool.
-   - `TicketStatusParam::{Open, Pending}` and `TicketStatusTool` still accept/return pending-style state.
-   - `crates/ticket/src/lib.rs` still has `set_status()` mapping old `TicketStatus::Pending` into planning.
-   - This violates the invariant that pending bucket/status is removed and `state` is canonical.
-
-2. Panel/TUI still has pending/status dependencies.
-   - `crates/tui/src/workspace_panel.rs` `derive_ticket_state()` still treats `TicketStatus::Pending` specially for Defer.
-   - `cargo test -p tui ticket_action --no-run` fails with stale references (`TicketStatus`, `workflow_state_field`, old `TicketPanelEntry` fields, pending defer action test).
-
-3. CLI unit tests still assert old slug/status/bucket behavior.
-   - `cargo test -p yoi ticket_cli` fails: 5 passed, 3 failed.
-   - Failing tests still pass `--slug` and panic on `unknown create argument: --slug`.
-
-4. `AGENTS.md` still presents old commands/layout as authoritative guidance.
-   - Mentions `--slug`, `--kind`, `--label`, `--status`, `open|pending|closed`, `id-or-slug`, `.yoi/tickets/{open,pending,closed}/<id>/`, and close moving to `closed/`.
-
-Positive evidence:
-- Flat `.yoi/tickets/<ticket-id>/` layout is present.
-- `cargo run -q -p yoi -- ticket doctor` passes with `doctor: ok`.
-- `ticket list --state all` and exact ID show work.
-- Old slug lookup fails as expected.
-- `cargo test -p ticket`, `cargo fmt --check`, `git diff --check`, `cargo check --workspace`, and `nix build .#yoi` passed.
-
-Required fix direction:
-- Remove or explicitly retire `TicketStatus` / `pending` from current Ticket tools/backend mutation surface, or make retained compatibility non-current and not user/tool-visible.
-- Update panel/current action model to use canonical `state` only, with no pending/defer status path.
-- Update `cargo test -p yoi ticket_cli` tests to new CLI behavior: `create --title`, `list --state`, `state <id> ...`, exact ID lookup, flat path assertions.
-- Update TUI/panel tests to compile and assert canonical ID/state behavior.
-- Update `AGENTS.md` to the new Ticket commands/layout and exact ID guidance.
-
----
-
-<!-- event: implementation_report author: coder at: 2026-06-09T04:04:33Z -->
-
-## Implementation report
-
-Fix loop update: removed current TicketStatus mutating tool/backend status move path and pending status handling; updated panel/TUI action model to state-only Queue/Close/Edit/Wait/Open without Defer; refreshed yoi ticket CLI tests to canonical ID, `list --state`, `state`, and flat `.yoi/tickets/<ticket-id>/` assertions; updated AGENTS.md current Ticket guidance. Validation passed locally: `cargo test -p ticket`, `cargo test -p yoi ticket_cli`, `cargo test -p tui ticket_action --no-run`, `cargo test -p tui workspace_panel`, `cargo test -p tui ticket_action`, `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, and `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T04:06:54Z -->
-
-## Implementation report
-
-Coder fix-loop for reviewer request_changes completed and is ready for re-review.
-
-Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- New fix commit: `21114fd fix: remove stale ticket status surfaces`
-- Branch status after fix: clean
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Fix summary:
-- Removed current `TicketStatus` mutating tool surface and related schema registration.
-- Removed backend `set_status()` and stale pending status mutation path.
-- Removed panel/TUI `Defer` / pending-status current action path and updated focused tests to canonical `state` behavior.
-- Updated yoi CLI tests away from `--slug`, `--status`, bucket paths, and old lookup expectations toward canonical IDs, `list --state`, `state <ticket-id> ...`, and flat paths.
-- Updated `AGENTS.md` to flat `.yoi/tickets/<ticket-id>/`, canonical exact ID, `state` lifecycle, and no slug/bucket/pending authority.
-
-Coder validation reported passed:
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p tui ticket_action --no-run`
-- `cargo test -p tui workspace_panel`
-- `cargo test -p tui ticket_action`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi` (dirty-tree warning only; build succeeded)
-
-Coder reports no remaining risks or unresolved removal conflicts.
-
----
-
-<!-- event: review author: reviewer-simplify-ticket-identity-fields at: 2026-06-09T04:16:11Z status: request_changes -->
-
-## Review: request changes
-
-Review result: request_changes
-
-The requested focused validation now passes, but stale old-layout/current-guidance surfaces remain and block merge.
-
-Blockers:
-
-1. Built-in Ticket feature still requires old bucket layout.
-   - `crates/pod/src/feature/builtin/ticket.rs` `usable_backend_root()` still requires `open`, `pending`, and `closed` directories.
-   - In the new flat `.yoi/tickets/<ticket-id>/` layout this would cause built-in Ticket tool registration to be warning-skipped.
-   - Tests encode the stale expectation: `make_ticket_root()` creates old buckets and `does_not_register_ticket_tools_when_root_lacks_state_dirs` asserts old behavior.
-   - Fix direction: validate the flat Ticket backend root/current marker semantics instead, and update pod feature tests accordingly. Do not reintroduce open/pending/closed buckets.
-
-2. Workflow guidance still exposes `TicketStatus` / pending routing.
-   - `.yoi/workflow/ticket-intake-workflow.md` still mentions `TicketStatus` and `open / pending Ticket` lookup.
-   - `.yoi/workflow/ticket-orchestrator-routing.md` still mentions `TicketStatus`, pending/open state cleanup, `defer_pending`, routing target `pending`, and moving Tickets to pending.
-   - Fix direction: update guidance to canonical `state` lifecycle and remove pending/TicketStatus/defer_pending current routing target. Defer/block decisions should be expressed through planning/queued/inprogress/done/closed plus attention/planning records as appropriate, not pending status.
-
-3. Maintained development docs still contain old pending/create guidance.
-   - `docs/development/work-items.md` still mentions `defer_pending`, `yoi ticket state <id> open|pending`, and old `create --kind --label` style.
-   - Fix direction: update to current flat layout, canonical ID, `state`, and new minimal create/list/state guidance.
-
-Validation evidence from reviewer:
-- Passed: `cargo test -p yoi ticket_cli`, `cargo test -p tui ticket_action --no-run`, `cargo test -p ticket`, `cargo test -p tui workspace_panel`, `cargo test -p tui ticket_action`, `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-- Additional `cargo test -p pod ticket` passed but with stale old-bucket expectations, confirming the remaining issue is encoded authority/guidance rather than a compile failure.
-
-Positive evidence:
-- The flat Ticket layout and canonical `state` model are mostly implemented.
-- `TicketStatusTool` / `TicketStatusParam` are no longer in current ticket tool registration.
-- Exact canonical ID lookup works.
-
-Required before re-review:
-- Fix the built-in Ticket feature root validation/tests for flat layout.
-- Remove/update stale `TicketStatus` / pending / `defer_pending` guidance from maintained workflow/docs.
-- Run at minimum: `cargo test -p pod ticket`, `cargo test -p ticket`, `cargo test -p yoi ticket_cli`, `cargo test -p tui ticket_action --no-run`, `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T04:28:16Z -->
-
-## Implementation report
-
-Coder fix-loop for second reviewer request_changes completed and is ready for re-review.
-
-Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- New fix commit: `8fe4b82 fix: align ticket flat-state surfaces`
-- Branch status after fix: clean
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Fix summary:
-- Updated built-in Ticket feature backend-root validation to accept flat `.yoi/tickets/<ticket-id>/` root and removed `open/`, `pending/`, `closed/` bucket requirements.
-- Updated pod feature tests so flat backend root registers Ticket tools instead of requiring old bucket dirs.
-- Removed stale `TicketStatus` / pending guidance from Intake and Orchestrator workflows.
-- Removed `pending` / `defer_pending` routing target guidance and described defer/block via attention/action-required or orchestration plan blocker/waiting-capacity records.
-- Updated `docs/development/work-items.md` for flat layout, canonical opaque Ticket IDs, current `create/list/state` guidance, and distinct `done` vs `closed` close semantics.
-
-Coder validation reported passed:
-- `cargo test -p pod ticket`
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p tui ticket_action --no-run`
-- `cargo test -p tui workspace_panel`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Coder reports no remaining requested surface or design conflict.
-
----
-
-<!-- event: review author: reviewer-simplify-ticket-identity-fields at: 2026-06-09T04:35:54Z status: request_changes -->
-
-## Review: request changes
-
-Review result: request_changes
-
-The previous three blockers were fixed, and the requested validation set passed. However, one stale old-bucket TUI test setup remains and a focused test fails.
-
-Blocking issue:
-- `crates/tui/src/multi_pod.rs` still contains an old bucket path in test setup:
-  - `.yoi/tickets/open/done-ticket`
-- Focused test failure:
-  - `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`
-  - exits 101 because the test writes `resolution.md` under `.yoi/tickets/open/done-ticket/`, but the current flat layout no longer creates that parent path.
-
-This is a test/helper path rather than production runtime behavior, but the Ticket requires completion of the flat `.yoi/tickets/<ticket-id>/` migration and no current old-bucket route. Executable tests should not encode old bucket paths.
-
-Positive evidence:
-- Built-in Ticket feature root validation no longer requires `open/`, `pending/`, `closed/` buckets.
-- Maintained workflows/docs no longer expose `TicketStatus`, pending routing, or `defer_pending` as current guidance.
-- Main requested validation passed: `cargo test -p pod ticket`, `cargo test -p ticket`, `cargo test -p yoi ticket_cli`, `cargo test -p tui ticket_action --no-run`, `cargo test -p tui workspace_panel`, `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
-Required fix:
-- Update the stale TUI test setup in `crates/tui/src/multi_pod.rs` to the flat layout/current state schema.
-- Run the failing focused test: `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`.
-- Re-run the relevant focused validation and core checks before re-review.
-
----
-
-<!-- event: implementation_report author: coder at: 2026-06-09T04:40:07Z -->
-
-## Implementation report
-
-Third review fix-loop update: removed the remaining stale old-bucket TUI test setup in `crates/tui/src/multi_pod.rs` by writing `resolution.md` under the flat `.yoi/tickets/<ticket-id>/` test fixture path. Re-scanned `crates/tui/src` for `.yoi/tickets/open`, `.yoi/tickets/pending`, and `.yoi/tickets/closed`; no matches remain. Focused pending/slug-current-authority searches only found non-Ticket pending UI/task terminology and local role-session display slug metadata, not old Ticket bucket/current-state setup.
-
-Validation passed:
-- `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`
-- `cargo test -p tui ticket_action --no-run`
-- `cargo test -p tui workspace_panel`
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p pod ticket`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` (`doctor: ok`)
-- `cargo check --workspace`
-- `nix build .#yoi` (dirty-tree warning only while uncommitted)
-
-No remaining risks identified for the requested blocker.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T04:41:51Z -->
-
-## Implementation report
-
-Coder fix-loop for third reviewer request_changes completed and is ready for re-review.
-
-Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- New fix commit: `6ca27f3 fix: use flat ticket path in tui test`
-- Branch status after fix: clean
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Fix summary:
-- Updated `crates/tui/src/multi_pod.rs` test fixture `ticket_close_action_blocks_existing_resolution_without_moving_ticket` from old `.yoi/tickets/open/<ticket-id>/resolution.md` to flat `.yoi/tickets/<ticket-id>/resolution.md`.
-- Re-searched `crates/tui/src` for `.yoi/tickets/open`, `.yoi/tickets/pending`, `.yoi/tickets/closed`; coder reports no matches.
-
-Coder validation reported passed:
-- `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`
-- `cargo test -p tui ticket_action --no-run`
-- `cargo test -p tui workspace_panel`
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p pod ticket`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Coder reports no remaining risks.
-
----
-
-<!-- event: review author: reviewer-simplify-ticket-identity-fields at: 2026-06-09T04:50:13Z status: request_changes -->
-
-## Review: request changes
-
-Review result: request_changes
-
-The previous TUI flat-path blocker is fixed and all requested validation passed, but two stale current-authority/guidance surfaces remain.
-
-Blockers:
-
-1. `.yoi/workflow/ticket-intake-workflow.md` still asks Intake to propose old identity/core metadata:
-   - `Ticket record fields proposal: title / canonical id / kind / priority / labels / body / explicit acceptance conditions.`
-   - `Proposed title / canonical id / priority / labels.`
-   - `Proposed title / canonical id / kind / priority / labels;`
-
-   This conflicts with the current invariants:
-   - canonical ID is opaque/path-derived and should not be proposed by Intake as an external/current field;
-   - `kind` and unmanaged `labels` are no longer current core frontmatter authority.
-
-2. `crates/ticket/src/lib.rs` still emits generated thread/audit text with stale `workflow_state` vocabulary:
-   - `planning_ready: workflow_state planning -> ready.`
-   - `workflow_state planning -> ready.`
-
-   Frontmatter uses `state`; generated current-visible audit text should say `state planning -> ready` or equivalent.
-
-Positive evidence:
-- Previous TUI blocker is fixed.
-- `crates/tui/src` has no `.yoi/tickets/open|pending|closed` matches.
-- Current `.yoi/tickets/*/item.md` frontmatter scan found all records using `state` and no obsolete `id`, `slug`, `kind`, `labels`, `status`, `workflow_state`, `legacy_ticket`, or `needs_preflight` frontmatter.
-- Validation passed: targeted TUI close test, `cargo test -p pod ticket`, `cargo test -p ticket`, `cargo test -p yoi ticket_cli`, `cargo test -p tui ticket_action --no-run`, `cargo test -p tui workspace_panel`, `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
-Required fix:
-- Update Intake workflow guidance so Intake proposes title/body/acceptance/current behavioral metadata only, not canonical id/kind/labels as core fields.
-- Update generated event text in `crates/ticket/src/lib.rs` from `workflow_state` to canonical `state` vocabulary.
-- Re-run focused validation and core checks before re-review.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T04:59:07Z -->
-
-## Implementation report
-
-Coder fix-loop for fourth reviewer request_changes completed and is ready for re-review.
-
-Coder Pod:
-- `coder-simplify-ticket-identity-fields`
-- New fix commit: `a6326a9 fix: align ticket intake state wording`
-- Branch status after fix: clean
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Fix summary:
-- Updated `.yoi/workflow/ticket-intake-workflow.md` so Intake no longer proposes canonical ID, `kind`, or unmanaged `labels` as current/core fields.
-- Clarified that storage assigns the opaque/path-derived canonical ID.
-- Reframed Intake draft/core guidance around title, priority, body/request snapshot, acceptance conditions, readiness/action/attention fields.
-- Updated `crates/ticket/src/lib.rs` generated intake-ready audit/error text from `workflow_state ... -> ready` to `state ... -> ready`.
-
-Coder validation reported passed:
-- Focused grep/text validation: removed old Intake proposal patterns and stale `workflow_state planning -> ready` generated vocabulary; positive check shows generated text now uses `state {from} -> ready`.
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`
-- `cargo test -p pod ticket`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Coder reports no remaining risks.
-
----
-
-<!-- event: review author: reviewer-simplify-ticket-identity-fields at: 2026-06-09T05:04:45Z status: approve -->
-
-## Review: approve
-
-Review result: approve
-
-Fourth fix-loop request_changes items are resolved. No additional blocking findings.
-
-Evidence:
-- `.yoi/workflow/ticket-intake-workflow.md` no longer asks Intake to propose `canonical id`, `kind`, or unmanaged `labels` as current/core fields.
-- Intake guidance now treats canonical ID as storage-assigned opaque/path-derived identity and focuses drafts on title, priority, body/request snapshot, acceptance conditions, readiness/action/attention fields.
-- `crates/ticket/src/lib.rs` generated intake-ready audit/thread text now uses `state {from} -> ready` wording rather than stale `workflow_state ... -> ready` vocabulary.
-- Product/workflow/docs searches did not find blocker-level stale old-bucket current guidance.
-- Remaining `workflow_state` occurrences are internal compatibility/API/transition helper names rather than generated intake-ready audit text or current frontmatter authority.
-
-Validation passed from the worktree:
-- `cargo test -p ticket`
-- `cargo test -p yoi ticket_cli`
-- `cargo test -p tui ticket_close_action_blocks_existing_resolution_without_moving_ticket`
-- `cargo test -p pod ticket`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Worktree remained clean after review.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T05:41:12Z from: inprogress to: closed reason: closed field: state -->
-
-## State changed
-
-Ticket を closed にしました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T05:41:12Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Migrated current Ticket storage from `.yoi/tickets/{open,pending,closed}/<id-or-slug>/` buckets to flat `.yoi/tickets/<ticket-id>/` directories.
-- Simplified current Ticket identity to opaque path-derived canonical IDs such as `YYYYMMDD-HHMMSS-NNN`; title remains user-facing display/search text, but slug/title words are not canonical identity.
-- Simplified current frontmatter to use canonical `state` instead of independent `status` / `workflow_state` axes.
-- Removed current authority for frontmatter `id`, `slug`, `kind`, unmanaged `labels`, `status`, and `workflow_state`.
-- Preserved distinct `done` vs `closed` lifecycle semantics; close records `state: closed` and `resolution.md` without moving directories.
-- Updated Ticket backend, CLI, built-in tools, panel/TUI, role/session claims, orchestration-plan references, workflows, docs, tests, and local Ticket records to the flat ID/state model.
-- Migrated local Ticket records, including merge-boundary records created while the branch was under review.
-
-Implementation:
-- Coder commits included `191a875`, `591db3f`, `21114fd`, `8fe4b82`, `6ca27f3`, and `a6326a9`.
-- Reviewer approved after fix loops.
-- Merge commit: `634da5d merge: simplify ticket identity fields`.
-
-Validation:
-- Pre-merge and merge-boundary validation passed:
-  - `cargo fmt --check`
-  - `git diff --check`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - `cargo test -p ticket`
-  - `cargo check --workspace`
-  - `nix build .#yoi`
-- After runtime/tooling refresh, new tools also read the flat layout successfully and `cargo run -q -p yoi -- ticket doctor` reports `doctor: ok`.
-
-
----

.yoi/tickets/20260608-125430-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-054243-1","ticket_id":"20260608-125430-001","kind":"after","related_ticket":"20260608-072732-001","note":"Defer Objective record implementation until typed Ticket relation metadata lands; Objective links should be designed against the stable non-hierarchical relation/reference model, not in parallel with it.","author":"orchestrator","at":"2026-06-09T05:42:43Z"}

.yoi/tickets/20260608-125430-001/resolution.md

@@ -1,25 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added first lightweight Objective project-record surface.
-- Objective records live at `.yoi/objectives/<objective-id>/item.md` with path-derived opaque Objective IDs.
-- Objective frontmatter includes `title`, `state: active|paused|done|archived`, `created_at`, `updated_at`, and `linked_tickets` using canonical Ticket IDs.
-- Objective body includes required sections for goal, motivation/background, strategy/design direction, success criteria/exit conditions, and decision context.
-- Added top-level `yoi objective` CLI: `create`, `list`, `show`, and `doctor`.
-- Objective doctor validates malformed frontmatter/state/timestamps, missing required sections, unsafe IDs, and missing linked Ticket records.
-- Objective-to-Ticket links are non-blocking context links and do not write Ticket relation metadata, drive Ticket state, or replace OrchestrationPlan execution records.
-- Updated Intake/Orchestrator/work-item guidance to keep Objectives distinct from Tickets, TicketRelation metadata, OrchestrationPlan records, and Pod/session claims.
-
-Implementation:
-- Coder commit: `be12072 objective: add lightweight records`
-- Reviewer approved with no blocking findings.
-- Merge commit: `be69a8b merge: add objective records`
-
-Validation after merge:
-- `cargo test -p yoi objective_cli`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- objective doctor`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`

.yoi/tickets/20260608-125430-001/thread.md

@@ -1,331 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-08T12:54:30Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: plan author: intake at: 2026-06-09T00:17:06Z -->
-
-## Plan
-
-## Intake refinement
-
-既存 Ticket は `Objective` record の目的・背景・要件・受け入れ条件をすでに含んでおり、新規 Ticket 作成ではなくこの Ticket の refinement で足りる。`objective` label の重複 Ticket は見つからず、関連する planning Ticket として `typed-ticket-relation-metadata` と `deprecate-umbrella-tickets` がある。
-
-### Binding decisions / invariants
-
-- `Objective` は Ticket / OrchestrationPlan / Pod session claim と別の first-class project record として扱う。
-- Objective は medium-term goal、motivation、strategy / design direction、success criteria / exit conditions、decision context、linked Tickets を保持するための軽量 record であり、実装可能 work item である Ticket を置き換えない。
-- Objective と Ticket の link は dependency / blocking relation ではない。Ticket が Objective に属していても、その Objective 内の他 Ticket すべてに依存することを意味しない。
-- Objective context は Intake / Planning / Orchestrator の判断材料になるが、実装判断の authority は引き続き各 Ticket body/thread と明示的な Ticket relation / OrchestrationPlan record にある。
-- 初期設計は Markdown-oriented かつ local file backend 前提に留め、roadmap scheduling、milestones、OKR、dependency graph solving、全 Ticket への Objective 必須化は範囲外にする。
-- `Project` / `Initiative` ではなく `Objective` という用語を使う。
-
-### Implementation latitude
-
-- 具体的な record schema、`.yoi/` 配下の path、frontmatter fields、CLI/API 名、Panel 表示の段階分けは実装時の調査で提案してよい。
-- 初回 scope は設計文書と最小実装方針の提示で足りる。必要であれば小さな local-file reader/writer/API skeleton を提案してよいが、full roadmap system に広げない。
-- Ticket 側に Objective reference を置くか、Objective 側に linked Tickets を列挙するか、または両方をどう扱うかは、validation と git-trackable record と運用の単純さを基準に設計してよい。
-- `deprecate-umbrella-tickets` と `typed-ticket-relation-metadata` の内容は関連 context として読むべきだが、それらの実装をこの Ticket に取り込まない。
-
-### Escalation conditions
-
-- Objective が dependency/blocking relation、OrchestrationPlan runtime plan、または local Pod/session/worktree claim を兼ね始める設計になりそうな場合は Orchestrator/人間判断へ戻す。
-- Objective を全 Ticket に必須化する、または scheduling / roadmap / OKR system に拡張する必要が出た場合は scope creep として戻す。
-- public CLI/API、storage migration、backward compatibility、Panel UX の binding decision が複数案で割れる場合は、設計案と trade-off を thread に記録して判断を戻す。
-- Ticket body/thread を読まずに Objective context だけで実装判断できるような導線になりそうな場合は、Ticket authority boundary に反するため戻す。
-
-### Readiness
-
-- readiness: implementation_ready
-- risk_flags: [project-record, ticket-model, workflow, persistence, cli-api, panel-ux]
-- blocking open questions: none
-
-Validation は既存 acceptance criteria の通り `target/debug/yoi ticket doctor` と `git diff --check` を含める。runtime resource / prompt / packaging / code に触れる実装になった場合は repository guidance に従って focused tests と `nix build .#yoi` も実施する。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T00:17:13Z -->
-
-## Intake summary
-
-既存 Ticket を新規作成せず refinement した。`Objective` は Ticket / OrchestrationPlan / Pod/session claim と別の lightweight project record とし、medium-term goal・motivation・strategy/design direction・success criteria/exit conditions・decision context・linked Tickets を保持する。Ticket を置き換えず、Objective link は dependency/blocking relation ではない。初期 scope は Markdown/local-file 前提の設計と最小実装方針に限定し、roadmap scheduling、milestones、OKR、dependency graph solving、全 Ticket への Objective 必須化は範囲外。blocking open questions はなく、Orchestrator が implementation/design work として routing できる。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T00:17:13Z from: planning to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake refinement により目的・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions が揃ったため、workflow_state を ready にする。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T02:27:33Z from: ready to: queued reason: queued field: workflow_state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T02:28:14Z -->
-
-## Decision
-
-Routing decision: defer_pending_ticket_identity_migration
-
-This Ticket is queued and appears implementation-ready, but I am intentionally not accepting it to `inprogress` yet.
-
-Reason:
-- `simplify-ticket-identity-fields` is already active, with Coder Pod `coder-simplify-ticket-identity-fields` running in `.worktree/simplify-ticket-identity-fields`.
-- Objective record design/linking depends on stable Ticket identity and reference semantics, and the active Ticket is changing canonical Ticket identity, flat layout, state, and lookup surfaces.
-- Implementing Objective link/reference guidance before the identity simplification lands would create avoidable conflict and may choose reference shapes that immediately need migration.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T05:42:43Z -->
-
-## Decision
-
-Routing decision: waiting_for_relation_metadata
-
-`objective-records-for-medium-term-goals` remains queued, but implementation is intentionally ordered after `typed-ticket-relation-metadata`.
-
-Reason:
-- Objective records need stable Ticket link/reference semantics.
-- `typed-ticket-relation-metadata` is the lower-level non-hierarchical Ticket relation/reference surface that should land first.
-- Running both in parallel would create avoidable conflict in project-record guidance, Ticket link semantics, panel/CLI display, and Orchestrator/Intake wording.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- Complete and merge `typed-ticket-relation-metadata` first.
-- Re-read Objective records against the resulting relation/reference model, then accept from queued if still unblocked.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T06:32:20Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
-
-## State changed
-
-Accepted queued implementation after `typed-ticket-relation-metadata` landed, was validated, closed, and cleaned up. Objective records can now be designed against the flat canonical Ticket ID model and the newly available non-hierarchical Ticket relation metadata surface.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T06:32:20Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body and Intake refinement.
-- Prior deferral decisions for identity simplification and typed relation metadata.
-- OrchestrationPlan record requiring this Ticket to run after `20260608-072732-001`.
-- Current state: `simplify-ticket-identity-fields` and `typed-ticket-relation-metadata` are merged, validated, closed, and cleaned up.
-- Current Ticket model: flat canonical Ticket IDs, `state` lifecycle, and typed non-hierarchical Ticket relations are available.
-
-Reason:
-- The previous blockers are resolved.
-- The Ticket has explicit binding decisions and clear acceptance criteria.
-- This can proceed as a lightweight Objective record design/minimal implementation without replacing Tickets, typed Ticket relations, OrchestrationPlan, or Pod/session claims.
-
-IntentPacket:
-
-Intent:
-- Define and implement the first lightweight Objective record surface for medium-term goals, using local git-trackable project records and canonical Ticket IDs for links.
-
-Binding decisions / invariants:
-- Objective is a first-class project record distinct from Ticket, TicketRelation, OrchestrationPlan, and Pod/session claims.
-- Objective captures medium-term goal, motivation/background, strategy/design direction, success criteria/exit conditions, decision context, linked Tickets, and current Objective lifecycle if useful.
-- Objective does not replace Tickets. Tickets remain implementable work items and implementation authority remains each Ticket body/thread/artifacts plus explicit Ticket relations and OrchestrationPlan records.
-- Objective-to-Ticket links are not dependency/blocking relations. A Ticket linked to an Objective does not depend on every other linked Ticket.
-- Use canonical opaque Ticket IDs for Objective links; do not use title/slug words as link authority.
-- Keep the first version lightweight and Markdown/local-file oriented under a clear `.yoi/` path.
-- Avoid roadmap scheduling, milestones, OKRs, dependency graph solving, and making Objectives mandatory for every Ticket.
-- Do not implement or alter typed Ticket relation metadata except by using the already-landed relation concepts in docs/guidance where relevant.
-- Do not implement broad Panel UX if a minimal record/API/CLI surface is sufficient for this first version; note future UX follow-ups if needed.
-- Orchestrator/Intake guidance should say Objective context is judgment/background context, not a substitute for reading the Ticket.
-
-Implementation latitude:
-- Coder may choose exact storage path, e.g. `.yoi/objectives/<objective-id>/item.md` plus artifacts/thread if useful, if it is simple, typed enough, and git-trackable.
-- Coder may choose whether this first version is docs/design + minimal backend/CLI/tool skeleton or a fuller reader/writer/list/show implementation, but it must satisfy the acceptance criteria and remain bounded.
-- If implementing code, add focused parser/writer/doctor/CLI tests; if only designing, update docs/workflows and record a concrete implementation path with validation.
-- Prefer a path-derived opaque Objective ID model consistent with the new Ticket identity direction if IDs are introduced.
-
-Escalate if:
-- Objective starts to duplicate Ticket dependency/blocking relations, OrchestrationPlan execution decisions, or Pod/session runtime claims.
-- The design requires a full roadmap/OKR/scheduling system.
-- Objective links require changing Ticket relation metadata or Ticket identity semantics.
-- Storage/API shape requires a broad project-record framework beyond the first Objective surface.
-
-Validation:
-- If code/storage is implemented: focused Objective parser/writer/list/show/doctor/CLI tests and Ticket-link validation tests.
-- If docs/design only: focused text validation that Objective is distinct from Ticket/TicketRelation/OrchestrationPlan/Pod claims, Objective links are non-blocking/non-dependency, and Ticket body/thread remains authority.
-- `cargo fmt --check` if code/tests touched.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor`.
-- `cargo check --workspace` if code/tests touched.
-- `nix build .#yoi` if resources/docs/code/package inputs are touched.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T06:33:20Z -->
-
-## Implementation report
-
-Implementation routing started after the previously required typed Ticket relation metadata surface landed.
-
-Worktree/branch:
-- Worktree: `.worktree/objective-records-for-medium-term-goals`
-- Branch: `objective-records-for-medium-term-goals`
-- Base/routing commit: `4b3be3f ticket: route objective records`
-
-Spawned sibling Coder Pod:
-- `coder-objective-records-for-medium-term-goals`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- `simplify-ticket-identity-fields` is complete and the flat canonical Ticket ID/state model is active.
-- `typed-ticket-relation-metadata` is complete, so Objective links can now be designed against stable non-hierarchical Ticket relation/reference semantics.
-- This is now the active implementation work for the deferred Objective record Ticket.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T06:49:43Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-objective-records-for-medium-term-goals`
-- Commit: `be1207254708bea4035235b4cc49186817b83156 objective: add lightweight records`
-- Worktree status before review: clean branch `objective-records-for-medium-term-goals`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Selected design:
-- Objective records live at `.yoi/objectives/<objective-id>/item.md`.
-- Objective IDs are path-derived opaque canonical IDs; title/slug words are not authority.
-- Objective frontmatter fields: `title`, `state: active|paused|done|archived`, `created_at`, `updated_at`, `linked_tickets`.
-- Required Markdown sections: Goal, Motivation/background, Strategy/design direction, Success criteria/exit conditions, Decision context.
-- Objective-to-Ticket links use canonical Ticket IDs and are non-blocking context links, not Ticket dependency/blocking/ordering relations.
-
-Implementation summary:
-- Added top-level `yoi objective` CLI with create/list/show/doctor commands.
-- Objective create/doctor validate linked Tickets against the configured Ticket backend root.
-- Objective doctor validates frontmatter, state, timestamps, required body sections, and linked Ticket existence.
-- Updated Intake/Orchestrator/work-item guidance so Objective context remains distinct from Tickets, TicketRelation, OrchestrationPlan, and Pod/session claims.
-- Updated Nix package hash for the changed Cargo dependency graph.
-
-Changed files:
-- `.yoi/workflow/ticket-intake-workflow.md`
-- `.yoi/workflow/ticket-orchestrator-routing.md`
-- `Cargo.lock`
-- `crates/yoi/Cargo.toml`
-- `crates/yoi/src/main.rs`
-- `crates/yoi/src/objective_cli.rs`
-- `docs/development/work-items.md`
-- `package.nix`
-
-Coder validation reported passed:
-- `cargo test -p yoi objective_cli`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- objective doctor`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-Residual risks noted by coder:
-- Objective surface is intentionally minimal CLI/backend only; Panel UX, Objective thread/artifacts, roadmap/OKR/scheduling are not implemented.
-- Objective show uses exact Objective ID lookup only; prefix/title query is intentionally omitted to preserve opaque ID authority.
-- `linked_tickets` validates Ticket existence but does not write Ticket relation metadata, preserving the non-blocking boundary.
-
----
-
-<!-- event: review author: reviewer at: 2026-06-09T06:55:24Z status: approve -->
-
-## Review: approve
-
-Approved review for commit `be1207254708bea4035235b4cc49186817b83156` (`objective: add lightweight records`).
-
-Evidence checked:
-- `crates/yoi/src/objective_cli.rs` implements a local Markdown Objective record at `.yoi/objectives/<objective-id>/item.md`, with path-derived opaque Objective IDs and required sections for Goal, Motivation/background, Strategy/design direction, Success criteria/exit conditions, and Decision context.
-- Objective frontmatter is limited to Objective metadata (`title`, `state`, timestamps, `linked_tickets`) and does not create or mutate TicketRelation, OrchestrationPlan, Pod/session, or Panel state.
-- Linked Tickets are checked as safe single path components under the configured Ticket backend root and require an existing `item.md`; slug/title/path-word references without a canonical Ticket directory are rejected.
-- `doctor` validates malformed frontmatter/state/timestamps, missing required sections, unsafe IDs, and missing linked Ticket records.
-- Intake/Orchestrator/work-item docs describe Objective context as background/judgment context only; Tickets remain implementation authority, Objective links are non-blocking, and Objectives are not mandatory.
-- Keeping the initial implementation in the product `yoi` CLI is acceptable for the first lightweight local-file surface and avoids introducing a premature feature crate boundary.
-- Cargo changes add only the dependencies needed by this CLI/parser (`chrono`, `serde_yaml`), and `package.nix` updates the cargo hash accordingly.
-
-Validation run from the review worktree:
-- `cargo test -p yoi objective_cli`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- objective doctor`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-- Manual temp-workspace validation: canonical Ticket ID link create succeeds; slug/title-like missing link is rejected; malformed Objective with invalid state, missing sections, and missing linked Ticket makes `objective doctor` fail.
-
-Residual risks:
-- Objective remains a minimal CLI/local-file surface; Panel display, Objective artifacts/threading, reverse Ticket display, and richer project-record abstractions are intentionally future work.
-- Link validation is exact local backend existence validation rather than a separate Ticket-query API, which is consistent with the current flat local backend but should be revisited if Objective support moves into a shared library/provider boundary.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T06:57:19Z from: inprogress to: closed reason: closed field: state -->
-
-## State changed
-
-Ticket を closed にしました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T06:57:19Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added first lightweight Objective project-record surface.
-- Objective records live at `.yoi/objectives/<objective-id>/item.md` with path-derived opaque Objective IDs.
-- Objective frontmatter includes `title`, `state: active|paused|done|archived`, `created_at`, `updated_at`, and `linked_tickets` using canonical Ticket IDs.
-- Objective body includes required sections for goal, motivation/background, strategy/design direction, success criteria/exit conditions, and decision context.
-- Added top-level `yoi objective` CLI: `create`, `list`, `show`, and `doctor`.
-- Objective doctor validates malformed frontmatter/state/timestamps, missing required sections, unsafe IDs, and missing linked Ticket records.
-- Objective-to-Ticket links are non-blocking context links and do not write Ticket relation metadata, drive Ticket state, or replace OrchestrationPlan execution records.
-- Updated Intake/Orchestrator/work-item guidance to keep Objectives distinct from Tickets, TicketRelation metadata, OrchestrationPlan records, and Pod/session claims.
-
-Implementation:
-- Coder commit: `be12072 objective: add lightweight records`
-- Reviewer approved with no blocking findings.
-- Merge commit: `be69a8b merge: add objective records`
-
-Validation after merge:
-- `cargo test -p yoi objective_cli`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- objective doctor`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-
----

.yoi/tickets/20260608-132230-001/resolution.md

@@ -1,22 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Deprecated long-lived umbrella/progress-container Tickets in maintained workflow/docs guidance.
-- Clarified that Tickets should be concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
-- Updated broad-request split guidance to use concrete implementable Tickets, durable split decisions, Objective context, and future non-hierarchical typed relations rather than umbrella containers.
-- Explicitly disallowed hierarchy/container substitutes such as parent/child, sub-ticket, umbrella, part-of, and contains.
-- Preserved the carve-out for concrete planning/design/investigation Tickets.
-- Added existing umbrella retirement guidance and recorded a migration/close recommendation on `workspace-panel-orchestrator-queue-automation`.
-
-Implementation:
-- Coder commit: `1349a75 ticket: deprecate umbrella containers`
-- Reviewer approved with no blocking findings.
-- Merge commit: `ee41ed9 merge: deprecate umbrella tickets`
-
-Validation after merge:
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-`cargo check --workspace` was intentionally omitted because the merged implementation is docs/workflow/Ticket-thread-only and no Rust code/tests changed; Nix build covered package/resource integrity.

.yoi/tickets/20260608-132230-001/thread.md

@@ -1,339 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-08T13:22:30Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: plan author: intake at: 2026-06-09T00:16:33Z -->
-
-## Plan
-
-## Intake refinement
-
-既存 Ticket は新規 umbrella Ticket 廃止の方針・背景・要件・受け入れ条件・非目標をすでに含んでおり、新規 Ticket 作成ではなくこの Ticket の refinement で足りる。
-
-### Binding decisions / invariants
-
-- 新規の長期 umbrella Ticket / progress container は作らない方針として文書化する。
-- Ticket は単独で実装・レビュー・検証・完了判断できる concrete work item として扱う。
-- 広い依頼の分割時は、進捗コンテナとしての umbrella を残すのではなく、concrete Tickets、Objective、typed Ticket relations、thread/decision 記録に責務を分ける。
-- 既存 umbrella の退役 close は「関連作業がすべて完了した」ではなく「umbrella container の役割を退役した」ことを表す。
-- `typed-ticket-relation-metadata` と `objective-records-for-medium-term-goals` の設計実装はこの Ticket の範囲外に残す。
-
-### Implementation latitude
-
-- 具体的な変更箇所は実装時の調査で選んでよいが、少なくとも開発/workflow docs、Intake/Planning guidance、Orchestrator guidance に umbrella Ticket を作らない・退役する方針が反映されている必要がある。
-- 既存 umbrella の扱いは、代表例として `workspace-panel-orchestrator-queue-automation` に migration/close recommendation を残すか、明示的な follow-up に接続すればよい。
-
-### Escalation conditions
-
-- Objective または typed relation の current schema をこの作業内で設計・実装する必要が出た場合は scope creep として Orchestrator/人間判断へ戻す。
-- 既存 Ticket の大量移行や historical thread rewrite が必要に見える場合は、この Ticket の非目標に反するため判断を戻す。
-- umbrella 廃止方針が initial planning Ticket まで禁止する表現になりそうな場合は、受け入れ条件の「deprecated pattern is the long-lived umbrella progress container」を優先して調整する。
-
-### Readiness
-
-- readiness: implementation_ready
-- risk_flags: [ticket, workflow, documentation, planning, orchestration]
-- blocking open questions: none
-
-Validation は既存 acceptance criteria の通り、`target/debug/yoi ticket doctor` と `git diff --check` を含める。実装が runtime resource / prompt / package source に触れる場合は通常の repository guidance に従って `nix build .#yoi` も検討する。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T00:16:38Z -->
-
-## Intake summary
-
-既存 Ticket を refinement し、新規 umbrella Ticket 作成ではなくこの Ticket を concrete documentation/workflow cleanup として進める方針を確認した。新規の長期 umbrella/progress-container Ticket を非推奨化し、広い依頼は concrete Tickets、Objective、typed Ticket relations、thread/decision 記録へ責務分離する。Objective/typed relation の設計実装、大量 historical migration、thread rewrite は範囲外。blocking open question はなく、implementation_ready として Orchestrator が routing 可能。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T00:16:38Z from: planning to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake refinement により、意図・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions が揃ったため ready に遷移します。
-
----
-
-<!-- event: decision author: hare at: 2026-06-09T01:00:46Z -->
-
-## Decision
-
-## Decision: no hierarchy relations
-
-Umbrella Ticket deprecation also means not replacing umbrellas with Ticket hierarchy relations.
-
-Do not introduce or use these relation concepts for current Ticket work:
-
-- `parent` / `child`;
-- `sub-ticket`;
-- `umbrella`;
-- `part_of` / `contains` decomposition semantics.
-
-Concrete split work should become separate implementable Tickets. Medium-term context belongs in Objectives. Ticket relations should stay non-hierarchical: dependency, blocking, related, supersedes, duplicate/replacement, and similar direct relations.
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T01:14:14Z from: ready to: queued reason: queued field: workflow_state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T01:14:47Z -->
-
-## Decision
-
-Routing decision: defer_pending_policy_merge
-
-This Ticket is queued and appears implementation-ready, but I am intentionally not accepting it to `inprogress` yet.
-
-Reason:
-- There is an approved merge-ready workflow/docs branch pending: `orchestrator-return-to-planning-context-policy` at commit `8576615`.
-- `deprecate-umbrella-tickets` is also a workflow/docs/planning policy cleanup and is likely to touch adjacent files such as Orchestrator/Intake/Planning guidance and work-item docs.
-- Running it before the pending policy branch is merged or otherwise resolved would create unnecessary conflict/review risk across the same maintained policy surfaces.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- After `orchestrator-return-to-planning-context-policy` is merged/closed/cleaned up or explicitly held back, re-read this Ticket and accept it from queued if still unblocked.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T01:19:38Z from: queued to: inprogress reason: orchestrator_acceptance field: workflow_state -->
-
-## State changed
-
-Accepted queued implementation after re-reading the Ticket and current workspace state. The earlier deferral condition has been resolved: `orchestrator-return-to-planning-context-policy` was merged, validated, closed, and cleaned up, so there is no longer a pending adjacent policy branch blocking this work.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T01:19:38Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body and thread, including Intake refinement and the explicit `no hierarchy relations` decision.
-- Current workspace/worktree state after merging and cleaning up `orchestrator-return-to-planning-context-policy`.
-- Current open worktree list: no active implementation worktree remains.
-- The prior `defer_pending_policy_merge` blocker is resolved.
-
-Reason:
-- This is a bounded workflow/docs/planning policy cleanup.
-- It does not require implementing Objective records or typed relation metadata.
-- Requirements and acceptance criteria are concrete, including the migration/close recommendation for `workspace-panel-orchestrator-queue-automation`.
-
-IntentPacket:
-
-Intent:
-- Deprecate long-lived umbrella/progress-container Tickets and align Intake/Planning/Orchestrator/work-item guidance around concrete Tickets, Objectives, and non-hierarchical relation concepts.
-
-Binding decisions / invariants:
-- Do not create or endorse new umbrella Tickets for broad multi-Ticket efforts.
-- Tickets should be concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
-- Splitting broad requests should produce concrete implementable Tickets and durable decision context, not parent/child or umbrella containers.
-- Do not introduce or use hierarchy/container relations such as parent/child, sub-ticket, umbrella, part_of, or contains as replacements.
-- Typed Ticket relation design/implementation remains out of scope; relation wording must stay non-hierarchical and defer implementation details to `typed-ticket-relation-metadata`.
-- Objective record design/implementation remains out of scope; Objective references may be conceptual/policy guidance only.
-- Existing umbrella Tickets may be closed as superseded/decomposed once concrete follow-up Tickets/Objective context exists; that close means the container role is retired, not that all related future concerns are complete.
-- Preserve the ability to create an initial concrete planning/design/investigation Ticket when the user asks for a concrete work item; the deprecated pattern is the long-lived progress container.
-- Do not rewrite historical thread history or migrate every historical umbrella immediately.
-
-Implementation latitude:
-- Update maintained workflow docs, resource prompts/workflows, and development docs narrowly.
-- Add or update focused validation where practical. If there is no resource-test harness, focused grep/resource validation plus `git diff --check`, `ticket doctor`, and Nix build is acceptable for docs/workflow-only changes.
-- For `workspace-panel-orchestrator-queue-automation`, either record a clear migration/close recommendation in that Ticket thread or create a narrow follow-up if direct closure is not appropriate.
-
-Escalate if:
-- The implementation requires changing Ticket backend schema/workflow states.
-- Objective records or typed Ticket relation metadata must be implemented to express the policy.
-- The wording would accidentally prohibit concrete initial planning/design/investigation Tickets.
-- Broad historical migration or thread rewriting appears necessary.
-
-Validation:
-- Focused text validation for: no new umbrella/progress-container guidance; no parent/child/sub-ticket/part_of hierarchy replacement; concrete planning Ticket carve-out preserved; existing umbrella retirement guidance present.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor` or equivalent current binary Ticket doctor.
-- `nix build .#yoi` if workflows/resources/docs included in package inputs are touched.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T01:20:28Z -->
-
-## Implementation report
-
-Implementation routing started after the previously blocking policy branch was merged and cleaned up.
-
-Worktree/branch:
-- Worktree: `.worktree/deprecate-umbrella-tickets`
-- Branch: `deprecate-umbrella-tickets`
-- Base/routing commit: `8db8d7d ticket: route umbrella deprecation`
-
-Spawned sibling Coder Pod:
-- `coder-deprecate-umbrella-tickets`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- `orchestrator-return-to-planning-context-policy` is merged, validated, closed, and cleaned up.
-- This Ticket is now the active routed policy/workflow implementation work.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T01:33:23Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-deprecate-umbrella-tickets`
-- Commit: `1349a75 ticket: deprecate umbrella containers`
-- Worktree status before review: clean branch `deprecate-umbrella-tickets`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Implementation summary:
-- Updated workflow/docs guidance to deprecate long-lived umbrella/progress-container Tickets.
-- Clarified that Tickets should be concrete work items implementable/reviewable/validatable/closable on their own terms.
-- Added broad-request split guidance: create concrete Tickets, record split decisions, use Objective context for medium-term strategy, and keep future typed relations non-hierarchical.
-- Prohibited parent/child, sub-ticket, umbrella, part-of, contains, and similar hierarchy/container relation substitutes.
-- Preserved the carve-out for initial concrete planning/design/investigation Tickets.
-- Added existing-umbrella retirement guidance: close as superseded/decomposed once concrete follow-up Tickets and Objective context exist, with a resolution that lists completed concrete work and remaining follow-ups.
-- Recorded a migration/close recommendation on `workspace-panel-orchestrator-queue-automation`.
-
-Changed files:
-- `docs/development/work-items.md`
-- `.yoi/workflow/ticket-intake-workflow.md`
-- `.yoi/workflow/ticket-orchestrator-routing.md`
-- `.yoi/workflow/ticket-preflight-workflow.md`
-- `.yoi/workflow/multi-agent-workflow.md`
-- `.yoi/tickets/open/20260607-020215-workspace-panel-orchestrator-queue-automation/thread.md`
-
-Coder validation reported passed:
-- Focused text validation for umbrella/progress-container deprecation, hierarchy-relation prohibition, concrete planning carve-out, and existing umbrella retirement guidance.
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-Coder did not run `cargo check --workspace` because only docs/workflow/Ticket thread files changed.
-
----
-
-<!-- event: review author: reviewer at: 2026-06-09T01:36:52Z status: approve -->
-
-## Review: approve
-
-Reviewed commit `1349a75` (`ticket: deprecate umbrella containers`) against the Ticket invariants.
-
-Evidence checked:
-
-- Changed files are limited to maintained docs/workflow guidance plus the requested migration note thread: `docs/development/work-items.md`, `.yoi/workflow/{ticket-intake-workflow,ticket-orchestrator-routing,ticket-preflight-workflow,multi-agent-workflow}.md`, and `.yoi/tickets/open/20260607-020215-workspace-panel-orchestrator-queue-automation/thread.md`.
-- `docs/development/work-items.md` now defines Tickets as concrete work items that can be implemented/reviewed/validated/closed independently, disallows new broad umbrella/progress-container Tickets, explicitly forbids parent/child, sub-ticket, umbrella, part-of, contains, and hierarchy/container substitutes, preserves the carve-out for concrete planning/design/investigation Tickets, and documents superseded/decomposed retirement guidance for existing umbrellas.
-- Intake/Planning workflow guidance now avoids creating umbrella/progress-container Tickets and hierarchy/container relations during split/refinement while still allowing concrete investigation/design/planning Tickets when requested.
-- Orchestrator routing guidance now routes broad splits to concrete implementable Tickets / Objective context / split decision records, includes existing umbrella retirement/close-resolution guidance, and disallows hierarchy/container substitutes.
-- `multi-agent-workflow` clarifies that Pod delegation and multi-Ticket coordination are not Ticket hierarchy and should use concrete Tickets plus Objective/non-hierarchical relation context.
-- `workspace-panel-orchestrator-queue-automation` has an explicit migration/close recommendation saying to close the existing umbrella as superseded/decomposed once concrete follow-up Tickets/Objectives are confirmed, and that this does not implement backend schema, workflow_state, Objective records, or typed relations.
-- Focused grep over maintained docs/workflows found no conflicting active umbrella/parent-child guidance outside historical Ticket records/artifacts.
-
-Validation run:
-
-- `git diff --check 1349a75^ 1349a75` passed.
-- `cargo run -q -p yoi -- ticket doctor` passed (`doctor: ok`).
-- Focused text validation for umbrella deprecation, hierarchy prohibition, concrete planning carve-out, existing umbrella retirement guidance, and the queue-automation migration note passed.
-- `nix build .#yoi` passed.
-
-Decision: approve. The implementation satisfies the documentation/workflow policy cleanup without introducing Objective record implementation, typed relation implementation, Ticket backend schema changes, workflow_state semantic changes, broad historical migration, or thread rewrites.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T01:37:59Z -->
-
-## Implementation report
-
-Merge-ready dossier for human/orchestrator approval.
-
-Status:
-- Implementation branch: `deprecate-umbrella-tickets`
-- Worktree: `.worktree/deprecate-umbrella-tickets`
-- Commit under review: `1349a75 ticket: deprecate umbrella containers`
-- Reviewer: `reviewer-deprecate-umbrella-tickets`
-- Review result: approved; no blocking findings.
-
-Intent / invariant check:
-- Deprecates long-lived umbrella/progress-container Tickets in maintained workflow/docs guidance.
-- Keeps Tickets as concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
-- Does not implement Objective records, typed Ticket relation metadata, backend schema changes, workflow_state semantics changes, broad historical migration, or thread rewrites.
-- Preserves the carve-out for concrete planning/design/investigation Tickets when the user asks for a concrete work item.
-- Prohibits hierarchy/container substitutes such as parent/child, sub-ticket, umbrella, part-of, and contains.
-
-Implementation summary:
-- Updated `docs/development/work-items.md` and workflow guidance to avoid creating new umbrella/progress-container Tickets.
-- Aligned broad-request split guidance around concrete implementable Tickets, durable split decisions, Objective context, and future non-hierarchical typed relations.
-- Added existing umbrella retirement guidance: close as superseded/decomposed once concrete follow-ups and Objective context exist; resolution should list completed concrete Tickets plus remaining follow-up Tickets/Objectives.
-- Recorded a migration/close recommendation on `workspace-panel-orchestrator-queue-automation`, clarifying that retiring the container role does not mean all future concerns are complete.
-
-Validation evidence:
-- Coder reported pass:
-  - focused text validation for umbrella/progress-container deprecation, hierarchy-relation prohibition, concrete planning carve-out, and existing umbrella retirement guidance
-  - `git diff --check`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - `nix build .#yoi`
-- Reviewer independently passed:
-  - `git diff --check 1349a75^ 1349a75`
-  - `cargo run -q -p yoi -- ticket doctor`
-  - focused text validation / grep
-  - `nix build .#yoi`
-
-Residual risks / notes:
-- `cargo check --workspace` was intentionally not run because this is docs/workflow/Ticket-thread-only and `nix build .#yoi` covered package/resource integrity.
-- Final merge/close/cleanup is intentionally not performed here without explicit merge approval.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T02:04:39Z from: inprogress to: done reason: closed field: workflow_state -->
-
-## State changed
-
-Ticket closed; workflow_state を done に設定しました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T02:04:40Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Deprecated long-lived umbrella/progress-container Tickets in maintained workflow/docs guidance.
-- Clarified that Tickets should be concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
-- Updated broad-request split guidance to use concrete implementable Tickets, durable split decisions, Objective context, and future non-hierarchical typed relations rather than umbrella containers.
-- Explicitly disallowed hierarchy/container substitutes such as parent/child, sub-ticket, umbrella, part-of, and contains.
-- Preserved the carve-out for concrete planning/design/investigation Tickets.
-- Added existing umbrella retirement guidance and recorded a migration/close recommendation on `workspace-panel-orchestrator-queue-automation`.
-
-Implementation:
-- Coder commit: `1349a75 ticket: deprecate umbrella containers`
-- Reviewer approved with no blocking findings.
-- Merge commit: `ee41ed9 merge: deprecate umbrella tickets`
-
-Validation after merge:
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-`cargo check --workspace` was intentionally omitted because the merged implementation is docs/workflow/Ticket-thread-only and no Rust code/tests changed; Nix build covered package/resource integrity.
-
----

.yoi/tickets/20260609-032533-001/item.md

@@ -1,119 +0,0 @@
----
-title: "セッション解析ツールを追加する"
-state: 'closed'
-created_at: "2026-06-09T03:25:33Z"
-updated_at: '2026-06-09T07:40:53Z'
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T06:56:20Z'
----
-
-## 背景
-
-ドッグフーディングのセッションが十分に濃くなり、Worker / Pod の挙動を体感だけで調整するのが難しくなっている。永続化された session JSONL から安定した指標を抽出できる基盤が必要。
-
-現時点の懸念:
-
-- prune / compaction によってモデルが有用な文脈を失い、同じファイルを繰り返し読んでいる可能性がある。
-- `Read` の繰り返しが、必要な検証なのか、避けられる文脈喪失なのかを観測したい。
-- `Edit` の `old_string` / `new_string` が大きくなり、出力トークンを不必要に増やしている可能性がある。
-- 広すぎる `Bash` / `Grep` / `Glob` / `Read` の結果が history / context を膨らませている可能性がある。
-- 同じファイルへの編集 churn から、非効率な workflow や tool guidance の問題を見つけたい。
-
-まずは再利用可能な解析ライブラリとして作り、その上に CLI surface を薄く載せる。挙動を「無駄」と断定するのではなく、観測事実と suspicious pattern を報告する。
-
-## ゴール
-
-専用 crate `session-analytics` を作り、session JSONL log を解析して tool / session metrics を抽出できるようにする。その後、薄い `yoi session analyze` CLI として公開する。
-
-## 要件
-
-### ライブラリ crate
-
-- 専用の解析 crate を追加する。例: `crates/session-analytics`。
-- 1つの session file を解析する再利用可能 API を提供する。将来的には複数 session の集約も可能にする。
-  - 例: `analyze_session(path) -> SessionReport` または同等の API。
-  - 大きい session file を不必要に全読みしなくて済むよう、可能な範囲で streaming parse する。
-- TUI rendering や Pod runtime side effect から独立させる。
-- 既存の session / log schema 型は適切に再利用してよいが、runtime crate が analytics に依存する形にはしない。
-
-### 最初に抽出する metrics
-
-- Tool usage summary:
-  - tool name / kind ごとの呼び出し回数。
-  - turn ごとの tool call 数。
-  - failed tool call 数。
-  - 検出可能なら、より具体的な tool があるのに `Bash` で file inspection しているような broad tool usage pattern。
-- File read duplication:
-  - file path ごとの repeated `Read`。
-  - 同じ path + offset/limit の repeated `Read`。
-  - repeated read の間に対象ファイルへの write/edit があったかどうか。
-  - 観測可能なら compaction / prune event 後の repeated read。
-- Edit / write churn:
-  - file path ごとの `Edit` / `Write` 回数。
-  - 同一ファイルへの repeated edit。
-  - `old_string` / `new_string` / edit argument 全体のおおよその byte size。
-  - 出力トークンを増やし得る大きな replacement argument。
-  - `replace_all` の使用。
-- Tool result size:
-  - 取得可能な範囲で output bytes / lines。
-  - truncated / saved Bash output indicator。
-  - large `Read` / `Grep` / `Bash` / web result の観測。
-- Context lifecycle correlation:
-  - session log に存在する prune / compaction 関連 event を記録する。
-  - その後の repeated read / tool call と相関を取る。ただし因果として断定しない。
-
-### Report model
-
-- 後続の CLI / TUI / report rendering に使える構造化 `SessionReport` を定義する。
-- summary total と suspicious-pattern diagnostics の両方を含める。
-- 最初の安定 interface は machine-readable output を優先する。
-- default report では user input / file content の raw dump を避ける。
-  - path、count、byte size、timestamp / turn index、必要なら hash を含める。
-  - raw snippet / content は default では出さず、必要なら後続で明示 opt-in にする。
-
-### CLI integration
-
-- product binary に薄い CLI entrypoint を追加する。例:
-
-```text
-yoi session analyze <session-jsonl-or-session-id> [--json]
-```
-
-- 初期版は明示 file path 指定だけでもよい。
-- 後続拡張候補:
-  - `--latest`
-  - `--pod <name>`
-  - directory aggregation
-  - Markdown / human summary output
-- CLI は library crate を呼び、analytics logic を重複実装しない。
-
-### 意味論と制約
-
-- repeated read を自動的に悪いものとして扱わない。
-  - mutation 後の再読や validation のための再読は適切な場合がある。
-  - 事実と bounded suspicious diagnostics として報告する。
-- 通常出力で raw session content を露出しない。
-- 解析は read-only にする。
-- session log は記録済み tool call / history の authority として扱う。ただし context prune の因果は、明示 event がない限り相関としてしか推定できない。
-
-## 非目標
-
-- この Ticket で Worker の pruning / compaction 挙動を変更すること。
-- analytics 用の full TUI dashboard を作ること。
-- metrics に基づいて prompt / tool guidance を自動修正すること。
-- LLM を使って session content を意味的に要約すること。
-- default report で secret や raw file content を露出すること。
-
-## 受け入れ条件
-
-- `session-analytics` crate が存在し、tool analytics に必要な current session JSONL entry を少なくとも parse できる。
-- library が tool counts、repeated reads、edit/write churn、edit argument sizes、large/truncated result observations を含む structured report を返す。
-- `yoi session analyze <path> --json` または同等の CLI が machine-readable output を出す。
-- report は default で raw user/file content を避ける。
-- tests が以下を cover する:
-  - intervening edit あり/なしの repeated reads。
-  - large edit argument sizing。
-  - tool failure counting。
-  - representative log entry がある場合の basic compaction/prune event correlation。
-  - malformed / unknown log entry を bounded diagnostics で扱うこと。
-- focused tests、`cargo fmt --check`、`git diff --check`、`target/debug/yoi ticket doctor` が通る。

.yoi/tickets/20260609-032533-001/resolution.md

@@ -1,25 +0,0 @@
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added reusable `crates/session-analytics` library with `analyze_session(path) -> SessionReport`.
-- Added thin product CLI `yoi session analyze <SESSION_JSONL_PATH> --json` that delegates to the library.
-- Implemented tolerant streaming JSONL parsing with bounded malformed/unknown-entry diagnostics.
-- Report covers tool usage counts, calls per turn, failed tool counts, repeated reads with mutation/context-lifecycle observations, edit/write churn, `replace_all`, large edit/result observations, saved/truncated Bash outputs, and compaction/prune/context correlations.
-- Default report avoids raw user input, raw tool arguments, raw file contents, raw session snippets, and raw tool output content.
-- Tests use synthetic/minimal fixtures rather than private local sessions.
-- No Worker pruning/compaction, Pod protocol/history/session writer, TUI dashboard, prompt auto-fixer, or LLM summarization behavior was changed.
-
-Implementation:
-- Coder commit: `c1809b3 feat: add session analytics tooling`
-- Reviewer approved with no blocking findings.
-- Merge commit: `0d2a6a7 merge: add session analytics tooling`
-
-Validation after merge:
-- `cargo test -p session-analytics`
-- `cargo test -p yoi session_cli`
-- `cargo test -p yoi parse_session_analyze_uses_session_mode`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`

.yoi/tickets/20260609-032533-001/thread.md

@@ -1,273 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T03:25:33Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T04:43:46Z -->
-
-## Intake summary
-
-既存 Ticket は、session JSONL を read-only に解析する再利用可能な `session-analytics` crate と薄い `yoi session analyze <path> --json` CLI を追加する concrete work item として十分に具体化済み。初期対象 metrics、raw content を既定で出さない privacy/secret 境界、non-goals、受け入れ条件、検証項目が明記されており、Orchestrator が実装 routing を判断できる。関連する `prompt-eval-metrics` は評価/改善 offer 寄りであり、本 Ticket は低レベル session/tool analytics 基盤として重複ではない。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T04:43:46Z from: planning to: ready reason: intake_ready field: workflow_state -->
-
-## State changed
-
-Intake で要件が実装 routing 可能な粒度まで整理済みであることを確認したため、planning から ready にします。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T06:56:20Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T06:59:15Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
-
-## State changed
-
-Accepted queued implementation after reading the Ticket body/thread and current workspace state. The Ticket has concrete library/CLI/report/privacy acceptance criteria and does not depend on the just-landed Objective work. Implementation can proceed with synthetic fixture tests and read-only analysis semantics.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T06:59:15Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body and Intake summary.
-- Current workspace state after Objective records merged, closed, and cleaned up.
-- Current worktree state: no active implementation worktree remains.
-- Current queued set: this is the only queued Ticket.
-
-Reason:
-- The Ticket is specific enough for implementation: add a reusable `session-analytics` crate, structured report model, and thin `yoi session analyze <path> --json` CLI.
-- The privacy boundary is explicit: default output must not dump raw user input, file contents, secrets, or raw session snippets.
-- The non-goals are clear: no pruning/compaction behavior changes, no TUI dashboard, no prompt/tool guidance auto-rewrite, no LLM semantic summarization.
-
-IntentPacket:
-
-Intent:
-- Add read-only session JSONL analytics that extracts structured tool/session metrics and suspicious-pattern diagnostics without exposing raw content by default.
-
-Binding decisions / invariants:
-- Add a reusable library crate, e.g. `crates/session-analytics`, with an API such as `analyze_session(path) -> SessionReport`.
-- Add a thin product CLI surface, e.g. `yoi session analyze <session-jsonl-or-path> --json`, that calls the library and avoids duplicating analytics logic.
-- Prefer streaming/bounded parsing for large JSONL files; do not unnecessarily read huge files into memory if line-by-line parsing is practical.
-- Analysis is read-only and has no runtime side effects.
-- The analytics crate must stay independent from TUI rendering and Pod runtime side effects; runtime crates must not depend on analytics.
-- Reuse current session/log schema types only where dependency direction remains healthy.
-- Structured report should include at least:
-  - tool usage counts by name/kind;
-  - tool calls per turn;
-  - failed tool call counts;
-  - repeated `Read` by path and by path+offset/limit;
-  - whether repeated reads had intervening write/edit observations;
-  - edit/write churn by path;
-  - edit/write argument byte-size estimates and large replacement diagnostics;
-  - `replace_all` usage;
-  - observable tool result sizes/large/truncated indicators where available;
-  - prune/compaction events and bounded correlation with subsequent repeated reads/tool calls;
-  - malformed/unknown entry diagnostics.
-- Suspicious diagnostics must be framed as observations, not automatic blame. Re-reading after mutation or validation may be correct.
-- Default CLI/report output must avoid raw user input/file contents/session snippets. It may include paths, counts, byte sizes, turn/timestamp indexes, and hashes if useful.
-- Tests should use synthetic/minimal session JSONL fixtures rather than relying on private local sessions.
-- Do not implement a full dashboard, prompt auto-fixer, semantic summarizer, or Worker pruning/compaction behavior changes.
-
-Implementation latitude:
-- Coder may choose exact report struct field names and JSON format if machine-readable and test-covered.
-- Coder may add a small JSONL adapter tolerant of unknown/malformed records with bounded diagnostics if current session log enum parsing is too strict.
-- Coder may keep initial path input file-only; `--latest`, `--pod`, directory aggregation, and Markdown output can remain future work.
-- If current session schema is too hard to reuse without unhealthy dependencies, implement a minimal analytics event parser for the observed JSONL shape and document the limitation.
-
-Escalate if:
-- Implementing this requires changing session writer/history schemas or Worker compaction behavior.
-- Avoiding raw-content exposure conflicts with required metrics.
-- Healthy crate dependency direction would require a larger session-schema extraction refactor.
-- Real local session data would need to be read for tests/validation; use synthetic fixtures instead unless explicitly authorized.
-
-Validation:
-- Focused unit tests for repeated reads with/without intervening edit/write.
-- Focused tests for large edit argument sizing and replace_all observations.
-- Focused tests for tool failure counting and tool calls per turn.
-- Focused tests for large/truncated result observations if representable in fixtures.
-- Focused tests for compaction/prune event correlation as correlation only.
-- Focused tests for malformed/unknown JSONL entries producing bounded diagnostics.
-- CLI JSON output test for `yoi session analyze <path> --json` or equivalent.
-- `cargo fmt --check`.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor`.
-- `cargo check --workspace`.
-- `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T07:00:26Z -->
-
-## Implementation report
-
-Implementation routing started.
-
-Worktree/branch:
-- Worktree: `.worktree/session-analytics-tooling`
-- Branch: `session-analytics-tooling`
-- Base/routing commit: `c166140 ticket: route session analytics tooling`
-
-Spawned sibling Coder Pod:
-- `coder-session-analytics-tooling`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- This Ticket is now the active implementation work.
-- Handoff explicitly requires synthetic/minimal session fixtures for validation and avoids reading private real local session contents.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T07:26:46Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-session-analytics-tooling`
-- Commit: `c1809b37b1816a73e18c7587b9952cf4fc7b43f3 feat: add session analytics tooling`
-- Worktree status before review: clean branch `session-analytics-tooling`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Selected design:
-- Added `crates/session-analytics` with public `analyze_session(path) -> SessionReport`.
-- Parser is a tolerant `serde_json::Value` JSONL parser using `BufReader::lines()` instead of tightly coupling analytics to runtime schema enums.
-- Report avoids raw user input, raw tool arguments, raw file contents, and raw tool output snippets by default; it reports paths, counts, byte/line sizes, line/turn indexes, bounded diagnostics, and observation text.
-- Added thin CLI `yoi session analyze <SESSION_JSONL_PATH> --json` that delegates to the library crate.
-
-Implementation summary:
-- Tool usage summary: counts by tool name/kind, calls per turn, failed tool result count, and Bash file-inspection-like heuristic observations.
-- Repeated reads: by path and path+offset/limit, with intervening Edit/Write observation and post-context-lifecycle correlation.
-- Edit/write churn: counts by path, repeated edits, argument byte-size estimates, large replacement diagnostics, and `replace_all` observations.
-- Tool result size: output byte/line sizes, large result observations, and saved/truncated Bash result indicators.
-- Context lifecycle: observes `segment_start.compacted_from` and context/prune/compact-like extension events; correlation only, not causation.
-- Robustness: malformed/unknown JSONL entries produce bounded diagnostics; unreadable input file remains an error.
-
-Changed files:
-- `Cargo.toml`
-- `Cargo.lock`
-- `package.nix`
-- `crates/session-analytics/Cargo.toml`
-- `crates/session-analytics/src/lib.rs`
-- `crates/yoi/Cargo.toml`
-- `crates/yoi/src/main.rs`
-- `crates/yoi/src/session_cli.rs`
-
-Coder validation reported passed:
-- `cargo test -p session-analytics`
-- `cargo test -p yoi session_cli`
-- `cargo test -p yoi parse_session_analyze_uses_session_mode`
-- `cargo fmt --check`
-- `git diff --check`
-- `git diff --cached --check`
-- `cargo run -q -p yoi -- ticket doctor` -> `doctor: ok`
-- `cargo check --workspace`
-- `nix build .#yoi`
-- `result/bin/yoi session analyze --help`
-
-Residual risks noted by coder:
-- Parser is intentionally tolerant and may emit more diagnostics if future session JSONL shapes change.
-- Context lifecycle support is based on currently observable `segment_start.compacted_from` and context/prune/compact-like extension events.
-- Bash file-inspection detection is a lightweight heuristic and should be treated as an observation, not automatic blame.
-
----
-
-<!-- event: review author: reviewer-session-analytics-tooling at: 2026-06-09T07:37:41Z status: approve -->
-
-## Review: approve
-
-## Review result: approve
-
-Reviewed commit `c1809b37b1816a73e18c7587b9952cf4fc7b43f3` on branch `session-analytics-tooling` in worktree `.worktree/session-analytics-tooling`.
-
-### Evidence
-
-- The implementation adds `crates/session-analytics` with public `analyze_session(path) -> SessionReport` and a tolerant JSONL parser using `BufReader::lines()` / per-line `serde_json::Value` parsing.
-- The product CLI adds a thin `yoi session analyze <SESSION_JSONL_PATH> --json` surface through `crates/yoi/src/session_cli.rs`; analytics logic remains in the library crate.
-- Changed files are limited to workspace/package metadata, the new analytics crate, and the top-level product CLI wiring. I did not find changes to Worker pruning/compaction, Pod protocol/history/session writer semantics, TUI dashboarding, prompt auto-fixing, or summarization behavior.
-- Dependency direction is healthy for this Ticket: `session-analytics` depends only on `serde`, `serde_json`, and `thiserror` plus test `tempfile`; `cargo tree -i session-analytics --workspace` shows the product `yoi` crate as the consumer, not runtime/TUI crates.
-- Privacy boundary checked with a synthetic fixture containing secret-like user/file/tool argument/tool output strings. JSON output did not include raw `Read` content, `Edit` old/new strings, Bash command arguments, or Bash result content; it emitted paths, counts, byte/line sizes, line/turn indexes, and bounded observations.
-- Malformed and unknown JSONL entries are counted and surfaced as bounded diagnostics instead of crashing the whole report; unreadable input remains an error.
-- Tests are synthetic/minimal fixtures in the new crate / CLI tests, not private local sessions.
-
-### Validation run
-
-Passed:
-
-- `cargo test -p session-analytics`
-- `cargo test -p yoi session_cli`
-- `cargo test -p yoi parse_session_analyze_uses_session_mode`
-- synthetic CLI JSON privacy/metrics assertion fixture created during review
-- `cargo fmt --check`
-- `git diff --check HEAD~1..HEAD`
-- `cargo check --workspace`
-- `nix build .#yoi`
-- `result/bin/yoi session analyze --help`
-- `git diff --exit-code` / `git status --short` clean after review
-
-### Residual risks / notes
-
-- Tool result size reporting is most detailed for large-result and truncated/saved Bash observations; this meets the Ticket acceptance focus, but future aggregation could add per-tool output-size histograms if analysis needs it.
-- Repeated-read and Bash-file-inspection diagnostics are correctly framed as observations/correlations rather than automatic blame.
-- The new top-level `session` subcommand reserves that literal bare token; explicit `--pod session` remains the escape hatch for a Pod named `session`.
-
----
-
-<!-- event: state_changed author: hare at: 2026-06-09T07:40:53Z from: inprogress to: closed reason: closed field: state -->
-
-## State changed
-
-Ticket を closed にしました。
-
-
----
-
-<!-- event: close author: hare at: 2026-06-09T07:40:53Z status: closed -->
-
-## 完了
-
-Implemented, reviewed, merged, and validated.
-
-Summary:
-- Added reusable `crates/session-analytics` library with `analyze_session(path) -> SessionReport`.
-- Added thin product CLI `yoi session analyze <SESSION_JSONL_PATH> --json` that delegates to the library.
-- Implemented tolerant streaming JSONL parsing with bounded malformed/unknown-entry diagnostics.
-- Report covers tool usage counts, calls per turn, failed tool counts, repeated reads with mutation/context-lifecycle observations, edit/write churn, `replace_all`, large edit/result observations, saved/truncated Bash outputs, and compaction/prune/context correlations.
-- Default report avoids raw user input, raw tool arguments, raw file contents, raw session snippets, and raw tool output content.
-- Tests use synthetic/minimal fixtures rather than private local sessions.
-- No Worker pruning/compaction, Pod protocol/history/session writer, TUI dashboard, prompt auto-fixer, or LLM summarization behavior was changed.
-
-Implementation:
-- Coder commit: `c1809b3 feat: add session analytics tooling`
-- Reviewer approved with no blocking findings.
-- Merge commit: `0d2a6a7 merge: add session analytics tooling`
-
-Validation after merge:
-- `cargo test -p session-analytics`
-- `cargo test -p yoi session_cli`
-- `cargo test -p yoi parse_session_analyze_uses_session_mode`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo run -q -p yoi -- ticket doctor`
-- `cargo check --workspace`
-- `nix build .#yoi`
-
-
----

.yoi/tickets/20260609-073047-001/artifacts/relations.json

@@ -1,13 +0,0 @@
-{
-  "version": 1,
-  "relations": [
-    {
-      "ticket_id": "20260609-073047-001",
-      "kind": "related",
-      "target": "20260608-110940-001",
-      "note": "非ブロッキング関連。先行の Ticket identity/frontmatter 簡素化で timestamp/counter 型の opaque canonical ID と flat layout が導入済みで、本 Ticket はその ID 形式を Ticket / Objective 共通の fixed-width base32 epoch-milliseconds 形式へさらに統一する follow-up。",
-      "author": "intake",
-      "at": "2026-06-09T10:26:20Z"
-    }
-  ]
-}

.yoi/tickets/20260609-073047-001/item.md

@@ -1,96 +0,0 @@
----
-title: 'Ticket と Objective の ID を base32 timestamp 形式に統一する'
-state: 'queued'
-created_at: '2026-06-09T07:30:47Z'
-updated_at: '2026-06-09T10:35:08Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:31:17Z'
----
-
-## 背景
-
-Ticket identity simplification と Objective record 導入により、Ticket / Objective の canonical ID を共通の短い不透明 ID に揃えたい。
-
-現状:
-
-- Ticket は過去の timestamp + slug 形式から移行中。
-- Objective は `YYYYMMDD-HHMMSS-001` 形式で、秒単位 timestamp + counter を使っている。
-
-望ましい方向:
-
-- ID は title / slug / 内容を含まない。
-- lexicographic sort が作成時系列として使える。
-- 完全連番は Git branch / workspace 並行作業で衝突しやすいため避ける。
-- 秒単位 + `-001` ではなく、millisecond timestamp を短い固定幅 text に圧縮する。
-- `created_at` は人間可読な timestamp field として別に持つ。
-
-## ゴール
-
-Ticket と Objective の canonical ID を、共通の fixed-width base32 encoded Unix epoch milliseconds 形式に統一する。
-
-## 要件
-
-- Ticket と Objective の canonical ID 形式を共通化する。
-- ID は Unix epoch milliseconds を base32 text にしたものにする。
-- alphabet は人間が読み間違えにくいものを使う。
-  - 例: Crockford base32 系 `0123456789ABCDEFGHJKMNPQRSTVWXYZ`。
-  - `I` / `L` / `O` など紛らわしい文字は避ける。
-- ID は fixed width にする。
-  - 例: 9 chars。
-  - fixed width により lexicographic sort が chronological sort と一致する。
-- ID は title / slug / content words を含まない。
-- ID は canonical path component として安全であること。
-- `created_at` は引き続き frontmatter field として持つ。
-  - ID は compact primary key。
-  - `created_at` は人間可読な作成時刻。
-- `updated_at` も existing behavior として維持する。
-
-## Collision handling
-
-- ID 生成時に同じ workspace 内で path collision が起きた場合、timestamp milliseconds を `+1ms` して再 encode する。
-- 衝突時に `-001` / suffix / random tail を付けない。
-- `+1ms` を繰り返して空き ID を探す。
-- 生成に使った adjusted timestamp と `created_at` の関係を明確にする。
-  - 推奨: `created_at` は実作成時刻を保持し、ID は collision-adjusted primary key として扱う。
-  - もしくは adjusted timestamp を `created_at` にも反映する場合は、その理由を明記する。
-- 過剰衝突時の bounded error を用意する。
-
-## Scope
-
-- 共通 ID allocator/helper を作る。
-  - Ticket create path と Objective create path で共有する。
-  - 将来の project records にも使える形が望ましい。
-- Ticket create / path layout をこの ID 形式に移行する。
-- Objective create / path layout をこの ID 形式に移行する。
-- Existing Ticket / Objective records を migration する。
-- `TicketList` / `TicketShow` / `Objective list` / `Objective show` / doctor / tests を更新する。
-- Relation metadata や Objective linked tickets は、この canonical ID を前提にする。
-
-## 非目標
-
-- ID から作成時刻を人間が直接読めるようにすること。
-  - 必要なら `created_at` を見る。
-- 完全連番 ID。
-- title / slug を ID に含めること。
-- random UUID を使うこと。
-- この Ticket で Ticket relation metadata や Objective の高機能化を実装すること。
-
-## 受け入れ条件
-
-- Ticket と Objective の新規作成で同じ canonical ID format が使われる。
-- ID は fixed-width base32 epoch-milliseconds text で、title/slug を含まない。
-- ID の lexicographic sort が作成時系列と一致する。
-- 同一 millisecond collision は `+1ms` retry で解決される。
-- `created_at` と `updated_at` が frontmatter に残る。
-- Existing Ticket / Objective records が新 ID/path に migration される。
-- Objective の `YYYYMMDD-HHMMSS-001` 形式は current format ではなくなる。
-- Ticket の old timestamp-slug path / slug-derived identity は current format ではなくなる。
-- Tests cover:
-  - encoding/decoding or ordering property;
-  - collision handling;
-  - Ticket create;
-  - Objective create;
-  - doctor validation;
-  - migration-relevant lookup behavior.
-- `target/debug/yoi ticket doctor`, `target/debug/yoi objective doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.

.yoi/tickets/20260609-073047-001/thread.md

@@ -1,95 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T07:30:47Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T10:26:34Z -->
-
-## Decision
-
-Intake refinement / readiness decision。
-
-この Ticket は `implementation_ready` として扱える。目的、対象範囲、受け入れ条件、collision handling、migration 対象、非目標がすでに具体化されており、Orchestrator が実装 routing を判断できる。
-
-Binding decisions / invariants:
-
-- Ticket と Objective の canonical ID は共通の fixed-width base32 encoded Unix epoch milliseconds text に統一する。
-- ID は title / slug / content words を含めない opaque path component とする。
-- fixed width により lexicographic sort と chronological sort が一致することを維持する。
-- 同一 millisecond collision は suffix / random tail ではなく `+1ms` retry で解決する。
-- `created_at` / `updated_at` は frontmatter の人間可読 timestamp field として維持する。
-- 既存 Ticket / Objective record の migration、lookup、doctor、関連 metadata / linked-ticket 参照の整合性を対象に含める。
-
-Implementation latitude:
-
-- exact width と alphabet は要件を満たす範囲で実装時に確定してよい。現行 epoch milliseconds を十分な期間表現でき、紛らわしい文字を避け、path-safe で、固定長 ordering property を満たすこと。Crockford base32 系と 9 chars は推奨例として扱える。
-- 共通 helper の crate / module 配置は、Ticket create path と Objective create path から共有でき、将来の project records に自然に拡張できる範囲で実装判断してよい。
-- migration は既存 durable project records を壊さず、canonical ID/path と内部参照を一貫して更新できる方式を選ぶ。
-
-Risk flags / reviewer focus:
-
-- `storage-migration`
-- `canonical-id-schema`
-- `ticket-objective-cross-reference`
-- `backward-compatibility-boundary`
-- `cli-doctor-validation`
-
-Escalation conditions:
-
-- fixed-width base32 epoch milliseconds では要件の ordering / collision / path-safety を同時に満たせないと判明した場合。
-- 既存 Ticket / Objective migration が reference integrity を安全に保てない場合。
-- exact width を 9 chars から大きく外す、Crockford 系ではない alphabet を採る、または random / suffix fallback を追加したくなった場合。
-- ID timestamp と `created_at` の関係を推奨と異なる semantics にしたい場合。
-
-Validation expectation:
-
-- Ticket body の既存 validation に加え、コード・パッケージングに関わるため完了前に `nix build .#yoi` も通す。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T10:26:42Z -->
-
-## Intake summary
-
-Ticket と Objective の canonical ID を共通の fixed-width base32 epoch-milliseconds 形式へ統一する concrete work item として整理済み。Open questions はなく、binding decisions は opaque/path-safe ID、title/slug/content words 非包含、lexicographic ordering、`+1ms` collision retry、`created_at` / `updated_at` 維持、既存 Ticket / Objective migration と参照整合性。Risk flags は storage-migration / canonical-id-schema / ticket-objective-cross-reference / backward-compatibility-boundary / cli-doctor-validation。関連する先行 Ticket `20260608-110940-001` は closed の非ブロッキング前提、`20260609-085212-001` は非ブロッキング関連。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T10:26:42Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake refinement により、目的・範囲・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions・validation focus が揃ったため、Orchestrator が routing できる ready に移行する。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:31:17Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:35:08Z -->
-
-## Decision
-
-Routing decision: waiting_for_active_record_churn_to_settle
-
-This Ticket remains queued for now, despite the updated parallelism preference.
-
-Reason:
-- This Ticket is a broad Ticket/Objective ID migration touching current project-record paths and internal references.
-- There are multiple active worktrees currently writing Ticket records and code.
-- Running a storage/ID migration in parallel with active Ticket record churn would create high merge/migration risk, not a small conflict.
-
-State decision:
-- Leave this Ticket `queued`.
-- Re-read when active worktrees are merged/closed or the workspace is otherwise quiescent enough for a record migration.
-
----

.yoi/tickets/20260609-082209-001/item.md

@@ -1,149 +0,0 @@
----
-title: 'Profile feature flagsでtool surfaceを制御する'
-state: 'queued'
-created_at: '2026-06-09T08:22:09Z'
-updated_at: '2026-06-09T10:35:08Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:31:11Z'
----
-
-## 背景
-
-最近追加した Ticket tools、Ticket orchestration tools、Pod orchestration tools などにより、Pod に渡される tool schema が増えている。すべての role にすべての tools を渡すと、コンテキストを圧迫し、tool choice の性能低下や role 外行動を誘発する。
-
-現状は core tools、Task tools、Ticket tools、Pod orchestration tools などがかなり広く登録されており、role/profile から feature 単位で tool surface を選ぶ設定がない。
-
-Coder は Ticket 管理や orchestration をしないなら、それらの tools を見るべきではない。SpawnPod などの Pod orchestration tools も、明示的に与えられた role/profile だけが使える optional capability にするべき。
-
-## ゴール
-
-Lua Profile / resolved Manifest に feature 単位の tool selection を導入し、role ごとに不要な high-level tools を登録しないようにする。
-
-## 要件
-
-### Profile syntax
-
-- Lua Profile に `feature.<name>.enabled` を追加する。
-- object の存在確認ではなく、明示 bool を見る。
-  - `feature.ticket = {}` が true 扱いになるような挙動は避ける。
-  - `enabled = true` / `enabled = false` を authority とする。
-- まず対応する feature groups:
-  - `task`
-  - `ticket`
-  - `ticket_orchestration`
-  - `pods`
-  - `memory`
-  - `web`
-- resolved Manifest では各 feature の enabled が concrete bool になるようにする。
-- Profile source layer では optional でもよいが、project role profiles は明示的に設定する。
-
-### Feature group semantics
-
-- `feature.task`:
-  - `TaskCreate`
-  - `TaskUpdate`
-  - `TaskGet`
-  - `TaskList`
-- `feature.ticket`:
-  - Ticket の基本 lifecycle / review / state / close / doctor tools。
-  - access level が必要なら `access` を追加する。
-    - 候補: `read_only`, `intake`, `reviewer`, `lifecycle`。
-- `feature.ticket_orchestration`:
-  - Ticket relation / orchestration plan 系 tools。
-  - 例: `TicketRelationRecord`, `TicketRelationQuery`, `TicketOrchestrationPlanRecord`, `TicketOrchestrationPlanQuery`。
-  - Orchestrator 専用に近い。
-- `feature.pods`:
-  - Pod orchestration / communication tools。
-  - 例: `SpawnPod`, `SendToPod`, `ReadPodOutput`, `StopPod`, `ListPods`, `RestorePod`, `SendToPeerPod`。
-  - disabled の場合は tool schema に出さない。
-- `feature.memory`:
-  - Memory / Knowledge tools。
-  - access level が必要なら後続または同 Ticket 内で `read_only` / `write` を検討する。
-- `feature.web`:
-  - `WebSearch`, `WebFetch`。
-  - existing web provider config と連動する。
-  - `feature.web.enabled=false` なら tools を登録しない。
-  - provider config が不足している場合は、enabled でも existing fail-closed behavior を維持してよい。
-
-### Core tools
-
-- この feature grouping には core filesystem / shell tools を含めない。
-  - `Read`
-  - `Write`
-  - `Edit`
-  - `Glob`
-  - `Grep`
-  - `Bash`
-- これらは workspace scope / tool permission policy の制御対象として扱う。
-- `Bash` は将来的に別途 opt-in/tool permission refinement の対象になり得るが、この Ticket の first pass には含めない。
-
-### Registration behavior
-
-- disabled feature の tools は Worker に登録しない。
-- permission deny で失敗させるのではなく、tool schema から消す。
-- feature disabled によって normal prompt guidance も可能な範囲でその tool group を前提にしない。
-- FeatureRegistry / controller の無条件 registration を profile/resolved manifest に基づく conditional registration に変更する。
-
-### Role defaults
-
-Project role profiles should set feature defaults explicitly.
-
-- Orchestrator:
-  - `ticket = enabled`, lifecycle access
-  - `ticket_orchestration = enabled`
-  - `pods = enabled`
-  - `task = disabled` unless explicitly justified
-  - `memory = enabled` preferably read/query oriented
-  - `web = enabled` if configured
-- Intake:
-  - `ticket = enabled`, intake-oriented access
-  - `ticket_orchestration = disabled`
-  - `pods = disabled`
-  - `task = disabled`
-  - `memory = enabled` preferably read/query oriented
-  - `web = enabled` if configured
-- Coder:
-  - `ticket = disabled` by default
-  - `ticket_orchestration = disabled`
-  - `pods = disabled`
-  - `task = disabled`
-  - `memory = enabled` only if desired for read/query context
-  - `web = enabled` if configured
-- Reviewer:
-  - `ticket = disabled` or reviewer/read-only access depending on chosen review-report flow
-  - `ticket_orchestration = disabled`
-  - `pods = disabled`
-  - `task = disabled`
-- Companion:
-  - `ticket = read_only` if useful
-  - `ticket_orchestration = disabled`
-  - `pods = disabled` unless a specific Companion Pod-management UI/tool role is designed
-  - `task = disabled`
-
-### Access granularity
-
-- If `ticket.enabled=true` is too broad, implement or design `feature.ticket.access` in the same change.
-- Existing `TicketFeatureAccess::ReadOnly` / `Lifecycle` should be reused or extended rather than ignored.
-- `ticket_orchestration` should be separable from basic Ticket read/show/list tools.
-
-## 非目標
-
-- Redesigning core filesystem tools.
-- Removing permission policy.
-- Implementing user approval/ask flow.
-- Making feature object existence imply enabled.
-- Adding a plugin system beyond existing feature registry.
-- Changing the semantics of individual Ticket/Pod tools beyond whether they are registered.
-
-## 受け入れ条件
-
-- Lua Profiles can explicitly set `feature.<name>.enabled` for the six initial feature groups.
-- Resolved Manifest has concrete feature enablement values.
-- Disabled features do not register their tools and therefore do not appear in tool schemas or greetings.
-- Project role profiles set explicit feature defaults.
-- Coder profile does not expose Ticket management, Ticket orchestration, Task, or Pod orchestration tools by default.
-- Orchestrator profile exposes Ticket lifecycle, Ticket orchestration, and Pod orchestration tools as intended.
-- Web tools are omitted when `feature.web.enabled=false` and still fail closed when enabled but provider config is insufficient.
-- Tests cover tool definition lists for at least Orchestrator, Coder, Intake, Reviewer, and Companion profiles.
-- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-082209-001/thread.md

@@ -1,51 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:22:09Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T10:20:48Z -->
-
-## Intake summary
-
-既存 Ticket を再読し、duplicate/related work を確認した。これは既存の `pod::feature` registry、Task built-in feature、Ticket built-in feature、Ticket orchestration tools を前提に、Lua Profile / resolved Manifest から feature 単位で LLM tool surface を登録抑制する concrete implementation work item であり、新規 duplicate Ticket は不要。意図、対象 feature groups、core tools の非対象化、disabled feature は permission deny ではなく schema から消す方針、role default、受け入れ条件、検証が十分明確。blocking open question はなし。主な risk/reviewer focus は `profile/manifest`, `feature-boundary`, `authority-boundary`, `tool-schema`, `prompt-guidance`, `web-config-fail-closed`。`feature.ticket.access` / `feature.memory.access` の粒度は、既存 `TicketFeatureAccess` を再利用・拡張する範囲で実装中判断可能だが、silent broad grant になる場合は escalate する。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T10:20:48Z from: planning to: ready reason: planning_ready field: state -->
-
-## State changed
-
-Intake が既存 Ticket の要件を確認し、Orchestrator が routing できる状態と判断したため planning から ready に遷移します。実装はまだ開始しません。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:31:11Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:35:08Z -->
-
-## Decision
-
-Routing decision: waiting_for_core_tool_surface_stability
-
-This Ticket remains queued for now, despite the updated parallelism preference.
-
-Reason:
-- This Ticket changes Profile/Manifest feature flags and conditional tool registration across Task/Ticket/Ticket orchestration/Pod/Memory/Web tool surfaces.
-- `20260609-093050-001` is still under review and changes the core Tool execution API.
-- Running both together would overlap deeply in ToolRegistry/tool surface registration and test expectations, not just create a small mechanical conflict.
-
-State decision:
-- Leave this Ticket `queued`.
-- Re-read after ToolExecutionContext lands and active tool-surface branches settle.
-
----

.yoi/tickets/20260609-084725-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-084725-001","kind":"waiting_capacity_note","note":"Defer this TUI panel/composer UX work while the core ToolExecutionContext API migration is active. It can be routed after the tool API work lands or if explicitly prioritized; this avoids parallel broad changes across tool/runtime and TUI surfaces.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

.yoi/tickets/20260609-084725-001/item.md

@@ -1,85 +0,0 @@
----
-title: 'Improve workspace panel display and composer key handling'
-state: 'inprogress'
-created_at: '2026-06-09T08:47:25Z'
-updated_at: '2026-06-09T10:21:06Z'
-assignee: null
-readiness: 'implementation_ready'
-risk_flags: ['tui-input', 'ux-consistency']
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:01:08Z'
----
-
-## Background
-
-`yoi panel` のトップ行と actionbar に `Ctrl+T` の操作ヒントが表示されているが、Panel 表示として目立たせる必要が薄く、情報密度も上げている。
-
-また、Panel composer の入力操作が通常のチャット UI / event view TUI composer と一部異なっている。観測された例として、`Ctrl+Left` / `Ctrl+Right` による単語単位カーソル移動が Panel composer では効かない。現在は `InputBuffer` など低レベルの composer 実装は共有されている一方、key handling dispatcher は通常チャット UI と Panel で分かれており、Panel 側が composer editing keymap を十分に共有していない。
-
-Panel は workspace / Ticket 操作の入口である一方、composer は通常の TUI 入力欄として期待されるため、表示と操作の両方を整理する。
-
-## Requirements
-
-- Panel のトップ行から `Ctrl+T` 表示を削除する。
-- Panel の actionbar / help text から `Ctrl+T` 表示を削除する。
-- Panel の target switching 操作を `Ctrl+T` から `Tab` に変更する。
-- `Tab` の優先順位は composer completion がある場合は completion を優先し、completion がない Panel 状態では target switching として扱う。
-- Panel composer の編集操作は、通常チャット UI composer と可能な限り互換にする。
-- Panel 側で composer 操作を再実装して乖離を増やすのではなく、既存 composer 入力処理・keymap・action model を共有または抽象化し、互換性を維持しやすい構造にする。
-- bare letter shortcuts を復活させない。通常の文字入力は composer text として扱う既存方針を維持する。
-
-## Acceptance criteria
-
-- `yoi panel` のトップ行に `Ctrl+T` が表示されない。
-- Panel の actionbar / help text に `Ctrl+T` が表示されない。
-- Panel で `Tab` により target switching ができる。
-- Panel に completion popup / completion state がある場合、`Tab` は target switching より completion 操作を優先する。
-- Panel composer で、通常チャット UI composer と同等の主要編集操作が動作する。
-  - 例: 左右移動、行頭/行末移動、削除、履歴操作、`Ctrl+Left` / `Ctrl+Right` 等の単語単位移動。
-- terminal / backend が特定 key sequence を送らない場合は、その制約を壊れた実装と誤認しない範囲で扱う。
-- Panel 専用の ad-hoc composer key handling が増えず、通常 composer との互換性を保ちやすい実装になっている。
-- `nix build .#yoi` が通る。
-
-## Binding decisions / invariants
-
-- `Ctrl+T` を Panel の表示要素や target switching 操作として使わない。
-- Panel の target switching shortcut は `Tab` とする。
-- `Tab` は completion が active な場合、target switching ではなく completion 操作を優先する。
-- Composer に入力可能な通常文字キーを Panel 操作用 shortcut として奪わない。
-- bare `j` / `k` / `o` / `r` のような bare letter shortcuts は復活させない。
-- Panel composer は通常チャット UI composer と別物として再実装しない。既存 composer 操作との互換性を保つ方向で実装する。
-
-## Implementation latitude
-
-- composer 操作の共有方法は実装者が選んでよい。
-  - 例: composer input handling の共通関数化。
-  - 例: key event normalization の共有。
-  - 例: Panel 側を既存 composer action model に寄せる。
-- Panel 固有操作は、共通 composer editing layer の上に別レイヤーとして載せてよい。
-- トップ行は `Ctrl+T` 削除に加えて、workspace / Ticket / role Pod 状態の表示を整理してよい。ただしこの Ticket の主目的は大規模な Panel redesign ではない。
-
-## Readiness
-
-- readiness: implementation_ready
-- risk_flags: [tui-input, ux-consistency]
-
-## Escalation conditions
-
-- `Tab` が terminal focus、既存 TUI 操作、accessibility 上の期待、または将来の Panel completion と衝突する場合は、completion 優先の方針を保ったうえで相談する。
-- 通常チャット UI composer 側にも同じ操作欠落がある場合は、Panel 固有修正ではなく composer 共通改善として扱う。
-- key event が terminal / crossterm 側で区別できない場合は、可能な範囲と制約を implementation report に明記する。
-
-## Validation
-
-- `yoi panel` を起動し、トップ行と actionbar に `Ctrl+T` が出ないことを確認する。
-- `Tab` で Panel target switching ができることを確認する。
-- completion が active な状態を実装が持つ場合、`Tab` が completion を優先することを確認する。
-- Panel composer で通常チャット UI composer と同等の主要 key 操作を手動確認する。
-- `nix build .#yoi` を実行する。
-
-## Related work
-
-- `20260606-060548-001` Workspace panel layout and display tuning
-- `20260607-213808-001` Remove bare letter shortcuts from workspace panel
-- `20260607-001651-002` Workspace panel Companion interface
-- `20260601-021104-001` TUI: persist composer input recall history per workspace

.yoi/tickets/20260609-084725-001/thread.md

@@ -1,253 +0,0 @@
-<!-- event: create author: intake at: 2026-06-09T08:47:25Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T08:47:33Z -->
-
-## Intake summary
-
-Panel 表示・操作改善 Ticket を作成した。`Ctrl+T` はトップ行/actionbar/help text から削除し、target switching は `Tab` に変更する。`Tab` は completion が active な場合 completion を優先し、completion がない Panel 状態では target switching として扱う。Panel composer は通常チャット UI composer と低レベル `InputBuffer` は共有しているが key handling が分岐しているため、Panel 専用の ad-hoc 実装を増やさず、composer editing keymap/action model を共有または抽象化して互換性を維持する。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T08:47:33Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-要件・binding decisions・受け入れ条件が揃ったため、Orchestrator が routing できる ready 状態にする。
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T08:54:26Z -->
-
-## Decision
-
-## Refinement: composer status line and mixed operation model
-
-User clarified an additional UX issue in the Panel composer area:
-
-- The line above the composer currently showing text like `composer Companion · ticket ready · Edit` is redundant and does not make the available action clear.
-- Panel currently mixes two interaction models in the same visual/control area:
-  - when the composer is empty, row selection with Up/Down plus Enter dispatches the selected Ticket action/open behavior;
-  - when the composer has text, Enter sends the text to the selected composer target, either Companion or new Ticket Intake.
-- The implementation should make this separation visible and understandable instead of presenting row action state and composer target/edit state as one ambiguous status line.
-
-Additional requirements:
-
-- Rework the composer-adjacent status line so it does not redundantly restate `composer`, target name, Ticket state, and `Edit` without explaining the action.
-- Clearly distinguish selected-row action context from text-composer target context.
-- The UI should make the empty-composer Enter behavior and non-empty-composer Enter behavior understandable at a glance.
-- If the implementation keeps both behaviors, the display should communicate the mode/priority without making it look like the selected Ticket is the composer destination.
-- If the implementation introduces a more explicit focus/mode model, it must preserve the binding decisions already recorded: no bare letter shortcuts, `Tab` target switching with completion priority, and shared composer key handling with the normal chat UI.
-
-Reviewer focus:
-
-- Verify that the final Panel display does not conflate selected Ticket actions with Companion/Intake text submission.
-- Verify that the composer status/help text answers “what will Enter do now?” rather than only listing internal state labels.
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T08:59:44Z -->
-
-## Decision
-
-## Refinement: selected Ticket while composer has text
-
-Clarified current behavior and resulting UX invariant:
-
-- In the current Panel implementation, a selected Ticket only drives `Enter` actions when the composer is blank.
-- If the composer has text and the target is `Companion`, `Enter` sends the text to the workspace Companion; the selected Ticket is not used as the message destination or action target.
-- If the composer has text and the target is `TicketIntake`, `Enter` launches a new pre-ticket Intake from the typed text; the selected Ticket is not used. Existing-Ticket Intake for a selected `Clarify` action is currently reached only from the blank-composer selected-row action path.
-- Therefore, “composer has text while a Ticket row is selected” currently has no actionable selected-Ticket semantics. The selected row may still be visible/navigation state, but it should not be displayed as if the typed text will act on that Ticket.
-
-Additional requirement:
-
-- The Panel display should avoid suggesting that typed composer text is scoped to or sent to the selected Ticket unless the implementation explicitly adds such a feature.
-- If text composer mode is active, selected-row Ticket action hints should be de-emphasized, hidden, or explicitly separated from the composer destination/action.
-- If the future design wants typed text to refine a selected Ticket, that must be an explicit product decision and not implied by the current mixed UI.
-
----
-
-<!-- event: comment author: intake at: 2026-06-09T09:35:47Z -->
-
-## Comment
-
-## UX exploration note: contextual input instead of always-visible ambiguous composer
-
-User raised a broader display/operation concern:
-
-- The always-visible bottom composer may be intrinsically ambiguous in the Panel because it is not obvious what the box is for at any moment.
-- The current UI mixes selected-list-item actions with global text submission. Even if labels are improved, a fixed bottom box can still look like it applies to the selected Ticket/Pod when it may actually send to Companion or launch new Intake.
-- A potentially clearer direction is to show an input box contextually for the selected list item/action, rather than keeping one always-visible global box whose meaning changes.
-
-Potential design direction for implementation consideration:
-
-- Default Panel state emphasizes list navigation and selected-row actions; no ambiguous always-active global input is required.
-- Immediate row actions can remain `Enter`-driven when no text is needed.
-- Actions that need text open a contextual input box attached to, or clearly associated with, the selected row/action.
-- Global text destinations such as workspace Companion or new Ticket Intake should be explicit actions/targets, not visually conflated with the selected Ticket action state.
-- If a persistent bottom input remains, it should have one unambiguous purpose, such as “Ask Companion”, and selected Ticket action hints should be visually separate from it.
-
-This is not yet a final binding redesign decision. Treat it as reviewer/orchestrator context for the same Ticket: the implementation should prioritize making the input box’s scope and destination obvious, and should avoid relying only on denser status labels to explain a mixed interaction model.
-
----
-
-<!-- event: plan author: intake at: 2026-06-09T09:46:50Z -->
-
-## Plan
-
-## Refinement: explicit focus model for row actions vs global composer
-
-User clarified a more concrete interaction model to reduce the ambiguity between selected list actions and global text submission.
-
-Desired direction:
-
-- The Panel should distinguish at least two visible interaction states:
-  - row/list focus: the user is hovering/selecting a Ticket/Pod/list item and can inspect or choose actions for that item;
-  - global composer focus/no selection: the bottom composer is used to send text to a global target such as Companion or new Ticket Intake.
-- `Esc` should be able to clear the current row/item selection or action focus and return to the global composer/no-selection state.
-- When selection is cleared, the bottom composer can be used for Companion or new Intake target submission without implying that text applies to a selected Ticket.
-- For a selected Ticket/list item, Left/Right should navigate into or out of the item’s available actions.
-- Pressing Right while hovering a Ticket should expand or focus the available actions for that item.
-- The action-focused display should make available actions selectable, such as text-related actions, `Queue`, or other valid item actions.
-- Up/Down should continue to navigate list items in list focus; when action focus is active, implementation may define whether Up/Down changes focused action or returns to item navigation, but the resulting behavior must be visible and predictable.
-- Text submission for a selected item should be explicit through an item/action-focused UI. Typed text in the global bottom composer should not silently apply to a selected Ticket.
-
-Implications / reviewer focus:
-
-- Avoid a mixed state where a Ticket is visually selected, a bottom composer has text, and the UI does not clearly say whether Enter affects the selected Ticket or the global target.
-- The display should make focus explicit: selected item, selected item action, or global composer target.
-- `Esc` behavior must be specified carefully because current Panel uses `Esc` as quit. A reasonable implementation may make `Esc` clear action/list focus first and reserve quit for `Ctrl+C`/`Ctrl+D`, or quit only when already in no-selection/global state, but the chosen behavior must be clear and tested.
-- `Tab` remains the target-switching key for global composer targets, with completion priority if completion is active.
-- Bare letter shortcuts must not be reintroduced.
-
-This refinement supersedes the earlier weaker idea of only improving labels around an always-visible ambiguous composer. The preferred UX direction is an explicit focus/action model: list hover -> Right opens item actions -> choose action; Esc backs out to global composer/no-selection; global composer sends only to explicit global target.
-
----
-
-<!-- event: decision author: intake at: 2026-06-09T09:50:15Z -->
-
-## Decision
-
-## Decision: Panel quit key and Esc focus behavior
-
-User decided that Panel quit should be available through `Ctrl+C`.
-
-Binding decision update:
-
-- `Ctrl+C` is the Panel quit key.
-- `Esc` should not be the primary quit action in the redesigned Panel interaction model.
-- `Esc` should be available for backing out of UI focus states, such as item action focus or selected-row focus, toward the no-selection / global composer state.
-- If the implementation preserves any `Esc` quit behavior for compatibility, it must not conflict with the new focus-clear/back-out behavior and must be clearly justified in the implementation report.
-
-Reviewer focus:
-
-- Verify that `Esc` does not unexpectedly exit the Panel when the user is trying to leave item/action focus.
-- Verify that `Ctrl+C` exits reliably from the redesigned Panel states.
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:01:08Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
-
-## Decision
-
-Routing decision: waiting_capacity_parallelism
-
-This Ticket remains queued for now.
-
-Reason:
-- `20260609-093050-001` is being accepted as the active core tool execution API migration.
-- This Ticket is TUI panel/composer UX work and is implementation-ready, but it is better sequenced after the core tool API migration to keep review/validation focused and avoid broad parallel changes.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- Re-read this Ticket after the ToolExecutionContext API migration lands, or earlier if explicitly prioritized.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T10:19:34Z from: queued to: inprogress reason: orchestrator_acceptance_parallel_capacity field: state -->
-
-## State changed
-
-Accepted queued implementation under the updated parallel-capacity policy. This Ticket is TUI panel/composer UX work and is independent from the active ToolExecutionContext migration except for normal workspace validation. It can run in a separate worktree with separate write scope.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:19:34Z -->
-
-## Decision
-
-Routing decision: implementation_ready_parallel
-
-Updated user instruction: prefer parallel work when Tickets are independent or expected conflicts are small/manageable.
-
-Reason:
-- This Ticket is focused on TUI panel display/composer key handling.
-- It is independent from the active ToolExecutionContext API migration and the TicketList output work, aside from normal shared validation.
-- It can run in a separate worktree with a separate Coder scope.
-
-IntentPacket:
-
-Intent:
-- Improve Panel display and composer key handling so global composer text entry, selected-row actions, target switching, and focus states are explicit and less ambiguous.
-
-Binding decisions / invariants:
-- Remove `Ctrl+T` from Panel top line/actionbar/help and stop using it for Panel target switching.
-- Use `Tab` for Panel target switching, but completion state has priority when active.
-- Preserve no bare-letter shortcuts; normal typed letters go to composer text.
-- Share or abstract composer editing/key handling rather than adding ad-hoc Panel-only editing behavior.
-- Support normal composer editing operations including cursor movement, line start/end, deletion, history, and `Ctrl+Left` / `Ctrl+Right` where terminal events make that possible.
-- Make focus/model explicit: selected row, item action focus, or global composer target.
-- Global composer text must not imply it applies to a selected Ticket unless such a feature is explicitly added.
-- `Esc` backs out of action/list focus toward global composer/no-selection; `Ctrl+C` is the reliable quit key.
-
-Reviewer focus:
-- Verify the UI answers “what will Enter do now?” in selected-row/action/global-composer states.
-- Verify target switching/completion `Tab` priority.
-- Verify composer key handling is shared/compatible with normal TUI where practical.
-- Verify no bare-letter shortcuts are reintroduced.
-
-Validation:
-- Focused TUI/panel key handling/display tests where feasible.
-- Manual or test evidence for top/actionbar `Ctrl+T` removal and `Tab` target switch.
-- `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:21:06Z -->
-
-## Implementation report
-
-Implementation routing started in parallel with the active ToolExecutionContext and TicketList work.
-
-Worktree/branch:
-- Worktree: `.worktree/panel-display-composer-keys`
-- Branch: `panel-display-composer-keys`
-- Base/routing commit: `d95b3ff ticket: route parallel ticketlist and panel work`
-
-Spawned sibling Coder Pod:
-- `coder-panel-display-composer-keys`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Parallel-routing rationale:
-- User asked to prefer parallel work when conflicts are absent or expected small.
-- This Ticket is primarily TUI panel/composer UX and is independent from the core ToolExecutionContext migration and TicketList output shaping.
-- Coder was instructed to avoid Ticket backend/tool output changes unless necessary.
-
----

.yoi/tickets/20260609-085148-001/item.md

@@ -1,78 +0,0 @@
----
-title: 'session analyticsにresponse単位のbatching指標を追加する'
-state: 'inprogress'
-created_at: '2026-06-09T08:51:48Z'
-updated_at: '2026-06-09T10:36:44Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:31:14Z'
----
-
-## 背景
-
-`session-analytics-tooling` を実際の Coder / Reviewer セッションに適用したところ、tool call の総数だけではなく、assistant response 単位の batching が重要だと分かった。
-
-観測例:
-
-- Coder session では `avg tools / tool response = 1.16`、`p90 = 1` で、ほぼ 1 response = 1 tool call だった。
-- `Edit` は 40 responses すべてが `1 response = 1 Edit` だった。
-- 同じ response 内で同一ファイルに複数 `Edit` している例はなかった。
-- その一方で、同じファイルへの edit-only response が 2〜4 回連続している箇所があり、round-trip latency の観点では batching opportunity の可能性がある。
-- Reviewer session では編集はないが、tool calls per response は同様に低く、探索時に Read/Grep/Bash の result size と response batching を見る価値がある。
-
-Edit batching 自体の是非は追加調査するが、analytics 側には response 単位の指標が必要。
-
-## ゴール
-
-`session-analytics` に assistant response 単位の tool batching / edit round-trip 指標を追加し、tool call の使い方を速度面から評価できるようにする。
-
-## 要件
-
-- Session JSONL から assistant response / tool result cycle 単位を推定する。
-  - 1 assistant response に含まれる tool call 群を集計する。
-  - user turn 単位とは別に response 単位の metrics を持つ。
-- Tool calls per response を集計する。
-  - total responses
-  - tool-call responses
-  - total tool calls
-  - avg / p50 / p90 / max
-  - histogram
-  - top responses by tool call count
-- Edit batching metrics を追加する。
-  - Edit calls per response
-  - responses containing Edit
-  - same-file multiple Edit calls in one response
-  - files touched per edit response
-  - large edit arguments との相関が取れる形にする。
-- Consecutive edit round-trip metrics を追加する。
-  - 同一ファイルに対する連続 edit-only responses を検出する。
-  - streak length / file path / response range / line range を報告する。
-  - 間に Read/Bash/test/tool result dependent step がある場合と、pure edit-only streak を区別する。
-- Suspicious diagnostics は断定しない。
-  - 連続 Edit が必ず悪いとは言わない。
-  - "possible batching opportunity" として報告する。
-  - Edit の成功/失敗や前回 result を見て次を決める必要がある場合は正当な分割であり得る。
-- JSON report に machine-readable field として追加する。
-- Human summary mode がある場合は、top-N の batching observations を表示する。
-  - まだ human summary が無い場合は、少なくとも JSON schema に追加し、後続で CLI summary に出せるようにする。
-
-## 非目標
-
-- この Ticket で prompt / workflow を変更して batching を強制すること。
-- 複数 Edit を同一 response に並べる方針を決めること。
-- ordered patch / EditBatch tool を実装すること。
-- Edit が小さいこと自体を悪いと判定すること。
-
-## 受け入れ条件
-
-- `session-analytics` report に response-level tool batching metrics が含まれる。
-- Coder session のような `1 response = 1 Edit` 傾向を数値で確認できる。
-- 同一ファイルへの consecutive edit-only response streak を検出できる。
-- Same-response same-file multiple Edit がある場合に検出できる。
-- Tests cover:
-  - single response with multiple tools;
-  - single response with multiple same-file edits;
-  - consecutive edit-only responses to the same file;
-  - interleaved Read/test step that breaks or annotates a streak;
-  - sessions with no edits.
-- `cargo fmt --check`, focused tests, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-085148-001/thread.md

@@ -1,96 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:51:48Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T10:20:52Z -->
-
-## Intake summary
-
-既存 Ticket は、closed 済みの `20260609-032533-001` で追加された `session-analytics` 基盤への concrete follow-up として十分に具体化済み。目的は assistant response 単位の tool batching / edit round-trip 指標を JSON report に追加することで、実装対象 metrics、断定しない diagnostics 方針、非目標、受け入れ条件、テスト観点が明記されている。未決定の product/API/authority boundary はなく、Orchestrator は implementation_ready として routing できる。Reviewer focus は、response/tool-result cycle 推定の妥当性、raw content を出さない既存 analytics privacy boundary の維持、consecutive edit-only streak の過剰断定回避、既存 CLI/JSON schema との整合性。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T10:20:52Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake で既存 Ticket の本文・thread・artifacts と関連する closed Ticket `20260609-032533-001` を確認した。要件は実装・レビュー・検証できる粒度まで整理済みであり、planning から ready にする。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:31:14Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T10:35:08Z from: queued to: inprogress reason: orchestrator_acceptance_parallel_capacity field: state -->
-
-## State changed
-
-Accepted queued implementation under the updated parallel-capacity policy. This Ticket extends the already-landed session analytics crate and is independent from the active ToolExecutionContext, TicketList, and Panel worktrees.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:35:08Z -->
-
-## Decision
-
-Routing decision: implementation_ready_parallel
-
-Reason:
-- This Ticket extends `session-analytics`, a recently landed and currently inactive area.
-- It is independent from active ToolExecutionContext, TicketList output, and Panel UX work.
-- User asked to prefer parallel work when conflicts are absent or expected small.
-
-IntentPacket:
-
-Intent:
-- Add assistant-response-level tool batching and edit round-trip metrics to `session-analytics` so tool-use speed patterns can be evaluated in structured JSON.
-
-Binding decisions / invariants:
-- Infer assistant response / tool-result cycle units from session JSONL as best-effort analytics.
-- Add response-level tool call metrics: total responses, tool-call responses, total tool calls, avg/p50/p90/max, histogram, top responses by tool call count.
-- Add edit batching metrics: Edit calls per response, responses containing Edit, same-file multiple Edit calls in one response, files touched per edit response, and correlation with large edit args where possible.
-- Add consecutive edit-only response streak metrics by file/path and response range, distinguishing pure edit-only streaks from sequences broken/annotated by Read/Bash/test/result-dependent steps.
-- Diagnostics must be observations such as possible batching opportunity, not blame or policy enforcement.
-- Preserve existing privacy boundary: no raw user input, raw tool args, raw file contents, raw session snippets, or raw tool output content in default output.
-- Do not change prompt/workflow behavior, implement EditBatch/ordered patch tools, or force batching policy.
-
-Validation:
-- Tests for single response with multiple tools.
-- Tests for same-response same-file multiple Edit.
-- Tests for consecutive edit-only responses to same file.
-- Tests for interleaved Read/test step breaking or annotating streak.
-- Tests for sessions with no edits.
-- `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:36:44Z -->
-
-## Implementation report
-
-Implementation routing started in parallel with the current active work set.
-
-Worktree/branch:
-- Worktree: `.worktree/session-analytics-response-batching`
-- Branch: `session-analytics-response-batching`
-- Base/routing commit: `5d9e227 ticket: route analytics batching and parallel guidance`
-
-Spawned sibling Coder Pod:
-- `coder-session-analytics-response-batching`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Parallel-routing rationale:
-- This extends the isolated `session-analytics` crate/CLI surface and is independent from active ToolExecutionContext/TicketList/Panel work.
-- Coder was instructed to use synthetic fixtures and preserve the privacy boundary.
-
----

.yoi/tickets/20260609-085212-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-085212-001","kind":"after","related_ticket":"20260609-093050-001","note":"Wait for the ToolExecutionContext API migration before changing TicketList output/tool behavior so the TicketList implementation targets the stable tool execution context interface.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

.yoi/tickets/20260609-085212-001/artifacts/relations.json

@@ -1,13 +0,0 @@
-{
-  "version": 1,
-  "relations": [
-    {
-      "ticket_id": "20260609-085212-001",
-      "kind": "related",
-      "target": "20260609-073047-001",
-      "note": "非ブロッキング関連。ID 形式変更は TicketList の ID 表示長や tests に影響し得るが、本 Ticket は canonical id を不透明文字列として扱うため先後関係は不要。",
-      "author": "intake",
-      "at": "2026-06-09T09:55:43Z"
-    }
-  ]
-}

.yoi/tickets/20260609-085212-001/item.md

@@ -1,72 +0,0 @@
----
-title: 'TicketListの出力を軽量化する'
-state: 'inprogress'
-created_at: '2026-06-09T08:52:12Z'
-updated_at: '2026-06-09T10:21:06Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:01:28Z'
----
-
-## 背景
-
-実セッションを `session analyze` で確認したところ、Orchestrator / Companion 系のセッションで `TicketList` の tool result が大きくなりやすいことが分かった。
-
-観測例:
-
-- `TicketList` result が 20KB〜65KB 程度になるケースがある。
-- 一覧系 tool は頻繁に使われるため、1回の大きな summary が history/context を圧迫しやすい。
-- Coder / Reviewer では `TicketList` は主因ではなかったが、Orchestrator / Companion では Ticket 一覧が routing / cleanup / backlog 判断の起点になりやすい。
-
-TicketList は人間/AI の探索入口として必要だが、default output はもっと bounded にしてよい。
-
-## ゴール
-
-`TicketList` の default output を減量し、必要十分な bounded summary にする。詳細は `TicketShow` に委ねる。
-
-## 要件
-
-- `TicketList` default output の情報量を再設計する。
-- default では item body / thread / artifacts の詳細を含めない。
-- 1 Ticket あたりの summary を短くする。
-  - canonical id
-  - title
-  - state
-  - priority 相当が残る場合のみ
-  - updated_at または queued_at など、必要な最小 timestamp
-  - attention/blocking hint がある場合の短い indicator
-- title や diagnostics が長い場合は bounded に切り詰める。
-- `limit` の default / max を見直す。
-  - default は current UI/LLM usage に適した小さい値にする。
-  - max も context blow-up を起こしにくい上限にする。
-- `state=all` / closed を含む一覧は特に慎重に制限する。
-- 必要なら detail-heavy mode を明示 opt-in にする。
-  - 例: `--verbose` / `--json-full` / separate command。
-  - ただし default tool result は軽量に保つ。
-- Tool output と CLI human output の両方を確認する。
-  - LLM-facing TicketList tool は特に bounded であるべき。
-  - CLI は人間可読性を保ちつつ、巨大 JSON/Markdown を default で出さない。
-- Orchestrator が詳細判断する場合は `TicketShow <id>` を読む前提にする。
-  - List は selection / triage / backlog overview 用。
-  - routing / close / planning return / implementation acceptance の authority にはしない。
-
-## 非目標
-
-- TicketShow の詳細を削ること。
-- Ticket backend schema を変更すること。
-- Ticket relation / Objective / OrchestrationPlan の設計を変えること。
-- List だけで Orchestrator が routing 判断できるようにすること。
-
-## 受け入れ条件
-
-- `TicketList` default result が現在より明確に小さい bounded summary になる。
-- Large open/all Ticket set でも tool result が context を過度に圧迫しない。
-- `TicketList` は detail authority ではなく selection/overview 用であることが docs/tool description/workflow guidance から分かる。
-- `TicketShow` は詳細確認の authority として引き続き使える。
-- Tests cover:
-  - long title truncation;
-  - large list limit behavior;
-  - all/closed state listing cap;
-  - JSON/tool output shape;
-  - no body/thread leakage in list output.
-- `target/debug/yoi ticket doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.

.yoi/tickets/20260609-085212-001/thread.md

@@ -1,173 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:52:12Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: plan author: intake at: 2026-06-09T09:55:30Z -->
-
-## Plan
-
-## Intake refinement
-
-readiness は `implementation_ready`。目的、対象 surface、非目標、受け入れ条件、検証観点がすでに具体的で、Orchestrator が routing できる。
-
-### Binding decisions / invariants
-
-- `TicketList` は selection / triage / backlog overview 用の bounded summary として扱い、routing / close / planning return / implementation acceptance の authority にはしない。
-- 詳細判断の authority は `TicketShow <id>` の body/thread/artifacts とする。
-- LLM-facing `TicketList` tool の default result は軽量・bounded にし、item body / thread / artifacts の詳細を漏らさない。
-- CLI human output も default では巨大な JSON/Markdown を出さず、人間可読性と context safety を両立する。
-- `state=all` や closed を含む一覧は特に context blow-up を起こしにくい default/max limit を持つ。
-- long title / diagnostics / attention hint は bounded に切り詰める。
-- Ticket backend schema、TicketShow の詳細性、Ticket relation / Objective / OrchestrationPlan の設計はこの Ticket の範囲外。
-
-### Implementation latitude
-
-- 1 Ticket あたりの summary field、timestamp の選択、title truncation 長、default/max limit の具体値は実装者が current UI/LLM usage を見て決めてよい。
-- detail-heavy mode は必要がある場合だけ明示 opt-in として追加してよいが、default tool result は軽量に保つ。
-- CLI と tool output は同じ内部 summary model を共有してもよいし、human readability のために表示整形だけ分けてもよい。
-- Docs/tool description/workflow guidance の更新範囲は、`TicketList` を selection/overview 用、`TicketShow` を詳細 authority と明示するために必要な範囲に限定してよい。
-
-### Escalation conditions
-
-- Orchestrator が `TicketList` だけで routing authority を持つ設計に変える必要が出た場合。
-- Summary を削ることで panel / CLI / role workflow の既存の必須操作が成立しなくなる場合。
-- Detail-heavy mode 追加が新しい public API / plugin / capability boundary の判断を要する場合。
-- `limit` / truncation の方針が Ticket identity/base32 migration Ticket と衝突し、先後関係の判断が必要になった場合。
-
-### Validation focus
-
-- long title truncation。
-- large list の default/max limit behavior。
-- `state=all` / closed を含む listing cap。
-- JSON/tool output shape が bounded summary であること。
-- `TicketList` output に body/thread/artifacts の本文が漏れないこと。
-- CLI list output が default で巨大化しないこと。
-- `target/debug/yoi ticket doctor`、focused tests、`cargo fmt --check`、`git diff --check`。コード・resource 変更が入るため完了前に `nix build .#yoi` も確認する。
-
-Open questions: なし。
-Risk flags: `tool-output`, `context-budget`, `cli-ux`, `ticket-tools`, `docs-workflows`。
-Related work: `20260609-073047-001` は Ticket/Objective ID 形式変更で非ブロッキング関連。ID 長や表示が変わっても、本 Ticket の summary/truncation 方針は canonical ID を不透明文字列として扱えば成立する。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T09:55:37Z -->
-
-## Intake summary
-
-TicketList の default output を LLM/context に安全な bounded summary へ軽量化する concrete work item として整理済み。詳細 authority は TicketShow に残し、List は selection/overview 用とする。Open questions はなく、risk flags は tool-output / context-budget / cli-ux / ticket-tools / docs-workflows。関連する ID 形式変更 Ticket は非ブロッキングで、canonical id は不透明文字列として扱う。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T09:55:37Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake refinement により、目的・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions・validation focus が揃ったため、Orchestrator が routing できる ready に移行する。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:01:28Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
-
-## Decision
-
-Routing decision: waiting_for_tool_execution_context
-
-This Ticket remains queued for now.
-
-Reason:
-- `20260609-093050-001` (`Tool実行にToolExecutionContextを渡す`) changes the core tool execution API.
-- This Ticket changes `TicketList`, which is an LLM tool surface and should target the stable post-migration execution context API.
-- Running both in parallel would create avoidable conflicts across tool schema/execution code.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- Complete and merge `20260609-093050-001` first.
-- Re-read this Ticket and accept from queued if still unblocked.
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T10:19:34Z from: queued to: inprogress reason: orchestrator_acceptance_parallel_capacity field: state -->
-
-## State changed
-
-Accepted queued implementation under the updated parallel-capacity policy. The active ToolExecutionContext branch changes core Tool execution plumbing, while this Ticket changes the bounded TicketList output surface. There may be a small mechanical conflict around the TicketList tool implementation, but it is expected to be localized and manageable, so parallel work is preferred.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:19:34Z -->
-
-## Decision
-
-Routing decision: implementation_ready_parallel
-
-Updated user instruction: prefer parallel work when Tickets are independent or expected conflicts are small/manageable.
-
-Reason:
-- This Ticket changes `TicketList` output/tool/CLI/workflow guidance.
-- `20260609-093050-001` changes the core Tool execution context API. The overlap is expected to be a localized mechanical merge in tool execution signatures / TicketList implementation, not a design conflict.
-- Running this in parallel should improve throughput while preserving separate worktrees and explicit review.
-
-IntentPacket:
-
-Intent:
-- Make `TicketList` a lightweight bounded overview/selection surface and keep detailed authority in `TicketShow`.
-
-Binding decisions / invariants:
-- Default `TicketList` output must not include body/thread/artifact details.
-- Per-Ticket summary must be short and bounded: canonical id, title, state, minimal timestamp, and short attention/blocking hints if any.
-- Long titles/diagnostics must be truncated.
-- Default/max limits should be smaller and context-safe, especially for `state=all` / closed-inclusive listing.
-- Tool output is the priority for context safety; CLI should remain human-readable without huge default JSON/Markdown.
-- `TicketList` is not routing/close/implementation authority; Orchestrator must read `TicketShow` for decisions.
-- Do not change Ticket backend schema, TicketShow detail, Ticket relation/Objectives/OrchestrationPlan design.
-
-Reviewer focus:
-- Verify no body/thread/artifact prose leaks into list output.
-- Verify output remains useful for selection and backlog overview.
-- Verify default limits and truncation are bounded and tested.
-- Watch for small merge interactions with the ToolExecutionContext branch; resolve by using the new context API without expanding scope.
-
-Validation:
-- Focused tests for long-title truncation, large-list limits, all/closed cap, JSON/tool output shape, no body/thread leakage.
-- CLI list output tests.
-- `cargo fmt --check`, `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `cargo check --workspace`, `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:21:06Z -->
-
-## Implementation report
-
-Implementation routing started in parallel with the active ToolExecutionContext migration.
-
-Worktree/branch:
-- Worktree: `.worktree/ticketlist-output-lightweight`
-- Branch: `ticketlist-output-lightweight`
-- Base/routing commit: `d95b3ff ticket: route parallel ticketlist and panel work`
-
-Spawned sibling Coder Pod:
-- `coder-ticketlist-output-lightweight`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Parallel-routing rationale:
-- User asked to prefer parallel work when conflicts are absent or expected small.
-- Overlap with ToolExecutionContext should be localized/mechanical around tool execution signatures and TicketList implementation.
-- Any non-mechanical design conflict should be escalated rather than broadened.
-
----

.yoi/tickets/20260609-093050-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-093050-001","kind":"before","related_ticket":"20260609-085212-001","note":"Run the ToolExecutionContext API migration before slimming TicketList output because TicketList is an LLM tool surface that may need to adopt the new execution context API shape.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

.yoi/tickets/20260609-093050-001/item.md

@@ -1,92 +0,0 @@
----
-title: 'Tool実行にToolExecutionContextを渡す'
-state: 'inprogress'
-created_at: '2026-06-09T09:30:50Z'
-updated_at: '2026-06-09T10:33:45Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:01:00Z'
----
-
-## 背景
-
-LLM-Worker は tool calls を並列実行する前提で作られている。Worker 側に tool/resource scheduling policy を持たせるのではなく、順序性や排他が必要な tool は tool 実装側で待つ設計にしたい。
-
-そのためには tool 実装が、現在の tool call がどの LLM response / tool batch に属し、response 内で何番目の call なのかを知る必要がある。
-
-現状の `Tool::execute(input_json)` には以下の情報が渡らない:
-
-- tool call id;
-- response/tool-batch identity;
-- response 内の tool call order;
-- LLM call / turn に紐づく実行文脈。
-
-Hook / Interceptor ではこの用途をきれいに満たせない。`pre_tool_call` で lock を取ると、全 pre hooks が tool execution 前に走る構造のため deadlock し得る。また guard を tool execution future の lifetime に渡す API もない。
-
-## ゴール
-
-Tool 実行 API に `ToolExecutionContext` を導入し、tool 実装が response-local order / call identity を参照できるようにする。Worker は並列実行を維持し、scheduling policy は持たない。
-
-## 要件
-
-### API 変更
-
-- 既存 API 互換を優先せず、`Tool::execute` を context 付き signature に置き換える。
-- 例:
-
-```rust
-async fn execute(&self, input_json: &str, ctx: ToolExecutionContext) -> Result<ToolOutput, ToolError>;
-```
-
-- `ToolServer::call_tool` / Worker の tool execution path も context を渡す形に更新する。
-- 互換 wrapper や default old-API bridge は原則作らなくてよい。既存 tools を一括更新する。
-
-### ToolExecutionContext
-
-- `ToolExecutionContext` に少なくとも以下を含める:
-  - `call_id`: provider/tool call id;
-  - `batch_id`: 1つの assistant response / tool-call batch を識別する id;
-  - `call_index`: batch 内の tool call order;
-  - 必要なら `llm_call_index` / `turn_index` 相当。ただし first pass では過剰に増やさない。
-- `batch_id` は tool execution batch ごとに stable であればよい。
-  - random UUID でも Worker-local increment でもよい。
-  - session log に出す必要があるかは実装時に判断する。
-- `call_index` は LLM が出した tool call order を反映する。
-- Context は Worker の scheduling 判断に使わない。tool が必要に応じて利用する metadata とする。
-
-### Worker behavior
-
-- Worker はこれまで通り approved tool calls を並列実行する。
-- Worker は per-tool parallel-safe / serial / resource conflict policy を持たない。
-- Worker は各 tool call に context を付与して並列実行するだけ。
-- `pre_tool_call` / `post_tool_call` interceptors の既存意味論は極力維持する。
-  - 必要なら `ToolCallInfo` / `ToolResultInfo` に context 相当の情報を追加する。
-  - ただし lock/permit lifecycle を interceptor に持たせない。
-
-### Tool update
-
-- 既存 built-in tools を新 signature に更新する。
-- 初期段階では多くの tools は context を無視してよい。
-- Context を使う具体的な same-file mutation queue / Edit-Write serialization は別 Ticket で扱う。
-
-## 非目標
-
-- Worker に resource scheduling policy を実装すること。
-- `Edit` / `Write` の same-file mutex をこの Ticket で実装すること。
-- `parallel_tool_calls=false` の導入。
-- Hook / Interceptor で lock lifecycle を管理すること。
-- Backward-compatible old Tool API を長期維持すること。
-
-## 受け入れ条件
-
-- `Tool::execute` が `ToolExecutionContext` を受け取る。
-- Worker が 1 assistant response / tool batch ごとに `batch_id` と `call_index` を付与して tools を並列実行する。
-- `call_index` は response 内の tool call order と一致する。
-- 既存 built-in tools が新 API に移行され、context を無視しても動作する。
-- Interceptor / hook の意味論が壊れていない。
-- Tests cover:
-  - multiple tool calls in one response receive same `batch_id` and increasing `call_index`;
-  - separate tool batches receive distinct `batch_id`;
-  - synthetic / skipped / aborted tool calls の context handling が破綻しない;
-  - parallel execution is still used for approved calls.
-- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-093050-001/thread.md

@@ -1,165 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T09:30:50Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T09:55:00Z -->
-
-## Intake summary
-
-既存 Ticket を確認し、同目的の未完了重複は見当たりません。要件は Tool 実行 API に `ToolExecutionContext` を導入し、`call_id` / response-local `batch_id` / `call_index` を Tool 実装へ渡すことです。Worker は従来どおり approved tool calls を並列実行し、resource scheduling policy は持たないこと、old Tool API 互換層を長期維持しないこと、Interceptor / hook に lock lifecycle を持たせないことが binding decision です。実装側には `batch_id` 生成方式や session log への記録有無の裁量があります。関連し得る Ticket として `20260609-085148-001` は response 単位の batching analytics であり、目的が異なるため重複ではありません。リスク/レビュー焦点は public API 変更、Worker tool execution path、Interceptor/hook 意味論、並列実行維持、既存 built-in tools の一括移行です。受け入れ条件と validation が明確なため implementation_ready と判断します。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T09:55:00Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake により要件・非目標・受け入れ条件・レビュー焦点が routing 可能な状態で確認されたため、planning から ready にします。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:01:00Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T10:03:41Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
-
-## State changed
-
-Accepted queued implementation after reading the Ticket and current workspace state. This is a core tool execution API migration and should land before changing individual tool outputs such as TicketList. No active implementation worktree exists, and the workspace record updates were committed before acceptance.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
-
-## Decision
-
-Routing decision: implementation_ready
-
-Evidence checked:
-- Ticket body and Intake summary.
-- Current queued set: `20260609-093050-001`, `20260609-085212-001`, and `20260609-084725-001`.
-- Current workspace/worktree state after committing queued record updates: main workspace clean, no active implementation worktree.
-- Relation/order context: `TicketList` output slimming should wait for this core tool execution API migration.
-
-Reason:
-- The Ticket has clear implementation requirements: introduce `ToolExecutionContext`, pass it through Tool execution, and move context-dependent path/working-directory/backend access out of static Tool definitions where appropriate.
-- It is a lower-level API migration that should land before individual tool output/UX changes.
-- No concrete missing decision remains requiring return to planning.
-
-IntentPacket:
-
-Intent:
-- Pass a `ToolExecutionContext` into Tool execution so tool behavior can depend on runtime context without encoding runtime-dependent data in static tool definitions.
-
-Binding decisions / invariants:
-- Static Tool definitions/schemas remain static and reusable.
-- Runtime-dependent values such as cwd/workspace context/backend handles should flow through execution context where appropriate, not through schema metadata or global mutable state.
-- Existing tool behavior must remain compatible unless a tool explicitly needs the new context.
-- Keep capability/authority checks explicit and typed; do not use `ToolExecutionContext` as an unstructured escape hatch.
-- Do not weaken scope, host-authority, Ticket backend, or web/network safety boundaries.
-- Avoid broad speculative refactors beyond the execution-path migration required for this Ticket.
-- Update built-in tools/tests that need context, especially file/path/Ticket/backend-sensitive surfaces.
-- Preserve LLM-facing tool names and schemas unless a specific schema change is required.
-
-Implementation latitude:
-- Coder may choose exact `ToolExecutionContext` fields and lifetimes if they keep ownership/thread-safety practical and avoid leaking runtime/session-private data into static schemas.
-- Coder may introduce default/empty context helpers for tests and tools that do not need context.
-- If a subset of tools must be migrated first, keep a coherent buildable boundary and report remaining follow-up explicitly.
-
-Escalate if:
-- The change requires redesigning the whole ToolRegistry/plugin system.
-- Context fields would need to carry raw Worker/history/session mutable access.
-- Authority checks cannot remain explicit and typed.
-- Too many unrelated tool schema/output changes become necessary.
-
-Validation:
-- Focused Tool trait/ToolRegistry tests for context passing.
-- Focused tests for context-sensitive built-in tools such as Ticket/backend/path tools if affected.
-- Existing tool schema/name tests.
-- `cargo fmt --check`.
-- `git diff --check`.
-- `cargo run -q -p yoi -- ticket doctor`.
-- `cargo check --workspace`.
-- `nix build .#yoi`.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:05:03Z -->
-
-## Implementation report
-
-Implementation routing started.
-
-Worktree/branch:
-- Worktree: `.worktree/tool-execution-context`
-- Branch: `tool-execution-context`
-- Base/routing commit: `b21fab8 ticket: route tool execution context`
-
-Spawned sibling Coder Pod:
-- `coder-tool-execution-context`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Routing context:
-- This is the active implementation work.
-- `20260609-085212-001` (`TicketListの出力を軽量化する`) is intentionally left queued until this core Tool execution API migration lands.
-- `20260609-084725-001` is also left queued for capacity/sequencing while this core migration is active.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:33:45Z -->
-
-## Implementation report
-
-Coder implementation completed and is ready for sibling review.
-
-Coder Pod:
-- `coder-tool-execution-context`
-- Commit: `d8aed7befe6ff739cbee1b49221d3b8be35a57d7 tool: add execution context`
-- Worktree status before review: clean branch `tool-execution-context`
-- Stopped after collecting output to reclaim delegated worktree scope.
-
-Selected design:
-- Added `llm_worker::tool::ToolExecutionContext` with `call_id`, `batch_id`, and `call_index`.
-- `batch_id` is Worker-local monotonic (`tool-batch-{n}`) and shared across one `execute_and_commit_tools` batch.
-- `call_index` is 0-based order from the LLM-returned tool call array.
-- `call_id` is synchronized to any pre-interceptor-mutated tool call id before execution/post context.
-
-Implementation summary:
-- `Tool::execute` and `ToolServer::call_tool` now receive `ToolExecutionContext`.
-- Worker assigns context while preserving parallel approved tool execution via `join_all`.
-- `ToolCallInfo` / `ToolResultInfo` expose context.
-- skipped / synthetic / post-tool paths have context available.
-- Built-in tools, Ticket tools, Memory tools, Pod tools, test fixtures, and macro-generated Tool implementations were migrated.
-- `llm-worker-macros` excludes `ToolExecutionContext` parameters from JSON schema and supplies them from execution context.
-- Added direct/default context helpers for low-level direct tests; Worker path passes explicit batch context.
-
-Validation reported passed:
-- `cargo test -p llm-worker --test tool_macro_test`
-- `cargo test -p llm-worker --test parallel_execution_test`
-- `cargo test -p llm-worker`
-- `cargo test -p tools -p ticket`
-- `cargo test -p memory`
-- `cargo test -p pod --tests --no-run`
-- `cargo test --workspace --no-run`
-- `cargo fmt --check`
-- `git diff --check`
-- `cargo check --workspace`
-- `cargo run -q -p yoi -- ticket doctor`
-- `nix build .#yoi`
-
-Residual notes:
-- `batch_id` is not globally durable.
-- Resumed pending tool calls receive a fresh execution batch id.
-- No scheduling, serialization, per-resource locks, same-file queueing, or `parallel_tool_calls=false` equivalent was added.
-
----

.yoi/tickets/20260609-095518-001/artifacts/orchestration-plan.jsonl

@@ -1 +0,0 @@
-{"id":"orch-plan-20260609-101207-1","ticket_id":"20260609-095518-001","kind":"waiting_capacity_note","note":"Defer while `20260609-093050-001` ToolExecutionContext API migration is active. This Ticket touches Ticket schema/tool API/panel behavior and should run after the core tool execution API migration lands to avoid overlapping broad tool/Ticket surface changes.","author":"orchestrator","at":"2026-06-09T10:12:07Z"}

.yoi/tickets/20260609-095518-001/item.md

@@ -1,65 +0,0 @@
----
-title: 'action_requiredとattention_requiredをTicket schemaから削除する'
-state: 'queued'
-created_at: '2026-06-09T09:55:18Z'
-updated_at: '2026-06-09T10:19:34Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:11:38Z'
----
-
-## 背景
-
-`action_required` / `attention_required` は Ticket frontmatter overlay として曖昧で、state / relation / body sections / thread event と責務が重複している。
-
-特に `attention_required` は Panel で強い意味を持っており、non-empty の場合は `state: ready` でも Queue できず、blocked/red + `Edit` action になる。実際には「実装時の注意事項」程度の内容が `attention_required` に入ったことで、ready Ticket が誤って Queue 不能になった。
-
-今後は以下の分担に寄せる:
-
-- Queue / routing を止める不足は `state: planning` と typed state/thread reason で表す。
-- dependency / blocker は typed Ticket relation metadata で表す。
-- 実装時の注意、不変条件、相談条件は Ticket body の `Binding decisions / invariants` / `Escalation conditions` に書く。
-- 中長期の判断軸は Objective に置く。
-- 一時 UI notice は Panel/TUI local state に置く。
-
-## ゴール
-
-`action_required` と `attention_required` を current Ticket schema / tool API / Panel action 判定から削除する。
-
-## 要件
-
-- Ticket frontmatter schema から `action_required` と `attention_required` を削除する。
-  - New Ticket はこれらの fields を書かない。
-  - `ticket doctor` はこれらを要求しない。
-  - current records ではこれらの fields が無い状態を正とする。
-- Ticket create / tool input / output から `action_required` / `attention_required` を削除する。
-  - `TicketCreate` params から削除する。
-  - `TicketList` / `TicketShow` の current metadata output から削除する。
-  - 必要なら legacy parser compatibility は短期 migration 用に限定し、current output には出さない。
-- Panel の action 判定から `attention_required` blocker を削除する。
-  - `state: ready` は、unresolved relation blocker など明確な blocker が無ければ Queue 可能にする。
-  - 人間判断が不足している場合は `state: planning` に戻す運用にする。
-- Existing docs / workflows / tests / examples を更新する。
-  - `attention_required` を human-attention overlay として説明している古い記述を削除または置換する。
-  - `action_required` を current Ticket field として扱う記述を削除する。
-- Existing Ticket records から field は削除済みだが、schema 削除後も doctor が通ることを確認する。
-- Historical thread/body mentions は audit/history として残してよい。ただし current docs/examples として使う場合は更新する。
-
-## 非目標
-
-- Typed Ticket relation metadata の実装。
-- Objective の実装。
-- Panel の新しい確認 UX の設計。
-- `state: planning` に戻す policy 全体の再設計。
-
-## 受け入れ条件
-
-- `action_required` / `attention_required` が current Ticket schema から消えている。
-- `TicketCreate` / `TicketList` / `TicketShow` がこれらを current fields として露出しない。
-- Panel は `attention_required` の有無で ready Ticket を blocked/Edit 扱いしない。
-- Queue/routing を止める理由は state / relation / typed thread reason のいずれかで表現される。
-- Tests cover:
-  - ready Ticket without relation blockers derives Queue action;
-  - historical/legacy `attention_required` があっても current behavior を壊さないか、または doctor で明確に診断される;
-  - Ticket create/list/show output に fields が出ない。
-- `target/debug/yoi ticket doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.

.yoi/tickets/20260609-095518-001/thread.md

@@ -1,75 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T09:55:18Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: ticket-intake at: 2026-06-09T10:02:25Z -->
-
-## Intake summary
-
-既存 Ticket を精査し、重複ではなく実装可能な concrete work item と判断した。目的は `action_required` / `attention_required` を current Ticket schema、TicketCreate/TicketList/TicketShow などの tool/API output、Panel action 判定から削除し、routing を止める不足は `state: planning`・typed thread reason・relation metadata に寄せること。非目標は typed relation metadata / Objective / 新しい Panel 確認 UX / planning-return policy 全体の再設計。リスク/レビュー重点は ticket-schema、tool-api、panel-behavior、workflow/docs 更新、legacy/current record compatibility。実装は current output から両 field を消し、ready Ticket の Queue 判定を `attention_required` に依存させず、既存 docs/workflows/tests/examples の current 記述を更新し、historical audit mention は残してよい。検証は Ticket doctor、focused Ticket/Panel/tool output tests、cargo fmt --check、git diff --check、必要に応じて `nix build .#yoi` を含める。関連する既存作業として explicit workflow state 導入 `20260606-215403-001`、YAML frontmatter strict 化 `20260607-223233-001`、Panel close safety `20260608-032200-001`、Ticket state commit policy `20260607-220606-001` を確認済みで、いずれもこの Ticket の duplicate ではない。
-
----
-
-<!-- event: state_changed author: ticket-intake at: 2026-06-09T10:02:25Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake classified this Ticket as ready to queue: the purpose, schema/tool/panel/doc scope, non-goals, acceptance criteria, validation expectations, and migration/compatibility boundary are explicit enough for Orchestrator routing.
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:11:38Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:12:07Z -->
-
-## Decision
-
-Routing decision: waiting_for_active_tool_api_migration
-
-This Ticket is queued and appears implementation-ready, but I am intentionally not accepting it to `inprogress` yet.
-
-Reason:
-- `20260609-093050-001` (`Tool実行にToolExecutionContextを渡す`) is already active, with Coder Pod `coder-tool-execution-context` running in `.worktree/tool-execution-context`.
-- This Ticket touches Ticket schema, Ticket tool API output/input, and Panel action behavior.
-- Running it in parallel with a core Tool execution API migration would create avoidable conflict across tool/Ticket surfaces and make review less reliable.
-
-State decision:
-- Leave this Ticket `queued`.
-- Do not create a worktree or spawn a coder yet.
-
-Next action:
-- Complete and merge `20260609-093050-001` first.
-- Re-read this Ticket after that lands, then accept from queued if still unblocked.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:19:34Z -->
-
-## Decision
-
-Routing decision update: still_waiting_due_surface_overlap
-
-The user asked to prefer parallel work when conflicts are absent or expected to be small. I re-evaluated this Ticket under that policy and am still leaving it queued.
-
-Reason:
-- This Ticket removes `action_required` / `attention_required` from Ticket schema/tool API/Panel behavior.
-- `20260609-085212-001` now runs in parallel and also changes TicketList/tool output.
-- `20260609-084725-001` now runs in parallel and changes Panel behavior/key/display.
-- Running this cleanup at the same time would overlap both active Ticket tool output and Panel behavior surfaces; this is more than a small mechanical conflict.
-
-State decision:
-- Leave this Ticket `queued`.
-- Re-read and route it after either TicketList output slimming or Panel display work lands, depending on which surface remains active.
-
----

.yoi/tickets/20260609-101732-001/artifacts/relations.json

@@ -1,13 +0,0 @@
-{
-  "version": 1,
-  "relations": [
-    {
-      "ticket_id": "20260609-101732-001",
-      "kind": "related",
-      "target": "20260608-061235-001",
-      "note": "旧/広域の starvation-prevention / OrchestrationPlan planning Ticket。対象 Ticket は実装ストア変更ではなく workflow guidance に限定した follow-up として扱う。blocking relation ではない。",
-      "author": "intake",
-      "at": "2026-06-09T10:24:05Z"
-    }
-  ]
-}

.yoi/tickets/20260609-101732-001/item.md

@@ -1,81 +0,0 @@
----
-title: 'Orchestratorに独立queued workの並列開始を促す'
-state: 'inprogress'
-created_at: '2026-06-09T10:17:32Z'
-updated_at: '2026-06-09T10:36:44Z'
-assignee: null
-queued_by: 'workspace-panel'
-queued_at: '2026-06-09T10:31:16Z'
----
-
-## 背景
-
-現行の Orchestrator workflow は安全側の制約が強く、並列稼働は許可されているが積極的に促されていない。
-
-現状の強い指示:
-
-- Queue notification だけで blind spawn しない。
-- `queued -> inprogress` acceptance 前に worktree / coder Pod / reviewer Pod を起動しない。
-- dependency / conflict / capacity / risk / current workspace state を確認する。
-- OrchestrationPlan は automatic scheduler ではなく、Orchestrator が読んで明示判断する。
-
-一方で、以下の指示が弱い:
-
-- independent queued Tickets が複数あり capacity が空いているなら、1件ずつ完了待ちするのではなく並列に受理・起動する。
-- idle capacity を残さないよう active work set を更新する。
-- Orchestrator は safety checks を満たした範囲で parallel work を優先する。
-
-結果として、Orchestrator が保守的に 1 Ticket ずつ処理し、coder/reviewer capacity を使い切らない傾向がある。
-
-## ゴール
-
-Orchestrator / multi-agent workflow guidance を更新し、独立した queued work があり capacity が空いている場合は、明示的な safety checks を満たした上で並列稼働を優先するようにする。
-
-## 要件
-
-- `ticket-orchestrator-routing` に parallel capacity policy を追加する。
-- `multi-agent-workflow` の並列運用 guidance を、注意事項だけでなく積極的な scheduling/acceptance stance として補強する。
-- Orchestrator は automatic scheduler ではないが、明示的に起動された routing / queue review / panel kick の中では idle capacity を残さないように判断する。
-- 複数 queued Tickets がある場合、Orchestrator は以下を確認した上で並列開始を優先する:
-  - each Ticket is queued and human-authorized for routing;
-  - each Ticket has no unresolved `depends_on` / incoming blocking relation;
-  - no `do_not_parallelize` / conflict / shared write-scope constraint blocks concurrent work;
-  - separate worktree / branch / write scope can be created;
-  - coder/reviewer capacity is available and trackable;
-  - each Ticket can be accepted with `queued -> inprogress` before side effects;
-  - existing active inprogress work is not waiting for a bottleneck that makes new work unsafe.
-- If parallel start is not chosen despite available queued work, Orchestrator should record a bounded reason:
-  - dependency;
-  - conflict;
-  - capacity;
-  - missing planning decision;
-  - workspace dirty state;
-  - reviewer/coder bottleneck;
-  - user/human gate.
-- OrchestrationPlan records may help express waiting/capacity/conflict decisions, but they are not automatic scheduler authority.
-- The guidance should distinguish:
-  - active work that is waiting on coder/reviewer completion, where re-kick should not thrash;
-  - idle Orchestrator with queued/planned work, where starting another independent Ticket is preferred.
-- Keep all existing safety invariants:
-  - no implementation side effects before `queued -> inprogress`;
-  - no blind spawn from notification alone;
-  - no shared write scope between coder Pods;
-  - reviewer remains read-only unless explicitly scoped;
-  - dependency/conflict relations are respected.
-
-## 非目標
-
-- Implementing an automatic background scheduler.
-- Starting unqueued Tickets.
-- Ignoring relation blockers or workspace conflicts.
-- Implementing OrchestrationPlan store changes.
-- Changing Pod runtime scheduling.
-
-## 受け入れ条件
-
-- Orchestrator workflow says independent queued work with available capacity should be started in parallel after explicit checks, rather than waiting one Ticket at a time by default.
-- Multi-agent workflow includes active parallel work-set management guidance, not only safety notes.
-- If Orchestrator leaves queued work idle while capacity appears available, it records a reason.
-- Safety invariants around `queued -> inprogress`, worktree isolation, scope separation, relation blockers, and review loop remain explicit.
-- Focused prompt/workflow tests or snapshot tests are updated if present.
-- `target/debug/yoi ticket doctor` and `git diff --check` pass.

.yoi/tickets/20260609-101732-001/thread.md

@@ -1,95 +0,0 @@
-<!-- event: create author: LocalTicketBackend at: 2026-06-09T10:17:32Z -->
-
-## 作成
-
-LocalTicketBackend によって作成されました。
-
----
-
-<!-- event: intake_summary author: intake at: 2026-06-09T10:24:23Z -->
-
-## Intake summary
-
-Ticket 20260609-101732-001 は implementation_ready。目的は Orchestrator / multi-agent workflow guidance に parallel capacity policy を追加し、独立した queued work が複数あり capacity が空いている場合に、安全確認後は 1 件ずつ待たず並列受理・起動を優先するよう明文化すること。非目標は automatic background scheduler、unqueued Ticket の開始、OrchestrationPlan store/runtime scheduling の変更。既存安全不変条件（queued -> inprogress 前の副作用禁止、blind spawn 禁止、worktree/write-scope 分離、relation blocker 尊重、reviewer read-only 原則）は維持する。関連 Ticket 20260608-061235-001 は broader starvation-prevention/planning work であり、本 Ticket は workflow guidance に限定した non-blocking follow-up として扱う。risk_flags: [orchestration-policy, workflow-guidance, parallelism, authority-boundary, scope-isolation]。未解決の blocking question はない。
-
----
-
-<!-- event: state_changed author: intake at: 2026-06-09T10:24:23Z from: planning to: ready reason: intake_ready field: state -->
-
-## State changed
-
-Intake により要件・受け入れ条件・非目標・安全不変条件・関連 work を確認した。実装は prompt/workflow resource の focused update と必要な snapshot/test 更新に限定でき、Orchestrator が routing 可能な状態。
-
----
-
-<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:31:16Z from: ready to: queued reason: queued field: state -->
-
-## State changed
-
-Ticket を `workspace-panel` が queued にしました。
-
-
----
-
-<!-- event: state_changed author: orchestrator at: 2026-06-09T10:35:08Z from: queued to: inprogress reason: orchestrator_acceptance_parallel_capacity field: state -->
-
-## State changed
-
-Accepted queued implementation under the updated parallel-capacity policy. This is workflow guidance for starting independent queued work in parallel, matching the user's current routing preference. It is docs/workflow-oriented and expected conflicts are small/manageable.
-
----
-
-<!-- event: decision author: orchestrator at: 2026-06-09T10:35:08Z -->
-
-## Decision
-
-Routing decision: implementation_ready_parallel
-
-Reason:
-- The user explicitly requested more parallelism when conflicts are absent or small.
-- This Ticket updates Orchestrator/multi-agent workflow guidance to encode that same policy.
-- It is workflow/docs-oriented and can run alongside active code changes with expected small conflict risk.
-
-IntentPacket:
-
-Intent:
-- Update Orchestrator and multi-agent workflow guidance so independent queued work with available capacity is started in parallel after explicit safety checks, rather than waiting one Ticket at a time by default.
-
-Binding decisions / invariants:
-- Orchestrator is not an automatic background scheduler.
-- Do not start unqueued Tickets.
-- No implementation side effects before `queued -> inprogress` acceptance.
-- No blind spawn from queue notifications alone.
-- Respect unresolved `depends_on` / incoming blocker relations, `do_not_parallelize`, conflict records, workspace dirty state, and shared write-scope constraints.
-- Use separate worktrees/branches/write scopes for parallel Coder Pods.
-- Reviewer remains read-only unless explicitly scoped otherwise.
-- If queued work is left idle while capacity appears available, record a bounded reason: dependency, conflict, capacity, missing planning decision, workspace dirty state, reviewer/coder bottleneck, or human gate.
-- Distinguish active work waiting on coder/reviewer output from idle Orchestrator queue-review moments.
-
-Validation:
-- Focused workflow/prompt text validation or tests showing parallel start is preferred when safety checks pass.
-- Validation that safety invariants remain explicit.
-- `git diff --check`, `cargo run -q -p yoi -- ticket doctor`, `nix build .#yoi` if packaged resources/docs are touched.
-
----
-
-<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:36:44Z -->
-
-## Implementation report
-
-Implementation routing started in parallel with the current active work set.
-
-Worktree/branch:
-- Worktree: `.worktree/orchestrator-parallel-queued-work`
-- Branch: `orchestrator-parallel-queued-work`
-- Base/routing commit: `5d9e227 ticket: route analytics batching and parallel guidance`
-
-Spawned sibling Coder Pod:
-- `coder-orchestrator-parallel-queued-work`
-- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
-
-Parallel-routing rationale:
-- This workflow/docs Ticket encodes the user's updated parallel-capacity preference.
-- It is expected to have only small/managed conflicts with active work and no runtime scheduler changes.
-
----

.yoi/tickets/closed/20260527-000001-auto-maintain-workflow/item.md

@@ -1,8 +1,14 @@
 ---
-title: "半自動開発運用 Workflow"
-state: "closed"
-created_at: "2026-05-27T00:00:01Z"
-updated_at: "2026-06-05T15:56:29Z"
+id: 20260527-000001-auto-maintain-workflow
+slug: auto-maintain-workflow
+title: 半自動開発運用 Workflow
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:01Z
+updated_at: 2026-06-05T15:56:29Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000004-manual-turn-rollback/item.md

@@ -1,8 +1,14 @@
 ---
-title: "Pod/TUI: 手動 rewind 導線"
-state: "closed"
-created_at: "2026-05-27T00:00:04Z"
-updated_at: "2026-05-29T03:09:22Z"
+id: 20260527-000004-manual-turn-rollback
+slug: manual-turn-rollback
+title: 'Pod/TUI: 手動 rewind 導線'
+status: closed
+kind: task
+priority: P2
+labels: [tui, pod, ux]
+created_at: 2026-05-27T00:00:04Z
+updated_at: 2026-05-29T03:09:22Z
+assignee: null
 ---
 
 ## Background

.yoi/tickets/closed/20260527-000005-memory-tool-guidance-prompt/item.md

@@ -1,8 +1,14 @@
 ---
-title: "プロンプト: memory / knowledge tool 利用タイミングのガイダンス"
-state: "closed"
-created_at: "2026-05-27T00:00:05Z"
-updated_at: "2026-05-28T23:59:06Z"
+id: 20260527-000005-memory-tool-guidance-prompt
+slug: memory-tool-guidance-prompt
+title: 'プロンプト: memory / knowledge tool 利用タイミングのガイダンス'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:05Z
+updated_at: 2026-05-28T23:59:06Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000007-pod-inbound-pod-event-dedup/item.md

@@ -1,8 +1,14 @@
 ---
-title: "Inbound PodEvent ハンドリングの重複を統合する"
-state: "closed"
-created_at: "2026-05-27T00:00:07Z"
-updated_at: "2026-05-30T05:37:00Z"
+id: 20260527-000007-pod-inbound-pod-event-dedup
+slug: pod-inbound-pod-event-dedup
+title: Inbound PodEvent ハンドリングの重複を統合する
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:07Z
+updated_at: 2026-05-30T05:37:00Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000008-pod-scope-persistence-authority/item.md

@@ -1,8 +1,14 @@
 ---
-title: "Pod: scope 永続化 authority の整理"
-state: "closed"
-created_at: "2026-05-27T00:00:08Z"
-updated_at: "2026-05-30T05:57:16Z"
+id: 20260527-000008-pod-scope-persistence-authority
+slug: pod-scope-persistence-authority
+title: 'Pod: scope 永続化 authority の整理'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:08Z
+updated_at: 2026-05-30T05:57:16Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000011-session-todo-reminder/item.md

@@ -1,8 +1,14 @@
 ---
-title: "セッション内 Task ツールの注意機構"
-state: "closed"
-created_at: "2026-05-27T00:00:11Z"
-updated_at: "2026-05-29T04:31:10Z"
+id: 20260527-000011-session-todo-reminder
+slug: session-todo-reminder
+title: セッション内 Task ツールの注意機構
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:11Z
+updated_at: 2026-05-29T04:31:10Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000012-spawnpod-initial-run-confirmation/item.md

@@ -1,8 +1,14 @@
 ---
-title: "SpawnPod: initial Run delivery confirmation"
-state: "closed"
-created_at: "2026-05-27T00:00:12Z"
-updated_at: "2026-05-28T13:24:48Z"
+id: 20260527-000012-spawnpod-initial-run-confirmation
+slug: spawnpod-initial-run-confirmation
+title: 'SpawnPod: initial Run delivery confirmation'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:12Z
+updated_at: 2026-05-28T13:24:48Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000013-tickets-sh-workitem-thread-mvp/item.md

@@ -1,8 +1,14 @@
 ---
-title: "Ticket 管理: tickets.sh による WorkItem / Thread MVP"
-state: "closed"
-created_at: "2026-05-27T00:00:13Z"
-updated_at: "2026-05-27T19:28:41Z"
+id: 20260527-000013-tickets-sh-workitem-thread-mvp
+slug: tickets-sh-workitem-thread-mvp
+title: 'Ticket 管理: tickets.sh による WorkItem / Thread MVP'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:13Z
+updated_at: 2026-05-27T19:28:41Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000014-tui-actionbar-transient-notice-api/item.md

@@ -1,8 +1,14 @@
 ---
-title: "TUI: actionbar transient notice API"
-state: "closed"
-created_at: "2026-05-27T00:00:14Z"
-updated_at: "2026-05-29T03:57:35Z"
+id: 20260527-000014-tui-actionbar-transient-notice-api
+slug: tui-actionbar-transient-notice-api
+title: 'TUI: actionbar transient notice API'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:14Z
+updated_at: 2026-05-29T03:57:35Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000016-tui-picker-live-pending-pods/item.md

@@ -1,8 +1,14 @@
 ---
-title: "TUI picker: live pending Pod の表示優先と状態補完"
-state: "closed"
-created_at: "2026-05-27T00:00:16Z"
-updated_at: "2026-05-30T05:00:56Z"
+id: 20260527-000016-tui-picker-live-pending-pods
+slug: tui-picker-live-pending-pods
+title: 'TUI picker: live pending Pod の表示優先と状態補完'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:16Z
+updated_at: 2026-05-30T05:00:56Z
+assignee: null
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000017-tui-spawned-pod-panel/item.md

@@ -1,8 +1,15 @@
 ---
-title: "TUI: spawned child Pod の一覧と一時 attach"
-state: "closed"
-created_at: "2026-05-27T00:00:17Z"
-updated_at: "2026-06-07T03:14:39Z"
+id: 20260527-000017-tui-spawned-pod-panel
+slug: tui-spawned-pod-panel
+title: 'TUI: spawned child Pod の一覧と一時 attach'
+status: closed
+kind: task
+priority: P2
+labels: [migrated]
+created_at: 2026-05-27T00:00:17Z
+updated_at: 2026-06-07T03:14:39Z
+assignee: null
+workflow_state: done
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000019-workspace-memory-lint-cli/item.md

@@ -1,8 +1,14 @@
 ---
-title: "ワークスペースのメモリーをLintするヘッドレスCLI"
-state: "closed"
-created_at: "2026-05-27T00:00:19Z"
-updated_at: "2026-05-31T02:15:17Z"
+id: 20260527-000019-workspace-memory-lint-cli
+slug: workspace-memory-lint-cli
+title: ワークスペースのメモリーをLintするヘッドレスCLI
+status: closed
+kind: task
+priority: P2
+labels: [migrated, memory, cli]
+created_at: 2026-05-27T00:00:19Z
+updated_at: 2026-05-31T02:15:17Z
+assignee: null
 ---
 
 ## Background