yoi/.yoi/tickets/00001KVSKJ0EA/thread.md

作成

LocalTicketBackend によって作成されました。

---

Intake summary

ユーザー合意により ready 化。Ticket は implementation_ready で、初回 yoi panel 表示時から未選択、Esc 後の no-selection を reload が復活させない、未選択 + TicketIntake composer submit を global/new Intake に流す、という要件・受け入れ条件・validation が明記されている。未決定点なし。

---

State changed

ユーザーから readyにして の明示指示があり、対象 Ticket の item/thread を確認した。要件・受け入れ条件・risk flags・validation が揃っており、Orchestrator が routing 可能なため ready に遷移する。

---

State changed

Ticket を workspace-panel が queued にしました。

---

Decision

Routing decision: implementation_ready_parallel

Reason:

• Ticket body has concrete Dashboard selection semantics and focused test requirements。
• No relations / blockers / orchestration plan records exist。
• Active queued Workspace identity Ticket is backend/workspace-server focused and separate from TUI Dashboard row-selection code, so parallel implementation is acceptable。
• Orchestrator worktree is clean on orchestration at 13e76d35; target worktree / branch is not present。
• Code map from Ticket body points to crates/tui/src/dashboard/mod.rs, tests.rs, and render.rs。

IntentPacket:

Intent:

• Treat no-selection as a first-class Dashboard UX state: initial panel display and reload/background refresh must not auto-select rows, while explicit keyboard/mouse selection still works。

Binding decisions / invariants:

• Initial yoi panel display should have selected_row = None even when rows are visible。
• Esc clear must persist across reload/snapshot refresh; reload must not recreate selection after explicit no-selection。
• If a user explicitly selected a row and it remains visible after reload, that selection may be preserved。
• If selected row disappears after reload, fall back safely to no-selection。
• Composer draft must survive selection clear/reload。
• Existing row actions, queue/close/open operations, Ticket workflow state semantics, and row-click-is-selection-only policy must remain unchanged。
• No broad Dashboard layout redesign in this Ticket。

Requirements / acceptance criteria:

• Initial Dashboard state has no selected row when rows exist。
• Esc clear -> reload completion -> still no selected row。
• No-selection + TicketIntake composer submit routes to global/new Intake, not selected Ticket refinement。
• Keyboard navigation or mouse click can explicitly create selection again。
• Focused tests cover the above semantics。

Implementation latitude:

• Use an explicit no-selection flag or refine selection visibility correction conditions。
• The key is to make selection creation happen only from explicit user navigation/click/action paths, not from reload/init visibility correction。

Escalate if:

• Initial no-selection substantially breaks keyboard-only navigation or blank Enter action contract。
• Existing selection visibility correction has safety roles that cannot be preserved with a local change。
• Real terminal / PTY behavior is required beyond focused tests。

Validation plan:

• cargo fmt --check
• cargo test -q -p tui workspace_panel
• Dashboard focused tests as needed。
• git diff --check
• cargo run -p yoi -- ticket doctor。

---

State changed

Human authorized queue routing from Workspace Dashboard. Ticket has concrete Dashboard selection semantics and no recorded blockers, so Orchestrator accepts implementation.

---