crm-backend-matt/.scratch/clue-module/prototype-statemachine

线索状态机原型（throwaway）

这是可丢弃的原型代码，不是生产代码。 验证完把结论折回 spec，壳丢到废弃分支。

问题

crm-lead 的 7 状态机 + 双计时器在纸上（线索业务-PRD.md §3/§5、issues/03）看起来自洽，但几条边组合在一起时容易藏矛盾。本原型手动驱动状态机，逐步打印 (状态, owner, recycle_deadline, expire_deadline)，把难推的序列跑一遍，回答：

1. 作废回环是否自洽？已领取/跟进中 →[反馈=无效]→ 作废(清owner) →[管理员分配]→ 作废(写owner) →[反馈=有效]→ 已领取。中途失效计时 M 持续跑会不会把作废线索"跑成"过期失效？两个态叠加时谁赢？
2. 双计时器独立性：回收 N（领取起、反馈续期、释放/回收/转商机清零）与失效 M（创建起、持续跑、仅激活重置）在同一条线索上并行，边的副作用有没有互相踩。
3. 激活 F2：过期失效 → 恢复失效前态 + 原 owner + 同时重置 N 和 M。失效前若在待领取（无 owner），恢复后 owner 应为空——恢复"失效前态"这一步记得住吗？
4. 终态冻结：已转商机后 tick 时钟，N/M 是否真的都不再触发。
5. 失效发生在私海：已领取态失效，owner 应保留、只读。

逻辑与壳的边界

• lead-machine.js — 纯 reducer，(state, event) => nextState，无 I/O、无终端码。这是将来迁移进 Java LeadStateMachine 的部分，语言无关。
• tui.js — 丢弃的终端壳，只负责读键、调 reducer、重画整帧。

跑

node .scratch/clue-module/prototype-statemachine/tui.js

时钟是逻辑时钟（now 是整数“天”），按 t 走一天，方便观察计时器到期。