@evandu/super-pi 0.1.132 → 0.1.133

package/dist/server/http-server.js

@@ -913,6 +913,26 @@ export function createHttpServer(options) {
             }
             return;
         }
+        /**
+         * CHECKS THE CONNECTION, and says why it does not work when it does not.
+         *
+         * The status already verifies the credential against Feishu, so this is the same answer shaped
+         * for a button - the difference is that a failure comes back as a MESSAGE AND A HINT rather
+         * than as a state the panel has to interpret.
+         */
+        if (url.pathname === "/api/feishu/verify" && request.method === "POST") {
+            if (!context.feishu) {
+                response.writeHead(503).end();
+                return;
+            }
+            if (!isLocalOrPrivateAddress(remote)) {
+                json(403, { error: "测试飞书连接只允许来自本机或局域网的请求。" });
+                return;
+            }
+            const result = await context.feishu.verify();
+            json(result.ok ? 200 : 400, result);
+            return;
+        }
         if (url.pathname === "/api/shutdown") {
             if (request.method !== "POST" || !isLocalOrPrivateAddress(remote)) {
                 response.writeHead(403, { "content-type": "text/plain; charset=utf-8" }).end("Shutdown requires a loopback or private network POST");

package/dist/server/persistence/sqlite-state-repository.js

@@ -120,6 +120,24 @@ export class SqliteStateRepository {
             }
             else if (transaction.kind === "collections.remove") {
                 this.db.prepare("DELETE FROM collections WHERE name=?").run(transaction.name);
+                // AND THE BASE SNAPSHOT MUST STOP CARRYING IT TOO. Deleting only the overlay row was not
+                // enough: this loader treats an overlay as a PURE INCREMENT - "no row for this name" means
+                // "read it from the base snapshot" - so the base's stale array came back on the next load,
+                // and a scheduled task the user had deleted was resurrected and ran again on its old
+                // schedule (ledger TEST-038). "This collection is empty" is stored as the ABSENCE of the key
+                // (app-state-repository.ts), so the base has to lose the key as well - the row's deletion
+                // alone cannot express it, because the base is where the value would come from.
+                //
+                // The json backend has no incremental path and falls back to a whole-state save, which is
+                // why it was always right; that asymmetry is what makes this a defect and not a choice.
+                const base = this.db.prepare("SELECT json FROM state WHERE id=1").get();
+                if (base) {
+                    const parsed = JSON.parse(String(base.json));
+                    if (transaction.name in parsed) {
+                        delete parsed[transaction.name];
+                        this.db.prepare("UPDATE state SET json=? WHERE id=1").run(JSON.stringify(parsed));
+                    }
+                }
             }
             else if (transaction.kind === "conversation.messages") {
                 // A DIFF, NOT A REWRITE. This used to DELETE the conversation's rows and re-INSERT every

package/dist/server/pi-session-events.js

@@ -16,7 +16,7 @@
  * be announced as unhandled is still announced as unhandled - this bridge changes WHERE the events come
  * from, not what they mean.
  */
-import { describeToolCall, describeToolCallArgs, extractPartialResultText } from "./tool-calls.js";
+import { describeToolCall, describeToolCallArgs, extractPartialResultText, readQuestionCall } from "./tool-calls.js";
 import { toolTargetPath } from "./file-changes.js";
 /** Keeps only real strings, so a malformed queue snapshot cannot put objects into a broadcast. */
 const textList = (value) => Array.isArray(value) ? value.filter((item) => typeof item === "string") : undefined;
@@ -254,7 +254,15 @@ export function handleSessionEvent(event, queue, handlers, report, failure) {
                 return true;
             const name = record.toolName ?? "unknown";
             try {
-                handlers.onToolCall?.({ id, name, detail: describeToolCall(name, record.args), args: describeToolCallArgs(record.args) });
+                // A `question` CALL IS READ HERE, AT `tool_execution_start` - the same place the one-shot path
+                // reads it, and for the same reason: the card on screen must be the tool call the model is
+                // actually blocked in, with the same identity and the same lifecycle. This path left the
+                // question out, so the host never saw a pending question and the model was told the session
+                // had no question waiting for an answer - the `question` tool was simply dead on the SDK
+                // session path, which is the PRODUCTION default (ledger TEST-037). Two paths must give the
+                // same answer to "what is a question call".
+                const question = readQuestionCall(name, record.args);
+                handlers.onToolCall?.({ id, name, detail: describeToolCall(name, record.args), args: describeToolCallArgs(record.args), ...(question ? { question } : {}) });
             }
             catch (error) {
                 console.warn(`PiRpcRuntime: the tool call handler threw: ${error instanceof Error ? error.message : "unknown error"}`);

package/dist/server/pi-session-pool.d.ts

@@ -87,6 +87,22 @@ export declare class PiSessionPool {
      * where that gets fixed.
      */
     private readonly modelEpoch;
+    /**
+     * Mints the OTHER per-session credentials the extensions need, at the moment the session is born.
+     *
+     * WHY A SECOND CALLBACK AND NOT PART OF THE CAPABILITY. The memory and knowledge extensions each
+     * need their own credential - the memory one even carries per-caller flags (read-only for a
+     * sub-agent) that a single session capability cannot express. The one-shot path has always minted
+     * them per turn; the SESSION path minted none, so those two extensions returned before registering
+     * a single tool or injecting a single line of prompt, and both features were absent in production -
+     * the SDK session path is the default backend, and only the test scripts use the one-shot path
+     * (ledger TEST-039).
+     *
+     * They are minted HERE, where the session is born, for the same reason the capability is: the
+     * extension reads its environment ONCE, when it is loaded, so a token minted per turn would be
+     * replaced before the second turn and the extension would still be holding the first turn's value.
+     */
+    private readonly mintExtensionTokens;
     private readonly sessions;
     constructor(
     /** Where Pi keeps its session files. */
@@ -122,7 +138,23 @@ export declare class PiSessionPool {
      * settings window makes every live session unable to reach the new model, and the next turn is
      * where that gets fixed.
      */
-    modelEpoch?: () => number);
+    modelEpoch?: () => number, 
+    /**
+     * Mints the OTHER per-session credentials the extensions need, at the moment the session is born.
+     *
+     * WHY A SECOND CALLBACK AND NOT PART OF THE CAPABILITY. The memory and knowledge extensions each
+     * need their own credential - the memory one even carries per-caller flags (read-only for a
+     * sub-agent) that a single session capability cannot express. The one-shot path has always minted
+     * them per turn; the SESSION path minted none, so those two extensions returned before registering
+     * a single tool or injecting a single line of prompt, and both features were absent in production -
+     * the SDK session path is the default backend, and only the test scripts use the one-shot path
+     * (ledger TEST-039).
+     *
+     * They are minted HERE, where the session is born, for the same reason the capability is: the
+     * extension reads its environment ONCE, when it is loaded, so a token minted per turn would be
+     * replaced before the second turn and the extension would still be holding the first turn's value.
+     */
+    mintExtensionTokens?: (conversationId: string) => Promise<Record<string, string>> | Record<string, string>);
     /**
      * The session for a conversation, built if there is none and REPLACED if the live one is stale.
      *

package/dist/server/pi-session-pool.js

@@ -49,6 +49,7 @@ export class PiSessionPool {
     factory;
     mintCapability;
     modelEpoch;
+    mintExtensionTokens;
     sessions = new Map();
     constructor(
     /** Where Pi keeps its session files. */
@@ -84,7 +85,23 @@ export class PiSessionPool {
      * settings window makes every live session unable to reach the new model, and the next turn is
      * where that gets fixed.
      */
-    modelEpoch = () => 0) {
+    modelEpoch = () => 0, 
+    /**
+     * Mints the OTHER per-session credentials the extensions need, at the moment the session is born.
+     *
+     * WHY A SECOND CALLBACK AND NOT PART OF THE CAPABILITY. The memory and knowledge extensions each
+     * need their own credential - the memory one even carries per-caller flags (read-only for a
+     * sub-agent) that a single session capability cannot express. The one-shot path has always minted
+     * them per turn; the SESSION path minted none, so those two extensions returned before registering
+     * a single tool or injecting a single line of prompt, and both features were absent in production -
+     * the SDK session path is the default backend, and only the test scripts use the one-shot path
+     * (ledger TEST-039).
+     *
+     * They are minted HERE, where the session is born, for the same reason the capability is: the
+     * extension reads its environment ONCE, when it is loaded, so a token minted per turn would be
+     * replaced before the second turn and the extension would still be holding the first turn's value.
+     */
+    mintExtensionTokens = () => ({})) {
         this.sessionDir = sessionDir;
         this.repositoryRoot = repositoryRoot;
         this.agentDir = agentDir;
@@ -92,6 +109,7 @@ export class PiSessionPool {
         this.factory = factory;
         this.mintCapability = mintCapability;
         this.modelEpoch = modelEpoch;
+        this.mintExtensionTokens = mintExtensionTokens;
     }
     /**
      * The session for a conversation, built if there is none and REPLACED if the live one is stale.
@@ -138,7 +156,7 @@ export class PiSessionPool {
         // server separately requires that a turn is RUNNING for the token to be usable, which is what keeps a
         // longer-lived token from being a weaker credential than a per-turn one.
         const capability = this.mintCapability(request.conversationId);
-        const extensionEnv = { ...request.extensionEnv, [CAPABILITY_ENV]: capability, [TOOLS_CAPABILITY_ENV]: capability };
+        const extensionEnv = { ...request.extensionEnv, [CAPABILITY_ENV]: capability, [TOOLS_CAPABILITY_ENV]: capability, ...await this.mintExtensionTokens(request.conversationId) };
         const building = this.build({ ...request, extensionEnv }, fingerprint);
         if (process.env.SUPER_PI_TRACE_LATENCY === "1")
             console.warn(`[super-pi latency] conversation=${request.conversationId} phase=session.build.begin`);

package/dist/server/runtime.d.ts

@@ -164,7 +164,11 @@ export interface AnswerInput {
     onToolPreparing?(call: ToolCallPreparing): void;
     /** Called while the primary model is emitting reasoning, so the UI can show live progress. A call means
      *  the model is STILL THINKING - there is no separate flag, because Pi does not send one. */
-    onThinking?(delta: string): void;
+    /** Called while the primary model is emitting reasoning, so the UI can show live progress. A call means
+     *  the model is STILL THINKING - there is no separate flag, because Pi does not send one.
+     *  The handler may be async: the reasoning signal is the same "the model is producing" signal as
+     *  a text delta, and the caller waits for it so the state it writes is ordered with the delta. */
+    onThinking?(delta: string): void | Promise<void>;
     /** Called when the reasoning phase ends - the only signal that it has. */
     onThinkingEnd?(): void;
 }
@@ -560,6 +564,12 @@ export declare class PiRpcRuntime implements AgentRuntime {
     private readonly options;
     private memory?;
     setMemory(memory: ActiveMemory): void;
+    /**
+     * The memory and knowledge credentials minted for each LIVE session, so they can be released when
+     * the session goes. A credential whose session is gone must not keep working - that is exactly the
+     * shape of a secret with no owner.
+     */
+    private readonly sessionExtensionTokens;
     private knowledge?;
     setKnowledge(knowledge: KnowledgeBase): void;
     private readonly runs;
@@ -841,6 +851,21 @@ export declare class PiRpcRuntime implements AgentRuntime {
      * The TODO ENDPOINT is the one value here that is NOT per-turn derived from disk: it is this server's
      * own address, so it is the same string on every turn and is read once from the constructor's options.
      */
+    /**
+     * THE MEMORY AND KNOWLEDGE CREDENTIALS FOR A NEW SESSION.
+     *
+     * Both extensions read their environment ONCE, when they are loaded, so these are minted where the
+     * session is born - the same place, and for the same reason, as the session's capability. The
+     * one-shot path has always minted them (per turn); the session path minted none, so the memory and
+     * knowledge extensions returned before registering a tool or injecting a prompt, and both features
+     * were missing in production - the SDK session path is the DEFAULT backend, and only the test
+     * scripts take the one-shot path (ledger TEST-039).
+     *
+     * The endpoints are published as global environment variables (index.ts), and they are repeated
+     * here so the extension's contract is stated in one place: an endpoint and a credential travel
+     * together, and the credential is what proves the caller.
+     */
+    private mintSessionExtensionTokens;
     /**
      * The environment Super Pi's extensions read when they are loaded.
      *

package/dist/server/runtime.js

@@ -289,6 +289,12 @@ export class PiRpcRuntime {
     options;
     memory;
     setMemory(memory) { this.memory = memory; }
+    /**
+     * The memory and knowledge credentials minted for each LIVE session, so they can be released when
+     * the session goes. A credential whose session is gone must not keep working - that is exactly the
+     * shape of a secret with no owner.
+     */
+    sessionExtensionTokens = new Map();
     knowledge;
     setKnowledge(knowledge) { this.knowledge = knowledge; }
     runs = new Map();
@@ -466,7 +472,16 @@ export class PiRpcRuntime {
             // ABOUT that session and stop being true with it.
             this.sessionHosts.delete(conversationId);
             this.reportedSessionFiles.delete(conversationId);
-        }, options.sessionFactory ?? createPiSession, (conversationId) => mintCapability(conversationId), () => this.modelEpoch);
+            // The session held these credentials too, so they die with it.
+            const tokens = this.sessionExtensionTokens.get(conversationId);
+            if (tokens) {
+                if (tokens.memoryToken)
+                    this.memory?.release(tokens.memoryToken);
+                if (tokens.knowledgeToken)
+                    this.knowledge?.release(tokens.knowledgeToken);
+                this.sessionExtensionTokens.delete(conversationId);
+            }
+        }, options.sessionFactory ?? createPiSession, (conversationId) => mintCapability(conversationId), () => this.modelEpoch, (conversationId) => this.mintSessionExtensionTokens(conversationId));
     }
     /**
      * The configuration of the session that was built for a conversation, for tests to inspect.
@@ -628,6 +643,37 @@ export class PiRpcRuntime {
      * The TODO ENDPOINT is the one value here that is NOT per-turn derived from disk: it is this server's
      * own address, so it is the same string on every turn and is read once from the constructor's options.
      */
+    /**
+     * THE MEMORY AND KNOWLEDGE CREDENTIALS FOR A NEW SESSION.
+     *
+     * Both extensions read their environment ONCE, when they are loaded, so these are minted where the
+     * session is born - the same place, and for the same reason, as the session's capability. The
+     * one-shot path has always minted them (per turn); the session path minted none, so the memory and
+     * knowledge extensions returned before registering a tool or injecting a prompt, and both features
+     * were missing in production - the SDK session path is the DEFAULT backend, and only the test
+     * scripts take the one-shot path (ledger TEST-039).
+     *
+     * The endpoints are published as global environment variables (index.ts), and they are repeated
+     * here so the extension's contract is stated in one place: an endpoint and a credential travel
+     * together, and the credential is what proves the caller.
+     */
+    async mintSessionExtensionTokens(conversationId) {
+        const minted = {};
+        const env = {};
+        if (this.memory && (await this.memory.configuration()).enabled) {
+            minted.memoryToken = this.memory.issue(conversationId);
+            env.SUPER_PI_MEMORY_TOKEN = minted.memoryToken;
+            env.SUPER_PI_MEMORY_ENDPOINT = process.env.SUPER_PI_MEMORY_ENDPOINT ?? "";
+        }
+        if (this.knowledge && this.knowledge.enabled()) {
+            minted.knowledgeToken = this.knowledge.issue(conversationId);
+            env.SUPER_PI_KNOWLEDGE_TOKEN = minted.knowledgeToken;
+            env.SUPER_PI_KNOWLEDGE_ENDPOINT = process.env.SUPER_PI_KNOWLEDGE_ENDPOINT ?? "";
+        }
+        if (minted.memoryToken || minted.knowledgeToken)
+            this.sessionExtensionTokens.set(conversationId, minted);
+        return env;
+    }
     /**
      * The environment Super Pi's extensions read when they are loaded.
      *
@@ -906,13 +952,10 @@ export class PiRpcRuntime {
                 // pushes the terminal item when Pi settles, and the consumer below reads it. This promise
                 // waits for that signal, and the race with the prompt's own failure is what keeps a turn that
                 // never settles from hanging forever - a hung turn is a conversation that never answers.
-                await Promise.race([
-                    queue.settledSignal,
-                    // The safety net. A session that was aborted, or a Pi that died mid-turn, may never settle,
-                    // and the turn still has to end - otherwise the conversation is stuck on a turn that will
-                    // never produce anything and the next message can never be sent.
-                    new Promise((resolvePromise) => setTimeout(resolvePromise, 5_000)),
-                ]);
+                // `prompt()` only means Pi accepted the request. Do not end this generator on a wall-clock
+                // timeout: the session may still be streaming or executing a tool, and ending here drops
+                // subsequent events while falsely allowing the next prompt onto a busy session.
+                await queue.settledSignal;
                 traceLatency(conversation.id, "session.settled", latencyStartedAt);
                 // THE REVERT BOUNDARY, recorded at the same moment the one-shot path records it: the turn has
                 // settled, so every entry this turn wrote - the user message included - is in the transcript.
@@ -1144,7 +1187,7 @@ export class PiRpcRuntime {
                 if (segment.kind === "text")
                     yield segment.text;
                 else if (segment.kind === "thinking")
-                    input.onThinking?.(segment.text);
+                    await input.onThinking?.(segment.text);
                 else
                     input.onThinkingEnd?.();
             }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.132",
+  "version": "0.1.133",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",
@@ -88,6 +88,10 @@
     "scripts/followup.test.mjs",
     "scripts/pi-followup-queue.test.mjs",
     "scripts/background-result-delivery.test.mjs",
+    "scripts/thinking-status-promotion.test.mjs",
+    "scripts/question-call-session-path.test.mjs",
+    "scripts/withdrawn-message-persistence.test.mjs",
+    "scripts/git-write-endpoint-guard.test.mjs",
     "scripts/question-stop.test.mjs",
     "scripts/background-result-body.test.mjs",
     "scripts/question-request-size.test.mjs",
@@ -119,10 +123,12 @@
     "scripts/styles-no-dangling.test.mjs",
     "scripts/theme-no-hardcoded-colours.test.mjs",
     "scripts/agent-config-regression.test.mjs",
+    "scripts/agents-directory-resilience.test.mjs",
     "scripts/model-filter.test.mjs",
     "scripts/settings-default-model.test.mjs",
     "scripts/provider-registry.test.mjs",
     "scripts/provider-pi-reads.test.mjs",
+    "scripts/session-extension-credentials.test.mjs",
     "scripts/active-memory.test.mjs",
     "scripts/knowledge-base.test.mjs",
     "scripts/knowledge-import-path.test.mjs",
@@ -171,6 +177,7 @@
     "scripts/scheduled-tasks-browser.test.mjs",
     "scripts/md-render-browser.test.mjs",
     "scripts/right-sidebar-browser.test.mjs",
+    "scripts/rail-workspace-follows-session-browser.test.mjs",
     "scripts/sidebar-tools-browser.test.mjs",
     "scripts/tool-runtime-browser.test.mjs",
     "scripts/session-context-menu-browser.test.mjs",
@@ -200,6 +207,8 @@
     "scripts/composer-resize-browser.test.mjs",
     "scripts/workspace-picker-browser.test.mjs",
     "scripts/optimistic-browser.test.mjs",
+    "scripts/stop-while-waiting-browser.test.mjs",
+    "scripts/new-session-stays-selected-browser.test.mjs",
     "scripts/active-memory-browser.test.mjs",
     "scripts/knowledge-base-browser.test.mjs",
     "scripts/terminal-browser.test.mjs",