@securecoms/agent-bridge 0.11.2 → 0.11.3

package/dist/bin.js

@@ -2122,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)
@@ -4602,9 +4630,9 @@ var SqliteMlsStateStore = class {
    * ⛔ THE WRITE PATH GETS NO READINESS BARRIER, AND THAT IS DELIBERATE. Two
    * independent reasons, and the FIRST is the primary one.
    *
-   * 1. `:171` below populates `this.bundles` BEFORE the seal on the next line.
+   * 1. `:191` below populates `this.bundles` BEFORE the seal at `:192`.
    *    A same-process reload therefore hits the cache at `loadPendingBundle`'s
-   *    `:182-183` and NEVER decodes. The decode path is only ever taken for a
+   *    `: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

package/dist/index.js

@@ -2019,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)
@@ -4499,9 +4527,9 @@ var SqliteMlsStateStore = class {
    * ⛔ THE WRITE PATH GETS NO READINESS BARRIER, AND THAT IS DELIBERATE. Two
    * independent reasons, and the FIRST is the primary one.
    *
-   * 1. `:171` below populates `this.bundles` BEFORE the seal on the next line.
+   * 1. `:191` below populates `this.bundles` BEFORE the seal at `:192`.
    *    A same-process reload therefore hits the cache at `loadPendingBundle`'s
-   *    `:182-183` and NEVER decodes. The decode path is only ever taken for a
+   *    `: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

package/dist/sodium-ready.d.ts

@@ -21,10 +21,12 @@
  * ⛔ 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 entire
- * synchronous surface, sixteen exported synchronous functions throw when
- * libsodium's WASM heap is not yet initialised (`<member> is not a function`
- * or `Cannot read properties of undefined (reading '_malloc')`), and
+ * 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')`, 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
@@ -45,9 +47,12 @@
  * 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
- * `packages/connect-sdk-ts/src/sodium-ready.memo.gate.test.ts` (G-C1) and by
- * `src/sodium-ready.retry.test.ts:52-69` in this package, which reaches the SDK
- * memo THROUGH this delegate.
+ * 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.
  *
  * ⛔⛔ 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
@@ -60,6 +65,9 @@
  * 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`, both halves.
+ * 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.2",
+  "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"