docs(sales): 把看板列顶合计与 Sales 组两个导航名写实 (#992, #993)

[yinlianghui]

Fixes #992
Fixes #993

两单同族、行集互斥，一次扫平：#992 是 sales/pipeline-management 看板列顶「两个数字」的假能力，#993 是 Sales 组两个非对象导航项的幻名（散在同页与 sales/index）。三语同址同步，src/ 零改动，不触 content/docs/releases/，不动 @objectstack/* 版本。

与刚合并的 PR #990（本页 :94/:95）和 PR #994（本页 :34/:36、报表表格、节奏表、经理提示）行集互斥，两者落地的写法在本 PR 中零回退 —— :53 新增的那句加权预测落点，是照 #994 刚在 :34 立好的口径抄平的。issue 正文给的行号已按 fresh main 重定位（#994 合并后 :48-:51 → :50-:53，:38 → :40，sales/index :64/:65 → :63/:64）。

一、#992 —— 看板列顶「两个数字（未加权 + 加权）」两点都不成立

stale-premise 复核：premise 成立，两条证据都在 fresh main 上逐字复现。

1. 一块看板每列只能有一个合计。 @objectstack/spec 的 KanbanConfigSchema（node_modules/@objectstack/spec/src/ui/view.zod.ts:586-593）把它声明为单数可选字符串，不是数组：

summarizeField: z.string().optional().describe('Field to sum at top of column (e.g. amount)'),

2. 那唯一的一个数求的是 amount。 pipeline_kanban（src/views/opportunity.view.ts:147-157）：

kanban: {
  groupByField: 'stage',
  summarizeField: 'amount',
  columns: ['name', 'crm_account', 'amount', 'close_date'],
},

所以原文两条 bullet 里，未加权那条是真的、加权那条在看板上根本不存在，「两个」本身也是错的。销售代表按现文去列顶找加权合计，读到的是未加权的金额之和 —— 两者之间差着一个概率系数，正是本页上一节《How expected revenue is calculated》讲的那层加权。

改写后：列顶写作「一个数 = 该列金额之和 = 这个阶段的未加权合计」，并写明「一个」是 schema 的形状而非本 app 的取舍；加权预测指回 #994 刚立的落点 —— 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 一致。

zh 内链不带锚：本段引用上一节时用节名指路（《预期营收是如何计算的》/《預期營收是如何計算的》），三语都没有生成 anchor 链接。

二、#993 —— 幻名第三处，逐一归位

真名（src/apps/crm.app.ts，zh 取 src/translations/zh-CN.ts）：

导航项	id	en label	zh-CN label
看板入口	nav_pipeline（:55）	Pipeline	销售管道（:1190）
仪表盘入口	nav_sales_dashboard（:61）	Sales Performance	销售业绩（:1193）

三处逐一：

• sales/index :63 —— Sales Pipeline 是那张视图自己的 label（opportunity.view.ts:150，zh-CN :956 作 销售流水线），不是侧边栏上的字。改为 Pipeline，并把视图 label 与标识符 pipeline_kanban 一并写在同一句里，两个名字各归其位。
• sales/index :64 —— Sales Dashboard 两边都不是：它正是 PR docs(sales): 按真名写「预测汇总」的仪表盘与报表两条 (#985) #990（本页 :94）与 PR docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) #994（本页 :34）已经修掉的那个幻名，这里是第三处。改为 Sales Performance，并按 service/index.mdx:66 已立的写法点名说清「没有任何侧边栏条目叫 Sales Dashboard」—— 幻名以斜体留在页面上指路，不静默删除（service/index 的《Where to find things》(:63-67) 四项与 crm.app.ts 的 Service 分组三项对不上：Service Board 不存在、Tasks 不在这个组、Knowledge 被漏掉、导航项实际叫 Service Overview #927 / PR docs(service): write the index page's 《Where to find things》 list to the real navigation (#927) #932 的约定）。
• pipeline-management :40 —— 「sidebar shortcut Sales Pipeline」明确宣称的是侧边栏上的字，而侧边栏写的是 Pipeline。原句一句话里混了三种指称（Pipeline Kanban 是标识符的驼峰读法、Sales Pipeline 是视图 label、真正的导航名是 Pipeline）。改写后照 content/docs/sales/opportunities.mdx:122 已有的正确口径：视图叫 Sales Pipeline，侧边栏入口叫 Pipeline，两者分开说。

zh 两页一律用语言包里的真 label（销售管道 / 销售业绩 / 销售流水线），繁体只作字形转换、不另造名（沿 PR #990 的处理）；zh-Hant 的「銷售流水線」与 opportunities.zh-Hant.mdx:122 的既有拼法一致。zh-Hans :63 原文的「销售管道」本就等于真导航 label，本 PR 保留该词并补上视图 label 那一半，使三语结构对齐。

验证

六道门全部 exit=0（在共享 flock -w 7200 /tmp/os-heavy-verify.lock 内串行，NODE_OPTIONS=--max-old-space-size=4096）：

门	结果
pnpm validate	✓ Validation passed (1289ms)，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 (1159ms)，artifact 1921.3 KB，exit 0
pnpm test -- --maxWorkers=2	Test Files 75 passed (75)／Tests 1766 passed, 1 skipped (1767)，exit 0

控制字节自扫：对 6 个 mdx + changeset 跑 grep -naP 扫 0x00-0x08 / 0x0b / 0x0c / 0x0e-0x1f，零命中（exit 1）；file 报 Unicode text, UTF-8 text。pnpm hygiene 的扫描面本身覆盖 content 与 .changeset（「255 files under src, test, e2e, scripts; the control-byte scan adds 450 under content, .changeset」→「✓ no raw control bytes in first-party files」）。

守卫盲区：predicted GREEN，并已双向实测。 这两页的导航指称与看板合计口径没有任何 guard 覆盖 —— test/docs-drift.test.ts 的磁贴/仪表盘规则只扫 content/docs/analytics/dashboards*.mdx，test/docs-quick-tour-navigation.test.ts（#960）只钉 quick-tour 一页的侧边栏。全量套件在两种状态下单跑：

• 已修：Test Files 75 passed (75)｜Tests 1766 passed, 1 skipped
• 带缺陷（git checkout origin/main -- content/docs/sales/ 还原后重跑）：Test Files 75 passed (75)｜Tests 1766 passed, 1 skipped

即两种状态同为绿，逐个测试计数都不动。这不是「修好了所以绿」，而是这两族口径根本不在任何门的扫描面上；同理，本次修好之后再漂回去也没有门会红 —— 所以本 PR 不存在 red→green 的方向可报，如实记为 GREEN/GREEN。未为本页新增 guard：那是独立的能力扩张，不在本单面内（#997 里给了一条更合适的落点建议）。

未起任何 dev server；worktree 在 PR 建立后移除。

面外发现（Prime Directive #10，均已另立、未指派、未在本 PR 中修）

开单前均按关键词 + 文件路径检索过 open issues，无重复。

• sales/pipeline-management 看板小节剩余三处（#992/#993 行集之外）：「7 列」、卡片上的 Owner 头像、:86 残留的 Pipeline Kanban 名 #996 —— 同页看板小节 sales/pipeline-management :48-:51：看板列顶「两个数字（未加权 + 加权）」是假能力——kanban 只有一个 summarizeField，且绑的是 amount #992/Sales 组两个非对象导航项被按侧边栏上没有的名字指称：sales/index :64/:65 的 *Sales Pipeline* / *Sales Dashboard*，sales/pipeline-management :38 的「sidebar shortcut Sales Pipeline」 #993 行集之外的三处：:40 的「7 columns — one per stage」（板子自带 stage not_in ['closed_won','closed_lost'] 过滤，源码注释自述「keeps all five active stages visible」，列数取决于 console 渲染器，需浏览器复核）、:42-:46 卡片字段多出的 Owner avatar（kanban.columns 只有四个字段，owner_id 不在卡面上）、:86 仍以 Pipeline Kanban 指称这块板（本 PR 归位了 :40，:86 在面外）。另附一条低置信待核项：:48「the system enforces … you can't drag」对应的 state_machine 规则 severity 是 'warning'。
• sales/index 的《Where to find things》(:62，三语) 漏掉 Sales 组里的 **Account Workbench**，与 quick-tour 已钉全的九项对不上 #997 —— sales/index :62（三语）漏掉 Sales 组九项里的 Account Workbench；quick-tour.mdx:53 已由 getting-started/quick-tour 的导航表（:35-:44，三语）整表失实：8 行里 4 个分组不存在、3 个真实分组缺席、条目名多处对不上 crm.app.ts #960 的守卫钉全九项，两页对新读者的答案不一致。
• 全站 22 个页面把这个应用叫 **Enterprise CRM**，而应用 label（含 app launcher 上的字）是 **HotCRM** —— 全仓零处支持这个名字 #998 —— 全站 22 个文件 25 处把本应用叫 Enterprise CRM，而 app label（含 app launcher 上的字）、语言包、构建产物与 marketplace displayName 一律是 HotCRM；Enterprise CRM 在 src/ 全树零命中。含命名决定，未预判处置方向。

---

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:45pm