Repository navigation
🔥 Hot Leads 视图的 rating ≥ 4.5 与整星评分/路由流的「hot = rating ≥ 4」不一致：被判定为 hot、发了告警的四星线索永远进不了这个队列 #766
Description
Activity
分诊(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
认领:PM 循环(17.0 发布修复线)第 8 轮
会话:session_01VHrPAGEgFDoHjphqYG4BMa
分支:claude/issue-766-hot-leads-threshold
Worktree:hotcrm-issue-766
文件面:src/views/lead.view.ts(hot_leads 过滤阈值 ≥4.5 → ≥4,删幽灵 workflow 注释)、相关测试(建议钉「视图阈值 = 路由流 hot 分支阈值」的一致性)、changeset;若 #768 刚落地的 leads 文档因此需要一句话同步(五星队列表述),同 PR 顺改并说明。⛔ 不动src/views/opportunity.view.ts(#744 同轮在飞)。派发依据:分诊评论已裁定方向(恢复不变式:一个 hot 定义,流是语义生产者)。dev 复核时若发现新证据推翻裁定,照常 premise 报告,不强行执行。
Generated by Claude Code
- added a commit that references this issue
on Aug 5, 2026 ✅ 验收通过 — PR #774 已转 ready 并挂 auto-merge(新 head 669918d,CI 9/9 绿)。
判定要点:
- 裁定执行准确:仓库只留一个 hot 定义,语义生产者是
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 被删过一次)。 - 重叠明写而不藏:改后两视图过滤逐字相同,PR body 直接承认「完全重叠」,以用途(工作队列 vs 速览表)区分;是否并存是产品决策,按越界即停单独立 阈值对齐后
hot_leads与high_priority的过滤条件逐字相同：两个视图是否还该并存是产品决策 #775(finding),本 PR 不删不改high_priority—— 处置正确。 - 守卫质量:16 断言全部从编译后 stack 派生(视图 filter 子句 ↔ 流的 conditional 边 CEL),真值表两侧问真引擎(
AutomationEngine.evaluateCondition);整星断言本身也是派生的(先钉Math.round还在);反真空齐备(子句恰一、阈值必须 number、真值表 hot/非 hot 都必须出现、状态过滤必须含 new);反向验证两次,方向先声明,红的恰是预测的三条/一条。 - CodeQL 收尾处置对:
highPriorityView未用变量以删除了结,不造真空断言 —— 对它唯一可写的断言会把 阈值对齐后hot_leads与high_priority的过滤条件逐字相同：两个视图是否还该并存是产品决策 #775 的未决产品决策锁进守卫(无缺陷也变红),注释已写明为何守卫不读high_priority,防止下一个人加回去。断言数保持 16。 - docs 同步分寸对:只动 docs(sales): 用真实的视图名册重写 accounts / leads / contacts / quotes 四页的「标准列表视图」 #768 三语的 Hot Leads / High Priority 两行(旧阈值描述随本 PR 失效,必须同步);leads.mdx:132 的 SLA 提示本来就对,未动。
- 平台版本未动(17.0.0-rc.2),releases/ 未动,Two source comments still assert the list-view path resolves no date macro — one of them tells the next author not to generalise #744 在飞文件未碰。
#766 随本 PR 关闭;#775 入 finding 池(决策项:两视图是否并存)。
Generated by Claude Code
- 裁定执行准确:仓库只留一个 hot 定义,语义生产者是
- added a commit that references this issue
on Aug 10, 2026
来源：#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）。修法（需要决定，不要直接猜）
两个方向都自洽，选哪个是产品决定：
hot_leads改成rating >= 4，与lead_assignment一致；此时它与high_priority的差别只剩排序（按下次跟进日期 vs 按评分着色）和列，需要重新回答「这两个视图是否还该并存」。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