FDS-18 · B9 待办管理

待办不是新存一份,而是事实库里 kind=action 那类事实的一个专门视图 + 状态机 + 跨会归并。AI 派生的待办默认"待确认",人把负责人和截止时间敲定才"已确认";同一个人的同一件事被多次会议提到,只维护一条,把所有出处串成"这条待办的演进史"。全程站内闭环,不接飞书。

1. 业务说明

• 待办(action)是什么:一句"谁、在什么时候之前、要把什么事做完"。它不是单独建一张表凭空记的,而是 FDS-17 项目事实库里 kind=action(行动项)那类事实——内容标准化文本在 text,负责人 / 截止时间 / 当前状态都放在该事实的 payload(类型特有字段:owner/due/status,见 FDS-17 §3)。待办管理 = 围绕这类事实的状态流转 + 跨会归并 + 一个站内能看能改能追的面板,不是另起一套数据。
• "待确认"是什么:会议处理流水线从纪要里抽出来的待办,机器并不能 100% 确定"该谁做、什么时候交"——所以 AI 派生的待办一律先落"待确认(proposed)",等人在面板上把负责人 / 截止时间核对敲定,才转"已确认(confirmed)"。这和 FDS-16 B7"拿不准的默认归人拍板"是同一条原则的延续:不让 AI 替人认领工作、替人定 deadline。
• "跨会归并"是什么:同一个项目里,同一个负责人的同一件事,可能在周会、评审会、复盘会被反复提到("张三本周内交接口文档"说了三次,期间状态从没动到进行中)。如果每次会都新建一条,面板上就是三条几乎一样的待办,人根本看不清这件事到底干完没。归并 = 判定"这几条说的是同一件事",合成一条主待办,把每次被提到的出处都挂上去,形成"这条待办从被提出到现在的演进史"(用 FDS-17 的 project_fact_links 表记归并关系,不删原始事实)。
• 给谁 / 解决什么:给项目经理、组织者、各负责人——在产品内一处就能看到"这个项目所有待办、各自什么状态、谁在拖、这条待办前后是怎么演变的",不用翻一堆会议纪要自己对。
• 不做会怎样:像现在一样——待办散在各场会议纪要里,没有统一状态(分不清做没做),同一件事在不同会重复出现也对不上,逾期没人管,无法追溯一条待办的来龙去脉。

2. 用户操作与界面

待办面板在项目工作台内,全站内闭环,不接飞书 / 企微 / 邮件(全局约束〇):

1. 一场会处理完,抽到的待办进事实库,状态 proposed(待确认)。项目工作台 → 待办面板出现这些待办,带醒目"待确认"标,并站内消息提醒默认负责人(默认负责人由抽取时带的 owner 给;抽取没给或拿不准的,这一步本身会走 FDS-16 B7 让人确认负责人,确认结果回灌后才到这里)。
2. 负责人 / 项目经理在面板上对"待确认"那条:核对或修改负责人、截止时间,然后点"确认"。确认后这条转 confirmed(已确认),正式生效进入跟踪。也可点"这不是个待办 / 作废",该条记软删(进回收站,可恢复)。
3. 之后负责人推进这件事,在面板上把状态点成"进行中(in_progress)";做完点"完成(done)";不做了点"取消(cancelled)"。到了截止时间还没完成的,系统自动标"逾期(overdue)"并站内提醒负责人 + 抄送项目经理(只提醒,不自动改成完成、不自动猜进度)。
4. 同一件事下次会议又被提到,系统判定为"同一件事"并归并到已有那条:面板上仍只有一条,但点开能看到"演进史"——第一次哪场会提出、中间哪场会又提到、各次原话能点回原文(出处定位复用事实库 trace)。归并若没把握(文本像但不完全确定是不是同一件),不自动并,转人确认(见 §4)。
5. 误删的待办可在回收站找回(软删可逆)。每一次状态变更、负责人 / 截止时间修改、归并,都在面板"操作记录"里可查(谁、何时、改了什么),可追溯。

一句话:待办来自事实库 kind=action,AI 派生默认"待确认",人确认负责人 / 截止后生效,跨会同一件事归并成一条留全出处,全程站内面板可见可改可追。

3. 数据与接口(字段级)

待办不新建主表,复用 FDS-17 project_facts(kind='action')。待办的全部状态机字段落在该事实的 payload(jsonb),归并关系落 project_fact_links,操作留痕落 project_fact_amendments(均 FDS-17 已有,本章不另造表):

