docs(automation): 内置 flow 表补齐到 24 条，并把行集/触发面/数词从编译后 stack 派生（#827）

[yinlianghui]

Fixes #827

零行为变更：src/**、releases/ 一行没碰，flow 元数据逐字节未动。本次只改 content/docs/administration/automation.mdx ×3、一个新测试文件、一个 changeset。

前提复核（在最新 main 上）

git fetch origin main @ 4c12791（issue 写的基线 6f6ed9a 之后 main 已前进）。以 编译后 stack 为准，不数源码文件：

pnpm validate → Logic: 24 Flows
dist/objectstack.json → flows 24

issue 的前提成立，而且比它写的更糟 —— 三语各错一处，且不是同一个数：

页面	表头数词	实际行数	「Schedule 行」数词
automation.mdx	(11)	11	five
automation.zh-Hans.mdx	（10 个）	10	四个
automation.zh-Hant.mdx	（10 個）	10	四個

两个中文页比英文页还少一行（缺 forecast_snapshot，#615 只改了英文页）。

issue 没写、实施中查出来的第二个缺陷：一行的触发面是错的，不是缺失。 campaign_enrollment 原本是周一 9 点的 schedule flow，后来被改写成 screen flow —— 理由写在 src/flows/campaign-enrollment.flow.ts 的文件头：cron 触发不喂任何输入变量（只有 console 的 flow-action 触发器喂），所以每次运行要么匹配不到 campaign，要么把全部开放线索灌进一个 null campaign 然后死在「Campaign required」校验上。三语的表却都还写着 Schedule (Mon 9 AM) / 计划（周一 9 点），而且表下那句数词句把它算进了定时清扫里。管理员照着表去找一个不存在的周一清扫，是能找到「文档依据」的。

git log 佐证：content/docs/administration/automation.mdx 最后一次实质改动是 66fa27f5（#615 加 forecast_snapshot 行），此后 12 条 flow 落地无一进表。

改了什么

表本身（三语）

24 行，按触发面分组（Screen 6 / Record change 9 / Schedule 9），每行的标签用 flow 自己的 label（英文页逐字用，中文页翻译）。这不只是测试便利：label 正是 Setup → 流程监控器 / 计划作业 里显示的名字，所以管理员盯着一次运行记录，可以逐字回到这张表里查。表头因此加了一句说明这件事。

| Campaign Enrollment | Schedule (Mon 9 AM) | 一行改为 | Enroll Leads in Campaign | Screen |。

数词句

• 表头 (11) / （10 个） / （10 個） → (24) / （24 个） / （24 個）。
• 「See the five Schedule rows above (campaign enrollment, contract renewal, SLA monitor, stalled-deal alert, forecast snapshot)」→「The nine Schedule rows above are the complete set; there is no separate scheduled-job metadata to look for」。手写的括号清单删掉了 —— 它正是过期的那半（一个 screen flow 在里面），而且是第二张需要同步维护的花名册。数词保留但被守卫钉住，不再是散文里的裸数字。

新增两段散文

• (on create) 孪生流程：case_escalation / opportunity_approval 各有一条 insert-time 孪生。记录变更类 flow 每条只订阅一种触发类型，所以「新建与后续修改都要管」写成条件相同的一对。它们在流程监控器里就是两次独立运行，所以在表里各占一行而不是合并。
• demo_bootstrap 为什么在表里：issue 把这条留给实施时判断。裁定是列进去，并在散文里注明它是脚手架而非业务自动化。理由是它不是个边界情况：该 flow ship 在 artifact 里，在客户组织里也每十分钟跑一次并写 owner_id（它自己的文件头就是这么说的，test/demo-staffing.test.ts 管着它能写什么）。管理员看到归属按十分钟节拍变动时，需要有一行可查。

中文用词的一处修正

新的营销活动两行用 营销活动 / 行銷活動，不用旧表的「活动」。「活动」是语言包给 crm_event 的标签，而 crm_campaign 是「营销活动」—— 与 #810/#828 对 crm_campaign_member 做的判断同源。旧行「活动登记」正好落在这个撞车上。

守卫（PM 裁定项 2：可行，已做）

新文件 test/automation-docs-coverage.test.ts，20 条。照 #795/#811 的派生-authored 分界。

派生自编译后 stack（stack.flows，不数 src/flows/* 文件 —— 有几个文件各导出两条 flow，这正是 21 个文件 ship 24 条 flow 的原因，也是数文件的读者会得到第三个错误数字的原因）：

• 行集 —— 每条 ship 的 flow 在三页各有且仅有一行；没有任何一行能冒充一条本仓不 ship 的 flow；
• 每行的触发格 —— start 节点的 kind（screen / record change / schedule）、记录变更类的 record-after-create vs record-after-update 半边、定时类的 cron；
• 两个数词 —— 表头的 (24) 与下方的「九个 Schedule 行」。两者都从 stack 算，永远不从解析出来的行数算，所以表与散文无法「互相迁就着一起错」。(11) 就活在这条通道里：它和底下那 11 行完全自洽。

authored（因为派生不出来）：

• 两个中文页的行标签（ROW_LABEL）。flow 在语言包里没有条目 —— src/translations/zh-CN.ts 翻的是对象、字段、视图、action，不含 flow —— 而 zh-Hant 语言包根本不存在。与 sharing-coverage.test.ts 的 ROW_LABEL 同一分界、同一理由。
• 英文行标签不在 ledger 里：英文页逐字用 flow 自己的 label，因此直接对着 stack 校验，比 ledger 强。这也是 docs(sharing): OWD 表对齐注册对象全集，zh 两页带到 #699 的实测口径（#790, #791） #811 的做法（英文页用 stack 派生的 pluralLabel，中文页才退回 ledger）。
• cron 显示文案（CRON_LABEL）与数词字（COUNT_WORD）。未登记的 cron 或数字直接抛错，不静默通过 —— docs-drift.test.ts 给它自己的 CRON_LABEL 定的惯例。

不设 status 过滤，理由写在文件头：行集是 artifact 里的全部 flow。今天 24 条全是 status: 'active'，所以一个 status 过滤会是没人走过的分支。将来真有 draft flow ship，这条守卫会红到有人决定这张表的含义是「本仓 ship 的 flow」还是「会跑的 flow」为止 —— 那才是做这个决定的时候，好过现在凭猜写一个过滤。

过度锁死的评估：一次普通的 flow 改动（改条件、改节点、改文案）不触发任何一条规则。会触发的是三类：新增/删除/重命名一条 flow、改一条 flow 的触发面、改一条定时 flow 的 cron 时刻。这三类都是「不改文档就会让管理员页面变成假话」的改动，正是本次真实发生的两种缺陷。所以是钉住，不是锁死。

反向验证（四个方向，都是先声明方向再跑）

四个方向的预测都写进了测试文件头，与 #795/#811 的体例一致。

方向	预测	实测
1. 把英文表头改回 (11)	只有英文的总数规则转红；所有行规则保持绿，因为没有任何一行动过	1 failed | 19 passed：automation.mdx (en) says 11 built-in flows; the stack ships 24
2. 删掉 zh-Hant 新补的 聯絡人歡迎 行	只有该页行规则转红并点名 flow；两条数词规则都保持绿 —— 数词来自 stack，不来自行	1 failed | 19 passed：contact_welcome: …automation.zh-Hant.mdx (zh-Hant) has no "聯絡人歡迎" row
3. 把过期的 计划（周一 9 点） 触发格放回 zh-Hans 的营销活动行，标签不动	只有触发规则转红；定时数词规则保持绿，因为它数的是 stack 里的定时 flow，从不数表里写着 计划 的行	1 failed | 19 passed：campaign_enrollment: … row "将线索登记进营销活动" trigger cell "计划（周一 9 点）" is missing "屏幕"
4. 加一行本仓不 ship 的 flow	只有幽灵行规则转红	1 failed | 19 passed：automation.mdx (en): row "Territory Rebalance" names no flow this app ships

方向 2 与方向 3 是这套守卫真正买到的东西。方向 3 尤其直白：把过期触发格放回去之后，zh-Hans 表里有 十 行写着 计划，而它下方的散文写「九个」，数词规则依然是绿的 —— 因为它读的是 stack，那是这两个数字唯一真正成立过的地方。方向 2 从另一侧证明同一件事：删掉一整行也不会让数词跟着一起变错。这两条合起来说明行集、触发格与两个数词各自独立钉在同一个派生集上，无法两两迁就。

验证

pnpm validate  ✓ 17 Objects 344 Fields / Logic: 24 Flows（13 条 warning 全为既有的 approval/field-group 提示）
pnpm typecheck ✓ tsc --noEmit 无输出
pnpm lint      ✓ 13 warning(s), 14 suggestion(s)（与 main 同）
pnpm hygiene   ✓ no raw control bytes in source files
pnpm build     ✓ dist/objectstack.json (1921.3 KB)
pnpm test      ✓ Test Files 65 passed (65) / Tests 1580 passed | 1 skipped (1581)

新增 20 条测试（本 PR 之前 1560 条）。改动文件的控制字符自扫（grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f]'，含 changeset 与测试文件）零命中。changeset：.changeset/automation-docs-built-in-flow-table.md（patch，docs + test），站内路径一律反引号、无 markdown 链接语法。

与 #729 的边界

按派单要求未并单：#729 说的是 README 与 marketplace 文档里的数量（15 objects / 23 flows）过期，本 PR 只动 content/docs/administration/automation.mdx 三语 + 测试 + changeset，文件面不重叠。#749（该页缺 #case-escalation 锚点）同样未碰 —— 本 PR 没有新增或改动任何小节标题。

越界发现（均已先搜重、后单独立 issue，未 assign）

• automation 三语的「工作流规则」整节讲的是本仓无法编写的元数据，三条「内置示例」其实都是 flow #833 — automation 三语的「工作流规则」整节讲的是本仓无法编写的元数据类型：@objectstack/spec 17.0.0-rc.2 里 WorkflowRule 零命中，defineStack 没有 workflows 字段，编译产物里也没有这一类；那三条「内置示例」其实分别是 lead_assignment / opportunity_won_alert / case_escalation 三条 flow（#wins 频道那半更是凭空的 —— 该 flow 只有 notify 节点）。本 PR 补全 flow 表之后，同一页把这三种行为同时归给了两套机制。未在本 PR 修：改这一节要先在「保留平台能力只删示例」与「整节退休」之间定调，而本仓的证据只覆盖「本仓能否 author」，不覆盖平台运行时是否还提供 —— [观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800 就是这句话写宽了的现成教训。
• automation 三语的「内置模板涵盖潜在客户路由、商机赢单、案例确认、合同激活、续约提醒」—— 本仓一个邮件模板都没有 #834 — 同页「内置模板涵盖潜在客户路由、商机赢单、案例确认、合同激活、续约提醒」，而编译产物里根本没有邮件模板这一类，那五条通知实际是 flow 的 notify 节点发的（同页下方那句话说的就是这件事，两句在一页上互相矛盾）。
• automation 的 zh-Hans / zh-Hant 缺了英文页「计划类自动化」节的第三段（#615 落地的预测分工说明） #836 — 两个中文页缺英文页「计划类自动化」节的第三段（feat(forecast): add the forecast_snapshot nightly writer (#590) #615 落地的 flow/hook 分工说明，是该页唯一一处讲判据的地方）。与 sharing-and-security 的 zh-Hans / zh-Hant 停在 PR #699 之前：仍承诺「看得到父记录才看得到子行」，相关列表表还缺 Events #791 同族；docs-drift.test.ts 的 callout 平价规则只数 > 块，普通段落在它量程之外。
• [观察] crm_case 在中文文档里有三种叫法：语言包「服务案例」、25 个页面「工单」、14 个页面「案例」（两页同页混用） #837 — [观察] crm_case 在中文文档里三种叫法：语言包「服务案例」、25 个页面「工单」、14 个页面「案例」，两页同页混用。本 PR 重写 24 行标签本是统一口径的机会，但选哪个词是产品用词决策，且只改一页会当场造出新的页间漂移。已打 finding，未打 pm:queue。

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 5, 2026 10:50pm