@drakon-systems/multi-clawd 1.7.0 → 1.7.2

package/README.md

@@ -153,7 +153,52 @@ npm i -g @drakon-systems/multi-clawd && multi-clawd update
 ```
 
 `update` runs the registry install with the right flags, offers the gateway
-restart, and finishes with a doctor health check. Prefer the raw form?
+restart, and finishes with a doctor health check.
+
+> ### ⚠️ Keeping up to date: there are two halves
+>
+> One package installs as **two separate artifacts**, and they update by
+> different routes:
+>
+> | Half | What it is | How it updates |
+> |---|---|---|
+> | **The plugin** | serves your turns — pooling, rotation, credentials | `multi-clawd update` |
+> | **The CLI** | the `multi-clawd` command — `doctor`, `chain`, `setup`, `explain` | `npm i -g @drakon-systems/multi-clawd@latest` |
+>
+> **`multi-clawd update` upgrades the plugin, not itself.** Since v1.6.0 it
+> notices when the command has fallen behind and offers to update it — but
+> that notice ships *in the command*, so a CLI older than v1.6.0 has no code
+> to warn you with. We found this on three of our own machines, all running
+> current plugins behind commands that were three versions stale.
+>
+> **So run the global install once, by hand, to arm it:**
+>
+> ```bash
+> npm i -g @drakon-systems/multi-clawd@latest
+> ```
+>
+> After that it maintains itself. It matters because `doctor` and `chain` live
+> in the CLI — a stale command reports *stale diagnostics about a current
+> plugin*, which is a confusing way to be told nothing is wrong. `multi-clawd
+> version` shows both halves, and since v1.6.0 says plainly whether the pair
+> is a problem.
+>
+> ### ⚠️ `openclaw plugins update --all` cannot move this plugin
+>
+> It will tell you the plugin is up to date when it is not. We install with
+> `--pin` (OpenClaw's own security audit raises a HIGH finding for unpinned
+> install specs, so pinning is the right side of that trade), and OpenClaw
+> resolves registry metadata *for the pinned spec* — comparing 1.6.0 against
+> 1.6.0 and returning "up to date" while a newer version sits on npm. The
+> honest "pinned to X; registry default resolves to Y" message exists in
+> OpenClaw but is built inside its `--dry-run` branch, so a real update run
+> never prints it.
+>
+> **Use `multi-clawd update`.** Since v1.7.2 `doctor` also checks the registry
+> itself (cached, and silent when offline), so a lagging plugin is reported
+> rather than left to a command that reassures you wrongly.
+
+Prefer the raw form?
 
 ```bash
 openclaw plugins install @drakon-systems/multi-clawd --pin
@@ -189,7 +234,7 @@ openclaw plugins install (Get-Location).Path
 **Or let your agent install it.** Running an OpenClaw assistant or Claude
 Code on the target machine already? Paste it this and go make coffee:
 
-> Read https://raw.githubusercontent.com/Drakon-Systems-Ltd/multi-clawd/v1.7.0/SETUP-AGENT.md
+> Read https://raw.githubusercontent.com/Drakon-Systems-Ltd/multi-clawd/v1.7.2/SETUP-AGENT.md
 > and follow it to set up multi-clawd on this machine. I own a second
 > Claude account — ask me when you need me to log in.
 
