docs(sales): 按真名写「预测汇总」的仪表盘与报表两条 (#985)

[yinlianghui]

Fixes #985

事实复核（两个源码锚点，逐一重验，均未漂移）

立单正文给出的两条断言在 origin/main（e4d7c43f，即 PR #987 刚落地之后）上完全成立，premise 有效。

锚点一 —— 仪表盘真名

• src/dashboards/sales.dashboard.ts:22 —— label: 'Sales Performance'
• src/apps/crm.app.ts:61 —— { id: 'nav_sales_dashboard', type: 'dashboard', dashboardName: 'sales_dashboard', label: 'Sales Performance', icon: 'chart-line' }

Sales Dashboard 两者皆非：sales_dashboard 是标识符，不是展示名。与 #947 的服务侧不同，这里导航 label 与仪表盘自身 label 是同一个字符串，所以无需 #947 那种「主要指称 + 附注另一个名」的双名处理，一个名写到底即可。

锚点二 —— 报表维度实名

src/reports/opportunity.report.ts:35-:42 逐字：

export const PipelineCoverageByQuarterReport: ReportInput = {
  name: 'pipeline_coverage_by_quarter',
  label: 'Pipeline Coverage by Forecast × Quarter',
  dataset: 'opportunity_metrics', rows: ['forecast_category'], columns: ['close_quarter'], values: ['total_amount', 'opp_count'],
  type: 'matrix',
  runtimeFilter: { stage: { $nin: ['closed_won', 'closed_lost'] } },
};

即预测类别（行）× 结束季度（列）。立单说的「轴写反且写错」两点都对：stage 只出现在 runtimeFilter 里用于排除已结单，根本不是一个轴；而季度是 close_quarter（src/datasets/opportunity.dataset.ts:39，同一 close_date 字段上 dateGranularity: 'quarter' 的专用维度）。

名字一侧同样复核过：侧边栏 Insights 组的条目 label 是 Pipeline Coverage（src/apps/crm.app.ts:153），报表自身 label 是 Pipeline Coverage by Forecast × Quarter —— 两者都真，只是长短不同，所以本 PR 把短名作主要指称、把长名作括注（读者顺 :78 的链接到 Analytics › Reports，看到的正是长名）。

抄平口径

第二条与 PR #975 已写实的 analytics/reports 那一行原本直接矛盾。本 PR 的措辞逐字沿用该行，让两页说同一句话：

页	措辞
analytics/reports.mdx:22（#975 已落地）	a matrix of open pipeline: forecast category down the rows, close quarter across the columns
本 PR pipeline-management.mdx:95	a matrix of open pipeline: forecast category down the rows, close quarter across the columns

中文两页同样抄平各自的对应行 —— zh-Hans 用「行 / 列」（reports.zh-Hans.mdx:22），zh-Hant 用「列 / 欄」（reports.zh-Hant.mdx:22），这是两地对 row/column 的正常译法差异，不是漂移。

三语译法（沿既有落地惯例，非自创）

两个展示名在中文两页保留拉丁原文，与紧邻的 :93（PR #987 刚落地的 **Opportunity Metrics** dataset）同形，也与读者点过去会看到的那几页一致：analytics/dashboards.zh-Hans.mdx:48 的章节标题就是 ## 📈 Sales Performance，analytics/index.zh-Hans.mdx:18、quick-tour.zh-Hans.mdx:55 亦然。此处若译成中文，读者顺链接过去反而对不上标题 —— 与 #947 保留 Customer Service 原文是同一条理由。

未附中文译名括注：语言包只有 zh-CN（src/translations/zh-CN.ts:1193 nav_sales_dashboard: { label: '销售业绩' }），没有 zh-TW/zh-Hant 包，在 zh-Hant 页上写一个繁体译名等于凭空造名。三语一律拉丁原文，同步且零杜撰。

逐处处理

content/docs/sales/pipeline-management{,.zh-Hans,.zh-Hant}.mdx 的 :94 / :95 两行，三语共 6 行。列表形状对齐 :93：真名 + 反引号标识符 + 破折号描述。

- The **Sales Dashboard** widgets (pipeline by stage, win rate, top deals)
- The **Pipeline Coverage** report (quarter × stage matrix)
+ The **Sales Performance** dashboard (`sales_dashboard`) — widgets for pipeline by stage, win rate, top deals
+ The **Pipeline Coverage** report (`pipeline_coverage_by_quarter`, whose own label reads **Pipeline Coverage by Forecast × Quarter**) — a matrix of open pipeline: forecast category down the rows, close quarter across the columns

标识符入正文是有意的：把 sales_dashboard 显式写出来，正好解释了「Sales Dashboard」这个幻名是怎么来的 —— 带着旧名来找的读者一眼看懂那是 id 而非展示名。

括号里那三块磁贴的名字逐字保留未动，按立单「面限两条行族」的边界。实施时逐个核过（见下「越界发现」），结论另立单，不在本 PR 里改。

:93（#987 落地行）逐字未动，零回退 —— 见 diff。src/ 零改动，@objectstack/* 版本零改动，content/docs/releases/ 未触碰。

验证

六道门在共享验证锁 /tmp/os-heavy-verify.lock 内串行跑，全绿：

门	退出码	关键行
pnpm validate	0	✓ Validation passed (1774ms)；5 条 warning 皆为既有的 approval / field-group 提示
pnpm typecheck	0	tsc --noEmit 无输出
pnpm lint	0	13 warning(s), 14 suggestion(s)
pnpm hygiene	0	✓ no raw control bytes in first-party files（扫描面 255 files under src/test/e2e/scripts + 447 under content/.changeset）
pnpm build	0	Artifact: dist/objectstack.json (1921.3 KB)
pnpm test -- --maxWorkers=2	0	Test Files 75 passed (75) / Tests 1757 passed | 1 skipped (1758)

控制字节另做过一次超出 gate 覆盖面的自扫（grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f]'，含 0x01 等 check:nul-bytes 不扫的字节），四个文件全部零命中。