project_facts.payload(当 kind='action')约定字段:

payload 字段	类型	说明
owner	uuid	负责人(具体人,不落角色;抽取给的初值,人确认时可改)
owner_text	text	原文里负责人的称呼(留痕,便于"看原文"对照)
due	date null	截止时间(抽取给的初值,人确认时可改;无则 null,确认时要求补)
state	enum	待办状态机:proposed/confirmed/in_progress/done/cancelled/overdue
confirmed_by	uuid null	谁确认了负责人 / 截止(state 进 confirmed 时必填)
confirmed_at	ts null	确认时间
state_history	jsonb	状态变更轨迹:[{from,to,by,at,reason?}](本条待办自己的状态演进)

注:事实级的 project_facts.status(proposed/confirmed/superseded/dropped,FDS-17 §3)管"这条事实在不在账上、是否被取代 / 软删";payload.state 管"这件待办的事干到哪一步"。两者分工不同:前者是事实生命周期,后者是业务进度。软删走事实级(deleted_at + status=dropped,复用 FDS-17 的可逆存储与回收站,不重造)。

跨会归并:project_fact_links(FDS-17 已定,B9 写入)——每条记录"某场会新抽到的待办事实 → 归并进了哪条主待办事实",关系类型标 same_action;主待办事实保留,被归并的原始事实不删(留作出处),status 标 superseded 并 supersedes_id 指向主待办(沿用 FDS-17 演进链字段)。一条主待办 + 它名下所有 same_action 链接 = 这条待办的"演进史"。

接口(acdm-backend 提供;面板前端与流水线经此交互,模型不直接碰状态机与写库):

• GET /facts/query?kind=action&owner=&state=:待办面板拉列表,复用 FDS-17 /facts/query,按 project_id + owner + state 精确查询、强一致(刚确认完即刷新)。
• POST /actions/{id}/confirm:把待办从 proposed → confirmed,入参带核定后的 owner / due;写 confirmed_by/confirmed_at,记 amendments。只有 proposed 能 confirm。
• POST /actions/{id}/transition:状态流转(confirmed→in_progress→done | cancelled),入参 to + 可选 reason;服务端按状态机校验合法迁移,非法迁移拒绝;写 state_history 与 amendments。
• POST /actions/sweep-overdue:定时任务调用,把 due 已过且未 done/cancelled 的置 overdue 并触发站内提醒(只标 + 提醒,不改完成)。
• POST /actions/merge:把一条待办归并进主待办;写 project_fact_links(same_action)、被并条 status=superseded+supersedes_id;幂等(已并不再重复并)。
• POST /actions/{id}/soft-delete …/restore:软删 / 回收站恢复,复用 FDS-17 /facts/{id}/soft-delete/restore。
• GET /actions/{id}/history:取这条待办的演进史(主待办 + 所有 same_action 出处 + 各自 source_ref,供面板"演进史"与"看原文")。

4. 技术实现(分步)

1. 派生待办(默认待确认):会议流水线 B5 抽取产出的"待办类"条目,经 B6 出处校验、必要时 B7 确认后,通过 FDS-17 /facts/commit 写入 kind=action;payload.state 一律初始化为 proposed,owner/due 取抽取值(抽取没给 owner / 给得没把握的,在 B7 已转人确认负责人,回灌后才到这步)。AI 不直接生成 confirmed 待办——这是代码侧的硬约束,不靠技能自律。
2. 人确认负责人 / 截止:面板上人核对 / 修改 owner 与 due,调 /actions/{id}/confirm。代码校验:当前必须是 proposed;due 为空时要求补(不允许确认一条没截止时间的待办,除非显式标"无明确截止");写 confirmed_by/confirmed_at,事实级 status 同步 confirmed,留痕 amendments。
3. 状态机流转(代码强校验):/actions/{id}/transition 按下方状态机判定合法迁移,非法迁移(如 proposed 直接跳 done、done 再改 in_progress)一律拒绝并返回当前态,不靠前端约束;每次迁移追加 state_history(from/to/by/at/reason)。
4. 逾期自动标记:定时任务周期跑 /actions/sweep-overdue,扫 due < 今天 且 state ∉ {done,cancelled} 的待办,置 overdue,经 deer-flow 站内通知能力(🟢 复用)提醒负责人 + 抄送项目经理。只标记 + 站内提醒,绝不自动判完成 / 自动猜进度(沿用 FDS-16"系统不擅自替人下结论"的底线)。
5. 跨会归并(判定→写库都在代码):新会写入一条 action 后,代码侧在同项目同负责人范围内找候选(先按 owner 收窄,再做文本归一比对:去标点 / 同义词归一 / 关键词重合度阈值;语义相近度判断可由一个"同义判定技能"辅助打分,见 §5):
   • 判定确定是同一件事 → 调 /actions/merge:保留较早那条为主待办,新条 status=superseded+supersedes_id 指向主待办,写 project_fact_links(same_action),把新条的 source_ref 作为一次新出处挂到主待办演进史;主待办 payload 若有更新的 due / 进度,按"较新会议优先"合并并记 amendments。
   • 判定像但不确定(分数在模糊区间) → 不自动并,生成一条站内确认任务交人(复用 FDS-16 B7 的站内异步确认机制:疑点说明给"这两条疑似同一件事 + 各自原文",候选"是同一件 / 不是 / 我来归并",指派给项目经理 / 负责人)。最终判定与写库一定在代码,技能只出建议分。
   • 判定不是同一件 → 各自独立存在。归并 /actions/merge 幂等:重复触发不产生重复链接。
