来源：#992 + #993 并单实施（分支 claude/issue-992-993-pipeline-sales-names）过程中的卫星命中，按 Prime Directive #10 另立。行集与 #992（列顶合计）、#993（:38 的 sidebar shortcut）互斥，也与 #989 / PR #994 互斥。
三语同址（en 行号按 PR #994 落地后的 fresh main；本单未修，行号可能再随本族 PR 位移）。
A. :40「7 columns — one per stage」——看板上最多只可能有 5 个阶段有卡
pipeline_kanban 自带过滤器，把两个已结束阶段整个排除在外（src/views/opportunity.view.ts:160）：
filter: [{ field: 'stage', operator: 'not_in', value: ['closed_won', 'closed_lost'] }],
同处的源码注释把意图写得很直白：
The board is the active working pipeline. Closed business remains in the full book and the dashboard, while excluding it here keeps all five active stages visible at a presentation-friendly width.
OPPORTUNITY_STAGE_OPTIONS（src/objects/_picklists.ts:111-119）确有 7 个选项，但其中 closed_won / closed_lost 两列在这块板上永远拿不到一张卡。
未定的那一半（需要浏览器复核，不要凭静态判断结案）：列是由 groupBy 字段的 picklist 选项生成（那就是 7 列、其中 2 列恒空）还是由数据生成（那就是 5 列），取决于 console 的 kanban 渲染器，不在本仓内。两种结果下现文都需要改：要么写「7 列，其中两列恒空」，要么写「5 列」。content/docs/sales/opportunities.mdx:122 的口径（「one column per stage, open deals only」，不给数字）是可抄的保守写法。
B. :42-:46 卡片字段清单多了一条 Owner 头像
现文说每张卡片显示五项，末条是 Owner avatar。卡面字段由 kanban.columns 决定，只有四个（src/views/opportunity.view.ts:156）：
kanban: {
groupByField: 'stage',
summarizeField: 'amount',
columns: ['name', 'crm_account', 'amount', 'close_date'],
},
owner_id 只出现在视图级的 columns（同文件 :153，供网格/切换器用），不在卡面上。KanbanConfigSchema 对 columns 的 describe 就是 "Fields to show on cards"。
C. :86 仍以 Pipeline Kanban 指称这块板
「每日」那行写作 Open Pipeline Kanban。Pipeline Kanban 是标识符 pipeline_kanban 的驼峰读法，产品里没有任何东西叫这个名字：视图 label 是 Sales Pipeline（opportunity.view.ts:150），侧边栏条目是 Pipeline（crm.app.ts:55）。#993 的 PR 把同页 :40 的这个名字归位了，但行集不含 :86，于是同一页上留了一处孤名。zh 两页 :86 同址作「销售管道看板 / 銷售管道看板」。
D.（低置信，待核）:48「The system enforces the stage rules, so you can't drag …」
阶段跃迁规则确实存在且 prospecting -> closed_won 确实不在允许集里（src/objects/opportunity.object.ts:412-431），但这条规则的 severity 是 'warning'（:415），不是 'error'。若 warning 语义是「提示但放行」，那么「你无法（can't）」就说过头了，应写成「会被提示为非法跃迁」。这一条需要确认平台对 severity: 'warning' 的写入语义后再改，不要照着本段直接动手。
边界
- 均为文档失实，不涉及
src/ 改动（B 若判为「文档写对了、元数据漏了 owner」则另当别论，但那是产品决定，不是本单预设）。
- 三语同址，需同步。
- 无 guard 覆盖：
test/docs-drift.test.ts 的磁贴规则只扫 content/docs/analytics/dashboards*.mdx，test/docs-quick-tour-navigation.test.ts 只钉 quick-tour 一页的侧边栏。本页在带缺陷与已修两种状态下六道门都是绿的。
Refs #992 #993 #989
来源：#992 + #993 并单实施（分支
claude/issue-992-993-pipeline-sales-names）过程中的卫星命中，按 Prime Directive #10 另立。行集与 #992（列顶合计）、#993（:38 的 sidebar shortcut）互斥，也与 #989 / PR #994 互斥。三语同址（en 行号按 PR #994 落地后的 fresh main；本单未修，行号可能再随本族 PR 位移）。
A.
:40「7 columns — one per stage」——看板上最多只可能有 5 个阶段有卡pipeline_kanban自带过滤器，把两个已结束阶段整个排除在外（src/views/opportunity.view.ts:160）：同处的源码注释把意图写得很直白：
OPPORTUNITY_STAGE_OPTIONS（src/objects/_picklists.ts:111-119）确有 7 个选项，但其中closed_won/closed_lost两列在这块板上永远拿不到一张卡。未定的那一半（需要浏览器复核，不要凭静态判断结案）：列是由 groupBy 字段的 picklist 选项生成（那就是 7 列、其中 2 列恒空）还是由数据生成（那就是 5 列），取决于 console 的 kanban 渲染器，不在本仓内。两种结果下现文都需要改：要么写「7 列，其中两列恒空」，要么写「5 列」。
content/docs/sales/opportunities.mdx:122的口径（「one column per stage, open deals only」，不给数字）是可抄的保守写法。B.
:42-:46卡片字段清单多了一条 Owner 头像现文说每张卡片显示五项，末条是 Owner avatar。卡面字段由
kanban.columns决定，只有四个（src/views/opportunity.view.ts:156）：owner_id只出现在视图级的columns（同文件 :153，供网格/切换器用），不在卡面上。KanbanConfigSchema 对columns的 describe 就是 "Fields to show on cards"。C.
:86仍以 Pipeline Kanban 指称这块板「每日」那行写作 Open Pipeline Kanban。
Pipeline Kanban是标识符pipeline_kanban的驼峰读法，产品里没有任何东西叫这个名字：视图 label 是 Sales Pipeline（opportunity.view.ts:150），侧边栏条目是 Pipeline（crm.app.ts:55）。#993 的 PR 把同页 :40 的这个名字归位了，但行集不含 :86，于是同一页上留了一处孤名。zh 两页 :86 同址作「销售管道看板 / 銷售管道看板」。D.（低置信，待核）
:48「The system enforces the stage rules, so you can't drag …」阶段跃迁规则确实存在且
prospecting -> closed_won确实不在允许集里（src/objects/opportunity.object.ts:412-431），但这条规则的severity是'warning'（:415），不是'error'。若 warning 语义是「提示但放行」，那么「你无法（can't）」就说过头了，应写成「会被提示为非法跃迁」。这一条需要确认平台对severity: 'warning'的写入语义后再改，不要照着本段直接动手。边界
src/改动（B 若判为「文档写对了、元数据漏了 owner」则另当别论，但那是产品决定，不是本单预设）。test/docs-drift.test.ts的磁贴规则只扫content/docs/analytics/dashboards*.mdx，test/docs-quick-tour-navigation.test.ts只钉 quick-tour 一页的侧边栏。本页在带缺陷与已修两种状态下六道门都是绿的。Refs #992 #993 #989