[Decision] A notify node already mails a written-out or computed email address: does ruling 6377842908's 「⛔ 不接受自由文本或表达式拼出的地址」 reach it — refuse both (A), refuse computed addresses only (B), or leave both (C)? #25647

Ruled: 6386629237 · batch #12 item 2 · letter B · 2026-10-24T16:24:48Z (a computed address no user holds fails the node pointing to { emailField }; a written-out address stays an author constant; rides #25571 + a spec describe-text card)

Filing gate ②: only the maintainer can decide this. The dev raised it as an open question on #25610 (report 6384295899, open_questions[2]), and the domain:spec seat 2 review of PR #25645 confirms it. Filed by domain:spec seat 2 (seat post #18549) · sunhaolin · session session_01PC4NPXPgPmpDRG9DdDnyXT. ⛔ Not a claim. Domain and grade are triage's; the seat suggests domain:services (where B and most of A live) and p2 (it limits a path that works today; no new protocol).

Reader who acts: the director seat presents it. After the ruling, the lane that owns the letter acts (see After the ruling).

维护者速读

• 事由： service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25444 的裁决给 notify 加了「收件人取自记录的 email 类型字段」这一新形态（spec(automation): a notify recipient form that is an address from an email-typed field of the triggering record — the protocol half of #25571 (ruling 6377731715, letter B) #25610 / PR feat(spec,lint): a notify recipient form { emailField } — the address in an email-typed field of the triggering record #25645 正在做），执行条件写着「收件人只能来自记录的 email 类型字段，⛔ 不接受自由文本或表达式拼出的地址」。但 notify 今天本来就能把邮件发到一个写死的地址（'ops@example.com'），也能发到一个表达式算出来的地址，只要那个地址不属于任何用户就原样发出去。裁决这句话管不管这条老路，原文没说。
• 要你定： A 两条老路都关（写死的、算出来的都拒绝，外部地址只能走 email 字段）；B 只关「算出来的」（推荐：写死在元数据里的固定地址照发，表达式算出的地址若不属于任何用户就拒绝）；C 都不关，裁决只管新形态。
• 为什么现在定： 按地址限速、写消息日志正在 service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571 里做。现在定下来，service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571 就知道这些要套到哪几条路上；B 的运行时检查也可以和 service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571 落在同一批文件里。

Background

Ruling 6377731715 on #25496 (batch #388 item 4, the maintainer's 「同意」), item 3, verbatim: "#25444 → B. A notify recipient form that is an address taken from an email-typed field of the triggering record — never a free string — rendered through the same templates, subject to the environment's outbound mail configuration, rate-limited per address, written to the messaging log." The governing ruling on the same row, 6377842908 (reconciliation 6377965040), gives the execution condition verbatim: 「收件人只能来自记录的 email 类型字段，⛔ 不接受自由文本或表达式拼出的地址；按地址限速，记消息日志」.

Two paths that exist today put an address no user holds into outbound mail:

• Written out. A string recipient shaped like an email is delivered as a literal address by the email channel: packages/services/service-messaging/src/email-channel.ts about :192, if (EMAIL_SHAPE(recipient)) { … return { address: recipient, … } }. The resolver keeps it verbatim when no user holds it (recipient-resolver.ts about :77, "'<email>' → sys_user lookup by email → id (verbatim on miss)"). The spec docblock names it as an audience selector (packages/spec/src/automation/io-node-config.zod.ts about :277, "team:ID, an email address").
• Computed. A CEL envelope in recipients may evaluate to any string, so { dialect: 'cel', source: 'record.contact_text' } over a free-text field reaches the same branch.

PR #25645 does not touch either path; its Acceptance notes record them.

Governing text: the ruling's 「收件人只能来自记录的 email 类型字段」 and 「⛔ 不接受自由文本或表达式拼出的地址」; facet ③ of the director's increment 6377530193, 「#25444 收件人只许记录的 email 字段，不许自由串」. Read literally, the words cover every recipient. Read in context, they are the execution condition on the new form for #25444, where the risk named is a guest-supplied value turning outbound mail into a relay. The text does not settle which reading holds, so it is raised.

Protocol: A narrows the protocol (Clause-②: yes (narrowing), BREAKING). B narrows a runtime behaviour and the spec describe text, not the accepted shape. C changes nothing but the describe text.

Premises, each with its re-check

• The written-out path delivers: git grep -c "if (EMAIL_SHAPE(recipient))" origin/main -- packages/services/service-messaging/src/email-channel.ts → 1. Control: git grep -c "verbatim on miss" origin/main -- packages/services/service-messaging/src/recipient-resolver.ts → 1.
• In-repo producers of the written-out path: git grep -cE "recipients\s*:\s*\[?\s*['\"][^'\"]*@" origin/main -- examples → 5, all in examples/app-showcase/src/automation/flows/index.ts (admin@objectos.ai ×4, the seeded admin, a user; exec@example.com ×1, no user). Control: git grep -c "recipients:" origin/main -- examples/app-showcase/src/automation/flows/index.ts → 21.
• No in-repo envelope computes an address: every recipients envelope in examples/** reads a user reference (record.assignee, record.owner, task.owner, ownerId, record.account.owner, …). Re-check: git grep -nE "recipients\s*:\s*\[?\s*\{\s*dialect" origin/main -- examples and read each source.

The question

Does the ruling's 「⛔ 不接受自由文本或表达式拼出的地址」 apply to the recipients a notify node already accepts, or only to the new email-field form?

Options

Business meaning: A is a mailroom that only delivers to staff or to an address printed on the customer's own file. B also takes a fixed address the manager wrote on the routing slip, but refuses one the visitor wrote in the margin. C delivers to any address on the slip.

Four axes

• Long-term (leads): B is the shape mainstream platforms settled on. Salesforce email alerts address an outside person through an Email-type field of the record or up to five written-out "additional emails". B makes 「表达式拼出的地址」 false by construction and keeps the authored constant. A goes further than those platforms. C leaves the relay path the ruling names.
• Real business need: the pull behind service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25444 is mailing an applicant (hotsrm), and { emailField } covers it. Mailing a fixed shared mailbox (finance, ops) is a common ask that A would break and B keeps. Nobody in-repo computes an address today, so B refuses nothing anyone has.
• Preventing AI mistakes: under B, an AI that writes record.contact_text as a recipient gets a loud refusal naming the right form. Under C, that config works and opens a relay. Under A, an AI writing an ops alert hits a refusal whose fix (create a user) is heavier than the need.
• Startup focus: C costs a describe sentence. B is one runtime check plus that sentence and could ride service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571. A is a breaking narrowing with migration notes.

Recommendation: B. Two years out, mainstream workflow platforms reach an outside address through an authored constant or an email field (Salesforce email alerts take exactly those two). Confidence gap: whether "free text" in the ruling also meant the authored constant. If it did, the answer is A, and the seat would not argue it. Not A: it removes a common, low-risk need (a fixed mailbox) that the ruling's risk does not cover. Not C: it keeps the exact path the ruling's second clause names.

Self-check: looking at ① alone, B. Do ②③④ flip it? No.

After the ruling

• A: the domain:spec seat files the narrowing card (Clause-②: yes (narrowing), BREAKING, showcase migration), and a domain:services card for the run-time refusal. The PR feat(spec,lint): a notify recipient form { emailField } — the address in an email-typed field of the triggering record #25645 describe text stands.
• B: a domain:services card (or a line in service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571's scope, if that lane takes it) for the run-time refusal of a computed address no user holds. The domain:spec seat files a describe-text card that names the written-out address as a constant and drops "an email address" from the audience-selector list.
• C: a domain:spec describe-text card naming both ways; service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571 applies the rate limit and log to both.

os-decision-facets

• ① 项目长远合理性：B 与主流平台一致（Salesforce 邮件提醒给外部地址发信只走两条：记录的 Email 字段、最多 5 个写死的附加地址），把「表达式拼出的地址」从结构上关掉，同时保留作者写死的常量；A 比主流更紧；C 留着裁决点名的那条转发路。
• ② 实际业务拉动：service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25444 的拉动是给申请人发邮件（hotsrm），{ emailField } 已覆盖；发到固定共享邮箱（财务、运维）是常见需求，A 会打断，B 保留；仓库内没有任何表达式算地址，B 不拒绝任何现有配置。
• ③ 防 AI 犯错：B 下 AI 把 record.contact_text 写成收件人会被响亮拒绝并指向正确形态；C 下这种配置能跑且开出转发口；A 下 AI 写个运维告警就被拒，改法（建用户）比需求重。
• ④ 创业阶段不扩散：C 只改一句描述；B 一处运行时检查加那句描述，可随 service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571 一起落；A 是带迁移说明的破坏性收窄。

Prior rulings read: "notify recipient email address free text expression" → 2 hits (6377731715, 6377842908 on #25496; reconciliation 6377965040; director increment 6377530193); ADR-0012 (recipient resolver), ADR-0030 P1 (the resolver's single home); thread: none (new card)

Dedupe

• Titles of the 100 objectstack-ai/objectstack issues most recently updated since 2026-09-15 (open and closed, repo-scoped issues endpoint), matched on literal, email address, free text, EMAIL_SHAPE, recipient: 3 hits, all this question's lineage (spec(automation): a notify recipient form that is an address from an email-typed field of the triggering record — the protocol half of #25571 (ruling 6377731715, letter B) #25610, service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571, service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25444).
• Semantic issue search "notify recipient literal email address string free text expression refuse": 2 hits, neither this question (spec(automation): a notify recipient form that is an address from an email-typed field of the triggering record — the protocol half of #25571 (ruling 6377731715, letter B) #25610; plugin-email: the Send test email refusals tell the admin to pass "to" in the request body — name the page's control instead (same family as #25345) #25424, a test-email refusal message). Control query "service-messaging notify applicant public form": 7 hits, including service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25444 and service-messaging: a flow notify node can only address system users, so an applicant who came in through a public form never hears "received" or "rejected" #25571.
• New.