@@ -375,11 +420,25 @@ How it decides, per launch (all data from each account's live
 | Account state | Effect |
 |---|---|
 | `rejected` + reset in the future | skipped until `resetsAt` passes |
+| `rejected` with no reset, on a named window | skipped for an hour, then re-probed (v1.7.2) |
+| `rejected` on the `unknown` window | still used — that is where a single-model limit lands, and it must not strand the account |
 | any window utilization ≥ threshold | skipped (nearly maxed — the point of the pool) |
-| `allowed_warning` alone | still used — weekly windows warn early; only the utilization number rotates |
+| `allowed_warning` with a number below threshold | still used — trust the number |
+| `allowed_warning` and **no** number, on a short window | skipped (v1.7.2) — see below |
+| `allowed_warning` and no number, on the weekly window | still used — weekly warns from ~30% and would flap |
 | no data / stale data | used — never rotate on missing evidence |
 | whole pool exhausted | home account anyway → real limit error → your chain drops provider |
 
+**Why the short-window rule exists (v1.7.2).** The threshold rule needs a
+utilization number, and Anthropic does not send one for the 5-hour session
+window — across every observation we hold from two accounts it arrives as a
+bare status plus a reset time, while the weekly windows carry percentages. A
+rule that waits for a number therefore could never pre-empt the session
+limit: the pool would take the hit and rotate afterwards. So on hour-scoped
+windows the warning counts on its own. It stays narrow deliberately — a
+reported number always wins over the status, and a warning from a window that
+has since reset is void, exactly like a stale percentage.
+
 Notes:
 
 - Rotation happens at limit boundaries only. A mid-conversation handover

package/dist/health.js

@@ -3,6 +3,17 @@ const DEFAULT_UTILIZATION_THRESHOLD = 0.85;
 const DEFAULT_STALE_AFTER_MS = 6 * 60 * 60 * 1000;
 export const MODEL_REJECTED_TTL_MS = 60 * 60 * 1000;
 const MODEL_WINDOW_PREFIX = "model:";
+const SHORT_WINDOW_PATTERN = /(^|_)hours?(_|$)/;
+export function isShortWindow(window) {
+    return SHORT_WINDOW_PATTERN.test(window);
+}
+const PERIOD_WINDOW_PATTERN = /(^|_)(minutes?|hours?|days?|weeks?|months?)(_|$)/;
+export function isPeriodWindow(window) {
+    return PERIOD_WINDOW_PATTERN.test(window);
+}
+export function isWarningStatus(status) {
+    return /warning/i.test(status);
+}
 export const MAX_RESET_HORIZON_MS = 8 * 24 * 60 * 60 * 1000;
 export function classifyAccountHealth(state, options, nowMs, requestedModel) {
     const staleAfterMs = options.staleAfterMs ?? DEFAULT_STALE_AFTER_MS;
@@ -58,6 +69,13 @@ export function classifyAccountHealth(state, options, nowMs, requestedModel) {
                 reason: `${window} rejected until ${new Date(resetMs).toISOString()}`,
             };
         }
+        if (w.status === "rejected" && resetMs === undefined && isPeriodWindow(window)) {
+            return {
+                verdict: "exhausted",
+                resumeAt: w.seenAt + MODEL_REJECTED_TTL_MS,
+                reason: `${window} rejected ${Math.round((nowMs - w.seenAt) / 60000)}m ago (no reset time; TTL block)`,
+            };
+        }
         if (worst.verdict === "ok" &&
             typeof w.utilization === "number" &&
             w.utilization >= threshold &&
@@ -67,6 +85,16 @@ export function classifyAccountHealth(state, options, nowMs, requestedModel) {
                 reason: `${window} utilization ${w.utilization} >= ${threshold}`,
             };
         }
+        if (worst.verdict === "ok" &&
+            typeof w.utilization !== "number" &&
+            isShortWindow(window) &&
+            isWarningStatus(w.status) &&
+            (resetBearing || resetMs === undefined)) {
+            worst = {
+                verdict: "near_limit",
+                reason: `${window} reported ${w.status} with no utilization — short window, treated as near-limit`,
+            };
+        }
     }
     if (worst.verdict === "ok" && !hasLiveEvidence)
         return { verdict: "no_data" };

package/dist/index.js

@@ -471,7 +471,7 @@ function writeStickyEntry(file, entry, logger) {
         logger.warn(`[multi-clawd] sticky state write failed: ${String(err)}`);
     }
 }
-function registerPoolBackend(api, pool, accounts, registeredIds, execMode) {
+export function registerPoolBackend(api, pool, accounts, registeredIds, execMode) {
     const logger = api.logger;
     if (!pool)
         return;

package/dist/update-core.js

@@ -57,6 +57,25 @@ export function formatCliSkew(opts) {
                 `the plugin serving your turns is behind. Fix: multi-clawd update`);
     }
 }
