Skip to content

docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) - #994

Merged
yinlianghui merged 1 commit into
mainfrom
claude/issue-989-pipeline-reference-drift
Aug 6, 2026
Merged

docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989)#994
yinlianghui merged 1 commit into
mainfrom
claude/issue-989-pipeline-reference-drift

Conversation

@yinlianghui

@yinlianghui yinlianghui commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

Fixes #989

同一页上的三族指称漂移,读者按现文在产品里都找不到东西。三语同址同步(en 行号,zh-Hans / zh-Hant 同行),src/ 零改动,不触 content/docs/releases/,不动 @objectstack/* 版本。

与 PR #990(刚合并,改本页 :94 / :95)和 #987(:93)行集互斥,两者落地的写法在本 PR 中零回退 —— coverage 报表的轴、sales_dashboard 的真名与标识符都按 #990 刚落地的措辞抄平。

一、:34 —— 幻名 + 一条源码里给不出的能力

原文:Sales Dashboard sums Expected Revenue across the open pipeline …

两半都不成立:

加权预测这件事在产品里是存在的,落点是表格视图的列合计open_opportunities(label Open Deals)与 all_opportunities(label All Opportunities)各声明了对 expected_revenuesummary: sumsrc/views/opportunity.view.ts:37:138)。content/docs/sales/opportunities.mdx:120 已经这样写了(Amount and Expected Revenue carry column totals),本 PR 与它对齐,并写明仪表盘为什么给不出同一个数。

⚠️ 裁定与实况有一处出入,未按裁定执行

issue 正文与派发裁定都把本页 :51(看板列顶的「加权合计」)当作「已写对」的参照系,要求 :34 与之对齐。复核不成立:kanban 的列顶合计由 summarizeField 一个单数可选字符串决定 —— @objectstack/specsrc/ui/view.zod.tsKanbanConfigSchema 写的是 summarizeField: z.string().optional(),describe 为 Field to sum at top of column —— 而 pipeline_kanban 设的是 summarizeField: amountsrc/views/opportunity.view.ts:147-157)。看板每列只有一个数字,且求的是 amount,:48-:51 的「两个数字」本身就是同一类假能力。

本 PR 因此没有引用 :51,改为按上述源码证据把落点写成两张表格视图;:48-:51 属本单面外,已另立 #992,本 PR 不动它。

二、:68 + :72-:76 报表表格(含 :86 / :87 / :107 / :108 截断名)

:68「You will find these in the Reports section of the sidebar」:侧边栏没有 Reports 分组。分组叫 Insightssrc/apps/crm.app.ts:143-156),且只钉了三张报表 —— Pipeline Coverage、Lead Inflow、SLA Performance —— 外加 CRM Overview 与 Forecasts。本表五行里只有第一行在导航上,其余四张从报表界面进。改写后与 content/docs/analytics/index.mdx:54 的口径(#987 落地)一致,两页不再矛盾。

四行报表名逐字对 src/reports/opportunity.report.ts

原文 真实 label 出处
Pipeline Coverage (Quarter),轴写作 quarter × stage Pipeline Coverage by Forecast × Quarter;轴为 forecast_category(行)× close_quarter(列) :36-:39
Funnel by Owner → Stage Opportunity Funnel by Owner → Stage :50-:51
Opportunities by Stage 逐字正确,未动 :6-:7
Won by Owner Won Opportunities by Owner :19-:20
Customer Churn Signals 逐字正确,未动 churn.report.ts:28-:29

coverage 行的轴按 PR #990 刚在 :95 落地的措辞抄平(未结管道的矩阵:行是预测类别,列是预计成交季度),不再写反的 quarter × stage;同时点明导航项上的短名是 Pipeline Coverage:72 的「3x the quota」是描述业务问题的修辞(没有任何 coverage-ratio 度量),按原样保留,未当事实句处理。

截断名逐处补全::86:107Opportunity Funnel by Owner → Stage:87Won Opportunities by Owner:108 原来的 Pipeline Coverage by Quarter 两边都不是,归到导航名 Pipeline Coverage,与已写对的 :85 一致。

zh 两页里这些报表名原本被意译成中文(销售管道覆盖率 / 按负责人的赢单 …),没有任何翻译文件为它们背书(src/translations/zh-CN.ts 不含报表 label),一并归位为真 label —— 与 content/docs/analytics/reports.zh-Hans.mdx:23 的既有写法一致,不另造名。这一条也覆盖 zh 的 :85:en 的 Pipeline Coverage 本就正确无需动,zh 同址的意译名则需要归位,三语才真正同步。

三、:94 括号里的 top deals

  • pipeline by stage → 真磁贴 Pipeline by Stagesrc/dashboards/shared-widgets.ts:32-36)✓ 逐字未动
  • win rate → 真磁贴 Win Rate (12M)src/dashboards/sales.dashboard.ts:143)✓ 逐字未动
  • top deals不存在,且结构性不可能

仪表盘 table 绑定的是分析 dataset,只能聚合、列不出原始记录(ADR-0021)。src/dashboards/sales.dashboard.ts 第 5 行区(:243-:249)的注释记着这次替换:

// A dashboard `table` binds to an analytics cube and aggregates; it cannot
// list raw deals (ADR-0021). The previous "Top Open Opportunities" table
// selected only `opp_count` with no dimension — one summary row, not a deal
// ranking. Grouping open pipeline by owner yields a rep leaderboard (one
// row per rep). For a per-deal list, surface an object-bound ListView
// through app navigation (ADR-0017).

所以不是「改个名就行」。列表项改为真磁贴 Open Pipeline by Owner,并在列表后新增一段点名说清「为什么不可能有 top deals 磁贴」,把逐笔排行指向商机列表视图 —— 出处(Row 5 注释 + ADR-0021)一并写进正文。

验证

六道门全部 exit=0(在共享 flock -w 7200 /tmp/os-heavy-verify.lock 内串行,NODE_OPTIONS=--max-old-space-size=4096):

结果
pnpm validate ✓ Validation passed (1177ms),exit 0
pnpm typecheck exit 0,无输出
pnpm lint 13 warning(s), 14 suggestion(s),均为既有项,exit 0
pnpm hygiene ✓ source hygiene clean,exit 0
pnpm build ✓ Build complete (1155ms),exit 0
pnpm test -- --maxWorkers=2 Test Files 75 passed (75)/Tests 1757 passed, 1 skipped (1758),exit 0

控制字节自扫:对三个 mdx 跑 grep -naP 扫 0x00-0x08 / 0x0b / 0x0c / 0x0e-0x1f 零命中;pnpm hygiene 的扫描面本身覆盖 content.changeset("255 files under src, test, e2e, scripts; the control-byte scan adds 448 under content, .changeset" → "✓ no raw control bytes in first-party files")。

守卫盲区,如实报 predicted GREEN 并已实测:本页没有任何 guard 覆盖这两族词汇 —— test/docs-drift.test.ts 的磁贴/仪表盘规则只扫 content/docs/analytics/dashboards*.mdxDOC_PAGES),test/docs-analytics-vocabulary.test.tswalk(DOCS_ROOT) 全树,但对全树只查 cubes/ 字样一条。两个套件单跑:

  • 带缺陷(git stash 回到 origin/main 的三页):Test Files 2 passed (2)|Tests 73 passed (73)
  • 已修:Test Files 2 passed (2)|Tests 73 passed (73)

两种状态同为绿。这不是「修好了所以绿」,而是这两族词汇根本不在任何门的扫描面上;同理,本次修好之后再漂回去也没有门会红。没有为本页新增 guard —— 那是独立的能力扩张,不在本单面内。

与刚合并的 #991 的兼容#991 给 docs-drift 加了「产品文档里 src/<dir>/ 必须存在」的新规则,而本 PR 新增了三处这类引用(src/views/src/apps/src/dashboards/)。把 #991 版本的 docs-drift.test.ts 取到本分支上单跑:本页相关断言全过,6 条失败全部落在 for-developers.mdx 上 —— 那是本分支还没有 #991 同 PR 的页面修正所致,合并后即消失。

未起任何 dev server;worktree 已 git worktree remove

面外发现(Prime Directive #10,均已另立且未指派)

两条在开单前均已按关键词 + 文件路径检索过 open issues,无重复。

同一页上三族指称漂移,读者按现文在产品里都找不到东西。三语同步,
`src/` 零改动。

一、:34 的「Sales Dashboard 求和 Expected Revenue」两半都不成立。幻名是
PR #990 刚从同页 :94 修掉的那个(真身 sales_dashboard,label 与 Sales 组
导航项都是 Sales Performance)。能力那半更重:opportunity_metrics 没有
任何 measure 读 expected_revenue,它暴露的金额类度量 total_amount /
avg_amount / won_amount / lost_amount 一律 field: 'amount'
(src/datasets/opportunity.dataset.ts:44-91),所以 Total Pipeline 磁贴给的是
未加权的管道总额。真正对 expected_revenue 求和的是两张表格视图 ——
open_opportunities (Open Deals) 与 all_opportunities (All Opportunities) 各
声明 { field: 'expected_revenue', summary: 'sum' }
(src/views/opportunity.view.ts:37, :138),也正是
content/docs/sales/opportunities.mdx:120 已经写对的那件事。现改为指向列表
视图,并写明仪表盘为什么给不出同一个数。

二、:68 的「Reports 分组」侧边栏上没有:分组叫 Insights
(src/apps/crm.app.ts:143-156),只钉了 Pipeline Coverage / Lead Inflow /
SLA Performance 三张报表,外加 CRM Overview 与 Forecasts,所以本表五行里
只有第一行在导航上。四行报表名按 src/reports/opportunity.report.ts 的真实
label 补全(Pipeline Coverage by Forecast x Quarter、Opportunity Funnel by
Owner -> Stage、Won Opportunities by Owner),coverage 行的轴按 PR #990 刚在
:95 落地的写法抄平(行是预测类别、列是预计成交季度),不再写反的
quarter x stage。:86 / :87 / :107 / :108 的截断名同步补全;:108 原来的
Pipeline Coverage by Quarter 两边都不是,归到导航名 Pipeline Coverage,与
:85 一致。zh 两页里被意译成中文的报表名同样归位 —— 没有任何翻译文件为它们
背书。

三、:94 括号里的 top deals 磁贴不存在,且改名也救不了:仪表盘 table 绑的是
分析 dataset,只能聚合、列不出原始记录 (ADR-0021),原先那块
Top Open Opportunities 正因此被换成按负责人聚合的 Open Pipeline by Owner,
经过记在 src/dashboards/sales.dashboard.ts 第 5 行区的注释里。现点名说清
并把逐笔排行指向商机列表视图。同括号里的 pipeline by stage 与 win rate 逐字
为真(shared-widgets.ts 的 Pipeline by Stage、sales.dashboard.ts:143 的
Win Rate (12M)),未动。

六道门全绿(validate / typecheck / lint / hygiene / build / test 均 exit 0,
75 个测试文件 1757 passed)。守卫盲区如实记录:docs-drift 的磁贴规则只扫
analytics/dashboards*.mdx,docs-analytics-vocabulary 的全树扫描只查 cubes/
字样,两者在带缺陷与已修两种状态下都是 73/73 绿 —— 本页的仪表盘/报表词汇
无门可拦。

复核中另发现两条本单面外的缺陷,已按 Prime Directive #10 另立:#992
(:48-:51 看板列顶「两个数字」是假能力,kanban 只有一个 summarizeField 且绑
amount;#989 正文把 :51 当作已写对的参照系,该判断不成立,故本 PR 未引用
:51)、#993 (Sales 组两个非对象导航项在 sales/index 与本页 :38 被按侧边栏上
没有的名字指称)。

Claude-Session: https://claude.ai/code/session_01VHrPAGEgFDoHjphqYG4BMa

Co-authored-by: Claude <noreply@anthropic.com>
@vercel

vercel Bot commented Aug 6, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
hotcrm Ignored Ignored Aug 6, 2026 3:21pm

Request Review

@yinlianghui
yinlianghui marked this pull request as ready for review August 6, 2026 15:25
@yinlianghui
yinlianghui added this pull request to the merge queue Aug 6, 2026
Merged via the queue into main with commit aaaed20 Aug 6, 2026
9 checks passed
yinlianghui added a commit to yinlianghui/hotcrm that referenced this pull request Aug 10, 2026
…-ai#993) (objectstack-ai#999)

两单同族、行集互斥,一次扫平。三语同步,`src/` 零改动。

一、objectstack-ai#992:pipeline-management「看板列顶两个数字(未加权 + 加权)」两点都
不成立。看板列顶只能有一个数:@objectstack/spec 的 KanbanConfigSchema 把
summarizeField 声明为单数可选字符串(src/ui/view.zod.ts:591,describe 写作
"Field to sum at top of column"),不是数组;而 pipeline_kanban 把它绑到
amount(src/views/opportunity.view.ts:155)。所以未加权那条是真的、加权那条
在看板上根本不存在,「两个」也是错的。销售代表按现文去列顶找加权合计,读到
的是未加权的金额之和,两者差着一个概率系数。现改写为「每列一个数 = 该列
金额之和」,并把加权预测指回 PR objectstack-ai#994 刚在 :34 立好的口径 —— open_opportunities
(Open Deals) 与 all_opportunities (All Opportunities) 各声明
{ field: 'expected_revenue', summary: 'sum' }(同文件 :37、:138),与
content/docs/sales/opportunities.mdx:120 一致。

二、objectstack-ai#993:Sales 组两个非对象导航项的幻名第三处。真名在
src/apps/crm.app.ts:nav_pipeline 的 label 是 Pipeline(:55),
nav_sales_dashboard 的是 Sales Performance(:61);zh-CN 语言包对应
销售管道 / 销售业绩(src/translations/zh-CN.ts:1190、:1193)。
sales/index :63/:64 的 Sales Pipeline / Sales Dashboard 两条都不是侧边栏上的
字 —— 前者是那张视图自己的 label(opportunity.view.ts:150),后者两边都不是,
正是 PR objectstack-ai#990(:94)与 PR objectstack-ai#994(:34)已修掉的同一个幻名。pipeline-management
:40 的「sidebar shortcut Sales Pipeline」同理。三处一律按
opportunities.mdx:122 已有的正确口径处理:视图名与导航名分开说。zh 两页用
语言包里的真 label,繁体只作字形转换,不另造名。

六道门全绿(validate / typecheck / lint / hygiene / build / test 均 exit 0,
75 个测试文件 1766 passed | 1 skipped)。守卫盲区如实记录:docs-drift 的
磁贴规则只扫 analytics/dashboards*.mdx,docs-quick-tour-navigation 只钉
quick-tour 一页的侧边栏,两页的导航指称与看板合计口径无门可拦 —— 带缺陷与
已修两种状态下六道门都是绿的,故本 PR 预测且实测为 GREEN,不存在 red→green
的方向可报。

复核中另发现三条本单面外的缺陷,已按 Prime Directive objectstack-ai#10 另立、未在本 PR
中修:objectstack-ai#996(同页看板小节的 7 列 / Owner 头像 / :86 残留的 Pipeline Kanban
名)、objectstack-ai#997(sales/index :62 三语漏 Account Workbench)、objectstack-ai#998(全站 22 页把
应用叫 Enterprise CRM,真 label 是 HotCRM)。

Claude-Session: https://claude.ai/code/session_01VHrPAGEgFDoHjphqYG4BMa

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants