dsh-connect-workbuddy 5.4.0 → 5.5.0

package/lib/{host-heartbeat-D5FWM_8k.js → host-heartbeat-CVnH8S3J.js}

@@ -1784,6 +1784,16 @@ const GLOBAL_CONFIG_PATH = "/v3/config";
 * host- and identity-insensitive on the CN side (measured 2026-10-21 on all
 * three CN hosts, under both the CLI and the app user agent: byte-identical),
 * so it is asked as the chat channel's own identity.
+*
+* IT DOES NOT EXIST ON THE GLOBAL GATEWAY. Measured 2026-10-22: this exact POST
+* against `www.workbuddy.ai` answers 404 `Route Not Found` (as do the four
+* neighbouring spellings tried under both POST and GET), while the same
+* credential reads that gateway's `/v3/config` normally and finds no load field
+* on any model. {@link WorkBuddyUpstreamClient.fetchModelBusy} is therefore
+* expected to THROW for that region — `withBusyLevels` in `src/index.ts` catches
+* it and ships the roster without levels. Kept as-is rather than region-gated:
+* the day upstream adds it, this needs no change, and the cost today is one
+* 404 per refresh that never blocks anything.
 */
 const MODEL_BUSY_PATH = "/v2/chat/busy";
 /**
@@ -5956,7 +5966,7 @@ function generationOf(version) {
 //#endregion
 //#region src/version.ts
 /** The npm package version this build was produced from. */
-const WORKBUDDY_CONNECT_VERSION = "5.4.0";
+const WORKBUDDY_CONNECT_VERSION = "5.5.0";
 //#endregion
 //#region src/host-heartbeat.ts
 /**

package/lib/index.d.ts

@@ -792,6 +792,22 @@ interface WorkBuddyPromo {
  * `/v3/config`, this endpoint is not channel-sensitive, so the plugin asks it as
  * the CLI agent it already is on the chat path — no product identity needed.
  *
+ * THE GLOBAL GATEWAY DOES NOT HAVE IT (measured 2026-10-22, and the reason the
+ * README says "CN only"). `www.workbuddy.ai` answers that same POST with
+ * `404 {"error_msg":"404 Route Not Found"}`, and so do `/v3/chat/busy`,
+ * `/v2/models/busy`, `/v2/chat/model/busy` and `/v1/chat/busy` under both POST
+ * and GET — twelve path/method pairs, twelve 404s. The credential is fine: the
+ * SAME token reads that gateway's `/v3/config` (200, 28 models), and none of
+ * those models carries a field whose name mentions busy / load / queue / wait /
+ * level / pressure. So this is not a wrong path, a wrong identity or a
+ * permission problem — upstream never published the fact for that region. The
+ * probe therefore fails there on every refresh; it is caught (see
+ * `withBusyLevels` in `src/index.ts`), logged once, and the roster ships with
+ * no levels, which the card renders as no badge. Deliberately NOT "fixed" by
+ * inferring a level from latency or credits: a made-up load badge is worse than
+ * no badge, and the plugin's whole rule here is to never state a fact the
+ * upstream did not state.
+ *
  * THE LEVELS ARE THE APP'S OWN ENUM, and anything outside it is `unknown`:
  * `idle` / `normal` / `busy` / `congested` / `unavailable`. The app's own words
  * (from its `im-channels` bundle, `chatInput.modelSelector.busy.*`) are
@@ -1597,6 +1613,7 @@ interface CliBridgeSettings {
   allowUnattended?: boolean;
   maxReplyChars?: number;
   injectResult?: boolean;
+  sessionContinuity?: string;
   maxTurnsPerSessionHour?: number;
   maxTurnsPerHour?: number;
 }
@@ -3802,6 +3819,16 @@ interface WorkBuddyStatusRouteOptions {
    * probe.
    */
   accountUsable?(region: WorkBuddyRegion, account: WorkBuddyRecoveryCandidate): Promise<boolean>;
+  /**
+   * The CLI route's live turns, for the composer readout.
+   *
+   * A READ of the bridge's in-memory board, not a computation: the route exists
+   * so a turn that is still running has somewhere to be observed from, and the
+   * board is the only thing that knows. Absent (the bridge is switched off, or
+   * this Host mounted the status routes without it) means "no live turns", which
+   * the chip renders as nothing at all.
+   */
+  cliLive?(): unknown;
   /**
    * Why each of the region's accounts cannot serve right now, keyed by account
    * id. Absent key (or an absent dep) means "no reason known" — the composer