@coreplane/switchboard 1.224.0 → 1.226.0

package/dist/assets/config/config.example.yaml

@@ -24,7 +24,10 @@ providers:
   # vendor, so a model is named openrouter/anthropic/claude-sonnet-4 (the first
   # slash separates the provider; the rest is passed through). The compatible
   # adapter sends no effort tier, turns document inputs into a text note and
-  # asks for no provider-side prompt caching.
+  # asks for no provider-side prompt caching. The request router and memory
+  # reflection reach it through pi's model library instead (the same block,
+  # the same key), which applies its own OpenRouter rules there, prompt-cache
+  # markers included.
   # openrouter:
   #   type: openai-compatible
   #   baseUrl: https://openrouter.ai/api/v1
@@ -369,6 +372,7 @@ workspaceDir: ./workspaces
 # Spend reporting: GET /costs (Access-gated). Optional. See docs/reference/specs/costs.md.
 # costs:
 #   cloudflareAccountId: <32-hex account id>
+#   cloudflareAccountName: acme-infra              # optional: how the page names the account beside its share (else the id's first hex)
 #   cloudflareTokenEnv: CF_ANALYTICS_TOKEN     # token with Account Analytics:Read
 #   anthropicAdminKeyEnv: ANTHROPIC_ADMIN_KEY  # optional: sk-ant-admin… for LLM spend
 #   groups:

package/dist/assets/deploy/cloudflare-resident/Dockerfile

@@ -1,6 +1,7 @@
 # Resident container image: the @cloudflare/sandbox base (Ubuntu 22.04; already
-# ships git, curl, jq, npm, bun, cloudflared and a Node 22 this image replaces
-# with Node 24 below) plus GitHub tooling and a pool of unprivileged users.
+# ships git, curl, jq, npm, cloudflared, and a Node 22 and a bun this image
+# replaces with pinned ones below) plus GitHub tooling and a pool of
+# unprivileged users.
 
 # The Node this image ships (copied in below), at the exact tag every image in
 # this repository shares — its major is .nvmrc's, which is what CI runs and
@@ -64,14 +65,14 @@ RUN node --version | grep -qx 'v24.21.0' \
   && npm --version >/dev/null \
   && npx --version >/dev/null
 
-# pnpm + yarn: the base ships npm + bun but neither pnpm nor yarn, so a
-# repo whose onboard table is detected as pnpm or yarn (resident-repos item 52 —
-# every manager `detectCommands` can emit must exist here, or the table fails
-# deterministically at provision) couldn't be provisioned (install → build).
-# corepack is NOT on this base's PATH (unlike the older sandbox base), so both
-# come from npm at build time. yarn here is classic (1.x); a Yarn Berry repo
-# bootstraps through it via the `yarnPath` release it commits under
-# `.yarn/releases`.
+# pnpm + yarn + bun: the base ships npm and a bun of its own, but neither pnpm
+# nor yarn, so a repo whose onboard table is detected as pnpm or yarn
+# (resident-repos item 52 — every manager `detectCommands` can emit must exist
+# here, or the table fails deterministically at provision) couldn't be
+# provisioned (install → build). corepack is NOT on this base's PATH (unlike
+# the older sandbox base), so all three come from npm at build time. yarn here
+# is classic (1.x); a Yarn Berry repo bootstraps through it via the `yarnPath`
+# release it commits under `.yarn/releases`.
 #
 # EXACT versions, enforced by src/deploy/imagePins.test.ts. This line once read
 # `pnpm@latest yarn@latest`, which made the pnpm major a property of the last
@@ -87,9 +88,38 @@ RUN node --version | grep -qx 'v24.21.0' \
 # pinning pnpm@10.10.0 gets exactly that), so provisioning needs the registry,
 # not just the image. The grep asserts the pin took, so a resolution surprise
 # fails the build instead of a provision.
-RUN npm install -g pnpm@10.34.5 yarn@1.22.22 \
+#
+# bun is the opposite case, which is why it is pinned here instead of taken
+# from the base: bun does NOT self-manage `packageManager`, so the version
+# baked here IS the one a repo's `bun install` runs, whatever the repo pins.
+# The base ships bun as a real binary at /usr/local/bin/bun on the 1.3 line,
+# and 1.3.x rejects a `bun.lock` at lockfileVersion 3 as "Unknown lockfile
+# version" (bun 1.4 stamps v3 when `overrides` carry scoped `name@range`
+# rules) — so a repo pinning `bun@1.4.2` with such a lockfile failed
+# `deps-install` at EVERY attach (`bun install v1.3.14 … "lockfileVersion":
+# 3`) and every run on it fell to a cold sandbox. For bun the pin is a ceiling
+# as well as a floor: it must be at or above what any onboarded repo pins, and
+# it moves by a commit here, never by a base bump. The base's binary is
+# removed first: npm will not write its `bun` link over a file it does not
+# own, and a leftover would be a second bun to find. It has to be THIS
+# directory: a thread's commands run through `su`, whose PATH is
+# /etc/environment's (pam_env), not this file's ENV — /usr/local/bin is on it,
+# a prefix of our own would not be. The container server
+# (/container-server/sandbox) is a standalone bun-compiled executable and does
+# not run through this binary. The npm `bun` package is a placeholder until
+# its postinstall runs: that script moves the linux-x64 binary out of the
+# platform optional dependency into the package's own `bin` (no second copy),
+# and npm's global installs are growing an allowlist for install scripts
+# (`allow-scripts`; 11.19 warns about every script outside it), so the one
+# script this layer depends on is allowed by name. The grep proves the bun on
+# PATH is the pin, and the proof runs again as worker1 below. The npm cache
+# (bun's tarball is large) is dropped in the same layer.
+RUN rm -f /usr/local/bin/bun \
+  && npm install -g --allow-scripts=bun pnpm@10.34.5 yarn@1.22.22 bun@1.4.2 \
+  && npm cache clean --force \
   && pnpm --version | grep -qx '10\.34\.5' \
