4.9 KiB
4.9 KiB
| title | state | created_at | updated_at | assignee | readiness | risk_flags | queued_by | queued_at | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Panel startup latency E2E を一覧データ描画完了基準に修正する | done | 2026-06-15T16:44:06Z | 2026-06-18T13:30:51Z | null | implementation_ready |
|
workspace-panel | 2026-06-17T09:46:03Z |
Background
既存の Panel startup latency E2E は、panel_ready を主要な startup readiness として扱っている。しかし現在の panel_ready は terminal.draw(|f| draw(f, app)) の初回完了直後に emit される first visible frame であり、Ticket / Pod / Orchestrator 一覧データが取得され、Panel rows として実際に描画されたことを意味しない。
ユーザーが問題にしている startup latency は、空または loading の初回 frame ではなく、Panel が実用可能な一覧データを表示するまでの時間である。したがって、既存 E2E の前提は不十分であり、startup latency E2E の readiness 基準を「一覧データ取得後の row render」に修正する必要がある。
この Ticket は、first frame の高速化を否定するものではない。first frame metric は補助 metric として残してよい。ただし startup latency の主 assertion / 報告値は、fixture の期待 Ticket / Pod / Orchestrator rows が ViewModel に反映され、描画後の row metadata / screen output として観測できたタイミングを基準にする。
Requirements
- Panel startup latency E2E の readiness 定義を明確化する。
panel_first_frame: 初回 visible draw。loading / empty frame でもよい。panel_rows_readyまたは同等: 一覧データが取得され、期待 row が描画された状態。
- Startup latency の主 budget / assertion は
panel_rows_ready相当に置く。panel_ready/ first frame を「一覧 ready」として扱わない。
- Fixture は期待される一覧データを具体的に持つ。
- 少なくとも fixture Ticket id / title / state の row が描画されたことを assert する。
- 必要に応じて Pod row / orchestration overlay row も fixture に含める。
rows_rendered.len() >= Nのような弱い条件だけに依存しない。- 期待 Ticket id / title / state / row kind など、実データ反映を確認する。
- E2E event naming / diagnostics を誤解しにくくする。
panel_readyが残る場合は first frame として説明する。- 一覧 ready 用の別 event / helper / metric 名を追加する。
- Background reload / observation が遅い場合でも、first frame と rows ready を別々に測る。
- first frame が速いことと、一覧 ready が速いことを混同しない。
- Existing Panel behavior を変更する場合は、loading frame 後に reload を開始する設計を維持してよいが、latency E2E の成功条件を loading frame だけで満たさないようにする。
- E2E report / Ticket implementation report では、before/after 数値が何を測っているかを明記する。
- first visible frame
- fixture rows ready
- full/background observation completion if measured
Acceptance criteria
- Panel startup latency E2E が、fixture の具体的な Ticket row が描画されたタイミングを readiness として測定する。
panel_ready/ first visible frame だけでは startup latency E2E の主 assertion が通らない。- Fixture row readiness は
len >= 2などの抽象条件ではなく、期待 Ticket id / title / state 等で確認される。 - E2E output / helper 名 / comments から、first frame と rows ready の違いが分かる。
- Background reload を hold するテストがある場合、first frame は先に出てもよいが、rows ready はデータ反映まで完了しないことを確認できる。
- Existing Panel mouse / row selection E2E に regression がない。
- Tests cover:
- first frame event does not imply list readiness
- fixture Ticket row rendered readiness
- delayed reload delays rows-ready metric but not necessarily first-frame metric
- row readiness fails when expected fixture row is absent
- Validation:
cargo test -p yoi-e2e --features e2e panel, relevantcargo check,cargo fmt --check,git diff --check, andnix build .#yoiif runtime/package/dependency changes occur.
Non-goals
- Solving all live workspace startup latency causes in this Ticket.
- Replacing Panel ViewModel architecture.
- Requiring every Pod socket / Orchestrator observation to fully settle before any UI is shown.
- Removing first visible frame metric entirely.
- Changing Ticket lifecycle semantics.
Related work
00001KV5MRH6D— Panel startup latency E2E / first visible frame separation work.00001KV5D7MG5— Panel orchestration worktree Ticket state overlay.00001KV4ZPAD3— Panel Ticket / Intake Pod row visual hierarchy.