@bridge4dev/runner 0.45.1 → 0.46.1

package/dist/index.js

@@ -145,6 +145,14 @@ function runnerCapabilities(apiUrlOverride) {
         resumeEpoch: true,
         /** Session 8: understands `maxSessions` and runs sessions side by side. */
         parallelSessions: true,
+        /**
+         * 0.46.0: reports which sessions are actually holding a seat here, so the
+         * API stops having to guess the occupancy of this machine from its own
+         * rows. Announced rather than inferred from the version, because the API
+         * runs a compatibility sweep for runners that cannot say it — and that
+         * sweep must switch off the moment this one can.
+         */
+        sessionSlots: true,
         /**
          * Session 9: can update itself on command. Reported as a capability rather
          * than inferred from the version, because the dashboard must not offer a
@@ -234,6 +242,13 @@ function runnerCapabilities(apiUrlOverride) {
          * anything the previous version could not.
          */
         gitRefs: true,
+        /**
+         * 0.46.0: умеет выложить файл из рабочей копии в хранилище платформы
+         * (`fs_publish`). Без флага дашборд не рисует кнопку «Опубликовать», а
+         * объясняет, что раннер надо обновить — кнопка, чей фрейм старый раннер
+         * молча уронит, хуже отсутствующей кнопки.
+         */
+        filePublish: true,
         /**
          * Session 14: reads `.devbridge/project.json`. Announced even when
          * verification is switched off — «this machine will not run recipes» and

package/dist/protocol.d.ts

@@ -1485,6 +1485,45 @@ export type RunnerFrame = {
  | {
     type: 'verify_report';
     report: Record<string, unknown>;
+}
+/**
+ * How many seats this machine is REALLY holding, and which sessions hold them
+ * (runner 0.46.0).
+ *
+ * Until this frame existed the occupancy of a dev server had two independent
+ * answers — rows in the API's database, and entries in this process's map —
+ * and nothing but a reconnect ever compared them. Every path that ended a
+ * session on paper without releasing the entry silently burned a seat, and
+ * the first symptom was a user being refused a session the dashboard had just
+ * offered (31.08.2026).
+ *
+ * The ids, not only the count: a number tells the API that it disagrees, the
+ * ids tell it WHICH sessions to lay to rest. That turns `reconcile` from
+ * something that happens once per reconnect into something that happens
+ * whenever the two sides drift.
+ */
+ | {
+    type: 'session_slots';
+    /**
+     * Every session this runner still tracks, parked or not.
+     *
+     * This is the reconciliation list: «here is what I still know about».
+     * The API compares it with its own rows and lays to rest anything it has
+     * already buried.
+     */
+    sessionIds: string[];
+    /**
+     * The subset that a new session would actually have to wait for.
+     *
+     * Not the same question, and conflating them is a bug in both
+     * directions. `ensureCapacity` PARKS an idle session (REVIEW or
+     * WAITING_INPUT with no open question) to make room, so its seat is
+     * available on demand and must not be counted as taken. What is left —
+     * a mid-turn session, or one holding an unanswered question card — is
+     * what really refuses the next one.
+     */
+    blockingIds: string[];
+    maxSessions: number;
 } | {
     type: 'pong';
 };

package/dist/protocol.js

@@ -369,7 +369,7 @@ export const GatewayFrameSchema = z.discriminatedUnion('type', [
         // git_branches, update_from_base, git_push, git_refs, workspace_state,
         // recipe_state, verify_start, verify_status, verify_cancel,
         // preview_checkout, preview_stop, propose_commit_message, git_stage,
-        // git_unstage, git_discard, git_pull, git_merge_abort.
+        // git_unstage, git_discard, git_pull, git_merge_abort, fs_publish.
         name: z.string().min(1).max(64),
         workspaceId: z.string().optional(),
         sessionId: z.string().optional(),

package/dist/supervisor.d.ts

@@ -123,6 +123,9 @@ export declare class Supervisor {
     private readonly verify;
     private readonly verifyReports;
     constructor(ws: RunnerWsClient, opts: SupervisorOptions);
+    /** How often the seat report re-derives the truth. See the constructor. */
+    private static readonly SLOTS_REPORT_INTERVAL_MS;
+    private readonly slotsTimer;
     /**
      * Push every unacked verdict at the API.
      *
@@ -132,6 +135,38 @@ export declare class Supervisor {
      */
     private flushVerifyReports;
     get activeSessionIds(): string[];
+    /** The last set of seat-holders we told the API about, to send only changes. */
+    private lastPublishedSlots;
+    /**
+     * Tell the API which sessions are actually holding a seat here (0.46.0).
+     *
+     * The seat count is a property of THIS process, and until now the API could
+     * only guess it from its own rows. The guess was wrong whenever a session
+     * ended on paper without releasing its entry, and wrong in the direction that
+     * costs a person their session: the dashboard offers a seat, the create
+     * passes, this runner refuses, the session dies in fifty milliseconds.
+     *
+     * Called from `reportStatus` — the choke point every seat change already
+     * passes through — and from the interval in the constructor, which is the net
+     * under any path that forgets. Both are safe to call as often as they like:
+     * this compares what it is about to say against what it last said and returns
+     * without touching the socket when nothing moved.
+     *
+     * Two lists, because two different questions are being asked and answering
+     * both with one number is wrong in both directions:
+     *
+     *  - `sessionIds` — everything still tracked here, parked or not. This is the
+     *    reconciliation list, and it must be generous: a session the API has
+     *    buried needs laying to rest whatever state it is in on this side.
+     *  - `blockingIds` — what a new session would really have to wait for.
+     *    `ensureCapacity` parks an idle REVIEW or WAITING_INPUT session to make
+     *    room, so those seats are available on demand.
+     *
+     * Reporting the second as the first would have the API stop live REVIEW
+     * sessions; reporting the first as the second would call a machine full while
+     * it had room. Both were caught by the independent QA review of this change.
+     */
+    private publishSlots;
     private onFrame;
     private startSession;
     /**
@@ -570,7 +605,61 @@ export declare class Supervisor {
     private isMidTurn;
     /** The three live setters, in the order that lets an explicit pick win. */
     private applyLiveSettings;
+    /**
+     * Let go of a session the API says no longer exists, so its files can go.
+     *
+     * `purge_session` and `clean` used to refuse outright while ANY entry for the
+     * id was in the map. That reads as caution and behaves as a deadlock: the
+     * frame arrives precisely because the API has already deleted the row, so
+     * nothing will ever come along to release the entry, the worktree stays on
+     * disk, and the retry runs until the purge ages out of its window. On
+     * production one such tombstone was still failing two hours later, on a
+     * machine that was refusing new sessions for exactly the seat it held.
+     *
+     * The API is the authority on whether a session exists. If it says gone, the
+     * honest answer is to end it here too — the same teardown a reconnect
+     * performs for a session missing from `hello_ack` — and only then report that
+     * we could not finish, if the process really will not go.
+     *
+     * Returns true when nothing is holding the id any more.
+     */
+    private releaseForCleanup;
+    /**
+     * How long cleanup waits for a stopped agent process to actually be gone.
+     *
+     * Deliberately a small slice of the API's ten-second command budget: removing
+     * the worktree still has to happen after this, under the repository lock, and
+     * a purge that times out on the wire is reported as a failure even when it
+     * succeeded here. Three seconds is enough for an ordinary exit; anything
+     * slower is better answered honestly, so the drain comes back and finds the
+     * entry already gone.
+     */
+    private static readonly CLEANUP_RELEASE_MS;
     private stopSession;
+    /**
+     * The ONE way a session ends on this runner.
+     *
+     * A terminal status is two facts, not one: the API is told the session is
+     * over, AND this machine stops holding a seat for it. They used to be
+     * separate lines at eight call sites, and three of them wrote only the first
+     * — `settleTurnStatus`'s failed-turn branch, `forwardEvent`'s `case 'error'`
+     * and `runApiRetry`. Each left a `RunningSession` in the map with a live
+     * `session` handle and `stopRequested === false`, which is precisely what
+     * `liveSessionCount` counts. The seat was then held for a session the API had
+     * already buried, until the next reconnect — weeks, on a healthy runner.
+     *
+     * On production (31.08.2026) that arithmetic refused a fourth session on a
+     * machine whose database said one was running, and the dashboard had offered
+     * the seat a moment earlier. `launchCrashed` had the rule right all along
+     * («an entry left in the map would hold one of the runner's few slots»); it
+     * just could not be the only place that knew it.
+     *
+     * Deliberately NOT folded into `reportStatus`: that method is also how a
+     * session reaches REVIEW, WAITING_INPUT and RUNNING, and a teardown hidden
+     * inside it would be invisible at exactly the call sites that must not tear
+     * anything down. The name says what it does.
+     */
+    private finishSession;
     private reconcile;
     /**
      * Housekeeping for the journal directory. Safe to call any time: live