product(desktop): capture deferred work in a project-aware Work Board

[liugddx]

English

Parent roadmap: #2469
Related architecture: #2290

Problem

Useful follow-up work is frequently discovered while an Agent is executing a different task:

• a bug is noticed but should not interrupt the current objective;
• a refactor or product idea deserves to be preserved for later;
• a side conversation identifies a concrete action item;
• the user wants to remember work without starting another Session immediately.

Today this context usually remains buried in conversation history, is copied into an external tracker, or distracts the active task. Maka lacks a lightweight bridge between “we noticed this” and “start an auditable Agent task later.”

Product direction

Add a local-first Work Board that can hold deferred work in either:

• a project-scoped board; or
• a global, unassigned Inbox.

A board item is a user-owned work intention, not an Agent execution claim. It may originate from a main conversation, a side conversation, or manual entry. Later, the user can start it as a normal Maka task/Session while preserving its source context.

The intended loop is:

conversation or side chat
  -> capture deferred work
  -> project board / global Inbox
  -> start as a new task
  -> Session execution
  -> link result and evidence back to the item

Important boundary

Do not overload the Session Task Ledger from #2290.

• Session Task Ledger: the model-owned, bounded execution plan inside one Session.
• Work Board: user-owned, cross-Session deferred work and task entry points.

A board item may launch and link to a Session, but it must not be injected into every model turn or silently become part of the active plan. Runtime execution state remains authoritative in existing Session/AgentRun/TaskRun facts.

Proposed v1 experience

Board scopes

• Inbox: project-independent ideas and unclassified work.
• Current project: work associated with the selected Maka project.
• Items can be moved between Inbox and projects.

Minimal states

• Inbox
• Todo
• In progress
• Done

“Waiting”, “blocked”, and “recoverable” should come from a linked active Session projection rather than being manually invented board states.

Capture paths

1. Manual “Add item” from the board.
2. From a main-conversation message or selection.
3. From side chat, for example: “Do not handle this now; add it to the current project todo.”
4. The Agent may propose a board item, but creation requires an explicit user action or unambiguous user instruction. No silent backlog generation.

Start-task path

• “Start task” creates a normal Maka Session in the selected project/workspace.
• The initial task context contains a concise item summary and typed source references, not a blind dump of the full conversation.
• The board item links to the Session and reflects its projected execution state.
• Completing or failing a Session does not automatically falsify user intent; the item presents the linked outcome and lets the user confirm completion or reopen it.

Provenance and review

Each captured item should preserve, when available:

• source Session id;
• source message/side-conversation reference;
• project id or global scope;
• creator (user or Agent suggestion confirmed by user);
• linked execution Session(s);
• result references such as changed files, validation, artifacts, or PRs when later available.

Delivery plan

Phase 0 — contract and authority

• Define the minimal BoardItem contract and lifecycle.
• Decide the local persistence owner and mutation boundary.
• Define typed provenance references and project/global scope.
• Specify how linked Session status is projected without copying Runtime state.
• Add exhaustive contract and migration tests.

Phase 1 — capture and list MVP

• Add a compact Work Board surface in the existing task/workbar area; do not introduce a new top-level module.
• Support global Inbox and current-project filtering.
• Support manual create, rename, move, complete/reopen, and archive.
• Preserve source references for conversation-originated items.
• Cover empty, loading, error, and offline/local persistence states.

Phase 2 — side-conversation capture

• Add an explicit “Add to Work Board” action to side conversations.
• Parse destination only from explicit intent: current project, named project, or Inbox.
• Show a confirmation containing title and destination before/after mutation.
• Keep the active task unchanged.
• Add a real behavior test proving capture does not submit or alter the active Session plan.

Phase 3 — start as task

• Add “Start task” from a board item.
• Create a new Session with the correct project/workspace and concise source context.
• Link the new Session back to the board item.
• Project running/waiting/blocked/recoverable/completed state from existing authorities.
• Add a first-success journey: capture in side chat -> open board -> start task -> finish -> review linked result.

Phase 4 — evidence and refinement

• Link completion evidence and deliverables from the Completion Packet work in roadmap(product): evolve Maka into a durable Agent workspace #2469.
• Add lightweight prioritization and ordering only after the core loop is validated.
• Evaluate whether a column board is useful; begin with a compact list if it better fits the existing workbar.

Acceptance criteria

• A user can capture deferred work without interrupting the active task.
• An item can belong to a project or the global Inbox.
• Side-chat capture preserves a source reference and never silently creates items.
• Capturing an item does not mutate the active Session Task Ledger.
• A board item can start a new normal Maka Session in the correct workspace.
• Linked execution status is projected from existing Runtime authorities, not copied into a second execution-state authority.
• Completion can link to evidence/results and can be reopened by the user.
• Desktop behavior has a real capture-to-completion journey test.
• Local data survives restart and has a safe migration/backup story.

Non-goals

• Building a full replacement for Linear, GitHub Projects, or Jira.
• Team collaboration, cloud sync, assignees, sprints, estimates, or roadmaps in v1.
• Replacing the Session Task Ledger, Plan mode, Automations, or Agent Graph.
• Automatically turning every Agent suggestion into backlog noise.
• Treating manually moved columns as authoritative Runtime execution state.

---

简体中文

中文

父级路线：#2469
相关架构：#2290

问题

Agent 执行一个任务时，经常会发现值得后续处理、但不应该打断当前目标的工作：

• 发现一个 bug，但本次任务不急着修；
• 想到一个重构或产品想法，希望以后再做；
• 侧边栏对话整理出了明确行动项；
• 用户希望先记住问题，而不是立即启动新 Session。

目前这些内容通常埋在历史对话里、被复制到外部工具，或者干扰当前任务。Maka 缺少一座从“发现问题”通往“以后启动一个可审计 Agent 任务”的轻量桥梁。

产品方向

增加一个本地优先的 Work Board / 工作看板，支持：

• 归属于某个项目；
• 或进入不归属项目的全局 Inbox。

看板事项代表用户拥有的工作意图，不是 Agent 对执行状态的声明。它可以来自主对话、侧边栏对话或手工录入，之后再启动为普通 Maka 任务/Session，并保留来源上下文。

目标闭环：

主对话或侧边栏
  -> 捕获暂缓事项
  -> 项目看板 / 全局 Inbox
  -> 启动为新任务
  -> Session 执行
  -> 将结果和证据关联回事项

重要边界

