RFC: A project board for people and agent sessions

Status

Requirements settled, technical design in draft. The PRD was finalized on 2026-11-06; the technical design is waiting for maintainer review. Both live in docs/features/kanban/ on the feat/kanban branch (not pushed yet). No code.

Summary

Sessions can already start each other and exchange messages (#239). Once a long task is spread over several sessions, though, the tasks, owners, dependencies and progress live only in chat transcripts. Nobody can see the state of the project without asking each session, and it is lost when sessions stop or the app restarts.

This RFC adds a persistent project board that people and agent sessions share: a fixed project PM, an optional Task Lead for complex work, plus Workers and Reviewers. The board records what to do, who owns it, how far it got and what came out. Clarifying, planning, implementing and verifying stay inside the sessions; the board is not a workflow engine.

Scope

Four capabilities:

A persistent board. Cards can be created, split into sub-cards, linked by "must finish first" dependencies and moved between states. It survives sessions stopping and app restarts. Every branch and worktree of a project sees the same board.
Hierarchical delegation. Each project has one fixed PM session, set only by the human. A complex card can get a Lead, who may split it further and delegate to Workers, Reviewers, or a lower Lead (default limit: two levels of Leads). Assignments take effect only after the human confirms them.
Scoped access. The PM sees the whole project, a Lead its subtree, a Worker its own cards, a Reviewer the cards it reviews. The server enforces this.
Agents drive progress. Agents update progress, report blockers and submit results through tools. The human views, adjusts and accepts.

Each card has three identities:

Identity	Who
Owner	The card's Worker or Lead, at most one
Supervisor	The Lead of the nearest ancestor card that has one, else the PM
Acceptor	The human when the supervisor is the PM, otherwise the supervisor. The human can always step in

The owner and the acceptor of a card are never the same session, and a Reviewer is never the owner. Reports go to the supervisor, not to the session's parent.

States: Backlog, Todo, In Progress, Blocked, Review, Done, Cancelled. A light permission table decides who may make each transition; starting a card also requires an effective assignment and all dependencies done. An agent submitting a result never marks a card Done. Agent suggestions for new work are Backlog cards with a "suggestion" flag, accepted or rejected by the supervisor or the human.

Non-goals

A separate spec or requirements state machine, versioned approvals, or multi-stage review, acceptance and merge.
Creating card worktrees or branches, integration branches, automatic merges or PRs. Branches and PRs are recorded on a card as links.
Predicting file overlap, scheduling ready tasks, worker pools, leases, retries.
Cost per card, a cross-project board, scheduled cards, auto-approved assignments, multiple users, cloud sync.

Proposed design

Storage: one append-only event log per board, ~/.dreamcoder/boards/<sanitized repo root>/events.jsonl, replayed into memory by a pure reducer on first access. This matches how session metadata is already persisted as transcript entries (sessionService.ts), and the log doubles as the card history. No SQLite: nothing in the repo uses bun:sqlite, and the data fits in memory.
One board per repository. The board key is the canonical git root from findCanonicalGitRoot (src/utils/git.ts), which resolves any worktree to its main repository. It is the same rule that gives sessions their projectRoot, so the sidebar's project groups and the boards line up.
The entry point decides the actor. REST calls from the app act as the human. Agent tools send control requests over their own session's SDK connection, as StartSession does, so the server knows which session is acting; the request body cannot claim an identity.
Four CLI tools: KanbanList, KanbanGet, KanbanCreate, KanbanUpdate, backed by kanban_query and kanban_command control requests. The server checks every command against the permission table and the invariants in one pure function.
Notifications reuse deliverUserTurn. An effective assignment, a revoked assignment, a human comment, a submitted result and a blocker each become a user message with a new origin.kind = 'kanban'. A stopped session is resumed to receive it; a new session gets it as its first message. Like cross-session messages, it is wrapped and marked as carrying no user authority.
UI: a board page per project, opened from the project group in the sidebar, with a card detail and a "needs me" list. It polls with since=<version> instead of adding a WebSocket channel. Desktop and H5 share it; drag and drop is desktop only.

Open questions

Can sub-agents call the write tools? Leaning yes: the actor is still the session.
Should a session created for an assignment appear under its supervisor in the sidebar (a new parent.kind = 'assigned')? Leaning yes.
Who may edit a card's title, description and dependencies? The PRD does not say. Leaning owner, supervisor and human.
What counts as a "blocker that involves the human" and a "pending suggestion" in the "needs me" list.

Is the scope right? Is anything in the first version unnecessary, or is something missing without which the board isn't usable? The non-goals in section 9 (第九节) are excluded on purpose; if you think any of them should come back, please say so.
Any other suggestions about the roles, the permission rules, or how assignments and notifications work.

PRD：项目看板（2026-11-06 定稿）

项目看板 PRD

日期：2026-11-06，定稿。以维护者给出的精简版为骨架，补充了身份规则、状态权限、分配通知、评论和空缺的处理。补充的规则已经维护者确认。

本文是产品需求，不规定存储结构和 agent 运行时的实现，这些留给技术设计。

一、产品定位

为 DreamCoder 已有的会话协作能力，加一块持久的项目看板，让人和 agent 围绕同一份任务状态协作。

看板记录做什么、由谁负责、进展如何、结果是什么。需求澄清、规划、实现、验证和协作，由 agent 自己在会话里完成。看板不把 agent 的工作过程改造成一套强制的工作流。

一句话：固定的项目 PM，按需委派的任务 Lead，加上 Worker 和 Reviewer，共用一块持久的看板。

二、要解决的问题

DreamCoder 的会话已经能新开其他会话、互相发消息、向上级汇报。但是一件长期任务分给多个会话以后：

任务、负责人、依赖和进度散落在各个会话的聊天记录里，不容易追踪。
agent 做完工作，结果和遗留问题不一定能可靠地沉淀到项目里。
人要挨个去问各个会话，才知道项目现状。
会话暂停或应用重启以后，项目层面的任务关系看不清。

本功能的价值：把长期的项目事实从对话里提取出来，并持续维护。它不重新实现一套 agent 执行环境。

三、角色与协作

角色

角色	作用	看板范围
人	定义目标，决定任务分配，调整优先级，验收关键交付	整个项目
PM	项目级规划、拆分任务、跨任务协调、汇总进度	整个项目
Lead（可选）	复杂任务的局部协调者：澄清需求、拆子卡、协调下级 agent、汇总交付	自己负责的卡及其子树
Worker	执行分配给自己的任务，维护进度，报告阻塞和结果	自己的卡，以及必要的依赖摘要
Reviewer（可选）	独立检查指定任务的交付，提出修改意见	被指派评审的卡及相关证据

约定

PM 是每个项目固定关联的一个长期会话。进程停止不代表 PM 角色消失；重新打开时，恢复的是同一个会话。
Lead 不是固定的技术领域岗位，而是复杂任务需要时才设的任务负责人。Lead 可以继续委派下级 Lead，层数上限由看板设置控制，默认 2。普通子卡拆多少层，不计入委派层数。
Worker 和 Reviewer 是任务级的角色。Reviewer 和执行者相互独立，不是 Worker 的下属。
正式分配由人决定。 PM 和 Lead 可以拆任务、提出分配建议。agent 只能处理分配给自己的工作，不能自行取得其他任务的管理权限。
卡片树和会话树不要求一致。 卡片树表达工作的拆分和管理范围；会话树表达谁新开了谁。通常 Lead 会自己新开子会话来做子任务，但已有的会话也可以被分配到任务上。

每张卡的三种身份

身份	是谁
执行负责人	这张卡的 Worker 或 Lead，两者只能有一个
上级	从父卡往上找，第一张由 Lead 负责的卡上的那个 Lead；一路都没有，就是 PM
验收方	上级是 PM 的卡，由人验收；其他卡由上级验收。人随时可以替代任何验收方

上级从父卡开始找，所以 Lead 负责的卡，上级是更上一级的 Lead 或 PM，不是它自己。
同一张卡的执行负责人和验收方不能是同一个会话。一个会话可以同时担任多个角色，但不能因此批准自己的交付。
向上汇报按这里的 "上级" 找对象，不按会话的父子关系。
例子：

PM
└── T1 认证系统重构        执行负责人 Lead A    上级 PM       验收方 人
    └── T2 OAuth 模块      执行负责人 Lead B    上级 Lead A   验收方 Lead A
        └── T3 Token 服务  执行负责人 Worker C  上级 Lead B   验收方 Lead B

四、核心概念

不规定存储结构，产品上只需要这些概念：

项目看板：一个项目一块，关联项目根目录和固定的 PM 会话。
任务卡：编号、标题、描述、验收要点、状态、优先级、执行负责人、父卡、时间信息。
依赖：卡片之间 "必须先完成" 的关系，用来显示等待关系和是否就绪。
指派：卡片和 Lead、Worker、Reviewer 会话之间的关联，记录谁提出、谁确认、是否已生效。
更新和评论：进度说明、遇到的问题、讨论结论、关键决定。
交付物：结果摘要，以及相关的文件、提交、分支、PR 或其他链接。

项目卡片是长期任务的唯一可信来源。会话内部的待办清单（现有的 TaskCreate、TaskUpdate 等）仍然可以用来记录 agent 自己的执行步骤，不需要和项目卡片一一对应。

五、工作流程

A. 简单任务：PM → Worker

人或 PM 建卡，写清目标和可以检查的完成条件。
PM 提出分配建议，人确认，把任务分给一个已有的或新开的 Worker 会话。人也可以直接分配。
分配生效后，Worker 会话收到一条通知，里面有卡片编号和任务摘要；它通过看板工具读取完整的任务。
Worker 开始工作，在卡上更新进度或阻塞原因。
Worker 提交结果摘要和验证证据，卡片进入 Review。
Reviewer（如果有）检查并给出意见；验收方确认完成，或者退回。

B. 复杂任务：PM → Lead → Worker / Reviewer

PM 或人建一张粗粒度的任务卡，指派一个 Lead，人确认。Lead 会话收到分配通知。
Lead 开始工作。它可以先在自己的会话里和人或 PM 多轮澄清需求、调查代码、讨论方向。
Lead 把讨论的结论写回卡片：描述、验收要点、评论和关键决定；按需要拆出子卡，建立依赖。
Lead 为子卡提出分配建议，人确认。子卡可以交给 Worker，也可以继续委派给下级 Lead。
Lead 跟踪子卡的状态，处理阻塞，安排必要的 Reviewer 检查。
子卡完成后，Lead 汇总结果，提交父卡的交付。子卡全部完成，不会自动把父卡设为完成。
父卡的验收方检查整体交付，确认完成。

需求澄清本身是工作过程的一部分：Lead 可以在 "进行中" 的状态下不断完善卡片内容，不需要单独的需求状态、版本审批和重开流程。重要的需求变更要写成一条更新记录，并通知受影响的执行负责人。

C. agent 发现额外工作

agent 可以提出新任务或子任务的建议，并写明原因。建议的卡放在 Backlog，带 "建议" 标记。被接受之前，这张卡不能分配，也不能开始。

接受： 上级或人接受后，去掉 "建议" 标记，它就成了一张正式的卡，接受者可以顺手把它移到 Todo。
拒绝： 上级或人拒绝时写明原因，卡片转为 Cancelled，保留历史。

不新增 "提议" 状态，也不另建提议记录。

六、状态与权限

状态

状态	含义
Backlog	已记录，还没准备执行，或者暂时搁置
Todo	任务明确，等待分配或开始
In Progress	执行负责人正在工作，包括 Lead 的调研和需求澄清
Blocked	当前无法推进，必须写明原因
Review	已提交结果，等待检查和验收
Done	交付已确认
Cancelled	不再执行，保留历史

依赖还没满足的卡，显示为 "等待依赖"，不需要改成 Blocked；这时服务端拒绝开始这张卡。
卡片详情里显示子卡、依赖、执行负责人、状态、最新进展和交付物。

谁能做哪些转换

服务端只校验最基本的身份和操作权限，不做多阶段的工作流引擎。

操作	谁能做
在 Backlog 和 Todo 之间移动、排序、改优先级	上级、人
接受或拒绝任务建议	上级、人
开始：Todo → In Progress	执行负责人；分配已生效，且依赖的卡都已完成
标阻塞（写原因），解除阻塞	执行负责人、上级、人
提交结果：In Progress → Review	执行负责人，必须附结果摘要
要求修改：Review → In Progress	Reviewer、验收方、人
确认完成：Review → Done	验收方、人
重排或换人：In Progress → Todo	上级、人
取消	上级、人
重新打开已完成或已取消的卡	人

人在看板上拖拽卡片，可以做表中的任何操作。agent 只能通过看板工具操作，并受这张表约束。

七、首版功能需求

7.1 持久的项目看板

R01 一个项目对应一块持久的看板。从同一个项目的不同分支或 worktree 进入，看到的是同一份任务数据。
R02 支持卡片的创建、编辑、取消和归档，以及排序、设置优先级、拖拽改状态。拖拽受第六节的权限约束。
R03 支持子卡拆分，层数不限；支持 "必须先完成" 的依赖，并拒绝会形成循环的依赖。
R04 卡片记录描述、验收要点、评论、进度更新和结果链接，应用重启后仍然可以查看。
R05 卡片的验收要点只能由上级和人修改。Lead 可以完善自己负责的卡的验收要点，因为澄清需求是它的工作。

7.2 分层委派与权限

R06 看板固定关联一个 PM 会话，只有人能设置或更换 PM。会话停止运行后，关联仍然保留。
R07 复杂卡片可以指定一个 Lead。Lead 管理自己的子树，可以为子树里的卡建议下级 Lead；委派层数不能超过看板设置的上限。
R08 人可以把卡分配给已有的会话或新开的会话。PM 和 Lead 可以提出分配建议，经人确认后才生效。
R09 分配生效后，被分配的会话收到一条通知，并能通过看板工具读取完整的任务。通知的基本信息由系统根据卡片生成：卡片编号、标题、任务摘要、验收要点和上级；提出分配建议的 PM 或 Lead 可以补充一段说明。已有会话和新开会话都一样：新开的会话以这条通知作为第一条消息；已有会话没有在运行时，通知会让它恢复运行并收到。
R10 分配被撤销或换人时，原来的会话收到通知，之后不能再更新这张卡的执行结果。
R11 一张卡同时最多一个执行负责人（Worker 或 Lead）、一个 Reviewer。
R12 Worker 只能开始和更新分配给自己的卡，不能处理其他人的任务。只有当前的执行负责人能提交这张卡的执行结果。
R13 服务端按角色控制可见范围和修改权限：PM 看全部，Lead 看自己的子树，Worker 看自己的卡，Reviewer 看被指派评审的卡；各自都能看到必要的依赖摘要。一个会话担任多个角色时，取各角色范围的并集。
R14 Reviewer 不能和它评审的卡的执行负责人是同一个会话。
R15 同一张卡的执行负责人和验收方不能是同一个会话。如果一次分配会造成这种情况（比如把 Lead 自己分配为它子树里某张卡的 Worker），服务端拒绝这次分配并说明原因。

7.3 agent 的进度与协作

R16 agent 通过看板工具：查询自己的任务、查看依赖、开始任务、更新进度、标记阻塞、提交结果、提出新任务建议。
R17 Lead 通过看板工具：拆分子卡、管理子树、查看子卡进度、接收汇报、汇总父卡的交付。
R18 卡片的每次改动都保留操作历史：时间、操作者（人或哪个会话）、改了什么。
R19 任务汇报保存到对应的卡上。需要通知上级时，按第三节的规则找到上级（PM 或 Lead），通过现有的会话消息送达，不依赖会话的父子关系。
R20 会话暂停、关闭或应用重启后，看板和角色关联保持不变；会话重新打开后，能继续查询自己的任务。
R21 卡片上显示执行负责人的会话是否正在运行。运行状态和任务状态分开显示，不互相替代。
R22 Lead 提交父卡的结果时，如果还有没完成的子卡，系统给出提示，但不阻止提交。

7.4 人的操作与轻量验收

R23 人可以查看完整的看板，修改优先级和分配，检查所有 agent 的进度和交付。
R24 提供一个简洁的 "待我处理" 入口，至少包含：待确认的分配、待人验收的交付、和人有关的阻塞、待决定的任务建议、执行负责人空缺的卡。
R25 上级或人接受一条任务建议后，去掉 "建议" 标记，它成为正式的卡；拒绝时必须写原因，卡片转为 Cancelled 并保留历史。
R26 执行负责人可以把卡提交到 Review；Reviewer 可以提出修改意见；验收方或人可以确认完成，或者退回。
R27 agent 提交结果不会直接让卡片变成完成。
R28 从卡片详情可以打开关联的会话，方便人继续澄清需求、追问进展或要求修改。
R29 人在卡片上评论时，评论默认送到执行负责人的会话。人可以选择同时送给这张卡的 Reviewer 或上级。agent 的评论只记在卡上，不唤醒其他会话。
R30 执行负责人的会话被删除时，卡片保留，执行负责人显示为空缺，并列入 "待我处理"，由人重新分配。

八、页面与交互

首版只做一块看板、一张卡片详情和一个 "待我处理" 入口，不做完整的项目管理套件。

看板：按状态分列，可以拖拽。卡片上显示子卡数量、执行负责人、优先级、阻塞标记、是否在运行、最近更新时间。
卡片详情：目标、验收要点、子卡、依赖、讨论和进度、结果链接、关联的会话。
待我处理：待确认的分配、待人验收的交付、和人有关的阻塞、待决定的任务建议。
和会话联动：从卡片打开会话。界面和 agent 的工具读写同一份数据。

九、非目标

首版不做：

独立的需求状态、需求版本、强制的需求确认流程。需求靠会话澄清，结论写在卡片上。
评审、验收、合并分阶段的强制流程；评审轮次上限；完整的审批引擎；自动批准分配的开关。
自动创建或切换卡片专属的 worktree，集成分支管理，自动的合并、变基或 PR 流程。分支和 PR 只作为交付物链接记录在卡上，由 agent 用现有的 Git 能力处理。
预测文件修改范围、按文件冲突调度、由服务端阻止文件重叠。
自动调度就绪任务、Worker 池、失败重试、租约、agent 自主排程。
每张卡的花费统计、跨项目总看板、定时生成卡片、复杂的通知规则。
多用户、云端同步、可配置的工作流、甘特图。

这些能力以后可以作为独立的增强。现有会话和 Git 能力已经产生的结果，看板只做关联，不重复实现。

十、验收标准

产品是否可用，以完整的用户旅程来验证，不看实现了多少配置项。

人为项目建立看板并设置 PM 会话。关闭再打开应用后，PM 关联和任务都还在。
PM 建一个复杂任务，人指派 Lead。Lead 能在自己的会话里澄清需求、更新卡片、拆出子卡。
人把子卡分配给 Worker。Worker 收到带卡片编号和任务摘要的通知，能通过工具读取并开始自己的任务，但不能修改其他 Worker 的任务。已有会话和新开会话都要验证。
Worker 能报告进度、阻塞和完成结果。Lead 能在看板上看到子树的进度，并收到相应的汇报。这包括 Worker 不是 Lead 新开的会话的情况。
Reviewer 或人能检查交付、要求修改；验收方或人能确认完成。父卡不会因为子卡全部完成而自动完成。agent 不能把自己的卡直接改成完成，也不能通过同时担任多个角色来验收自己的交付。
应用重启后，任务状态、层级、分配、评论和交付物都能恢复；没有 agent 在运行时，看板也能正常使用。

十一、留给技术设计

产品层面的问题都已确认。以下留给技术设计决定：

看板用哪种本地存储，怎样保证并发更新不丢数据。
项目和它的多个 worktree 怎样对应到同一块看板。
看板工具怎样和现有的会话工具、消息机制衔接。
分配通知怎样送达已有会话和新开会话（复用现有的会话消息），以及角色变更怎样生效。

我看了一下，觉得这个方向很有用。多个 agent 可以通过同一个看板了解任务分配、进度和结果，人也能更方便地跟进。

第一版我建议先把基本流程做好：创建任务、人确认分配、agent 执行、提交结果，然后由负责人验收。自动分配任务和自动合并代码可以先放到后续。

另外有几个地方可以再确认一下：

如果任务已经分配，但程序在通知 agent 之前关闭，重新启动后能否继续通知？
如果一个任务换了负责人，原来的 agent 之后才提交结果，系统如何避免把旧结果当成新负责人的交付？
如果任务被移动到另一个负责人下面，是否会一起更新它下面所有子任务的负责人和验收关系？
人确认分配是一个重要步骤。需要确认 agent 是否有可能通过其他方式跳过这个确认。
一个任务被阻塞后，解除阻塞时应该回到什么状态？如果它依赖的任务被取消，又应该怎么处理？
还有一个细节：任务的负责人不一定是创建当前 session 的 agent。提交结果时，建议按看板上的任务关系找到实际负责人，而不是只按 session 的创建关系发送。

整体上，我觉得先把分配、进度、通知和验收做稳定，会比第一版加入更多自动化功能更重要。

@AIR-Xie

谢谢 @AIR-Xie 的仔细阅读，这几个问题都问到了点上。

先说明一下：你看的是较早的一版 PRD。之后我们按测试里的体验又改了几轮，最大的变化是去掉了 PM、Lead 和上下级，回到普通的任务和子任务。每张卡只记三种身份：负责人（做）、审核人（审，可以没有）、创建者（建这张卡的人或会话）。权限和通知只看这三种身份，不再沿卡片树往上找上级。最新的 PRD 放在本条评论末尾。

第一版先把基本流程做稳，这一点我们完全同意。现在的范围就是建任务、分配、执行、提交、审核验收，自动调度和自动合并都不在第一版里。

逐条回答：

1. 分配后、通知送出前程序关闭。 现在重启后不会补发。分配会先写进看板，再给会话发通知，中间关掉应用的话，这条通知会丢失。这个窗口只有唤醒会话的那几秒，我们先记作已知限制，有人遇到再补：重启时把还没有送达结果的通知重新发出。送达失败的通知已经会记在卡上，人可以手动重发。

2. 换了负责人后，原来的会话再提交。 不会被当成新负责人的交付。权限只看卡上还有效的分配，被撤下的会话再提交、再更新这张卡都会被拒绝，换人时它也会收到撤销通知。

3. 任务挪到别的父任务下。 负责人、审核人、创建者都记在卡片自己身上，和父任务是谁无关，所以父任务换人或换位置都不会改动子任务的这些关系。第一版也没有提供改父任务的操作。

4. agent 能不能跳过人的确认。 这一点我们有意改了。旧版要求所有分配都经人确认，但测试里会话拆完子任务后，每次分配都要停下来等人点，流程很碎。现在是这样：

开新会话（包括让新会话负责或审核某张卡）每次都要人确认，任何权限模式下都不能自动通过。
会话把卡分配给已有的会话、给自己分配，会在会话里弹确认卡片，跟着会话的权限模式走：默认模式下要人点，人主动开了跳过确认的模式才会直接通过。
会话给自己刚开出来的子会话分配不再确认，因为开这个会话时人已经确认过。
谁能分配由服务端按身份检查：只有卡的负责人或创建者能分配别的会话，agent 拿不到人才有的操作（重新打开、归档等）。

想严格把关时，不开跳过确认的模式就行。

5. 解除阻塞后回到哪，依赖的任务被取消怎么办。

解除阻塞后回到被阻塞之前的状态，在进行中被阻塞，解除后回到进行中。
依赖被取消确实是个漏洞：现在只认依赖是否完成，依赖被取消后，等它的卡会一直开不了工。我们定的处理是：一张卡不需要了由它的创建者决定（人随时可以替它决定），负责人觉得不需要时，标阻塞写明原因交给创建者；会话取消卡要人确认；取消时如果还有卡依赖它、或它还有没完成的子卡，系统把这些卡列出来，由取消的一方当场决定删掉依赖还是一起取消。这样依赖关系在取消的那一刻就处理掉，不会留下卡死的卡。这部分写进了 PRD（R38–R40），还没实现。

6. 按看板上的任务关系找负责人，不按会话的创建关系。 已经是这样了：提交结果时通知卡上记的审核人和创建者，阻塞时通知创建者，和会话是谁开的无关。

最新 PRD（2026-11-08）

项目看板 PRD

日期：2026-11-06，定稿。以维护者给出的精简版为骨架，补充了身份规则、状态权限、分配通知、评论和空缺的处理。补充的规则已经维护者确认。

2026-11-07 修订： 去掉 PM 和上下级，回到项目管理里任务和子任务的关系。谁做、谁审、谁建都记在卡片本身上，不再沿卡片树推出上级。验收由审核人做，没有审核人时由人验收。会话在别处建卡要经人同意，这个确认跟着会话的权限模式走。

同日第二次修订： 会话做的分配也改成在会话里弹确认卡片，跟着权限模式走，不再进 "待我处理" 等人去看板确认。会话开新会话来做一张卡时，确认开会话就同时确认了它当负责人。会话为自己申请角色并入同一种分配，不再总是询问。看板上不再有待确认的分配。

2026-11-08 补： 会话把卡分配给自己开出来的子会话时不再确认，开这个会话时人已经同意过。负责人可以直接从 Backlog 开始。起因是测试里模型开新会话时没带卡，开完再分配，两个会话确认了四次；子会话又因为卡在 Backlog 开始不了，只能回头找创建者挪卡。

同日再补：审核人有自己的工作。 指定审核人时带一段审核说明，写清怎么审（比如按某份规范审代码，或者协助人做验收）；没写就用默认说明。开新会话时可以直接让它当审核人。审核人接受时要写审核报告，负责人和创建者都会收到。任务处于 Review 时，看板上显示的是审核人。

同日再补：取消由创建者决定。 一张卡不需要了，由创建者判断，人可以替它决定。负责人觉得不需要时，标阻塞写明原因，由创建者处理。创建者是会话时，取消要人在会话里确认。取消时如果还有卡依赖它，或它还有没完成的子卡，系统列出这些卡，由取消的一方当场处理。

本文是产品需求，不规定存储结构和 agent 运行时的实现，这些留给技术设计。

用语（2026-11-07 补）： 界面上把卡片统一叫 "任务"（英文 Task），侧栏入口叫 "项目看板"。本文中的 "卡"、"卡片"、"子卡" 在界面上分别显示为 "任务"、"任务"、"子任务"，含义不变。

一、产品定位

为 DreamCoder 已有的会话协作能力，加一块持久的项目看板，让人和 agent 围绕同一份任务状态协作。

看板记录做什么、由谁负责、进展如何、结果是什么。需求澄清、规划、实现、验证和协作，由 agent 自己在会话里完成。看板不把 agent 的工作过程改造成一套强制的工作流。

一句话：一棵任务和子任务组成的树，每张卡记着负责人、审核人和创建者，人和会话共用这块持久的看板。

二、要解决的问题

DreamCoder 的会话已经能新开其他会话、互相发消息、向父会话汇报。但是一件长期任务分给多个会话以后：

任务、负责人、依赖和进度散落在各个会话的聊天记录里，不容易追踪。
agent 做完工作，结果和遗留问题不一定能可靠地沉淀到项目里。
人要挨个去问各个会话，才知道项目现状。
会话暂停或应用重启以后，项目层面的任务关系看不清。

本功能的价值：把长期的项目事实从对话里提取出来，并持续维护。它不重新实现一套 agent 执行环境。

三、角色与协作

角色

角色	作用
人	定义目标，决定谁来做，调整优先级，验收没有审核人的卡；能做看板上的任何操作
负责人	做这张卡：维护进度，报告阻塞和结果。任务大时把它拆成子卡
审核人（可选）	按审核说明检查这张卡的交付（看代码、跑测试、协助人验收等），写审核报告确认完成，或者退回
创建者	建这张卡的人或会话：管理这张卡，收到它的阻塞和提交

同一个项目里的会话都能看到整块看板。

约定

（2026-11-07 修订：去掉 PM 和上下级，原来的 Lead 和 Worker 也已合并为 "负责人"。）

没有项目级的 PM，也没有上级。 卡片之间只有任务和子任务的关系。规划和拆分由人来做，或者由人请某个会话来做。
负责人、审核人和创建者是会话和某张卡之间的关系，不是会话的固定身份。 同一个会话可以负责一张卡，同时审核另一张卡。
负责人可以拆自己的卡。 拆出来的子卡，创建者就是这个负责人。它可以为子卡分配负责人和审核人；需要检查子卡的结果时，把自己设为子卡的审核人。拆不拆由负责人自己判断，层数不限。
会话的分配要人同意。 卡的创建者和负责人可以把卡分配给其他会话，任何会话都可以把自己设为某张卡的负责人或审核人。分配在会话里弹确认卡片，跟着会话的权限模式走；分配给自己开出来的子会话不再确认。开新会话来做或审一张卡时，开会话的确认卡上写明它负责或审核哪张卡，确认一次就够了。
在别处建卡要人同意。 会话在自己负责或自己建的卡下面建子卡，直接建出；在别处建卡（包括顶层的卡）算作建议，在会话里弹确认卡片。
卡片树和会话树不要求一致。 卡片树表达工作的拆分；会话树表达谁新开了谁。负责人常会自己新开子会话来做子卡，但已有的会话也可以被分配到任务上。

每张卡的三种身份

身份	是谁	做什么
负责人	最多一个会话	开始、更新进度、提交交付报告
审核人	最多一个会话，可以没有	检查交付，确认完成或者退回。没有审核人时由人验收
创建者	建这张卡的人或会话	管理这张卡的状态和分配，收到它的阻塞和提交

同一张卡的负责人和审核人不能是同一个会话，所以一个会话不能验收自己的交付。人随时可以替代审核人做决定。
这些身份只看卡片本身。父卡换了负责人，子卡的负责人、审核人和创建者都不变。
例子：

T1 认证系统重构        创建者 人   负责人 A   审核人 无（人验收）
└── T2 OAuth 模块      创建者 A    负责人 B   审核人 A
    └── T3 Token 服务  创建者 B    负责人 C   审核人 无（人验收）

四、核心概念

不规定存储结构，产品上只需要这些概念：

项目看板：一个项目一块，关联项目根目录。
任务卡：编号、标题、描述、验收要点、状态、优先级、负责人、审核人、创建者、父卡、时间信息。
依赖：卡片之间 "必须先完成" 的关系，用来显示等待关系和是否就绪。
指派：卡片和负责人、审核人会话之间的关联，记录谁分配的、什么时候生效或撤下。
更新和评论：进度说明、遇到的问题、讨论结论、关键决定。
交付报告（2026-11-07 修订）：负责人提交的结果报告，写做了什么、怎么验证的、还有什么没解决，按 Markdown 显示；可以附分支、提交、PR 或文件的链接作为参考。做出来的东西本身（代码、分支、文档）留在原处，不存在看板上。

项目卡片是长期任务的唯一可信来源。会话内部的待办清单（现有的 TaskCreate、TaskUpdate 等）仍然可以用来记录 agent 自己的执行步骤，不需要和项目卡片一一对应。

五、工作流程

A. 简单任务

人建卡，或者会话建议一张卡、人同意。卡上写清目标和可以检查的完成条件。
人把任务分给一个已有的或新开的会话作为负责人；会话也可以分配，在会话里确认。需要时再指定审核人。
分配生效后，负责人会话收到一条通知，里面有卡片编号和任务摘要；它通过看板工具读取完整的任务。
负责人开始工作，在卡上更新进度或阻塞原因。
负责人提交交付报告，卡片进入 Review。审核人和创建者收到通知。
审核人按审核说明检查后，写审核报告确认完成，或者退回；没有审核人时由人验收。负责人和创建者收到确认完成的通知。

B. 复杂任务：负责人拆分

人建一张粗粒度的任务卡，分配给一个负责人。负责人会话收到分配通知。
负责人开始工作。它可以先在自己的会话里和人多轮澄清需求、调查代码、讨论方向。
负责人把讨论的结论写回卡片：描述、验收要点、评论和关键决定；判断需要拆分时直接拆出子卡，建立依赖。
负责人开新会话来做子卡，开会话的确认卡上写明新会话负责哪张子卡，人确认一次，新会话一启动就是负责人；也可以把子卡分配给已有的会话。需要检查子卡结果时，负责人把自己设为子卡的审核人。子卡的负责人还可以继续拆分。
子卡阻塞或提交时，作为创建者的负责人收到通知。它处理阻塞，并以审核人的身份验收子卡。
子卡完成后，负责人汇总结果，提交父卡的交付。子卡全部完成，不会自动把父卡设为完成。
父卡的审核人检查整体交付，确认完成；没有审核人时由人验收。

需求澄清本身是工作过程的一部分：负责人可以在 "进行中" 的状态下不断完善卡片内容，不需要单独的需求状态、版本审批和重开流程。重要的需求变更要写成一条更新记录，并通知受影响的子卡负责人。

C. agent 发现额外工作

agent 在自己负责或自己建的卡下面，可以直接建子卡。在别处建卡（顶层的卡，或者别人的卡下面）算作建议：会话里弹出确认卡片，显示标题和描述。

同意： 卡片正式建出来，建议它的会话成为创建者。
拒绝： 看板上什么都不留。

这个确认跟着会话的权限模式走：跳过确认的模式下直接建出，人也可以在卡片上选择 "本会话都允许"。建出来的卡没有负责人就不能开始，所以谁来做仍然由人决定。

不新增 "提议" 状态，看板上也不保留待决定的建议。会话做的分配也一样：在会话里确认，看板上不留待确认的分配。

六、状态与权限

状态

状态	含义
Backlog	已记录，还没准备执行，或者暂时搁置
Todo	任务明确，等待分配或开始
In Progress	负责人正在工作，包括调研和需求澄清
Blocked	当前无法推进，必须写明原因
Review	已提交结果，等待检查和验收
Done	交付已确认
Cancelled	不再执行，保留历史

依赖还没满足的卡，显示为 "等待依赖"，不需要改成 Blocked；这时服务端拒绝开始这张卡。
卡片详情里显示子卡、依赖、负责人、审核人、创建者、状态、最新进展和交付报告。

谁能做哪些转换

服务端只校验最基本的身份和操作权限，不做多阶段的工作流引擎。

操作	谁能做
在 Backlog 和 Todo 之间移动、排序	创建者、人
编辑标题、描述、验收要点、优先级和依赖	负责人、创建者、人
开始：Backlog 或 Todo → In Progress	负责人；分配已生效，且依赖的卡都已完成
标阻塞（写原因），解除阻塞	负责人、创建者、人
提交结果：In Progress → Review	负责人，必须附交付报告
要求修改：Review → In Progress	审核人、人
确认完成：Review → Done，附审核报告	审核人、人；没有审核人时只有人
重排或换人：In Progress → Todo	创建者、人
取消（会话取消时要人确认），撤销分配	创建者、人
把卡分配给其他会话	负责人、创建者、人
把自己设为负责人或审核人	任何会话、人
重新打开已完成或已取消的卡，归档	人

人在看板上拖拽卡片，可以做表中的任何操作。agent 只能通过看板工具操作，并受这张表约束。会话做的分配在会话里弹确认卡片，跟着会话的权限模式走；分配给自己开出来的子会话时不弹。

七、首版功能需求

7.1 持久的项目看板

R01 一个项目对应一块持久的看板。从同一个项目的不同分支或 worktree 进入，看到的是同一份任务数据。
R02 支持卡片的创建、编辑、取消和归档，以及排序、设置优先级、拖拽改状态。拖拽受第六节的权限约束。
R03 支持子卡拆分，层数不限；支持 "必须先完成" 的依赖，并拒绝会形成循环的依赖。
R04 卡片记录描述、验收要点、评论、进度更新和结果链接，应用重启后仍然可以查看。
R05（2026-11-07 修订）卡片的验收要点由创建者、负责人和人设定和完善，因为澄清需求是负责人工作的一部分；改动记入历史，审核人或人据此验收。
R31（2026-11-07 修订）人可以从项目菜单建看板。项目还没有看板时，会话建第一张卡会连同看板一起建立，这时总要人确认，和会话的权限模式无关。
R33（2026-11-07 补）卡片上的文字（进度、提交摘要、退回意见、阻塞原因等）保持简短，超过上限时系统拒绝并提示改写成文件。较长的内容（比如 review 报告）写成项目里的文件，在提交或退回时作为链接附上。人在卡片详情里点开链接就能在侧边面板查看文件，agent 需要细节时读取文件。agent 读卡时默认只拿到最近的进度和最近一次交付，需要时再取完整记录。

7.2 分配与权限

R06（2026-11-07 修订）看板不关联固定的 PM，卡片之间也没有上下级。每张卡的负责人、审核人和创建者记在卡片本身上，父卡的变化不影响子卡的这些身份。
R07（2026-11-07 修订）负责人可以把自己的卡拆成子卡，不需要确认，层数不限。它是子卡的创建者，可以为子卡分配负责人和审核人。
R08（2026-11-07 修订）人可以把卡直接分配给已有的会话或新开的会话；人分配的新会话挂在卡的创建者会话下面，卡由人建的就单独开。卡的创建者和负责人可以把卡分配给其他已有的会话，任何会话可以把自己设为负责人或审核人；这些分配在会话里弹确认卡片，跟着会话的权限模式走。分配给自己开出来的子会话时不弹，开这个会话时人已经同意过。分配一个已有人担任的位置时，原来的会话被撤下并收到通知。
R34（2026-11-07 补，2026-11-08 修订）卡的创建者和负责人开新会话时可以指定它负责或审核这张卡。开会话的确认卡上写明是哪张卡、什么身份，人确认后新会话一启动就担任这个身份，原来担任的会话被撤下。新会话挂在开它的会话下面。开审核人时，开场任务就是它的审核说明。
R35（2026-11-08 补）指定审核人时可以写一段审核说明：审什么、按什么标准，比如审代码或者协助人验收。没写时用系统的默认说明：等负责人提交，对照每条验收要点检查交付，查完写报告接受或者退回。审核说明出现在审核人收到的分配通知、负责人提交后的通知（同时附上验收要点）和卡片详情里。
R36（2026-11-08 补）审核人或人确认完成时必须写审核报告：查了什么、怎么查的，可以附文件链接。报告记在卡上，负责人和创建者收到通知。
R37（2026-11-08 补）卡片处于 Review 且有审核人时，看板、层级视图和卡片详情显示审核人和它是否在运行，而不是负责人。
R09 分配生效后，被分配的会话收到一条通知，并能通过看板工具读取完整的任务。通知的基本信息由系统根据卡片生成：卡片编号、标题、任务摘要、验收要点、创建者，以及由谁验收；分配的一方可以补充一段说明。人分配的新会话以这条通知作为第一条消息；会话开新会话来做一张卡时，这些信息接在它写的开场任务后面，作为同一条消息。已有会话没有在运行时，通知会让它恢复运行并收到。
R10 分配被撤销或换人时，原来的会话收到通知，之后不能再更新这张卡的执行结果。
R38（2026-11-08 补）只有卡的创建者和人能取消卡。创建者是会话时，取消在会话里弹确认卡片，人同意后才生效。
R39（2026-11-08 补）负责人认为卡不需要时，不能自己取消；它把卡标为阻塞并写明原因，由创建者决定取消还是继续。
R40（2026-11-08 补）取消一张卡时，如果有没完成的卡依赖它，或它还有没完成的子卡，系统列出这些卡：会话取消时写在结果里，人在看板上取消时写在确认框里。取消的一方当场决定删掉这些依赖，或者把这些卡一起取消。
R32（2026-11-07 补）卡片被退回修改、解除阻塞、退回待办或取消时，负责人收到通知，通知里带操作者和原因；退回修改时还带附上的文件链接。负责人自己做的操作不通知自己。
R11 一张卡同时最多一个负责人、一个审核人。
R12 负责人只能开始和更新自己负责的卡，不能处理其他会话的任务。只有当前的负责人能提交这张卡的执行结果。
R13（2026-11-07 修订）同一项目的会话都能看到整块看板。修改权限按第六节的表：负责人、审核人和创建者各自能做的操作不同，人能做全部。
R14 审核人不能和它审核的卡的负责人是同一个会话。验收由审核人做，所以会话不能验收自己的交付。
R15（2026-11-07 删除）原来要求负责人和验收方不是同一个会话。验收方并入审核人以后，由 R14 保证。

7.3 agent 的进度与协作

R16 agent 通过看板工具：查询任务、查看依赖、开始任务、更新进度、标记阻塞、提交结果、建卡或建议新卡、分配。
R17（2026-11-07 修订）负责人通过看板工具：拆分子卡、查看子卡进度、收到子卡的阻塞和提交、以审核人的身份验收子卡、汇总父卡的交付。
R18 卡片的每次改动都保留操作历史：时间、操作者（人或哪个会话）、改了什么。
R19（2026-11-07 修订）任务汇报保存到对应的卡上。提交时通知审核人和创建者，阻塞时通知创建者，通过现有的会话消息送达，不依赖会话的父子关系。
R20 会话暂停、关闭或应用重启后，看板和角色关联保持不变；会话重新打开后，能继续查询自己的任务。
R21 卡片上显示负责人的会话是否正在运行。运行状态和任务状态分开显示，不互相替代。
R22 负责人提交父卡的结果时，如果还有没完成的子卡，系统给出提示，但不阻止提交。

7.4 人的操作与轻量验收

R23 人可以查看完整的看板，修改优先级和分配，检查所有 agent 的进度和交付。
R24（2026-11-07 修订）提供一个简洁的 "待我处理" 入口，至少包含：没有审核人（或审核人会话已删除）的交付、阻塞的卡、负责人空缺的卡。
R25（2026-11-07 修订）会话在别处建卡时，在会话里弹确认卡片；人同意后卡片建出，拒绝则不留记录。这个确认跟着会话的权限模式走。看板上不保留待决定的建议。
R26（2026-11-07 修订）负责人可以把卡提交到 Review；审核人或人可以确认完成（附审核报告，见 R36），或者退回；没有审核人时由人验收。
R27 agent 提交结果不会直接让卡片变成完成。
R28 从卡片详情可以打开关联的会话，方便人继续澄清需求、追问进展或要求修改。
R29（2026-11-07 修订）人在卡片上评论时，评论默认送到负责人的会话。人可以选择同时送给这张卡的创建者。agent 的评论只记在卡上，不唤醒其他会话。
R30 负责人的会话被删除时，卡片保留，负责人显示为空缺，并列入 "待我处理"，由人重新分配。

八、页面与交互

首版只做一块看板、一张卡片详情和一个 "待我处理" 入口，不做完整的项目管理套件。

看板：按状态分列，可以拖拽。卡片上显示子卡数量、负责人、优先级、阻塞标记、是否在运行、最近更新时间。
层级和分工（2026-11-07 补，同日修订）：同一份数据另有两种看法。层级按父子关系展开卡片树，并标出依赖；分工列出各个会话负责和审核的卡。
卡片详情：目标、验收要点、子卡、依赖、讨论和进度、交付报告，以及负责人、审核人（没有时显示由你验收）和创建者；审核人下面显示审核说明。详情在右侧面板里打开，看板和会话里都能打开，不离开当前页面。
待我处理：待人验收的交付、阻塞的卡、负责人空缺的卡。
和会话联动：从卡片打开会话。界面和 agent 的工具读写同一份数据。会话建议的卡和会话做的分配都在会话里确认。

九、非目标

首版不做：

独立的需求状态、需求版本、强制的需求确认流程。需求靠会话澄清，结论写在卡片上。
评审、验收、合并分阶段的强制流程；评审轮次上限；完整的审批引擎；自动批准分配的开关。
项目级的 PM、沿卡片树推出的上下级、委派层数限制、按身份限制会话能看到哪些卡。
自动创建或切换卡片专属的 worktree，集成分支管理，自动的合并、变基或 PR 流程。分支和 PR 只作为交付报告里的参考链接记录在卡上，由 agent 用现有的 Git 能力处理。
预测文件修改范围、按文件冲突调度、由服务端阻止文件重叠。
自动调度就绪任务、Worker 池、失败重试、租约、agent 自主排程。
每张卡的花费统计、跨项目总看板、定时生成卡片、复杂的通知规则。
多用户、云端同步、可配置的工作流、甘特图。

这些能力以后可以作为独立的增强。现有会话和 Git 能力已经产生的结果，看板只做关联，不重复实现。

十、验收标准

产品是否可用，以完整的用户旅程来验证，不看实现了多少配置项。

人为项目建立看板，或者会话建第一张卡时经人确认建立。关闭再打开应用后，任务都还在。
人建一个复杂任务并指派负责人。负责人能在自己的会话里澄清需求、更新卡片，直接拆出子卡。
人或负责人把子卡分配给其他会话。子卡负责人收到带卡片编号和任务摘要的通知，能通过工具读取并开始自己的任务，但不能处理不归它的任务。已有会话和新开会话都要验证；负责人开新会话做子卡时，人只确认一次，新会话启动时已经是负责人。
子卡负责人能报告进度、阻塞和完成结果。拆出子卡的负责人能在看板上看到子卡的进度，并收到子卡的阻塞和提交。这包括子卡负责人不是它新开的会话的情况。
审核人或人能检查交付、要求修改、确认完成；没有审核人的卡由人验收。父卡不会因为子卡全部完成而自动完成。agent 不能把自己的卡直接改成完成，也不能验收自己的交付。
会话在别处建卡时，人在会话里确认；跳过确认的权限模式下直接建出。父卡换负责人后，子卡的负责人、审核人和创建者不变。
应用重启后，任务状态、层级、分配、评论和交付报告都能恢复；没有 agent 在运行时，看板也能正常使用。

十一、留给技术设计

产品层面的问题都已确认。以下留给技术设计决定：

看板用哪种本地存储，怎样保证并发更新不丢数据。
项目和它的多个 worktree 怎样对应到同一块看板。
看板工具怎样和现有的会话工具、消息机制衔接。
分配通知怎样送达已有会话和新开会话（复用现有的会话消息），以及角色变更怎样生效。

RFC: A project board for people and agent sessions #241

Description

Status

Summary

Scope

Non-goals

Proposed design

Open questions

Related

Activity

GoDiao commented on Nov 6, 2026

项目看板 PRD

一、产品定位

二、要解决的问题

三、角色与协作

角色

约定

每张卡的三种身份

四、核心概念

五、工作流程

A. 简单任务：PM → Worker

B. 复杂任务：PM → Lead → Worker / Reviewer

C. agent 发现额外工作

六、状态与权限

状态

谁能做哪些转换

七、首版功能需求

7.1 持久的项目看板

7.2 分层委派与权限

7.3 agent 的进度与协作

7.4 人的操作与轻量验收

八、页面与交互

九、非目标

十、验收标准

十一、留给技术设计

AIR-Xie commented on Nov 8, 2026

GoDiao commented on Nov 8, 2026

项目看板 PRD

一、产品定位

二、要解决的问题

三、角色与协作

角色

约定

每张卡的三种身份

四、核心概念

五、工作流程

A. 简单任务

B. 复杂任务：负责人拆分

C. agent 发现额外工作

六、状态与权限

状态

谁能做哪些转换

七、首版功能需求

7.1 持久的项目看板

7.2 分配与权限

7.3 agent 的进度与协作

7.4 人的操作与轻量验收

八、页面与交互

九、非目标

十、验收标准

十一、留给技术设计

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions