Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
98c85a1d9e
yoi/.yoi/tickets/00001KVMFFYVX/item.md
Hare 98c85a1d9e
ticket: queue 00001KVMFFYVX
2026-06-21 16:11:58 +09:00

4.6 KiB
Raw Blame History

title state created_at updated_at assignee queued_by queued_at
Workspace web control plane bootstrap queued 2026-06-21T06:57:06Z 2026-06-21T07:11:58Z null workspace-panel 2026-06-21T07:11:58Z

背景

Objective 00001KVJPT2PP（Team workspace control plane and runner architecture）の最初の実装スライスとして、Web から扱える Workspace control plane の土台を作る。

方針:

  • フルスタック framework ではなく、Rust backend + 静的 SPA frontend にする。
  • frontend は当面 monorepo 内に置く。置き場所は実装時に選ぶが、backend packaging / Nix build / repository hygiene を壊さない場所にする。
  • backend は Workspace ごとの authority boundary として設計する。
  • 初期実装は single-workspace server でよい。ただし record / API / store 設計は将来の multi-workspace / hosted deployment を阻害しない。
  • DB は最初 SQLite を使う。
  • backend と store 層は抽象化する前提で作り、SQLite 実装を最初の store backend とする。
  • Memory / Knowledge の本格再設計はこの Ticket では扱わない。将来の Workspace backend 移行時に回収する。

要件

Backend crate

  • Workspace control plane backend 用の Rust crate を追加する。
    • crate 名は実装時に決めてよいが、候補は workspace-server / workspace / control-plane。
    • public product command は将来的に yoi crate 側から露出する前提にし、backend crate に product CLI ownership を散らさない。
  • backend crate は HTTP API、static SPA serving、event stream / runner connection の将来拡張点を持つ。
  • 初期 server は single-workspace mode で起動できる。
  • API/state の内部 model には workspace_id を含め、将来の multi-workspace hosting に備える。

Store abstraction

  • Store 層は trait / interface 境界を持ち、SQLite 実装に直接結合しすぎない。
  • 初期 SQLite store を追加する。
    • WAL、foreign keys、busy timeout など、SQLite server use に必要な基本設定を行う。
    • migration / schema versioning の最小方針を持つ。
  • 初期 schema は最小限でよいが、少なくとも Workspace / Ticket / Objective / Repository / Run / Artifact / Runner の後続拡張を想定できる配置にする。
  • 既存 .yoi/tickets / .yoi/objectives は当面 canonical 互換 backend として残る。必要なら import/bridge は follow-up とし、この Ticket で無理に完全移行しない。

Frontend

  • SvelteKit static SPA の skeleton を monorepo 内に追加する。
  • frontend は static build を前提にし、SSR に backend authority を持たせない。
  • Rust backend は build 済み static assets を serve できる。
  • SPA routing fallback と /api/... の分離を設計する。
  • frontend package manager / lockfile / Nix packaging の扱いを明確にする。

Initial API / UX slice

  • 最初は read-heavy skeleton でよい。
  • 候補 API:
    • GET /api/workspace
    • GET /api/tickets
    • GET /api/tickets/{id}
    • GET /api/objectives
    • GET /api/objectives/{id}
    • GET /api/runs
    • GET /api/runners
  • write API、runner job dispatch、Ticket state mutation、Memory migration は follow-up でよい。
  • auth は初期 local/dev token または explicit local-only mode でよいが、multi-user SaaS 前提と衝突する形にしない。

Non-goals

  • full hosted SaaS / multi-tenant production server。
  • cloud runner fleet / scheduling / billing / quota。
  • Ticket/Objective の .yoi canonical store 完全移行。
  • Memory / Knowledge の本格再設計。
  • Git hosting service の実装。
  • frontend に business logic / lifecycle authority を持たせること。
  • Desktop app。

受け入れ条件

  • Workspace control plane backend 用 crate が workspace に追加されている。
  • backend と store 層の境界があり、SQLite はその初期実装として使われている。
  • SQLite schema / migration/versioning の最小実装がある。
  • single-workspace server を起動でき、静的 SPA と /api/... を同じ backend から serve できる。
  • SvelteKit static SPA skeleton が monorepo 内に追加されている。
  • frontend build artifact の扱いが Nix/package build で破綻しない。
  • 初期 read API が少なくとも workspace/ticket/objective の bounded JSON を返す。
  • existing local .yoi record workflow を壊さない。
  • cargo fmt --check、関連 cargo test / cargo check、frontend の build/check、git diff --check、yoi ticket doctor、yoi objective doctor、nix build .#yoi --no-link が通る。