flow record trigger: consider multi-event `triggerType` (array / unions beyond create-or-update)

[os-zhuang]

Context

#3427 asked for a way to fire a single record_change flow on both create and update. It was resolved (PR #3446) by adding record-after-write / record-before-write — the create-OR-update union — rather than a general array of triggerTypes.

That was a deliberate, scoped choice:

• write covers the canonical "created or updated" case (mirrors Salesforce's record-trigger option and Rails' after_save), which is the only combination record_change flow start node binds to a single lifecycle event — no create-OR-update in one flow #3427 and industry precedent actually ask for.
• A single canonical token keeps the start-node contract simple (triggerType stays a string), needs no engine/spec change (the engine already forwards any record-* token to the trigger), and avoids N authoring dialects (contract-first, AGENTS.md Prime Directive Add comprehensive test suite for Zod schema validation #12).
• An arbitrary array (triggerType: ['record-after-create', 'record-after-delete']) or other unions (create+delete, update+delete) would add real pipeline complexity — engine parsing string | string[], an ambiguous binding.event, per-event condition/ctx.event semantics — for combinations no concrete scenario needs yet (YAGNI).

The deferred question

Do we ever need record-trigger unions other than create-OR-update — e.g. create+delete, update+delete, or a fully general array?

Promotion criteria (AGENTS.md-style)

Revisit and implement a general multi-event form when two independent real projects need a non-write combination, or when a Tier-1 feature requires it. Until then, the surface stays: the single-op tokens plus the write union.

If we do build it, the likely shape is an array on the start node (triggerType: string | string[]), with the engine expanding it into a binding.events: string[] and the trigger binding one hook per token (the trigger already maps a token → N hook events via triggerTypeToHookEvents, so the trigger side is mostly there).

References

• Issue record_change flow start node binds to a single lifecycle event — no create-OR-update in one flow #3427 (the create-or-update request)
• PR feat(trigger-record-change): record-after-write fires one flow on create OR update (#3427) #3446 (record-after-write implementation)
• packages/triggers/trigger-record-change/src/record-change-trigger.ts (triggerTypeToHookEvents)
• packages/services/service-automation/src/engine.ts (resolveTriggerBinding)

[os-zhuang]

2026-07-25 评估 —— 关闭（not planned，deferral 成立）

今天对本 issue 做了推进评估。结论：暂不开发，按 #3476/#3477 的惯例关闭归档——重启条款 + 预写好的实现方案放在本评论，而不是留一个在 triage 里反复被重新评估的 open issue（本次评估本身就是例证：大半工作是重新推导并确认了 issue 正文里已写明的结论）。

需求核查（推进判据未满足）

• 零需求信号：没有任何 issue / 真实项目提出过非 write 组合（create+delete、update+delete）或数组形态的诉求。
• 唯一有行业先例的联合（create-OR-update）已由 record-{before,after}-write 落地（feat(trigger-record-change): record-after-write fires one flow on create OR update (#3427) #3446），对标 Salesforce record trigger 的 "created or updated" 单选项（delete 在 Salesforce 是独立的 flow 触发类型）与 Rails 的 after_save。行业先例不支持一般化为任意数组。
• 特殊组合今天已有逃生通道：两个 flow 共享同一 subflow；或按 ADR-0077 的意图路由，数据完整性逻辑本就该写在 object 生命周期 hook 层。

重启条款（与原 issue 一致）

当两个独立真实项目需要非 write 组合，或某 Tier-1 特性依赖时，重开本 issue 或带具体场景新开 issue。

预写实现方案（免得下一位评估者重做分析）

Phase 0 — 语义决策（真正的难点，先定）：

• 新增 ctx.operation: 'create' | 'update' | 'delete'，按腿从运行时实际 hook 事件注入；不动 ctx.event（保持 authored token——改它会变更现有全部 write flow 的可观察行为）。
• previous == null 判别法（文档化的 create/update 区分手段，见 changeset previous-null-on-create-leg）在 delete 加入联合后失效——previous != null 在 update 与 delete 之间产生歧义；由 ctx.operation 取代。
• 文档化 delete 腿的 record 形态：删除前的旧行、无 formula 水合（notify node templates can't resolve formula/lookup fields — renders blank silently #3426 的 re-read 明确跳过 afterDelete——行已不存在）。
• 决定 before-* / after-* 是否允许混入同一数组；建议 lint 禁止（语义过于混杂）。

Phase 1 — 管道（机械）：

• engine resolveTriggerBinding：接受 string | string[]，规范化为去重 token 列表，binding 增加 events: string[]（event 作为首元素别名保留一个 major——FlowTriggerBinding 被 trigger 插件结构镜像，直接删字段会破外部 trigger）。
• trigger-record-change：对 events 做 flatMap(triggerTypeToHookEvents) + hook 事件去重（write + create 混写不得对 afterInsert 双绑定）；绑定循环、per-flow packageId、stop() 整体撤销已就绪（原 issue 判断属实：trigger 侧基本现成）。
• buildContext：按腿注入 operation。

Phase 2 — 作者面（两仓）：

• lint：数组逐元素过 record-trigger 语法。
• objectui flow-node-config.ts：triggerType select → 多选 + i18n + FlowCanvas 标签。
• docs（flows.mdx、common-patterns.mdx）、trigger README、skills/objectstack-automation/SKILL.md、showcase 示例、changeset（service-automation minor——binding 结构变化）。

测试门（每个先证明能红）： trigger 单测（数组绑定/去重/stop 全撤）、engine 单测（解析/规范化/audit）、lint 单测、integration（create+delete flow 两腿各 fire 一次且 operation 正确）。

量级估计：语义决策 + 两仓改动 + 文档 ≈ 2–3 天；不是大特性，但每加一种 authoring 形态都是 AI 生成 / lint / 文档对齐的永久表面积税（Prime Directive #12）。

拆出的当下可修缺陷

评估中发现数组形态今天是全链路静默死亡（spec 放行 → engine 折叠成 manual → binding audit 跳过 → #3427 lint 的 typeof === 'string' 收窄看不到）——至今唯一还能绕过全部静默守卫的 authoring 形态。这是缺陷不是特性请求，已拆出 #3481 单独修（纯防御 lint/audit，不引入数组语义）。