ticket: accept workspace identity and selection work

2026-06-23 15:50:36 +09:00
parent 13e76d3544
commit 4cda83b748
6 changed files with 133 additions and 4 deletions
@@ -29,4 +29,64 @@ LocalTicketBackend によって作成されました。
 Ticket を `workspace-panel` が queued にしました。


+---
+
+<!-- event: decision author: yoi-orchestrator at: 2026-06-23T06:49:08Z -->
+
+## 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`。
+
+---
+
+<!-- event: state_changed author: yoi-orchestrator at: 2026-06-23T06:49:18Z from: queued to: inprogress reason: human_authorized_unblocked_dashboard_no_auto_selection field: state -->
+
+## State changed
+
+Human authorized queue routing from Workspace Dashboard. Ticket has concrete Dashboard selection semantics and no recorded blockers, so Orchestrator accepts implementation.
+
 ---