@cello-protocol/daemon 0.0.180 → 0.0.182

package/dist/close-session-handler.js

@@ -2,7 +2,7 @@
  * cello_close_session — the bilateral close, and every way it can fail.
  *
  * M7 error discipline: each distinct failure cause produces a DISTINCT error code
- * (session_already_sealed, seal_interrupted_in_progress, seal_interrupted_counterparty_unavailable,
+ * (session_already_sealed, seal_in_progress, seal_interrupted_counterparty_unavailable,
  * seal_interrupted_rejected_by_counterparty, signaling_reconnecting). A close that fails must tell
  * the operator WHY, not merely that it failed — this handler exists as much for its error paths as
  * for its happy path.
@@ -42,8 +42,9 @@ const ABANDON_NOTICE_DEADLINE_MS = 3_000;
 import { classifyOnlineResult } from "./cross-node-negotiation.js";
 import { validateSessionName } from "./session-name.js";
 import { escalateToUnilateralSeal as runUnilateralEscalation, UNILATERAL_SEAL_TIMEOUT_MS } from "./seal-escalation.js";
+import { describeSealCommitted } from "./close-commitment.js";
 export function registerCloseSessionHandler(deps) {
-    const { resolveConsortiumRoster, handlers, logger, sessionNodeManager, getConnState, resolveCurrentAgent, NO_CURRENT_AGENT_RESPONSE, getKeyProvider, signalingFor, sendOver, waitForSignalingConnected, openVisitingConnection, runDiscoveryLookup, crossNodeBrokerBySession, sealKey, sealInterruptedInProgress, pendingSealWaiters, pendingUnilateralWaiters, handleSealInterruptedFlow, handleActiveSealFlow, recoverParkedContent, } = deps;
+    const { resolveConsortiumRoster, handlers, logger, sessionNodeManager, getConnState, resolveCurrentAgent, NO_CURRENT_AGENT_RESPONSE, getKeyProvider, signalingFor, sendOver, waitForSignalingConnected, openVisitingConnection, runDiscoveryLookup, crossNodeBrokerBySession, sealKey, sealInterruptedInProgress, registerBackgroundSeal, sealFailures, pendingSealWaiters, pendingUnilateralWaiters, handleSealInterruptedFlow, handleActiveSealFlow, recoverParkedContent, } = deps;
     const UNILATERAL_TIMEOUT_MS = deps.unilateralTimeoutMs ?? UNILATERAL_SEAL_TIMEOUT_MS;
     /**
      * How long the seal path waits to learn where the counterparty is homed.
@@ -137,7 +138,7 @@ export function registerCloseSessionHandler(deps) {
     // ─── M7-SESSION-001: cello_close_session ────────────────────────────────────
     // M7 error discipline: each distinct failure cause produces a distinct error code.
     // AC-010: session_already_sealed
-    // AC-011: seal_interrupted_in_progress
+    // AC-011: seal_in_progress
     // AC-012: seal_interrupted_counterparty_unavailable
     // AC-013: seal_interrupted_rejected_by_counterparty
     // DB-001: signaling_reconnecting
@@ -164,6 +165,13 @@ export function registerCloseSessionHandler(deps) {
         "seal_unilateral_timeout",
         "session_seal_already_pending",
         "session_sealed",
+        /**
+         * DOD-M15-TERMINAL-REASON-1. Without this, a close on a session the relay REFUSED skips
+         * `pullSealCertificate` entirely — the one probe that distinguishes "never sealed" from "sealed
+         * and you were never told". Losing it here is how a close ends with no receipt and no
+         * explanation of why.
+         */
+        "seal_refused",
         "relay_session_gone",
     ]);
     /**
@@ -428,6 +436,17 @@ export function registerCloseSessionHandler(deps) {
             }
             const told = notice.told;
             await sessionNodeManager.abandonSession(record.agent_name, sessionId);
+            /**
+             * FORGET ANY SEAL FAILURE — review MEDIUM-5.
+             *
+             * An abandoned session is TERMINAL: there is no ceremony to retry and no receipt to obtain.
+             * Leaving the marker made two surfaces contradict each other — `cello_sealed_receipt` reported
+             * `seal_failed` and told the agent to *"call cello_close_session again"*, while
+             * `cello_close_session` refused with `session_abandoned` and *"it is terminal… it cannot be
+             * closed."* A refused loop, and exactly the contradicting-surfaces pair the previous unit's
+             * review flagged, reintroduced one unit later.
+             */
+            sealFailures.clear(record.agent_name, sessionId);
             logger.info("session.force_abandoned", {
                 agentName: record.agent_name,
                 sessionId,
@@ -475,14 +494,20 @@ export function registerCloseSessionHandler(deps) {
         const sealable = record.status === "active" || record.status === "interrupted";
         let readiness = sealable
             ? sessionNodeManager.sealReadiness(record.agent_name, sessionId)
-            : { ready: true, treeSize: 0, highWaterSeq: -1, heldCount: 0, missingLeaves: 0, heldOwn: 0, heldReceived: 0 };
+            // DOD-M15-DIVERGE-1: `diverged: false` for the same reason every other field here is a
+            // no-op value — this branch is the NOT-sealable statuses, where readiness is never consulted
+            // and both gates below are skipped. It asserts nothing about the record; it keeps the shape.
+            : { ready: true, treeSize: 0, highWaterSeq: -1, heldCount: 0, missingLeaves: 0, heldOwn: 0, heldReceived: 0, diverged: false };
         // Review HIGH-1: the guidance used to promise "the daemon pulls missing content automatically"
         // while nothing on this path pulled anything — autoRecoverForAgent fires on signaling reconnect,
         // seal-upgrade and agent start, none of which a close triggers. So the operator waited for an
         // event that would never happen, retried, got the same refusal, and reached for force:true — the
         // terminal receipt-less outcome this gate exists to prevent. Drain FIRST, then judge, which is
         // the sequence seal-upgrade.ts already documents: "Recover content -> consult the gate -> REFUSE".
-        if (sealable && !readiness.ready && recoverParkedContent) {
+        // Review LOW-10: skip the drain for a diverged record. `diverged` is now a term in `ready`, so
+        // without this a diverged session pays a relay round trip that cannot change the answer — the
+        // gap the drain fills is not the condition that refused it.
+        if (sealable && !readiness.ready && !readiness.diverged && recoverParkedContent) {
             try {
                 await recoverParkedContent(record.agent_name, "close_readiness_gate");
                 readiness = sessionNodeManager.sealReadiness(record.agent_name, sessionId);
@@ -496,6 +521,62 @@ export function registerCloseSessionHandler(deps) {
                 });
             }
         }
+        /**
+         * DOD-M15-DIVERGE-1 — a PERMANENT parting gets its own answer, before the transient one.
+         *
+         * `#diverged` is set when an ack came back behind this side's frontier, which proves the tree
+         * and the relay's counter can never agree on a root again. It was detected correctly, logged at
+         * ERROR, and reached exactly one consumer: the text `cello status` prints. This gate — the one
+         * place the fact changes an outcome — could not see it, so the operator learned only when the
+         * counterparty answered `leaf_count_mismatch`, by which point the receipt was gone.
+         *
+         * BRANCHED, NOT FOLDED INTO `session_incomplete`, and that is the whole point of the ordering.
+         * The refusal below tells the operator to "wait a moment and close again" and says the daemon
+         * just pulled from the relay — true and useful for a session waiting on arrival, and false for
+         * this one. Nothing backfills a position the relay already assigned to something else, so a
+         * retry loop on that guidance ends where every one of them ends: `force: true`, terminal, no
+         * receipt. Substituting a transient explanation for a permanent condition is the error class
+         * this whole milestone exists to remove; doing it inside its own fix would be the worst place.
+         *
+         * The ERROR log at the detection site STAYS. This is the second half of it, not a relocation:
+         * the log is the forensic record and this is the control. (M15-PROCEDURE §2b, Invariant 2.)
+         */
+        if (sealable && readiness.diverged) {
+            logger.warn("session.seal.blocked_diverged", {
+                agentName: record.agent_name, sessionId,
+                treeSize: readiness.treeSize, highWaterSeq: readiness.highWaterSeq,
+                // Review MEDIUM-5: the same four counters the sibling refusal carries. Without them a
+                // session that is BOTH diverged and gapped reported its gap on no surface at all — this
+                // branch preempts the incomplete one, and `sealReadinessView` short-circuits to `unknown`.
+                heldCount: readiness.heldCount, missingLeaves: readiness.missingLeaves,
+                heldOwn: readiness.heldOwn, heldReceived: readiness.heldReceived,
+                impact: "this side's tree holds a leaf at a position the relay assigned to something else; the relay's ordering is what gets notarized, so a bilateral seal may be refused and this side cannot tell in advance",
+            });
+            return {
+                ok: false,
+                reason: "session_record_diverged",
+                tree_size: readiness.treeSize,
+                relay_high_water: readiness.highWaterSeq,
+                held_messages: readiness.heldCount,
+                missing_leaves: readiness.missingLeaves,
+                held_own: readiness.heldOwn,
+                held_received: readiness.heldReceived,
+                // Review HIGH-1: SAY WHAT WAS MEASURED, NOT WHAT IS PREDICTED. The earlier wording asserted
+                // the counterparty would refuse with `leaf_count_mismatch` and that force was the only exit.
+                // Neither is established here. What is measured is that THIS tree parted from THE RELAY's
+                // counter. The bilateral check compares LEAF COUNT, not the root (`seal-flows.ts`:
+                // "Merkle-root agreement is NOT verified at this leaf-exchange layer"), and both sides
+                // append a behind-frontier leaf at the tail — so if the counterparty skewed the same way
+                // the counts still agree and the seal can succeed. Predicting their refusal was an
+                // over-claim, and offering force-abandon as "the only exit" pointed at the one irreversible
+                // action while the codebase's own mismatch handling leaves the session retryable.
+                guidance: `This side's record no longer agrees with the relay's ordering — your tree holds ${readiness.treeSize} message(s) and the relay's counter is at ${readiness.highWaterSeq + 1}. ` +
+                    `The relay's ordering is what gets notarized, so sealing now may be refused. It may also succeed: the bilateral check compares message COUNTS, not contents, so if the counterparty's record skewed the same way the counts still match. This side cannot tell which from here. ` +
+                    `What is certain is that this will not resolve on its own — nothing backfills or re-numbers a leaf, so waiting does not change it. ` +
+                    `Compare message counts with the counterparty before deciding; cello_transcript ${sessionId} shows your full record and it stays readable whatever you choose. ` +
+                    `cello_close_session ${sessionId} { force: true } ends the session with NO notarized receipt and cannot be undone — the last resort, not the next step.`,
+            };
+        }
         if (sealable && !readiness.ready) {
             logger.warn("session.seal.blocked_incomplete", {
                 agentName: record.agent_name, sessionId,
@@ -523,12 +604,34 @@ export function registerCloseSessionHandler(deps) {
                     `. Everything here is waiting on an earlier message from the counterparty that has not arrived; the daemon just pulled from the relay and the gap is still there, so wait a moment and close again. If it does not resolve, cello_transcript ${sessionId} shows what did arrive, and cello_close_session ${sessionId} { force: true } abandons it terminally (no receipt).`,
             };
         }
-        // AC-011: seal-interrupted already in progress
+        /**
+         * AC-011: a seal attempt is already running for this session.
+         *
+         * DOD-M15-CLOSEWAIT-1 review HIGH-3 rewrote this, because the change made it COMMON and the old
+         * wording did not survive contact:
+         *
+         *   - it said *"wait for `session.interrupted.sealed` to appear in the daemon logs"*. That event
+         *     is emitted NOWHERE in the tree — grep finds it only inside this string. An operator would
+         *     tail a log for a line that cannot arrive.
+         *   - it named the seal-INTERRUPTED subsystem, but the common case now is an ACTIVE session
+         *     whose background ceremony is mid-flight. Wrong subsystem, on the path an operator most
+         *     often reaches.
+         *   - it was hard to reach before, because the first close held the caller for the whole
+         *     ceremony. Now the operator has their terminal back for up to eleven minutes, and
+         *     re-closing is the obvious move.
+         */
         if (sealInterruptedInProgress.has(sealKey(record.agent_name, sessionId))) {
             return {
                 ok: false,
-                reason: "seal_interrupted_in_progress",
-                guidance: "A seal-interrupted attempt is already in progress for this session. Wait for session.interrupted.sealed to appear in the daemon logs before retrying. Do not call cello_close_session again until the current attempt completes or times out.",
+                reason: "seal_in_progress",
+                seal_status: "committed",
+                guidance: "A seal ceremony is ALREADY RUNNING for this session — your commitment is recorded and " +
+                    "there is nothing to retry. This is the normal state after a close: the close answers as " +
+                    "soon as the commitment is durable and notarizes in the background, which waits for the " +
+                    "counterparty and can take several minutes. Fetch the result with cello_sealed_receipt " +
+                    `(session_id ${sessionId}); a seal_in_progress answer there means the same thing — still ` +
+                    "running, not failed. Do NOT re-close with { force: true } to hurry it: forcing ABANDONS " +
+                    "the session and permanently forfeits the receipt this ceremony is about to produce.",
             };
         }
         // DB-001: signaling stream reconnecting
@@ -706,6 +809,16 @@ export function registerCloseSessionHandler(deps) {
             // seal handlers) for the duration of the seal, then release it in finally. Same-node sessions have
             // no entry here and use the home stream unchanged.
             let sealBrokerConn = null;
+            // DOD-M15-CLOSEWAIT-1: set when the seal tail is handed to a background task, so the enclosing
+            // finally does not release a broker connection that ceremony still needs.
+            let handedOff = false;
+            /**
+             * The caller may still ASK to block. Default is the new contract (answer on commitment);
+             * `wait_for_seal: true` restores the inline behaviour for a script that genuinely wants the
+             * receipt in one call and will wait up to eleven minutes for it. Opt-IN rather than opt-out,
+             * because the default has to be the one that does not freeze an interactive operator.
+             */
+            const waitForSeal = params?.["wait_for_seal"] === true;
             try {
                 // Memory only, deliberately. An ACTIVE session has not been through the restart that
                 // empties the broker map, so the entry is there when it is needed — and a lookup here would
@@ -812,60 +925,216 @@ export function registerCloseSessionHandler(deps) {
                 // long this can legitimately take, and what forcing costs.
                 logger.warn("session.seal.awaiting_counterparty", {
                     sessionId, agentName: record.agent_name, deadlineMs: bilateralTimeoutMs, correlationId,
-                    impact: `this close will not answer for up to ${Math.round(bilateralTimeoutMs / 60_000)} minutes while it waits for the counterparty, then it escalates to a unilateral seal and produces a real receipt. It is working. Do NOT force-abandon it — that forfeits the receipt this wait is earning.`,
+                    impact: `the seal is waiting for the counterparty for up to ${Math.round(bilateralTimeoutMs / 60_000)} minutes, then escalates to a unilateral seal and produces a real receipt. It is working. Do NOT force-abandon it — that forfeits the receipt this wait is earning.`,
                 });
-                let timer;
-                const timeoutP = new Promise((r) => { timer = setTimeout(() => r(null), bilateralTimeoutMs); });
-                const sealedCompletion = await Promise.race([sealedP, timeoutP]);
-                clearTimeout(timer);
-                pendingSealWaiters.delete(sealKey(record.agent_name, sessionId));
-                if (sealedCompletion !== null) {
-                    logger.info("session.seal.completed", { sessionId, sealedRoot: sealedCompletion.rootHex, role: "bilateral", correlationId });
-                    crossNodeBrokerBySession.delete(`${record.agent_name}:${sessionId}`); // Fix #1 review: evict on terminal seal success (a FAILED close keeps the entry so a retry can still reconnect).
-                    // M7-SESSION-004 (AC-006): return the legibility certificate on the seal completion so
-                    // a reader gets it on the same surface that proves the seal — receipt-not-assent,
-                    // per-party frontiers, attestation modes, and final_message.answered.
-                    return { ok: true, sealed_root: sealedCompletion.rootHex, legibility: sealedCompletion.legibility };
-                }
-                // M8B FINDING-1: `responder_seal_already_submitted` has two producers — (a) the auto-ack
-                // path submitted our leaf because the COUNTERPARTY's SEAL arrived, or (b) our OWN earlier
-                // close submitted it and the counterparty never co-closed. The result now carries the
-                // first submit's reportedRootHex/sequenceNumber, so a retry close can still escalate to a
-                // unilateral seal (case b — the live-deadlock path). We deliberately do NOT distinguish
-                // (a) from (b) client-side: the bilateral wait above already gave case (a) its window, and
-                // the directory's grace/already-sealed gates arbitrate a redundant seal_unilateral — that
-                // is the sovereign-node-correct shape. Only when the not-ok result carries NO root (the
-                // first submit is still in flight) is "pending" the honest terminal answer here.
-                const escalation = submit.ok
-                    ? { reportedRootHex: submit.reportedRootHex, sequenceNumber: submit.sequenceNumber }
-                    : submit.reason === "responder_seal_already_submitted" &&
-                        typeof submit.reportedRootHex === "string" &&
-                        typeof submit.sequenceNumber === "number"
+                /**
+                 * DOD-M15-CLOSEWAIT-1 — THE TAIL, EXTRACTED SO IT CAN OUTLIVE THE RESPONSE.
+                 *
+                 * Everything from here to the escalation is "wait for the counterparty, then escalate if
+                 * they never came". It ran inline, which is why the caller sat on a frozen command for up to
+                 * eleven minutes while it worked correctly — and why one operator force-abandoned seventeen
+                 * sessions, forfeiting the exact receipts the wait was earning.
+                 *
+                 * Extracting it changes nothing about WHAT is signed or in what order: same race, same
+                 * escalation, same leaf. It changes only who waits for it. (Decisions Carried #4.)
+                 *
+                 * `rec`/`sid` are captured because TypeScript discards the narrowing of `record` and
+                 * `sessionId` inside a nested function.
+                 */
+                const rec = record;
+                const sid = sessionId;
+                const awaitSealAndEscalate = async () => {
+                    let timer;
+                    const timeoutP = new Promise((r) => { timer = setTimeout(() => r(null), bilateralTimeoutMs); });
+                    const sealedCompletion = await Promise.race([sealedP, timeoutP]);
+                    clearTimeout(timer);
+                    pendingSealWaiters.delete(sealKey(record.agent_name, sessionId));
+                    /**
+                     * THE CERTIFICATE WAS REFUSED — `DOD-M15-SEALWIRE-1` bullet 2 (review F4).
+                     *
+                     * The seal arrived, its signature verified, and its root did not describe this conversation.
+                     * Before this the coordinator logged and dropped the waiter, so control fell through to the
+                     * eleven-minute timeout and the operator was told the counterparty had not closed — about a
+                     * counterparty who had, and whose certificate had just been refused here.
+                     *
+                     * Answered immediately instead, with what was actually detected. NOT retryable, and it says
+                     * so: `session_sealed` is delivered once, so a retry re-enters the same wait and then finds
+                     * the relay session gone.
+                     */
+                    if (sealedCompletion !== null && "refused" in sealedCompletion) {
+                        logger.error("session.seal.refused", {
+                            sessionId, agentName: record.agent_name, correlationId,
+                            reason: sealedCompletion.reason, detail: sealedCompletion.detail,
+                        });
+                        return {
+                            ok: false,
+                            reason: sealedCompletion.reason,
+                            seal_status: "refused",
+                            ...(sealedCompletion.ownRootHex ? { own_root: sealedCompletion.ownRootHex } : {}),
+                            guidance: "The directory returned a VALIDLY SIGNED seal whose root does not describe this " +
+                                `conversation (${sealedCompletion.detail}). This daemon refused it: the session is NOT ` +
+                                "marked sealed, your transcript is untouched, and nothing was signed with your key. " +
+                                "Do NOT retry the close — the seal notification is delivered once, so a retry waits the " +
+                                "full window and then finds the relay session gone. Do NOT force-abandon either: that " +
+                                "permanently forfeits any receipt. Compare the leaf count and the message list with your " +
+                                "counterparty, and report the session id — this is a directory or relay fault, not " +
+                                "something you did.",
+                        };
+                    }
+                    if (sealedCompletion !== null) {
+                        logger.info("session.seal.completed", { sessionId, sealedRoot: sealedCompletion.rootHex, role: "bilateral", correlationId });
+                        crossNodeBrokerBySession.delete(`${record.agent_name}:${sessionId}`); // Fix #1 review: evict on terminal seal success (a FAILED close keeps the entry so a retry can still reconnect).
+                        // M7-SESSION-004 (AC-006): return the legibility certificate on the seal completion so
+                        // a reader gets it on the same surface that proves the seal — receipt-not-assent,
+                        // per-party frontiers, attestation modes, and final_message.answered.
+                        return { ok: true, sealed_root: sealedCompletion.rootHex, legibility: sealedCompletion.legibility };
+                    }
+                    // M8B FINDING-1: `responder_seal_already_submitted` has two producers — (a) the auto-ack
+                    // path submitted our leaf because the COUNTERPARTY's SEAL arrived, or (b) our OWN earlier
+                    // close submitted it and the counterparty never co-closed. The result now carries the
+                    // first submit's reportedRootHex/sequenceNumber, so a retry close can still escalate to a
+                    // unilateral seal (case b — the live-deadlock path). We deliberately do NOT distinguish
+                    // (a) from (b) client-side: the bilateral wait above already gave case (a) its window, and
+                    // the directory's grace/already-sealed gates arbitrate a redundant seal_unilateral — that
+                    // is the sovereign-node-correct shape. Only when the not-ok result carries NO root (the
+                    // first submit is still in flight) is "pending" the honest terminal answer here.
+                    const escalation = submit.ok
                         ? { reportedRootHex: submit.reportedRootHex, sequenceNumber: submit.sequenceNumber }
-                        : null;
-                if (!escalation) {
-                    return {
-                        ok: false,
-                        reason: "seal_pending_bilateral",
-                        guidance: "Your SEAL leaf is recorded (auto-acknowledged) and the bilateral seal is completing, but it did not finalize within the wait window. Check cello status and the daemon logs; retry cello_close_session if the session remains unsealed.",
-                    };
-                }
-                // SESSION-002 (DOD-SEAL): the counterparty did not co-close. Escalate to a UNILATERAL
-                // seal. The body now lives in escalateToUnilateralSeal so the INTERRUPTED branch can reach
-                // it too — it never could, and that is why an interrupted session could not get a receipt.
-                return await escalateToUnilateralSeal(record, sessionId, escalation, correlationId);
+                        : submit.reason === "responder_seal_already_submitted" &&
+                            typeof submit.reportedRootHex === "string" &&
+                            typeof submit.sequenceNumber === "number"
+                            ? { reportedRootHex: submit.reportedRootHex, sequenceNumber: submit.sequenceNumber }
+                            : null;
+                    if (!escalation) {
+                        return {
+                            ok: false,
+                            reason: "seal_pending_bilateral",
+                            guidance: "Your SEAL leaf is recorded (auto-acknowledged) and the bilateral seal is completing, but it did not finalize within the wait window. Check cello status and the daemon logs; retry cello_close_session if the session remains unsealed.",
+                        };
+                    }
+                    // SESSION-002 (DOD-SEAL): the counterparty did not co-close. Escalate to a UNILATERAL
+                    // seal. The body now lives in escalateToUnilateralSeal so the INTERRUPTED branch can reach
+                    // it too — it never could, and that is why an interrupted session could not get a receipt.
+                    return await escalateToUnilateralSeal(rec, sid, escalation, correlationId);
+                };
+                /**
+                 * OWNERSHIP OF THE BROKER CONNECTION MOVES WITH THE TAIL.
+                 *
+                 * This is the one genuinely dangerous part of the change. The enclosing `finally` releases
+                 * `sealBrokerConn`; if it ran while the tail was still going, the background seal would lose
+                 * the connection it is waiting on. So the tail releases it itself, and the enclosing
+                 * `finally` stands down via `handedOff`.
+                 *
+                 * PRECISELY WHAT IS LOST, corrected after review: not a corrupted seal. The escalation goes
+                 * over the HOME stream, so it still completes. What this connection carries is the
+                 * `seal_verified` / `session_sealed` push for a CROSS-NODE bilateral seal — so releasing it
+                 * early silently downgrades every cross-node close from a bilateral receipt to a unilateral
+                 * one, eleven minutes later. Quieter than corruption, and still worth the guard.
+                 */
+                const finishSeal = async () => {
+                    try {
+                        return await awaitSealAndEscalate();
+                    }
+                    finally {
+                        if (sealBrokerConn) {
+                            try {
+                                await sealBrokerConn.stop("seal-complete");
+                            }
+                            catch (err) {
+                                logger.warn("session.seal.broker.release_failed", { sessionId: sid, reason: err instanceof Error ? err.message : String(err) });
+                            }
+                            sealBrokerConn = null;
+                        }
+                        sealInterruptedInProgress.delete(sealKey(rec.agent_name, sid));
+                    }
+                };
+                /**
+                 * A NEW CEREMONY IS STARTING, so any previous failure verdict is now false.
+                 *
+                 * ABOVE the `waitForSeal` branch — review MEDIUM-4. It used to sit below, so the clear ran
+                 * only on the handed-off path: a blocking re-close (which the MCP tool exposes and the
+                 * document-delivery seal uses) left the old marker in place, and a stale `seal_failed` from
+                 * half an hour earlier was then reported as the current state. That is `STALEROSTER-1`'s
+                 * defect, in the store whose own docstring says it avoids it.
+                 */
+                sealFailures.clear(rec.agent_name, sid);
+                if (waitForSeal)
+                    return await finishSeal();
+                handedOff = true;
+                /**
+                 * Detached deliberately, and never awaited. A rejection must not become an unhandled
+                 * rejection — and must not be silent either: the operator has already been told the seal is
+                 * running, so a failure they never hear about is the worst of both worlds.
+                 */
+                const tail = finishSeal();
+                /**
+                 * TRACKED FOR SHUTDOWN — review MEDIUM-6.
+                 *
+                 * `stop()` cancels or awaits every other background worker: the reconcile scheduler, the
+                 * telegram poller, the manifest poll, the roster sweep. `RestartSealResolver.stop()` goes
+                 * further and AWAITS its in-flight seal, with a comment saying exactly why — *"severing
+                 * signaling under a half-finished seal-interrupted exchange leaves the counterparty holding
+                 * a commitment we never acknowledged… permanently divergent."*
+                 *
+                 * A detached, untracked ceremony was the one background task that could be cut at an
+                 * arbitrary point by `cello logout`. Recoverable on the next boot, but recoverable is not
+                 * the same as not breaking it.
+                 */
+                registerBackgroundSeal?.(tail);
+                void tail.then((result) => {
+                    const r = result;
+                    if (r?.ok) {
+                        sealFailures.clear(rec.agent_name, sid);
+                        logger.info("session.seal.background.completed", { sessionId: sid, agentName: rec.agent_name, correlationId });
+                    }
+                    else {
+                        /**
+                         * THE BRANCH PRODUCTION ACTUALLY TAKES — review HIGH-1.
+                         *
+                         * `escalateToUnilateralSeal` contains zero `throw`s: all nine of its failure paths
+                         * RESOLVE with `{ ok: false, reason }`. So recording only in the `.catch` below meant
+                         * every ordinary dead ceremony went unrecorded and `cello_sealed_receipt` kept
+                         * answering `not_sealed_yet` — the very answer this unit exists to replace. The log
+                         * line three lines down said so out loud the whole time.
+                         */
+                        sealFailures.record(rec.agent_name, sid, r?.reason ?? "seal_unresolved", new Date().toISOString(), "unresolved");
+                        logger.warn("session.seal.background.unresolved", {
+                            sessionId: sid, agentName: rec.agent_name, correlationId, reason: r?.reason,
+                            impact: "the close already answered; this session holds a durable commitment but has no receipt yet.",
+                            guidance: "cello_sealed_receipt now reports seal_failed with this reason; a daemon restart also retries it.",
+                        });
+                    }
+                }, (err) => {
+                    // RECORDED FOR THE RESPONSE, not only the log. The caller already holds `ok: true`, so a
+                    // failure that lives only in daemon.log is one the agent has no way to discover.
+                    sealFailures.record(rec.agent_name, sid, err instanceof Error ? err.message : String(err), new Date().toISOString(), "threw");
+                    logger.error("session.seal.background.failed", {
+                        sessionId: sid, agentName: rec.agent_name, correlationId,
+                        error: err instanceof Error ? err.message : String(err),
+                        impact: "the close already answered ok; the notarization did NOT complete and no receipt exists.",
+                        guidance: "The commitment is durable — a daemon restart resolves it via the restart seal resolver.",
+                    });
+                });
+                return describeSealCommitted({ sessionId: sid, deadlineMs: bilateralTimeoutMs });
             }
             finally {
                 // Fix #1: release the transient broker seal-connection (best-effort; the seal result stands).
-                if (sealBrokerConn) {
-                    try {
-                        await sealBrokerConn.stop("seal-complete");
-                    }
-                    catch (err) {
-                        logger.warn("session.seal.broker.release_failed", { sessionId, reason: err instanceof Error ? err.message : String(err) });
+                //
+                // DOD-M15-CLOSEWAIT-1: skipped when the tail was handed to a background task, which owns
+                // this cleanup itself. Releasing here would pull the transport out from under a ceremony
+                // still in flight — the one way this change could corrupt a seal rather than merely report
+                // it differently.
+                if (!handedOff) {
+                    if (sealBrokerConn) {
+                        try {
+                            await sealBrokerConn.stop("seal-complete");
+                        }
+                        catch (err) {
+                            logger.warn("session.seal.broker.release_failed", { sessionId, reason: err instanceof Error ? err.message : String(err) });
+                        }
                     }
+                    sealInterruptedInProgress.delete(sealKey(record.agent_name, sessionId));
                 }
-                sealInterruptedInProgress.delete(sealKey(record.agent_name, sessionId));
             }
         }
         // DOD-M12B-PENDING-EXIT-1 — `seal_interrupted_pending` had NO exit, and the refusal below told
@@ -897,12 +1166,36 @@ export function registerCloseSessionHandler(deps) {
                     // started yet", which a freshly booted daemon reports for every session. The genuinely
                     // permanent case (the relay released the session) has its own reason,
                     // `seal_carry_empty`, raised inside the escalation where it is actually known.
+                    /**
+                     * ⚠️ "USUALLY LOCAL AND TEMPORARY" IS NOT TRUE OF EVERY REASON, AND THE ONES IT IS FALSE
+                     * FOR ARE THE ONES DESIGNED TO FAIL LOUD — review pass 2, MEDIUM-4.
+                     *
+                     * The sentence below was fixed text wrapped around whatever reason arrived. That is right
+                     * for `standing_receiver_unavailable` and a relay this daemon cannot reach. It is wrong
+                     * for the client-side seal-payload guards, which fire only on a deterministic defect that
+                     * will never clear — and the operator was being sent to `cello_start_agent`, `cello_status`
+                     * and an endless retry for a bug in this daemon.
+                     *
+                     * A guard built to fail loud, converted back into "try again later" by the sentence that
+                     * reports it. Enumerated, never pattern-matched: a substring rule would absorb the next
+                     * reason nobody has considered, which is the same collapse in a new coat.
+                     */
+                    const NON_RETRYABLE_SEAL_SUBMIT_REASONS = new Set([
+                        "seal_payload_not_carried",
+                        "seal_payload_unbound",
+                        "seal_payload_invalid",
+                        "content_not_permitted_for_leaf_kind",
+                    ]);
                     return {
                         ok: false,
                         reason: uni.reason,
-                        guidance: `This session holds a bilateral commitment, but no notarization could be requested for it: ${uni.reason}. ` +
-                            `That is usually local and temporary — an agent that is not started yet (cello_start_agent), or a relay this daemon cannot currently reach (cello_status). ` +
-                            `The conversation is intact either way; retry cello_close_session once the daemon reports healthy.`,
+                        guidance: NON_RETRYABLE_SEAL_SUBMIT_REASONS.has(uni.reason)
+                            ? `This session holds a bilateral commitment, but no notarization could be requested for it: ${uni.reason}. ` +
+                                `This one is NOT transient and retrying will not clear it — it is a defect in this daemon's seal path, refused locally before anything was sent. ` +
+                                `The conversation is intact and nothing was disclosed. Report the reason code above; the daemon log carries the detail under session.relay.submit.*.`
+                            : `This session holds a bilateral commitment, but no notarization could be requested for it: ${uni.reason}. ` +
+                                `That is usually local and temporary — an agent that is not started yet (cello_start_agent), or a relay this daemon cannot currently reach (cello_status). ` +
+                                `The conversation is intact either way; retry cello_close_session once the daemon reports healthy.`,
                     };
                 }
                 if (uni.ok)