Repository navigation
automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851
Description
Activity
[PM 处置] 已入队
pm:queue,方向裁定如下(session_01VHrPAGEgFDoHjphqYG4BMa)申报建议「与 #595 一并 triage」——采纳其精神但不让事实修正等增强决策:两者不互斥。
- 本单方向(PM 可决,按 幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841 口径):文档表行与
opportunity-won-alert.flow.ts的 description 写实当前行为(该 flow 唯一 notify 的收件人只有{record.owner_id};案例升级不改派、不建任务)。不静默删「经理/改派」这些读者可能带着找来的词,指明当前不做、最近的真实机制是什么。 - SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595(让升级真的改派)是行为增强,仍留维护者决策收件箱。若日后采纳,行为变更走独立实现单,文档随之再更新——顺序无依赖,今天先让文档止损。
- 派发排期注意:本单触
automation.mdx三语的 flow 表(docs(automation): retire the workflow-rules section in all three locales (#833) #854 刚动过同页其它节)与src/flows/*.flow.tsdescription,与 automation 三语的「内置模板涵盖潜在客户路由、商机赢单、案例确认、合同激活、续约提醒」—— 本仓一个邮件模板都没有 #834(同页 Email templates 节)互斥,不同轮派发。
异议窗口照旧:维护者任何时点否决即回滚裁定。
Generated by Claude Code
- 本单方向(PM 可决,按 幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841 口径):文档表行与
[PM 认领 · R21] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-851-flow-table-write-real· 文件面:content/docs/administration/automation.mdx×3(仅 flow 表两行的「它做什么」描述)+src/flows/opportunity-won-alert.flow.ts(仅 description 串)+ changeset裁定(已在本单前一评论记录,此处执行细则):
- 写实当前行为(幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841 口径):Large Deal Won Alert——唯一 notify 的 recipients 只有
{record.owner_id},无 manager 寻址;Case Escalation Process——update_record不碰owner_id、无create_record节点,即不改派、不建任务。逐节点重读两条 flow 源码为据。 - 不静默删名:「经理」「改派」「跟进任务」这些读者可能带着找的词,写实句要说明当前不做、SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595(真让升级改派)是尚开放的产品提案——文档不预判其结论。
opportunity-won-alert.flow.ts只动 description 串(元数据散文,非行为);case-escalation 的 flow 文件 description 若同错一并写实——除 description 外src/**零改动。- 守卫面:
automation-docs-coverage派生的是行集/触发面/数词,「它做什么」列是散文(docs(automation): retire the workflow-rules section in all three locales (#833) #854 已证盲区)——预期全绿,如实报;若 description 改动使任何测试红(如 metadata-references 钉了原文),同批同步并说明。 ⚠️ 同页近期高频改动(docs(automation): retire the workflow-rules section in all three locales (#833) #854/docs(automation): 三语写实「电子邮件模板」节末句 —— 本仓不 ship 邮件模板，通知在 flow 的 notify 里 (#834) #864 刚合并):基线取最新 main,重定位行号;⛔ 不碰 Email templates 句(docs(automation): 三语写实「电子邮件模板」节末句 —— 本仓不 ship 邮件模板，通知在 flow 的 notify 里 (#834) #864)、docs(automation): retire the workflow-rules section in all three locales (#833) #854 各节、zh 页 Scheduled automation 段(automation 的 zh-Hans / zh-Hant 缺了英文页「计划类自动化」节的第三段（#615 落地的预测分工说明） #836/crm_opportunity.forecast_category 的 best_case 在 zh 文档有三种写法：包里「最佳情况」，opportunities 写「最佳可能」，automation 写「最好情况」 #845 待派)。
⛔ 不升级 @objectstack/*;不动 releases/;不加守卫;三语同步;changeset 站内路径反引号;控制字节自扫;JSON 报告按标准 schema。
Generated by Claude Code
- 写实当前行为(幽灵字段 Customer Since 的最后 6 处：ai-copilot 两页把「成为客户的日期」写进 Copilot 会读的客户画像（三语） #840/docs(revenue,sales): 按 contract.hook 与续约 flow 写实 Customer Since 幽灵与提醒收件人 (#824) #841 口径):Large Deal Won Alert——唯一 notify 的 recipients 只有
[PM 验收] PR #870 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa;验收时 Playwright 尚在跑,8/9 已绿,合并由 merge queue 的必查项把关,若红会以 CI 事件回到本线处理)
复核结论——本轮最重要的一单,前提部分证伪,dev 的处置正确:
- 成立两项照裁定写实:赢单提醒只发负责人(recipients 实测 + 节点注释自陈 lookup 穿透限制)、案例升级不改派(update 字段集 + 「No owner reassignment」注释 + profile 无 transfer grant 三重佐证);
opportunity-won-alert.flow.ts的 description 一并写实,产物落位复核。 - 「不建任务」一项被证伪,且证据链完整:issue 从 dist 节点表读「无 create_record → 不建任务」,但节点表看不见 hook——flow 刻意不放 task 节点(源码注释写明防重复),任务由
case_status_side_effectshook 在 status→escalated 时创建、归客户负责人,hooks-runtime-service.test.ts:92有现成通过用例钉死。照 issue 与派单字面写会把真话改成假话——dev 按「写实当前行为」的原则覆盖派单字面,是对的。表行最终写法(不改派 + 任务归客户负责人而非资深客服)采纳。 - 派单第二处预设也被纠正:case_escalation 两条 description 核为准确 →
case-escalation.flow.ts零改动,src/**改动面仅一行。两处均记为 issue/派单行文精度问题,非本单前提整体失效。 - 守卫盲区是测出来的:同一规则集在真值相反的两份散文上都绿(stash 反向探针),按边界不补守卫,如实报。
- 「经理/资深客服/跟进任务」三词均保留并写成当前不做/当前归谁;SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判。三语同步;docs(automation): 三语写实「电子邮件模板」节末句 —— 本仓不 ship 邮件模板，通知在 flow 的 notify 里 (#834) #864/docs(automation): retire the workflow-rules section in all three locales (#833) #854 各节未碰。
越界发现处置:#869(两条 flow 的节点 label + JSDoc 仍写未发生的行为;节点 id 承重不可动的边界已写明)入队
pm:queue——与 #851 同族的 authored-metadata 散文修正,待本 PR 落地后可派。
Generated by Claude Code
- 成立两项照裁定写实:赢单提醒只发负责人(recipients 实测 + 节点注释自陈 lookup 穿透限制)、案例升级不改派(update 字段集 + 「No owner reassignment」注释 + profile 无 transfer grant 三重佐证);
来源：#833 实施过程中的顺带发现（为写准退休说明而逐节点读了三条 flow 的编译产物）。基线
origin/main= 3912845。事实
从
dist/objectstack.json（pnpm build产物）逐节点读出的实况：1.
opportunity_won_alert（表行「Large Deal Won Alert」/「大额商机赢单提醒」）表述："When an opportunity over $100K turns Closed Won, notify the owner and their manager"
实况：整条 flow 只有
start/notify/end三个节点，唯一的 notify 配置是只有负责人一个收件人，没有任何经理寻址（无
manager_id、无 position/team 目标）。顺带：flow 自身的
description也这么写 ——"On closed_won opportunities over $100K: notify owner + manager."（src/flows/opportunity-won-alert.flow.ts）。所以表行不是抄错，是忠实抄了 src 里同样不实的描述；修复面跨 src + docs。2.
case_escalation（表行「Case Escalation Process」/「案例升级流程」）表述："When a case turns Critical, reassign to a senior agent, notify, create a follow-up task"
实况：节点为
start/get_record/update_record/notify/end。update_record只写is_escalated/escalation_reason/escalated_date/status，不碰owner_id—— 没有改派。create_record节点 —— 不建任务。{caseRecord.owner_id}，且消息正文自己就说："It remains assigned to you." —— 与「改派给资深客服」直接矛盾。影响
这张表是 #839 专门为「从症状回溯到自动化」建立的唯一入口，其守卫
test/automation-docs-coverage.test.ts派生校验了行集、触发面、两个数词，但 「它做什么」这一列是纯散文，不在派生范围内 —— 所以这两行怎么写都不会红。后果分两层：
is_escalated标记。第二条与 #834（「内置模板涵盖…」但本仓一个邮件模板都没有）属于同一类：文档把「本应有的通知面」写成了既成事实。
修复面（未做，留给 triage）
src/flows/opportunity-won-alert.flow.ts的description。因此本单不打
pm:queue，等定性。Refs #833 #839 #834 #595