## 作成 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 Reason: - Ticket は Workspace Browser route/API を immutable workspace id で scope する具体的な URL/API contract、acceptance criteria、非目標を明記している。 - 1 Backend = 1 Workspace の現状でも request path の `workspace-id` と Backend current `workspace_id` を照合するという authority boundary が明確。 - Runtime `/v1/...` API とは混同しないこと、multi-workspace DB migration / slug / admin UI は非目標であることが明確。 - typed relation blocker は 0 件、OrchestrationPlan record は 0 件。 - queued notification は human authorized routing であり、今回の routing acceptance 後にのみ implementation side effect へ進める。 Evidence checked: - Ticket body / thread / artifacts。 - `TicketRelationQuery(00001KWWE8E04)`: 0 件。 - `TicketOrchestrationPlanQuery(00001KWWE8E04)`: 0 件。 - Orchestrator worktree git status: clean on `orchestration`。 - queued Ticket 一覧: この Ticket 1件のみ。inprogress は 0 件。 - visible Pods: previous execution-workspace child Pods が idle で残っているが、`StopPod` 不使用方針のため停止せず、新規 unique Pod を使う。capacity blocker ではない。 - `TicketDoctor`: 0 errors / 既存 diagnostics のみ。 - Bounded code map: `crates/workspace-server/src/{identity.rs,server.rs,hosts.rs,config.rs,records.rs,repositories.rs}`, `web/workspace/src/routes/**`, `web/workspace/src/lib/workspace-sidebar/**`, workspace settings/sidebar/console helpers。 IntentPacket: Intent: - Workspace Browser の canonical UI route を `/w//...` に移し、Frontend が Browser-facing API を `/api/w//...` 経由で呼ぶようにする。 - 1 Backend = 1 Workspace の現状でも、path workspace id と serving workspace id を照合し、mismatch を typed sanitized diagnostic として fail closed する。 Binding decisions / invariants: - Workspace URL は slug/renameable handle ではなく immutable `workspace_id` を使う。 - canonical route prefix は短い `/w//...`。 - Browser-facing scoped API prefix は `/api/w//...`。 - Runtime API `/v1/runtime`, `/v1/workers` はこの Ticket の scope 外であり、workspace id segment を追加しない。 - Backend canonical store の multi-workspace DB migration、Workspace slug/alias/rename、global admin UI は非目標。 - 既存 unscoped API/routes は互換 alias / redirect として残してよいが、Frontend の own calls/tests は scoped API/route を期待する。 - workspace id mismatch response は typed sanitized error とし、raw path / internal store / authority-bearing internals を漏らさない。 Requirements / acceptance criteria: - `/w/` が overview を表示する。 - `/w//repositories/` が Repository detail を表示する。 - `/w//objectives` と `/w//objectives/` が動く。 - `/w//settings` が Settings を表示する。 - `/w//runtimes//workers//console` が Worker console を表示する。 - Frontend API calls use `/api/w//...` for workspace/repositories/objectives/workers/settings runtime-connections and relevant worker console endpoints。 - Sidebar/settings/repository/objectives/worker-console links include workspace id。 - mismatched workspace id returns typed 404 or equivalent mismatch diagnostic。 - Focused backend/web tests cover scoped API, mismatch, and frontend scoped API/link construction。 Implementation latitude: - Route grouping/layout structure, helper naming, redirect vs compatibility route choice, and scoped API client abstraction can follow current SvelteKit/backend style。 - Existing unscoped API can remain as compatibility alias if scoped variants are canonical for frontend use。 - A small workspace route helper/client module is acceptable to avoid string duplication。 - Tests may cover helper/model/API routing rather than full browser E2E, consistent with current project constraints。 Escalate if: - Multi-workspace DB/store authority must be implemented to satisfy routing。 - Workspace slug/handle/rename/alias becomes necessary。 - Runtime `/v1/...` API needs workspace id path segment。 - Browser-facing mismatch diagnostics require exposing raw internal paths/store/runtime details。 Validation: - `cd web/workspace && deno task check && deno task test` - `cargo test -p yoi-workspace-server` - `cargo check -p yoi` - `git diff --check` - `yoi ticket doctor` - `nix build .#yoi --no-link` は Cargo.lock / dependency / resource packaging / Nix 変更がある場合だけ実行し、未実行なら理由を報告する。 Current code map: - Workspace identity: `crates/workspace-server/src/identity.rs`, config/server setup in `config.rs`, `main.rs`。 - Backend routes/API: `crates/workspace-server/src/server.rs`, host/worker API context in `hosts.rs`, project records in `records.rs`, repository API in `repositories.rs`。 - Frontend routes: `web/workspace/src/routes/+layout.ts`, `+layout.svelte`, `+page.ts`, `+page.svelte`, `routes/repositories/[repositoryId]`, `routes/objectives`, `routes/settings`, `routes/runtimes/[runtimeId]/workers/[workerId]/console`。 - Frontend navigation/API call surfaces: `web/workspace/src/lib/workspace-sidebar/**`, settings model/page, worker console page, repository navigation helpers。 Critical risks / reviewer focus: - Frontend must not keep calling unscoped `/api/...` for workspace-scoped data。 - Links must include the route `workspaceId`; no hardcoded current workspace routes should remain as canonical links。 - Scoped API mismatch must fail closed with sanitized typed diagnostics。 - Runtime `/v1/...` API must remain unchanged。 - Compatibility aliases must not become the frontend canonical path。 - workspace id should be treated as immutable id, not slug/alias。 --- ## State changed Queued acceptance recorded after Workspace Dashboard Queue notification authorized Orchestrator routing. Checked context: - Ticket body / thread / artifacts。 - `TicketRelationQuery(00001KWWE8E04)`: blocking relation 0 件。 - `TicketOrchestrationPlanQuery(00001KWWE8E04)`: prior record 0 件。今回 accepted_plan を記録済み。 - Orchestrator worktree git status: clean on `orchestration`。 - queued Ticket はこの Ticket 1件のみ。inprogress は 0 件。 - visible Pods / TicketDoctor / bounded code map を確認。 Acceptance basis: - concrete missing decision / information は残っていない。 - Ticket の scope は Browser route/API workspace-id scoping に閉じており、multi-workspace DB migration / slug/alias / Runtime `/v1` scope change は非目標として明確。 - side effect はこの `queued -> inprogress` acceptance 後に、worktree-workflow に沿って implementation worktree を作成してから開始する。 ---