docs(configure): the notification template locale is the notification's, not the recipient's

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code

[os-bill]

Fixes#246

The Notification Templates field table told an admin that a template's locale is "matched to the recipient". The delivery path never reads a recipient locale, so authoring es and en rows for a topic cannot give two recipients their own languages — it gives whichever locale the producer named.

What changed

content/docs/configure/notifications.mdx, two edits carrying one claim:

• The field-table row now reads Locale of this rendering — the notification's own, not the recipient's.
• A paragraph after the table carries the consequence: the locale is payload.locale when the producer sets one, else the deployment default, and one emit renders in a single locale for every recipient it reaches.

The wording is aligned to upstream's own phrasing at messaging-service-plugin.ts:250 — "one locale per notification: payload.locale, else the deployment default" — rather than a third coinage.

This reports the wiring as it stands. It makes no forecast about recipient-locale matching, and it does not touch the question of whether the platform should match on recipient locale — that is a product question and a different card.

Upstream re-trace

Re-measured on objectstackorigin/main @ 2514d49. The card measured 9e0ba21 and dispatch expected 90ff957; both were stale, so this was re-read rather than quoted forward. Every claim in the card survives:

Site	Reading
messaging-service.ts	zero occurrences of locale, in 1095 lines
recipient-resolver.ts	zero occurrences of locale — the file whose whole job is resolving recipients
email-channel.ts:224	const locale = typeof payload.locale === 'string' ? payload.locale : defaultLocale;
sms-channel.ts:124	byte-identical to the line above; md5 of each line is ec055715f3db3f6cbcf5ddd08af48185
inbox-channel.ts:143-145	payload.locale, else getDefaultTemplateLocale()
messaging-service-plugin.ts:148-156	getDefaultTemplateLocale resolves i18n.getDefaultLocale()

Control-probed, because a zero from a path-scoped grep is worth nothing on its own. The same probe returns 41 hits in email-channel.ts, 14 in sms-channel.ts, 14 in inbox-channel.ts and 21 in messaging-service-plugin.ts; and inside messaging-service.ts itself, read the same way, it returns 52 recipient, 33 emit and 95 channel. The absence is real, not a broken pathspec.

The last row is also why the existing "Where to go next" link — "Set locale defaults that templates match against" pointing at Localization — stays accurate: the deployment default really is the tenant Localization setting.

For a reviewer wondering whether this is upstream drift rather than intent: objectstack#12178 and objectstack#12446 record a maintainer ruling of 2026-08-13 that this resolution is deliberate, and note that sys_user carries no locale column for a channel to read. That sweep's PR objectstack#12505 is why messaging-service-plugin.ts:250 reads honestly today.

Verification

All gates below ran on a059c27, the final commit, against a clean worktree. Each row quotes the gate's own conclusion.

Gate	Exit	Its own verdict
turbo run type-check build --filter=@objectos/docs	0	Tasks: 2 successful, 2 total · Cached: 0 cached, 2 total — both ran, neither replayed
check-locale-surface.mjs (reads the BUILT sitemap)	0	"every advertised URL has a source file and every source file is advertised" — sitemap.xml 409 read / 409 expected / 0 unexpected / 0 missing
check-translations.mjs (freshness)	0	"translations gate passed"
check-translation-ownership.mjs	0	"This PR touches 0 translation artifact(s) and 1 other file(s)". Reported alongside it: "TRANSLATION_BOT_LOGIN is not set — ownership is not enforced yet", so the rule itself is inert; the load-bearing half is the 0-artifact count, which is a real measurement
check-translation-output.mjs --files	0	"translation output gate passed (139 pre-existing finding(s) reported)" — none in this diff
gen-zh-hant.mjs --check	0	"zh-Hant: 73 generated file(s) match the zh-Hans sources byte for byte"
check-node-floor.mjs	0	"Every declared floor clears what the dependency tree requires"
turbo run test	0	1 successful — a legitimate cache hit: the test task declares no content/docs/** input, so this diff cannot affect it
control-byte self-scan	clean	no bytes in the U+0000-U+001F / U+007F range in the edited file

Rendering was confirmed on the build artifact, not just on the source: the corrected row and the new paragraph appear in apps/docs/.next/server/app/en/docs/configure/notifications.html, and the string "matched to the recipient" appears zero times anywhere under apps/docs/.next/.

Scope

content/docs/configure/notifications.mdx only.

No locale siblings were touched, and none exist: this page is one of the English-only pages, so the whole translation family is a no-op here rather than merely left alone.

I checked whether anything PR #247 added implies recipient-locale matching by implication. It does not — the "What each channel renders" table names locale as a bare match key without attributing it to anyone, and with the field-table row corrected its antecedent is now unambiguous. No edits were manufactured there.

---

Generated by Claude Code