@threadbase-sh/streamer 1.58.0 → 1.58.2

package/dist/index.d.cts

@@ -1788,6 +1788,21 @@ declare class LiveSessionManager {
     listSessions(): ManagedSession[];
     dispose(): void;
     private runnerFor;
+    /**
+     * Refuse before spawning when the provider's CLI is not on this machine.
+     *
+     * Without this the spawn "succeeds": on POSIX execvp fails inside the forked
+     * child, so a session appears, exits ~12ms later with code 1 and no output,
+     * and the caller is told only that it "exited before becoming ready" — or,
+     * on the Claude resume path, is told nothing at all, since that path answers
+     * 200 before the process has had a chance to die. Every start route funnels
+     * through here, so one check covers start, resume, adopt and fork.
+     *
+     * 503, not 500: the request was well-formed and the fault is this machine's
+     * environment. `code` is what mobile branches on (it reads `errBody.code`),
+     * and `PROVIDER_NOT_INSTALLED` is a remediation string it already knows.
+     */
+    private assertProviderInstalled;
     private assertSupportedProvider;
     private activeRunners;
 }
@@ -2381,6 +2396,30 @@ declare class StreamerServer {
     private finishWarmup;
     private withWarmup;
     private rejectIfWarmingUp;
+    /**
+     * Say which provider CLIs this machine can actually launch.
+     *
+     * The operator cannot discover this case unaided: under launchd/Task
+     * Scheduler the service inherits a stripped PATH, so a CLI that works
+     * perfectly in their terminal is invisible to the service, and every session
+     * start dies milliseconds in. `/api/diagnostics` answers it too, but only for
+     * someone who already suspects it.
+     *
+     * Availability only, never a version — `--version` costs a process spawn per
+     * provider (85ms for claude here) and belongs on the first request that wants
+     * it, not on boot.
+     *
+     * Called AFTER the port is bound, which is not cosmetic. This is the first
+     * caller of the exe resolvers in the process, so the memo is cold by
+     * definition and each provider pays one synchronous `which` / `where.exe`
+     * (platform.ts) with a 3s timeout. On POSIX that is 3ms found, 7ms missing.
+     * Windows is the risk — `where.exe` is slower, `execFileSync` blocks the
+     * event loop, and Task Scheduler's stripped PATH is exactly where a miss
+     * pays the full timeout — so the worst case is ~6s of two blocking lookups.
+     * After `listen()` that delays the first requests on a box that cannot start
+     * a session anyway; before it, it would have delayed binding the port.
+     */
+    private logProviderAvailability;
     listen(port: number, opts?: {
         awaitReady?: boolean;
     }): Promise<void>;

package/dist/index.d.ts

@@ -1788,6 +1788,21 @@ declare class LiveSessionManager {
     listSessions(): ManagedSession[];
     dispose(): void;
     private runnerFor;
+    /**
+     * Refuse before spawning when the provider's CLI is not on this machine.
+     *
+     * Without this the spawn "succeeds": on POSIX execvp fails inside the forked
+     * child, so a session appears, exits ~12ms later with code 1 and no output,
+     * and the caller is told only that it "exited before becoming ready" — or,
+     * on the Claude resume path, is told nothing at all, since that path answers
+     * 200 before the process has had a chance to die. Every start route funnels
+     * through here, so one check covers start, resume, adopt and fork.
+     *
+     * 503, not 500: the request was well-formed and the fault is this machine's
+     * environment. `code` is what mobile branches on (it reads `errBody.code`),
+     * and `PROVIDER_NOT_INSTALLED` is a remediation string it already knows.
+     */
+    private assertProviderInstalled;
     private assertSupportedProvider;
     private activeRunners;
 }
@@ -2381,6 +2396,30 @@ declare class StreamerServer {
     private finishWarmup;
     private withWarmup;
     private rejectIfWarmingUp;
+    /**
+     * Say which provider CLIs this machine can actually launch.
+     *
+     * The operator cannot discover this case unaided: under launchd/Task
+     * Scheduler the service inherits a stripped PATH, so a CLI that works
+     * perfectly in their terminal is invisible to the service, and every session
+     * start dies milliseconds in. `/api/diagnostics` answers it too, but only for
+     * someone who already suspects it.
+     *
+     * Availability only, never a version — `--version` costs a process spawn per
+     * provider (85ms for claude here) and belongs on the first request that wants
+     * it, not on boot.
+     *
+     * Called AFTER the port is bound, which is not cosmetic. This is the first
+     * caller of the exe resolvers in the process, so the memo is cold by
+     * definition and each provider pays one synchronous `which` / `where.exe`
+     * (platform.ts) with a 3s timeout. On POSIX that is 3ms found, 7ms missing.
+     * Windows is the risk — `where.exe` is slower, `execFileSync` blocks the
+     * event loop, and Task Scheduler's stripped PATH is exactly where a miss
+     * pays the full timeout — so the worst case is ~6s of two blocking lookups.
+     * After `listen()` that delays the first requests on a box that cannot start
+     * a session anyway; before it, it would have delayed binding the port.
+     */
+    private logProviderAvailability;
     listen(port: number, opts?: {
         awaitReady?: boolean;
     }): Promise<void>;