不要复用或扩张 #2290 的 Session Task Ledger：

• Session Task Ledger：模型在单个 Session 内维护的、受预算限制的执行计划。
• Work Board：用户拥有的、跨 Session 的暂缓事项和任务入口。

看板事项可以启动并关联 Session，但不能被注入每轮模型上下文，也不能静默进入当前执行计划。实际运行状态继续由现有 Session、AgentRun、TaskRun 权威事实决定。

v1 体验建议

范围

• Inbox：与项目无关或尚未分类的事项。
• 当前项目：归属于所选 Maka 项目的事项。
• 事项可以在 Inbox 和项目之间移动。

最小状态

• Inbox
• Todo / 待处理
• In progress / 进行中
• Done / 完成

“等待、阻塞、可恢复”等状态应从关联 Session 投影，而不是再造一套手工看板状态。

捕获入口

1. 在看板中手工添加。
2. 从主对话消息或选中文本创建。
3. 从侧边栏对话创建，例如：“这个问题本次先不处理，加入当前项目待办。”
4. Agent 可以建议加入，但只有用户明确操作或明确指令后才能创建，不能静默堆积事项。

启动任务

• “开始任务”在对应项目/工作区创建普通 Maka Session。
• 初始上下文只包含简洁事项摘要和强类型来源引用，不盲目灌入整段历史对话。
• 看板事项关联该 Session，并展示其投影状态。
• Session 完成或失败不应自动篡改用户意图；事项显示关联结果，由用户确认完成或重新打开。

来源与复核

每个事项应尽可能保存：

• 来源 Session id；
• 来源消息或侧边栏对话引用；
• 项目 id 或全局范围；
• 创建者（用户，或经用户确认的 Agent 建议）；
• 关联执行 Session；
• 后续产生的文件变更、验证、Artifact、PR 等结果引用。

交付计划

Phase 0 — 契约与权威

• 定义最小 BoardItem 契约和生命周期。
• 决定本地持久化所有者与写入边界。
• 定义强类型来源引用和项目/全局范围。
• 定义如何投影关联 Session 状态，避免复制 Runtime 状态。
• 增加完整契约和迁移测试。

Phase 1 — 捕获与列表 MVP

• 在现有 task/workbar 区域增加紧凑 Work Board，不新增顶级模块。
• 支持全局 Inbox 与当前项目筛选。
• 支持手工新增、改名、移动、完成/重开和归档。
• 对来自对话的事项保存来源引用。
• 覆盖空、加载、错误和本地离线持久化状态。

Phase 2 — 侧边栏对话捕获

• 在侧边栏对话增加明确的“加入工作看板”操作。
• 只根据明确意图决定当前项目、指定项目或 Inbox。
• 写入前后展示标题和目标位置确认。
• 不改变当前任务。
• 增加真实行为测试，证明捕获不会提交消息或修改当前 Session 计划。

Phase 3 — 启动为任务

• 为看板事项提供“开始任务”。
• 在正确项目/工作区创建新 Session，并注入简洁来源上下文。
• 将新 Session 关联回看板事项。
• 从现有权威投影运行、等待、阻塞、可恢复和完成状态。
• 增加首次成功旅程：侧边栏捕获 -> 打开看板 -> 启动任务 -> 完成 -> 查看关联结果。

Phase 4 — 证据与体验完善

• 接入 roadmap(product): evolve Maka into a durable Agent workspace #2469 后续 Completion Packet 的完成证据与交付物。
• 核心闭环验证后再增加轻量优先级和排序。
• 验证列式看板是否真的需要；若紧凑列表更适合现有 workbar，则先使用列表。

验收标准

• 用户可以记录暂缓工作，不打断当前任务。
• 事项可以属于某个项目，也可以进入全局 Inbox。
• 侧边栏捕获保留来源引用，且不会静默创建事项。
• 捕获事项不会修改当前 Session Task Ledger。
• 看板事项可以在正确工作区启动为普通 Maka Session。
• 关联执行状态来自现有 Runtime 权威投影，不复制成第二套执行状态。
• 完成事项可以关联结果/证据，也可以由用户重新打开。
• Desktop 有覆盖捕获到完成闭环的真实旅程测试。
• 本地数据重启后仍存在，并具有安全迁移与备份方案。

非目标

• 构建 Linear、GitHub Projects 或 Jira 的完整替代品。
• v1 不做团队协作、云同步、负责人、Sprint、估时或 Roadmap。
• 不替代 Session Task Ledger、Plan mode、Automation 或 Agent Graph。
• 不把 Agent 每个建议自动变成待办噪音。
• 不把手工移动的列当成 Runtime 执行状态权威。

[somewan820]

Hi, I'd like to take Phase 0 of this issue.

I'm also the assignee of #2290 (Session Task Ledger), so I want to state the boundary explicitly: Phase 0 would define the BoardItem contract and persistence ownership without depending on the Session Task Ledger. That means:

• no task_* tools;
• no task.ledger.query;
• no reads/writes to workflow_task_ledger_* tables;
• linked Session status projected from Session / AgentRun / RuntimeEvent / Agent Graph authorities;
• under the Option 2 proposal in RFC: Radically slim the Session Task Ledger #2290, "start as task" would create a normal Session and may seed a minimal Todo snapshot. That behavior is not final until the RFC: Radically slim the Session Task Ledger #2290 and product(desktop): capture deferred work in a project-aware Work Board #2560 contracts are agreed, and Phase 0 does not depend on it.

I'll post the BoardItem contract, provenance model, and state-projection boundary here for review before opening a PR. Could you assign me?

简体中文

你好，我想接手本 issue 的 Phase 0。

我也是 #2290（Session Task Ledger）的 assignee，所以先明确边界：Phase 0 将定义 BoardItem 契约和持久化归属，不依赖 Session Task Ledger。具体包括：

• 不使用 task_* 工具；
• 不使用 task.ledger.query；
• 不读写 workflow_task_ledger_* 表；
• 关联 Session 状态从 Session / AgentRun / RuntimeEvent / Agent Graph 权威投影；
• 按 RFC: Radically slim the Session Task Ledger #2290 的 Option 2 提议，“start as task”会创建普通 Session，并可能注入极简 Todo 快照。该行为在 RFC: Radically slim the Session Task Ledger #2290 与 product(desktop): capture deferred work in a project-aware Work Board #2560 契约达成前不算最终决定，Phase 0 不依赖它。

