ticket: record panel validation failures

.yoi/tickets/00001KV0723PC/item.md

@@ -2,7 +2,7 @@
 title: 'Panel Quit 時の断続的な遅延を調査して解消する'
 state: 'done'
 created_at: '2026-06-13T10:04:55Z'
-updated_at: '2026-06-13T11:41:26Z'
+updated_at: '2026-06-13T12:57:53Z'
 assignee: null
 readiness: 'spike_needed'
 risk_flags: ['tui-panel', 'shutdown-latency', 'async-cancellation']

.yoi/tickets/00001KV0723PC/thread.md

@@ -260,3 +260,32 @@ Next:
 Implementation branch `ticket-00001KV0723PC-panel-quit-latency` was reviewed, approved, merged into the Orchestrator branch as `db7bad7a`, and validated in the Orchestrator worktree. Focused panel quit latency tests, formatting, diff check, and `cargo check -p tui --all-targets` passed. Ticket implementation work is done; closure remains separate.
 
 ---
+
+<!-- event: comment author: orchestrator at: 2026-06-13T12:57:53Z -->
+
+## Comment
+
+Post-merge measurement report: Panel quit latency is still present / not proven fixed.
+
+User report:
+- 「相変わらずPanelをquitする際の遅延も解決してない」
+
+Measurement performed after merge in Orchestrator worktree `/home/hare/Projects/yoi/.worktree/orchestration/yoi-orchestrator`:
+- Built current debug binary: `cargo build -p yoi`。
+- PTY measurement command shape: pipe `sleep <delay>; Ctrl+C` into `script -q -c 'target/debug/yoi panel --workspace ...'` and measure process elapsed.
+- Current debug binary `target/debug/yoi` results with Ctrl+C sent after 1.5s:
+  - approx after Ctrl+C: 2488ms, 2561ms, 2453ms, 2558ms, 2507ms。
+- Varying Ctrl+C send delay against current debug binary:
+  - delay 0.2s -> total 3958ms
+  - delay 1.0s -> total 3919ms
+  - delay 2.0s -> total 4062ms
+  - delay 3.5s -> total 4095ms
+  - delay 5.0s -> total 6309ms
+- Installed `/home/hare/.nix-profile/bin/yoi` showed approx 24-25ms after Ctrl+C in the same scripted shape, and also appeared not to contain the new test/symbol strings, so binary-path freshness differs between measurements.
+
+Conclusion:
+- The original merge was based on a plausible code-path fix and focused tests, but no interactive/user-path latency measurement was done before marking done。
+- The current debug binary still shows a roughly 4s startup/quit floor in the PTY measurement, so the merged fix did not prove the user's observed latency is gone and may have missed a different blocking path。
+- Follow-up must identify the actual user command/binary path and measure `yoi panel` quit latency before and after any further fix. If the relevant path is current source/debug, this Ticket should be treated as not actually resolved.
+
+---

.yoi/tickets/00001KV072V89/item.md

@@ -2,7 +2,7 @@
 title: 'Workspace panel の View item をマウスで選択できるようにする'
 state: 'done'
 created_at: '2026-06-13T10:05:19Z'
-updated_at: '2026-06-13T11:26:30Z'
+updated_at: '2026-06-13T12:57:53Z'
 assignee: null
 readiness: 'implementation_ready'
 risk_flags: ['tui-input', 'mouse-capture', 'panel-ux']

.yoi/tickets/00001KV072V89/thread.md

@@ -220,3 +220,24 @@ Next:
 Implementation branch `ticket-00001KV072V89-panel-mouse-selection` was reviewed, approved, merged into the Orchestrator branch as `02311883`, and validated in the Orchestrator worktree. Focused mouse-selection tests, formatting, diff check, and `cargo check -p tui --all-targets` passed. Ticket implementation work is done; closure remains separate.
 
 ---
+
+<!-- event: comment author: orchestrator at: 2026-06-13T12:57:53Z -->
+
+## Comment
+
+Post-merge user verification report: mouse selection is still ineffective.
+
+User report:
+- 「マウス選択全く効かない」
+
+What was re-checked:
+- Merge commit for this Ticket: `02311883 merge: panel mouse selection`。
+- Implementation added `PanelRowHitBox` / `TermEvent::Mouse` handling in `crates/tui/src/multi_pod.rs` and focused tests, but there was no interactive `yoi panel` manual validation before marking done。
+- Current built debug binary contains `PanelRowHitBox` symbols; installed `/home/hare/.nix-profile/bin/yoi` did not contain those symbols in `strings` check, so at least one live/user-visible binary path may still be stale。
+- This does not fully explain the report if the user already rebuilt/restarted; the remaining likely failure areas are terminal mouse-event delivery, runtime binary freshness, hitbox coordinate mismatch, or lack of interactive validation coverage。
+
+Conclusion:
+- The original done decision was insufficient because it relied on internal hit-test/focused tests and did not prove actual terminal mouse selection in a live Panel.
+- Follow-up must include measured/manual validation with the same command/binary path the user runs, including a positive proof that a click changes selected row in `yoi panel`.
+
+---