@byok-sdk/client 0.1.0 → 0.1.1

package/dist/adapters/pi/resolve-bin.d.ts

@@ -6,39 +6,29 @@
  * is NOT the coding agent. On npm it resolves to an unrelated "CLI tool for
  * managing vLLM deployments on GPU pods" (bin: `pi-pods`). The real coding
  * agent was `@mariozechner/pi-coding-agent`, which is now itself deprecated
- * in favor of this package (same maintainers: badlogic, mitsuhiko), as of
- * literally the day before this was written. `package.json` pins the
- * `legacy-node20` dist-tag (0.74.2) rather than `latest` (0.80.7), because
- * `latest` requires Node >=22.19 while this SDK's baseline is Node >=20;
- * both versions were empirically confirmed to speak the identical RPC-mode
- * frame shapes this adapter depends on.
+ * in favor of this package (same maintainers: badlogic, mitsuhiko).
+ *
+ * This constant identifies the user-installed runtime for diagnostics and
+ * documentation only. The client package deliberately does not install pi:
+ * security-fixed pi releases require Node >=22.19 while this SDK supports
+ * Node >=20, and runtime credentials/lifecycle remain user-owned.
  */
 export declare const PI_PACKAGE_NAME = "@earendil-works/pi-coding-agent";
 export interface ResolvedBin {
     command: string;
-    source: 'package' | 'path';
+    source: 'path';
 }
 /**
- * Resolve the pi CLI executable. Prefers the optionalDependency installed
- * alongside @byok-sdk/client (guarantees a known-good, version-matched build);
- * falls back to whatever `pi` is on PATH so users with a pre-existing global
- * pi install still work even when the optionalDependency didn't install.
+ * Resolve the user-installed pi CLI executable.
  *
- * `BYOK_PI_BIN` overrides both of the above when set: `PiAdapterOptions.resolveBin`
+ * `BYOK_PI_BIN` overrides PATH lookup when set: `PiAdapterOptions.resolveBin`
  * is the injectable seam for in-process tests, but the `byok-agent` CLI bin
  * only ever constructs `new PiAdapter()` with no options (see `createDaemon`),
  * so an out-of-process substitution (e.g. examples/basic's e2e run swapping
  * in the fake-pi fixture ahead of a real pi install) has no other seam to use.
  *
- * Deliberately does NOT use `createRequire(...).resolve()`: this package is
- * pure ESM with no `require` export condition (`exports["."]` only offers
- * `import`), so CJS-style resolution fails outright with
- * `ERR_PACKAGE_PATH_NOT_EXPORTED` — empirically confirmed, not a hypothetical.
- * It also does NOT resolve the `./package.json` subpath directly (also not
- * exported by this package); instead it resolves the package's main entry
- * via `import.meta.resolve` and walks up parent directories to find the
- * package root (identified by a `package.json` whose `name` matches), which
- * is robust to `dist/` layout changes and to whether `./package.json` is
- * ever exported.
+ * Resolution is deliberately the same authority shape as Claude Code and
+ * Codex: an explicit product/test override, otherwise the user's PATH. The
+ * SDK does not infer package-manager layouts or install a second runtime.
  */
 export declare function resolvePiBin(): ResolvedBin;