@evandu/super-pi 0.1.90 → 0.1.91

package/dist/client/index.html

@@ -8,8 +8,8 @@
     <link rel="alternate icon" href="/favicon.ico" />
     <link rel="apple-touch-icon" href="/favicon.svg" />
     <title>Super Pi</title>
-    <script type="module" crossorigin src="/assets/index-p1BjYE_T.js"></script>
-    <link rel="stylesheet" crossorigin href="/assets/index-DgQRMp3j.css">
+    <script type="module" crossorigin src="/assets/index-DYjBTgl4.js"></script>
+    <link rel="stylesheet" crossorigin href="/assets/index-BcHIMxNF.css">
   </head>
   <body>
     <div id="root"></div>

package/dist/server/application/conversation-service.js

@@ -37,9 +37,35 @@ export class ConversationService {
         const workspace = this.store.snapshot().workspaces.find(item => item.id === workspaceId);
         if (!workspace)
             throw new Error("Workspace not found");
-        const defaults = workspace.defaultAgentId
-            ? await this.resolveAgentConfiguration({ id: workspaceId, model: workspace.defaultModel, thinkingLevel: workspace.defaultThinkingLevel }, workspace.defaultAgentId, workspaceId)
-            : undefined;
+        // Workspace defaults are copied at birth, but Pi's model list can change after the
+        // setting was saved (for example when a model is removed from Pi's config). Do not
+        // stamp a dead selection onto every new conversation: the scoped catalog probe would
+        // fail and leave the model/thinking controls unavailable. A missing or invalid default
+        // means "follow Pi's current default" for this newly-created conversation.
+        let model = workspace.defaultModel;
+        let thinkingLevel = workspace.defaultThinkingLevel;
+        const catalog = model || thinkingLevel ? await this.runtime.catalog() : undefined;
+        if (catalog?.source === "pi" && model) {
+            const option = catalog.models.find(item => item.provider === model?.provider && item.modelId === model?.modelId);
+            if (!option) {
+                model = undefined;
+                thinkingLevel = undefined;
+            }
+            else {
+                model = { provider: option.provider, modelId: option.modelId, label: option.label };
+                if (thinkingLevel) {
+                    const scoped = await this.runtime.catalog(model);
+                    if (scoped.source === "pi" && !scoped.levels.includes(thinkingLevel))
+                        thinkingLevel = undefined;
+                }
+            }
+        }
+        const resolved = workspace.defaultAgentId
+            ? await this.resolveAgentConfiguration({ id: workspaceId, model, thinkingLevel }, workspace.defaultAgentId, workspaceId)
+            : { model, thinkingLevel };
+        // `null` is intentional here: Store uses it to remove a workspace value that it
+        // would otherwise have copied before applying the resolved configuration.
+        const defaults = { ...resolved, model: resolved.model ?? null, thinkingLevel: resolved.thinkingLevel ?? null };
         const created = await this.store.createConversation(workspaceId, defaults);
         this.broadcaster.broadcastState();
         return created.id;

package/dist/server/application/run-service.d.ts

@@ -239,6 +239,15 @@ export declare class RunService {
     steer(conversationId: string, messageId: string): Promise<void>;
     /** Starts a chosen waiting message as the next turn, only when the conversation is idle. */
     sendQueued(conversationId: string, messageId: string): Promise<void>;
+    /**
+     * Stops the current turn and immediately gives one waiting message its own fresh turn.
+     *
+     * `steer` cannot provide this meaning: Pi only reads its steering queue after the current tool batch
+     * finishes. Stopping first is what makes a long-running tool give way now. `sendQueued` already owns
+     * the hand-off window after a stop, so it waits until the old run has released its slot before opening
+     * the selected message. That preserves the one-Pi-per-conversation invariant.
+     */
+    interruptQueued(conversationId: string, messageId: string): Promise<void>;
     /**
      * The lower-level "wait for run slot, open the turn on a specific waiting message, run it" sequence.
      *

package/dist/server/application/run-service.js

@@ -542,6 +542,22 @@ export class RunService {
         let assistant = assistantMessage;
         let toolCalls = [];
         let pendingTools = Promise.resolve();
+        // A TURN MOVES FROM `waiting` TO `running` ONCE THE MODEL HAS PRODUCED ANY SIGNAL: a text delta
+        // OR a tool-call notice. The `running` state means "we have data flowing", and that is true the
+        // moment Pi yields anything back, regardless of shape. Without this, a pure tool-call turn would
+        // stay in `waiting` until the very end and the reader would see a stuck turn for the whole of a
+        // long tool execution. The flag is the only way to make the flip one-shot: calling `setStatus` on
+        // every delta would be a per-token status write.
+        let firstSignal = true;
+        const promoteToRunning = async () => {
+            if (!firstSignal)
+                return;
+            firstSignal = false;
+            if (this.store.snapshot().conversations.find((item) => item.id === conversation.id)?.status === "waiting") {
+                await this.store.setStatus(conversation.id, "running");
+                this.broadcaster.broadcastState();
+            }
+        };
         // Live events are independent from durable checkpoints. Persisting every token made the stdout
         // reader wait for one disk transaction per token; over a remote browser connection that backlog
         // looked exactly like a slow model. Keep the in-memory transcript current, publish immediately, and
@@ -570,6 +586,12 @@ export class RunService {
         };
         const enqueueTools = (what, work) => {
             pendingTools = pendingTools.then(async () => {
+                // A TOOL CALL IS A SIGNAL THE MODEL IS ALIVE. Promote `waiting` → `running` on the same
+                // path as text deltas: a tool row appearing on screen is the same "we have data" event
+                // the status needs to reflect. Doing it BEFORE the tool write keeps the order
+                // honest - a client that saw the new tool row in the same frame also saw the running
+                // status, instead of flashing back to a still-spinning waiting mark for the next paint.
+                await promoteToRunning();
                 toolCalls = await work();
                 this.broadcaster.broadcast({ type: "message.tools", conversationId: conversation.id, messageId: assistant.id, toolCalls });
             }).catch((error) => {
@@ -853,6 +875,12 @@ export class RunService {
                 // publish a new message underneath it. One `await` at the top covers both, and costs nothing:
                 // the lane is empty most of the time.
                 await pendingTools;
+                // `waiting` → `running` ON THE FIRST DELTA, before the live write. The conversation was
+                // opened in `waiting` (see `openTurn` / `openTurnOnSpecificMessage` / `openTurnOnMessage`),
+                // and the first response token is the observable fact that says the LLM is actually
+                // answering rather than hanging on auth / quota / network. `promoteToRunning` is a no-op
+                // after the first signal so this stays a one-shot status write, not a per-token one.
+                await promoteToRunning();
                 this.store.appendAssistantDeltaLive(conversation.id, assistant.id, delta);
                 spoken += delta.length;
                 // Tool events are structural transcript boundaries. Publish any boundary Pi announced before
@@ -1088,6 +1116,19 @@ export class RunService {
         }
         await this.processWaitingMessage(conversationId, messageId);
     }
+    /**
+     * Stops the current turn and immediately gives one waiting message its own fresh turn.
+     *
+     * `steer` cannot provide this meaning: Pi only reads its steering queue after the current tool batch
+     * finishes. Stopping first is what makes a long-running tool give way now. `sendQueued` already owns
+     * the hand-off window after a stop, so it waits until the old run has released its slot before opening
+     * the selected message. That preserves the one-Pi-per-conversation invariant.
+     */
+    async interruptQueued(conversationId, messageId) {
+        if (this.activeRuns.has(conversationId))
+            await this.stopRun(conversationId);
+        await this.sendQueued(conversationId, messageId);
+    }
     /**
      * The lower-level "wait for run slot, open the turn on a specific waiting message, run it" sequence.
      *

package/dist/server/command-handler.js

@@ -169,6 +169,10 @@ export class CommandHandler {
             await this.runService.steer(command.conversationId, command.messageId);
             return;
         }
+        if (command.type === "message.interrupt") {
+            await this.runService.interruptQueued(command.conversationId, command.messageId);
+            return;
+        }
         if (command.type === "message.sendQueued") {
             await this.runService.sendQueued(command.conversationId, command.messageId);
             return;

package/dist/server/store.d.ts

@@ -107,8 +107,8 @@ export declare class Store {
     deleteWorkspace(workspaceId: string): Promise<string[]>;
     createConversation(workspaceId: string, configuration?: {
         agentId?: string;
-        model?: ModelSelection;
-        thinkingLevel?: string;
+        model?: ModelSelection | null;
+        thinkingLevel?: string | null;
     }): Promise<Conversation>;
     /**
      * Copies a conversation into a NEW one, under an id the caller has already minted.
@@ -549,9 +549,10 @@ export declare class Store {
      * question that is still waiting - a transcript lying about its own order. Splicing at
      * `indexOf(user) + 1` keeps every waiting message below the reply that belongs to the one above it.
      *
-     * The side effects - title, `updatedAt`, `status: "running"`, clearing a stale failure - all describe a
+     * The side effects - title, `updatedAt`, `status: "waiting"`, clearing a stale failure - all describe a
      * TURN rather than a message, which is why `addUserMessage` skips them for a message that is only
-     * waiting. They belong here, at the moment the turn genuinely begins.
+     * waiting. They belong here, at the moment the turn genuinely begins - the model still has not
+     * returned a token, and that is the shape the row carries until `streamTurn` sees the first delta.
      */
     openTurnOnMessage(conversationId: string, messageId: string, agentIdentity?: Message["agentIdentity"]): Promise<{
         user: Message;

package/dist/server/store.js

@@ -135,7 +135,11 @@ function reconcileConversations(state) {
     state.conversations = conversations;
     const orphaned = [];
     for (const conversation of conversations) {
-        if (!conversation || conversation.status !== "running")
+        // `waiting` joins the orphan set for the same reason `running` does: the turn was opened (a prompt
+        // was sent) and the server died before any settled state was recorded. A conversation that was in
+        // either of those two states when the process went away has a half-open turn whose outcome nobody
+        // can determine from the file alone - exactly the situation this sweep exists to remove.
+        if (!conversation || (conversation.status !== "running" && conversation.status !== "waiting"))
             continue;
         conversation.status = "failed";
         conversation.error = ORPHANED_CONVERSATION_ERROR;
@@ -690,10 +694,18 @@ export class Store {
         if (workspace.defaultAgentId)
             conversation.agentId = workspace.defaultAgentId;
         if (configuration) {
-            if (configuration.model)
-                conversation.model = { ...configuration.model };
-            if (configuration.thinkingLevel)
-                conversation.thinkingLevel = configuration.thinkingLevel;
+            if (configuration.model !== undefined) {
+                if (configuration.model)
+                    conversation.model = { ...configuration.model };
+                else
+                    delete conversation.model;
+            }
+            if (configuration.thinkingLevel !== undefined) {
+                if (configuration.thinkingLevel)
+                    conversation.thinkingLevel = configuration.thinkingLevel;
+                else
+                    delete conversation.thinkingLevel;
+            }
             if (configuration.agentId)
                 conversation.agentId = configuration.agentId;
         }
@@ -876,8 +888,13 @@ export class Store {
             : (firstUser?.images?.length ? "【图片】" : DEFAULT_CONVERSATION_TITLE);
         if (!conversation.titleLocked)
             conversation.title = autoTitle || DEFAULT_CONVERSATION_TITLE;
+        // A TURN STARTS IN `waiting`, NOT `running`. The first delta from the model is what flips the
+        // conversation to `running` (see `RunService.streamTurn`); opening a turn only proves a prompt was
+        // sent, and a prompt that was sent but never answered looks identical to one that is mid-stream
+        // until something tells them apart. Holding the gap open is what makes a stuck LLM endpoint
+        // visible to a person - the `waiting` mark on the sidebar row is the only honest signal.
         conversation.updatedAt = message.createdAt;
-        conversation.status = "running";
+        conversation.status = "waiting";
         // The reason this conversation was failed - startup reconciliation's note that a previous run was cut
         // short - describes THAT run, and this line is the moment it stops being the current one. Deleting the
         // key rather than overwriting it keeps the file byte-identical to a conversation that was never
@@ -1610,9 +1627,10 @@ export class Store {
      * question that is still waiting - a transcript lying about its own order. Splicing at
      * `indexOf(user) + 1` keeps every waiting message below the reply that belongs to the one above it.
      *
-     * The side effects - title, `updatedAt`, `status: "running"`, clearing a stale failure - all describe a
+     * The side effects - title, `updatedAt`, `status: "waiting"`, clearing a stale failure - all describe a
      * TURN rather than a message, which is why `addUserMessage` skips them for a message that is only
-     * waiting. They belong here, at the moment the turn genuinely begins.
+     * waiting. They belong here, at the moment the turn genuinely begins - the model still has not
+     * returned a token, and that is the shape the row carries until `streamTurn` sees the first delta.
      */
     async openTurnOnMessage(conversationId, messageId, agentIdentity) {
         const conversation = this.requireConversation(conversationId);
@@ -1629,8 +1647,10 @@ export class Store {
             : (firstUser?.images?.length ? "【图片】" : DEFAULT_CONVERSATION_TITLE);
         if (!conversation.titleLocked)
             conversation.title = autoTitle || DEFAULT_CONVERSATION_TITLE;
+        // Same `waiting` reasoning as `addUserMessage` above - the prompt was just handed off and no
+        // token has come back yet, which is a different observable state from "we have data flowing".
         conversation.updatedAt = user.createdAt;
-        conversation.status = "running";
+        conversation.status = "waiting";
         delete conversation.error;
         await this.persistMessages(conversation);
         return { user: structuredClone(user), assistant: structuredClone(assistant) };

package/dist/server/types.d.ts

@@ -5,7 +5,19 @@ export type ModelFilterRule = {
     label?: string;
 };
 import type { WorkflowRun } from "./workflow.js";
-export type RunStatus = "idle" | "running" | "completed" | "stopped" | "failed";
+/**
+ * The lifecycle states a `Conversation.status` moves through while a turn is in flight. `waiting` is the
+ * gap between "prompt handed to the LLM" and "the first response token arrived" - holding it apart from
+ * `running` is what lets the reader tell a slow or broken LLM endpoint (still waiting) apart from a
+ * streaming turn that is just slow (already running, just no new tokens in the last second). Without
+ * the gap the two states look the same on screen for as long as the model is silent, and the reader has
+ * no signal to debug from.
+ *
+ * `completed` / `stopped` / `failed` are the three settled states. `stopped` is what `run.stop` lands;
+ * `failed` is what any unhandled throw lands (with `Conversation.error` carrying the translated reason);
+ * `completed` is the clean path.
+ */
+export type RunStatus = "idle" | "waiting" | "running" | "completed" | "stopped" | "failed";
 export type MessageRole = "user" | "assistant" | "tool" | "system";
 /**
  * One message in `state.json`.
@@ -1078,6 +1090,12 @@ export type ClientCommandBody =
     conversationId: string;
     messageId: string;
 }
+/** Stops the active turn, then starts this waiting message as a fresh turn. */
+ | {
+    type: "message.interrupt";
+    conversationId: string;
+    messageId: string;
+}
 /** Starts this waiting message as the next turn, only after the current turn has ended. */
  | {
     type: "message.sendQueued";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.90",
+  "version": "0.1.91",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",