@evandu/super-pi 0.1.81 → 0.1.83

package/dist/server/runtime.js

@@ -232,9 +232,22 @@ export function taskExtensionPath(from = import.meta.dirname) {
  * The tool's name as far as the stream has revealed it so far, or an empty string while the model is
  * still on the first token. Deliberately NOT a placeholder: a block labelled 「工具」 tells the reader
  * nothing they cannot already see, whereas one labelled 'edit' one second early is the whole point.
+ *
+ * THE EVENT IS READ BEFORE `partial`, and that order is the whole fix. This used to look only at
+ * `partial` - the half-built assistant message - which is where the Anthropic and pi-messages converters
+ * put the toolCall block. Real Pi does NOT send it: a live RPC probe against Pi itself returns
+ * `toolcall_start {"contentIndex":1,"id":"call_…","toolName":"read","hasPartial":false}`, the name on the
+ * event and no `partial` at all. So this returned "" for every call the user ever made, every placeholder
+ * row was filed under an empty name, and the name-based lookup that pairs a call with the row the reader
+ * is already looking at could never match - see `onToolCall` in application/run-service.ts, which then
+ * fell back to recency and put the calls on each other's rows. Reading `toolName` first is what makes the
+ * pairing work at all; `partial` stays as the fallback for a Pi that only fills the message.
  */
-function toolNameOf(partial) {
-    const content = partial?.content;
+function toolNameOf(event) {
+    const direct = event?.toolName;
+    if (typeof direct === "string" && direct)
+        return direct;
+    const content = event?.partial?.content;
     const block = Array.isArray(content) ? content.find((item) => item?.type === "toolCall") : undefined;
     return typeof block?.name === "string" ? block.name : "";
 }
@@ -705,12 +718,13 @@ export class PiRpcRuntime {
                             // A fresh index means a fresh call, so anything the PREVIOUS call at this index wrote is
                             // dropped here rather than carried into this one's first fragment.
                             argumentText.delete(event.contentIndex);
-                            toolNames.set(event.contentIndex, toolNameOf(event.partial));
-                            onToolPreparing?.({ contentIndex: event.contentIndex, name: toolNameOf(event.partial) });
+                            const name = toolNameOf(event);
+                            toolNames.set(event.contentIndex, name);
+                            onToolPreparing?.({ contentIndex: event.contentIndex, name });
                         }
                         else if (event?.type === "toolcall_delta" && typeof event.contentIndex === "number") {
                             const delta = typeof event.delta === "string" ? event.delta : "";
-                            // The NAME IS CARRIED FORWARD because the line naming the call needs it: `toolcall_start`
+                            // THE NAME IS CARRIED FORWARD because the line naming the call needs it: `toolcall_start`
                             // is the only event that carries one, and by the second fragment the mapping has to choose
                             // between a `read`'s path and a `bash`'s command.
                             const name = toolNames.get(event.contentIndex) ?? "";
@@ -723,6 +737,36 @@ export class PiRpcRuntime {
                             const detail = describeToolCallInProgress(name, text);
                             onToolPreparing?.({ contentIndex: event.contentIndex, name, ...(text ? { live: text } : {}), ...(detail ? { detail } : {}) });
                         }
+                        // `toolcall_end` IS THE ARGUMENTS, FINISHED - and this branch is what stops a call that Pi
+                        // announced but never ran from rendering as a call with no parameters at all.
+                        //
+                        // Until `tool_execution_start`, a row's parameters exist only as the JSON text streaming past
+                        // in `live`, which the transcript deliberately does not show as parameters. So a call the turn
+                        // cut off mid-flight - an abort, a cancelled turn, an upstream error - reached the reader as
+                        // 「正在生成参数…」 above 「（这次调用没有可显示的参数）」, the two halves of which are the same fact: the
+                        // parameters were known and were not shown. Pi puts the completed object on this event, so the
+                        // row gets its real parameters from here instead.
+                        //
+                        // Reduced exactly as everywhere else (`describeToolCallArgs`), so this is the same bounded
+                        // derivation and not the arguments themselves, and the raw object stops at this line.
+                        else if (event?.type === "toolcall_end" && typeof event.contentIndex === "number") {
+                            const toolCall = event.toolCall;
+                            const name = typeof toolCall?.name === "string" && toolCall.name ? toolCall.name : (toolNames.get(event.contentIndex) ?? "");
+                            // The name this event carries is the authoritative one, so a row filed under an empty name
+                            // by a start that carried none can still be paired with its execution.
+                            if (name)
+                                toolNames.set(event.contentIndex, name);
+                            const args = describeToolCallArgs(toolCall?.arguments);
+                            const text = argumentText.get(event.contentIndex) ?? "";
+                            // `detail` GOES OUT ONLY WHEN NOTHING HAS DERIVED ONE. The delta path reads the same target
+                            // out of the same text a fragment earlier, so re-sending it would be a patch that changes
+                            // nothing - and a patch that changes nothing still publishes a frame, which is one more
+                            // `message.tools` broadcast per call for no reader-visible change. The one case it earns its
+                            // place in is a call whose fragments never became readable, where this is the last moment
+                            // the parameters are available to name the target from.
+                            const detail = describeToolCall(name, toolCall?.arguments);
+                            onToolPreparing?.({ contentIndex: event.contentIndex, name, final: true, ...(args ? { args } : {}), ...(!describeToolCallInProgress(name, text) && detail ? { detail } : {}) });
+                        }
                         // Pi's reasoning lifecycle is three events, not one flag: `thinking_delta` means the model is
                         // STILL THINKING RIGHT NOW, and `thinking_end` is the only thing that says it stopped. There is
                         // deliberately no `active` field read here - every `thinking_delta` in Pi's wire shape carries

package/dist/server/store.d.ts

@@ -307,6 +307,30 @@ export declare class Store {
         question?: ToolCallQuestion;
         backgroundTask?: ToolCallBlock["backgroundTask"];
     }): Promise<ToolCallBlock[]>;
+    /**
+     * STOPS SEVERAL ROWS FROM CLAIMING THE MODEL IS STILL WRITING THEM, in one write.
+     *
+     * A row is created by `toolcall_start` and filled in by `tool_execution_start`, so a call the turn cut
+     * off between the two - an abort, a cancelled turn, an upstream error - kept `preparing` for the rest of
+     * time. A finished turn showing 「生成参数中…」 is the same expensive lie as a settled tool still saying
+     * 「正在生成参数…」: it says the agent is working on something it has already stopped doing, and it is
+     * what a reader sees on every such row for the rest of the conversation.
+     *
+     * WHAT IS *NOT* WRITTEN HERE, and the omissions are the point. No `status`: Pi reported no outcome for
+     * these calls, and `status` is the field that says an outcome was observed - writing `"error"` would
+     * claim the tool failed, which is a different fact from "it never ran". No `result`, for the same
+     * reason. `preparing: false` alone says exactly what is true, which is that the arguments stopped
+     * arriving.
+     *
+     * `live` IS CLEARED, because during preparation that field holds the ARGUMENT TEXT and the transcript
+     * would otherwise print a raw JSON fragment under a call that never ran. The parameters themselves are
+     * not lost: `args` carries them from `toolcall_end`, and `detail` has named the target since the first
+     * readable fragment.
+     *
+     * Addressed by position like every other row write, and one that is not there is skipped rather than
+     * failing the turn - the same tolerance `settleToolCall` has for an id it cannot resolve.
+     */
+    clearPreparingToolCalls(conversationId: string, messageId: string, rows: readonly number[]): Promise<ToolCallBlock[]>;
     setStatus(conversationId: string, status: Conversation["status"]): Promise<void>;
     /** The plan a revert would carry out, without carrying it out. The server reads this to stop children first. */
     planRevert(conversationId: string, messageId: string, withdraw?: boolean): RevertPlan;

package/dist/server/store.js

@@ -1084,6 +1084,52 @@ export class Store {
         await this.persist();
         return structuredClone(calls);
     }
+    /**
+     * STOPS SEVERAL ROWS FROM CLAIMING THE MODEL IS STILL WRITING THEM, in one write.
+     *
+     * A row is created by `toolcall_start` and filled in by `tool_execution_start`, so a call the turn cut
+     * off between the two - an abort, a cancelled turn, an upstream error - kept `preparing` for the rest of
+     * time. A finished turn showing 「生成参数中…」 is the same expensive lie as a settled tool still saying
+     * 「正在生成参数…」: it says the agent is working on something it has already stopped doing, and it is
+     * what a reader sees on every such row for the rest of the conversation.
+     *
+     * WHAT IS *NOT* WRITTEN HERE, and the omissions are the point. No `status`: Pi reported no outcome for
+     * these calls, and `status` is the field that says an outcome was observed - writing `"error"` would
+     * claim the tool failed, which is a different fact from "it never ran". No `result`, for the same
+     * reason. `preparing: false` alone says exactly what is true, which is that the arguments stopped
+     * arriving.
+     *
+     * `live` IS CLEARED, because during preparation that field holds the ARGUMENT TEXT and the transcript
+     * would otherwise print a raw JSON fragment under a call that never ran. The parameters themselves are
+     * not lost: `args` carries them from `toolcall_end`, and `detail` has named the target since the first
+     * readable fragment.
+     *
+     * Addressed by position like every other row write, and one that is not there is skipped rather than
+     * failing the turn - the same tolerance `settleToolCall` has for an id it cannot resolve.
+     */
+    async clearPreparingToolCalls(conversationId, messageId, rows) {
+        const conversation = this.requireConversation(conversationId);
+        const message = conversation.messages.find((item) => item.id === messageId);
+        if (!message)
+            throw new Error("Assistant message not found");
+        const calls = message.toolCalls;
+        if (!calls)
+            return [];
+        let touched = false;
+        for (const index of rows) {
+            const call = calls[index];
+            if (!call || call.preparing !== true)
+                continue;
+            call.preparing = false;
+            call.live = "";
+            touched = true;
+        }
+        if (touched) {
+            conversation.updatedAt = now();
+            await this.persist();
+        }
+        return structuredClone(calls);
+    }
     async setStatus(conversationId, status) { const conversation = this.requireConversation(conversationId); conversation.status = status; conversation.updatedAt = now(); await this.persistMetadata(conversationId); }
     /** The plan a revert would carry out, without carrying it out. The server reads this to stop children first. */
     planRevert(conversationId, messageId, withdraw = false) { return planRevert(this.state, conversationId, messageId, withdraw); }

package/dist/server/terminal.d.ts

@@ -20,9 +20,8 @@
  *
  * So the guards here are deliberately redundant, and each one closes a hole the others do not:
  *
- *   1. OPT-IN, OFF BY DEFAULT. `SUPER_PI_TERMINAL` must be set to `1`/`true`/`on` before a single shell
- *      is spawned. The default install has no terminal at all - the tab is not even rendered. Enabling
- *      it is a deliberate act by someone who knows what it does.
+ *   1. AVAILABLE BY DEFAULT. The terminal is a built-in local capability. Network scope, workspace
+ *      resolution, and bounded sessions still protect every command.
  *   2. NETWORK SCOPE. Even enabled, a command is refused unless the WebSocket arrived from loopback or
  *      an RFC 1918 / link-local / ULA address (`isLocalOrPrivateAddress`, the same predicate the file
  *      endpoints use). A request that arrives from a routed or proxied address is refused by name.
@@ -48,7 +47,6 @@
  *
  * `node-pty` allocates a real pseudo-terminal (ConPTY on Windows, `forkpty` elsewhere), which is the
  * only way to get them. The cost is a native module, and it is paid only by operators who set
- * `SUPER_PI_TERMINAL=1` - see `loadPty` below, which is reached lazily and never at import time.
  */
 import type { ServerEvent, Workspace } from "./types.js";
 /** One shell per browser tab, and a hard ceiling so reconnects cannot accumulate processes. */
@@ -99,11 +97,11 @@ export type TerminalEvent = {
     reason?: string;
 };
 /**
- * Reads the opt-in flag. Anything other than an explicit truthy string leaves the terminal OFF.
+ * The terminal is built in; node-pty availability is checked when a session opens.
  */
 export declare function isTerminalEnabled(env?: NodeJS.ProcessEnv): boolean;
 /** The sentence a browser shows when the terminal is missing. Says WHICH of the three gates closed. */
-export declare function terminalDisabledReason(env?: NodeJS.ProcessEnv): string;
+export declare function terminalDisabledReason(_env?: NodeJS.ProcessEnv): string;
 export declare class TerminalService {
     private readonly sessions;
     private readonly workspaceFor;

package/dist/server/terminal.js

@@ -20,9 +20,8 @@
  *
  * So the guards here are deliberately redundant, and each one closes a hole the others do not:
  *
- *   1. OPT-IN, OFF BY DEFAULT. `SUPER_PI_TERMINAL` must be set to `1`/`true`/`on` before a single shell
- *      is spawned. The default install has no terminal at all - the tab is not even rendered. Enabling
- *      it is a deliberate act by someone who knows what it does.
+ *   1. AVAILABLE BY DEFAULT. The terminal is a built-in local capability. Network scope, workspace
+ *      resolution, and bounded sessions still protect every command.
  *   2. NETWORK SCOPE. Even enabled, a command is refused unless the WebSocket arrived from loopback or
  *      an RFC 1918 / link-local / ULA address (`isLocalOrPrivateAddress`, the same predicate the file
  *      endpoints use). A request that arrives from a routed or proxied address is refused by name.
@@ -48,7 +47,6 @@
  *
  * `node-pty` allocates a real pseudo-terminal (ConPTY on Windows, `forkpty` elsewhere), which is the
  * only way to get them. The cost is a native module, and it is paid only by operators who set
- * `SUPER_PI_TERMINAL=1` - see `loadPty` below, which is reached lazily and never at import time.
  */
 import { createRequire } from "node:module";
 import { existsSync } from "node:fs";
@@ -60,8 +58,8 @@ let ptyLoadFailure;
  *
  * `import("node-pty")` would be evaluated by the bundler/compiler as a real dynamic import of a package
  * the project does not depend on by default, and its rejection is a load-time failure of the WHOLE
- * server rather than of the terminal. The operator who never sets `SUPER_PI_TERMINAL` should not be
- * able to tell that node-pty exists.
+ * server rather than of the terminal. A server can start without node-pty and report a useful error only
+ * when the terminal is used.
  *
  * `createRequire` sidesteps the module-resolution question entirely: this file is compiled to ESM by
  * `tsconfig.server.json`, `node-pty` is CommonJS, and `require` is the one call that loads CJS from ESM
@@ -166,18 +164,16 @@ const MAX_CHUNK_BYTES = 64 * 1024;
 /** Hard per-session backlog. Beyond this the session is considered runaway and is killed. */
 const MAX_BACKLOG_BYTES = 4 * 1024 * 1024;
 /**
- * Reads the opt-in flag. Anything other than an explicit truthy string leaves the terminal OFF.
+ * The terminal is built in; node-pty availability is checked when a session opens.
  */
 export function isTerminalEnabled(env = process.env) {
-    const raw = env.SUPER_PI_TERMINAL?.trim().toLowerCase();
-    return raw === "1" || raw === "true" || raw === "on" || raw === "yes";
+    void env;
+    return true;
 }
 /** The sentence a browser shows when the terminal is missing. Says WHICH of the three gates closed. */
-export function terminalDisabledReason(env = process.env) {
-    if (!isTerminalEnabled(env))
-        return "终端未启用。设置 SUPER_PI_TERMINAL=1 后重启即可使用。";
+export function terminalDisabledReason(_env = process.env) {
     if (ptyLoadFailure)
-        return `node-pty 未能加载（${ptyLoadFailure}）。请重新安装依赖，或确认 node-pty 版本不低于 ${MINIMUM_PTY_VERSION}。`;
+        return "node-pty unavailable: " + ptyLoadFailure;
     return "";
 }
 export class TerminalService {

package/dist/server/types.d.ts

@@ -262,12 +262,27 @@ export type ToolCallNotice = {
  * field with two meanings would make the caller store one kind of text by appending and the other by
  * replacing - which is a flicker and a duplication at once. Pi sends argument fragments raw; accumulating
  * them is the runtime's job, where the fragments already are.
+ *
+ * `args` arrives ONLY at `toolcall_end`, where Pi hands over the finished argument object. Nothing before
+ * that point can produce it: `live` is raw JSON text, and a half-written document is not one. It is what
+ * gives a row its parameters before `tool_execution_start` announces the call, so a call the turn cut off
+ * mid-flight shows what it was going to do instead of 「（这次调用没有可显示的参数）」. Bounded by the same
+ * `describeToolCallArgs` derivation as every other arguments field, so it adds no new way for raw arguments
+ * to reach `state.json`.
+ *
+ * `final` says these are the FINISHED arguments, and it exists so that one cannot create a row. Pi emits
+ * `toolcall_end` whenever the argument document closes, which on a live probe is before the call runs -
+ * but a turn can also close a document after the call has already been announced and settled, and a
+ * notice that arrives then describes a row that is already on screen. A caller that treated it as an
+ * announcement would append a second, empty block for a call the reader is already looking at.
  */
 export interface ToolCallPreparing {
     contentIndex: number;
     name: string;
     live?: string;
     detail?: string;
+    args?: ToolCallArg[];
+    final?: boolean;
 }
 /**
  * `archivedAt` is the whole archive mechanism: a state MARKER, not a move. The conversation object never

package/dist/server/update.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Return npm's install arguments for the package that is actually running.
+ *
+ * Pi can keep Super Pi in its own npm prefix, separate from the user's normal
+ * global npm prefix.  A bare `npm install -g` therefore may update a different
+ * copy while this process keeps serving the old one.  Installed package roots
+ * contain `node_modules/@evandu/super-pi`; walking back to the prefix makes the
+ * update target unambiguous.  Source checkouts retain the global fallback.
+ */
+export declare function packageUpdateArgs(rootDir: string): {
+    args: string[];
+    prefix?: string;
+};

package/dist/server/update.js

@@ -0,0 +1,20 @@
+import { sep } from "node:path";
+/**
+ * Return npm's install arguments for the package that is actually running.
+ *
+ * Pi can keep Super Pi in its own npm prefix, separate from the user's normal
+ * global npm prefix.  A bare `npm install -g` therefore may update a different
+ * copy while this process keeps serving the old one.  Installed package roots
+ * contain `node_modules/@evandu/super-pi`; walking back to the prefix makes the
+ * update target unambiguous.  Source checkouts retain the global fallback.
+ */
+export function packageUpdateArgs(rootDir) {
+    const marker = `${sep}node_modules${sep}`;
+    const lower = rootDir.toLowerCase();
+    const index = lower.lastIndexOf(marker);
+    if (index >= 0) {
+        const prefix = rootDir.slice(0, index);
+        return { prefix, args: ["install", "--prefix", prefix, "@evandu/super-pi"] };
+    }
+    return { args: ["install", "-g", "@evandu/super-pi"] };
+}