glasspane-mcp 1.7.0 → 1.8.2

package/dist/dispatch.d.ts

@@ -26,7 +26,7 @@ export declare const MCP_PROTOCOL_VERSION: "2025-06-18";
 export declare const SUPPORTED_PROTOCOL_VERSIONS: readonly string[];
 export declare const SERVER_INFO: {
     readonly name: "glasspane-mcp";
-    readonly version: "1.7.0";
+    readonly version: "1.8.2";
 };
 export declare const PARSE_ERROR = -32700;
 export declare const INVALID_REQUEST = -32600;

package/dist/engine-client.d.ts

@@ -243,6 +243,15 @@ export declare function livenessProbeDecision(outcome: LivenessProbeOutcome): st
 export type ShellSurface = "mcp" | "http";
 /** Where the answer to a timed-out request can be found, per surface. */
 export declare function lateReplyRoute(surface: ShellSurface): string;
+/**
+ * 背压闸的出路。两条禁令各由一条现场证据撑着：探针本身也要过一次 `call()`，会被
+ * 同一道测量原地拒掉，所以旧文本那句"先用 gp_probe_status 查一下"是一件此刻做不到
+ * 第二次的事；这里唯一测到的是**本进程**的字节水位，不是 daemon 的状态，而旧文本
+ * 却挂了 GP_E_ENGINE_UNREACHABLE 那条重启命令——`livenessProbeDecision` 把点名生命
+ * 周期命令的权力只留给 `unreachable`，换一个可能正跑着 act 的 service 会回滚用户屏
+ * 幕上的动作。"每次重试都只会把队列堆得更深"同样不成立：拒绝发生在 `writeLine` 之前。
+ */
+export declare function writeBacklogRemedy(backlogBytes: number, limitBytes: number): string;
 /**
  * Remedy for a deadline overrun: wait and measure, never restart on a probe that
  * merely went unanswered, and never replay a request whose re-issue has a side

package/dist/errors.d.ts

@@ -32,6 +32,20 @@ export declare const GP_E_NOT_FOUND = "GP_E_NOT_FOUND";
  */
 export declare const GP_E_ENGINE_TIMEOUT = "GP_E_ENGINE_TIMEOUT";
 export declare const GP_E_PAYLOAD_TOO_LARGE = "GP_E_PAYLOAD_TOO_LARGE";