-  && yarn --version | grep -qx '1\.22\.22'
+  && yarn --version | grep -qx '1\.22\.22' \
+  && bun --version | grep -qx '1\.4\.2'
 
 # squashfs-tools (`unsquashfs`): the SDK's presigned restore does not extract
 # an archive, it MOUNTS it (squashfuse + fuse-overlayfs at the handle's dir)
@@ -199,3 +229,8 @@ RUN su -s /bin/bash worker1 -c "playwright screenshot --viewport-size=640,480 'd
 # and pi answers without a writable home (its config directory is the run's
 # own, named by PI_CODING_AGENT_DIR at start).
 RUN su -s /bin/bash worker1 -c "pi --version | grep -qx '0.85.1'"
+
+# bun once more, as worker1: a thread's `bun install` runs as the thread's user
+# through the same `su`, whose PATH is /etc/environment's rather than this
+# file's — so the BUILD proves that PATH resolves the pin, not the base's bun.
+RUN su -s /bin/bash worker1 -c "bun --version | grep -qx '1\.4\.2'"

package/dist/assets/deploy/cloudflare-sandbox/Dockerfile

@@ -1,7 +1,7 @@
 # Sandbox container image: the @cloudflare/sandbox base plus git + gh, a Docker
-# engine, Node 24 with pnpm, and the toolchain a run builds and looks with
-# (compilers, ffmpeg, a headless Chromium), so the coding/review/explore
-# agents work out of the box.
+# engine, Node 24 with pnpm and a pinned bun, and the toolchain a run builds
+# and looks with (compilers, ffmpeg, a headless Chromium), so the
+# coding/review/explore agents work out of the box.
 
 # The Node this image ships (copied in below), at the exact tag every image in
 # this repository shares — its major is .nvmrc's, which is what CI runs and
@@ -76,7 +76,7 @@ RUN node --version | grep -qx 'v24.21.0' \
   && npm --version >/dev/null \
   && npx --version >/dev/null
 
-# pnpm: the base image ships Node + npm (corepack is under
+# pnpm + bun: the base image ships Node + npm (corepack is under
 # /usr/local/lib/node_modules but not on PATH) and not pnpm, so coding runs in pnpm repos hit
 # `pnpm: command not found` on install/build. Installed globally with npm, the
 # same way the resident image does it, so this version is here before any run
@@ -84,13 +84,32 @@ RUN node --version | grep -qx 'v24.21.0' \
 # repo's own `packageManager` field and fetches it, so a pnpm repo that pins
 # one still needs the registry on its first install.
 #
-# EXACT version, enforced by src/deploy/imagePins.test.ts, same pin and same
-# reason as the resident image (deploy/cloudflare-resident/Dockerfile): with
+# EXACT versions, enforced by src/deploy/imagePins.test.ts, same pins and same
+# reasons as the resident image (deploy/cloudflare-resident/Dockerfile): with
 # `@latest` here the pnpm major moved on a rebuild, and pnpm 11 stopped
 # reading `package.json`'s `pnpm` field. pnpm still honours a repo's own
-# `packageManager`, so this is the floor for repos that name none.
-RUN npm install -g pnpm@10.34.5 \
-  && pnpm --version | grep -qx '10\.34\.5'
+# `packageManager`, so this is the floor for repos that name none. bun does
+# NOT honour it: the version baked here is the one a repo's `bun install`
+# runs, and the base's own bun — a real binary at /usr/local/bin/bun, 1.3.12
+# on this base, measured — rejects a `bun.lock` at lockfileVersion 3 as
+# "Unknown lockfile version" (bun 1.4 stamps v3 when `overrides` carry scoped
+# `name@range` rules), so a coding run in such a repo fails its install
+# exactly as the resident's attach did. The pin must therefore sit at
+# or above what any repo we run pins, and it moves by a commit, not a base
+# bump. The base's binary is removed first (npm will not write its `bun` link
+# over a file it does not own; the container server at
+# /container-server/sandbox is a standalone bun-compiled executable and does
+# not run through it), bun's postinstall is allowed by name (the npm package
+# is a placeholder until that script moves the real binary in from the
+# platform optional dependency, and npm's global installs are growing an
+# `allow-scripts` allowlist for install scripts), the grep proves the bun on
+# PATH is the pin, and the npm cache (bun's tarball is large) is dropped in
+# the same layer.
+RUN rm -f /usr/local/bin/bun \
+  && npm install -g --allow-scripts=bun pnpm@10.34.5 bun@1.4.2 \
+  && npm cache clean --force \
+  && pnpm --version | grep -qx '10\.34\.5' \
+  && bun --version | grep -qx '1\.4\.2'
 
 # The toolchain for what a run BUILDS and LOOKS AT — the same layer as the
 # resident image's (deploy/cloudflare-resident/Dockerfile);