Repository navigation
sales/pipeline-management 看板小节剩余三处（#992/#993 行集之外）：「7 列」、卡片上的 Owner 头像、:86 残留的 Pipeline Kanban 名 #996
Description
Activity
🔒 认领(/pm-dispatch R36,与 #997 并单,本单为主单)— session
session_01VHrPAGEgFDoHjphqYG4BMa,分支claude/issue-996-997-sales-pages-final。文件面(×3 语言):#996 的
sales/pipeline-management看板小节三处(:40 列数、:42-:46 Owner avatar、:86 Pipeline Kanban 指称 + 低置信 :48 severity 措辞项)+ #997 的sales/index:62(漏 Account Workbench)——PR #999 刚改过两页,fresh main 重定位、#990/#994/#999 落地行零回退。裁定:
sales/pipeline-management看板小节剩余三处（#992/#993 行集之外）：「7 列」、卡片上的 Owner 头像、:86 残留的 Pipeline Kanban 名 #996 列数条:板子自带 stage not_in 过滤、源码注释自述 keeps all five active stages visible——按证据边界写(元数据侧五个活跃阶段可见;console 渲染器最终列数无浏览器实测条件则不断言具体数字,沿「写实+标注未实测」姿势);Owner avatar 按 kanban.columns 四字段实况;:86 指称沿真名;:48 severity 措辞按 docs(administration): list all five objects that have a state machine (#896) #919/docs(administration): write the state-machine status vocabulary and the last two behavioural claims to source (#921, #940) #950 实测(warning 不阻断)口径核后处理。sales/index的《Where to find things》(:62，三语) 漏掉 Sales 组里的 **Account Workbench**，与 quick-tour 已钉全的九项对不上 #997:补 Account Workbench(crm.app.ts:52,zh-CN 客户工作台),并与getting-started/quick-tour的导航表（:35-:44，三语）整表失实：8 行里 4 个分组不存在、3 个真实分组缺席、条目名多处对不上crm.app.ts#960 守卫已钉的 quick-tour 九项对齐——两页对新读者答案一致化;沿 docs(service): write the index page's 《Where to find things》 list to the real navigation (#927) #932/docs(marketing): name Products in the index page's "Where to find things" (#938) #942 导航清单先例。- SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判;src/ 零改动;三语同步;zh 内链不带锚。
⚠️ 落地后 R37 的 Docs drift (round 2 leftovers): ~39 product pages still name "Sales/Service Copilot" as a persona; config comment and RELEASE_STRATEGY.md still stale #612 将全站扫 Copilot 称谓——你只动本面行族,Copilot 字样如在面内行中出现保持原样留给 Docs drift (round 2 leftovers): ~39 product pages still name "Sales/Service Copilot" as a persona; config comment and RELEASE_STRATEGY.md still stale #612。
Generated by Claude Code
✅ 实施完成 — draft PR #1000(
claude/issue-996-997-sales-pages-final,与 #997 并单)。#996 四条的处置(前提全部核实成立)
条 核实结果 处置 A :40「7 columns」板自带 stage not_in [closed_won, closed_lost];7 个选项中两个永远无卡;源码注释自述 keeps all five active stages visible按证据边界改写:每阶段一列 + 只放在飞交易 + 五个活跃阶段逐个点名;不断言 console 渲染列数,并明写那是渲染器的选择而非本应用声明。沿 opportunities.mdx:122保守口径B :42-:46Owner avatarkanban.columns仅四个字段,owner_id只在视图顶层columns清单改四条;Owner 按 #927/#932 惯例指回 All Opportunities 的 Owner 列与 Deal Cards 图库(注意 Open Deals 并无 Owner 列,未列入) C :86(fresh main 为:85)Pipeline Kanban产品里无此名 「每日」行改指侧边栏条目 Pipeline;en 页全页已无该串 D :48强制力措辞(原标低置信)怀疑成立: severity: 'warning',且prospecting允许集不含closed_won按「advice, not a gate」口径改。佐证无需新探针: administration/state-machines.mdx:100早就明写「an opportunity can go from Prospecting straight to Closed Won … writes one warning to the server log and is then saved」,test/status-state-machines.test.ts:68已把 severity 钉为 warning。是两页互相矛盾,而错的是本页补的守卫:
test/docs-pipeline-kanban-section.test.ts— 卡片 bullet 数 =kanban.columns长度、必须点名被过滤的两个 stage 值与五个活跃阶段、必须带 advisory 措辞与规则名、节奏表「每日」行必须点名侧边栏条目、四条 retired 断言不得复活;源码侧反向钉住(绑 owner 上卡面 / 拿掉过滤器 / 提到error都会红)。反向验证(先判后跑,预测 RED、实测 RED):正文退回 main 只留守卫 →
24 failed | 15 passed,红全部落在读文档的用例上,仍绿的 15 条正是不读文档的 source-facts 块。六道门全 0:validate / typecheck / lint / hygiene / build /
test(77 files passed,1811 passed | 1 skipped)。#960、#987 守卫为本面盲区,单跑确认不触,predicted GREEN 实测 GREEN。⚠️ CI 未派发:PR 建好近半小时,分支上 0 个 workflow run(仅 Vercel 一项)。同仓 #999 的Build and Test日志是Failed to resolve action download info. Error: Service Unavailable—— GitHub Actions 侧的基础设施降级,与本次改动无关;仓库最后一批 PR workflow run 停在 15:45Z。留给 PM 复查。src/零改动,content/docs/releases/未触碰,三语同步,zh 内链不带锚;Sales Copilot字样原样保留给 R37 的 #612。
Generated by Claude Code
🔧 更正上一条评论里的 CI 结论 —— 我报「CI 未派发」报早了。
17:36Z(建 PR 后约 3 分钟)GitHub Actions 已把 7 个 job 全部排上 PR #1000:
Build and Test (22.x)、Quality Checks、Check Changeset、Playwright、link-check、Analyze Code (javascript)、Label Pull Request。所以不是「没派发」,是排队延迟。不过 Actions 侧确实还在降级中:这 7 个 job 排上后十多分钟仍全部停在
queued,一个都没开始跑;同仓 #999 的Build and Test日志是Failed to resolve action download info. Error: Service Unavailable(重试两次后放弃)。所以 #999 上那几个红大概率也不是代码问题。本地六道门的结论不变,全 0:
pnpm validate exit=0 Data: 17 Objects 344 Fields pnpm typecheck exit=0 tsc --noEmit 无输出 pnpm lint exit=0 13 warning(s), 14 suggestion(s) — 与 main 同 pnpm hygiene exit=0 ✓ no raw control bytes in first-party files pnpm build exit=0 ✓ Build complete, dist/objectstack.json (1921.3 KB) pnpm test exit=0 Test Files 77 passed (77) / Tests 1811 passed | 1 skipped (1812)CI 的最终结论请 PM 复查队列跑完后的状态。
Generated by Claude Code
✅ 验收通过(并单 #996+#997)—— PR #1000 已转 ready 并挂 auto-merge(本地六道门全绿 + 新守卫 39 断言;CI 七 job 因 GitHub Actions 降级卡 queued、零失败,由 auto-merge 等检查跑完把关——沿 #995 先例)。
验收要点:
sales/pipeline-management看板小节剩余三处（#992/#993 行集之外）：「7 列」、卡片上的 Owner 头像、:86 残留的 Pipeline Kanban 名 #996 列数条的证据边界执行标准:元数据侧五个活跃阶段写实、console 渲染选择明写「本应用元数据没有声明」;产物反编译线索只进 PR 不进文档——「不足以断言的不写」的分寸精确。- :48 低置信项核实为真并闭环:state-machines.mdx:100 的既有明文 + docs(administration): list all five objects that have a state machine (#896) #919 守卫钉住的 warning 构成决定性佐证(两页矛盾、错的是本页),无需新探针——用已落地资产做证据的效率范本。
- Owner avatar 幻影按四字段实况改写并给真实去处(实测 Open Deals 无 Owner 列故未列——连「指路」本身也复核);
sales/index的《Where to find things》(:62，三语) 漏掉 Sales 组里的 **Account Workbench**，与 quick-tour 已钉全的九项对不上 #997 补 Account Workbench 并写清它是什么,与 quick-tour 九项对齐。 - 两道新守卫含 dev 自抓自修的判据错误(nav_pipeline 的 type='object' 但钉 viewName——切分判据修正且理由入注释);反向 24 红/15 绿边界清晰。
- Copilot 字样按裁定原样留给 Docs drift (round 2 leftovers): ~39 product pages still name "Sales/Service Copilot" as a persona; config comment and RELEASE_STRATEGY.md still stale #612;CI 异常的报告与更正评论处置得当。
零越界发现——发现飞轮首次收敛于零。本单合并后 R36 收官,R37 = #612 终局单随即派出。
Generated by Claude Code
来源：#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