@byok-sdk/keys 0.5.0 → 0.6.0

package/dist/pi-provider-launcher-core.d.ts

@@ -1,9 +1,19 @@
+import { type ChildProcess } from 'node:child_process';
+import { type ImplementationSpawnBindingV1 } from '@byok-sdk/implementation-identity';
+import { type CommandRunner } from './command-runner';
+import { type PiLauncherRuntimeEntry } from './pi-provider-projection';
 import { type ExactProviderProfileBinding, type ModelProviderProfile, type ProviderProfileRef } from './provider-profile';
 import { type SecretStore } from './secret-store';
 export interface PiProviderLauncherOptions {
     piBin: string;
     /** Explicit script entry for the selected interpreter; never inferred from a filename. */
     piEntry?: string;
+    launchBinding?: ImplementationSpawnBindingV1;
+    piCwd?: string;
+    piFixedArgs?: readonly string[];
+    piConfigDigest?: string;
+    /** Which of this launcher's two child grammars applies; never defaulted. */
+    runtimeEntry: PiLauncherRuntimeEntry;
     profileDbPath: string;
     /** Carried by the `--provider` flag: the exact local profile to launch. */
     profileRef: ProviderProfileRef;
@@ -16,6 +26,23 @@ export interface PiProviderLauncherOptions {
     piArgs: string[];
 }
 export declare function parsePiProviderLauncherOptions(args: string[]): PiProviderLauncherOptions;
+/**
+ * What a profile must declare before it may parent a prepared host.
+ *
+ * Both refusals are about the prepared lane's own compile support set, not
+ * about custody: a prepared artifact is `openai-completions` bytes compiled by
+ * the device, and the host resolves a key for the projected provider before it
+ * will consume one. An `anthropic` adapter projects `anthropic-messages`, which
+ * the prepared compiler never emits, and `auth_mode: 'none'` projects a
+ * provider with no `apiKey` reference at all, so the host would refuse with
+ * `prepared_provider_credential_unavailable` AFTER a child had already been
+ * spawned. Refusing here means the admission (`--validate-only true`) answers
+ * the same question the launch would, before any process exists.
+ *
+ * Deliberately NOT a silent narrowing of the profile: nothing here rewrites the
+ * adapter or invents a credential.
+ */
+export declare function assertPiPreparedProviderProfile(profile: ModelProviderProfile): void;
 /**
  * Resolve only the credential the validated profile requires. In particular,
  * an auth-free local provider must remain usable on hosts without an OS
@@ -23,14 +50,35 @@ export declare function parsePiProviderLauncherOptions(args: string[]): PiProvid
  * dependency and turn an explicit `auth_mode: none` into a hidden fallback.
  */
 export declare function resolvePiProviderSecret(profile: ModelProviderProfile, createStore: () => SecretStore): Promise<string | undefined>;
-/** Build Pi's child environment from a closed platform baseline plus one exact key. */
+/** The inherited inventory is shared with admission; controlled values come only from the binding. */
 export declare function buildPiProviderChildEnvironment(options: {
     ambient: NodeJS.ProcessEnv;
-    projectionDir: string;
+    binding: ImplementationSpawnBindingV1;
     sessionDir: string;
     secret: string | undefined;
     platform?: NodeJS.Platform;
 }): Record<string, string>;
+/** Read-only Windows equivalent of uid + 0700; never repairs host ACLs. */
+export declare function assertWindowsPiProjectionAcl(directory: string, options?: {
+    systemRoot?: string;
+    run?: CommandRunner;
+}): Promise<void>;
+/** Validate the client-owned empty directory before any credential access. */
+export declare function assertPiProjectionDirectory(projectionDir: string, expectedDir: string): Promise<void>;
+export interface PiProviderLaunchDependencies {
+    ambient: NodeJS.ProcessEnv;
+    createSecretStore: () => SecretStore;
+    spawn?: (command: string, args: string[], options: {
+        cwd: string;
+        env: Record<string, string>;
+        stdio: 'inherit';
+    }) => ChildProcess;
+}
+/** Owns the credential-to-spawn sequence; the client retains directory ownership. */
+export declare function startPiProvider(profile: ModelProviderProfile, options: PiProviderLauncherOptions, dependencies: PiProviderLaunchDependencies): Promise<{
+    child: ChildProcess;
+    cleanup: () => Promise<void>;
+}>;
 /**
  * Create the configured session directory owner-only without mutating the
  * mode of an existing host-owned directory. The path is operator config, so

package/dist/pi-provider-projection.d.ts

@@ -1,5 +1,22 @@
 import type { ModelProviderProfile } from './provider-profile';
 export declare const PI_PROJECTED_KEY_ENV = "PI_PROVIDER_API_KEY";
+/**
+ * The runtime entries this launcher may parent, and the ONLY two.
+ *
+ * The entry is not a hint about which flags happen to be present: it selects
+ * which delegated-argv grammar below is applied, and the two grammars admit
+ * disjoint argument sets. A client that could omit it would be a client whose
+ * argv decides the grammar, so the flag is required at the parser rather than
+ * defaulted — a client/keys version skew then fails closed instead of
+ * silently launching a prepared host under the rpc grammar.
+ *
+ * `@byok-sdk/implementation-identity` declares four entries; the other two
+ * (`pi-subagent-print`, `pi-subagent-runner`) are descendants the launcher
+ * never parents, so restating the pair here is a narrowing, not a second
+ * vocabulary.
+ */
+export declare const PI_LAUNCHER_RUNTIME_ENTRIES: readonly ['pi-rpc', 'pi-prepared'];
+export type PiLauncherRuntimeEntry = (typeof PI_LAUNCHER_RUNTIME_ENTRIES)[number];
 /** Keep projected providers disjoint from Pi built-ins so composition can never fall back to one. */
 export declare function piProjectionProviderId(profileRef: string): string;
 /**
@@ -18,3 +35,17 @@ export declare function buildPiProviderProjection(profile: ModelProviderProfile)
  * the Pi child to the namespaced projection and exact configured model.
  */
 export declare function buildPiProviderArgs(profile: ModelProviderProfile, delegatedArgs: readonly string[]): string[];
+/**
+ * The whole delegated argv a prepared host may be launched with: one
+ * `--config <absolute path>` pair, and nothing else.
+ *
+ * Nothing is APPENDED either. The rpc grammar ends by binding the child to the
+ * projected provider, the configured model and the configured thinking level,
+ * because the rpc child composes its session from `models.json`. A prepared
+ * host composes nothing: the request it consumes was already compiled and the
+ * model it verifies against is the one the durable record pinned, so a
+ * `--provider`/`--model`/`--thinking` appended here would be a second, silent
+ * authority over a request that was already decided — and the host's own
+ * argument parser refuses anything but `--config` regardless.
+ */
+export declare function buildPiPreparedArgs(delegatedArgs: readonly string[]): string[];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@byok-sdk/keys",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "description": "BYOK SDK key management: provider profiles, credential-backed auth headers, and direct provider transports",
   "type": "module",
   "license": "MIT",
@@ -48,7 +48,8 @@
     "clean": "rm -rf dist"
   },
   "dependencies": {
-    "@byok-sdk/core": "0.18.0",
-    "zod": "^4.4.3"
+    "@byok-sdk/core": "0.19.0",
+    "zod": "^4.4.3",
+    "@byok-sdk/implementation-identity": "0.19.0"
   }
 }