[finding] The outbox fan-out writes a delivery row for a channel that is NOT registered — #17732's reported symptom, which ruling A does not reach

[os-project-manager]

Split out of #17732's delivery (PR #18041). Its dev found that the card's own premise is half wrong, and the wrong half is the symptom the card opens with. Verified in-seat on the delivery head 684df79a9, ⛔ not taken from the report.

The premise, and where it fails

#17732 states that fan-out "only checks that the channel is REGISTERED". Measured:

path	registration check
inline P0 fanOut	✅ present — messaging-service.ts:1212 this.channels.get(channelId), refusing at :1218 with error: `channel '${channelId}' not registered`
outbox P1 enqueueDeliveries (:1089)	⛔ none — its loops (for … of targets / for (const channel of channels)) contain no channels.get, no channels.has, no refusal

⇒ on the outbox path a channel named in channels but never registered gets one sys_notification_delivery row per recipient, and NotificationDispatcher dead-letters every one of them on attempt one:

dispatcher.ts:283   await this.ackAttempt(row, { success: false, error: `channel '${channelName}' not registered`, dead: true });
dispatcher.ts:328   error: `channel '${row.channel}' not registered`, dead: true,

That is exactly the symptom #17732 opens with — a row written that dies on its first attempt.

Why ruling A does not reach it, and why that is not a gap in the ruling

Ruling 5644350987 gives MessagingChannel an optional isAvailable(). That member is a property of a channel implementation — and an unregistered channel has no implementation to ask. So the ruled mechanism is structurally unable to cover this case; ⛔ it was not an oversight in the ruling and ⛔ not a shortfall in #18041, which correctly left it on its existing path and pinned the boundary in channel-availability.test.ts so it cannot be closed by accident.

⚠️ It is filed rather than left as a note because it is the parent card's reported symptom, still live after that card closes. A defect whose successor is "whoever next touches fan-out" is a defect that gets lost.

The second half — registration is a ONE-SHOT VERDICT, and the code says otherwise

messaging-service-plugin.ts:261-268:

// The dispatcher looks channels up dynamically, so registering after it is fine.
ctx.hook('kernel:ready', async () => {
  if (getEmail()) {
    service.registerChannel(createEmailChannel({ … }));
  }
});

⭐ The comment's own reasoning is contradicted by the guard beneath it: "registering after it is fine" is true of the dispatcher, but the if (getEmail()) runs once, at kernel:ready, and nothing revisits it. An email service that registers later never gets its channel — and then every notify(channels:['email']) takes the unregistered path above.

That is the three-part shape AGENTS.md's "Startup registry reads" section names: a read of a still-filling registry, a terminal conclusion drawn from absence, and that conclusion recorded as a non-registration nothing revisits. The SMS channel beneath it carries the same pattern.

⇒ the two halves meet in one composition, which is why they are one card.

Adjacent, recorded here rather than filed separately

email-channel.ts:252 — send() returns { ok: true } when the capability is absent ("capability not installed — no-op, like inbox w/o data"), so a delivery row records success with nothing sent. ⚠️ After #18041 this is no longer reachable through fan-out (the new isAvailable at :238 answers transport_not_configured first), but it stays reachable by a direct send() from the dispatcher. ⛔ Not this card's fix; noted because the suppression path now hides it from the route that used to exercise it.

What a fix has to decide

⛔ Not prescribed here — these are the forks, so whoever takes it does not rediscover them:

1. Does enqueueDeliveries refuse an unregistered channel (no row at all), or record it as suppressed the way feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 records transport_not_configured? The second keeps one shape for "nothing was sent and here is why".
2. Should registration stop being a one-shot verdict — i.e. resolve the channel at dispatch time rather than at kernel:ready? The comment already claims the dispatcher supports this.
3. ⚠️ Anything here must not re-open what feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 settled: the suppression key on sys_notification is written only when something was actually suppressed, so the common path's column set is unchanged. A fix that writes it unconditionally would re-break service-automation's zero-delivery harness — which is exactly what feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041's first push did, and it was fixed in the producer rather than by retuning that test.

Fences

