Repository navigation
analytics/reports 的「Lead reports」整节失实:三份报表 src/ 里一份都不存在,而仅有的那份没被列出;两行还把导入别名 Working 当成 lead 状态在用 #951
Description
来源:#921 / PR #950 实施过程的卫星命中。清 Working 这个词在 content/ 里的全部命中时,发现它除了 state-machines 页(#921 裁定面,PR #950 已清)之外还落在 content/docs/analytics/reports 上;回源核对那两行所在的表,发现整节比一个词错得更彻底。基线 origin/main = 11f62429(平台 17.0.0-rc.3)。行号为英文页行号,zh-Hans / zh-Hant 同址。
一、入口::31 / :33 把 Working 当 lead 状态用
| **Lead Conversion Funnel** | New → Working → Qualified → Converted |
| **Lead Source ROI** | Volume, conversion rate, and revenue by source |
| **Aged Leads** | Leads in *New* or *Working* status > 30 days |
crm_lead.status 的真实取值是 new / contacted / qualified / unqualified / converted(src/objects/lead.object.ts:191-197)。Working 不是状态,它是 src/mappings/lead_import.mapping.ts 导入别名表里的一行('Working': 'contacted'),产品从不显示这个词。这与 #921 是同一处失真的两个落点,只是 #921 的裁定面是 state-machines 页与 setup 三页,扫不到这里。
二、回源之后:这三份报表在 src/ 里一份都不存在
grep -rn "Lead Conversion Funnel\|Lead Source ROI\|Aged Leads" src/ 零命中。
src/reports/ 一共六个文件,其中 lead 侧只有 lead.report.ts 一份报表:
src/reports/* |
label |
|---|---|
account.report.ts |
Accounts by Industry and Type |
case.report.ts |
Cases by Status and Priority / SLA Performance Report / Cases Opened by Priority × Day |
churn.report.ts |
Customer Churn Signals(含 At-Risk Accounts / Silent High-Value Accounts / Recently Lost Opportunities 三个块) |
lead.report.ts |
Lead Engagement by Month × Source |
opportunity.report.ts |
Opportunities by Stage / Won Opportunities by Owner / Pipeline Coverage by Forecast × Quarter / Opportunity Funnel by Owner → Stage |
也就是说:页面列的三份 lead 报表全是不存在的,而唯一真实发布的 Lead Engagement by Month × Source 在这一节里一次都没出现。这与 PR #939 在 service/cases「Standard list views」那一节处理过的形状完全相同(七个名字里六个不是视图),只是换了一个页面。
三、影响
读者按这一节去找报表,三个名字一个都搜不到;反过来产品里真实存在的那份没人告诉他。:31 / :33 的 Working 更进一步:即使有人想照着 Lead Conversion Funnel 自建一份漏斗,他会按页面去筛一个下拉里根本没有的状态值。
四、修复面(未做)
三语同步,以 src/reports/lead.report.ts 与 src/objects/lead.object.ts 为唯一事实来源重写 ### 🎯 Lead reports 整节 —— 列真实发布的那一份,说清它按什么维度切;不存在的三份按 #939 在 cases 页的口径处理(点名说不存在,并指向真实的替代品,而不是默默删掉)。状态词按 new / contacted / qualified / unqualified / converted 书写。
边界
- 与
administration/state-machines用的一整套状态词在src/里查无此值:lead 的 Working / Disqualified 是导入别名不是状态,opportunity 的 Closed Without Decision 根本不存在,Needs Analysis 被漏掉;:60的「Disallowed」举例反了 #921 /administration/state-machines还剩两处 #920 没枚举到的行为性主张::79-84的四条「The system also enforces」(审批阈值写成 $500K,实际入口是 $100K)、:114-122的 Copilot 一节在src/里零支撑 #940 不重叠:那两单的裁定面是administration/state-machines与administration/setup,PR docs(administration): write the state-machine status vocabulary and the last two behavioural claims to source (#921, #940) #950 已清空,本页不在其中,PR docs(administration): write the state-machine status vocabulary and the last two behavioural claims to source (#921, #940) #950 未动本页。 - 与 「首次响应 SLA」被三处文档写成可度量的目标:setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936 不重叠:「首次响应 SLA」被三处文档写成可度量的目标:setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936 的裁定面是本页的 SLA Performance 那一行(首次响应目标),属 service 报表节;本条是 Lead reports 节。
- 本条只要求把这一节写到
src/,不预判是否应该新增这三份报表(那是产品决策,不是文档失实)。
Activity
yinlianghui commentedon Aug 6, 2026
🔒 已随 #936 三单并单认领(/pm-dispatch R31,session
session_01VHrPAGEgFDoHjphqYG4BMa,分支claude/issue-936-951-952-metrics-claims)——裁定与文件面见 #936 认领评论。Generated by Claude Code
docs(analytics,administration): write the first-response claims, the …