@evandu/super-pi 0.1.93 → 0.1.95

package/dist/server/store.js

@@ -1556,18 +1556,18 @@ export class Store {
         const waiting = this.waitingMessages(conversation);
         const from = waiting.indexOf(message);
         const target = Math.max(0, Math.min(Math.trunc(toIndex), waiting.length - 1));
-        if (target === from)
-            return structuredClone(message);
         // NOTHING MAY OCCUPY THE `sending` MESSAGE'S SLOT, in either direction. It is already in Pi's stdin and
         // Pi's steering queue is FIFO, so it is delivered next whatever this method does - meaning a different
         // message landing in front of it would be a move the UI performed and the transport then ignored, and
         // moving the `sending` message itself off that spot would be a lie of the same kind.
-        const sendingIndex = waiting.findIndex((item) => item.delivery === "sending");
-        if (sendingIndex >= 0 && (from === sendingIndex || target <= sendingIndex)) {
+        const lastSendingIndex = waiting.reduce((last, item, index) => item.delivery === "sending" ? index : last, -1);
+        if (lastSendingIndex >= 0 && (message.delivery === "sending" || target <= lastSendingIndex)) {
             throw new Error(message.delivery === "sending"
                 ? "这条消息已经交给 Agent 了，挪不动（Pi 会先回答已经收到的那条）"
                 : "前面那条消息已经交给 Agent 了，插不过去（Pi 按收到的顺序送达）");
         }
+        if (target === from)
+            return structuredClone(message);
         // Permute THE WAITING SLOTS rather than splicing a message to an index. The waiting messages are
         // usually a suffix of the array, but they are not guaranteed to be one - an assistant message sits
         // between two of them once a steer has been delivered mid-turn - and an offset derived from "where in

package/dist/server/ws-server.js

@@ -222,10 +222,11 @@ export class WsServer {
                     this.broadcaster.configureStreaming(socket, parsed.coalesce);
                     return;
                 }
-                // A send represents a streaming operation. It must be admitted immediately so a second send
-                // can observe the active run and enter the durable follow-up queue; waiting for the first model
-                // turn here makes every follow-up test time out and defeats the queue semantics.
-                const runIndependently = parsed.type === "message.send" || parsed.type === "run.stop";
+                // A send or selected queued turn is a streaming operation. It must leave the socket's command
+                // chain immediately: waiting for the model turn would block later priority/cancel commands and
+                // make a second send miss the durable queue. The service owns per-conversation run claims.
+                const runIndependently = parsed.type === "message.send" || parsed.type === "message.sendQueued"
+                    || parsed.type === "message.interrupt" || parsed.type === "run.stop";
                 // ...WHICH MEANS A SEND CAN OVERTAKE A REVERT SENT JUST BEFORE IT, because the revert below is
                 // queued behind whatever this socket was already doing. The service only learns it is cutting
                 // when the command EXECUTES, so a send handled in between would find the conversation open and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.93",
+  "version": "0.1.95",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",
@@ -40,6 +40,7 @@
   "check:logic": [
     "scripts/stream-checkpoint.test.mjs",
     "scripts/stream-transport.test.mjs",
+    "scripts/pi-session.test.mjs",
     "scripts/lan-access.test.mjs",
     "scripts/terminal-pty.test.mjs",
     "scripts/persistence-repository.test.mjs",
@@ -141,6 +142,7 @@
     "scripts/knowledge-base-browser.test.mjs"
   ],
   "dependencies": {
+    "@earendil-works/pi-coding-agent": "^0.86.1",
     "@xterm/addon-fit": "^0.11.0",
     "@xterm/xterm": "^6.0.0",
     "node-pty": "^1.2.0-beta.15",