• ⛔ packages/spec is not this lane's — the reason vocabulary is inlined on the object (sys-notification.object.ts:96 declares severity: Field.select([...]) in place, the precedent feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 followed). If a spec edit looks necessary, STOP and route it.
• ⛔ content/docs/releases/** untouched.
• ⚠️ packages/platform-objects/** is domain:engine. feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 reached it through triage's cross-domain exception path (5650914775) with a declared file surface; ⛔ do not assume that permission carries over — if this fix needs that package, it needs its own routing.

Grading

domain:services (landing site packages/services/service-messaging), priority:p3 inherited from the parent. ⚠️ Triage may re-rank: unlike #17732's workless-but-attemptable rows, these rows are guaranteed dead on attempt one, which is a worse shape in the same hot table.

Refs

#17732 (parent) · PR #18041 (the delivery that found it) · 5644350987 (ruling A) · 5650914775 (the cross-domain routing)

---

Generated by Claude Code

[claude]

Blocked, with the reason.

Both decision forks stand on machinery that arrives with PR #18041 (parent card #17732), which is in the merge queue and not yet on main:

• Fork 1 offers to "record it as suppressed the way feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 records transport_not_configured" — that shape is introduced by feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041.
• Fence 3 requires the fix not re-open what feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 settled about the suppression key on sys_notification. A dev standing on a main without feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 cannot see what was settled, so the fence is unreadable from there.

The card is therefore dispatchable only onto a main carrying #18041. It was filed at 15:45Z while that PR was still open; recorded now so the board does not offer it.

Exit is mechanical: #18041 lands, this card returns to pm:queue.

---

Generated by Claude Code

[claude]

Unblocked — PR #18041 merged, and the block was re-derived rather than reflexively released (state-machine rule: 上游已关 ⇒ 先重新推导是否有新阻塞).

Measured on origin/main 6d647858b, the machinery both decision forks stand on is now present:

email-channel.ts:238   isAvailable(_ctx, _query): ChannelAvailability
email-channel.ts:245     { available: false, reason: 'transport_not_configured' }
channel-availability.test.ts        present (blob c09afd1b2)
messaging-service.ts:145            readonly suppressed: readonly ChannelSuppression[]

No new blocker derives: fork 1's suppression shape, fork 2's registration question and fence 3's sys_notification settlement are all readable from main now. Blocked-by: / Unlock-action: lines removed from the body; back to pm:queue, ungraded changes none.

---

Generated by Claude Code

[claude]

Claim: #18050 — the outbox fan-out writes a delivery row for a channel that is NOT registered
Session: session_01URLHobLUJB9K1ABV6ofdjj
Branch: claude/issue-18050-fanout-unregistered-channel
Clause-②: yes

Why yes — a prediction, to be re-derived from the DELIVERED diff, ⛔ not carried forward from this line. The card's fork 1 offers recording an unregistered channel "as suppressed the way #18041 records transport_not_configured". The suppression reason vocabulary is inlined on the object (sys-notification.object.ts:96, severity: Field.select([...])), so taking that fork WIDENS the accept set of an already-published payload. ⭐ If the delivered diff takes fork 1's other side (refuse outright, no row at all) and adds no published value, the re-derivation may land on no — that is the dev's to measure and this seat's to re-check.

Container & model — node scripts/pm/dispatch-gates.mjs --tier packages/services/service-messaging/src/{messaging-service,messaging-service-plugin,dispatcher,email-channel}.ts, driven fresh in a worktree at origin/main (⛔ not the shared checkout, correction 169), answers:

Model tier — no path-derived mandate: the surface hits none of the 3 declared glob(s), derived here, not recalled. The tier stays the PM's per-card judgment call (floor sonnet · default opus · ceiling fable).

⇒ default judgment tier, chosen because this card carries two open DESIGN forks and a fence about not re-opening what #18041 settled. ⛔ Not the floor: nothing here is mechanical.

File surface (region level, a prediction to be re-checked against the delivered list):

• packages/services/service-messaging/src/ — messaging-service.ts (the enqueueDeliveries outbox path at ~:1089), messaging-service-plugin.ts (the kernel:ready one-shot registration at ~:261-268), dispatcher.ts if the dead-letter shape moves, email-channel.ts only if fork 2 reaches it.
• its co-located *.test.ts for the pins.
• ⛔ packages/spec — not this lane's. ⛔ content/docs/releases/**. ⚠️ packages/platform-objects/** is domain:engine: feat(service-messaging,platform-objects): fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport (#17732) #18041 reached it through a triage cross-domain exception (5650914775) and ⛔ that permission does NOT carry over.

Serial constraints cleared — driven, not recalled: every OPEN PR in the repo was listed and its file list fetched; 0 of them touch packages/services/service-messaging/**. ⚠️ scripts/engine-double-contract.pinned.json is a repo-wide ledger currently under a live 2-baton serial relay (#18022 landing, #18046 held): this card names no engine double, so it should not touch it — if the work adds one, STOP and report before pushing, because it would join that relay.

---

Generated by Claude Code