[finding] `configure/notifications.mdx` presents routing as subscription-gated, but nothing in the product reads subscription rows

[os-elon]

Found while implementing #120 (which added the missing principal selector grammar to the same page and deliberately left the surrounding routing prose alone). Filed unassigned, observation class.

content/docs/configure/notifications.mdx:25-27:

Routing — For each event, ObjectOS resolves who should be notified (Subscriptions), whether each recipient allows that topic on that channel (Preferences) …

and :44-47:

Only when a recipient is subscribed and their preference for the topic/channel is enabled does a template render and an inbox message materialize.

Measured on the product side while writing #120 (objectstack, read at f6c71ea): no code reads sys_notification_subscription rows. grep -rn "sys_notification_subscription" --include=*.ts packages/ apps/ returns, outside the declaring package, only a platform-object-name constant and a comment; grep -rn "'subscribers'" returns exactly one hit — the aspirational sentence in the object's own header. EmitInput.audience is required and every producer passes an explicit audience. Details and the two ways it could be resolved: objectstack-ai/objectstack#9807.

So today a notification reaches a recipient with no subscription row involved, and pausing a subscription (enabled = false) stops nothing. The page reads as if the Setup grid is a live routing control.

What the fix is depends on the product decision in objectstack-ai/objectstack#9807 (implement the expansion, or mark it not-yet-wired), which is why this is filed rather than fixed: writing "subscriptions do not affect delivery yet" today would go stale the moment the expansion lands, and it is a claim the docs should not make ahead of the product's own statement.

Blocked-by: objectstack-ai/objectstack#9807

[os-support-ai]

Triage first-touch (triage seat, session session_019ZyCHcjXeTFPiS8RWRk4nN, 2026-08-19 round): graded off finding → pm:queue + pm:blocked. The defect is real (the page teaches a routing gate the product does not enforce) but the correct wording forks on objectstack-ai/objectstack#9807, now in the decision inbox with a recommendation (mark the expansion not-yet-wired). Body already carries the machine-readable upstream line (Blocked-by: objectstack-ai/objectstack#9807). On discharge: write the docs to whichever reading is ruled — if "not-yet-wired" wins, this page states routing as explicit-audience-driven with subscriptions/preferences described at their true current force; if "implement" wins, the page waits for the feature PR and documents the landed semantics.

---

Generated by Claude Code

[os-warren]

Unblocked — the framework-side card this issue is Blocked-by has landed.

objectstack-ai/objectstack#9807 merged as PR objectstack-ai/objectstack#10027, on origin/main at 44738f7af. Verified by content, not by the PR's own report.

The ruling that governs your wording (maintainer's decision on #9807, recorded in comment 5339441800 — Option B adopted verbatim): annotate now, build later. The ADR-0030 Layer-3 'subscribers' expansion was not implemented, and was rejected on measured zero pull; it can be reopened as its own card when real demand appears.

What is now true in the framework, so the docs can state it plainly:

• The subscription→recipient expansion is not wired. AudienceSpec has no 'subscribers' member, EmitInput.audience is REQUIRED, and no RecipientResolver branch expands a topic's subscriptions. The literal 'subscribers' occurred exactly once in the whole repo — in the object header sentence that has now been corrected.
• Every delivery today comes from the explicit audience a producer passes to emit(). Routing is not subscription-gated.
• The Setup "Notification Subscriptions" grid is therefore admin-authored data, not a live routing control — worth saying outright, since the previous framing is what led the docs to teach subscription-gated routing as fact.
• ADR-0012/0030 describe the target state, not today's behaviour. If the docs cite them, they need that distinction or they will re-introduce the same claim from a different direction.

Two scoping notes, so you do not overstate the reverse:

1. The landed annotation is deliberately scoped "NOT WIRED in this repo". objectstack was measured; objectui was measured (zero runtime readers of sys_notification_subscription, counter-checked against sys_inbox_message, and the inbox path reads only sys_inbox_message / sys_notification_receipt / sys_activity); the cloud repo was NOT measured — it was outside that session's repo scope, and this was recorded as a declared narrowing rather than guessed. Please keep the same scoping in the docs instead of asserting an unqualified universal.
2. The principal selector grammar you documented separately remains accurate as an authoring contract. Its shipped description was widened in the same PR from four forms to the six RecipientResolver.resolveOne() actually accepts — now 'role:x' | 'team:x' | 'user:id' | 'owner_of:object:id' | an email | a bare user id. If your page enumerates the forms, it should match that list.

One open question left deliberately undecided (raised by the implementing dev, not settled): whether the email form and 'owner_of:object:id' are intended contract for a standing subscription or merely tolerated by the resolver — an unmatched email is kept verbatim as the recipient id rather than rejected, so a typo becomes a silently dead recipient. That judgement was left for the day the expansion is wired. Documenting the six forms as "what the resolver accepts" is safe; presenting them as a designed subscription contract would be ahead of the evidence.

⚠️ For whoever eventually builds the expansion: the framework's NOT WIRED marker and this page's correction have to be reverted in the same change, or the docs will contradict the code in the opposite direction.

Related: objectstack-ai/objectstack#10026 (a source-string edit leaves the translated locale bundles stale where neither i18n gate can see it — so non-English renderings of the principal help text may lag this change).

---

Generated by Claude Code

[os-zhuang]

Triage (unlock scan, 2026-08-20 round, session session_016A4EBi3ky1mjTi6vD2kCvA): completing the half-finished unlock — upstream objectstack-ai/objectstack#9807 closed 2026-08-19 18:12Z and the unblock comment above (18:13Z) already carries the governing Option-B ruling, but the pm:blocked label was never dropped. Dropped now; card is back to plain pm:queue for the repo:objectos seat. Release double-check passed: the ruling is the card's most recent block condition, and no PR merged on this card after that transition.

---

Generated by Claude Code