# 作废态保留 owner 的状态机小改:残留触点核实与文档定稿 Type: grilling Status: resolved Blocked by: ## Question 决策 01 已定:作废态**保留 `owner_user_id`**(反馈无效自动作废时不再清空),使销售能在「我的线索」看到自己作废的线索;名额 `hold_limit` / 可转商机目录按 status IN(3,4) 排除作废、不依赖 owner=null,已核实不受影响。 本 ticket 把这个「小改」的边界钉死——核实残留触点,产出改动清单(仍是 spec 层,不写实现): 1. **`LeadTransitionImpl#applyFeedback`(line 211)**:改为 targetStatus=VOID 时**不** `set(ownerUserId, null)`。但 `ownerNameSnapshot` / `claimTime` / `recycleDeadline` 是否也保留?(recycleDeadline 关系回收计时,见下。) 2. **回收计时 N**:作废保留 owner 后,回收 job / `LeadDeadlines` 是否会把「作废且 owner 非空」误当私海去续期或回收?作废态 N 应停(PRD §3.4:作废态 N 不跑,M 继续)。需确认保留 owner **不会**让作废线索重新被回收扫描命中。 3. **激活恢复(过期失效→失效前态)**:作废→失效→激活 恢复到作废态,现在 owner 已保留,`statusBeforeExpire` 恢复逻辑读 owner 是否仍自洽。 4. **`@DataScope`**:作废线索 owner=me 后,会不会改变它在「线索管理」等视图的部门天花板/owner 过滤判定,导致别处列表意外多/少数据。 5. **边 #15「作废自环换 owner」**(管理员把作废线索重新分配给新销售):原逻辑是「作废态 owner 可能为空→写入新 owner」。保留 owner 后,重新分配=**覆盖**原 owner,语义是否仍正确(原持有人被顶替)。 6. **文档**:PRD §3.4 / 状态机边 #14 / `crm-lead/CONTEXT.md` 中「进入作废时清空 owner_user_id」全部要改。列出待改条目(PRD §3.4、边#14、§6.10 G1/G2、CONTEXT「线索作废」段)。 7. **回归面**:列出受影响的现有测试(`LeadTransitionImplTest` 的作废/反馈无效用例、`ClaimLimitCheckerTest`、可转商机目录测试)需要新增/改写的断言清单。 产出:一份「作废保留 owner」改动清单 + 文档待改条目 + 回归断言清单,作为 spec 的领域改动章节。这是 02(口径表)的前置——「我的线索」到底含哪些作废线索,取决于本 ticket 把归属语义钉死。 ## 已定(逐步澄清) **① 作废 VOID 分支的字段取舍**(`applyFeedback` line 211 四个 `set(...,null)`)——用户认可推荐: - `owner_user_id` — **保留**(本 ticket 核心) - `owner_name_snapshot` — **保留**(否则列表“归我却无名”) - `claim_time` — **保留**(列表显示领取时间;每日领取上限本就按 claim_time 计次,不受影响) - `recycle_deadline` — **继续置 null**(PRD §3.4:作废态 N 不跑;且回收扫描 `recycle_deadline