docs: design workspace db schema v0

This commit is contained in:
Keisuke Hirata 2026-06-22 17:48:37 +09:00
parent 520209f38c
commit c6ddff159f
No known key found for this signature in database
6 changed files with 695 additions and 2 deletions

View File

@ -2,7 +2,7 @@
title: "Team workspace control plane and runner architecture"
state: "active"
created_at: "2026-06-20T14:26:29Z"
updated_at: "2026-06-21T06:57:06Z"
updated_at: "2026-06-21T18:10:00Z"
linked_tickets: ["00001KVMFFYVX"]
---
@ -175,6 +175,10 @@ Web UI は Ticket、Objective、Memory、Knowledge、Run、Runner、Artifact を
Cloud/remote execution を成立させるには、多数のエージェント実行を安く管理できる必要がある。logical agent session と runtime process/resource placement を分ける。
初期 Workspace DB では、Worker を canonical table として永続化しない。Host / Worker 一覧は backend-local runtime inspection や将来の Host protocol から逐次取得する live view とし、Ticket に関わった Worker は Ticket thread events と WorkerRef snapshot / TicketWorkerLink として記録する。
Worker の一元管理、データ永続化、アーカイブは将来的には必要になる。これは Host protocol、remote/self-hosted/hosted worker lifecycle、worker identity、retention policy、audit requirements が固まった後に、dedicated Worker registry / archive model として追加する。v0 で Pod metadata の代替として Worker table を作らない。
検討対象:
- Agent identity と process/runtime placement の分離。
@ -241,4 +245,5 @@ Cloud/remote execution を成立させるには、多数のエージェント実
- Web frontend を最初の primary team UI とする。Desktop app は web/control-plane model が安定した後に検討する。
- Git は重要な Repository provider / materialization backend として使うが、Workspace identity と authority を Git Repository root に固定しない。
- Ticket と Objective は Workspace 配下に平たく持つ。対象コードベースや ref は Repository target selector として表現し、Run が concrete RepositoryPoint に解決する。
- Memory の本格再設計は後回しにする。先に Workspace / Ticket / Run / Repository / Runner / Control plane の基盤を固め、Memory の保存先を Workspace backend に移すタイミングで、意味論・抽出・承認・検索・staleness 処理をまとめて回収する。
- Memory の本格再設計は後回しにする。先に Workspace / Ticket / Repository / Host/Worker live view / Control plane の基盤を固め、Memory の保存先を Workspace backend に移すタイミングで、意味論・抽出・承認・検索・staleness 処理をまとめて回収する。
- Worker の一元管理・データ永続化・アーカイブも後続設計に回す。初期 DB では Worker を Pod metadata の代替として永続化せず、live view と Ticket-linked WorkerRef 記録に留める。

View File

@ -0,0 +1,21 @@
{
"version": 1,
"relations": [
{
"ticket_id": "00001KVNKD56W",
"kind": "related",
"target": "00001KVMFFYVX",
"note": "Defines canonical DB model for workspace web control plane",
"author": "yoi ticket",
"at": "2026-06-21T17:25:34Z"
},
{
"ticket_id": "00001KVNKD56W",
"kind": "related",
"target": "00001KVNEKH9Q",
"note": "Host/Worker naming and local execution state should align with canonical DB schema",
"author": "yoi ticket",
"at": "2026-06-21T17:25:34Z"
}
]
}

View File

