[Decision] service-messaging: should fan-out consult per-tenant channel availability (a new `MessagingChannel` member) so no delivery row is written for a channel with no transport? — split from #17611

[os-tesla]

Split from #17611's ruling (C taken; A deferred to its own pricing). ⛔ A decision card: the question is whether to widen a published interface, which is the maintainer's floor, so it is filed needs-user-decision rather than queued.

一句话问题

租户没有配置某个渠道(例如没有邮件传输)时,通知 fan-out 现在仍然为该渠道写一行投递记录,这一行第一次尝试就死信。要不要让 fan-out 在写之前先问一句「这个租户这个渠道能发吗」,不能就不写这一行,只在通知上记录该渠道被抑制及原因?代价是给已发布的 MessagingChannel 接口新增一个可用性成员。

The proposal (the reporter's option A on #17611)

At fan-out, resolve channel availability per tenant. For a channel whose transport is not configured, write no sys_notification_delivery row; record on sys_notification that the channel was suppressed and why. Hot-table cost for such channels goes to zero; the suppression stays auditable at the notification level.

Why it is its own card, and why it is a decision

Measured by the services seat on origin/main @ 6fa2a8ae1 (5641086533 on #17611): MessagingChannel (packages/services/service-messaging/src/channel.ts) has three members — id, send(), optional classifyError?() — and no availability or capability query; fan-out (messaging-service.ts) only checks that the channel is REGISTERED, and the reported case is a channel that is registered while the tenant has no transport, one layer below. ⇒ A adds a member to a published interface, with tenant context, and every channel implementation (inbox, email today; webhook, push, chat channels later) has to answer it. That is a Clause-②: yes widening and a declare-and-maintain obligation.

What the ruling on #17611 already bought, and what this card is for

#17611 C caps terminal rows at 7d through the existing retention.onlyWhen key (the same shape as sys_automation_run), which by the seat's arithmetic turns a ~28,000-row ceiling into ~2,200. The remaining question is whether the existence of workless rows is acceptable at all, or only their age. If the former, A is the fix; if the latter, C is sufficient and this card closes as not planned.

Options

	what	cost
A	Add the availability member to MessagingChannel, consult it at fan-out, suppress with a recorded reason	published-interface widening; every channel implements it; a per-tenant availability answer may cost an I/O round trip at fan-out (unmeasured)
hold	Take no contract change; let #17611's 7d retention run and read the table again	zero cost; the hot table still carries ~2,200 workless rows at steady state on the reporting tenant

⛔ Confidence gaps carried from #17611

1. Whether the reporting deployment runs the lifecycle Reaper at all (asked of the reporter on service-messaging: fan-out writes an email delivery for a tenant with no email transport — it dead-letters on its first attempt and is kept 90d, so the hot outbox grows ~1 dead row per notification #17611); if it does not, C yields nothing there and this card is the live one.
2. Whether anything reads dead email rows (reports, SLA, manual triage).
3. Whether "can this tenant send on this channel" is cheaply answerable at fan-out time.

Refs

#17611 (ruling C, 2026-09-12) · 5641086533 (the services seat's four-facet price) · #17609 (driver-side missing index) · #17610 (scheduler idle cost) · hotcrm#1892 (12 flows notify on ['inbox','email'])

Filed by the director seat, session_01QsCVSivtpwT6ZXs5Rtvqxe, 2026-09-12T01:0xZ, with Claude Code.

---

Generated by Claude Code

[os-tesla]

Ruling recorded — A: fan-out consults per-tenant channel availability and writes no delivery row for a channel with no transport; MessagingChannel gains an optional availability member (director seat, decision batch #122 item 5, 2026-09-12)

Maintainer, verbatim (live PM chat, 2026-09-12T05:5xZ), to decision batch #122 presented as 1A·2A·3A·4A·5A: 「同意」.

Derived first from the long-term axis: every row in the delivery table is an attemptable delivery; whether a channel is configured for a tenant is a pre-send fact, checked before writing, on every mainstream notification pipeline. #17611's C (7-day retention for terminal rows) bounds the symptom; this ruling removes its cause. The director seat records that its own C-first recommendation on #17611 was cost-led; re-derived from the long-term axis, A is the shape.

What is ruled

1. MessagingChannel (packages/services/service-messaging/src/channel.ts) gains an OPTIONAL availability query taking the tenant context — optional so every existing channel implementation stays valid unchanged; a channel that does not implement it is treated as available (today's behaviour).
2. Fan-out (messaging-service.ts) consults it per channel before enqueueDeliveries; for an unavailable channel no sys_notification_delivery row is written, and sys_notification records the channel as suppressed with the reason (a small closed enum, e.g. transport_not_configured).
3. The inbox channel is always available; the email channel answers from the tenant's transport configuration — the seat measures whether that answer is cheap at fan-out time and caches per tenant per tick if it is not.
4. Clause-②: yes (a member on a published interface, a new key on sys_notification), contract-review carrier; Feature changeset.
5. Order: service-messaging: fan-out writes an email delivery for a tenant with no email transport — it dead-letters on its first attempt and is kept 90d, so the hot outbox grows ~1 dead row per notification #17611's C lands first (same seat), this second; the reporter's Reaper reading asked on service-messaging: fan-out writes an email delivery for a tenant with no email transport — it dead-letters on its first attempt and is kept 90d, so the hot outbox grows ~1 dead row per notification #17611 still matters for C, not for this.

State

needs-user-decision → pm:queue; domain:services / priority:p3 kept.

---

Generated by Claude Code

[os-project-manager]

pm:retriage —— 裁决 A 的落地面跨两条车道，本席只持有其中一条

⛔ 这不是对裁决的异议。裁决 A 本身清楚、可执行，本席也确认它的串行前提已解除。转诊的唯一理由是：本席无权写 A 所要求的其中一个文件。

一、先把好消息记上：串行前提已解除，且是测出来的

裁决第 5 条：「#17611's C lands first (same seat), this second」。

e7fea4665  2026-09-12T16:25:39Z
fix(service-messaging): sys_notification_delivery reaps its terminal-failure rows after 7d, not 90d (#17611) (#17871)

⇒ 已落 origin/main。本卡的排队理由消失，⭐ 应当按 rebase 重定价，而不是重新规划 —— 卡面的四facet定价仍然成立。

二、⭐ 红线探针：不触 packages/spec

本席先按红线查了，结论是不触，这一点值得写明以免下一席重查：

• sys_notification 的对象定义在 packages/platform-objects/src/audit/sys-notification.object.ts，不在 spec。
• 裁决第 2 条要的「a small closed enum, e.g. transport_not_configured」不需要进 spec：同一文件里的 severity 就是 Field.select(['info','warning','critical'], {…})，闭合枚举就地内联声明。
• packages/spec/src/system/notification.zod.ts 只持有 NotificationChannelSchema（渠道枚举）与 NotificationChannel 类型；本卡不新增渠道。

⇒ 本卡不是 spec 座位的卡。

三、⛔ 但它跨 domain:services / domain:engine 两条车道

裁决条目	落点	车道
1. MessagingChannel 新增可选可用性成员	packages/services/service-messaging/src/channel.ts	✅ domain:services（本席）
2a. fan-out 在 enqueueDeliveries 前咨询，不写 delivery 行	packages/services/service-messaging/src/messaging-service.ts	✅ domain:services（本席）
2b. sys_notification 记录该渠道被抑制及原因（新键 + 原因枚举）	packages/platform-objects/src/audit/sys-notification.object.ts	⛔ domain:engine
3. inbox 恒可用；email 读租户传输配置	service-messaging 渠道实现	✅ domain:services（本席）

车道岗位说明 engine.md:10 原文把 packages/platform-objects 划给 domain:engine。⇒ 第 2b 条不在本席持有面内，而裁决第 4 条把它写进了 Clause-② 的广义面（"a member on a published interface, a new key on sys_notification"），⛔ 不可由本席自行削去半边落地。

四、⭐ 这条边界本身值得记，因为它反直觉

service-messaging/src/objects/ 持有 ADR-0030 通知管线的几乎整个对象族：

notification-delivery.object.ts       (L4 投递)
inbox-message.object.ts               (L5 materialize)
notification-receipt.object.ts        (L5 回执)
notification-subscription.object.ts   notification-preference.object.ts
notification-template.object.ts       http-delivery.object.ts

唯独 L2 事件对象 sys_notification 一个人站在 packages/platform-objects/src/audit/ 里。 ⇒ 从卡面标题（"service-messaging: should fan-out …"）看这是一张单车道卡，它不是；这个读数只有把对象文件逐个列出来才拿得到，本席记在这里以免下一席重走。

五、交给分诊的问题（⛔ 本席不自答，自答就是自行扩道）

第 2b 条是一个字段 + 一个内联枚举。分诊可判：

• (i) 视为 de-minimis 跨道触碰，随 services 卡一并落，由本席一单做完；或
• (ii) 拆成两单，domain:engine 先落字段，domain:services 随后落 fan-out（两半不可独立落地：fan-out 写抑制记录需要字段先存在，是硬串行）；或
• (iii) 另有本席没看到的归属读法。

⚠️ 本席的倾向不构成路由，仅供分诊参考：(i) 的代价最低且不制造跨轮串行，但它确实让 domain:services 写了一行 domain:engine 的文件——这正是车道模型要防的事，所以本席不自取。

六、另一条给认领席的串行提醒

#17611 的 PR 同时改了 scripts/engine-double-contract.pinned.json（+5 行）。本轮本席在该文件上跑过三棒串行接力。⇒ 本卡新增对象字段极可能再次触碰它，认领前须重查该文件当刻是否有在途 PR，并按串行接力办，⛔ 不要并行。

状态

pm:queue 保留（裁决已下，卡是活的、可派的，只是路由待定）；加 pm:retriage；domain:services / priority:p3 暂留，由分诊决定是否改。⛔ 本席不认领本卡，直到路由回来。

_{domain:services execution seat · seat post #6021 · R2 · measured at origin/main = a61ae59f9}

---

Generated by Claude Code

[claude]

Claim: PM loop round 1
Session: session_01URLHobLUJB9K1ABV6ofdjj
Branch: claude/issue-17732-channel-availability-fanout
Worktree: objectstack-issue-17732
Domain: domain:services — assigned by triage (5650914775) through the cross-domain exception path, ⛔ not self-taken
File surface: declared verbatim as triage required, ⛔ not as service-messaging:

packages/services/service-messaging/src/channel.ts              (ruling 1: the availability member)
packages/services/service-messaging/src/messaging-service.ts    (ruling 2a: fan-out consults it)
packages/services/service-messaging/src/**                      (ruling 3: inbox / email channel implementations)
packages/platform-objects/src/audit/sys-notification.object.ts  (ruling 2b: new key + inlined reason enum)
                                                                 ⚠️ this line is domain:engine

Container & model: M, mode:subagent, model: opus. Derived this round, ⛔ not recalled: node scripts/pm/dispatch-gates.mjs --tier <the three paths above> at f52bfa90f → "no path-derived mandate: the surface hits none of the 3 declared glob(s) … the tier stays the PM's per-card judgment call (floor sonnet · default opus · ceiling fable)." Opus is also what SKILL.md 强制条款② prescribes for a card that widens the public surface (默认判断档施工).
Clause-②: yes
Thread-read: 5650914775
Serial constraints cleared: the targeted in-flight check the exception path requires — scope domain:services and domain:engine only, ⛔ not a global sweep. Five in-flight cards, every file surface measured, not read off prose:

in-flight	measured surface	disjoint?
#18028 (this seat)	packages/plugins/plugin-auth/src/	✅
#17985 (this seat)	78 *.test.ts naming resolveUserAuthzGrants/resolveAuthzContext, across 18 packages — 0 under packages/services/service-messaging/, 0 under packages/platform-objects/	✅
#17897 (this seat)	2 plugin-auth test files	✅
#17516 (this seat)	9 files, all packages/plugins/plugin-security/ + scripts/engine-double-contract.pinned.json	✅
#16506 (zhuangjianguo)	packages/plugins/plugin-email/src/email-service.queue-delivery.test.ts — ⚠️ the title says "email", which reads like service-messaging; git ls-tree says plugin-email	✅
#17970 (os-musk, domain:engine)	measured from the pushed branch, ⛔ not from its claim's prose: driver-sql/src/sql-driver-doors-declared-types.test.ts, driver-turso/src/turso-driver-doors-declared-types.test.ts	✅

⇒ no intersection; nothing to yield to. ⭐ The #17985 row is the one that mattered: its sweep is defined by a predicate over 73+ files, not by a directory, so "does it reach service-messaging?" had to be run rather than assumed. Positive control: the same grep finds 78 files across 18 packages including four other services/* packages, so the zero under service-messaging is a reading and ⛔ not a broken search.

Why Clause-②: yes — from the ruling, not from a guess

Ruling 5644350987 item 4 states it: "a member on a published interface, a new key on sys_notification". Both limbs are the mechanical floor. ⇒ needs:contract-review hung on the card in the same stroke; re-derived from the DELIVERED diff at review time.

The serial prerequisite is discharged — measured

Ruling item 5: "#17611's C lands first (same seat), this second." That landed:

e7fea4665  2026-09-12T16:25:39Z
fix(service-messaging): sys_notification_delivery reaps its terminal-failure rows after 7d, not 90d (#17611) (#17871)

⇒ the queueing reason is gone. ⭐ The card is re-priced by rebase, ⛔ not re-planned — its four-facet price still stands.

---

Generated by Claude Code

[claude]

⚠️ Correction to this seat's claim (5653381936) — the declared file surface was INCOMPLETE

PR #18041's delivered diff is 15 files. 7 of them sit outside the surface my claim declared:

packages/platform-objects/src/apps/translations/en.objects.generated.ts
packages/platform-objects/src/apps/translations/es-ES.objects.generated.ts
packages/platform-objects/src/apps/translations/es-ES.source-hashes.generated.ts
packages/platform-objects/src/apps/translations/ja-JP.objects.generated.ts
packages/platform-objects/src/apps/translations/ja-JP.source-hashes.generated.ts
packages/platform-objects/src/apps/translations/zh-CN.objects.generated.ts
packages/platform-objects/src/apps/translations/zh-CN.source-hashes.generated.ts

⛔ This is the seat's error, not the delivery's. Ruling item 2 requires sys_notification to record the suppressed channel and its reason — a new field on a platform object, and a field carries a label, which regenerates the i18n bundles through the repo's own check-i18n-bundles.mjs --write. This seat's own standing rule says every card touching an object field's label must name that generator as a deliverable, and the claim did not. The delivery running it is correct; the declaration was short.

The exception path's condition was re-checked against the DELIVERED surface, ⛔ not re-assumed

Triage's cross-domain routing (5650914775) turns on declared surfaces being disjoint from every in-flight card in domain:services and domain:engine. A wider real surface could have broken that, so it was re-measured from the pushed heads rather than from the claims' prose:

in-flight branch	files	hits on …/translations/	on service-messaging/	on platform-objects/
#17985 …authz-false-green-sweep	2	0	0	0
#18028 …import-manager-id	5	0	0	0
#17516 …permission-set-collision-diagnostic	9	0	0	0

⇒ still disjoint; nothing to yield to. ⭐ The check returned the same verdict, but only because it was re-run against what was delivered instead of against what was declared — a declaration is a prediction, exactly like Clause-②.

Red lines re-verified on the delivered diff

⛔ packages/spec — 0 files. ⛔ content/docs/releases/** — 0 files. Both measured from GET /pulls/18041/files, ⛔ not taken from the PR body.

⚠️ Still owed at review time and ⛔ not asserted here: that those 7 bundles are genuine generator output. AGENTS.md permits hand-written values in translated locales but forbids hand-editing the generated structure, so the review checks that the structure came from the tool.

This correction does not edit the claim; the claim stands as written, in the same way a Clause-② correction supersedes without rewriting.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 17732,
  "status": "done",
  "branch": "claude/issue-17732-channel-availability-fanout",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/18041",
  "premise_still_valid": true,
  "summary": "Ruling 5644350987 landed as A. `MessagingChannel` gains an OPTIONAL `isAvailable(ctx, { organizationId })` answering from the closed vocabulary `CHANNEL_UNAVAILABLE_REASONS` (today `transport_not_configured`); `emit()` consults it once per channel BEFORE the event write, so an unavailable channel gets no `sys_notification_delivery` row and no `send()` on either the outbox (P1) or inline (P0) path; `sys_notification` gains one key, `suppressed_channels` ([{channel, reason}]), written in the SAME insert that creates the event row, so the feature costs zero extra writes. The email channel implements the member; the inbox channel deliberately does NOT, which is literally 'always available' and doubles as the production instance of the optional default. `EmitResult` gains `suppressed` so a two-channel emit reporting one row is never indistinguishable from a fan-out bug. VERIFIED AGAINST THE TREE, not taken on trust: sys-notification.object.ts:96 still reads severity: Field.select(['info','warning','critical'], {...}) (triage's reading 3 holds, so the reason enum is inlined and `packages/spec` is untouched — measured: 0 files under packages/spec in the diff); `MessagingChannel` had exactly id + send() + classifyError?() (reading 4 holds); the claim comment 5653443952 names this session and this branch. ONE CARD CLAIM IS FALSE and it is the load-bearing half: the card says fan-out 'only checks that the channel is REGISTERED'. True of the inline fanOut, FALSE of the outbox `enqueueDeliveries`, which performs no registration check at all — which is how an unregistered channel gets a row that NotificationDispatcher dead-letters with dead:true on attempt ONE, the exact symptom the card opens with. The ruling does not reach that case (its member is a property of a channel IMPLEMENTATION, and an unregistered channel has none to ask), so it is left on its existing path, pinned as deliberate, and filed below rather than widened into this PR.",
  "tests": "FINAL, on head 684df79a9, after the final commit. SUITES: pnpm --filter service-messaging --filter platform-objects --filter service-automation test -> exit 0; platform-objects 40 files / 575 tests passed; service-messaging 42 files / 455 tests passed; service-automation 134 files / 1581 tests passed. TYPECHECK: pnpm --filter service-messaging --filter platform-objects typecheck -> exit 0. Coverage is real, not assumed: the package tsconfig is include:['src'] / exclude:[node_modules,dist], so every src/**/*.test.ts is compiled, and check:type-check-coverage is green. LINT: pnpm lint (eslint . --no-inline-config, REPO-WIDE, not narrowed) -> exit 0, so no narrowing evidence is owed. GATES: 95 commands, each with its own captured exit code, 0 non-zero. 62 derived by `node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack` (re-derived after the final commit, byte-identical to the first derivation); 33 more named by .github/workflows/lint.yml and absent from that set. FOUR gates first answered exit 3 (PREREQUISITE NOT MET) and NONE was read as a pass: check:i18n -> built the 10-package closure it named -> exit 1, a REAL finding (platform-objects bundles drifted) -> regenerated -> exit 0; check:i18n-coverage, check:dual-build-cjs-loads and check:type-check-debt -> built the full closure -> all exit 0. Exit codes were captured before any pipe (cmd > log 2>&1; EXIT=$?). TRANSPORT-COST MEASUREMENT (ruling item 3, the number owed): email.isAvailable() = 4.8 ns/op with the service present, 31.1 ns/op absent, against 10.2 ns/op for an empty arrow call and 121.3 ns/op for merely AWAITING an already-resolved no-op findOne — i.e. the probe is cheaper than the floor of any I/O-shaped answer because it is synchronous. The three nanosecond figures are within noise of each other; the honest statement is that the probe is not distinguishable from call overhead, and the 'present' row reading below the empty-call baseline is that noise, not a speedup. Call count driven through the real emit(): 1 probe for 50 recipients x 2 channels, and 50 delivery rows avoided. => O(channels), never O(deliveries). NO CACHE ADDED, on the ruling's own condition ('caches ... if it is not [cheap]') plus a second reason: the `mail` settings manifest is scope:'global' and the transport is ONE in-memory instance hot-swapped by the settings change bus, so a per-tenant-per-tick memo would answer 'unavailable' straight through the settings save that fixed it. CI INCIDENT AND ITS CONTROL: my first push turned Test Core (4/6) red, 4 tests in service-automation's notify-zero-delivery-visibility.integration.test.ts, with 'Unknown field suppressed_channels on object sys_notification'. MINE, and fixed in the PRODUCER, not the test: the first draft named the new column on EVERY insert, making every emit depend on every sys_notification schema already carrying it; writeEvent now adds the key only when something was actually suppressed, so the common path's column set is exactly what it was before. NO assertion was retuned and the automation fixture is untouched. Three readings: merge-base 1e20f816e in a clean detached worktree with none of my commits = 134 files / 1581 tests, 0 failed; branch e57ee063c = 4 failed (CI run 34763053926); branch 684df79a9 = 134 files / 1581 tests, 0 failed. Independent second control on the cause itself: `suppressed_channels` occurs 0 times in the merge-base tree and 13 on this branch, with `dedup_key` (44 files) as the positive control for the same git grep against that same tree — a failure whose cause is a string absent from origin/main cannot be pre-existing. SECOND RED, also mine: Object.hasOwn is outside this package's lib. Reproduced first (exit 2, TS2550 at channel-availability.test.ts:188 and :356), fixed to Object.prototype.hasOwnProperty.call (the spelling 151 files in this repo already use), re-run clean. NO tsconfig touched. The presence distinction that call site needs: 'was the key NAMED on the insert at all', which must stay distinct from 'named with an empty value' — hasOwnProperty.call keeps it, `in` would answer for inherited keys too and `!== undefined` would conflate them; receiver is the plain object literal writeEvent builds, ordinary prototype, no own hasOwnProperty key. CLAUSE-2 RE-DERIVED FROM THE DELIVERED DIFF against the built entry, not from the ruling: packages/services/service-messaging/dist/index.d.ts now declares isAvailable?() on the exported MessagingChannel, plus CHANNEL_UNAVAILABLE_REASONS / ChannelAvailability / ChannelAvailabilityQuery / ChannelUnavailableReason / ChannelSuppression and the new required EmitResult.suppressed, all in the terminal export list. POSITIVE CONTROL 'type MessagingChannel,' = 1 hit; NEGATIVE CONTROLS EMAIL_SHAPE / actionUrlFor / READ_RECEIPT_STATES (all module-private) = 0 hits each, so the zeros discriminate. Limb 2: suppressed_channels is present in packages/platform-objects/dist/index.js, inside that package's published files[] (['dist',...]). => Clause-2: yes CONFIRMED, and in fact BROADER than the ruling's two limbs (EmitResult.suppressed is a third additive widening). check:pm-clause2-carriers --pair 18041 -> exit 0; needs:contract-review hung on the PR and read back present alongside size/l. Changeset: Feature-grade minor on both packages, as the ruling names and as a Clause-2 PR owes. NO ABLATION FILES LEFT IN THE TREE: the cost measurement ran from scratchpad scripts against the built dist and the control worktree has been removed.",
  "mcp_calls": "1 — a single mcp__github__get_job_logs for the failing Test Core job; every other GitHub read and write went through repo-scoped REST (probe: GET /repos/objectstack-ai/objectstack -> 200)",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: THE CARD'S OWN PREMISE IS HALF WRONG, and the wrong half is the reported symptom. #17732 says fan-out 'only checks that the channel is REGISTERED'. True of the inline P0 fanOut; FALSE of the P1 outbox enqueueDeliveries, which performs NO registration check — so a channel named in `channels` but not registered gets one delivery row per recipient and NotificationDispatcher dead-letters it with dead:true on attempt ONE (dispatcher.ts:283 and :328). That is exactly the card's opening symptom, and this ruling does not reach it: its member is a property of a channel IMPLEMENTATION and an unregistered channel has none to ask. Left on its existing path and pinned as deliberate. Successor: the seat that next touches messaging fan-out — the pin in channel-availability.test.ts names the boundary so it cannot be closed by accident.",
    "noted, not filed: messaging-service-plugin.ts:264 registers the email MessagingChannel only `if (getEmail())` at kernel:ready — a registry read turned into a permanent registration verdict, the exact three-part shape AGENTS.md's 'Startup registry reads' section names (read of a still-filling registry, terminal conclusion from absent, conclusion RECORDED as a non-registration that nothing revisits). An email service registering later never gets its channel. Successor: whoever lands the unregistered-channel fix above, since the two meet in the same composition.",
    "noted, not filed: createEmailChannel().send() returns { ok: true } when no email service is registered (email-channel.ts) — a delivery row recorded SUCCESS with nothing sent, the 'declared not delivered' shape of Prime Directive #10. Not reachable through fan-out once this lands (the channel now answers unavailable first), but still reachable by a direct send() from the dispatcher. Successor: none today — recorded because the suppression path now hides it from the route that used to exercise it.",
    "noted, not filed: the card and the ruling both say 'inbox, email today'; the tree also ships sms-channel.ts. Untouched here and stays available, which is what the optional default requires. Successor: none — a documentation-level inaccuracy in the card, with no code consequence.",
    "SURFACE EXTENSION, REPORTED NOT RIDDEN IN: 7 files under packages/platform-objects/src/apps/translations/*.generated.ts are outside the claim's declared file surface. They are the mechanical consequence of the declared out-of-lane file — a labelled field on sys_notification drifts the bundles, pnpm check:i18n fails on it and names the remedy. PRODUCED BY THE GENERATOR, `node scripts/check-i18n-bundles.mjs --write`, never by hand (AGENTS.md forbids hand-editing generated structure; translated values may be hand-written and none was). 22 added lines across 7 files, containing nothing but the new field — no other package drifted and no other agent's work was picked up. Same package and same lane as the declared out-of-lane file, so the cross-domain exception path's disjointness measurement is unaffected. The PM has acknowledged this as an under-declaration in the claim and corrected it on the card.",
    "CONFLICT BETWEEN MY DISPATCH AND THE STANDING os-dev CONTRACT, named rather than silently resolved: the dispatch asked me to run the full `Lint & Repo Gates` step sequence from lint.yml locally; the standing contract forbids enumerating that job's check:* steps locally because it runs the whole farm, and says the standing contract wins and the conflict must be reported. Resolved by running the two subsets that ARE mine — the 62 mechanically derived families plus 33 more that lint.yml names explicitly — to 95 real verdicts with no step inferred from the one before it, plus the repo-wide `pnpm lint` in full. The tail was not inferred anywhere."
  ]
}

---

Generated by Claude Code