来源：#989 实施过程中的卫星命中。#989 只动它列出的三族（:34、:68/:72-:76 + 截断名、:94 括号），按 Prime Directive #10 另立本单。
三语同址（en 行号，zh-Hans / zh-Hant 同行）。
现文
48 At the top of each column you'll see two numbers:
49
50 - The **unweighted total** (sum of amount)
51 - The **weighted total** (sum of expected revenue)
两点都不成立
1. 看板列顶只有一个数字，不是两个。 kanban 的列顶合计由 summarizeField 一个键决定，spec 里它是 单数可选字符串，不是数组：
@objectstack/spec src/ui/view.zod.ts KanbanConfigSchema：summarizeField: z.string().optional().describe('Field to sum at top of column (e.g. amount)')
所以「两个数字」在这个 schema 下结构性不可能——一块看板每列只能有一个合计。
2. 那唯一的一个数字求的是 amount，不是 expected revenue。 src/views/opportunity.view.ts 的 pipeline_kanban（:147-:157）：
kanban: {
groupByField: 'stage',
summarizeField: 'amount',
columns: ['name', 'crm_account', 'amount', 'close_date'],
},
也就是说 :50 那条（未加权合计 = 金额之和）是真的，:51 那条（加权合计 = 预期营收之和）在看板上根本不存在，:48 的「两个」也是错的。
真正对 expected_revenue 求和的地方
是表格视图的列合计，不是看板：
src/views/opportunity.view.ts:35/:37 —— open_opportunities（label Open Deals）同时对 amount 与 expected_revenue 求和- 同文件
:136/:138 —— all_opportunities（label All Opportunities）同上
content/docs/sales/opportunities.mdx:120 已经把这件事写对了：「Open Deals (the landing view) … Amount and Expected Revenue carry column totals.」本页 :48-:51 与它矛盾。
与 #989 的关系（重要）
#989 正文把 :51 列为「已写对」的参照系，并据此要求 :34 与之对齐。该判断经复核不成立——:51 本身是假能力。#989 的 PR 因此没有引用 :51，而是按上面这条证据把 :34 的落点写成了两张表格视图（与 sales/opportunities.mdx:120 一致）。本单是那次复核的产物，与 #989 的行集互斥（#989 不动 :48-:51）。
读者影响
销售代表按这句话去看板每列顶部找「加权合计」，看板上只有一个数、且是未加权的金额之和——他会把未加权数当成加权数读，两者差着一个概率系数。这正是 #989 第一族在仪表盘上修掉的同一类错误，只是落在了看板上。
边界
- 不涉及
src/ 改动：summarizeField 单值是 spec 的形状，看板绑 amount 是这块板的设计（列顶给一个管道总额），要改的是文档。
- 建议方向：:48-:51 改写成「每列顶部一个合计——该列的金额之和」，并把加权合计指到 Open Deals / All Opportunities 两张表格视图的 Expected Revenue 列合计；措辞留给 triage。
- 三语同址，需同步。
- 没有任何 guard 读本页（
test/docs-drift.test.ts 的磁贴规则只扫 content/docs/analytics/dashboards*.mdx；test/docs-analytics-vocabulary.test.ts 的全树扫描只查 cubes/ 字样）——本条在带缺陷与已修两种状态下六道门都是绿的，回归同样无门可拦。
Refs #989 #985
来源：#989 实施过程中的卫星命中。#989 只动它列出的三族（:34、:68/:72-:76 + 截断名、:94 括号），按 Prime Directive #10 另立本单。
三语同址（en 行号，zh-Hans / zh-Hant 同行）。
现文
两点都不成立
1. 看板列顶只有一个数字，不是两个。 kanban 的列顶合计由
summarizeField一个键决定，spec 里它是 单数可选字符串，不是数组：@objectstack/specsrc/ui/view.zod.tsKanbanConfigSchema：summarizeField: z.string().optional().describe('Field to sum at top of column (e.g. amount)')所以「两个数字」在这个 schema 下结构性不可能——一块看板每列只能有一个合计。
2. 那唯一的一个数字求的是 amount，不是 expected revenue。
src/views/opportunity.view.ts的pipeline_kanban（:147-:157）：也就是说 :50 那条（未加权合计 = 金额之和）是真的，:51 那条（加权合计 = 预期营收之和）在看板上根本不存在，:48 的「两个」也是错的。
真正对 expected_revenue 求和的地方
是表格视图的列合计，不是看板：
src/views/opportunity.view.ts:35/:37——open_opportunities（label Open Deals）同时对amount与expected_revenue求和:136/:138——all_opportunities（label All Opportunities）同上content/docs/sales/opportunities.mdx:120已经把这件事写对了：「Open Deals (the landing view) … Amount and Expected Revenue carry column totals.」本页 :48-:51 与它矛盾。与 #989 的关系（重要）
#989 正文把 :51 列为「已写对」的参照系，并据此要求 :34 与之对齐。该判断经复核不成立——:51 本身是假能力。#989 的 PR 因此没有引用 :51，而是按上面这条证据把 :34 的落点写成了两张表格视图（与
sales/opportunities.mdx:120一致）。本单是那次复核的产物，与 #989 的行集互斥（#989 不动 :48-:51）。读者影响
销售代表按这句话去看板每列顶部找「加权合计」，看板上只有一个数、且是未加权的金额之和——他会把未加权数当成加权数读，两者差着一个概率系数。这正是 #989 第一族在仪表盘上修掉的同一类错误，只是落在了看板上。
边界
src/改动：summarizeField单值是 spec 的形状，看板绑amount是这块板的设计（列顶给一个管道总额），要改的是文档。test/docs-drift.test.ts的磁贴规则只扫content/docs/analytics/dashboards*.mdx；test/docs-analytics-vocabulary.test.ts的全树扫描只查cubes/字样）——本条在带缺陷与已修两种状态下六道门都是绿的，回归同样无门可拦。Refs #989 #985