@remits/remits-cli 0.1.150 → 0.1.152

package/index.js

@@ -8,14 +8,14 @@
 - L621  Local State, Workspaces, And Verification Evidence
 - L2659  Account Repos, Guide Sync, And Platform Repo
 - L3499  Component Discovery And HTTP Logging
-- L4225  Skill Delivery And TOC Resolution
-- L4540  Auth And Component Staging
-- L5172  Component Summaries, Status, And Sync Gates
-- L7473  Branches, Promotion, Commit, And Test Runs
-- L9562  Tokens, Tools, Verification, And Config
-- L10989  Service Dashboard And WebSocket Listener
-- L13488  Agent And Ticket Workflows
-- L17623  Help, Auto Update, And Command Dispatch
+- L4267  Skill Delivery And TOC Resolution
+- L4582  Auth And Component Staging
+- L5214  Component Summaries, Status, And Sync Gates
+- L7515  Branches, Promotion, Commit, And Test Runs
+- L9631  Tokens, Tools, Verification, And Config
+- L11058  Service Dashboard And WebSocket Listener
+- L13557  Agent And Ticket Workflows
+- L17692  Help, Auto Update, And Command Dispatch
 */
 
 /*
@@ -4142,6 +4142,48 @@ function describeToolsSnapshotWorld(world) {
     'data ' + (world.dataMode || '?')].filter(Boolean).join(', ');
 }
 
+// How many times a `WORKLOAD_BUSY` refusal is retried before it is handed to the caller. About 90 seconds
+// in total: long enough to ride out another agent's stage or sync, short enough that a gate filled by
+// long-running suites still answers as "busy" rather than as a hang.
+const WORKLOAD_BUSY_MAX_RETRIES = 6;
+
+/**
+ * How long to wait before retrying a request the platform refused as `WORKLOAD_BUSY`, or null when the
+ * failure is anything else (or the retries are spent).
+ *
+ * The platform admits only a few heavyweight requests per instance and answers the rest with HTTP 429
+ * BEFORE doing any work, so repeating the identical request is safe — which is not true of any other
+ * failure, and is why this matches on the code rather than on the status alone. The wait starts at the
+ * server's Retry-After and grows, with jitter so several refused agents do not come back in step.
+ */
+function workloadBusyRetryDelayMs(err, attempt, maxRetries, random) {
+  const response = err && err.response;
+  const body = response && response.data;
+  if (!response || response.status !== 429 || !body || body.code !== 'WORKLOAD_BUSY') return null;
+  if (attempt >= maxRetries) return null;
+  const headers = response.headers || {};
+  const advised = Number(body.retryAfterSeconds || headers['retry-after']);
+  const baseSeconds = Number.isFinite(advised) && advised > 0 ? Math.min(advised, 60) : 5;
+  const grown = Math.min(baseSeconds * Math.pow(1.5, attempt), 30);
+  return Math.round(grown * 1000 * (0.75 + 0.5 * random()));
+}
+
+async function postRidingOutBusy(api, endpoint, payload) {
+  const configured = Number(process.env.REMITS_CLI_BUSY_RETRIES);
+  const maxRetries = Number.isInteger(configured) && configured >= 0 ? configured : WORKLOAD_BUSY_MAX_RETRIES;
+  for (let attempt = 0; ; attempt += 1) {
+    try {
+      return await api.post(endpoint, payload);
+    } catch (err) {
+      const delayMs = workloadBusyRetryDelayMs(err, attempt, maxRetries, Math.random);
+      if (delayMs == null) throw err;
+      console.error('Platform instance is busy with ' + (err.response.data.workload || 'other work') +
+        '; retrying in ' + Math.round(delayMs / 1000) + 's (' + (attempt + 1) + '/' + maxRetries + ').');
+      await new Promise((resolve) => setTimeout(resolve, delayMs));
+    }
+  }
+}
+
 async function loggedPost(api, cwd, endpoint, payload, options = {}) {
   const requestId = options.requestId || crypto.randomUUID();
   const started = Date.now();
@@ -4155,7 +4197,7 @@ async function loggedPost(api, cwd, endpoint, payload, options = {}) {
   }
 
   try {
-    responseData = await api.post(endpoint, payload).then((r) => r.data);
+    responseData = await postRidingOutBusy(api, endpoint, payload).then((r) => r.data);
     if (options.toolResponseFile) {
       const callId = options.toolCallId || (responseData && responseData.callId) || requestId;
       responseFile = writeToolResponseFile(cwd, callId, responseData);
@@ -8537,6 +8579,32 @@ function selectPivotCases(tests, limit = 6) {
   return { shown: representatives.slice(0, limit), failedCount: failed.length, rootCount: representatives.length };
 }
 
+// What a PASSING case reported: report(...) / diagnostic(...) values and captured println output. Failed
+// cases print theirs in the pivot block below. Without this, the only way to read a value out of a run
+// was to end the case in a deliberately failing assertion. Bounded, because this output is an agent's
+// context: a few cases, a few hundred characters each, and a count for the rest.
+const PASSING_DIAGNOSTIC_CASES = 6;
+const PASSING_DIAGNOSTIC_CHARS = 700;
+function passingCaseDiagnostics(tests) {
+  return (Array.isArray(tests) ? tests : []).filter((test) => {
+    const passed = test && (test.passed === true || test.outcome === 'passed') && !test.error;
+    const diagnostics = test && test.diagnostics && typeof test.diagnostics === 'object' ? test.diagnostics : null;
+    return passed && diagnostics && Object.keys(diagnostics).length > 0;
+  });
+}
+function printPassingCaseDiagnostics(tests) {
+  const reporting = passingCaseDiagnostics(tests);
+  if (!reporting.length) return;
+  reporting.slice(0, PASSING_DIAGNOSTIC_CASES).forEach((test) => {
+    const text = JSON.stringify(test.diagnostics);
+    console.log('Reported by passing case:', (test.name || '(unnamed)'));
+    console.log('  Diagnostics:', text.length > PASSING_DIAGNOSTIC_CHARS ? text.slice(0, PASSING_DIAGNOSTIC_CHARS) + '... (' + text.length + ' chars; --json for all)' : text);
+  });
+  if (reporting.length > PASSING_DIAGNOSTIC_CASES) {
+    console.log('  ' + (reporting.length - PASSING_DIAGNOSTIC_CASES) + ' more passing case(s) reported diagnostics; use --json to read them.');
+  }
+}
+
 function printTestRunPivots(status = {}) {
   const tests = status.result && Array.isArray(status.result.tests) ? status.result.tests : [];
   if (!tests.length) return;
@@ -8544,6 +8612,7 @@ function printTestRunPivots(status = {}) {
   if (slowest && slowest.duration != null) {
     console.log('Slowest case:', (slowest.name || '(unnamed)') + ' in ' + formatDurationMs(slowest.duration));
   }
+  printPassingCaseDiagnostics(tests);
   const selection = selectPivotCases(tests);
   selection.shown.forEach((test) => {
     console.log('Pivots for failed case:', test.name || '(unnamed)');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remits/remits-cli",
-  "version": "0.1.150",
+  "version": "0.1.152",
   "description": "Local CLI for auth, component sync, and live test execution against Remits",
   "license": "MIT",
   "private": false,

package/skills/remits-cli/references/tool-reference.md

@@ -736,9 +736,10 @@ Read `classification` first:
 - `ORPHANED_*` / `RECOVERED_*` — the attempt was abandoned; read `abandonmentCause`.
 - `REQUEST_TIMEOUT_LIKELY` — it used its whole deadline (`timing.deadlineUsed` near `1.0`). The unit of
   work is too big for one event; the fix is resumable batches, not component logic.
-- `PROCESS_TERMINATED_LIKELY` — it stopped well inside its deadline (`timing.deadlineUsed` near `0`), so
-  the worker was killed (memory pressure, restart). Not a logic bug; inspect JVM/node health and
-  container lifecycle logs.
+- `PROCESS_TERMINATED_LIKELY` — its last recorded sign of life came well inside its deadline
+  (`timing.deadlineUsed` near `0`). A killed worker (memory pressure, restart) is one explanation; a
+  stalled heartbeat or a missed completion write leaves the same evidence. Not a logic bug; check the
+  correlated worker logs, then JVM/node health and container lifecycle logs.
 - `UNKNOWN_NO_DEADLINE_EVIDENCE` — no deadline was recorded, so the cause is genuinely unknown. Use the
   returned `logQuery` filters; do not assume. Events predating delivery-envelope capture always look
   like this.
@@ -996,14 +997,17 @@ every command, so you navigate iteratively.
 | `ticketId` / `artifactType` / `artifactLabel` / `artifactNotes` | no | Attach a screenshot/pdf/trace/video to a support ticket |
 
 ### `mcp_jvm_spike_triage`
-Production-aware triage bundle for a Cloud Run service showing a latency/memory spike. Safe by construction:
-optional class-histogram sampling, **no heap dump and no JFR**.
+Single-instance triage bundle for a Cloud Run service showing a latency/memory spike.
+Summary, optional histogram and stacks come from one request with an explicit process UUID.
+Requires the bundle-capable platform; deploy it before promoting the updated System Account tool.
+Preserves container/heap/non-heap memory, classes, buffers, all-thread family totals and HTTP pool counters.
+Optional logs are service-region scope and can concern other JVMs. No heap dump or JFR.
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
 | `serviceName` | yes | e.g. `remits`, `remits-actions` |
 | `region` | yes | e.g. `us-east5`, `us-east1` |
-| `sampleHeap` | no | Default true — one class histogram + heap composition sample (brief stop-the-world) |
+| `sampleHeap` | no | Default false — explicitly request a live-object histogram; it can trigger GC and pause the JVM |
 | `top` | no | Top classes to return. Default 20, max 100. |
 | `includeThreadDump` / `threadLimit` | no | Fuller thread dump beyond the built-in top-thread preview |
 | `includeLogs` / `logLookbackMinutes` / `logLimit` | no | Recent WARNING+ log signals for the same service |

package/skills/remits-cli/references/troubleshooting.md

@@ -25,6 +25,7 @@
 | Need to learn command behavior | Read the `remits-cli` skill and its references, repo docs, or CLI source. Do not run unsupported mutating subcommand variants such as `remits-cli components commit --help`; if a command unexpectedly mutates or commits, run `remits-cli doctor local-state` and inspect the active actor's repo-local session log before doing anything else. |
 | Sync response reports unexpected deletes, creates, renames, uniqueness errors, or component ID drift | Stop immediately. Do not rerun sync, do not create replacement components to paper over the mismatch, and do not promote more changes. Preserve session logs/tool responses, compare `account-info.json`, local filenames, live inventory, and git history, then prepare a repair/escalation summary. |
 | 500 / `Internal Server Error` from Remits | Stop normal task work. Capture the exact command, error, and response artifact, then escalate to a Remits system admin. Do not invent a workaround. |
+| `Platform instance is busy with ...; retrying` on stderr, or a final `WORKLOAD_BUSY` (HTTP 429) | The platform runs only a few stage/sync/commit requests and Test suites at once per instance, and refused yours before doing any work. The CLI already retried for about 90 seconds. Nothing is broken and nothing was half-applied by the refused request: wait for the other work and run the same command again. If the refusal came from the last step of `components commit`, read the outcome it printed: a branch that was pushed but not synced needs `remits-cli components sync`, not another commit. |
 | Tool parameters rejected | Tool schemas may be cached. Run `remits-cli tools` to refresh `.remits-cli/shared/tools/tools.json` with latest schemas. |
 | Tool response missing | Run `remits-cli doctor local-state`, then check `./.remits-cli/actors/<local-agent>/tool-responses/` and any legacy flat `./.remits-cli/tool-responses/` fallback it reports. |
 | Long-running tool times out | For `mcp_run_action`/`mcp_run_agent`, use the tool's own `executionMode:"async"` and poll with a `controlAction:"status"` call (see `command-reference.md` → *Tool Execution Lifecycle*). For other long tools without their own async, use `remits-cli tool --async true` and poll `remits-cli tool status --call-id <callId>`. `--timeout-ms` only adjusts the per-request HTTP timeout; it is not a substitute for async. |