project: record queued tickets and issue notes

.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/item.md

@@ -6,11 +6,13 @@ status: 'open'
 kind: 'bug'
 priority: 'P2'
 labels: ['tui', 'chat', 'markdown', 'rendering', 'ux']
-workflow_state: 'ready'
+workflow_state: 'queued'
 created_at: '2026-06-08T10:31:33Z'
-updated_at: '2026-06-08T10:31:40Z'
+updated_at: '2026-06-08T13:13:23Z'
 assignee: null
 risk_flags: ['tui-rendering', 'markdown']
+queued_by: 'workspace-panel'
+queued_at: '2026-06-08T13:13:23Z'
 ---
 
 ## Background

.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/thread.md

@@ -20,4 +20,13 @@ LocalTicketBackend によって作成されました。
 
 要件・受け入れ条件・invariant・validation が揃っており、Orchestrator が implementation routing できる状態になった。
 
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-08T13:13:23Z from: ready to: queued reason: queued field: workflow_state -->
+
+## State changed
+
+Ticket を `workspace-panel` が queued にしました。
+
+
 ---

.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/item.md

@@ -0,0 +1,73 @@
+---
+id: '20260608-125430-objective-records-for-medium-term-goals'
+slug: 'objective-records-for-medium-term-goals'
+title: 'Define Objective records for medium-term goals'
+status: 'open'
+kind: 'task'
+priority: 'P2'
+labels: ['objective', 'ticket', 'planning', 'workflow', 'design']
+workflow_state: 'planning'
+created_at: '2026-06-08T12:54:30Z'
+updated_at: '2026-06-08T12:54:30Z'
+assignee: null
+---
+
+## Background
+
+Tickets are settling into a concrete implementation/work-item unit: Intake/Planning shapes user intent into Tickets that can be implemented, reviewed, and completed. Parent/child Ticket relationships are useful for decomposition, but they are not sufficient for medium-term strategic context.
+
+Some work needs a separate record for the goal, motivation, strategy, success criteria, and decision context that spans multiple Tickets without turning the Ticket hierarchy into a roadmap/project-management system.
+
+Use the term `Objective` for this concept. `Project` is too broad, and `Initiative` feels too business/process-heavy.
+
+## Goal
+
+Design a lightweight `Objective` record type for medium-term goals that can group and contextualize multiple Tickets while keeping Tickets focused on implementable work items.
+
+## Requirements
+
+- Define `Objective` as a first-class project record distinct from Ticket.
+  - Objective: medium-term goal, motivation, strategy, success criteria, and decision context.
+  - Ticket: implementable work item shaped by Intake/Planning.
+  - OrchestrationPlan: current execution plan for queued/in-progress work.
+- Keep Objectives lightweight and Markdown-oriented initially.
+  - Avoid building a full roadmap/project-management system in the first version.
+  - Prefer a simple local file backend under a clear `.yoi/` path.
+- An Objective should be able to record at least:
+  - title;
+  - goal statement;
+  - motivation/background;
+  - strategy or design direction;
+  - success criteria / exit conditions;
+  - linked Tickets;
+  - important decisions or pivots;
+  - current state such as active/paused/done, if useful.
+- Tickets should be able to reference an Objective or be listed under it.
+  - The relation should not replace Ticket dependency/blocking metadata.
+  - A Ticket can belong to an Objective without depending on every other Ticket in that Objective.
+- Orchestrator/Intake/Planning should be able to use Objective context when shaping or routing Tickets.
+  - Objective context should help answer “why this direction?” and “what judgment criteria apply?”
+  - It should not allow agents to skip reading the actual Ticket body/thread before implementation decisions.
+- Panel/CLI should eventually be able to show Objective context and linked Tickets, but first design can focus on record shape and workflow semantics.
+- Clarify how Objectives differ from:
+  - parent/child Tickets;
+  - typed Ticket relations such as `depends_on` / `blocks`;
+  - OrchestrationPlan execution decisions;
+  - local Pod/session runtime claims.
+
+## Non-goals
+
+- Replacing Tickets.
+- Replacing typed Ticket relation metadata.
+- Replacing OrchestrationPlan.
+- Implementing full roadmap scheduling, milestones, OKRs, or dependency graph solving.
+- Making every Ticket require an Objective.
+
+## Acceptance criteria
+
+- There is a documented concept and proposed file/API shape for `Objective` records.
+- The design explains when to create an Objective versus a parent Ticket.
+- The design explains how Tickets link to Objectives without conflating that link with dependency/blocking relations.
+- The design explains how Orchestrator/Intake should consult Objective context while still treating Ticket body/thread as the implementation authority.
+- A first implementation path is identified with minimal schema and tooling scope.
+- `target/debug/yoi ticket doctor` and `git diff --check` pass for any record changes.

