@evandu/super-pi 0.1.95 → 0.1.97

package/bin/super-pi.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 import { execFile, spawn } from "node:child_process";
-import { existsSync } from "node:fs";
+import { existsSync, readFileSync } from "node:fs";
 import { mkdir, rm, writeFile } from "node:fs/promises";
 import { homedir } from "node:os";
 import { dirname, join, resolve } from "node:path";
@@ -15,6 +15,31 @@ const home = process.env.SUPER_PI_AUTOSTART_HOME ?? homedir();
 const envPort = Number(process.env.SUPER_PI_PORT ?? 3080);
 const defaultPort = Number.isInteger(envPort) && envPort > 0 ? envPort : 3080;
 
+/**
+ * This installation's own version.
+ *
+ * READ AT RUN TIME, not baked in, because there can be more than one Super Pi on a machine and the one
+ * that matters is the one that is RUNNING. The two usual places are the global npm install - which is
+ * what the `super_pi` command runs - and the Pi extension's own install - which is what the
+ * `/super_pi` slash command loads. They are separate installations on purpose (Super Pi must not
+ * require Pi to be installed first), so their versions can differ, and a person comparing the two needs
+ * to see which is which. A bare version number cannot say that; a version number AND a path can.
+ */
+function ownVersion() {
+  try {
+    const pkg = JSON.parse(readFileSync(join(root, "package.json"), "utf8"));
+    return { version: pkg.version ?? "unknown", location: root };
+  } catch {
+    return { version: "unknown", location: root };
+  }
+}
+
+/** The line that names what is running, so two installations can be told apart at a glance. */
+function runningBanner(url) {
+  const { version, location } = ownVersion();
+  return `Super Pi v${version} is running at ${url}\n  installed at ${location}`;
+}
+
 function options(args) {
   const value = { port: defaultPort, host: process.env.SUPER_PI_HOST ?? "0.0.0.0", browser: true };
   for (let i = 0; i < args.length; i += 1) {
@@ -57,12 +82,12 @@ const command = implicitStart ? "start" : raw?.toLowerCase();
 const args = implicitStart ? [raw, ...rest] : rest;
 try {
   if (command === "help" || command === "--help" || command === "-h") { usage(); process.exit(0); }
-  if (!command) { const value = options(args); await start(value); const url = `http://127.0.0.1:${value.port}`; if (value.browser) openBrowser(url); console.log(value.browser ? `Opened ${url}` : `Super Pi is running at ${url}`); process.exit(0); }
+  if (!command) { const value = options(args); await start(value); const url = `http://127.0.0.1:${value.port}`; if (value.browser) openBrowser(url); console.log(value.browser ? `Opened ${url}\n${runningBanner(url)}` : runningBanner(url)); process.exit(0); }
   if (command === "autostart" || command === "startup") { const action = args.shift()?.toLowerCase() ?? "status"; const value = options(args); if (action === "enable") await enable(value); else if (action === "disable") await disable(); else if (action === "status") await status(); else throw new Error("Autostart action must be enable, disable, or status."); process.exit(0); }
   if (!["start", "stop", "restart", "update"].includes(command)) throw new Error(`Unknown command: ${command}`);
   if (command === "update") { const npm = platform === "win32" ? "npm.cmd" : "npm"; const args = prefix ? ["install", "--prefix", prefix, "@evandu/super-pi"] : ["install", "-g", "@evandu/super-pi"]; const child = spawn(npm, args, { stdio: "inherit", shell: platform === "win32", env: process.env }); const code = await new Promise((resolve) => child.on("close", resolve)); if (code !== 0) process.exit(code ?? 1); }
   const value = options(args);
   if (command === "stop") { console.log(await running(value.port) ? (await stop(value.port) ? `Shutdown requested on port ${value.port}.` : "Shutdown request failed.") : `Super Pi is not running on port ${value.port}.`); process.exit(0); }
   if ((command === "restart" || command === "update") && await running(value.port)) { await stop(value.port); await new Promise((resolve) => setTimeout(resolve, 600)); }
-  await start(value); const url = `http://127.0.0.1:${value.port}`; if (value.browser) openBrowser(url); console.log(value.browser ? `Opened ${url}` : `Super Pi is running at ${url}`);
-} catch (error) { console.error(error instanceof Error ? error.message : String(error)); usage(); process.exit(1); }
+  await start(value); const url = `http://127.0.0.1:${value.port}`; if (value.browser) openBrowser(url); console.log(value.browser ? `Opened ${url}\n${runningBanner(url)}` : runningBanner(url));
+} catch (error) { console.error(error instanceof Error ? error.message : String(error)); usage(); process.exit(1); }

package/dist/client/.super-pi-client-sources.json

@@ -24,5 +24,5 @@
     "src/client/types.ts": "6487df00c164370550b5977f9b23b17e22aff4bfb59dfe1e52200042340e3769",
     "src/client/vite-env.d.ts": "65996936fbb042915f7b74a200fcdde7e410f32a669b1ab9597cfaa4b0faddb5"
   },