@ -0,0 +1,514 @@
# Workspace DB canonical schema v0 design
## Purpose
This document defines the first concrete Workspace control-plane schema target. It is precise enough that implementation work can create migrations and API read/write surfaces without inventing meanings ad hoc.
The important corrections in this version are:
- **Ticket thread/events remain the execution history authority**.
- A separate top-level `Run` entity is not part of v0.
- Separate `validation_results` / CI tables are not part of v0.
- Worker is not a DB-canonical entity in v0. Worker state is obtained from runtime inspection / Host protocol as a live view.
- Ticket-to-Worker management is represented by typed WorkerRef snapshots on Ticket events and Ticket-Worker association records.
- v0 does **not** use generic JSON payload/metadata columns. If a value matters, give it a typed column or a small relation table. If it is large evidence, store it as an Artifact.
## Schema categories
1. **Current-state records**: long-lived records with stable ids and current snapshots, such as Ticket, Objective, Repository, Artifact.
2. **Event logs**: append-oriented records attached to current-state records, primarily `ticket_events` and `audit_events`.
3. **Relationship records**: explicit links such as Ticket-to-WorkerRef, Ticket-to-Repository target, Objective-to-Ticket.
4. **Snapshot references**: typed authorship / worker / host references embedded in event or relation records. These are not full entities in v0.
5. **Live views**: API results produced by inspecting local runtime or future Host protocol state. Host/Worker lists are live views in v0, not canonical DB tables.
All main tables include `workspace_id`. v0 is SQLite-first, but table shapes should not prevent later Postgres/multi-workspace hosting.
## Design rules
- Ticket and Objective belong to Workspace, not to Repository.
- Repository is a Workspace-connected source/storage. Git Repository is one provider, not the definition of Repository.
- Ticket target selectors are mutable intent/scope. Evidence artifacts may record the concrete repository revision they were produced from with typed source fields.
- Ticket thread is the human-readable and structured execution/audit history for work on that Ticket.
- Ticket current state is a snapshot derived/maintained from structured state transition events.
- Worker is a logical agent/session participating in work, but Worker registry/persistence is out of v0 DB scope.
- Host is an execution environment or observed placement. In v0, Host/Worker information is returned as a live view from local runtime inspection or future Host protocol, not stored as canonical DB records.
- Ticket-associated Worker management uses WorkerRef fields and `ticket_worker_links` snapshots. This lets the Ticket be managed without making the Worker itself DB-canonical.
- Orchestrator should be able to operate from DB/API records only: Ticket, TicketEvents, TicketWorkerLinks, live Host/Worker views, Artifact, and review/evidence summaries.
- Raw fs/Bash/Git authority belongs to Host/Worker execution, not to Orchestrator.
- Memory/Knowledge are intentionally out of v0 canonical schema. They are deferred until Workspace storage migration for Memory.
- Event authorship is mandatory, but a full Actor table is not required in v0.
- Generic JSON columns are intentionally excluded in v0. Do not add `metadata_json`, `payload_json`, `diagnostics_json`, or similar catch-all fields.
## Common columns and conventions
### IDs
Use opaque string ids allocated by the control plane for DB-canonical records.
Recommended prefixes are implementation detail, but the type must be obvious from column names:
- `workspace_id`
- `ticket_id`
- `event_id`
- `objective_id`
- `repository_id`
- `target_id`
- `artifact_id`
- `audit_event_id`
Worker and Host references use `*_ref_kind` / `*_ref_key` in v0 because they are not canonical DB entities.
### Timestamps
Store UTC timestamps as RFC3339 strings in SQLite v0.
Common names:
- `created_at`
- `updated_at`
- `observed_at`
- `started_at`
- `finished_at`
- `closed_at`
- `last_seen_at`
### No catch-all payload columns
v0 avoids generic JSON/text payload columns because they make the schema ambiguous and move authority into untyped blobs.
Rules:
- Fields used for lifecycle transitions, permissions, joins, filtering, or orchestration decisions must be typed columns or relation tables.
- Event kinds may have nullable typed columns such as `subject_kind`, `subject_id`, `previous_state`, `new_state`, `status`, `activity_id`, or `artifact_id`.
- Repository capabilities are derived from `repositories.kind` / `repositories.provider` and backend configuration in v0; do not add a separate capability table until provider-specific overrides are actually needed.
- Paths use relation tables such as `ticket_target_paths`.
- Diagnostics that matter should be Ticket events or Artifacts.
- Large logs, diffs, transcripts, prompts, raw tool outputs, and file contents must not be embedded in records. Store them in an artifact file/blob store and link through Artifact URI records.
- Secrets are never stored in this schema. Secret references, if needed, use typed reference columns such as `auth_ref_kind` and `auth_ref_key`.
## Authorship fields v0
Authorship is an embedded typed snapshot, not a full table in v0.
Use the following columns on event/request/audit records that need authorship:
```text
author_kind text not null
author_key text not null
author_display text not null
author_source_kind text null
author_source_key text null
```
`author_kind` allowed values:
- `human`
- `agent`
- `system`
- `integration`
- `unknown`
`author_key` is stable within its source namespace, for example:
- `local-user`
- `agent:orchestrator`
- `worker:<worker_ref_key>`
- `system:yoi-control-plane`
- `integration:ci:<provider>`
`author_display` is a display snapshot at event creation time. It must be sufficient for historical display even if a future Actor/User record changes name.
`author_source_kind` and `author_source_key` can point to bounded source context such as `worker`, `profile`, `external_account`, or `provider`. They must not hold secrets.
A future `actors` table may be added for auth, assignment, team membership, and permissions. v0 must not require it. If it is added later, historical events still keep their authorship snapshot and may optionally link to `actor_id`.
## WorkerRef and HostRef v0
Worker and Host are runtime concepts in v0. They are referenced by typed snapshots instead of DB foreign keys.
Use WorkerRef fields where a Ticket event, Ticket association, artifact, or check report needs to identify a Worker:
```text
worker_ref_kind text null -- local_pod | remote_worker | hosted_worker | external | unknown
worker_ref_key text null
worker_display text null
```
Examples:
- `worker_ref_kind = local_pod`, `worker_ref_key = coder-sidebar`, `worker_display = Coder sidebar`
- `worker_ref_kind = hosted_worker`, `worker_ref_key = worker_...`, `worker_display = Hosted coder`
Use HostRef fields only when observed placement matters:
```text
host_ref_kind text null -- local | self_hosted | cloud | external | unknown
host_ref_key text null
host_display text null
```
HostRef is not ownership. It means “this Worker or event was observed on this execution environment at this time”.
Future work may add canonical `workers`, `hosts`, `worker_archive`, and `host_connections` tables when Worker lifecycle, persistence, and archive requirements are concrete. v0 deliberately does not create those tables.
## Execution model without a Run entity
v0 does not create a separate `runs` table.
A concrete execution attempt is represented by:
- a `ticket_event` such as `execution_requested`, `worker_assigned`, `worker_status`, `implementation_report`, `review`, `check_report`, `artifact_link`, or `state_transition`;
- optional `activity_id` on related `ticket_events` to group a burst of execution activity;
- `ticket_worker_links` records showing which WorkerRefs are associated with the Ticket and in what role/status;
- `artifacts` linked to `ticket_id`, `event_id`, optional WorkerRef fields, and optional typed repository source revision fields.
`activity_id` is a correlation key, not an authority entity. It can be generated when a user/Orchestrator accepts an execution request, but the Ticket thread remains the authority.
This avoids duplicating Ticket events and Run records while preserving machine-readable execution state.
## Live Host/Worker API view
v0 API may expose Host and Worker lists, but they are live views, not DB tables.
Examples:
- `GET /api/hosts` may inspect the backend-local machine and return one synthetic local Host.
- `GET /api/workers` may scan current local Pod metadata and sockets and return Worker summaries.
- Future Host protocol can provide the same API shape from heartbeat/connection state.
These API responses must not imply DB persistence. If a Worker disappears from runtime inspection, it can disappear from the live view. Durable history belongs to Ticket events, TicketWorkerLinks, and Artifacts.
## Tables
### `workspaces`
```text
workspace_id text primary key
display_name text not null
state text not null -- active | archived
created_at text not null
updated_at text not null
```
### `tickets`
Current Ticket state and body snapshot.
```text
workspace_id text not null
ticket_id text primary key
title text not null
state text not null -- planning | ready | queued | inprogress | done | closed
priority text null
assignee_kind text null
assignee_key text null
assignee_display text null
body_md text not null
created_at text not null
updated_at text not null
closed_at text null
resolution_event_id text null
```
Notes:
- `tickets` stores the current read model.
- Historical changes belong to `ticket_events`.
- Ticket state transitions must be represented by structured `ticket_events`.
- Assignee is a snapshot, not a foreign key to `actors` in v0.
### `ticket_events`
Append-oriented Ticket thread/event log. This is also the execution history authority for work on a Ticket.
```text
workspace_id text not null
event_id text primary key
ticket_id text not null
event_seq integer not null
kind text not null
activity_id text null
author_kind text not null
author_key text not null
author_display text not null
author_source_kind text null
author_source_key text null
created_at text not null
body_md text null
subject_kind text null -- ticket | worker | artifact | check | repository | objective | system
subject_id text null
previous_state text null
new_state text null
status text null
artifact_id text null
worker_ref_kind text null
worker_ref_key text null
worker_display text null
host_ref_kind text null
host_ref_key text null
host_display text null
repository_id text null
caused_by_event_id text null
```
`kind` allowed values in v0:
- `comment`
- `plan`
- `decision`
- `review`
- `implementation_report`
- `state_transition`
- `close`
- `execution_requested`
- `worker_assigned`
- `worker_status`
- `check_report`
- `artifact_link`
- `system_note`
Constraints:
- unique `(ticket_id, event_seq)`.
- events are append-only except administrative repair migrations.
- state transitions and close events must include `previous_state` and `new_state` where applicable.
- execution events should use typed columns such as `activity_id`, WorkerRef fields, `artifact_id`, and `repository_id` instead of opaque payloads.
### `ticket_relations`
```text
workspace_id text not null
source_ticket_id text not null
target_ticket_id text not null
kind text not null -- depends_on | blocks | related | supersedes | duplicate_of
created_at text not null
author_kind text not null
author_key text not null
author_display text not null
author_source_kind text null
author_source_key text null
note text null
primary key (source_ticket_id, target_ticket_id, kind)
```
### `objectives`
```text
workspace_id text not null
objective_id text primary key
title text not null
state text not null -- active | paused | done | closed | archived
body_md text not null
created_at text not null
updated_at text not null
```
### `objective_ticket_links`
```text
workspace_id text not null
objective_id text not null
ticket_id text not null
kind text not null -- tracks | related | milestone | blocker
created_at text not null
primary key (objective_id, ticket_id, kind)
```
### `repositories`
Workspace-connected source/storage. Git is one provider.
```text
workspace_id text not null
repository_id text primary key
name text not null
kind text not null -- git | local | object_store | artifact_store | custom
provider text null -- git, local_fs, s3, etc.
uri text not null
default_ref text null
auth_ref_kind text null
auth_ref_key text null
created_at text not null
updated_at text not null
```
Notes:
- `uri` is identity/config data. It may be redacted in API responses.
- `auth_ref_kind` / `auth_ref_key` contain secret references only, never secret values.
- v0 does not store per-Repository capability rows. Capabilities are derived from `kind`, `provider`, and backend configuration. Add explicit capability/override records later only if a real provider needs per-Repository variance.
### `ticket_targets`
Ticket scope/intent against one or more Repositories.
```text
workspace_id text not null
ticket_id text not null
target_id text not null
repository_id text not null
role text not null -- primary | related | reference | check | output
intent text not null -- read | change | check | output
ref_selector text null
created_at text not null
updated_at text not null
primary key (ticket_id, target_id)
```
### `ticket_target_paths`
```text
workspace_id text not null
ticket_id text not null
target_id text not null
path text not null
primary key (ticket_id, target_id, path)
```
### `ticket_worker_links`
Current relationship between Ticket and a WorkerRef.
```text
workspace_id text not null
ticket_id text not null
worker_ref_kind text not null
worker_ref_key text not null
worker_display text null
role text not null -- companion | intake | orchestrator | coder | reviewer | validator | custom
status text not null -- requested | assigned | active | blocked | completed | released | failed | cancelled
activity_id text null
assigned_at text null
released_at text null
last_event_id text null
primary key (ticket_id, worker_ref_kind, worker_ref_key, role)
```
Notes:
- This is the main DB management relation for Ticket-associated Workers.
- It is not a Worker registry.
- Ticket thread events should record assignment/release/status changes.
### `artifacts`
Evidence/output linked to Ticket, Objective, event, WorkerRef, or Repository source revision.
Artifact content is not stored inline in the DB. Every Artifact points to a URI. The URI may be served by the Workspace backend's artifact/static-file service, a blob store, or an external system.
```text
workspace_id text not null
artifact_id text primary key
kind text not null -- diff | patch | log | report | check_report | review | file | external_link | summary
uri text not null
media_type text null
sha256 text null
size_bytes integer null
summary text null
created_at text not null
created_by_kind text not null
created_by_key text not null
created_by_display text not null
created_by_source_kind text null
created_by_source_key text null
ticket_id text null
objective_id text null
event_id text null
worker_ref_kind text null
worker_ref_key text null
worker_display text null
repository_id text null
source_kind text null -- git_commit | file_snapshot | object_version | custom
source_revision text null -- commit hash, snapshot id, or object version id
```
Rules:
- `uri` is mandatory.
- DB rows store metadata and summary only, never artifact body content.
- `source_kind` / `source_revision` are optional typed source fields for artifacts produced against a concrete repository revision. They do not represent branch/ref selectors; mutable selectors remain on `ticket_targets.ref_selector` or in the related Ticket event.
- Workspace-owned artifact content should use a stable internal URI scheme or backend-served URL, for example `artifact://<workspace_id>/<artifact_id>` or `/api/artifacts/<artifact_id>/content`.
- External artifacts may use redacted `https://...` or provider-specific URIs when policy allows.
- API list/detail responses return artifact metadata and URI by default. Fetching content is a separate artifact-content operation with bounds and permission checks.
## CI / actions-like checks are future work
v0 does not add `validation_results`, `ci_results`, or action tables.
For now, local checks, CI summaries, and check evidence are represented by:
- `ticket_events.kind = check_report` or `artifact_link`;
- Artifacts such as logs, check reports, or external CI URLs;
- Ticket state transitions or review events that reference those artifacts.
If first-class CI status is needed, design it as a separate actions-like subsystem rather than a generic validation table inside the core Ticket schema. That future subsystem should model workflow/check names, jobs, steps, attempts, statuses, logs, annotations, external provider ids, retention, and rerun semantics explicitly.
### `audit_events`
Control-plane operation audit trail.
```text
workspace_id text not null
audit_event_id text primary key
created_at text not null
actor_kind text not null
actor_key text not null
actor_display text not null
actor_source_kind text null
actor_source_key text null
action text not null
target_kind text not null
target_id text null
outcome text not null -- allowed | denied | succeeded | failed
request_id text null
summary text null
```
Audit events record the control-plane action and outcome. They should not duplicate full Ticket event payloads unless needed for audit.
## Read surfaces for Orchestrator without fs/Bash
The DB/API must let an Orchestrator read:
- Ticket current state, thread events, relations, targets, and TicketWorkerLinks.
- Objective body and linked Tickets.
- Repository summaries, Ticket target selectors, and Artifact source revision fields.
- Live Host/Worker views from runtime inspection or future Host protocol.
- Artifact summaries and selected artifact contents through bounded artifact APIs.
- Check/CI summaries as TicketEvents and Artifacts.
- Review evidence as TicketEvents/Artifacts.
## Write surfaces for Orchestrator without fs/Bash
The DB/API must let an Orchestrator create:
- Ticket comments/decisions/state transition requests.
- Ticket execution request events with target selectors and optional `activity_id`.
- TicketWorkerLink assignment/release/status changes.
- Review/check request events.
- Artifact links for logs, reports, diffs, CI/external check URLs, and review evidence.
- Close/done decisions that reference evidence artifacts and structured Ticket events.
The Orchestrator must not need raw repository filesystem reads, shell execution, or direct Git merge authority to perform control-plane routing.
## Migration stance
v0 implementation should support three modes conceptually:
1. `filesystem_read_through`: current `.yoi/tickets` and `.yoi/objectives` remain authority; DB holds runtime/projection tables.
2. `imported_projection`: filesystem records are imported into DB read models, but filesystem remains the write authority.
3. `db_authority`: Ticket/Objective write path moves to DB; filesystem export becomes compatibility/export snapshot.
This Ticket designs the schema target and can implement non-breaking migrations, but it does not require switching active authority to DB.
## Minimal implementation guidance
If implementation is included in this Ticket, prefer a small non-breaking migration:
- Keep Host/Worker API as live runtime views in v0.
- Add explicit schema versioning.
- Add tables that are safe to create empty: `repositories`, `ticket_targets`, `ticket_target_paths`, `ticket_worker_links`, `artifacts`, `audit_events`.
- Keep existing filesystem read APIs working.
- Do not create a full `actors` table in v0.
- Do not create `hosts` / `workers` canonical tables in v0.
- Do not create a separate `runs` table in v0; use structured Ticket events and TicketWorkerLink relationships.