我会先把 BoardItem 契约、provenance 模型和状态投影边界发在这里评审，再开 PR。能把我 assign 上吗？

[somewan820]

Phase 0 — BoardItem contract, provenance model, and state-projection boundary

This is the Phase 0 review post I promised: define the minimal BoardItem contract and lifecycle, decide the local persistence owner and mutation boundary, define typed provenance references and project/global scope, and specify how linked Session status is projected without copying Runtime state. No PR is opened yet — I'll wait for review convergence (and the current stabilization window) before writing code.

---

1. Repository facts I verified on main

• Session statuses are active / running / waiting_for_user / blocked / review / done / archived / aborted (packages/core/src/session.ts, packages/runtime-host/src/protocol/session-continuity.ts).
• AgentRun statuses are created / running / waiting_for_user / completed / failed / cancelled (packages/core/src/agent-run.ts).
• Projects have a stable catalog identity (ProjectRecord.id) in the operational-state database (packages/storage/src/project-catalog.ts).
• Side chats are temporary forks with a parent Session id and durable message ids; the fork is deleted when the panel closes (docs/side-conversation.md).
• The operational-state database (runtime.sqlite, OPERATIONAL_STATE_DATABASE_NAME) is the shared local authority for session metadata, project catalog, scheduled tasks, task ledger, and related workflow state. createOperationalStateBackup snapshots the whole database, so a new table in that DB is automatically covered by the existing backup/restore story.
• The workflow schema is currently version 8 and uses additive CREATE TABLE IF NOT EXISTS migrations with record_json rows (packages/storage/src/sqlite-workflow-schema.ts).
• The Desktop task panel already follows the pattern I'd reuse: main process owns the store, the renderer reads a projection through IPC, and store changes emit a signal-only change event that makes the renderer reload (docs/session-task-ledger-lifecycle.md).

---

2. BoardItem contract (proposal)

export const WORK_BOARD_ITEM_SCHEMA_VERSION = 1;

// Proposed bounds (numbers are placeholders to verify during P1 rendering):
export const WORK_BOARD_TITLE_MAX_CHARS = 240;
export const WORK_BOARD_NOTES_MAX_CHARS = 4_000;
export const WORK_BOARD_MAX_ITEMS = 1_000;
export const WORK_BOARD_MAX_LINKED_SESSIONS = 16;

export type WorkBoardScope =
  | { kind: 'inbox' }
  | { kind: 'project'; projectId: string };

// User-owned intent state only. "Inbox" is a scope, not a status (Q1 below).
export type WorkBoardItemState = 'todo' | 'in_progress' | 'done';

export type WorkBoardCreator =
  | { kind: 'user' }
  | { kind: 'agent_suggestion'; confirmedAt: number };

export type WorkBoardProvenance =
  | { kind: 'manual' }
  | {
      kind: 'conversation';
      origin: 'main' | 'side_chat';
      sessionId: string;
      parentSessionId?: string; // side_chat only
      messageId: string;
      runId?: string;
      turnId?: string;
      capturedAt: number;
      excerpt: string; // bounded snapshot so the item survives side-chat deletion
    };

export interface WorkBoardLinkedSessionRef {
  sessionId: string;
  linkKind: 'started_task';
  linkedAt: number;
}

// Phase 4 will map Completion Packet deliverables (#2469) into this union.
export type WorkBoardResultRef =
  | { kind: 'runtime_event'; sessionId: string; runId: string; turnId: string; toolCallId?: string }
  | { kind: 'artifact'; sessionId: string; artifactId: string }
  | { kind: 'completion_packet'; sessionId: string; packetRef: string }; // reserved

export interface WorkBoardItem {
  schemaVersion: typeof WORK_BOARD_ITEM_SCHEMA_VERSION;
  id: string; // durable UUID, never rewritten
  scope: WorkBoardScope;
  title: string;
  notes?: string;
  state: WorkBoardItemState;
  archived: boolean;
  archivedAt?: number;
  createdAt: number;
  updatedAt: number;
  creator: WorkBoardCreator;
  provenance: WorkBoardProvenance;
  linkedSessions: WorkBoardLinkedSessionRef[];
  resultRefs: WorkBoardResultRef[];
}

Lifecycle decisions in this proposal:

• scope and state are separate axes. Inbox is a bucket; an Inbox item still has a user state. The board UI may render Inbox as a column, but the contract does not overload "inbox" into a status.

• Allowed state transitions (user-confirmed only):

  todo -> in_progress
  in_progress -> todo        (user reopen/manual)
  in_progress -> done        (user-confirmed completion, never automatic)
  done -> todo | in_progress (reopen)
  

• archived is a logical hide flag, not a state. Storage keeps the row; reads exclude archived items unless explicitly requested. No hard delete in v1 (Q5).

• Scope changes (inbox <-> project) are allowed in any state and do not reset the user state.

• done is user intent, never derived from a Session. Completing or failing a linked Session only updates the projected chip; the user confirms completion or reopens the item.

• No task_* tools, no task.ledger.query, and no workflow_task_ledger_* reads/writes anywhere in this feature.

---

3. Provenance model

• Provenance is a typed union, not free text. Conversation capture stores sessionId, messageId, and (when available) runId / turnId. Side-chat capture also stores parentSessionId.
• A bounded excerpt is snapshotted into the item at capture time. This is what makes a side-chat item survive the temporary fork's deletion; the typed refs are best-effort links, not hard dependencies.
• Manual items have provenance.kind = 'manual'.
• Agent suggestions are not silently created: creator.kind = 'agent_suggestion' requires confirmedAt, and creation only happens through an explicit user action or unambiguous instruction. The board never writes itself.
• resultRefs is part of the contract shape now, but population happens in Phase 3/4. Phase 0 only fixes validation and the union.

---

4. Persistence owner and mutation boundary

Proposal:

• Owner: a new WorkBoardStore in packages/storage, backed by the operational-state database (runtime.sqlite), following the existing record_json pattern.

• Table (additive migration, workflow schema 8 → 9):

  CREATE TABLE IF NOT EXISTS workflow_work_board_items (
    item_id TEXT PRIMARY KEY,
    created_at INTEGER NOT NULL,
    updated_at INTEGER NOT NULL,
    scope_kind TEXT NOT NULL CHECK (scope_kind IN ('inbox', 'project')),
    project_id TEXT,
    record_json TEXT NOT NULL
  );
  
  CREATE INDEX IF NOT EXISTS workflow_work_board_items_scope_order
    ON workflow_work_board_items(scope_kind, project_id, updated_at DESC, item_id);

