活动 × 待办打通构想

1一页结论

2现状盘点（都是真实读出来的，不是设想）

3目标模型

3.1 待办：两级分类，两层都必填

你给的 8 类天然是 2 × 4：先分对内／对外，再选类型。建议把这两个维度做成两个字段 而不是 8 个平铺的值——因为「筛选对外待办」和「筛出所有客诉跟进」都会用到，平铺会两边都别扭。

3.2 活动：对外待办的载体

活动已经是结构化录入，本次只做 两处加法、一处回写：

3.3 拜访视图：把「拜访」第一次算成账

下钻：点客户名 → 打开该客户的活动清单（时间倒序），再点一条 → 进活动详情。 权限沿用 P4（admin/gm 全量、manager 本部门、sales 只看自己），且必须在服务端过滤—— 前端过滤不是授权。

4数据模型

4.1 待办（在现有结构上加 6 个字段）

todo = {
  id, text, client, due, created,        // 现有，due 改必填
  done, closed, closedBy,                // 现有，完成按钮留痕

  scope: 'internal' | 'external',        // 新增 ① 对内/对外
  type:  'internal_project' | ...,       // 新增 ② 8 类之一
  owner: '赵云浩',                        // 新增 ③ 负责人（现在是写在正文里的）
  tech_support: false,                   // 新增 ④ 是否需要技术支持协同
  tech_owner: '',                        // 新增 ⑤ 协同人（tech_support=true 时必填）
  source: {                              // 新增 ⑥ 溯源 + 幂等
    kind: 'activity' | 'manual',
    activity_id: 'ACT...', block_idx: 0, plan_idx: 1
  },
  fp: 'ACT123#0#1#回传测试报告'            // 幂等指纹
}

为什么要 owner：现在待办是「一人一文档」（{user:'刘新元', todos:[...]}）， 所以「这是谁的待办」是靠文档分片表达的。一旦要支持「技术支持同事也能看到协同给他的待办」， 就必须有字段级的负责人 + 服务端跨人查询，否则只能靠复制两份数据，必然不同步。

4.2 旧 7 类 → 新 8 类的映射（老数据不用重填）

映射写进迁移脚本，一次性跑完，前端保留旧值兼容显示（CATS/CAT_COLORS 要同步扩表）。

5打通规则（本次最容易做错的一段）

行在创建时领一个稳定 id：plan_row.uid = 'r-xxxx'（不随文本修改、不随排序变化）

fp = sha1(activity_id + '#' + plan_row.uid)

if 存在 fp:                    # 活动改了时间/负责人/措辞 → 更新，不新增
    只更新 due / owner / text    ← 绝不动 done / closed / conclusion
elif 不存在 fp:
    新建待办（done=false）
计划行被删掉:
    对应待办标 source_removed=true，不物理删除   ← 留痕，由人来决定要不要关

5.1 「提交前确认」——本次最关键的一层（按 #3 / #5）

活动录入页
 ├─ ① 填「下一步计划」/「问题现象」
 ├─ ② 点「生成待办预览」→ 页面下方出现【本次将生成的待办】清单（草稿态 · 未落库）
 │      每行可改：事项文本 / 负责人 / 截止 / 类型   可删   可勾「需要技术支持」
 │      「问题现象」自动派生 1 条，默认 客诉跟进（可改成其他类型）
 ├─ ③ 销售逐条修改并勾选确认
 └─ ④ 点「确认并提交」→ 活动落库 + 待办按确认后的清单落库（写 activity_id）

二次编辑同一个活动：按 source.activity_id 把该活动已生成的待办拉回来， 和当前清单一起进同一个「可改可确认」的清单，确认后做 diff upsert—— 只更新变动项，不动销售在待办侧已经打的勾和写的结论。

5.2 技术支持协同：只留入口（按 #4）

「只留入口」不等于字段先不设计。本次仍然把 tech_support 落库、把标记显示在待办行上—— 三个月后要真接技术协同，手上已经有真实使用数据（谁在哪些事上要技术、频率多高），不用回头补历史。 自动派单 / 跨人可见 / 状态双向同步一律留到口径成熟再做。

6页面构想（三处改动）

7落地分期

顺序不能颠倒：P1 依赖 P0 的 owner 字段，P2 依赖 P1 的 channel 字段。

7.1 P0 落点清单（改动面 · 可逐条对着核）

8口径回执与下一步

9已知的坑（做之前先知道）