View File

@ -0,0 +1,129 @@
---
title: 'Workspace DB canonical schema design'
state: 'ready'
created_at: '2026-06-21T17:24:43Z'
updated_at: '2026-06-21T18:10:00Z'
assignee: null
---
## 背景
Workspace web control plane は、Rust backend / SQLite store / static SPA / read-only filesystem bridge まで立ち上がっている。ただし現在の SQLite schema は起動・API skeleton 用の足場であり、Ticket / Objective / Repository / Host / Worker / Artifact を将来 DB 正本にするための canonical schema はまだ固まっていない。
DB 設計は過度に難しく扱わず、まずは既存 filesystem Ticket/Objective model と現在の orchestration 運用を素直に relational/event model へ写す。重要なのは、`.yoi` filesystem record をすぐ捨てることではなく、Web/API/Orchestrator が将来 DB authority に移れるだけの record 境界を決めること。
長期方針:
- Ticket / Objective は Workspace 配下に平たく存在する。
- Repository は Workspace に接続される source/storage であり、Git Repository はその一種。
- Ticket は必要に応じて Repository target selector を持つ。
- Ticket thread/events が実行履歴の authority であり、Ticket state は current snapshot として持つ。
- Worker は Ticket に関連づく logical agent/session だが、v0 では DB 正本として永続化しない。Host/Worker 一覧は runtime inspection / future Host protocol から逐次取得する live view とする。
- Worker の一元管理、データ永続化、アーカイブは将来必要になるが、Host/Worker protocol と lifecycle requirements が固まるまで v0 schema には入れない。
- Host は Worker が観測される実行環境または capacity を表すが、v0 では canonical table ではなく live view とする。
- CI/check information should be represented as Ticket events plus Artifact links in v0. If richer CI status is needed, design it later as a separate actions-like subsystem rather than a generic validation table.
- Orchestrator は将来的に fs/Bash/Git を直接持たず、Ticket / TicketEvent / TicketWorkerLink / live Host/Worker view / Artifact / Review の DB/API surface だけを見る。
- Memory / Knowledge の本格再設計はこの Ticket では扱わず、保存先を Workspace backend へ移す時に回収する。
## 要件
### Canonical records / tables
DB design は `artifacts/schema-v0.md` を主たる設計記録とする。Ticket 本文では scope と要求だけを示す。
`schema-v0.md` では以下を明確に定義する。
- record / event / reference の区別。
- ID / timestamp / no-catch-all-payload column conventions。
- `AuthorRef` v0。
- event author/source を記録する typed snapshot。
- 初期実装では full `actors` table を必須にしない。
- auth / permission / assignment / team membership が必要になった時点で `actors` table へ昇格できる。
- table candidates and required columns:
- `workspaces`
- `tickets`
- `ticket_events`
- `ticket_relations`
- `objectives`
- `objective_ticket_links`
- `repositories`
- `ticket_targets`
- `ticket_target_paths`
- `ticket_worker_links`
- `artifacts`
- `audit_events`
- Orchestrator no-fs/no-bash の read/write surfaces。
- filesystem read-through から DB authority への migration modes。
初期設計で曖昧な `actors` entity を置かない。必要なのは event authorship であり、v0 では `AuthorRef` fields として扱う。
### Authority / migration stance
- 当面は `.yoi/tickets` / `.yoi/objectives` filesystem read-through を維持する。
- DB schema は canonical target として設計するが、この Ticket だけで full migration はしない。
- import/projection/export の方針を決める。
- filesystem -> DB import。
- DB -> filesystem export / compatibility snapshot。
- read-through bridge と DB authority の切り替え条件。
- 二重正本を避けるため、write path をいつ DB に切り替えるかを明記する。
- SQLite first でよいが、将来 Postgres/multi-tenant へ進めるよう、`workspace_id` を全主要 record に含める。
### Orchestrator no-fs/no-bash surface
DB/API だけを見て Orchestrator が判断できるように、以下の read/write surface を設計する。
Orchestrator が読むもの:
- Ticket state/thread/relations/targets。
- Ticket-associated WorkerRef links and worker status events。
- Objective context。
- Live Host/Worker view from runtime inspection or future Host protocol。
- Repository target and artifact source revision fields。
- Artifact summaries/diff metadata/log summaries。
- Review evidence。
Orchestrator が作るもの:
- Ticket comment/decision/state transition request。
- Ticket execution request / WorkerRef assignment / worker status events。
- Worker job request / assignment request。
- Review/check request。
- Close/done decision with evidence references。
fs/Bash/Git 操作は Host/Worker に閉じ込める。Orchestrator は raw repository filesystem や shell access を authority として持たない。
### Initial implementation slice
この Ticket は design-only でもよいが、可能なら最小 schema migration まで含める。
- `crates/workspace-server` の SQLite schema を canonical design に合わせて整理する。
- 既存 placeholder `runs` / `runners` naming を、structured ticket events / live Host/Worker API / `ticket_worker_links` へ寄せる。
- Migration versioning の方針を明記する。
- Existing read API を壊さない。
## Non-goals
- Full DB migration of existing `.yoi/tickets` / `.yoi/objectives`
- Web UI からの Ticket/Objective mutation 実装。
- Memory / Knowledge の本格再設計。
- Multi-tenant production SaaS schema の完全設計。
- Auth/billing/quota/security の完全実装。
- Git hosting service の実装。
- Orchestrator profile から fs/Bash を実際に剥がすこと。
## 受け入れ条件
- Workspace DB canonical schema design が `artifacts/schema-v0.md` または同等の design record として記録されている。
- `schema-v0.md` が record / event / reference の区別を定義している。
- Table/record 境界として Workspace / Ticket / TicketEvent / TicketRelation / Objective / ObjectiveTicketLink / Repository / TicketTarget / TicketTargetPath / TicketWorkerLink / Artifact / AuditEvent が定義されている。
- Separate top-level Run entity/table を v0 では作らず、structured Ticket events と TicketWorkerLink relation を execution history/management surface とする方針が明記されている。
- Host/Worker は v0 DB canonical table ではなく live runtime view とし、Ticket には WorkerRef snapshot/link を保存する方針が明記されている。
- Event/request/audit authorship は `AuthorRef` v0 として required fields まで定義されている。
- 初期実装で full Actor entity/table を必須にしない方針と、将来 actors table へ昇格できる条件が明記されている。
- CI/check status は v0 core schema では Ticket events + Artifact links として扱い、actions-like subsystem は future work とする方針が明記されている。
- `.yoi` filesystem read-through から DB authority へ移る migration/export/import 方針が明記されている。
- Orchestrator no-fs/no-bash を可能にする DB/API read/write surface が明記されている。
- Memory / Knowledge は deferred として扱われ、この schema design の必須 scope から外れている。
- SQLite first だが、全主要 record に `workspace_id` を持たせる方針が明記されている。
- 既存 `runner` placeholder naming を Host/Worker に移す方針が明記されている。
- 実装まで含める場合は `cargo fmt --check`、`cargo test -p yoi-workspace-server`、`cargo check`、`git diff --check`、`yoi ticket doctor`、`nix build .#yoi --no-link` が通る。

View File

@ -0,0 +1,24 @@
<!-- event: create author: "yoi ticket" at: 2026-06-21T17:24:43Z -->
## 作成
LocalTicketBackend によって作成されました。
---
<!-- event: intake_summary author: hare at: 2026-06-21T17:25:35Z -->
## Intake summary
Marked ready by `yoi ticket state`.
---
<!-- event: state_changed author: "yoi ticket" at: 2026-06-21T17:25:35Z from: planning to: ready reason: cli_state field: state -->
## State changed
Marked ready by `yoi ticket state`.
---