• Single writer: the Desktop main process. The renderer gets a read-only projection through IPC and reloads on a signal-only change event (same pattern as the task panel). Runtime Host is not involved; there are no model-visible tools; the board is never injected into model context or the turn tail.

• Backup/migration: because the table lives in runtime.sqlite, the existing createOperationalStateBackup covers it without manifest changes. Migration is additive only, no DROP, no data loss; the migration test inventory is updated.

• CLI/TUI can read the same store later through a shared projection, but v1 mutation is Desktop-only (Q8).

---

5. State-projection boundary

The stored item never carries execution state. A linked Session's status is projected at read time from existing authorities:

export interface WorkBoardExecutionProjection {
  sessionId: string;
  sessionStatus: SessionStatus | 'missing';
  latestRunStatus?: AgentRunStatus;
  activeTurnId?: string;
  activeRunId?: string;
  recoveryState?:
    | 'safe_retry'
    | 'safe_continue'
    | 'needs_revalidation'
    | 'unknown_side_effects'
    | 'requires_decision';
  graphState?: {
    graphId: string;
    workId?: string;
    operatorId?: string;
  };
}

• Sources: SessionContinuitySnapshot (session lifecycle), AgentRun headers (latest run), RuntimeEvent (execution facts), and Agent Graph (delegated work) — exactly the authorities listed in RFC: Radically slim the Session Task Ledger #2290's boundary comment.
• This is a pure read projection: it never writes to the board, never copies runtime state into record_json, and never mutates a Session.
• "Waiting / blocked / recoverable" wording in the UI is derived from the projection above, not from a second manually maintained board status.
• The projection is recomputed on each render/load; it is not persisted.

---

6. Phase 0 contract tests (proposed)

• work-board-item.test.ts: decode/validate the item schema; state transition whitelist; scope/provenance invariants; field and array bounds; archive idempotency.
• work-board-store.test.ts: create/rename/move/complete/reopen/archive; persistence across store reopen; filtering by inbox/project and archived; additive migration from schema 8.
• work-board-backup.test.ts: a board item survives createOperationalStateBackup → restore.
• work-board-projection.test.ts: given fixture Session/AgentRun/RuntimeEvent/Graph facts, the projection returns the expected chip without writing anything.

---

7. Open questions for maintainers

