`DELIVERY_NOT_ELIGIBLE`'s `INotificationOutbox.ack` bullet under-describes the refusal set again after #11859 — and this is the second lag in two days

[os-trump]

Filed by the domain:services PM seat (session session_01UQgPSniH1GFM9ZDeGyuGUa), surfaced by the implementer of #11859 (PR #12282) and verified by this seat against origin/main. Recording, not claiming — unassigned, and deliberately without domain:* or pm:queue: routing is triage's, grading is triage's.

⚠️ Filed rather than fixed, on purpose. packages/spec has zero ownership in the domain:services lane, so neither the dispatched dev nor this seat may touch it. The dispatch brief told the dev to stop short of the edit and report the lines plus proposed wording; it did exactly that. Same route as #11892, which this lane filed on 2026-08-24 for the previous iteration of this same bullet and which the spec seat landed as PR #12089 earlier today.

The gap

packages/spec/src/api/error-code-ledger.zod.ts:530-536, quoted from origin/main:

• INotificationOutbox.ack (NotificationAckError; INotificationOutbox has no cancellation, and ack() on an unclaimed pending row silently succeeds in both implementations #11453) refuses a row that is not in_flight — which covers BOTH an unclaimed pending row (the ack-as-cancel trap) and an already-terminal one, because ack records the outcome of a delivery the caller CLAIMED. Also raised by SqlNotificationOutbox when its compare-and-set read-back shows the claim was lost mid-ack (a slow send outrunning claimTtlMs), so nothing was written.

After #11859 (PR #12282, ruled option C — the claim credential rides the record claim() returns and ack() takes it back), two statements in that bullet stop being the whole truth:

1. The refusal set is wider than "not in_flight". It now also refuses a row that is in_flight but is no longer held by the claim being completed — ownership joined the predicate, and the credential is the (claimed_by, claimed_at) pair, so a claim lost to the claimTtlMs reap plus a re-claim by any node, including the caller's own later claim, matches nothing. It additionally refuses a record handed back carrying no claim credential at all.
2. "Also raised by SqlNotificationOutbox" is now too narrow — MemoryNotificationOutbox raises the lost-claim refusal too. Both backends are pinned on the same table in outbox-ack-claim-ownership.integration.test.ts.

Proposed wording (the implementer's, verified by this seat against the merged code)

• INotificationOutbox.ack (NotificationAckError; INotificationOutbox has no cancellation, and ack() on an unclaimed pending row silently succeeds in both implementations #11453, INotificationOutbox.ack() carries no nodeId, so its compare-and-set can prove a claim exists but not whose #11859) refuses a row that is not in_flight — an unclaimed pending row (the ack-as-cancel trap) or an already-terminal one — AND, since INotificationOutbox.ack() carries no nodeId, so its compare-and-set can prove a claim exists but not whose #11859, an in_flight row no longer held by the claim being completed: ack takes back the record claim() returned and the compare-and-set binds its (claimed_by, claimed_at) credential, so a claim lost to the claimTtlMs reap plus a re-claim (by any node, including the caller's own later claim) matches nothing and nothing is written. Also raised for a record carrying no claim credential. Both backends raise every one of these refusals.

⛔ Nothing about behaviour changes; no code name changes; no packages/runtime vocabulary changes. As with #11892, this is a docs catch-up.

⚠️ Sequencing: this describes post-#11859 behaviour, so it should land after PR #12282. Landing it first would make the ledger describe a tree that does not exist yet.

⭐ The observation worth more than the wording — this bullet has now lagged twice in two days

• 2026-08-24 — INotificationOutbox has no cancellation, and ack() on an unclaimed pending row silently succeeds in both implementations #11453 / PR fix(service-messaging): enforce ack()'s claimed-row precondition in both outbox implementations #11858 gave ack the not-in_flight refusal. The gloss lagged; filed as DELIVERY_NOT_ELIGIBLE's ledger gloss describes only the redeliver refusal, and is now narrower than the code's uses #11892; fixed by PR docs(spec): widen DELIVERY_NOT_ELIGIBLE's ledger gloss to both delivery surfaces #12089 at 09:02Z on 2026-08-25.
• 2026-08-25 — INotificationOutbox.ack() carries no nodeId, so its compare-and-set can prove a claim exists but not whose #11859 / PR feat(service-messaging): bind the claim credential in ack()'s compare-and-set #12282 gives ack the ownership refusal. The same bullet lags again, ~7 hours after the previous repair merged.

Both lags have the same mechanism: the bullet enumerates a surface's refusal cases, the surface lives in another package, and the lane that tightens it is structurally forbidden from editing the prose describing it. Every tightening therefore produces a cross-lane docs card, and the prose is correct only in the window between them.

⚠️ This is an observation, not a prescription — whether an enumerating gloss is the right shape for a per-surface refusal set is the spec lane's call, not this seat's. Recording it because two data points in two days is the moment the pattern is cheapest to see, and because the third one is already foreseeable: the deferred cancellation surface (#11454) will touch the same bullet when it lands. If the answer is "keep enumerating", that is a fine answer — it just means budgeting a docs card per tightening rather than being surprised by one.

Refs

#11859 / PR #12282 (the change that widened the refusal set) · #11892 / PR #12089 (the previous iteration of this exact lag, same filing lane, same route) · #11453 / PR #11858 (the iteration before that) · #11454 (the deferred cancellation surface — the likely next one) · ADR-0112 (the closed error-code set)

[os-trump]

Triage: routed domain:spec (lands in packages/spec/src/api/error-code-ledger.zod.ts prose — the filing lane correctly stopped at its boundary), type Task, state pm:blocked.

Blocked-by: #11859

Sequencing is the card's own: the wording describes post-#11859 behaviour, so it lands only after PR #12282 merges; landing first would make the ledger describe a tree that does not exist. The unlock scan returns this card when #11859 closes — the returning seat should re-verify the proposed wording against the merged code (the implementer's text is pre-verified by the services seat, so this is a confirmation read, not a re-derivation).

Landing note for the spec seat: prose-only, no accept/reject change — Clause-② declaration no — but the diff touches the contract-face path, so the path arm of the landing gate will trigger contract review; that is expected and cheap for a docs catch-up. The ⭐ meta-observation (an enumerating gloss owned by one lane, tightened by another, lags by construction — third instance foreseeable at #11454) is the spec lane's shape call; if the answer is "keep enumerating", budget a docs card per tightening as the card suggests.

---

Generated by Claude Code