Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
f39127b752
yoi/.yoi/tickets/00001KVSGFM65/thread.md

5.9 KiB
Raw Blame History

作成

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.

Implementation report

Implementation start report:

  • Created child implementation worktree:
    • /home/hare/Projects/yoi/.worktree/00001KVSGFM65-kanban-lazy-rows
  • Created branch:
    • impl/00001KVSGFM65-kanban-lazy-rows
  • Base commit:
    • a6f9019e ticket: accept kanban lazy rows
  • Confirmed tracked Ticket project records are visible in the child worktree。
  • Confirmed .yoi/memory has no tracked/untracked entries in the child worktree check。
  • Spawned sibling Coder Pod:
    • yoi-coder-00001KVSGFM65
  • Coder scope:
    • read: /home/hare/Projects/yoi
    • write: /home/hare/Projects/yoi/.worktree/00001KVSGFM65-kanban-lazy-rows

Parallelization note:

  • 00001KVSEBF56 remains active and targets protocol TypeScript generation. This Ticket should stay limited to Workspace Repository Ticket Kanban frontend display。

Next action:

  • Wait for Coder implementation report, then spawn Reviewer read-only for the implementation diff。