docs(automation): retire the workflow-rules section in all three locales (#833)

[yinlianghui]

Fixes #833

分支裁定:走 (b),整节退休

PM 预授权了两条分支,以实测定。测量结果是 (b) —— 平台侧已无此能力面,不是「平台有、本仓未用」,因此该节整体退休,而不是按 #755 的 not-shipped 风格改写成「平台能力、本应用未使用」。

#800 的教训是把「本仓没有」写成「平台没有」。本 PR 的写法反过来受同一条约束:结论确实是「平台没有」,所以证据必须能独立支撑这个更强的判断,而不是从本仓的 author 面推出来。下面是那份证据。

第一步:平台测量(先于任何编辑)

依赖 @objectstack/* 17.0.0-rc.2,50 个包全部已装。

1. 符号面(带反空跑对照)

符号	命中文件数
WorkflowRule	0
FlowSchema	63
ApprovalNode	30
StateMachineSchema	40
JobSchema	46

对照列的意义是:同一条 grep 会找到真实存在的东西。零命中是结论,不是探针失灵。

2. spec 自己交代了五处退休

• kernel/metadata-plugin.zod.ts —— ADR-0020: there is no 'workflow' metadata type(元数据类型清单与类型描述符表各一处)
• stack.zod.ts —— ADR-0020: there is no top-level 'workflows' collection
• automation/node-executor.zod.ts —— 'workflow_rule' retired (ADR-0018 M5 dropped; see ADR-0019),授权范式只剩 flow / approval
• api/protocol.zod.ts / api/router.zod.ts / api/discovery.zod.ts / api/plugin-rest-api.zod.ts —— /api/v1/workflow 挂载与 WorkflowProtocol 在 v17 移除,注释原话 no workflow surface ever existed
• system/core-services.zod.ts —— workflow(Workflow State Machine Engine)核心服务槽位随之退休

另外 data/object.zod.ts 现在把 workflows / workflow 收进了具名拒绝建议表:今天在对象上写这两个键,拿到的是一条点名的报错。

3. Setup 导航(平台自己的 UI 面)

@objectstack/platform-objects 里 group_automation 分组只有一个子项,后面跟着一条注释:

{ id: "nav_flows", label: "Flows", params: { type: "flow" } }
// ADR-0020: no "Workflow Rules" nav — record state machines are a
// `state_machine` validation rule on the object, edited alongside the
// object's other validation rules (not a standalone metadata type).
// ADR-0019: no standalone "Approval Processes" nav — approvals are
// authored as Approval nodes inside a Flow (see nav_flows above).

即:管理员按旧文档去 Setup 找工作流规则,看到的只有 Flows。

4. 真实起服务实测(build 后起,防旧 artifact)

pnpm build 后 objectstack start -p 4833,实测:

• /api/v1 discovery 列出 15 个服务槽 —— metadata, data, analytics, auth, automation, cache, queue, job, ui, realtime, notification, ai, i18n, file-storage, search。没有 workflow。这一条尤其有分量:realtime / ai / search 这些「存在但本部署不可用」的槽是被列出来的(带 status: unavailable 和安装提示),所以缺席本身就是答案,而不是「装少了插件」。
• GET /api/v1/workflow → 404;/api/v1/workflows、/api/v1/metadata/workflow 同为 404。
• automation 服务自己的根 GET /api/v1/automation → {"success":true,"data":{"flows":[…24 条…],"total":24}} —— 只有 flows,没有第二个集合。
• 编译产物 dist/objectstack.json 顶层键无 workflows;全文 16 处 workflow 子串全部无关(视图名 case_workflow、种子数据散文等)。
• 字面串 Workflow Queue 在整个平台包树 0 命中 —— 文档里那条「设置 → 工作流队列」指向的页不存在。

服务用记录到的 PID 关停(监听子进程 27929 按端口反查,未用进程名匹配),端口已确认关闭。

三条「内置示例」的实况

逐节点读编译产物,确认它们就是表里的三条 flow,且描述本身也不准:

文档旧示例	实际 flow	实况
Hot 线索创建 → 给销售经理发邮件 + 建「24 小时内确认资格」任务	lead_assignment / New Lead Routing & SLA	写 next_followup_date,notify 收件人是 {record.owner_id}。没有经理邮件,也没有建任务
赢单 ≥ $100K → 给团队发庆祝邮件,在 #wins 频道发帖	opportunity_won_alert / Large Deal Won Alert	全 flow 只有 start / notify / end 三个节点。没有任何 Slack 投递面,#wins 凭空
案例转 Critical → 通知值班工程师	case_escalation / Case Escalation Process	notify 收件人是案例负责人,正文写着 "It remains assigned to you." 没有值班工程师寻址

所以这三条是删除而不是改写:同页的 flow 表已经在讲这三条行为,示例里那些从未成立的细节没有保留价值。表里那两行自己也有不准之处,但那属于 #839 的表,按派单保留不动,已另立 #851。

本 PR 的改动(三语同步,各 47 行)

• frontmatter description 去掉「工作流规则」
• 导语与小节标题 五种 → 四种,类目表删掉「工作流规则」行
• :10 callout 末句改写。原句「平台同样支持独立的工作流规则与审批流程元数据 —— 下文一并列出以供参考」两个半句都不成立(审批那半同样被 ADR-0019 移除,Setup 也无独立入口),整句无法只改一半,故一并写实
• 删除整个「工作流规则」小节(操作类型 + 三条假示例)
• 「流程(多步骤)」小节开头新增一条指路 blockquote,给带着「工作流规则」这个词进来的读者:平台无此类型、Setup 只有 Flows、对应写法是记录变更类流程、本应用的每一条都在下表
• 操作顺序:删掉「工作流规则触发」一步;原第 6 步「重新评估工作流最多 5 次后停止」是虚构的,改为引擎实况 —— 流程自身的写入是普通保存、会重新进入该顺序,引擎用重入守卫打断自触发环(同一记录在上次运行未结束时重入则跳过并记警告),并点明守卫是兜底而非停止条件(与 [17.0-rc][疑似平台] 记录变更流会因自己的写入重入自身 —— 阻止死循环的是引擎的 loop-breaker,而不是流作者写的 start condition #701 同一事实)
• 「在哪里监控自动化」删掉「设置 → 工作流队列」一条
• 管理员/用户提示里 4 处以工作流规则为前提的措辞改为流程 / 对象钩子

⛔ 未动:src/**、content/docs/releases/、#839 的 flow 表与其散文、任何守卫。

验证

全量四件套 + lint + hygiene,均在共享锁下 NODE_OPTIONS=--max-old-space-size=4096 跑:

validate  exit=0
typecheck exit=0   (tsc --noEmit)
build     exit=0   Logic: 24 Flows · Artifact: dist/objectstack.json (1921.3 KB)
test      exit=0   Test Files 66 passed (66) · Tests 1587 passed | 1 skipped (1588)
lint      exit=0   13 warning(s), 14 suggestion(s)  — 与 main 同
hygiene            ✓ no raw control bytes in first-party files

#839 落的 automation-docs-coverage 守卫单独复跑:Test Files 1 passed (1) · Tests 20 passed (20);与 docs-drift 合跑 53 passed。

控制字符自扫(超出 gate 覆盖面):对四个改动文件跑 grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f]' 零命中,file(1) 对四个文件均报 UTF-8 text(非 data/binary)。

反向验证:方向是「预测绿、实测绿」,不是红

先声明预测再跑:把整节(五种类型、工作流规则行、含 #wins 的假示例)原样放回英文页,automation-docs-coverage 守卫应当保持绿 —— 它的 tableAfter 锚在 ## Flows (multi-step) 上、只读那张 flow 表和两个数词句,我删的整节在它的视野之外。

实测:Test Files 1 passed (1) · Tests 20 passed (20) —— 与预测一致,全绿。随后已还原。

这条如实报成绿,而不是凑一个红:它证明的是本 PR 修的这类缺陷当前无门禁覆盖。派单明确要求本 PR 不加守卫,因此这里不补,只把这个事实写清楚 —— #839 的守卫派生校验了行集、触发面和两个数词,但「它做什么」那一列和表以外的散文都是纯散文,怎么写都不会红(#851 记录的两行错正是活在这条盲区里)。

越界发现(均已去重搜索后单独立单,未在本 PR 修)

• 「工作流规则」在 automation 之外还散布 8 个页族 ×3 语言共 33 处，其中 4 处把可配置项指向了不存在的配置面 #850 —— 「工作流规则」在 automation 之外还散布 8 个页族 ×3 语言共 33 处,其中 4 处把「阈值/收件人在哪配」指向了不存在的配置面
• automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851 —— docs(automation): 内置 flow 表补齐到 24 条，并把行集/触发面/数词从编译后 stack 派生（#827） #839 flow 表两行与 flow 实况不符(赢单提醒不发给经理;案例升级既不改派也不建任务),且 opportunity-won-alert.flow.ts 自身 description 同错
• AGENTS.md 第 120 行让 agent 用 WorkflowRuleSchema.parse() 校验「Workflows」—— 该导出在平台上不存在 #852 —— AGENTS.md:120 让 agent 用 WorkflowRuleSchema.parse(),该导出不存在
• [观察] 文档反复指路的 Setup 页名在平台上都不存在：Process Monitor / Scheduled Jobs 各零命中，真实导航是 Automation→Flows、Developer→Flow Runs #853 —— [观察] 文档指路的 Setup 页名 Process Monitor / Scheduled Jobs 在平台上零命中(打 finding,不入队)

另:#749(sla-and-escalation 链到本页 #case-escalation 锚点)同样落在本页,但本 PR 未新增或删除该锚点,互不影响。

---

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 11:55pm