diff --git a/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/item.md b/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/item.md index 2ef583e3..19d0ebf6 100644 --- a/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/item.md +++ b/.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 diff --git a/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/thread.md b/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/thread.md index dd1a4c5b..a25e65e4 100644 --- a/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/thread.md +++ b/.yoi/tickets/open/20260608-103133-tui-chat-markdown-table-rendering/thread.md @@ -20,4 +20,13 @@ LocalTicketBackend によって作成されました。 要件・受け入れ条件・invariant・validation が揃っており、Orchestrator が implementation routing できる状態になった。 +--- + + + +## State changed + +Ticket を `workspace-panel` が queued にしました。 + + --- diff --git a/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/artifacts/.gitkeep b/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/item.md b/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/item.md new file mode 100644 index 00000000..9c5d40fe --- /dev/null +++ b/.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. diff --git a/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/thread.md b/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/thread.md new file mode 100644 index 00000000..f43c6e6e --- /dev/null +++ b/.yoi/tickets/open/20260608-125430-objective-records-for-medium-term-goals/thread.md @@ -0,0 +1,7 @@ + + +## 作成 + +LocalTicketBackend によって作成されました。 + +--- diff --git a/KNOWN_ISSUES.md b/KNOWN_ISSUES.md index c25fbc4d..ac948291 100644 --- a/KNOWN_ISSUES.md +++ b/KNOWN_ISSUES.md @@ -2,17 +2,7 @@ Ticket を切るほどではないが、次に近所を触るときに合わせて拾いたい小粒な所見の置き場。 -## 運用 - -- 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/pod/src/controller.rs:1269-1278` — `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/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/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: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 周辺を次に触るときに責務境界を再整理。