chore: les paquets ng-org rattrapent le deploiement, et la lecture vive demarre

packages/polyfill/e2e/orm-live-entry.ts

@@ -250,19 +250,26 @@ async function seededTripleCount(doc: Nuri, subject: string): Promise<number> {
   /**
    * CHARACTERISATION of the deployed broker's `orm_start_graph` ARITY.
    *
-   * The failure the runner reports names a parameter — `config` — that the ORM does not
-   * send and that `nextgraph-rs` at the read commit does not declare. Two upstream
-   * arrangements could put one there, and they differ by POSITION:
+   * The failure the runner reports named a parameter - `config` - that the client of
+   * the day did not send. Two upstream arrangements could put one there, and they differ
+   * by POSITION:
    *   - config LAST, after the callback (upstream 2026-04-12 to 2026-04-21) — an
    *     unsupplied `config`, never a Function;
-   *   - config at index 4, BEFORE the callback — the 5-argument call from `@ng-org/orm`
-   *     then lands its callback exactly there, which is what the error describes.
+   *   - config at index 4, BEFORE the callback: the 5-argument call of the client of
+   *     the day then lands its callback exactly there, which is what the error described.
    *
-   * So this calls the SDK member directly with an empty config in position 4. It does not
-   * go through the ORM, which is fixed at five arguments — this is the one question the
-   * ORM cannot ask. The app-side proxy will mistake the `{}` for the stream callback, so
-   * nothing usable comes back; what is being read is only whether the engine still
-   * refuses on `config`.
+   * THE UPDATE ANSWERED THAT QUESTION. `@ng-org/web@0.1.2-alpha.14` declares six
+   * arguments with `config` at index 4 and routes the stream callback from index 5
+   * (`dist/ngweb.js`: `orm_start_graph: 5`), and `@ng-org/orm@0.1.2-alpha.21` sends six
+   * to match (`dist/connector/RdfOrmSubscription.js:159`). So the second arrangement was
+   * the right reading, and the ordinary `liveStart` path now exercises it.
+   *
+   * This is therefore kept as a FALLBACK, not as the live question: the runner only asks
+   * it when `liveStart` did not become ready, to say whether the engine still refuses on
+   * `config` when the client no longer can be blamed. It calls the SDK member directly
+   * rather than through the ORM. The app-side proxy takes index 5 as the stream callback,
+   * so the `{}` at index 4 is read as a config and nothing usable comes back; what is
+   * being read is only whether the start is refused.
    */
   async liveStartWithConfig() {
     const s = await sessionReady;
@@ -273,14 +280,12 @@ async function seededTripleCount(doc: Nuri, subject: string): Promise<number> {
       "store",
       undefined,
     )) as Nuri;
-    // Six arguments against a declaration that has five: the declaration describes the
-    // arity of the PUBLISHED client, and the arity of the DEPLOYED engine is the question.
-    // Widened through `unknown`, never `any` — the call is deliberate, not unchecked.
-    const startGraph = realNg.orm_start_graph as unknown as (
-      ...a: unknown[]
-    ) => Promise<unknown>;
+    // Called against the PUBLISHED declaration, which now has these six arguments, so the
+    // widening this used to need is gone: the arity is checked here rather than asserted.
+    // What remains unknowable at compile time is the DEPLOYED engine's arity, which is
+    // the question this asks.
     try {
-      await startGraph([doc], [], LIVE_SHAPE, s.session_id, {}, () => {});
+      await realNg.orm_start_graph([doc], [], LIVE_SHAPE, s.session_id, {}, () => {});
       return { doc, error: null };
     } catch (e) {
       return { doc, error: e instanceof Error ? e.message : String(e) };

packages/polyfill/e2e/orm-live-read.ts

@@ -261,9 +261,11 @@ async function main(): Promise<void> {
     }
     check(CHECKS[4]!, remaining === 0, `triples left for the seeded subject: ${remaining}`);
 
-    // Only worth asking when the five-argument call did NOT start: it is the diagnosis of
+    // Only worth asking when the published call did NOT start: it is the diagnosis of
     // that failure, and a deployment that answers the published arity has nothing to
-    // characterise.
+    // characterise. Since `@ng-org/web@0.1.2-alpha.14` the published call is itself the
+    // six-argument one, so this asks whether the engine refuses a start the client got
+    // right - no longer whether the client was sending the wrong number.
     if (readyMs === null) {
       const withConfig = await sdk<{ doc: string; error: string | null }>(
         frame,
@@ -273,12 +275,12 @@ async function main(): Promise<void> {
         CHECKS[5]!,
         withConfig.error === null
           ? "six arguments with `{}` in position 4 are ACCEPTED — the deployed " +
-              "`orm_start_graph` takes a `config` BEFORE the callback, so the published " +
-              "client's five-argument call puts its callback there"
+              "`orm_start_graph` takes a `config` BEFORE the callback, which is what the " +
+              "published client now sends, so the refusal is not an arity mismatch"
           : `six arguments were refused too: ${withConfig.error}`,
       );
     } else {
-      record(CHECKS[5]!, "not asked — the published five-argument call started");
+      record(CHECKS[5]!, "not asked — the published six-argument call started");
     }
   } finally {
     if (page) await closeQuietly("the ORM live-read page", () => page!.close());

packages/polyfill/e2e/tsconfig.json

@@ -2,10 +2,7 @@
   "extends": "../../../tsconfig.base.json",
   "compilerOptions": {
     "types": ["bun"],
-    "noEmit": true,
-    "paths": {
-      "@ng-org/web": ["../node_modules/@ng-org/web"]
-    }
+    "noEmit": true
   },
   "include": ["."]
 }