Skip to content

sales/pipeline-management :48-:51：看板列顶「两个数字（未加权 + 加权）」是假能力——kanban 只有一个 summarizeField，且绑的是 amount #992

Closed
#999
Closed
sales/pipeline-management :48-:51：看板列顶「两个数字（未加权 + 加权）」是假能力——kanban 只有一个 summarizeField，且绑的是 amount#992
#999
Assignees
yinlianghui
Labels
documentationImprovements or additions to documentationpm:dispatchedDispatched to a dev agent by /pm-dispatch

Description

@yinlianghui
yinlianghui
opened on Aug 6, 2026

来源：#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

Activity

  1. yinlianghui
    added
    documentationImprovements or additions to documentation
    pm:queueReady for the PM dispatch loop
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    and removed
    pm:queueReady for the PM dispatch loop
    on Aug 6, 2026
  2. yinlianghui
    self-assigned this
    on Aug 6, 2026

  3. yinlianghui commented on Aug 6, 2026

    @yinlianghui
    yinlianghui
    on Aug 6, 2026 – with Claude
    CollaboratorAuthor

    🔒 认领(/pm-dispatch R35,与 #993 并单,本单为主单)— session session_01VHrPAGEgFDoHjphqYG4BMa,分支 claude/issue-992-993-pipeline-sales-names。

    文件面(×3 语言):#992 的 sales/pipeline-management :48-:51(看板双数字假能力)+ #993 的同页 :38(sidebar shortcut Sales Pipeline)与 sales/index :64/:65(Sales Pipeline / Sales Dashboard 幻名第三处)——PR #994 刚大改 pipeline 页,全部 fresh main 重定位、#990/#994 落地行零回退。

    裁定:

    1. sales/pipeline-management :48-:51：看板列顶「两个数字（未加权 + 加权）」是假能力——kanban 只有一个 summarizeField，且绑的是 amount #992:KanbanConfigSchema.summarizeField 单数、pipeline_kanban 绑 amount——「两个数字(未加权+加权)」写实为每列一个未加权 amount 合计;加权预测落点沿 docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) #994 刚立的口径(两张表格视图列合计)。
    2. Sales 组两个非对象导航项被按侧边栏上没有的名字指称：sales/index :64/:65 的 *Sales Pipeline* / *Sales Dashboard*，sales/pipeline-management :38 的「sidebar shortcut Sales Pipeline」 #993:真名 Pipeline(crm.app.ts:55)与 Sales Performance(:61),opportunities.mdx:122 已有正确口径可抄;三处逐一归位。
    3. stale-premise 先复核;SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判;src/ 零改动;三语同步(繁体不造名);zh 内链不带锚。

    Generated by Claude Code

  4. yinlianghui commented on Aug 6, 2026

    @yinlianghui
    yinlianghui
    on Aug 6, 2026 – with Claude
    CollaboratorAuthor

    ✅ 验收通过(并单 #992+#993)—— PR #999 已转 ready 并挂 auto-merge(本地六道门全绿;CI 报告时零失败、数项排队中,由 merge queue 把关)。

    验收要点:

    1. sales/pipeline-management :48-:51：看板列顶「两个数字（未加权 + 加权）」是假能力——kanban 只有一个 summarizeField，且绑的是 amount #992:schema 形状证据到位(summarizeField 单数、describe 原文),「每列一个数 = 未加权 amount 合计」写实并把「一个」的结构性原因写明;加权落点沿 docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) #994 口径与 opportunities.mdx:120 对齐。
    2. Sales 组两个非对象导航项被按侧边栏上没有的名字指称：sales/index :64/:65 的 *Sales Pipeline* / *Sales Dashboard*，sales/pipeline-management :38 的「sidebar shortcut Sales Pipeline」 #993:三处逐一归位且各有细分(index :63 实为视图 label、:64 两边都不是按斜体点名、pipeline :40 的三种指称混用拆开说)——zh 用语言包真 label(销售管道/销售业绩/销售流水线),繁体只转字形不造名。
    3. 行号按 docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) #994 合并后重定位(:48-51→:50-53 等),docs(sales): 按真名写「预测汇总」的仪表盘与报表两条 (#985) #990/docs(sales): 把 pipeline-management 剩余的仪表盘/报表指称写实 (#989) #994 落地行零回退;predicted GREEN 双向实测如实记录不伪造 red→green。

    越界发现处置:

    Generated by Claude Code

  5. yinlianghui
    closed this as completedin #999on Aug 6, 2026
  6. yinlianghui
    added 2 commits that reference this issue on Aug 10, 2026

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

    aaaed20

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

    b359fac
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationpm:dispatchedDispatched to a dev agent by /pm-dispatch

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions