Localize the 16 `notify` nodes in all four locales once the platform template channel exists

[os-steve]

Blocked-by: objectstack-ai/objectstack#9205

Problem

16 notify flow nodes (channels: ['inbox','email']) carry inline English title/message literals, so zh-CN / ja-JP / es-ES users receive English notifications from every automation (deal won, SLA breach, escalation, task reminders, contract expiry, …). Unfixable app-side today: NotifyNodeConfig has no template/locale channel and the flows translation surface explicitly excludes notification text — see the measurements in the blocking issue.

Scope (after the platform channel lands)

• Author emailTemplates entries for each distinct notification (dedupe: several nodes share a shape), each in en / zh-CN / ja-JP / es-ES.
• Convert each notify node's inline title/message to the template reference the platform ships.
• Keep the inline-string fallback only where the platform requires it; the PR must verify at least one non-English delivery end-to-end (inbox + email) and state how.

Maintainer ruling, 2026-08-17, PM session chat (verbatim): 「立项，走 emailTemplates 路线」.

Re-check on unblock (the upstream merge may have changed shape): read the landed schema in @objectstack/spec before authoring; grep -rn "type: 'notify'" src/flows/ | wc -l to refresh the node count.

[huangyiirene]

✅ UNBLOCKED — and the capability is already in the version this repo pins. pm:blocked → pm:queue.

Blocked-by: objectstack-ai/objectstack#9205 — closed 2026-08-17 by PR objectstack#9224. Per this lane's charter the unlock predicate is 「消费方可安装」, not 「上游已合并」, so the closure alone does not unblock anything. Measured on the published tarball, which is the only thing this repo can consume:

$ npm install @objectstack/spec@17.1.0
$ grep -c "templateData" dist/automation/index.d.ts
2

NotifyConfigSchema in @objectstack/spec@17.1.0 — the exact version package.json already pins:

declare const NotifyConfigSchema: z.ZodObject<{
    recipients: ...
    title: z.ZodOptional<z.ZodString>;
    message: z.ZodOptional<z.ZodString>;
    template: z.ZodOptional<z.ZodString>;          // <- #9205's deliverable
    templateData: z.ZodOptional<z.ZodRecord<...>>; // <- and its render inputs
    ...
}, z.core.$strict>;

Its doc block names the ruling verbatim: "Localization contract (#9205, ruled 「走 emailTemplates 路线」): template names a sys_email_template bundle … the delivery path resolves (name, recipient locale) per recipient at delivery time via IEmailService.sendTemplate({ template, locale })."

⇒ No pin bump is needed. This is the unusual case where the fix shipped in a release the consumer had already adopted, so the card is dispatchable now. (Contrast #1206, whose predicate is measured on every round and is still unmet — no @objectstack/service-automation above 17.2.0 exists.)

⚠️ One line of this card's own Scope section is falsified by that measurement

The card says: "Keep the inline-string fallback only where the platform requires it." The platform requires the opposite — the two paths are mutually exclusive on a single node, enforced by a superRefine, and the schema is z.core.$strict. From the same doc block:

Inline title/message are the NON-localizable path … The two paths are mutually exclusive on one node (see the superRefine below): runtime precedence would silently ignore one of them, so the ambiguous combination is unrepresentable instead.

So each converted node must drop its inline title/message when it gains a template. Authoring both is not a fallback, it is a parse error. That sentence in the Scope section is superseded by this comment; nothing else in it changes.

Two further facts worth carrying into the work, from the same doc block:

• template is read RAW — a {token} in it is forwarded verbatim, never resolved. It is a static metadata cross-reference, so ⛔ do not try to compute a template name per record.
• templateData values do pass through interpolate(), so {record.x} is legal there. That is where the per-record data goes.

Premise re-verified against origin/main @ f685136, not quoted forward from the card

$ git grep -c "type: 'notify'" origin/main -- src/flows/   →  16 nodes, 14 files
$ git grep -n "template:"      origin/main -- src/flows/   →  0

Stating the reverse lookup so the zero counts: title: over the same paths returns 17 hits, so the grep does reach this code — the zero is a real absence, not a broken pattern. 16 notify nodes, none converted. The card's premise holds in full.

pm:queue, unassigned, no Blocked-by: line remaining. Ruled direction is unchanged and is the maintainer's (2026-08-17, 「立项，走 emailTemplates 路线」).

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 1
Session: session_01STpYzSP2LiZwZinh6m6Qgf
Branch: claude/issue-1185-notify-localization
Worktree: hotcrm-issue-1185
Domain: (hotcrm has no domain:* taxonomy — repo-wide seat, objectstack#10282)
File surface: src/flows/*.flow.ts (the 14 files carrying the 16 notify nodes), the email-template metadata this repo authors, and src/translations/{en,zh-CN,ja-JP,es-ES}.ts (stop on breach; explain in the report)
Container & model: L, mode:subagent, model: opus
Clause-②: no — this repo ships no packages and authors no contract. The card consumes a spec surface that already exists in the pinned 17.1.0; it neither changes accept/reject behaviour nor widens a public face.
Serial constraints cleared: 4 open PRs, all dependabot (#658, #1058, #1178, #1264), none touching src/ — all four are structurally unmergeable pending #1231 and are not moving. No open agent PR in this repo. Batch sibling #1244 takes src/data/revenue.seed.ts only — disjoint. Batch sibling #734 half 1 / #760 is a read-only live-console measurement plus at most src/views/opportunity.view.ts — disjoint. #1207 is serialised BEHIND this card on src/flows/lead-conversion.flow.ts and all four locale bundles, and is deliberately held out of this batch for that reason; it is the next batch's top item, so ⛔ do not opportunistically add duplicate-flag work to those files here.

Read the full issue body and every comment on GitHub yourself before starting, and verify the body is not truncated — a needs-user-decision-shaped sanitizer truncation is not detectable from a dispatch quote, so the completeness check is yours, not mine.

---

Ruling (⛔ not re-adjudicable)

Maintainer, 2026-08-17, PM session chat, verbatim and untranslated: 「立项，走 emailTemplates 路线」

That settles the route: notifications localize through sys_email_template bundles resolved by (name, recipient locale), not by widening the flows translation surface — widening it would overturn #7646, whose guidance block explicitly excludes notification text. ⛔ Do not reopen that comparison, and ⛔ do not add a _notify face to the object translation schema.

PM mechanism assumptions (measured this round — falsify them, and say so if they fail)

These were measured against the published tarball of @objectstack/spec@17.1.0, the version package.json already pins. They are strong, but they are readings, not rulings:

1. The capability is installable now, with no pin bump. NotifyConfigSchema in 17.1.0 declares template: z.ZodOptional<z.ZodString> and templateData: z.ZodOptional<z.ZodRecord<...>>. ⇒ ⛔ Do not bump any @objectstack/* version in this PR. If you find the capability is somehow not reachable at runtime from the installed package, stop and report — a pin bump is a separate card with its own review, never a rider.
2. ⚠️ Inline title/message and template are MUTUALLY EXCLUSIVE on one node, enforced by a superRefine on a z.core.$strict object. The card's own Scope section says "Keep the inline-string fallback only where the platform requires it" — that line is falsified and I have superseded it in a comment on the card. Authoring both on one node is a parse error, not a fallback. Each converted node must drop its inline strings.
3. template is read RAW — a {token} inside it is forwarded verbatim, never resolved, because it is a static metadata cross-reference. ⛔ Do not compute a template name per record. templateData VALUES do pass through interpolate(), so {record.x} is legal there — that is where per-record data goes. This is the load-bearing distinction for the conversion: everything currently interpolated into title/message has to re-enter through templateData.
4. Premise verified on origin/main @ f685136: 16 notify nodes across 14 files; git grep -n "template:" -- src/flows/ returns 0 (reverse lookup: title: returns 17 over the same paths, so the pattern reaches). Nothing is converted yet.

PM's suggested route (optional — measurement beats it)

• Dedupe first. The card says several nodes share a shape; the number of distinct templates is likely well below 16, and each template costs four locale authorings. A smaller, deduped set is the better exemplar.
• Naming: the templates are user-invisible metadata identifiers, so pick names that read as event names (large_deal_won, case_sla_breach) rather than as flow names.
• If a node's inline text carries record interpolation that has no clean templateData shape, that node is the interesting one — report it rather than forcing it.

Non-negotiable for this card

• Verify at least one non-English delivery end-to-end (inbox + email) and state how, per the card's own Scope. A schema that parses is not a delivered notification. If the harness genuinely cannot exercise delivery, say so explicitly and describe what you did verify — ⛔ do not let "the metadata validates" stand in for it silently.
• Gates, read off package.json on origin/main at dispatch time rather than quoted from memory: pnpm verify = validate → typecheck → lint → lint:i18n-gate → hygiene → hygiene:tokens → build → test. Capture exit codes after redirect, never through a pipe.
• ⚠️ hygiene:tokens is a shrink-only ratchet and this card ADDS authored content across four locale bundles. Measure headroom before you start, report before/after, and ⛔ never raise a ceiling — raising one is a maintainer ruling. If you cannot fit, stop and report with the numbers; deduplicating templates is the intended lever, not a bigger ceiling.
• This repo has a changeset gate. changeset-check.yml gates every PR to main on a newly added .changeset/*.md (diffed against the base sha — existing files do not count). The repo is private: true, which does not exempt it. Two legal escapes if this PR publishes nothing: the skip-changeset label, or a changeset with empty frontmatter.
• PR is draft, base main, first body line Fixes #1185 if you convert all 16; if you deliberately convert a subset, it is Part of #1185 and the card stays open — and say which in the report. ⚠️ A squash pulls commit subjects into the merge commit, so ⛔ do not write Fixes #1185 in a commit subject on a Part of PR.

Report

Leave your terminal report as a comment on this issue first (first line the literal os-dev-report), then as your return message — the comment is the record, the message only an accelerator. Machine-checkable fields only: gates with exit codes, ratchet before/after, files_changed, declared deviations, premise_still_valid. ⛔ Do not restate the PR body's narrative.

Also leave your own claim comment — your own session ID and branch, in addition to this one. This claim identifies the PM session, not the agent writing the code, and under a shared GitHub identity the assignee field cannot tell those apart.

premise_still_valid: false with pr: null is a legitimate and sometimes valuable delivery. The issue body is a clue, not a specification — and one line of it is already known to be wrong (assumption 2).

---

Generated by Claude Code