yoi/.yoi/tickets/00001KVSGFM65/thread.md

作成

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

---

Intake summary

Marked ready by yoi ticket state.

---

State changed

Marked ready by yoi ticket state.

---

State changed

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

---

Decision

Routing decision: implementation_ready_parallel

Reason:

• Ticket body has concrete frontend requirements for Repository Ticket Kanban grouping, sort order, per-group independent scroll, lazy row loading, component boundary, and Deno/Nix validation。
• No relations / blockers / orchestration plan records exist。
• Active Ticket 00001KVSEBF56 is protocol TypeScript generation and is expected to touch protocol crate / generated types; this Kanban ticket primarily targets Workspace Repository page UI and can proceed in parallel with narrow frontend scope。
• Current queued Ticket is this Ticket only。
• Orchestrator worktree is clean on orchestration at 2865abb6; target worktree / branch is not present。
• Current code map shows Repository Ticket Kanban is currently inline in web/workspace/src/lib/workspace-pages/WorkspacePage.svelte, using repositoryTickets.columns from /api/repositories/local/tickets。

IntentPacket:

Intent:

• Improve Repository Ticket Kanban display so high-volume states do not dominate the page, related states are grouped, and each group lazy-loads independently。

Binding decisions / invariants:

• Frontend display behavior only unless absolutely necessary; do not change Ticket lifecycle semantics or add mutation UI。
• Backend pagination is not required; frontend-only visible count per group is acceptable。
• Original Ticket state must remain visible on each row。
• Grouping is display-only: planning+ready, queued+inprogress, other states independent。
• Group sort priority: ready before planning, inprogress before queued。
• Each group has independent scroll/visible count state; scrolling one group must not increase other groups。
• Use existing design tokens from web/workspace/src/app.css; avoid raw colors and heavy card chrome。
• Keep static SPA / Deno tooling boundaries。
• Do not touch protocol TS generation scope from 00001KVSEBF56 unless unavoidable。

Requirements / acceptance criteria:

• planning and ready display in the same group, with ready above planning。
• queued and inprogress display in the same group, with inprogress above queued。
• done, closed, and other states keep independent display meaning。
• Each group has an independent scroll area approximately 10 rows tall。
• Initial visible rows per group are capped at 30。
• Near-bottom scroll within a group increases only that group’s visible count。
• closed or other high-volume group does not expand page height excessively。
• Row displays original Ticket state。
• Kanban display is preferably split into reusable Svelte component(s), moving grouping/sort/visible-count/scroll logic out of WorkspacePage.svelte。
• Deno check/build, git diff --check, and nix build .#yoi --no-link pass。

Implementation latitude:

• Component can live under web/workspace/src/lib/workspace-pages/ or another clear frontend component path。
• Backend response shape may remain unchanged; grouping can be performed client-side from returned columns/items。
• Add minimal frontend tests only if current tooling supports it cheaply; otherwise validation via Svelte check/build is acceptable。
• CSS can be simple rule/typography/spacing approach; no need for full design system。

Escalate if:

• Svelte 5 event/scroll handling requires a broader frontend state management rewrite。
• Backend response shape prevents group-level lazy display without changing API semantics。
• Deno build/check breaks due unrelated protocol type generation work。

Validation plan:

• cd web/workspace && deno task check && deno task build
• git diff --check
• cargo run -p yoi -- ticket doctor
• nix build .#yoi --no-link
• cargo test -p yoi-workspace-server only if backend API changes。

---

State changed

Human authorized queue routing from Workspace Dashboard. Ticket has concrete frontend acceptance criteria and no recorded blockers; active protocol TypeScript generation work is separate enough for parallel implementation.

---