6. 演进史:/actions/{id}/history 顺着主待办 + 所有 same_action 链接 + 各被并条 source_ref,组装"第 1 次哪场会提出 → 后续哪几场会又提到 → 各次原话可 trace 回原文",供面板展示与"看原文"跳转(trace 复用 FDS-17 同款定位)。
7. 软删可逆 + 回收站:删 = 事实级软删(deleted_at + status=dropped,FDS-17 §3/§4),进回收站可 restore;主待办被软删时,其演进史链接保留不级联硬删(恢复后演进史完整)。所有写改入 project_fact_amendments 留痕。
8. 隔离:所有接口强制 project_id(复用 FDS-17 / 现有权限校验);越权或缺 project_id 直接拒绝。

待办状态机(代码强校验,非法迁移拒绝):

跨会归并示意(同负责人同一件事,只维护一条 + 留全出处):

5. 技能 or 代码

• 代码(acdm-backend,不让步):待办状态机(合法迁移校验、非法拒绝)、AI 派生默认 proposed、人确认 / 流转 / 逾期标记的写库、跨会归并的最终判定与写库、软删 / 回收站 / 留痕、隔离。这些是"错了会算错数据 / 看不清待办真实状态"的事——按 FDS-04 §2 判据,确定性 + 写库 + 状态流转永远代码,绝不做成技能让模型自律。
• 技能(仅辅助,可选):"这两条待办文本是不是说的同一件事"的语义相近判断可做成一个轻量同义判定技能(给两段文本、返回相似度与依据),帮代码侧在文本归一比对之外多一个判断维度。但它只出建议分,是否归并、写不写 project_fact_links 一律由代码按阈值 + 模糊区间转人确认决定——技能不碰库、不拍板(契约同 FDS-04 §5:技能不直连数据库、拿不准交人)。

边界:模型最多帮判"像不像同一件事",绝不替人认领待办、定 deadline、改状态、决定归并。待办的真实性与状态一致性由代码独占。

6. 二开归类

🔴 自建为主 + 🟡 一个可选辅助技能。

• 🔴 从头自建(acdm-backend + 复用 FDS-17 事实库 / 现有 PostgreSQL):待办状态机、AI 派生默认待确认、人确认负责人 / 截止、状态流转接口与强校验、逾期定时扫描 + 站内提醒、跨会归并的判定与写库(写 project_fact_links)、演进史组装、软删 / 回收站。deer-flow 没有待办表、没有状态机、没有跨会归并,这一整层必须 acdm-backend 写。复用项目已有"可逆存储"做软删 / 回收站 / 留痕,复用 deer-flow 站内通知能力做提醒,均不重造。
• 🟡 基于 deer-flow(可选):"同义判定"辅助技能挂技能目录、跑在引擎上(技能机制是 deer-flow 现成的,在扩展位做)。它只输出相似度建议,不进库、不决定归并。

为什么自建这层:待办的状态机、跨会归并、演进史、逾期闭环都是强一致 + 确定性的事,deer-flow 完全没有这套;事实库地基已在 FDS-17 建好,B9 是它 kind=action 的专门视图与流转层,自然落 acdm-backend。

7. 与人机协同模型关系

