pgh's memory describes the architecture as "ONE engine (pgh-runtime), TWO front-ends — the pgh CLI (via runtime-factory) and embedded createRuntime". The second front-end was not reachable: runtime-factory is not in the exports map, so `import { createRuntime } from 'pgh/runtime-factory'` fails from outside the package. Every other library-shaped module is exported; this one was missed. Verified from a clean external package under bare (node cannot load it — the dependency chain pulls bare-fs): runtime-factory: createRuntime, defaultRuntimePath, finalizeInstall, installComplete, resolveBundledRuntime, selectMaterializer resolve-release: resolveRelease, makeGetLatestRelease, registryStoreDir Worth recording while adding this: the two apps that DO embed an updater — atproto-bridge/pds/bin/pds-serve.js and ap-bridge/lib/control.js — both carry a comment saying they deliberately avoid pgh-runtime because it "only fetches ROOT trees, not dep closures". That was true before pgh-runtime 0.1.4 and has not been since; installRelease fetches the full closure plus per-host prebuilds. Two apps are hand-rolling a fetch path to route around a limitation that no longer exists. Not touched here — changing another app's update path is its own change with its own proof — but it is why this export matters beyond hyper-tps. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>