Repository navigation
automation 三语的「内置模板涵盖潜在客户路由、商机赢单、案例确认、合同激活、续约提醒」—— 本仓一个邮件模板都没有 #834
Description
Activity
[PM 认领 · R20] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-834-email-templates-sentence· 文件面:content/docs/administration/automation.mdx×3(仅「电子邮件模板」节那一句)+ changeset裁定与边界:
- 只改那一句,三语同步:写实为——本仓不 author 邮件模板元数据(
dist顶层无emailTemplates),五类业务事件的通知由 flow 的notify节点发出、文案在 flow 里改;合同激活按 docs(contracts): 以 contract.hook.ts 为唯一事实来源重写三语「合同激活时」小节 (#805) #823 结论是 object hook。与同页「流程内的通知由notify节点投递」呼应而非再造一句矛盾。 ⚠️ [观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800 教训(issue 已自带,执行时落实):本仓证据只证明「本仓不 author」,不得断言平台 Setup 无模板页/无平台自带模板。EmailTemplateSchema是平台类型这一事实可如实引用。⚠️ 行号已漂移:issue 基线 4c12791,其后 docs(automation): retire the workflow-rules section in all three locales (#833) #854 重写了同页多节(Email templates 节未动,automation 三语的「工作流规则」整节讲的是本仓无法编写的元数据，三条「内置示例」其实都是 flow #833-dev 已确认)——在最新 main 上重定位重核,前提复核表写进 PR body。- ⛔ 不碰同页 flow 表与 docs(automation): 内置 flow 表补齐到 24 条，并把行集/触发面/数词从编译后 stack 派生（#827） #839 散文(automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851 已裁定另轮处理),不碰 docs(automation): retire the workflow-rules section in all three locales (#833) #854 刚写的各节;不加守卫;
automation-docs-coverage守卫的视野在 flow 表,预期对本句不敏感——如实报。
⛔ 不升级 @objectstack/*;不动
content/docs/releases/;changeset 站内路径反引号;JSON 报告按标准 schema。
Generated by Claude Code
- 只改那一句,三语同步:写实为——本仓不 author 邮件模板元数据(
[PM 验收] PR #864 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)
复核结论:
- 改动面纪律:三语各一句,该节其余四条平台能力 bullet、flow 表、docs(automation): retire the workflow-rules section in all three locales (#833) #854 各节零触碰——与派单边界完全一致。新句与同页「流程内的通知由 notify 节点投递」呼应,消掉了一页之内互相矛盾的一对。
- [观察] PR #762 落地的 integrations 页写「没有 Setup → 集成 菜单」，说法过宽：该分组在平台 Setup 应用里真实存在，plugin-webhooks 等会往里挂条目 #800 边界落实到了字面:主语一律本仓;Setup 模板面正面保留为「去处」;更进一步——dev 发现 issue 括注的
EmailTemplateSchema在 rc.2 已被平台 #4616 改名(canonical 是EmailTemplateDefinitionSchema),于是任何平台标识符都不写进用户文档,用 UI 入口表述。这是把「不写会漂的引用」原则用在了 issue 自己的措辞上,两处纠偏(标识符、数字双单位)都对。 - 合同激活写得比 issue 更强且有据:
contract_on_activation一条通知都不发(hook 源码:77-126只盖 signed_date + 提升 account),真正的合同邮件来自到期/续约两条 flow——三语行标签取自守卫 ROW_LABEL 与表内行文一字不差。 - 不落新数字是正确判断:21/14 与 24/16 双单位都对但都无派生守卫,写进散文就是下一个漂移源。
- 反向探针如实报绿:守卫对这句话零视野(它能活着的原因),按边界不补,只把事实亮出来。
- CI 实测 8/8 绿(head bea8617);文件面 4 个与申报一致。
越界发现处置:#863(同节合并字段示例
{{Opportunity.Name}}用不存在的对象/字段拼写)入队pm:queue——派发时将按 measure-first 框定:先从 spec 的EmailTemplateDefinitionSchema/notification 服务实测{{path}}解析的 data 载荷形状,再定替换文本;dev 已如实注明证据边界(本仓无 sendTemplate 调用方,无法端到端实测渲染)。
Generated by Claude Code
- added a commit that references this issue
on Aug 10, 2026
来源：#827（PR 补全同页的内置 flow 表）实施过程中的顺带发现。基线
origin/main= 4c12791。文件面content/docs/administration/automation.mdx×3（「电子邮件模板」节最后一行），与 #827 的表格改动不重叠。事实
content/docs/administration/automation.mdx:126（zh-Hans:123、zh-Hant:123）：编译后的 stack 里没有邮件模板这一类：
dist/objectstack.json顶层键是manifest, translations, i18n, objects, apps, views, pages, dashboards, reports, datasets, actions, flows, positions, permissions, sharingRules, skills, hooks, mappings, data, requires, docs—— 没有emailTemplates，defineStack也没有这个字段（EmailTemplateSchema在@objectstack/spec里存在，是平台类型，本仓没有 author 任何一条）。这五条业务事件的通知实际是 flow 的
notify节点发的（21 个 flow 文件里 14 个含type: 'notify'），同页 flow 表下方那句「流程内的通知由notify节点投递」说的就是这件事 —— 两句话在同一页上互相矛盾。「合同激活」这一条另有一层：#823 已经确认激活逻辑是 object hook，不是 flow。
影响
管理员按这句话去 设置 → 电子邮件模板 找「续约提醒模板」改措辞，找到的是空列表（或只有平台自带的），改不到实际发出去的文案 —— 那些文案写死在 flow 的
notify节点里。这是这一整节里唯一一句关于 本产品 的断言，其余（合并字段、条件块、HTML + 纯文本、附件）都是平台能力描述。修法建议
只改这一句，不动整节：说清 HotCRM 不 ship 邮件模板元数据，自动化通知由 flow 的
notify节点发出、文案在 flow 里改；需要模板化外发邮件时才用 Setup 的模板surface。注意不要写过头：本仓的证据只证明「本仓不 author 模板」，不证明「平台 Setup 里没有这个页面 / 没有平台自带模板」。#800 就是这个坑 —— 一句关于 Setup 菜单的「不存在」写宽了，实际平台侧存在。
Refs #827 #823 #800