• AI 与人共写的直接落点:AI 从会议派生待办(候选),但默认 proposed,负责人 / 截止由人在工作台敲定才生效——和 FDS-16 B7"拿不准默认归人拍板"完全一致,不让 AI 替人认领工作、定 deadline。
• 任务卡:每条待办就是项目工作台上的一张任务卡(待确认的高亮、逾期的标红),人可见、可改、可追。
• 项目工作台 = 单一真相:待办不另存一份,就是事实库 kind=action 的视图,杜绝"面板和会议纪要里的待办对不上"。跨会归并 + 演进史正是"跨会聚合 = 项目级智能"在待办上的体现:同一件事跨多场会只一条、来龙去脉看得见。
• 全链路可逆:软删 + 回收站 + 操作留痕,沿用项目可逆存储。

8. 验收(可证伪)

• 可用:一场会抽到 3 条待办,事实库 kind=action 出现 3 条且 payload.state 均为 proposed;面板显示"待确认"并站内提醒默认负责人(无任何外部 IM 调用)。
• 可用:对一条 proposed 调 confirm 补全 owner/due → 转 confirmed;尝试对 proposed 直接 transition 到 done、对 done 改回 in_progress,均被服务端拒绝并返回当前态(状态机硬校验生效)。
• 可用:造一条 due 已过且未完成的待办,跑逾期扫描后该条 state=overdue 且负责人 + 项目经理收到站内提醒;该待办未被自动改成 done(系统不替人判完成)。
• 可用:同一负责人同一件事在 3 场会被提到,归并后面板上只有一条主待办;/actions/{id}/history 能列出 3 次出处、各能 trace 回对应原文那句;被并的 2 条 status=superseded 且 supersedes_id 指向主待办。
• 可用:文本"像但不确定是不是同一件"的两条,不自动归并,生成一条站内确认任务交项目经理 / 负责人(复用 B7),人判定后才并 / 不并。
• 可用:软删一条待办进回收站,restore 后该待办与其演进史完整恢复;每次确认 / 流转 / 归并 / 删改在操作记录(amendments)可查到操作人与时间。
• 好用:面板能按"待我确认 / 进行中 / 逾期"过滤;同一项目跨会重复提及的待办始终是一条而非多条堆叠。

9. 现状

没有。当前没有待办表、没有状态机、没有跨会归并:待办散落在各场会议纪要文本里,无统一状态(分不清做没做、有没有逾期),同一件事在不同会重复出现且对不上,无法追溯一条待办从被提出到完成的演进史,误删也不可逆。本章在 FDS-17 事实库地基上,从零建 kind=action 的状态机 + 跨会归并 + 站内面板这一整层。

10. 风险与取舍

• 风险:跨会归并误并(把两件不同的事并成一条)→ 丢一件事。取舍:判定权全在代码,文本归一阈值定保守;模糊区间一律转 B7 人确认而非自动并;被并条不物理删除(superseded + 保留出处),误并可顺 supersedes_id 回退拆开。宁可少并(多一条),不可误并(丢一件)。
• 风险:同义判定技能给的相似分不靠谱诱导误并。取舍:技能只是辅助维度之一、只出建议分;最终归并由代码按阈值 + 人确认门控,技能改坏不影响正确性(技能必带 eval 样例 + 走评审,FDS-04 三红线)。
• 风险:AI 派生待办过多 → 面板被一堆"待确认"淹没。取舍:沿用 FDS-16 思路,B5 抽取阈值要"精而准",同一件事跨会归并后只一条,面板支持批量确认;只有真是待办的才落 action。
• 风险:逾期判定误伤(无明确截止的被标逾期)。取舍:due 为空不参与逾期扫描;确认时若确无截止显式标"无明确截止",这类不标 overdue,只在面板提示"建议补截止"。
• 风险:逾期一直挂着没人管。取舍:到期升级提醒 + 抄送项目经理,只催办不自动改完成 / 不自动猜进度——挂着是预期行为,靠站内催办闭环,不接外部 IM、不靠模型兜底(同 FDS-16 取舍)。
• 风险:状态机后续要加状态(如"已验收")→ 改动面大。取舍:状态存 payload.state 枚举 + 迁移规则集中在代码一处校验,加状态只改这一处 + 面板,不动事实库 schema(沿用 FDS-17"核心可查字段固定成列、类型差异进 payload"的取舍)。

待办从派生到闭环、跨会同一件事归并成一条留全出处——站内面板可见可改可追。下一章 FDS-19 B10:跨会汇总与项目看板(真关联),同样只读事实库。