反向验证：预测 GREEN，实测 GREEN（守卫盲区）

方向是先定后跑的，而且这里预测就是「不变红」。#987 新增的守卫 test/docs-analytics-vocabulary.test.ts 是本页最近的一道，先查它的覆盖面再定方向：

• 它的 PAGES 常量（:113-:139）只有 content/docs/analytics/index{,.zh-Hans,.zh-Hant}.mdx 三个文件；
• 唯一全仓遍历的规则是 :310 的 cubes/ 目录扫描，本 PR 两行不含该路径；
• 其余按名指定的载体是 reference/faq、reference/performance-and-limits、reference/glossary 六到九个文件，均不含本页。

全仓 grep -rln "pipeline-management" test/ scripts/ 零命中 —— 没有任何守卫读这三个文件。

把两行还原成幻名（git stash，重扫确认 6 行幻名全部回来，含 :34 / :72 上那两处本 PR 不动的同名残留），再跑四个读 content/docs 的测试文件 + hygiene：

Test Files  4 passed (4)
     Tests  99 passed (99)
DOCGUARDS_REVERSE_EXIT=0
HYGIENE_REVERSE_EXIT=0

改后同样四个文件：4 passed / 99 passed，逐项一致。也就是说这两行的措辞没有任何守卫在读，本 PR 无法被任何现有测试钉红，也不是「我忘了加测试」。

本 PR 未新增守卫：能覆盖它的那条规则是「文档里出现的展示名必须解析到真实 label」这一能力，已作为观察类 finding 记在 #802 / #809 / #867 名下（docs-analytics-vocabulary 也是按页硬编码载体、而非按名解析），在本单里做属于越界。这一段如实写出，而不是造一个「before red / after green」的假证据。

越界发现（已另立 #989，未在本 PR 修）

按立单「不预判括号里三块磁贴」的边界，实施时把它们逐个核了一遍，同时扫到同页另外两处同族失实。均已按 Prime Directive #10 另立 #989（先搜后立：Pipeline Coverage / Sales Dashboard / top deals / Expected Revenue 四轮开放 issue 检索，除 #985 外无命中）：

1. :34 —— 同一个幻名 Sales Dashboard 的第二处，并且「sums Expected Revenue」是假能力：opportunity_metrics 没有任何 measure 读 expected_revenue，仪表盘求的是 total_amount。这条涉及能力主张，是 sales/pipeline-management 剩余的仪表盘/报表指称漂移：:34 的 Sales Dashboard「求和 Expected Revenue」是假能力，:68/:72 的报表表格四行名字对不上，:94 括号里的 top deals 磁贴不存在 #989 里最重的一条。
2. :68 + :72-:76 —— 侧边栏没有 Reports 分组（是 Insights），且五行里四行的报表名对不上真实 label；:72 还带着与 :95 同一处的「quarter × stage」失实。
3. :94 括号里的 top deals —— 不存在，且按 ADR-0021 仪表盘 table 只能聚合、结构性地列不出逐笔排行（sales.dashboard.ts Row 5 注释记录了它被删的经过）。pipeline by stage 与 win rate 两个则逐字为真。

变更集

新增 .changeset/pipeline-management-forecast-rollup-real-names.md（patch）。

---

Generated by Claude Code

[vercel]

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

1 Skipped Deployment

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