Repository navigation
automation 三语的「工作流规则」整节讲的是本仓无法编写的元数据，三条「内置示例」其实都是 flow #833
Description
来源：#827（PR 补全同页的内置 flow 表）实施过程中的顺带发现。基线 origin/main = 4c12791。文件面 content/docs/administration/automation.mdx ×3，与 #827 的表格改动不重叠。
事实
src/flows/index.ts 的注释写着 Migrated from object workflows[] (removed in 7.7)。在当前依赖（@objectstack/spec 17.0.0-rc.2）上复核：
grep -rl "WorkflowRule" node_modules/@objectstack/spec/—— 零命中。没有WorkflowRuleSchema，也没有任何WorkflowRule*导出（仅node-executor.zod-*.d.mts的两行注释顺带提到历史枚举名WorkflowAction）。defineStack没有workflows字段；编译后dist/objectstack.json的顶层键里也没有：manifest, translations, i18n, objects, apps, views, pages, dashboards, reports, datasets, actions, flows, positions, permissions, sharingRules, skills, hooks, mappings, data, requires, docs。- 本仓因此 ship 零条 workflow rule。
而 automation 页（三语）仍然：
:10的 callout 写「平台同样支持独立的工作流规则与审批流程元数据 —— 下文一并列出以供参考」。审批流程那半页面自己在:99已经交代过 7.4 移除；工作流规则这半没有任何地方交代。:17「五种类型」表里「工作流规则 | 保存后 | 字段更新、简单的电子邮件提醒」占一行。:40起整节「工作流规则」讲 操作类型（字段更新 / 电子邮件提醒 / 创建任务 / 出站消息）。:51起三条 内置示例，实际都是 flow：- 「评级为 Hot 的潜在客户创建 → 向销售经理发邮件 + 创建 24 小时内确认资格任务」=
lead_assignment（record-after-create） - 「商机赢单，金额 ≥ $100K → 向团队发送庆祝邮件，在 #wins 频道发帖」=
opportunity_won_alert（record-after-update）。顺带：该 flow 只有notify节点，没有任何 Slack/频道投递，#wins这半是凭空的。 - 「案例优先级变更为 Critical → 通知值班工程师」=
case_escalation（record-after-update）
- 「评级为 Hot 的潜在客户创建 → 向销售经理发邮件 + 创建 24 小时内确认资格任务」=
:107/:112的「操作顺序」第 4、6 步，:128的「设置 → 工作流队列」，以及「给管理员的提示」里的「每个条件一个工作流」都建立在这一节上。
影响
#827 补全 flow 表之后，这三条行为在同一页上被归给了两套机制：既是「内置的工作流规则示例」，又是表里的 New Lead Routing & SLA / Large Deal Won Alert / Case Escalation Process 三行。管理员按第一种说法去 Setup 找工作流规则，找不到；按第二种能找到。这正是 #823 在合同页处理过的那类错归（那次是把「激活」从 flow 列表挪回 object hook）。
为什么单独立单
改这一节要先定调，不能顺手猜：
- A. 保留「工作流规则」作为平台能力，只删/改「内置示例」 —— 最小改动，但需要确认平台是否真的还提供这个类型。本仓的证据只覆盖「本仓能否 author」（不能），不覆盖「平台运行时是否还有」。[观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800 是这个坑的现成教训：一句关于 Setup 菜单的「不存在」写过头了，实际平台侧存在。
- B. 整节退休 —— 把「五种类型」收成四种，删掉工作流规则节，「操作顺序」第 4/6 步与「设置 → 工作流队列」跟着改，三条示例并入 flow 那节。与本仓「flow 是唯一多步自动化载体」的实况一致，但改动面横跨半页 ×3 语言。
建议先由维护者在 A / B 之间定调，再派实施。不打 label，留给 triage。
Activity
yinlianghui commentedon Aug 5, 2026
🔒 认领(修复线 PM 派单,测量先行):session_01VHrPAGEgFDoHjphqYG4BMa,分支
claude/issue-833-workflow-rules-section,worktreehotcrm-issue-833。文件面:content/docs/administration/automation.mdx×3(仅「工作流规则」一节及其在「The five kinds」等处的引用)、changeset。裁定(两分支预授权,以实测定):第一步测平台——本仓证据只覆盖「不能 author」(spec 无 WorkflowRule、defineStack 无 workflows 字段),须先确认 rc.2 运行时是否仍提供该能力面(平台包 grep + 起 server 看有无对应端点/元数据类;#800 是把「本仓没有」写成「平台没有」的现成教训)。(a) 平台仍提供、只是本仓未用 → 该节改写为「平台能力、本应用未使用」,删掉三条假示例(它们实为三条 flow,#wins 频道半凭空);(b) 平台已无此类 → 整节按 not-shipped 先例处理或并入 flow 叙述,PR body 写明证据。⚠️ 该页三语刚被 #839 大改(flow 表),基线取最新 main;#839 的表与散文保留。⛔ 不动 src/**。
Generated by Claude Code
yinlianghui commentedon Aug 5, 2026
✅ 实施完成:draft PR #854(session_01VHrPAGEgFDoHjphqYG4BMa,分支
claude/issue-833-workflow-rules-section)。CI 8/8 绿。分支裁定:走 (b) —— 整节退休。 第一步测平台的结果是「平台侧已无此能力面」,不是「平台有、本仓未用」,所以不适用 #755 的 not-shipped 标注风格。
关键证据(完整版在 PR body):
@objectstack/*包里WorkflowRule零命中;同一条 grep 对照FlowSchema63 /ApprovalNode30 /StateMachineSchema40 /JobSchema46 —— 探针没失灵。spec五处自述退休(ADR-0019 / ADR-0020 / v17 移除 REST 挂载与核心服务槽);ObjectSchema现在具名拒绝workflows:/workflow:。platform-objects的 Setupgroup_automation只有 Flows 一项,带注释ADR-0020: no "Workflow Rules" nav。/api/v1discovery 的 15 个服务槽里没有workflow(而realtime/ai/search这些「存在但不可用」的槽是列出来的 —— 缺席即答案);/api/v1/workflow404;automation 服务根只返回{"flows":[…24…]}。Workflow Queue平台树 0 命中 —— 原文「设置 → 工作流队列」指向的页不存在,已删。三条「内置示例」确认就是
lead_assignment/opportunity_won_alert/case_escalation,且描述本身也不成立(#wins频道凭空 —— 该 flow 只有 start/notify/end;「给销售经理发邮件 + 建任务」两半皆无;「值班工程师」实际是案例负责人,正文还写着 "It remains assigned to you.")。因此删除而非改写。同步改到的类目引用与数词:frontmatter description、导语「五种→四种」、类目表、
:10callout(审批那半句同样不成立,整句无法只改一半,一并写实)、操作顺序(删「工作流规则触发」步;原「重新评估最多 5 次」是虚构的,改为引擎实况的重入守卫,与 #701 同一事实)、监控列表、管理员/用户提示 4 处。三语各 47 行,改动形状完全对称。⛔ 未动
src/**、releases、#839 的 flow 表与散文,未加守卫。反向验证方向说明(与模板预设不同,如实报): 把整节原样放回英文页,
automation-docs-coverage守卫预测绿、实测绿(20/20)—— 它锚在## Flows (multi-step)上只读 flow 表,我删的整节在其视野外。这不是凑出来的红,而是证明这类缺陷当前无门禁覆盖;派单要求不加守卫,故只把事实写进 PR。越界发现(已去重后单独立单,均未在本 PR 修):
WorkflowRuleSchema.parse()校验「Workflows」—— 该导出在平台上不存在 #852 ——AGENTS.md:120让 agent 用不存在的WorkflowRuleSchema.parse()finding] 文档指路的 Setup 页名Process Monitor/Scheduled Jobs平台零命中Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
[PM 验收] PR #854 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)
分支裁定审查:采纳 (b) 整节退休。派单预授权的两条分支以测量定夺,而这份测量正是我在认领评论里要求的那种——能把「平台运行时不提供」与「本仓不能 author」区分开:
workflows:是具名拒绝)、platform-objects 的 Setup 导航只有 Flows 且注释点名「no Workflow Rules nav」、真实 server 实测。/api/v1discovery 会列出「存在但本部署不可用」的槽(realtime/ai/search 带 unavailable 状态),而workflow连槽都没有——缺席即答案,排除了「装少插件」的替代解释。这正好规避了 [观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800 的教训(把「本仓没有」写成「平台没有」),这次「平台没有」是独立测出来的。src/**、releases/、docs(automation): 内置 flow 表补齐到 24 条，并把行集/触发面/数词从编译后 stack 派生（#827） #839 的表未动,与申报一致。server 按记录 PID 关停、端口确认关闭、worktree 已清理。越界发现处置(4 单,去重边界已核):#850 / #851 / #852 入队,#853 记 finding,详见各单标签。
Generated by Claude Code
docs(automation): retire the workflow-rules section in all three loca…