Repository navigation
🔥 Hot Leads 视图的 rating ≥ 4.5 与整星评分/路由流的「hot = rating ≥ 4」不一致：被判定为 hot、发了告警的四星线索永远进不了这个队列 #766
Description
来源：#758（sales 页列表视图重写）核对 src/views/lead.view.ts 时发现。#758 的文件面是文档，不含 src/**，故单独立单。基线 origin/main = c55aaf5。
现状
三处对「hot」的定义不一致：
| 位置 | 判据 |
|---|---|
src/views/lead.view.ts:357-359（hot_leads 视图） |
rating >= 4.5 且 status in [new, contacted] |
src/flows/lead-assignment.flow.ts:61,126（路由流） |
决策节点标题 Hot Lead (rating ≥ 4)?，边 e2 的条件是 record.rating >= 4 —— 命中后写 1 天 SLA 并向负责人发 inbox + email 告警 |
src/objects/lead.hook.ts:144-148（打分钩子） |
Math.round(clamped) —— 只产生整星（1-5），注释写明「round to WHOLE stars」 |
rating 是 Field.rating(5)（lead.object.ts:200），表单用 star_rating 控件，也只给整星。
于是 rating >= 4.5 在实际数据上等价于 rating == 5。后果：一条四星线索会被路由流判为 hot、拿到 1 天 SLA、给负责人发出「Hot lead — assign within 24h」的告警，然后不出现在 🔥 Hot Leads 视图里——它落在 high_priority（rating >= 4）里。收到「24 小时内跟进」告警的人打开 Hot Leads 队列，看不到那条线索。
hot_leads 的注释还说这是「a tighter cut than the High Priority view (rating >= 4) so the two are not duplicates」——意图（更紧的一刀）成立，但用 4.5 表达一个只有整星的量，读起来像是存在半星，且与告警口径分叉。同一处注释里的「(Set by the auto_flag_hot_lead workflow)」也已失效：仓库里没有名为 auto_flag_hot_lead 的 workflow / flow。
影响
用户可见：告警说「这是热线索，24 小时内处理」，产品里的热线索队列却没有它。四星在当前打分权重下并不罕见（computeRating 里一个正经域名 + 电话 + 高级职位 + 高价值行业就到 4）。
修法（需要决定，不要直接猜）
两个方向都自洽，选哪个是产品决定：
- A. 让视图跟随告警口径：
hot_leads改成rating >= 4，与lead_assignment一致；此时它与high_priority的差别只剩排序（按下次跟进日期 vs 按评分着色）和列，需要重新回答「这两个视图是否还该并存」。 - B. 让告警跟随视图口径：路由流的 hot 判据收紧到 5 星，四星走标准 3 天 SLA；此时
hot_leads的阈值应写成>= 5而不是>= 4.5，把「整星」这件事写进条件本身。
无论选哪个，>= 4.5 这个写法都应该消失（对整星字段做半星比较），auto_flag_hot_lead 那句注释应一并删掉或改成真实的自动化名。
文档侧已在 PR（#758）里按现状描述：Hot Leads 记为「实际上的五星队列，四星在 High Priority」。这条 issue 落地后，content/docs/sales/leads.mdx 及其 zh 兄弟页的对应行需要同步。
Refs #758
Activity
yinlianghui commentedon Aug 5, 2026
分诊(PM 循环第 7 轮,会话
session_01VHrPAGEgFDoHjphqYG4BMa):按恢复不变式裁定为 PM 可决,入pm:queue,不进决策收件箱 —— 理由与否决窗口如下:「hot」的定义仓库里只能有一个。语义生产者是
lead_assignment路由流(≥4 → hot SLA + 24 小时认领告警,后果用户可见);hot_leads视图的 4.5 阈值无任何书面理由,且其注释引用一个不存在的auto_flag_hot_leadworkflow —— 这是漂移证据,不是设计意图。被系统宣告为 hot、发过告警的线索永远进不了同名队列,正是 declared ≠ enforced。裁定方向:视图阈值对齐流的 ≥4(一个 hot 定义),同时删掉那条幽灵 workflow 注释;五星专属队列如果是真实需求,应该以自己的名字另立视图,而不是借 Hot 之名。维护者如倾向反向(把流的告警阈值提到 4.5),请在本单否决,派发前会再读本线程。
Generated by Claude Code
yinlianghui commentedon Aug 5, 2026
派发依据:分诊评论已裁定方向(恢复不变式:一个 hot 定义,流是语义生产者)。dev 复核时若发现新证据推翻裁定,照常 premise 报告,不强行执行。
Generated by Claude Code
test(leads): drop the unused high_priority binding from the parity guard
yinlianghui commentedon Aug 5, 2026
✅ 验收通过 — PR #774 已转 ready 并挂 auto-merge(新 head 669918d,CI 9/9 绿)。
判定要点:
lead_assignment路由流(判定带用户可见后果:1 天 SLA + 24 小时认领告警),hot_leads视图从 4.5 改 4 跟随之;high_priority、流本身、其余视图未动。四条前提在 440db01 上逐条复核成立,且找到反向书证(sales.seed.ts:473-478 —— 4.5 曾作为「契约永远产不出的评分」在 Seed data gaps: no line items, no campaign members — CPQ and marketing surfaces are empty on a fresh install #591 被删过一次)。hot_leads与high_priority的过滤条件逐字相同：两个视图是否还该并存是产品决策 #775(finding),本 PR 不删不改high_priority—— 处置正确。AutomationEngine.evaluateCondition);整星断言本身也是派生的(先钉Math.round还在);反真空齐备(子句恰一、阈值必须 number、真值表 hot/非 hot 都必须出现、状态过滤必须含 new);反向验证两次,方向先声明,红的恰是预测的三条/一条。highPriorityView未用变量以删除了结,不造真空断言 —— 对它唯一可写的断言会把 阈值对齐后hot_leads与high_priority的过滤条件逐字相同：两个视图是否还该并存是产品决策 #775 的未决产品决策锁进守卫(无缺陷也变红),注释已写明为何守卫不读high_priority,防止下一个人加回去。断言数保持 16。#766 随本 PR 关闭;#775 入 finding 池(决策项:两视图是否并存)。
Generated by Claude Code
fix(leads): 一个 hot 定义 —— Hot Leads 视图阈值对齐 lead_assignment 路由流（rating …