[reynholm]

Background collection could disappear when ordinary traffic arrived, and retrying a partially successful collection could publish a second final report. This change retains the original collection/session/thread and adds managed final-result delivery with one canonical report per completion key.

Collection permits one ordinary interruption, then queues subsequent ordinary traffic behind its retry. Explicit cancellation, rotation and access revocation remain effective. buzz messages deliver persists signed evidence before publishing. Normal publication and late recovery share a transaction lock and canonical ledger: an accepted original is returned; an absent expired original may elect a freshly signed candidate with identical author/content/tags/route. The chosen event, thread metadata, mentions and binding commit together. Migration0056 preserves the production timestamp floor and community write fence.

Delivery requires the managed command, unique completion keys and retained journal. Late recovery requires coordinated updated relay writers with old writers/requests drained. Confirmed journal entries last seven days; server bindings last until community purge. Arbitrary shell/MCP publication bypasses this contract.

Integration also fixes the mesh echo receive being cancelled every100ms by ordinary shutdown polls. A pinned receive now survives those ticks and is abandoned only on actual shutdown. A deterministic RED/GREEN test covers continued reception and shutdown; both unit-test entry points select it. PostgreSQL discovery now resolves external files inside inline modules and supplies the actual CLI; recovery fixtures honor CI's pre-provisioned schema while retaining production Db::new/floor960. Migration assertions track the current migration set without adding an independent migration executor.

Validation receipts are under WORK_LOGS/BACKGROUND_DELIVERY_RELEASE_2026_10_14 and BACKGROUND_DELIVERY_RELEASE_2026_10_15. Full DB141/0, relay1449/0, fork Python77/0 and DB/relay all-target clippy passed on the final source snapshot. Earlier exact matching implementation sources passed CLI514/0, ACP1098/0, MCP80/0, eleven production-writer/NIP98/NIP42/actual-CLI recovery cases and four bundled-process mock-relay scenarios. Full local CI passed before the TLS patch; the subsequent complete affected Rust/native gate passed with rustls0.23.46 (native3646/0,20ignored). Final hosted CI passed at7d6fce62: https://github.com/reynholm/buzz/actions/runs/38688729383. The hosted PostgreSQL lane passed801/801 with all11 recovery cases present, and the separate mesh lifecycle smoke passed. The complete PostgreSQL lane passed801/0 on the identical final sources (one nextest leak diagnostic retained); a prior run had800/801 with a boot-timeout overrun (8.005s vs8s), without skips or widened timeouts. The tested tracked inputs match final commit7d6fce62e811899c31218381377a76423dee9da7 byte-for-byte.

The fork inventory records invocation mappings with compiling behavioral RED/GREEN evidence. The heartbeat has a textual drift guard and an acknowledged full-service-loop coverage gap. Whole-feature Astron review and addressed follow-ups through review-master closed the feature's IMPORTANT findings; Astron’s final integration review at7d6fce62 also returned PASS with5587/5587 inputs matched; no retained IMPORTANT/CRITICAL. Subsequent finite integration reviews found no retained important issue. Report and manual smoke steps: docs/superpowers/reports/2026-10-14-background-result-delivery.md.

The owner approved a single release-only exception for inherited unmaintained unsafe-libyaml/RUSTSEC-2024-0449 in Buzz event14da571fb65bf9ab1946c2be8ca6c3a621709f07a5ac5423e49fe6c64894c028 (2026-10-15). It is limited to fork-v0.5.26-4, linked to replacement issue #19, and must be reassessed before another release. All other advisory policy is unchanged. cargo-deny passes locally and hosted. Four rustls advisories were resolved with0.23.46 in both lockfiles rather than ignored.

The owner explicitly requested merge and macOS/Linux publication. Production deployment, hardware power-loss recovery and human acceptance are not claimed.

[mfethe1]

Context: external contributor, tracking Buzz forks and contributing measurements rather than patches. Earlier exchange on your PR #17 / background-result delivery. This is one measurement plus one open question about the delivery half of PR #18's contract — no patch proposed.

What you shipped (read first-hand)

• PR fix: preserve background results and recover final report delivery #18 (merged, 7d6fce62): "one canonical report per completion key"; normal publication and late recovery share a transaction lock and canonical ledger; "an accepted original is returned; an absent expired original may elect a freshly signed candidate".
• 7cbeb88027bde0db591d208bb1ada26b91f9fb14 "fix(acp): release completed Codex sessions on Linux": codex_helpers::classify now runs on Linux via ps -ww -o pid=,exe= (because Linux comm truncates), strips the (deleted) suffix for unlinked binaries, and failed_or_missing_executable_confirmation_keeps_work_blocking now also pins Some("10 -") — i.e. completion detection is deliberately fail-closed: unconfirmed ⇒ the slot stays blocked.

So completion detection is fail-closed, and publication is ledger-guarded by completion key. The measurement below is about the third hop, which is neither.

Our measurement (block/buzz PR block#6090, relay-side, open)

Diagnosing relay→client sync lag against upstream base f956e6fe we found the first broken boundary is not latency and not publication — it is silent fan-out:

• Authenticated production-relay probe (NIP-42 raw WS subscriber, 2026-08-16 19:02–19:11Z): healthy-path pushes arrive in 254–457 ms and are queryable on the first poll. The reported "lag" is a loss branch, not slowness.
• At base, try_send_ws_message on TrySendError::Full drops the frame with a server-side-only warn!. Below the grace limit (default 15) the socket stays "connected" with permanent holes in its stream. The publisher sees success; the event is persisted; the subscriber never receives it until reconnect-replay (desktop relayReconnectReplay.ts, mobile relay_session.dart).
• Reproduction harness (local relay, BUZZ_SEND_BUFFER=1, victim stalled 8 s while a publisher floods): victim got 5 buffered EVENTs, then 8× dropped frames on the ctrl channel at capacity 8 — the exact path that used to be invisible. PR fix(relay): emit BUZZ_SYNC_REQUIRED gap signal on fan-out backpressure drops block/buzz#6090 makes it emit ["BUZZ_SYNC_REQUIRED","backpressure"] instead, unsampled-counted via buzz_fanout_dropped_frames_total. The same harness also caught buzz_ws_backpressure_disconnects_total inflating to 46 for a single connection on drops-after-cancel (fixed + regression test in that PR).
• Gates at head 0048e96a0: two independent hosts, cargo test -p buzz-relay --lib 885/884 passed, fmt+clippy clean; the only failures are pre-existing host-shaped ones that reproduce on the base.

Why it touches your contract

An accepted, persisted, ledger-bound canonical report can still never reach a currently connected subscriber, and nothing on the publishing side observes that. Your fail-closed completion detection and your completion-key ledger both do their job, and the user still sees no final report until a reconnect. Late recovery would also not re-elect it, because the original was accepted, not absent/expired.

Open question (genuinely open — we have not instrumented your path)

In PR #18's ledger, is "accepted by the relay" the delivery predicate, or do you have a separate observation that the report reached the subscriber? Concretely: if the gap signal lands upstream, would you treat BUZZ_SYNC_REQUIRED as an input to the recovery path (a reason to re-serve the canonical report for that completion key without electing a new candidate), or is reconnect-replay considered sufficient and delivery deliberately out of the completion contract?

Asking because the two failure modes have opposite safe defaults — your completion side fails closed, the fan-out side (at that base) failed silent — and we would rather learn your intended boundary than guess at it.