-  "recordedAt": "2026-10-20T13:28:21.946Z"
+  "recordedAt": "2026-10-20T17:20:14.918Z"
 }

package/dist/extension.js

@@ -83,14 +83,24 @@ export default function (pi) {
             if (!running) {
                 ctx.ui.notify?.("Starting Super Pi web server...", "info");
                 const serverScript = resolveServerScript();
-                // Identify current pi command to pass down to Super Pi
-                const piCommand = process.argv[1] || "pi";
+                // The Pi that is hosting Super Pi, passed down so that the ONE-SHOT work - the sub-agents,
+                // which spawn a Pi process - runs on the same Pi that is running this extension.
+                //
+                // IT IS NOT `SUPER_PI_PI_COMMAND`, and that difference is load-bearing. That name means "the user
+                // named this Pi", and naming a Pi is what tells Super Pi to run CONVERSATIONS by spawning it
+                // rather than by using Pi's SDK - the SDK is a library, and it can only be the one that came with
+                // Super Pi. So a Pi named there cannot be a conversation's Pi, and a conversation that spawns a
+                // process for every turn is the slow architecture this all replaced.
+                //
+                // Setting it here therefore made every conversation started from inside Pi slow, with nothing
+                // saying why. The hosting Pi belongs to the one-shot paths, and this is where it is said.
+                const hostPi = process.argv[1] || "pi";
                 const child = spawn(process.execPath, [serverScript], {
                     detached: true,
                     stdio: "ignore",
                     env: {
                         ...process.env,
-                        SUPER_PI_PI_COMMAND: piCommand,
+                        SUPER_PI_HOST_PI: hostPi,
                         SUPER_PI_PORT: String(port),
                     },
                 });

package/dist/server/pi-command.js

@@ -126,6 +126,30 @@ export function resolvePiCommand(options = {}) {
             searched: [...onPath, ...globalDirs],
         };
     }
+    // THE PI THAT IS HOSTING SUPER PI, when Super Pi was started from inside Pi itself.
+    //
+    // It is NOT the same thing as an explicitly named Pi, and the difference is the whole point:
+    // `SUPER_PI_PI_COMMAND` means "the USER named this Pi", and naming a Pi is what tells Super Pi to
+    // run CONVERSATIONS by spawning it - the SDK is a library, and it can only be the one that came with
+    // Super Pi. A conversation that spawns a process for every turn is the slow architecture this all
+    // replaced, so the hosting Pi must NOT set that flag.
+    //
+    // What the hosting Pi IS good for is the one-shot work: the sub-agents spawn a Pi process, and they
+    // should run on the same Pi that is hosting Super Pi. So it is preferred over the bundled copy here,
+    // without being a user override.
+    const hostPi = (env.SUPER_PI_HOST_PI ?? "").trim();
+    if (hostPi) {
+        if (/[\\/]/.test(hostPi)) {
+            const full = nativeEntry(hostPi, platform) ?? hostPi;
+            if (exists(full))
+                return { found: true, command: full, via: "the Pi that is hosting Super Pi", explicit: false };
+        }
+        else {
+            const hit = firstHit([hostPi], [...onPath, ...globalDirs], exists, platform);
+            if (hit)
+                return { found: true, command: hit.command, via: `the Pi that is hosting Super Pi (${hit.dir})`, explicit: false };
+        }
+    }
     // THE COPY OF PI THAT CAME WITH SUPER PI, and it comes FIRST among the automatic choices.
     //
     // Super Pi depends on Pi's package, so npm installs it and puts its `pi` executable in

package/dist/server/runtime.d.ts

@@ -515,6 +515,16 @@ export declare class PiRpcRuntime implements AgentRuntime {
     private warnedMissingExtension;
     /** Latches the "Pi's SDK is not installed" warning, for the same reason. */
     private warnedMissingSdk;
+    /**
+     * How a CONVERSATION runs: on a persistent SDK session, or by spawning a Pi for every turn.
+     *
+     *  is the slower one, and it exists for the test suite: those suites drive a fake Pi that
+     * speaks the RPC protocol over a pipe, and a program is not a library - the session path cannot run
+     * it. It is an explicit request rather than something inferred from which Pi happens to be named,
+     * because inferring it is what made the Pi extension start conversations on the slow path without
+     * saying why.
+     */
+    private readonly sessionMode;
     /**
      * Agent definitions are read from disk, never cached. A file is cheap to parse, and re-reading it
      * per turn is the whole point: editing an agent's prompt or tool allowlist changes the NEXT message
@@ -571,6 +581,7 @@ export declare class PiRpcRuntime implements AgentRuntime {
         toolsEndpoint?: string;
         uploadsDir?: string;
         sessionFactory?: PiSessionFactory;
+        sessionMode?: "sdk" | "oneshot";
     });
     /**
      * The configuration of the session that was built for a conversation, for tests to inspect.
@@ -598,6 +609,14 @@ export declare class PiRpcRuntime implements AgentRuntime {
         };
         thinkingLevel?: string;
     } | undefined;
+    /**
+     * Which path a CONVERSATION on this runtime takes.
+     *
+     * Exposed so a test can assert it. The bug this exists to prevent was invisible from the outside:
+     * the version number said 0.1.95 while every conversation was still spawning a process per turn,
+     * and nothing said why. A test that can ask "would a conversation here spawn a Pi?" can catch that.
+     */
+    get conversationPath(): "sdk" | "oneshot";
     /**
      * Whether the SDK-backed session layer can be used at all.
      *

package/dist/server/runtime.js

@@ -303,6 +303,16 @@ export class PiRpcRuntime {
     warnedMissingExtension = false;
     /** Latches the "Pi's SDK is not installed" warning, for the same reason. */
     warnedMissingSdk = false;
+    /**
+     * How a CONVERSATION runs: on a persistent SDK session, or by spawning a Pi for every turn.
+     *
+     *  is the slower one, and it exists for the test suite: those suites drive a fake Pi that
+     * speaks the RPC protocol over a pipe, and a program is not a library - the session path cannot run
+     * it. It is an explicit request rather than something inferred from which Pi happens to be named,
+     * because inferring it is what made the Pi extension start conversations on the slow path without
+     * saying why.
+     */
+    sessionMode;
     /**
      * Agent definitions are read from disk, never cached. A file is cheap to parse, and re-reading it
      * per turn is the whole point: editing an agent's prompt or tool allowlist changes the NEXT message
@@ -364,6 +374,8 @@ export class PiRpcRuntime {
         this.pi = resolvePiCommand({ command });
         if (!this.pi.found)
             console.warn(`PiRpcRuntime: ${this.pi.reason}`);
+        this.sessionMode = this.options.sessionMode
+            ?? (process.env.SUPER_PI_SESSION_MODE === "oneshot" ? "oneshot" : "sdk");
         this.sessionPool = new PiSessionPool(sessionDir, repositoryRootFrom(), undefined, (conversationId) => {
             // A session's credential dies with the session. The session is what HELD the token - its
             // extension read it out of the environment when it was loaded - so a session that is gone must
@@ -391,6 +403,16 @@ export class PiRpcRuntime {
     builtSessionConfig(conversationId) {
         return this.builtSessions.get(conversationId);
     }
+    /**
+     * Which path a CONVERSATION on this runtime takes.
+     *
+     * Exposed so a test can assert it. The bug this exists to prevent was invisible from the outside:
+     * the version number said 0.1.95 while every conversation was still spawning a process per turn,
+     * and nothing said why. A test that can ask "would a conversation here spawn a Pi?" can catch that.
+     */
+    get conversationPath() {
+        return this.sessionMode;
+    }
     /**
      * Whether the SDK-backed session layer can be used at all.
      *
@@ -919,18 +941,26 @@ export class PiRpcRuntime {
             yield* this.answerOneShot(input);
             return;
         }
-        // AN EXPLICITLY NAMED PI MEANS THE ONE-SHOT PATH, and this is a rule about the user's CONFIGURATION
-        // rather than about speed.
+        // WHICH PATH A CONVERSATION RUNS ON, and why it is NOT decided by which Pi was named.
+        //
+        // The session path does not use a Pi COMMAND at all: it imports Pi as a library, and the library it
+        // imports is the one installed next to Super Pi. A named command is a PROGRAM, and the session path
+        // cannot run a program as itself.
+        //
+        // So the two are different questions, and they are asked of different variables:
         //
-        // `SUPER_PI_PI_COMMAND` says "use THIS Pi". The session path does not use a Pi command at all: it
-        // imports Pi as a library, and the library it imports is the one installed next to Super Pi. So a
-        // server configured with an explicit command would silently ignore it - the user would point Super Pi
-        // at one Pi and get a different one, with nothing saying so.
+        // - `SUPER_PI_HOST_PI` - the Pi that is hosting Super Pi, set by the Pi extension. It steers the
+        //   ONE-SHOT work (the sub-agents spawn a Pi) and nothing else. It does NOT redirect conversations.
+        // - `SUPER_PI_SESSION_MODE=oneshot` - the explicit request to run conversations by spawning a Pi
+        //   instead of by using the SDK. It is slower, and it is here for the test suite, which drives a fake
+        //   Pi that speaks the RPC protocol - a program, not a library.
         //
-        // A named command is therefore honoured: the child process IS that command, and the one-shot path is
-        // the only path that can promise that. This also keeps the test suite's fake Pi meaningful, because
-        // a test that names a fake Pi is naming a program that speaks the RPC protocol, not a library.
-        if (this.pi.found && this.pi.explicit) {
+        // THE BUG THIS FIXES. The extension used to set `SUPER_PI_PI_COMMAND`, and an explicitly named Pi
+        // used to mean the one-shot path - so every conversation started from inside Pi spawned a process for
+        // every turn. That is the exact architecture this refactor replaced, and it was still running for
+        // anyone who started Super Pi the way most people do. The version number said 0.1.95; the speed said
+        // 0.1.84.
+        if (this.sessionMode === "oneshot") {
             yield* this.answerOneShot(input);
             return;
         }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.95",
+  "version": "0.1.97",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",
@@ -19,7 +19,8 @@
     "bin",
     "scripts/restart-server.mjs",
     "README.md",
-    "assets/knowledge-model"
+    "assets/knowledge-model",
+    "scripts/patch-brace-expansion.mjs"
   ],
   "engines": {
     "node": ">=22.19.0"
@@ -35,7 +36,8 @@
     "start": "node dist/server/index.js",
     "restart:server": "node scripts/restart-server.mjs",
     "smoke": "npm run build && node scripts/smoke.mjs",
-    "check": "node scripts/run-check.mjs"
+    "check": "node scripts/run-check.mjs",
+    "postinstall": "node scripts/patch-brace-expansion.mjs"
   },
   "check:logic": [
     "scripts/stream-checkpoint.test.mjs",

package/scripts/patch-brace-expansion.mjs

@@ -0,0 +1,179 @@
+// Repairs one vulnerable transitive dependency that Super Pi cannot fix from the outside.
+//
+// THE PROBLEM. Pi's package ships an `npm-shrinkwrap.json`, and a shrinkwrap pins a dependency's
+// whole subtree. Pi's shrinkwrap pins `brace-expansion@5.0.9`, and npm honours a shrinkwrap over
+// everything else - so neither `overrides` (in either the flat or the nested form) nor `npm audit fix`
+// can move it. `npm audit` therefore reports "1 high severity vulnerability" to every person who
+// installs Super Pi, and the finding is real: brace-expansion 5.0.9 is quadratic-time on `{a,b}` and
+// recurses without bound on nested brace groups, so a pattern that reaches it can burn the CPU or the
+// stack.
+//
+// THE REACHABILITY, so this is not a reflex. brace-expansion is reached through `minimatch`, and in
+// Pi's tree `minimatch` is used by the package manager - to match the paths of installed extensions
+// and skills. Those names come from files on disk, so a hostile workspace is enough to feed a pattern
+// in. It is a denial of service, not a privilege escalation, but it is reachable by opening a
+// repository, and a workspace is exactly what Super Pi is pointed at.
+//
+// THE FIX. `brace-expansion@5.0.12` is the patched release, and it has the same file layout as
+// 5.0.9 (both are `tshy` builds with the same `dist/commonjs` + `dist/esm` shape), so replacing the
+// installed copy is a file-level swap with no re-linking and no API change.
+//
+// WHY IT IS A POSTINSTALL AND NOT A DEPENDENCY. A dependency cannot express "a different version of
+// my dependency's dependency", because the shrinkwrap is the whole point of a shrinkwrap. The only
+// place left is the install itself.
+//
+// WHAT IT WILL NOT DO. It never fails an install. A patched copy that cannot be fetched leaves the
+// tree as it was, and the script says so in one line. An install that cannot finish because of a
+// security patch is a worse outcome than an install that finishes with a known advisory, so the script
+// only ever warns.
+import { existsSync, readFileSync, writeFileSync, mkdirSync, rmSync, renameSync, cpSync } from "node:fs";
+import { dirname, join, relative, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+import { execFileSync } from "node:child_process";
+import { tmpdir } from "node:os";
+
+/** The patched release. 5.0.9 is what Pi's shrinkwrap pins; 5.0.12 carries the fix. */
+const PATCHED_VERSION = "5.0.12";
+/** The first fixed version. Below this, the advisory applies. */
+const VULNERABLE_BELOW = "5.0.12";
+
+const here = dirname(fileURLToPath(import.meta.url));
+const repositoryRoot = resolve(here, "..");
+
+/** The lockfile-relative path of a directory, in the form a lockfile's keys take. */
+const lockKeyOf = (directory) => relative(repositoryRoot, directory).split(/[\\/]/).filter(Boolean).join("/");
+
+/** Where Pi's package keeps its own `brace-expansion`, if it keeps one. */
+function findVulnerableCopies() {
+  const found = [];
+  const candidates = [
+    join(repositoryRoot, "node_modules", "@earendil-works", "pi-coding-agent", "node_modules", "brace-expansion"),
+    join(repositoryRoot, "node_modules", "brace-expansion"),
+  ];
+  for (const directory of candidates) {
+    const manifest = join(directory, "package.json");
+    if (!existsSync(manifest)) continue;
+    let version = "";
+    try { version = JSON.parse(readFileSync(manifest, "utf8")).version ?? ""; } catch { continue; }
+    if (!version) continue;
+    if (compareVersions(version, VULNERABLE_BELOW) >= 0) continue;
+    found.push({ directory, version, lockKey: lockKeyOf(directory) });
+  }
+  return found;
+}
+
+/** Numeric version comparison that does not care about a leading `v` or a prerelease tag. */
+function compareVersions(a, b) {
+  const parts = (value) => String(value).replace(/^v/, "").split("-")[0].split(".").map((n) => Number.parseInt(n, 10) || 0);
+  const left = parts(a);
+  const right = parts(b);
+  for (let index = 0; index < Math.max(left.length, right.length); index += 1) {
+    const difference = (left[index] ?? 0) - (right[index] ?? 0);
+    if (difference !== 0) return difference < 0 ? -1 : 1;
+  }
+  return 0;
+}
+
+/**
+ * Replaces one installed copy with the patched release.
+ *
+ * The patched copy is fetched with `npm install` into a throwaway directory - npm's own
+ * fetch-and-verify path - rather than `npm pack` plus `tar`, which needs a `tar` on PATH whose flags
+ * differ between platforms. It is laid out exactly the way npm would have laid it out.
+ */
+function patch(directory) {
+  const scratch = join(tmpdir(), `super-pi-brace-${process.pid}-${Date.now()}`);
+  try {
+    mkdirSync(scratch, { recursive: true });
+    const stage = join(scratch, "stage");
+    mkdirSync(stage, { recursive: true });
+    writeFileSync(join(stage, "package.json"), JSON.stringify({ name: "super-pi-brace-stage", version: "0.0.0", private: true }));
+    execFileSync("npm", ["install", `brace-expansion@${PATCHED_VERSION}`, "--no-audit", "--no-fund", "--silent", "--omit=dev"], {
+      cwd: stage,
+      stdio: ["ignore", "ignore", "pipe"],
+      shell: process.platform === "win32",
+    });
+    const unpacked = join(stage, "node_modules", "brace-expansion");
+    if (!existsSync(join(unpacked, "package.json"))) throw new Error("the staged install produced no package");
+    // The old copy is moved aside rather than deleted first, so a failure mid-swap cannot leave the
+    // tree with half a package in it.
+    const previous = `${directory}.super-pi-backup`;
+    rmSync(previous, { recursive: true, force: true });
+    renameSync(directory, previous);
+    try {
+      cpSync(unpacked, directory, { recursive: true });
+    } catch (error) {
+      // The swap failed halfway: put the old copy back rather than leaving the tree broken.
+      rmSync(directory, { recursive: true, force: true });
+      renameSync(previous, directory);
+      throw error;
+    }
+    rmSync(previous, { recursive: true, force: true });
+    return true;
+  } finally {
+    rmSync(scratch, { recursive: true, force: true });
+  }
+}
+
+/**
+ * The integrity hash npm recorded for the patched version, so the lockfile still describes a tree npm
+ * can verify. It comes from the registry metadata npm itself trusts.
+ */
+function readIntegrity() {
+  try {
+    const output = execFileSync("npm", ["view", `brace-expansion@${PATCHED_VERSION}`, "dist.integrity", "--silent"], {
+      stdio: ["ignore", "pipe", "pipe"],
+      shell: process.platform === "win32",
+      encoding: "utf8",
+    });
+    return output.trim() || undefined;
+  } catch {
+    return undefined;
+  }
+}
+
+/**
+ * Rewrites the lockfile's entry for a patched package.
+ *
+ * WITHOUT THIS THE PATCH IS INVISIBLE. `npm audit` reads the LOCKFILE, not the files on disk - it
+ * compares the resolved versions against the advisory database. So a tree that is genuinely patched
+ * still reports "1 high severity vulnerability", and the person who installed Super Pi is left looking
+ * at a warning that no amount of reinstalling will clear.
+ */
+function updateLockfile(lockKey, version, integrity) {
+  const lockPath = join(repositoryRoot, "package-lock.json");
+  if (!existsSync(lockPath)) return false;
+  let lock;
+  try { lock = JSON.parse(readFileSync(lockPath, "utf8")); }
+  catch { return false; }
+  const entry = lock.packages?.[lockKey];
+  if (!entry || entry.version === version) return false;
+  entry.version = version;
+  if (integrity) entry.integrity = integrity;
+  if (entry.resolved) entry.resolved = entry.resolved.replace(/-\/[^/]*\.tgz$/, `-/brace-expansion-${version}.tgz`);
+  writeFileSync(lockPath, `${JSON.stringify(lock, null, 2)}\n`);
+  return true;
+}
+
+const copies = findVulnerableCopies();
+if (copies.length === 0) {
+  console.log("[super-pi] brace-expansion is not a vulnerable version here; nothing to patch.");
+} else {
+  let patched = 0;
+  for (const copy of copies) {
+    try {
+      if (!patch(copy.directory)) continue;
+      patched += 1;
+      console.log(`[super-pi] patched brace-expansion ${copy.version} -> ${PATCHED_VERSION} (${copy.directory})`);
+      // And the lockfile, so `npm audit` stops reporting a tree that is no longer vulnerable.
+      if (updateLockfile(copy.lockKey, PATCHED_VERSION, readIntegrity())) {
+        console.log("[super-pi] the lockfile now records the patched version, so `npm audit` stops reporting it.");
+      }
+    } catch (error) {
+      // NEVER fail the install over this. An install that cannot finish is worse than an install that
+      // finishes with a known advisory, and the advisory is reported by `npm audit` either way.
+      console.warn(`[super-pi] could not patch brace-expansion in ${copy.directory}: ${error instanceof Error ? error.message : String(error)}. Run \`npm audit fix\` or reinstall to try again.`);
+    }
+  }
+  if (patched === 0) console.warn("[super-pi] brace-expansion is still at a vulnerable version; `npm audit` will keep reporting it. This is Pi's own pinned dependency tree.");
+}