.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-08T12:54:30Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---

KNOWN_ISSUES.md

@@ -2,17 +2,7 @@
 
 Ticket を切るほどではないが、次に近所を触るときに合わせて拾いたい小粒な所見の置き場。
 
-## 運用
+- `crates/pod/src/controller.rs:1269-1278` — `worker_error_code` で `PodError::WorkflowResolve(_) => InvalidRequest` が post-commit な resolve エラー (`KnowledgeNotFound` 等) にも適用される。意味論的には妥当方向だが、resolve 系のエラー粒度を分けたくなったタイミングで再評価。
-
-- 1 項目 = 出典 (file:line) + 症状 (一文) + トリガー (いつ拾うか、一文)
-- 関連 ticket があれば `→ [tickets/foo.md]` でリンク
-- 修正したら同じコミットで該当エントリを削除する (履歴は git)
-- ここに溜める基準: 「ticket は重い」「だが忘れたら次の触り手が踏む」もの。明確に作業すべきものは ticket 化する
-
-## エントリ
-
-- `crates/pod/src/controller.rs:703-718` / `crates/tui/src/app.rs:837-845` — bad workflow slug を含む `Method::Run` 送信時、`Event::UserMessage` の早期 broadcast で `turn_index += 1` されターンヘッダだけ残る ("ghost turn header")。次に TUI のターンヘッダ / エラー表示周りを触るときに整理。
-- `crates/pod/src/controller.rs:1256-1265` — `worker_error_code` で `PodError::WorkflowResolve(_) => InvalidRequest` が post-commit な resolve エラー (`KnowledgeNotFound` 等) にも適用される。意味論的には妥当方向だが、resolve 系のエラー粒度を分けたくなったタイミングで再評価。
 - `crates/session-store/src/fs_store.rs:200-210` — `FsStore::read_entry_count` が `fs::read_to_string` で全文ロードしてから行数カウントするため O(n)。`ensure_head_or_fork` は run-start でしか呼ばれず現状は許容範囲だが、長期セッションが普通になった時点で `\n` バイト数の cheap count か末尾 seek に置き換える。
-- `crates/session-store/src/segment.rs:143-172` `ensure_head_or_fork` (free fn, test 専用・本番 caller ゼロ) と `crates/pod/src/pod.rs:1943-2006` `Pod::ensure_segment_head` (本番 inline) に live auto-fork の検知 + forked_from 記録が二重実装されている。entry-hash-abolish 以前からの重複で、両方独立にテスト済みだが drift 必至。session-store 側を本番から呼ぶ形に寄せるか free fn を畳むかは要設計判断。Pod state / fork 周辺を次に触るときに統合を検討。
+- `crates/session-store/src/segment.rs:143-172` `ensure_head_or_fork` (free fn, test 専用・本番 caller ゼロ) と `crates/pod/src/pod.rs:1941-2006` `Pod::ensure_segment_head` (本番 inline) に live auto-fork の検知 + forked_from 記録が二重実装されている。entry-hash-abolish 以前からの重複で、両方独立にテスト済みだが drift 必至。session-store 側を本番から呼ぶ形に寄せるか free fn を畳むかは要設計判断。Pod state / fork 周辺を次に触るときに統合を検討。
-- `crates/pod/src/pod.rs:4074` / `crates/pod/src/spawn/registry.rs:83` — restore 時の spawned child prune/reclaim が Pod restore path と spawned registry load path の両方に残っている。現状は安全側の重複チェックだが、Pod state / spawned registry 周辺を次に触るときに責務境界を再整理。
+- `crates/pod/src/pod.rs:4100-4147` / `crates/pod/src/spawn/registry.rs:84-174` — restore 時の spawned child prune/reclaim が Pod restore path と spawned registry load path の両方に残っている。現状は安全側の重複チェックだが、Pod state / spawned registry 周辺を次に触るときに責務境界を再整理。