+/**
+ * Shell-only: this process refused to *write* a request, because the bytes it had
+ * already handed the daemon's socket were not being read
+ * (`ENGINE_WRITE_BACKLOG_BYTES` in `engine-client.ts`).
+ *
+ * It is deliberately not `GP_E_ENGINE_UNREACHABLE`, which is what this refusal
+ * used to answer with: that code's remedy orders a daemon restart, and a backlog
+ * measures a memory watermark in *this* process, not the service's state — the
+ * daemon may be mid-`act` on the user's screen, where a SIGTERM cancels and rolls
+ * the action back. The two answers also have different next moves, which is the
+ * real reason to split the code: the unread bytes may drain on their own, while a
+ * socket nobody is listening on never does.
+ */
+export declare const GP_E_ENGINE_BACKLOG = "GP_E_ENGINE_BACKLOG";
 /**
  * Shell-only, and deliberately *not* a daemon code: this is what the shell
  * answers when a daemon error frame arrives with no `code` at all. Naming it

package/dist/http-gateway-cli.js

@@ -151,6 +151,7 @@ var GP_E_PROJECT_LIMIT = "GP_E_PROJECT_LIMIT";
 var GP_E_NOT_FOUND = "GP_E_NOT_FOUND";
 var GP_E_ENGINE_TIMEOUT = "GP_E_ENGINE_TIMEOUT";
 var GP_E_PAYLOAD_TOO_LARGE = "GP_E_PAYLOAD_TOO_LARGE";
+var GP_E_ENGINE_BACKLOG = "GP_E_ENGINE_BACKLOG";
 var GP_E_UNKNOWN = "GP_E_UNKNOWN";
 var GP_E_NO_USER_RECORD = "GP_E_NO_USER_RECORD";
 function formatToolError(code, message, remedy) {
@@ -280,6 +281,9 @@ var NARROWING_AUTHORITY = {
   mcp: "the gp_* tool that took this call publishes its own parameters, and their floors, in the schema shown beside that tool \u2014 read it there, not here",
   http: "this gateway publishes no parameter listing of its own, so the floors a body was accepted against are in the request contract this call was copied from"
 };
+function writeBacklogRemedy(backlogBytes, limitBytes) {
+  return `this shell wrote nothing: ${backlogBytes} bytes \u2014 over this gate's ${limitBytes} \u2014 are queued in THIS process for the engine socket, and the service accepted the connection and is not reading it. That is a fact about this shell's buffer, not a diagnosis of why: one long operation and a service wedged solid look identical from here, which is why this answer orders neither a restart nor a probe. Stop sending. Do not retry this call in a loop: every attempt is refused by this same measurement, and a refusal writes no bytes, so a loop moves only the clock, not the queue. What is already queued is the service's to read, so wait for the backlog to drain and send again after that \u2014 this gate is re-measured per call, so the first call accepted after the wait is the proof that it drained, and it is a first send rather than a second copy of an action, because nothing went out the first time. While waiting, read the daemon's own log: it is the only side that can say what it is stuck on, and this shell cannot see past its own buffer. For the service installed by this repo's installer that log is \`~/.glasspane/installer-daemon.log\`, the file its stderr is redirected into, in the same directory as the default socket; a daemon started by hand writes wherever its operator pointed its stderr.`;
+}
 function clientClosingRemedy(surface) {
   const readRoute = surface === "mcp" ? "gp_recent_reports lists the operations this session recorded and gp_last_evidence {operationId} returns one in full" : "this gateway keeps no operation trail of its own, so the stderr line this reply is written to is the record";
   return `this shell's own engine client is ending, which measures nothing about the daemon: nothing here authorises touching the daemon's lifecycle, and no restart is authorised by this answer. What is unknown stays unknown: whether the daemon finished this request cannot be told from a client that stopped asking. The reply may still land, under the bound this shell already states \u2014 ${lateReplyRoute(surface)} \u2014 and this shutdown is one of the endings that bound names: the server log line written at this moment lists the requests this client stopped tracking. Read what happened rather than performing it a second time: ${readRoute}. Ask through a server process that still has a live engine client.`;
@@ -426,9 +430,9 @@ var EngineJsonRpcClient = class {
       if (backlog > ENGINE_WRITE_BACKLOG_BYTES) {
         this.pending.delete(id);
         this.reject(entry, new EngineCallError(
-          GP_E_ENGINE_UNREACHABLE,
+          GP_E_ENGINE_BACKLOG,
           `not sending '${method}': ${backlog} bytes are already queued for the engine socket and it has not read them`,
-          `the background service is accepting the connection but not reading it \u2014 it is wedged, not busy. Check it with gp_probe_status; if it stays like this, restart it with the command in \`glasspaned --help\` (or the panel's \u91CD\u542F\u540E\u53F0\u670D\u52A1 button). Do not retry this call in a loop: every retry only deepens the queue it is refusing to drain.`
+          writeBacklogRemedy(backlog, ENGINE_WRITE_BACKLOG_BYTES)
         ));
         return;
       }
@@ -3390,6 +3394,8 @@ function httpStatusForEngineCode(code) {
       return 409;
     case GP_E_ENGINE_UNREACHABLE:
       return 503;
+    case GP_E_ENGINE_BACKLOG:
+      return 503;
     case GP_E_ENGINE_TIMEOUT:
       return 504;
     case GP_E_PAYLOAD_TOO_LARGE:

package/dist/http-gateway.js

@@ -151,6 +151,7 @@ var GP_E_PROJECT_LIMIT = "GP_E_PROJECT_LIMIT";
 var GP_E_NOT_FOUND = "GP_E_NOT_FOUND";
 var GP_E_ENGINE_TIMEOUT = "GP_E_ENGINE_TIMEOUT";
 var GP_E_PAYLOAD_TOO_LARGE = "GP_E_PAYLOAD_TOO_LARGE";
+var GP_E_ENGINE_BACKLOG = "GP_E_ENGINE_BACKLOG";
 var GP_E_UNKNOWN = "GP_E_UNKNOWN";
 var GP_E_NO_USER_RECORD = "GP_E_NO_USER_RECORD";
 function formatToolError(code, message, remedy) {
@@ -276,6 +277,9 @@ var NARROWING_AUTHORITY = {
   mcp: "the gp_* tool that took this call publishes its own parameters, and their floors, in the schema shown beside that tool \u2014 read it there, not here",
   http: "this gateway publishes no parameter listing of its own, so the floors a body was accepted against are in the request contract this call was copied from"
 };
+function writeBacklogRemedy(backlogBytes, limitBytes) {
+  return `this shell wrote nothing: ${backlogBytes} bytes \u2014 over this gate's ${limitBytes} \u2014 are queued in THIS process for the engine socket, and the service accepted the connection and is not reading it. That is a fact about this shell's buffer, not a diagnosis of why: one long operation and a service wedged solid look identical from here, which is why this answer orders neither a restart nor a probe. Stop sending. Do not retry this call in a loop: every attempt is refused by this same measurement, and a refusal writes no bytes, so a loop moves only the clock, not the queue. What is already queued is the service's to read, so wait for the backlog to drain and send again after that \u2014 this gate is re-measured per call, so the first call accepted after the wait is the proof that it drained, and it is a first send rather than a second copy of an action, because nothing went out the first time. While waiting, read the daemon's own log: it is the only side that can say what it is stuck on, and this shell cannot see past its own buffer. For the service installed by this repo's installer that log is \`~/.glasspane/installer-daemon.log\`, the file its stderr is redirected into, in the same directory as the default socket; a daemon started by hand writes wherever its operator pointed its stderr.`;
+}
 function clientClosingRemedy(surface) {
   const readRoute = surface === "mcp" ? "gp_recent_reports lists the operations this session recorded and gp_last_evidence {operationId} returns one in full" : "this gateway keeps no operation trail of its own, so the stderr line this reply is written to is the record";
   return `this shell's own engine client is ending, which measures nothing about the daemon: nothing here authorises touching the daemon's lifecycle, and no restart is authorised by this answer. What is unknown stays unknown: whether the daemon finished this request cannot be told from a client that stopped asking. The reply may still land, under the bound this shell already states \u2014 ${lateReplyRoute(surface)} \u2014 and this shutdown is one of the endings that bound names: the server log line written at this moment lists the requests this client stopped tracking. Read what happened rather than performing it a second time: ${readRoute}. Ask through a server process that still has a live engine client.`;
@@ -422,9 +426,9 @@ var EngineJsonRpcClient = class {
       if (backlog > ENGINE_WRITE_BACKLOG_BYTES) {
         this.pending.delete(id);
         this.reject(entry, new EngineCallError(
-          GP_E_ENGINE_UNREACHABLE,
+          GP_E_ENGINE_BACKLOG,
           `not sending '${method}': ${backlog} bytes are already queued for the engine socket and it has not read them`,
-          `the background service is accepting the connection but not reading it \u2014 it is wedged, not busy. Check it with gp_probe_status; if it stays like this, restart it with the command in \`glasspaned --help\` (or the panel's \u91CD\u542F\u540E\u53F0\u670D\u52A1 button). Do not retry this call in a loop: every retry only deepens the queue it is refusing to drain.`
+          writeBacklogRemedy(backlog, ENGINE_WRITE_BACKLOG_BYTES)
         ));
         return;
       }
@@ -3380,6 +3384,8 @@ function httpStatusForEngineCode(code) {
       return 409;
     case GP_E_ENGINE_UNREACHABLE:
       return 503;
+    case GP_E_ENGINE_BACKLOG:
+      return 503;
     case GP_E_ENGINE_TIMEOUT:
       return 504;
     case GP_E_PAYLOAD_TOO_LARGE:

package/dist/index.js

@@ -807,6 +807,7 @@ var GP_E_PROJECT_LIMIT = "GP_E_PROJECT_LIMIT";
 var GP_E_NOT_FOUND = "GP_E_NOT_FOUND";
 var GP_E_ENGINE_TIMEOUT = "GP_E_ENGINE_TIMEOUT";
 var GP_E_PAYLOAD_TOO_LARGE = "GP_E_PAYLOAD_TOO_LARGE";
+var GP_E_ENGINE_BACKLOG = "GP_E_ENGINE_BACKLOG";
 var GP_E_UNKNOWN = "GP_E_UNKNOWN";
 var GP_E_NO_USER_RECORD = "GP_E_NO_USER_RECORD";
 function formatToolError(code, message, remedy) {
@@ -936,6 +937,9 @@ var NARROWING_AUTHORITY = {
   mcp: "the gp_* tool that took this call publishes its own parameters, and their floors, in the schema shown beside that tool \u2014 read it there, not here",
   http: "this gateway publishes no parameter listing of its own, so the floors a body was accepted against are in the request contract this call was copied from"
 };
+function writeBacklogRemedy(backlogBytes, limitBytes) {
+  return `this shell wrote nothing: ${backlogBytes} bytes \u2014 over this gate's ${limitBytes} \u2014 are queued in THIS process for the engine socket, and the service accepted the connection and is not reading it. That is a fact about this shell's buffer, not a diagnosis of why: one long operation and a service wedged solid look identical from here, which is why this answer orders neither a restart nor a probe. Stop sending. Do not retry this call in a loop: every attempt is refused by this same measurement, and a refusal writes no bytes, so a loop moves only the clock, not the queue. What is already queued is the service's to read, so wait for the backlog to drain and send again after that \u2014 this gate is re-measured per call, so the first call accepted after the wait is the proof that it drained, and it is a first send rather than a second copy of an action, because nothing went out the first time. While waiting, read the daemon's own log: it is the only side that can say what it is stuck on, and this shell cannot see past its own buffer. For the service installed by this repo's installer that log is \`~/.glasspane/installer-daemon.log\`, the file its stderr is redirected into, in the same directory as the default socket; a daemon started by hand writes wherever its operator pointed its stderr.`;
+}
 function clientClosingRemedy(surface) {
   const readRoute = surface === "mcp" ? "gp_recent_reports lists the operations this session recorded and gp_last_evidence {operationId} returns one in full" : "this gateway keeps no operation trail of its own, so the stderr line this reply is written to is the record";
   return `this shell's own engine client is ending, which measures nothing about the daemon: nothing here authorises touching the daemon's lifecycle, and no restart is authorised by this answer. What is unknown stays unknown: whether the daemon finished this request cannot be told from a client that stopped asking. The reply may still land, under the bound this shell already states \u2014 ${lateReplyRoute(surface)} \u2014 and this shutdown is one of the endings that bound names: the server log line written at this moment lists the requests this client stopped tracking. Read what happened rather than performing it a second time: ${readRoute}. Ask through a server process that still has a live engine client.`;
@@ -1082,9 +1086,9 @@ var EngineJsonRpcClient = class {
       if (backlog > ENGINE_WRITE_BACKLOG_BYTES) {
         this.pending.delete(id);
         this.reject(entry, new EngineCallError(
-          GP_E_ENGINE_UNREACHABLE,
+          GP_E_ENGINE_BACKLOG,
           `not sending '${method}': ${backlog} bytes are already queued for the engine socket and it has not read them`,
-          `the background service is accepting the connection but not reading it \u2014 it is wedged, not busy. Check it with gp_probe_status; if it stays like this, restart it with the command in \`glasspaned --help\` (or the panel's \u91CD\u542F\u540E\u53F0\u670D\u52A1 button). Do not retry this call in a loop: every retry only deepens the queue it is refusing to drain.`
+          writeBacklogRemedy(backlog, ENGINE_WRITE_BACKLOG_BYTES)
         ));
         return;
       }
@@ -3661,7 +3665,7 @@ var SUPPORTED_PROTOCOL_VERSIONS = [
   "2025-03-26",
   MCP_PROTOCOL_VERSION
 ];
-var SERVER_INFO = { name: "glasspane-mcp", version: "1.7.0" };
+var SERVER_INFO = { name: "glasspane-mcp", version: "1.8.2" };
 var PARSE_ERROR = -32700;
 var INVALID_REQUEST = -32600;
 var METHOD_NOT_FOUND = -32601;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "glasspane-mcp",
-  "version": "1.7.0",
+  "version": "1.8.2",
   "description": "GlassPane MCP stdio shell: JSON-RPC 2.0 over stdio bridging an AI agent to the glasspane engine daemon",
   "type": "module",
   "main": "./dist/index.js",