@securecoms/agent-bridge 0.11.1 → 0.11.3

package/dist/bin.js

@@ -1471,6 +1471,16 @@ function isServerExpired(exp, nowMs) {
   return nowMs - SKEW_GUARD_MS >= exp.getTime();
 }
 
+// ../connect-sdk-ts/dist/sodium-ready.js
+import { generateEphemeralKeypair } from "@agentvault/crypto";
+var warming = null;
+function ensureSodiumReady() {
+  return warming ??= generateEphemeralKeypair().then(() => void 0).catch((e) => {
+    warming = null;
+    throw e;
+  });
+}
+
 // ../connect-sdk-ts/dist/groupkey/mls.js
 var LABEL = "agentvault-connect-v1";
 var DEFAULT_STUCK_THRESHOLD = 2;
@@ -1546,8 +1556,6 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
   o;
   suite;
   managers = /* @__PURE__ */ new Map();
-  /** One-time libsodium (WASM) warm-up guard — see ensureCryptoReady(). */
-  cryptoWarmed = false;
   /**
    * Per-CHANNEL Promise-chain mutex (gen2's MlsOperationQueue, ported). Every
    * manager-mutating operation on a channel takes this lock keyed by channelId,
@@ -2072,37 +2080,8 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
     const w = rows.find((r) => r.message_type === "welcome" && r.connect_channel_id != null);
     return w?.connect_channel_id ?? null;
   }
-  /**
-   * Give the ts-mls libsodium (WASM) backend time to initialize before any
-   * store operation that deserializes a persisted KeyPackage. generateKeyPackage
-   * is pure in-memory (it neither publishes to the backend nor writes the
-   * store), so the throwaway bundle is a side-effect-free warm-up.
-   *
-   * ⛔ IT IS A RACE, NOT A BARRIER, and do not read it as one. Nothing on this
-   * path awaits sodium.ready: MLSGroupManager defaults _provider to
-   * nobleCryptoProvider, and _ensureCiphersuite passes that provider to
-   * getCiphersuiteImpl. What the warm-up actually does is BURN WALL CLOCK while
-   * libsodium's WASM initializes in PARALLEL. The margin is roughly 1.7 ms and
-   * it DRIFTS: libsodium-sumo is reached through a caret and its init timing
-   * sets the margin, so an install can move it with no change in this repo.
-   * See 02f47e15 (PR #87), whose commit body carries the correct diagnosis.
-   *
-   * Without it, the FIRST loadPendingBundle at boot (the republish
-   * guard, and the join path) runs while WASM is still cold, throws deep in the
-   * crypto ("Cannot read properties of undefined (reading '_malloc')"), is caught
-   * and misread as "no held bundle", and the daemon mints + republishes a FRESH
-   * KeyPackage on every restart — orphaning every Welcome sealed to the prior
-   * published KP (the root cause of "fresh DM never opens" across restarts).
-   * Idempotent and cheap (~ms); the flag makes repeat calls no-ops.
-   */
-  async ensureCryptoReady() {
-    if (this.cryptoWarmed)
-      return;
-    await new MLSGroupManager2().generateKeyPackage(this.o.identity);
-    this.cryptoWarmed = true;
-  }
   async publishKeyPackage() {
-    await this.ensureCryptoReady();
+    await ensureSodiumReady();
     return this.publishLock.run(this.o.deviceId, () => this.publishKeyPackageUnlocked());
   }
   /**
@@ -2143,8 +2122,36 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
    * even then a supersede Welcome self-heals next cycle (held == published again).
    *
    * Best-effort: any error resolving either side returns false, so the caller
-   * force-republishes (the conservative recovery). */
+   * force-republishes (the conservative recovery).
+   *
+   * ⛔⛔ THE READINESS BARRIER SITS OUTSIDE THE `try`, AND MOVING IT INSIDE
+   * RE-OPENS A SILENT FLEET-WIDE KEYPACKAGE ROTATION. The bare catch below is
+   * deliberate for the two things it was written for (a store read that fails,
+   * a backend fetch that fails), and for those `false` is the conservative
+   * answer. A readiness-barrier rejection is NOT one of those things. It means
+   * libsodium's WASM heap is broken, so this process cannot answer the question
+   * at all — and `false` is not "I don't know", it is an INSTRUCTION:
+   * `connect-agent-bridge/src/bridge-agent.ts:868` routes `false` straight to
+   * `forceRepublishKeyPackage()`, which DELETES the held bundle at `:1069` below
+   * and mints a replacement KeyPackage, orphaning every in-flight Welcome sealed
+   * to the prior one.
+   *
+   * ⛔ AND THE ROTATION COMPLETES RATHER THAN TEARING, WHICH IS WHY IT IS THE
+   * WORSE OUTCOME. `bytesToHex` is `sodium.to_hex` and touches no WASM heap,
+   * `generateKeyPackage` runs on noble, and the envelope seal runs on
+   * `@noble/ciphers` (`connect-core/src/envelope/aead.ts:41-43`). The daemon ends
+   * CONSISTENT and silently stranded, not crashed.
+   *
+   * ⛔ THIS IS THE ROUTE THAT FALSIFIES "a barrier rejection is always a loud
+   * boot failure". `heldBundleMatchesPublishedKp` also runs on the periodic
+   * self-heal sweep, so it is not a boot-only path. Hoisting the await is what
+   * makes the rejection propagate to the caller instead of being read as a
+   * verdict. Pinned by
+   * `packages/connect-mls-store/src/barrier-rejection-rotation.gate.test.ts`
+   * (G-H1), whose control case proves the resolving path still answers both
+   * `true` and `false`. */
   async heldBundleMatchesPublishedKp() {
+    await ensureSodiumReady();
     try {
       const bundle = await this.o.store.loadPendingBundle(this.o.deviceId);
       if (!bundle)
@@ -2189,7 +2196,7 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
   async ensureSessionUnlocked(channelId, opts) {
     if (!opts.forceReinit && await this.o.store.load(channelId))
       return;
-    await this.ensureCryptoReady();
+    await ensureSodiumReady();
     let bundle = await this.o.store.loadPendingBundle(this.o.deviceId);
     if (!bundle && (opts.bootstrap || opts.forceReinit)) {
       await this.publishKeyPackage();
@@ -4619,6 +4626,22 @@ var SqliteMlsStateStore = class {
   async discardStaging(channelId) {
     this.db.prepare("UPDATE mls_group_state SET sealed_staging=NULL WHERE identity_id=? AND channel_id=?").run(this.id, channelId);
   }
+  /**
+   * ⛔ THE WRITE PATH GETS NO READINESS BARRIER, AND THAT IS DELIBERATE. Two
+   * independent reasons, and the FIRST is the primary one.
+   *
+   * 1. `:191` below populates `this.bundles` BEFORE the seal at `:192`.
+   *    A same-process reload therefore hits the cache at `loadPendingBundle`'s
+   *    `:202-203` and NEVER decodes. The decode path is only ever taken for a
+   *    bundle written by a PREVIOUS process, which by definition is not this
+   *    one. A barrier here could not protect the read that actually fails.
+   * 2. `encodeBundle`'s `bytesToHex` is cold-safe BECAUSE `to_hex` needs no
+   *    `_malloc`. ⛔ IT IS NOT "PURE JS" AND THE COMMENT MUST NEVER SAY THAT.
+   *    It is a libsodium call like the others; it simply does not touch the
+   *    WASM heap. Recording the wrong reason invites a later reader to
+   *    "correct" the asymmetry between this method and `loadPendingBundle` in
+   *    the wrong direction.
+   */
   async savePendingBundle(ref, bundle) {
     this.bundles.set(ref, bundle);
     const sealed = await this.cipher.seal(encodeBundle(bundle));
@@ -4633,13 +4656,12 @@ var SqliteMlsStateStore = class {
     const row = this.db.prepare("SELECT sealed_bundle FROM mls_pending_bundle WHERE identity_id=? AND ref=?").get(this.id, ref);
     if (!row?.sealed_bundle)
       return null;
+    await ensureSodiumReady();
     let bundle;
     try {
       bundle = decodeBundle(await this.cipher.open(row.sealed_bundle));
     } catch (e) {
-      if (typeof process !== "undefined" && process.env?.SECURECOMS_TRACE_DELIVERY) {
-        console.warn(`[trace] loadPendingBundle: unseal/decode FAILED for ref ${ref.slice(0, 8)}: ${e?.message}`);
-      }
+      console.warn(`[trace] loadPendingBundle: unseal/decode FAILED for ref ${ref.slice(0, 8)}: ${e?.message}`);
       return null;
     }
     this.bundles.set(ref, bundle);
@@ -5116,13 +5138,8 @@ async function materializeAttachment(body, ctx, deps) {
 }
 
 // src/sodium-ready.ts
-import { generateEphemeralKeypair } from "@agentvault/crypto";
-var warming = null;
-function ensureSodiumReady() {
-  return warming ??= generateEphemeralKeypair().then(() => void 0).catch((e) => {
-    warming = null;
-    throw e;
-  });
+function ensureSodiumReady2() {
+  return ensureSodiumReady();
 }
 
 // src/memory/hermes-session-map.ts
@@ -6538,7 +6555,7 @@ var BridgeAgent = class _BridgeAgent {
   }
   sendDeps() {
     return {
-      ready: () => ensureSodiumReady(),
+      ready: () => ensureSodiumReady2(),
       uploadBlob: (ciphertext, channelId) => this.uploadBlobImpl(ciphertext, channelId),
       encryptFile,
       bytesToBase64: bytesToBase642,
@@ -6547,7 +6564,7 @@ var BridgeAgent = class _BridgeAgent {
   }
   receiveDeps() {
     return {
-      ready: () => ensureSodiumReady(),
+      ready: () => ensureSodiumReady2(),
       downloadBlob: this.downloadBlobImpl,
       decryptFile,
       computeFileDigest,

package/dist/index.js

@@ -1368,6 +1368,16 @@ function isServerExpired(exp, nowMs) {
   return nowMs - SKEW_GUARD_MS >= exp.getTime();
 }
 
+// ../connect-sdk-ts/dist/sodium-ready.js
+import { generateEphemeralKeypair } from "@agentvault/crypto";
+var warming = null;
+function ensureSodiumReady() {
+  return warming ??= generateEphemeralKeypair().then(() => void 0).catch((e) => {
+    warming = null;
+    throw e;
+  });
+}
+
 // ../connect-sdk-ts/dist/groupkey/mls.js
 var LABEL = "agentvault-connect-v1";
 var DEFAULT_STUCK_THRESHOLD = 2;
@@ -1443,8 +1453,6 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
   o;
   suite;
   managers = /* @__PURE__ */ new Map();
-  /** One-time libsodium (WASM) warm-up guard — see ensureCryptoReady(). */
-  cryptoWarmed = false;
   /**
    * Per-CHANNEL Promise-chain mutex (gen2's MlsOperationQueue, ported). Every
    * manager-mutating operation on a channel takes this lock keyed by channelId,
@@ -1969,37 +1977,8 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
     const w = rows.find((r) => r.message_type === "welcome" && r.connect_channel_id != null);
     return w?.connect_channel_id ?? null;
   }
-  /**
-   * Give the ts-mls libsodium (WASM) backend time to initialize before any
-   * store operation that deserializes a persisted KeyPackage. generateKeyPackage
-   * is pure in-memory (it neither publishes to the backend nor writes the
-   * store), so the throwaway bundle is a side-effect-free warm-up.
-   *
-   * ⛔ IT IS A RACE, NOT A BARRIER, and do not read it as one. Nothing on this
-   * path awaits sodium.ready: MLSGroupManager defaults _provider to
-   * nobleCryptoProvider, and _ensureCiphersuite passes that provider to
-   * getCiphersuiteImpl. What the warm-up actually does is BURN WALL CLOCK while
-   * libsodium's WASM initializes in PARALLEL. The margin is roughly 1.7 ms and
-   * it DRIFTS: libsodium-sumo is reached through a caret and its init timing
-   * sets the margin, so an install can move it with no change in this repo.
-   * See 02f47e15 (PR #87), whose commit body carries the correct diagnosis.
-   *
-   * Without it, the FIRST loadPendingBundle at boot (the republish
-   * guard, and the join path) runs while WASM is still cold, throws deep in the
-   * crypto ("Cannot read properties of undefined (reading '_malloc')"), is caught
-   * and misread as "no held bundle", and the daemon mints + republishes a FRESH
-   * KeyPackage on every restart — orphaning every Welcome sealed to the prior
-   * published KP (the root cause of "fresh DM never opens" across restarts).
-   * Idempotent and cheap (~ms); the flag makes repeat calls no-ops.
-   */
-  async ensureCryptoReady() {
-    if (this.cryptoWarmed)
-      return;
-    await new MLSGroupManager2().generateKeyPackage(this.o.identity);
-    this.cryptoWarmed = true;
-  }
   async publishKeyPackage() {
-    await this.ensureCryptoReady();
+    await ensureSodiumReady();
     return this.publishLock.run(this.o.deviceId, () => this.publishKeyPackageUnlocked());
   }
   /**
@@ -2040,8 +2019,36 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
    * even then a supersede Welcome self-heals next cycle (held == published again).
    *
    * Best-effort: any error resolving either side returns false, so the caller
-   * force-republishes (the conservative recovery). */
+   * force-republishes (the conservative recovery).
+   *
+   * ⛔⛔ THE READINESS BARRIER SITS OUTSIDE THE `try`, AND MOVING IT INSIDE
+   * RE-OPENS A SILENT FLEET-WIDE KEYPACKAGE ROTATION. The bare catch below is
+   * deliberate for the two things it was written for (a store read that fails,
+   * a backend fetch that fails), and for those `false` is the conservative
+   * answer. A readiness-barrier rejection is NOT one of those things. It means
+   * libsodium's WASM heap is broken, so this process cannot answer the question
+   * at all — and `false` is not "I don't know", it is an INSTRUCTION:
+   * `connect-agent-bridge/src/bridge-agent.ts:868` routes `false` straight to
+   * `forceRepublishKeyPackage()`, which DELETES the held bundle at `:1069` below
+   * and mints a replacement KeyPackage, orphaning every in-flight Welcome sealed
+   * to the prior one.
+   *
+   * ⛔ AND THE ROTATION COMPLETES RATHER THAN TEARING, WHICH IS WHY IT IS THE
+   * WORSE OUTCOME. `bytesToHex` is `sodium.to_hex` and touches no WASM heap,
+   * `generateKeyPackage` runs on noble, and the envelope seal runs on
+   * `@noble/ciphers` (`connect-core/src/envelope/aead.ts:41-43`). The daemon ends
+   * CONSISTENT and silently stranded, not crashed.
+   *
+   * ⛔ THIS IS THE ROUTE THAT FALSIFIES "a barrier rejection is always a loud
+   * boot failure". `heldBundleMatchesPublishedKp` also runs on the periodic
+   * self-heal sweep, so it is not a boot-only path. Hoisting the await is what
+   * makes the rejection propagate to the caller instead of being read as a
+   * verdict. Pinned by
+   * `packages/connect-mls-store/src/barrier-rejection-rotation.gate.test.ts`
+   * (G-H1), whose control case proves the resolving path still answers both
+   * `true` and `false`. */
   async heldBundleMatchesPublishedKp() {
+    await ensureSodiumReady();
     try {
       const bundle = await this.o.store.loadPendingBundle(this.o.deviceId);
       if (!bundle)
@@ -2086,7 +2093,7 @@ var MlsGroupKeyProvider = class _MlsGroupKeyProvider {
   async ensureSessionUnlocked(channelId, opts) {
     if (!opts.forceReinit && await this.o.store.load(channelId))
       return;
-    await this.ensureCryptoReady();
+    await ensureSodiumReady();
     let bundle = await this.o.store.loadPendingBundle(this.o.deviceId);
     if (!bundle && (opts.bootstrap || opts.forceReinit)) {
       await this.publishKeyPackage();
@@ -4516,6 +4523,22 @@ var SqliteMlsStateStore = class {
   async discardStaging(channelId) {
     this.db.prepare("UPDATE mls_group_state SET sealed_staging=NULL WHERE identity_id=? AND channel_id=?").run(this.id, channelId);
   }
+  /**
+   * ⛔ THE WRITE PATH GETS NO READINESS BARRIER, AND THAT IS DELIBERATE. Two
+   * independent reasons, and the FIRST is the primary one.
+   *
+   * 1. `:191` below populates `this.bundles` BEFORE the seal at `:192`.
+   *    A same-process reload therefore hits the cache at `loadPendingBundle`'s
+   *    `:202-203` and NEVER decodes. The decode path is only ever taken for a
+   *    bundle written by a PREVIOUS process, which by definition is not this
+   *    one. A barrier here could not protect the read that actually fails.
+   * 2. `encodeBundle`'s `bytesToHex` is cold-safe BECAUSE `to_hex` needs no
+   *    `_malloc`. ⛔ IT IS NOT "PURE JS" AND THE COMMENT MUST NEVER SAY THAT.
+   *    It is a libsodium call like the others; it simply does not touch the
+   *    WASM heap. Recording the wrong reason invites a later reader to
+   *    "correct" the asymmetry between this method and `loadPendingBundle` in
+   *    the wrong direction.
+   */
   async savePendingBundle(ref, bundle) {
     this.bundles.set(ref, bundle);
     const sealed = await this.cipher.seal(encodeBundle(bundle));
@@ -4530,13 +4553,12 @@ var SqliteMlsStateStore = class {
     const row = this.db.prepare("SELECT sealed_bundle FROM mls_pending_bundle WHERE identity_id=? AND ref=?").get(this.id, ref);
     if (!row?.sealed_bundle)
       return null;
+    await ensureSodiumReady();
     let bundle;
     try {
       bundle = decodeBundle(await this.cipher.open(row.sealed_bundle));
     } catch (e) {
-      if (typeof process !== "undefined" && process.env?.SECURECOMS_TRACE_DELIVERY) {
-        console.warn(`[trace] loadPendingBundle: unseal/decode FAILED for ref ${ref.slice(0, 8)}: ${e?.message}`);
-      }
+      console.warn(`[trace] loadPendingBundle: unseal/decode FAILED for ref ${ref.slice(0, 8)}: ${e?.message}`);
       return null;
     }
     this.bundles.set(ref, bundle);
@@ -4972,13 +4994,8 @@ async function materializeAttachment(body, ctx, deps) {
 }
 
 // src/sodium-ready.ts
-import { generateEphemeralKeypair } from "@agentvault/crypto";
-var warming = null;
-function ensureSodiumReady() {
-  return warming ??= generateEphemeralKeypair().then(() => void 0).catch((e) => {
-    warming = null;
-    throw e;
-  });
+function ensureSodiumReady2() {
+  return ensureSodiumReady();
 }
 
 // src/memory/hermes-session-map.ts
@@ -6394,7 +6411,7 @@ var BridgeAgent = class _BridgeAgent {
   }
   sendDeps() {
     return {
-      ready: () => ensureSodiumReady(),
+      ready: () => ensureSodiumReady2(),
       uploadBlob: (ciphertext, channelId) => this.uploadBlobImpl(ciphertext, channelId),
       encryptFile,
       bytesToBase64: bytesToBase642,
@@ -6403,7 +6420,7 @@ var BridgeAgent = class _BridgeAgent {
   }
   receiveDeps() {
     return {
-      ready: () => ensureSodiumReady(),
+      ready: () => ensureSodiumReady2(),
       downloadBlob: this.downloadBlobImpl,
       decryptFile,
       computeFileDigest,
@@ -8034,7 +8051,7 @@ export {
   attachAgentWebSocket,
   capabilities,
   createHttpServer,
-  ensureSodiumReady,
+  ensureSodiumReady2 as ensureSodiumReady,
   errorBody,
   httpStatus,
   isLoopback,

package/dist/sodium-ready.d.ts

@@ -1,43 +1,73 @@
 /**
  * Warm libsodium once per process, before any file-crypto call.
  *
- * ⛔ THE DISCARDED KEYPAIR IS THE READINESS GATE, NOT DEAD CODE. Do not
- * delete it. `@agentvault/crypto` has no readiness contract on its entire
- * synchronous surface: sixteen exported synchronous functions throw when
- * libsodium's WASM heap is not yet initialised, with either
+ * ⛔⛔ THIS IS A DELEGATE, AND THE DELEGATION IS THE POINT. #331 moved the
+ * warm-up body and its memo to `packages/connect-sdk-ts/src/sodium-ready.ts`.
+ * A process that holds TWO independent readiness memos warms libsodium twice,
+ * and this bridge process holds one instance of the SDK module already. Keeping
+ * a second memo here would have made the two barriers count separately.
+ * ⛔ DO NOT restore a local memo, a local `generateEphemeralKeypair()` call, or
+ * a local `warming` variable. `src/sodium-ready.delegation.gate.test.ts` (G-E)
+ * counts the underlying warm-ups across BOTH barriers and reads 2 the moment
+ * one comes back.
+ *
+ * ⛔ THE NAME AND THE EXPORT STAY. `bridge-agent.ts:64` imports this symbol and
+ * `index.ts:7` re-exports it. Callers keep calling `ensureSodiumReady()` from
+ * this package; only where the body lives changed.
+ *
+ * The four findings this file carried before #331, and where each one now
+ * lives. None is deleted, because each still binds on something.
+ *
+ * ⛔ 1. THE DISCARDED KEYPAIR IS THE READINESS GATE, NOT DEAD CODE. ⇒ ITS
+ * SUBJECT MOVED. The `generateEphemeralKeypair()` await now sits in the SDK
+ * module named above, and the finding travels with it. It still says what it
+ * always said: `@agentvault/crypto` has no readiness contract on its
+ * synchronous surface. ⛔ THE COUNT IS A WITNESSED SET, NOT A BARE NUMBER, and
+ * the earlier "sixteen" was not one — see the SDK module for the cold/warm
+ * differential that produced it and for the named nine. Cold-throwers fail with
  * `<member> is not a function` or
- * `Cannot read properties of undefined (reading '_malloc')`.
- * `generateEphemeralKeypair` is an ASYNC export that awaits `sodium.ready`
- * internally, on the SAME module instance the synchronous exports use, so
- * awaiting it is what makes those exports safe to call afterwards. The X25519
- * keypair it returns is minted and thrown away: it is never stored, never
- * published, and never used for anything.
+ * `Cannot read properties of undefined (reading '_malloc')`, and
+ * `generateEphemeralKeypair` is the ASYNC export that awaits `sodium.ready`
+ * internally on the SAME module instance those synchronous exports use. ⛔ Do
+ * not "simplify" the delegate by inlining a keypair mint back here: that is a
+ * second warm-up, not a shortcut.
  *
- * ⛔ DO NOT IMPORT `libsodium-wrappers-sumo` DIRECTLY HERE. That specifier is
- * absent from esbuild.config.mjs's EXTERNAL list, so esbuild would bundle a
- * SECOND libsodium instance. The await would then warm a heap that nothing
- * reads, and this fix would look correct and do nothing.
+ * ⛔ 2. DO NOT IMPORT `libsodium-wrappers-sumo` DIRECTLY HERE. ⇒ THIS ONE STILL
+ * BINDS ON THIS FILE, UNCHANGED. `esbuild.config.mjs:15` inlines every
+ * `@agentvault/connect-*` workspace package into the bridge bundle and that
+ * specifier is absent from the EXTERNAL list at `:3-8`, so esbuild would bundle
+ * a SECOND libsodium instance out of this file. The await would then warm a
+ * heap that nothing reads, and this fix would look correct and do nothing.
+ * ⚠️ The same inlining is why the delegate below is not a no-op in the shipped
+ * bundle: the SDK barrier is inlined into `dist/bin.js` exactly once, and this
+ * delegate points at that one copy.
  *
- * ⛔ MEMOIZE THE PROMISE, NOT A BOOLEAN. Measured: under
- * `if (warmed) return; await ...; warmed = true;` two CONCURRENT callers both
- * run the body. The bridge has two independent entry points (send and
- * receive), so that concurrency is real. The promise form runs the body once.
+ * ⛔ 3. MEMOIZE THE PROMISE, NOT A BOOLEAN. ⇒ ITS SUBJECT MOVED. The memo is the
+ * SDK module's `warming`. Measured: under `if (warmed) return; await ...;
+ * warmed = true;` two CONCURRENT callers both run the body. The bridge has two
+ * independent entry points (send and receive), so that concurrency is real
+ * here, which is why the finding was written here first. It is pinned now by
+ * the G-C1 case in `packages/connect-sdk-ts/src/sodium-ready.memo.gate.test.ts`,
+ * which is the CONCURRENT form of the property, and by
+ * `src/sodium-ready.retry.test.ts:52-69` in this package, which is the SEQUENTIAL
+ * form and reaches the SDK memo THROUGH this delegate.
+ * ⛔ G-C1 GATES THIS FINDING ONLY. It cannot fail on finding 4's memo-clearing
+ * `catch`, because its mock always resolves. Finding 4 names its own pins.
  *
- * ⛔⛔ THE `catch` THAT CLEARS THE MEMO IS NOT REDUNDANT. DO NOT DELETE IT.
- * Caching the promise fixes the double-warm race, but a bare
- * `warming ??= ...` introduces a failure mode the boolean form did NOT have:
- * if the FIRST warm-up REJECTS (WASM instantiation failure, OOM, a corrupt
- * binary), `warming` holds a REJECTED promise for the life of the process, and
- * every later prepareAttachment AND materializeAttachment then rejects at its
- * first statement, forever. ⛔ ON THE RECEIVE SIDE THAT IS SILENT: the ingest
- * pump's fail-soft catch acks the message, increments the failed-attachment
- * counter and logs, so one transient failure becomes a PERMANENT,
- * PROCESS-WIDE attachment outage that never surfaces as a crash. The boolean
- * form would have retried. Clearing the memo on rejection restores that retry
- * while keeping the single-warm guarantee on the success path.
- * ⛔ It RETHROWS: the first caller must still see the real failure. This is
- * not a swallow-and-proceed, which is the exact shape that caused the
- * production incident this whole finding catalogues.
- * Pinned by src/sodium-ready.retry.test.ts, both halves.
+ * ⛔⛔ 4. THE `catch` THAT CLEARS THE MEMO IS NOT REDUNDANT. DO NOT DELETE IT.
+ * ⇒ ITS SUBJECT MOVED, AND THE CONSEQUENCE STILL LANDS IN THIS PACKAGE. A bare
+ * `warming ??= ...` in the SDK module would hold a REJECTED promise for the
+ * life of the process if the FIRST warm-up rejects (WASM instantiation failure,
+ * OOM, a corrupt binary), and every later prepareAttachment AND
+ * materializeAttachment IN THIS PACKAGE would then reject at its first
+ * statement, forever. ⛔ ON THE RECEIVE SIDE THAT IS SILENT: the ingest pump's
+ * fail-soft catch acks the message, increments the failed-attachment counter
+ * and logs, so one transient failure becomes a PERMANENT, PROCESS-WIDE
+ * attachment outage that never surfaces as a crash. The SDK module clears the
+ * memo on rejection and RETHROWS, so the first caller still sees the real
+ * failure. Pinned by `src/sodium-ready.retry.test.ts` in this package, both
+ * halves, and by the G-C1b case in
+ * `packages/connect-sdk-ts/src/sodium-ready.memo.gate.test.ts`. ⛔ NOT by G-C1,
+ * which cannot fail on that `catch` — see finding 3 above.
  */
 export declare function ensureSodiumReady(): Promise<void>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securecoms/agent-bridge",
-  "version": "0.11.1",
+  "version": "0.11.3",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -23,6 +23,7 @@
   },
   "scripts": {
     "prepack": "npm run build",
+    "prepublishOnly": "bash scripts/pack-smoke.sh",
     "build": "tsc && node esbuild.config.mjs",
     "test": "vitest run",
     "test:watch": "vitest"