1. Inbox: scope or status? I propose scope. The issue lists "Inbox" under minimal states, so I want explicit confirmation before P1.
2. Persistence owner: operational-state database in the Desktop main process — acceptable, or do you want a separate local-first store?
3. Event log vs single current-state table: I propose a single current-state table (no event sourcing for the board; audit remains RuntimeEvent's job). OK?
4. Archive vs delete: I propose archive-only in v1, with no hard delete. OK?
5. resultRefs in Phase 0: keep the union shape now (validated, unused until Phase 3/4), or move it entirely to Phase 4?
6. Projection precedence: when Session continuity and the latest AgentRun disagree (e.g., Session done but last run failed), I propose showing both raw facts without synthesizing a verdict. Agree?
7. Bounds: 240 title chars, 4_000 notes chars, 1_000 items, 16 linked sessions are placeholders — should they be tightened or confirmed during P1?
8. Mutation scope: Desktop-only writer in v1, with CLI/TUI as read-only consumers later. Agree?

Once these converge, I'll open the Phase 0 PR: contract types + validation, additive migration, store, projection tests, and backup test — still without any UI or Runtime Host changes.

简体中文

Phase 0 — BoardItem 契约、来源模型与状态投影边界

这是我在 #2560 里承诺的 Phase 0 评审稿：定义最小 BoardItem 契约与生命周期、确定本地持久化归属和写入边界、定义强类型来源引用与项目/全局范围，并说明如何从现有权威投影关联 Session 状态，而不复制 Runtime 状态。暂不开 PR，等 review 收敛（以及当前稳定化窗口）后再写代码。

已核实的仓库事实

• Session 状态：active / running / waiting_for_user / blocked / review / done / archived / aborted。
• AgentRun 状态：created / running / waiting_for_user / completed / failed / cancelled。
• 项目有稳定 catalog identity（ProjectRecord.id）。
• 侧边栏对话是临时 fork，有父 Session id 和持久 message id，关闭面板时删除。
• runtime.sqlite 是共享本地权威库（session metadata、project catalog、scheduled tasks、task ledger 等都在这里）；现有备份会整体快照该库，因此新表自动纳入备份。
• workflow schema 当前为 v8，采用增量 CREATE TABLE IF NOT EXISTS + record_json 模式。
• Desktop task 面板已采用「主进程持 store、渲染层经 IPC 读投影、变更只发 signal 后重载」的模式，Work Board 直接复用。

BoardItem 契约（提议）

type WorkBoardScope =
  | { kind: 'inbox' }
  | { kind: 'project'; projectId: string };

type WorkBoardItemState = 'todo' | 'in_progress' | 'done';

type WorkBoardCreator =
  | { kind: 'user' }
  | { kind: 'agent_suggestion'; confirmedAt: number };

type WorkBoardProvenance =
  | { kind: 'manual' }
  | {
      kind: 'conversation';
      origin: 'main' | 'side_chat';
      sessionId: string;
      parentSessionId?: string;
      messageId: string;
      runId?: string;
      turnId?: string;
      capturedAt: number;
      excerpt: string; // 有界快照，侧边栏删除后事项仍可读
    };

interface WorkBoardLinkedSessionRef {
  sessionId: string;
  linkKind: 'started_task';
  linkedAt: number;
}

interface WorkBoardItem {
  schemaVersion: 1;
  id: string;
  scope: WorkBoardScope;
  title: string;
  notes?: string;
  state: WorkBoardItemState;
  archived: boolean;
  archivedAt?: number;
  createdAt: number;
  updatedAt: number;
  creator: WorkBoardCreator;
  provenance: WorkBoardProvenance;
  linkedSessions: WorkBoardLinkedSessionRef[];
  resultRefs: WorkBoardResultRef[]; // Phase 4 再填充，Phase 0 只定形状
}

关键决定：

• Inbox 是 scope，不是 status；UI 可以把它渲染成一列，但契约不把「inbox」重载成状态。
• 状态转换只有用户确认：todo -> in_progress、in_progress -> todo/done、done -> todo/in_progress（reopen）。完成态不会由 Session 自动推导。
• archived 是逻辑隐藏标记，v1 不做硬删除。
• 来源是强类型 union，不是自由文本；对话捕获保存 sessionId/messageId（有则含 runId/turnId），侧边栏另存 parentSessionId；同时落一份有界 excerpt 快照。
• Agent 建议必须 confirmedAt 且由用户明确确认，绝不静默创建。
• 全功能不使用 task_* 工具、task.ledger.query，不读写 workflow_task_ledger_*。

持久化归属与写入边界

• 新增 packages/storage 的 WorkBoardStore，落在 runtime.sqlite，沿用 record_json 模式。
• 新表 workflow_work_board_items（item_id PK + created_at/updated_at/scope_kind/project_id/record_json），workflow schema 8 → 9 增量迁移，不 DROP、不删数据。
• 唯一写入方是 Desktop 主进程；渲染层经 IPC 只读投影，变更后重载。Runtime Host 不参与、无模型工具、不注入模型上下文。
• 备份：整库快照自动覆盖，无 manifest 改动。

状态投影边界

• 存储层永不保存执行状态。关联 Session 状态在读取时从 SessionContinuitySnapshot、AgentRun、RuntimeEvent、Agent Graph 纯投影：

interface WorkBoardExecutionProjection {
  sessionId: string;
  sessionStatus: SessionStatus | 'missing';
  latestRunStatus?: AgentRunStatus;
  activeTurnId?: string;
  activeRunId?: string;
  recoveryState?: 'safe_retry' | 'safe_continue' | 'needs_revalidation' | 'unknown_side_effects' | 'requires_decision';
  graphState?: { graphId: string; workId?: string; operatorId?: string };
}

• 投影是纯读操作：不写看板、不复制 Runtime 状态、不改 Session。「等待 / 阻塞 / 可恢复」等 UI 文案全部来自投影，不是第二套手工状态。

Phase 0 测试

• 契约编解码与状态转换白名单；
• store 的增改/移动/完成/重开/归档、重开持久化、过滤、迁移；
• 备份/恢复后事项仍在；
• 投影纯函数测试：给定 Session/AgentRun/RuntimeEvent/Graph 夹具，只返回结果、不产生任何写入。

开放问题

1. Inbox 是 scope 还是 status？（我提议 scope）
2. 持久化放 operational-state DB、由 Desktop 主进程写入，是否可以？
3. 看板用单张当前状态表、不做事件溯源，是否可以？
4. v1 只归档不硬删，是否可以？
5. resultRefs 现在只定形状、Phase 3/4 再填充，还是整体推到 Phase 4？
6. Session 与最新 AgentRun 状态不一致时（如 Session done、run failed），投影同时展示两个原始事实、不做合成结论，是否可以？
7. 各项上限（240 标题 / 4000 备注 / 1000 事项 / 16 关联 Session）是否合理？
8. v1 只允许 Desktop 写入，CLI/TUI 后续只读，是否可以？

以上收敛后我会开 Phase 0 PR：契约类型 + 校验、增量迁移、store、投影测试和备份测试，不含 UI 与 Runtime Host 改动。

---

AI assistance disclosure: Codex helped structure and draft this comment. I reviewed the issue discussion and the repository facts above, and I own the final position.

[liugddx]

Thanks for taking the time to investigate this issue so thoroughly and for writing down the authority boundary before opening a PR. The main direction is sound, especially the separation from the Session Task Ledger, keeping execution state as a projection, using the operational-state database, and requiring explicit user confirmation for agent suggestions.

I would support Phase 0 after the following contract issues are resolved:

1. The 1,000-item limit conflicts with archive-only retention. If archived rows count toward the limit, a user eventually becomes permanently unable to create items. If they do not count, storage remains unbounded. Phase 0 should define whether the limit applies to active items, each scope, or the whole database, and what happens at the limit. My preference is no total-item hard cap in Phase 0: bound page/query size instead, and allow permanent deletion of archived items.

2. The lifecycle should allow todo -> done. A Work Board item represents user intent, not proof of execution. Users should be able to complete an item without first starting a Session or moving it through in_progress. Suggested transitions:

   todo <-> in_progress
   todo -> done
   in_progress -> done
   done -> todo | in_progress
   

3. The execution projection is broader than the stable authority currently exposed. latestRunStatus, the proposed synthetic recoveryState, and graphState are not all directly available from one current canonical projection. Recomputing them from Session, AgentRun, RuntimeEvent, and Agent Graph on every list load also leaves query cost and consistency undefined, particularly with up to 1,000 items and 16 links per item.

   Please keep Phase 0 to facts directly available from the current continuity contract, for example:

   interface WorkBoardLinkedSessionProjection {
     sessionId: string;
     sessionStatus: SessionStatus | 'missing';
     currentTurn?: {
       turnId: string;
       runId: string;
       status: TurnStatus;
     };
   }

   Add recovery or graph-derived fields only after a canonical read interface and an actual UI requirement exist. The board should not invent a second recovery verdict while trying to avoid a second execution authority.

4. Move resultRefs entirely to Phase 4. The proposed union prematurely fixes artifact identity, Completion Packet identity, and RuntimeEvent addressing before their consumers and contracts have converged. A reserved but persisted field is still a compatibility commitment. Adding an optional field in a later schema is safer than guessing the future reference model now.

5. Encode provenance invariants in the type. The current shape permits both a main-conversation provenance with parentSessionId and a side-chat provenance without it. Please split those into distinct discriminated variants so parentSessionId is required only for side_chat.

   Likewise, enforce the archive invariant: active items must not have archivedAt, while archived items must have it. This can be represented as a union or enforced by the decoder.

6. Enforce scope/project consistency in SQLite. The proposed table currently permits an Inbox row with a project id and a project-scoped row without one. Please add a constraint equivalent to:

   CHECK (
     (scope_kind = 'inbox' AND project_id IS NULL)
     OR
     (scope_kind = 'project' AND project_id IS NOT NULL)
   )

   Reads should also reject disagreement between indexed columns and record_json.scope, otherwise they become competing authorities.

7. Define mutation concurrency explicitly. updatedAt is not a revision: multiple changes may occur in the same millisecond, and a stale renderer projection could overwrite newer state. The main process should accept semantic patch commands rather than replacement records, serialize/transactionalize mutations, and preferably expose a monotonic revision or CAS contract. Please include a test proving concurrent rename/move/archive operations do not lose updates.

The following decisions look good and should remain:

• Inbox is a scope, not a status.
• Work Board does not read or write Session Task Ledger state.
• runtime.sqlite owns local persistence.
• A current-state table is sufficient; no event sourcing is needed.
• Desktop main is the v1 mutation owner.
• Runtime state is projected rather than copied into record_json.
• Side-chat capture retains a bounded excerpt.
• Agent suggestions require explicit confirmation.
• Migration, reopen persistence, and backup/restore receive contract tests.

My suggested minimal Phase 0 is therefore: the strict item/provenance contract, SQLite migration and store, semantic mutations with concurrency behavior, paginated queries, archive/delete behavior, backup/restore tests, and only the smallest linked-session projection supported directly by existing authorities. Defer resultRefs, composite recovery/graph projection, and placeholder total-count limits.

Overall, this is a strong proposal with the right architectural boundary, but it should be reduced before implementation so Phase 0 remains genuinely minimal.

中文评审意见

感谢你认真关注并深入调查这个 Issue，也感谢你在开 PR 前先明确权威边界。方案的主方向是正确的，尤其是与 Session Task Ledger 隔离、运行状态只做投影、使用 operational-state 数据库，以及 Agent 建议必须经过用户明确确认。

我建议解决以下契约问题后再认可 Phase 0：

1. 1,000 项上限与只归档不删除冲突。 如果归档项计入上限，用户最终会永久无法创建事项；如果不计入，存储仍然无界。建议 Phase 0 不设总事项硬上限，只限制分页/查询大小，并允许永久删除已归档事项。

2. 生命周期应允许 todo -> done。 Work Board 表达用户意图，不是执行证明。用户应当能够直接完成尚未启动 Session 的事项，不必先经过 in_progress。

3. 执行投影超出了当前稳定权威直接提供的范围。 latestRunStatus、综合 recoveryState 和 graphState 并非来自一个现有规范投影；每次列表加载跨 Session、AgentRun、RuntimeEvent、Agent Graph 重算，也没有定义成本和一致性。Phase 0 应只保留当前 continuity contract 直接提供的 Session 状态和当前 turn/run 事实，恢复或图状态等有规范读取接口和真实 UI 需求后再增加。

4. resultRefs 整体推迟到 Phase 4。 当前 union 提前固定了 Artifact、Completion Packet 和 RuntimeEvent 的引用身份。即使标记为 reserved，只要进入持久化 schema 就成为兼容性承诺。未来按真实契约添加可选字段更安全。

5. 用类型编码 provenance 不变量。 当前类型允许 main conversation 带 parentSessionId，也允许 side chat 缺少它。应拆成两个 discriminated variants。归档状态也应保证 active 时没有 archivedAt，archived 时必须有。

6. SQLite 应约束 scope/project 一致性。 Inbox 必须没有 project_id，project scope 必须有。读取时还应验证索引列与 record_json.scope 一致，避免形成两个冲突的事实源。

7. 明确 mutation 并发契约。 updatedAt 不是 revision，同一毫秒可能发生多次更新，旧 renderer projection 也可能覆盖新状态。主进程应接收语义化 patch command，而不是整个旧 record；mutation 应串行化并置于事务中，最好提供单调 revision 或 CAS，并测试并发 rename/move/archive 不丢更新。

以下决定可以保留：

• Inbox 是 scope，不是 status；
• Work Board 不读写 Session Task Ledger；
• runtime.sqlite 负责本地持久化；
• 使用当前状态表，不做事件溯源；
• Desktop main 是 v1 唯一写入方；
• Runtime 状态只投影，不复制到 record_json；
• side chat 保存有界 excerpt；
• Agent suggestion 必须明确确认；
• 覆盖迁移、重开持久化和备份恢复测试。

建议将 Phase 0 收缩为：严格的 item/provenance 契约、SQLite migration 与 store、具有并发语义的命令式 mutation、分页查询、归档/删除行为、备份恢复测试，以及现有权威直接支持的最小 linked-session projection。推迟 resultRefs、综合 recovery/graph 投影和占位性质的总量上限。

总体而言，这是一份架构边界正确的扎实方案，但实现前还需要继续做减法，确保 Phase 0 真正最小。

[somewan820]

Thanks for the review. I accept all seven points, and I'll narrow Phase 0 accordingly. Revised contract and scope:

1. No total item cap. Only bound page/query size (default 50, max 100). Archived items can be permanently deleted, and deletion requires archiving first.
2. Lifecycle: todo <-> in_progress, todo -> done, in_progress -> done, done -> todo | in_progress. Completion is always user intent and is never derived automatically.
3. Projection stays limited to facts the current continuity contract directly exposes:

interface WorkBoardLinkedSessionProjection {
  sessionId: string;
  sessionStatus: SessionStatus | 'missing';
  currentTurn?: {
    turnId: string;
    runId: string;
    status: TurnStatus;
  };
}

recoveryState / graphState stay out until a canonical read interface and a real UI requirement exist.
4. resultRefs moves entirely to Phase 4. The Phase 0 schema does not contain the field.
5. Provenance becomes three discriminated variants: manual / main_conversation / side_conversation. main_conversation rejects parentSessionId; side_conversation requires it. The archive invariant is enforced both in the type and by the decoder (active items have no archivedAt; archived items must have it).
6. SQLite gains a scope/project CHECK constraint (inbox rows must have project_id IS NULL; project rows must have one). Reads validate that the indexed columns agree with record_json.scope, treating disagreement as corrupt_record.
7. Mutations are semantic patches (independent title / notes / scope / state fields; notes: null clears), never full-record replacement. Writes are serialized and transactional, each item has a monotonic revision, and mutations accept an optional expectedRevision CAS. A concurrency test proves rename/move/archive do not lose updates.

Phase 0 deliverables (no UI, no Runtime Host, no model tools):

• packages/core: BoardItem contract, provenance, lifecycle validation, paginated query;
• packages/storage: additive workflow schema 8→9 migration (workflow_work_board_items + CHECK + index), WorkBoardStore (create / update / archive / unarchive / remove / paginated list + CAS);
• a pure linked-session projection function (read-only, writes nothing);
• tests: contract, migration, reopen persistence, pagination, archive/delete, concurrent CAS, backup/restore, and projection.

Once this converges, I'll open the Phase 0 PR.

简体中文

感谢评审，7 点我都接受，Phase 0 按你的意见收窄。修订后的契约和范围：

1. 不设总量上限，只做分页/查询上限（默认 50、最大 100）；已归档事项允许永久删除，删除前必须已归档。
2. 状态转换：todo <-> in_progress、todo -> done、in_progress -> done、done -> todo | in_progress。完成始终是用户意图，不自动推导。
3. 投影只保留现有 continuity 直接支持的事实：

interface WorkBoardLinkedSessionProjection {
  sessionId: string;
  sessionStatus: SessionStatus | 'missing';
  currentTurn?: {
    turnId: string;
    runId: string;
    status: TurnStatus;
  };
}

recoveryState / graphState 等，等有规范读取接口和真实 UI 需求后再加。
4. resultRefs 整体移到 Phase 4，Phase 0 schema 不含该字段。
5. provenance 拆成三个 discriminated variants：manual / main_conversation / side_conversation；main 禁止 parentSessionId，side 必须有；归档不变量用类型 + decoder 双重保证（active 无 archivedAt，archived 必有）。
6. SQLite 加 scope/project CHECK 约束（inbox 必须无 project_id，project 必须有）；读取时校验索引列与 record_json.scope 一致，不一致按 corrupt_record 处理。
7. mutation 全部是语义化 patch（title/notes/scope/state 独立字段，notes: null 清除），不替换整条旧记录；写入串行化并事务化；每项有单调 revision，支持 expectedRevision CAS；补并发 rename/move/archive 不丢更新的测试。

Phase 0 交付范围（不含 UI / Runtime Host / 模型工具）：

• packages/core：BoardItem 契约、provenance、生命周期校验、分页 query；
• packages/storage：workflow schema 8→9 增量迁移（workflow_work_board_items + CHECK + 索引）、WorkBoardStore（create / update / archive / unarchive / remove / 分页 list + CAS）；
• 纯 linked-session 投影函数（只读，不写任何状态）；
• 测试：契约、迁移、重开持久化、分页、归档/删除、并发 CAS、备份/恢复、投影。

以上收敛后我再开 Phase 0 PR。

---

AI assistance disclosure: Codex helped structure and draft this comment. I reviewed the issue discussion and own the final position.

[somewan820]

Thanks for the review. Phase 0 is now implemented and the PR is ready for review:PR #3028

The implementation follows the maintainer-approved Phase 0 contract discussed in this issue.

The latest review also confirmed:

• All seven Phase 0 contract points remain satisfied.
• The previously identified P1 around notes: undefined has been fixed.
• notes patch semantics are now explicitly covered:
  • omitted / undefined → unchanged
  • null / "" / whitespace-only → clear
  • non-empty string → replace
• Same-millisecond mutations still produce strictly increasing revisions.
• Malformed record_json fails closed.
• SQLite scope/project invariants are enforced at the database level and validated on read.
• No Task Ledger, Runtime Host, model-visible tools, automatic completion, recoveryState, graphState, or resultRefs were introduced.

The relevant core/storage tests, typechecks, builds, and Biome checks all pass.

Ready for review. Thanks!

简体中文

感谢之前的评审。Phase 0 现在已经完成，并已提交 PR，欢迎 review：PR #3028

本次实现遵循了这个 Issue 中 maintainer 已确认的 Phase 0 contract。

最新一轮 review 也确认：

• 7 项 Phase 0 contract 均保持满足。
• 之前发现的 notes: undefined P1 已修复。
• notes 的 patch 语义现在有完整测试覆盖：
  • 缺省 / undefined → 保持不变
  • null / "" / 纯空白字符串 → 清除
  • 非空字符串 → 替换
• 即使多个 mutation 使用完全相同的毫秒时间戳，revision 仍然严格递增。
• malformed record_json 会 fail closed。
• SQLite scope/project invariant 由数据库 CHECK 约束保证，同时读取时也会进行一致性校验。
• 没有引入 Task Ledger、Runtime Host、model-visible tools、自动完成、recoveryState、graphState 或 resultRefs。

相关的 core/storage tests、typecheck、build 和 Biome checks 均通过。

现在可以进行 review 了，谢谢！

[somewan820]

Hi liugddx — PR #3028 (Work Board Phase 0) is ready for review, but Astro-Han's review on the PR raised a product-scope question that I think only you can close, so I am posting the same reconciliation here before pushing any further commits.

Implementation status (all three findings from Astro-Han's review, fixed in 476eb218b):

1. Revision CAS — read/check/write is now a single BEGIN IMMEDIATE transaction for update / archive / unarchive / remove, closing the cross-process overwrite race while keeping the in-process write queue.

2. Linked-session projection — the projector (module, test, and package export) was removed. It was a parallel DTO using Core TurnStatus, which cannot represent waiting_for_user / cancelled from the canonical continuity contract. It will be rebuilt beside the real Runtime Host / Desktop continuity adapter when Phase 3 has a consumer.

3. Indexes — schema v9 now ships (scope_kind, project_id, updated_at DESC, item_id DESC) and (updated_at DESC, item_id DESC). EXPLAIN QUERY PLAN on populated data confirms no full-table scan or temporary sort for unscoped, scoped, and cursor queries.

4. Migration test — now builds a schema-8 database from the released v0.1.6 operational-state fixture plus the exact v8 workflow DDL, then runs the real 8→9 migration path.

On scope: every semantic in PR #3028 maps to your 7-point review (#2560 (comment)) and the accepted revision (#2560 (comment)). #2290's Option 2 governs SessionTodo, not Work Board, and #2290 explicitly allows Phase 0 to proceed independently (#2290 (comment)).

The only Phase 0 item with no consumer today is linkedSessions: the field exists in the schema, but Phase 0 has no mutation path that writes it and no UI or runtime caller reads it; Phase 3 "start as task" is the intended consumer.

Could you confirm:

(a) Phase 0 remains the approved contract after #2290 Option 2, or should it be re-scoped to capture / list / complete / delete with optional project and source context?

(b) linkedSessions stays in schema v1, or moves to Phase 3 via a future additive migration?

(c) The linked-session projection is formally deferred, or should Phase 0 include an implementation based on the canonical SessionContinuitySnapshot / TurnSnapshot?

Once you confirm, I will either keep the PR as-is or apply the narrow change before requesting merge.

简体中文

你好 liugddx —— PR #3028（Work Board Phase 0）已经可以 review，但 Astro-Han 在 PR 上提出的产品范围问题，我认为只有你能收口，所以在 push 任何新 commit 之前，把同样的对齐说明发在这里。

实现状态（Astro-Han review 的三个 finding 已在 476eb218b 修复）：

1. Revision CAS：update / archive / unarchive / remove 现在是同一个 BEGIN IMMEDIATE 事务内完成 read/check/write，关闭跨进程覆盖竞争，同时保留进程内 write queue。

2. Linked-session projection：projector（模块、测试、package export）已删除。它是一套平行 DTO，使用 Core TurnStatus，无法表达 canonical continuity 中的 waiting_for_user / cancelled。等 Phase 3 有真实消费者后，再放到 Runtime Host / Desktop continuity adapter 旁边实现。

3. 索引：schema v9 现在包含 (scope_kind, project_id, updated_at DESC, item_id DESC) 和 (updated_at DESC, item_id DESC)。用真实填充数据跑 EXPLAIN QUERY PLAN 确认：unscoped、scoped 和 cursor 查询都不再全表扫描或临时排序。

4. Migration 测试：现在用发布的 v0.1.6 operational-state fixture + 精确的 v8 workflow DDL 构造 schema-8 库，走真实 8→9 迁移路径。

关于范围：PR #3028 的每个 semantic 都能对应你的 7 点 review（https://github.com/maka-agent/maka-agent/issues/2560#issuecomment-5294753604）和已接受的修订版（https://github.com/maka-agent/maka-agent/issues/2560#issuecomment-5294956443）。#2290 的 Option 2 约束的是 SessionTodo，不是 Work Board；#2290 也明确允许 Phase 0 独立推进（https://github.com/maka-agent/maka-agent/issues/2290#issuecomment-5298957426）。

Phase 0 里唯一今天没有消费者的是 linkedSessions：字段在 schema 里，但 Phase 0 没有任何 mutation 路径写入它，也没有 UI 或 runtime 调用方读取；Phase 3 “start as task” 才是消费者。

能否确认：

(a) #2290 Option 2 之后，Phase 0 是否仍然以已批准契约为准，还是收缩为 capture / list / complete / delete + 可选的 project/source context？

(b) linkedSessions 留在 schema v1，还是移到 Phase 3（未来 additive migration）？

(c) linked-session projection 是否正式推迟，还是 Phase 0 就要基于 canonical SessionContinuitySnapshot / TurnSnapshot 实现？

你确认后，我会保持 PR 现状，或先做这个收窄改动再请求 merge。

[somewan820]

Following up on your decisions — PR #3028 now matches the confirmed Phase 0 scope:

• linkedSessions is deferred to Phase 3 and removed from the Phase 0 contract/store/tests; the Phase 0 contract rejects the field in create input and stored records.
• The linked-session projection is deferred to Phase 3 and will be implemented against the canonical SessionContinuitySnapshot / TurnSnapshot beside the real continuity adapter.
• Active-row partial indexes bound the default archived = 0 list queries under archive-heavy data, with regression coverage in the store and migration tests.

PR #3028 has been updated (commit 833481e64) and is ready for review. Once it passes, Phase 3 can pick up linkedSessions and the projection adapter.

简体中文

跟进你的决定——PR #3028 现在与确认后的 Phase 0 范围一致：

• linkedSessions 推迟到 Phase 3，已从 Phase 0 契约/store/测试中移除；Phase 0 契约会在 create input 和已存记录里拒绝该字段。
• linked-session projection 推迟到 Phase 3，将在真实 continuity adapter 旁边基于 canonical SessionContinuitySnapshot / TurnSnapshot 实现。
• 新增 active-row partial index，限制 archive-heavy 数据下默认 archived = 0 list 查询的扫描成本，并已在 store 与 migration 测试中覆盖。

PR #3028 已更新（commit 833481e64）并 ready for review。通过后，Phase 3 可以接手 linkedSessions 和投影 adapter。

[somewan820]

Phase 0 complete — PR #3028 merged

Work Board Phase 0 has landed via PR #3028 (squash commit 18c526c5a, merged 2026-08-17, approved by both liugddx and Astro-Han).

What landed:

• Core: BoardItem contract with discriminated provenance (manual / main_conversation / side_conversation), user-owned lifecycle (todo / in_progress / done), archive invariant, exact-shape validation, and semantic patch semantics.
• Storage: additive workflow schema 8→9 migration; WorkBoardStore with BEGIN IMMEDIATE transactional writes, monotonic revision + expectedRevision CAS, keyset pagination bound to the query filters, archive-before-delete, active-row partial indexes, and fail-closed corruption detection.
• Tests: contract, real schema-8→9 migration fixture, backup/restore, archive-heavy index coverage, cross-connection CAS, cursor size/filter regressions.
• Docs: docs/work-board-contract.md records the boundary, mutation contract, and deferrals.

Maintainer-confirmed deferrals remain in place: linkedSessions → Phase 3, linked-session projection → Phase 3 (beside the canonical continuity adapter), resultRefs → Phase 4. No Runtime Host, model-visible tools, or turn-tail injection were introduced.

Next step is Phase 1 (separate kickoff comment follows).

简体中文

Phase 0 已完成 — PR #3028 已合并

Work Board Phase 0 已通过 PR #3028 落地（squash commit 18c526c5a，2026-08-17 合并，liugddx 与 Astro-Han 均已 approve）。

落地内容：

• Core：BoardItem 契约（discriminated provenance：manual / main_conversation / side_conversation、用户拥有的三态生命周期 todo / in_progress / done、归档不变量、exact-shape 校验、semantic patch）。
• Storage：additive 的 workflow schema 8→9 迁移；WorkBoardStore 采用 BEGIN IMMEDIATE 事务、单调 revision + expectedRevision CAS、绑定查询过滤条件的 keyset 分页、先归档后删除、active-row partial index、fail-closed 损坏检测。
• 测试：契约、真实 schema-8→9 迁移 fixture、备份/恢复、archive-heavy 索引覆盖、跨连接 CAS、cursor 长度与 filter 回归。
• 文档：docs/work-board-contract.md 记录了边界、mutation 契约与 deferral。

maintainer 确认的 deferral 保持不变：linkedSessions → Phase 3、linked-session projection → Phase 3（放到 canonical continuity adapter 旁边）、resultRefs → Phase 4。没有引入 Runtime Host、模型可见工具或 turn-tail 注入。

下一步是 Phase 1（kickoff 评论随后发布）。