Found while implementing #132, whose ruling covers the routing claim only; this is a separate claim about rendering, so it was recorded rather than folded into that PR. Filed unassigned, observation class.
content/docs/configure/notifications.mdx describes Templates as the render stage for every delivery — pipeline step 3 ("renders the message for the recipient's channel and locale (Templates)") and the Templates section ("Templates turn an event payload into the subject and body a recipient reads, in their locale and for their channel"). That wording predates #132 and survived its correction unchanged, because #132's file surface was scoped to the routing claim.
Measured on objectstack origin/main @ 2866d5f97e:
- email and sms channels render
sys_notification_template — messaging-service-plugin.ts:250 (email channel registered (renders sys_notification_template; …)), :268 (sms channel registered (renders sys_notification_template)), and template-renderer.ts:102 loads rows by (topic, channel, locale).
- The inbox channel does not.
inbox-channel.ts writes a sys_inbox_message row from the notification's own title/body (falling back to the topic), and on the notify template path it consumes IEmailService.renderTemplate over sys_email_template — a different object from the one this page documents. The package CHANGELOG states the gap outright: the inbox channel "has no locale-capable rendering seam to the email-template subsystem today".
So an admin editing a Notification Template row expecting the in-app inbox message to change may be editing something the inbox path never reads. Since inbox is the always-on default channel (channels defaults to ['inbox']), that is the most likely thing they are looking at.
Not fixed here because the honest replacement needs a decision this page cannot make on its own: whether the docs should enumerate which channels consult sys_notification_template (and name sys_email_template for the inbox template path), or whether the framework should close the seam first. The upstream note treats the seam as a known gap, which suggests the docs statement should follow the product's own statement rather than lead it — the same shape as the #132 blocker.
Related: #132 (routing claim, corrected), objectstack-ai/objectstack#9807.
Found while implementing #132, whose ruling covers the routing claim only; this is a separate claim about rendering, so it was recorded rather than folded into that PR. Filed unassigned, observation class.
content/docs/configure/notifications.mdxdescribes Templates as the render stage for every delivery — pipeline step 3 ("renders the message for the recipient's channel and locale (Templates)") and the Templates section ("Templates turn an event payload into the subject and body a recipient reads, in their locale and for their channel"). That wording predates #132 and survived its correction unchanged, because #132's file surface was scoped to the routing claim.Measured on
objectstackorigin/main@2866d5f97e:sys_notification_template—messaging-service-plugin.ts:250(email channel registered (renders sys_notification_template; …)),:268(sms channel registered (renders sys_notification_template)), andtemplate-renderer.ts:102loads rows by(topic, channel, locale).inbox-channel.tswrites asys_inbox_messagerow from the notification's owntitle/body(falling back to the topic), and on the notifytemplatepath it consumesIEmailService.renderTemplateoversys_email_template— a different object from the one this page documents. The package CHANGELOG states the gap outright: the inbox channel "has no locale-capable rendering seam to the email-template subsystem today".So an admin editing a Notification Template row expecting the in-app inbox message to change may be editing something the inbox path never reads. Since
inboxis the always-on default channel (channelsdefaults to['inbox']), that is the most likely thing they are looking at.Not fixed here because the honest replacement needs a decision this page cannot make on its own: whether the docs should enumerate which channels consult
sys_notification_template(and namesys_email_templatefor the inbox template path), or whether the framework should close the seam first. The upstream note treats the seam as a known gap, which suggests the docs statement should follow the product's own statement rather than lead it — the same shape as the #132 blocker.Related: #132 (routing claim, corrected), objectstack-ai/objectstack#9807.