+export const REGISTRY_CHECK_TTL_MS = 6 * 60 * 60 * 1000;
+export function registryCacheIsFresh(checkedAt, nowMs, ttlMs = REGISTRY_CHECK_TTL_MS) {
+    if (typeof checkedAt !== "number")
+        return false;
+    return checkedAt <= nowMs && nowMs - checkedAt < ttlMs;
+}
+export function formatRegistryLag(opts) {
+    if (!opts.installed || !opts.latest)
+        return undefined;
+    if (compareVersions(opts.installed, opts.latest) >= 0) {
+        return { level: "ok", text: `plugin v${opts.installed} is the latest published version` };
+    }
+    return {
+        level: "warn",
+        text: `plugin v${opts.installed} — npm publishes v${opts.latest}. The install is pinned, so ` +
+            `\`openclaw plugins update --all\` reports it up to date and will not move it. ` +
+            `Fix: multi-clawd update`,
+    };
+}
 export function formatUpdateBanner(opts) {
     const action = decideUpdateAction(opts);
     switch (action) {

package/openclaw.plugin.json

@@ -1,7 +1,7 @@
 {
   "id": "multi-clawd",
   "name": "multi-clawd",
-  "version": "1.7.0",
+  "version": "1.7.2",
   "description": "Register additional Claude Code logins (Max/Pro accounts) as first-class OpenClaw CLI backends for cross-account failover, keeping the full skills/MCP harness on every account.",
   "cliBackends": [
     "claw1",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@drakon-systems/multi-clawd",
-  "version": "1.7.0",
+  "version": "1.7.2",
   "description": "Multi-account Claude Code failover for OpenClaw — register additional Claude (Max/Pro) logins as first-class CLI backends and keep the full skills/MCP harness across every account.",
   "type": "module",
   "license": "MIT",

package/scripts/doctor.mjs

@@ -20,7 +20,7 @@
  * Exit code: 0 all good, 1 any ❌.
  */
 import { execFileSync } from "node:child_process";
-import { existsSync, readFileSync, readdirSync, statSync } from "node:fs";
+import { existsSync, mkdirSync, readFileSync, readdirSync, statSync, writeFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { dirname, join, resolve } from "node:path";
 import { fileURLToPath } from "node:url";
@@ -138,6 +138,42 @@ else ok(`installed at ${EXT_DIR}`);
       : undefined;
   if (note) warn(note);
   else if (cliVer && pluginVer) ok(`CLI and plugin both v${cliVer}`);
+
+  // Is the installed plugin behind what npm publishes? Nothing else asks:
+  // `openclaw plugins update --all` compares against the PINNED spec and so
+  // always reports a pinned plugin up to date (found 1 Aug 2026), and doctor
+  // did no registry lookup at all. Cached, short-timeout, and silent when the
+  // registry cannot be reached — an offline box has no finding to report.
+  if (uc && pluginVer && typeof uc.formatRegistryLag === "function") {
+    const cacheFile = join(STATE_DIR, "registry-check.json");
+    const cached = readJson(cacheFile);
+    let latest = uc.registryCacheIsFresh(cached?.checkedAt, Date.now())
+      ? cached?.latest
+      : undefined;
+    if (!latest) {
+      try {
+        latest = execFileSync("npm", ["view", "@drakon-systems/multi-clawd", "version"], {
+          encoding: "utf8",
+          timeout: 8000,
+          stdio: ["ignore", "pipe", "ignore"],
+        }).trim();
+        try {
+          mkdirSync(STATE_DIR, { recursive: true });
+          writeFileSync(
+            cacheFile,
+            JSON.stringify({ latest, checkedAt: Date.now() }, null, 2) + "\n",
+          );
+        } catch {
+          /* cache is an optimisation, never a requirement */
+        }
+      } catch {
+        latest = undefined; // offline / registry down — stay silent
+      }
+    }
+    const lag = uc.formatRegistryLag({ installed: pluginVer, latest });
+    if (lag?.level === "warn") warn(lag.text);
+    else if (lag?.level === "ok") ok(lag.text);
+  }
 }
 if (!entry) bad("no plugins.entries[\"multi-clawd\"] in openclaw.json");
 else if (entry.enabled !== true) bad("plugin entry present but not enabled");