@evandu/super-pi 0.1.141 → 0.1.143

package/dist/server/task-tool.d.ts

@@ -71,6 +71,8 @@ export declare const TASK_EXEC_ENDPOINT_ENV = "SUPER_PI_EXEC_ENDPOINT";
 export declare const TASK_ROSTER_ENV = "SUPER_PI_TASK_ROSTER";
 /** The conversation the dispatch belongs to. The server resolves the workspace from this itself. */
 export declare const TASK_CONVERSATION_ENV = "SUPER_PI_TASK_CONVERSATION";
+/** The conversation that spawned this one. Empty means a top-level conversation. */
+export declare const PARENT_CONVERSATION_ENV = "SUPER_PI_PARENT_CONVERSATION";
 /** How many task hops deep this process already is. A primary is `0`. See `DEFAULT_SUBAGENT_DEPTH`. */
 export declare const TASK_DEPTH_ENV = "SUPER_PI_TASK_DEPTH";
 /**
@@ -255,9 +257,9 @@ export declare const SESSION_STATUS_TOOL_NAME = "session_status";
 export declare const SESSION_DISPATCH_TOOL_NAME = "session_dispatch";
 export declare const SESSION_STOP_TOOL_NAME = "session_stop";
 /** Model-facing description for session_spawn. */
-export declare const SESSION_SPAWN_DESCRIPTION = "Create a new sibling conversation in the current workspace and immediately dispatch its initial task.\n\nDIFFERENCE FROM THE 'task' TOOL:\n- The 'task' tool delegates to a transient, one-shot subagent process (scout, critic, patcher) that runs once, returns its final text, and terminates. It has no conversation history and does not appear in the workspace sidebar.\n- 'session_spawn' creates a real, persistent sibling CONVERSATION in Super Pi. It appears in the sidebar, retains multi-turn message history, can receive follow-up messages via session_dispatch, can be inspected via session_status, and can be stopped via session_stop. The user can also switch to it in the Web UI.\n\nWHEN TO USE THIS:\n- Long-running, multi-phase tracks of work that require ongoing context, multiple turns of dialogue, or independent user visibility.\n- Parallel work streams (e.g., Track A: backend refactor, Track B: frontend component update) where both need full conversational capabilities.\n- When the user asks you to act as an orchestrator/manager who delegates to multiple sessions.\n\nWHEN NOT TO USE THIS:\n- For one-off, focused delegation with a single answer: use 'task' (with scout/critic/patcher). It is faster, cheaper, and returns directly to your transcript.\n- For running shell commands or build watchers: use 'run_async'.\n- For a linear multi-step subagent pipeline: use 'workflow'.\n\nUsage notes:\n1. Spawning is ASYNCHRONOUS by default: it creates the conversation, enqueues the initial task, and returns the new conversationId immediately. The sibling session runs in the background.\n2. The initial task should provide clear context and goals since the new session starts with a fresh conversation history.\n3. Use session_status with the returned conversationId to check progress, or session_dispatch to send further messages.";
+export declare const SESSION_SPAWN_DESCRIPTION = "Create a new sibling conversation in the current workspace and immediately dispatch its initial task.\n\nDIFFERENCE FROM THE 'task' TOOL:\n- The 'task' tool delegates to a transient, one-shot subagent process (scout, critic, patcher) that runs once, returns its final text, and terminates. It has no conversation history and does not appear in the workspace sidebar.\n- 'session_spawn' creates a real, persistent sibling CONVERSATION in Super Pi. It appears in the sidebar, retains multi-turn message history, can receive follow-up messages via session_dispatch, can be inspected via session_status, and can be stopped via session_stop. The user can also switch to it in the Web UI.\n\nWHEN TO USE THIS:\n- Long-running, multi-phase tracks of work that require ongoing context, multiple turns of dialogue, or independent user visibility.\n- Parallel work streams (e.g., Track A: backend refactor, Track B: frontend component update) where both need full conversational capabilities.\n- When the user asks you to act as an orchestrator/manager who delegates to multiple sessions.\n\nWHEN NOT TO USE THIS:\n- For one-off, focused delegation with a single answer: use 'task' (with scout/critic/patcher). It is faster, cheaper, and returns directly to your transcript.\n- For running shell commands or build watchers: use 'run_async'.\n- For a linear multi-step subagent pipeline: use 'workflow'.\n\nUsage notes:\n1. Spawning is ASYNCHRONOUS by default: it creates the conversation, enqueues the initial task, and returns the new conversationId immediately. The sibling session runs in the background.\n2. The initial task should provide clear context and goals since the new session starts with a fresh conversation history.\n3. Use session_status with the returned conversationId to check progress, or session_dispatch to send further messages.\n4. The new session reports completion to its DIRECT parent automatically. 'parentConversationId' optionally selects that parent; by default it is the calling session.";
 /** Model-facing description for session_status. */
-export declare const SESSION_STATUS_DESCRIPTION = "Inspect the progress, run state, and latest activity of sibling conversations created by the orchestrator.\n\nWHEN TO USE THIS:\n- To check whether a spawned sibling conversation is still running, has finished (idle), is stopped, or encountered an error.\n- To read the latest assistant progress snippet without bloating your context with the session's entire raw message transcript.\n- To list all sibling conversations under your coordination when conversationId is omitted.\n\nUsage notes:\n1. When 'conversationId' is provided: returns a compact summary for that specific session, including its run status ('idle', 'running', 'waiting', 'stopped', 'failed'), messageCount, turnCount, lastAssistantSnippet, lastUserSnippet, activeTool, and error (if any).\n2. When 'conversationId' is omitted: returns a summary list of ALL sibling conversations spawned by this orchestrator session.\n3. This tool never returns full transcripts; it returns concise summaries and snippets to keep your context window lean.";
+export declare const SESSION_STATUS_DESCRIPTION = "Inspect the progress, run state, and latest activity of sibling conversations created by the orchestrator.\n\nWHEN TO USE THIS:\n- To check whether a spawned sibling conversation is still running, has finished (idle), is stopped, or encountered an error.\n- To read the latest assistant progress snippet without bloating your context with the session's entire raw message transcript.\n- To list all sibling conversations under your coordination when conversationId is omitted.\n\nUsage notes:\n1. When 'conversationId' is provided: returns a compact summary for that specific session, including its run status ('idle', 'running', 'waiting', 'stopped', 'failed'), messageCount, turnCount, lastAssistantSnippet, lastUserSnippet, activeTool, and error (if any).\n2. When 'conversationId' is omitted: returns a summary list of sibling conversations whose direct parent is 'parentConversationId' (the calling session by default).\n3. By default it never returns full transcripts; concise summaries keep your context window lean. Set 'includeOutput' with a conversationId to read the final output from its result file, capped to the last 64Ki characters with an explicit truncation notice.";
 /** Model-facing description for session_dispatch. */
 export declare const SESSION_DISPATCH_DESCRIPTION = "Send a message, follow-up instructions, or steering guidance to an existing sibling conversation.\n\nWHEN TO USE THIS:\n- To follow up with a sibling session after reading its progress with session_status.\n- To give feedback, provide additional requirements, or answer a question from a sibling session.\n- To kick off a new turn on an idle or stopped sibling session.\n\nUsage notes:\n1. 'conversationId' is required and must identify an existing sibling conversation.\n2. 'content' is the text instruction sent to that session, just as if typed by a user in that session's chat.\n3. Dispatch is ASYNCHRONOUS by default: it enqueues the message into the session's queue and returns immediately.\n4. If the sibling session is currently busy running a turn, the dispatched message is placed in its waiting queue and processed when the active turn completes.";
 /** Model-facing description for session_stop. */

package/dist/server/task-tool.js

@@ -70,6 +70,8 @@ export const TASK_EXEC_ENDPOINT_ENV = "SUPER_PI_EXEC_ENDPOINT";
 export const TASK_ROSTER_ENV = "SUPER_PI_TASK_ROSTER";
 /** The conversation the dispatch belongs to. The server resolves the workspace from this itself. */
 export const TASK_CONVERSATION_ENV = "SUPER_PI_TASK_CONVERSATION";
+/** The conversation that spawned this one. Empty means a top-level conversation. */
+export const PARENT_CONVERSATION_ENV = "SUPER_PI_PARENT_CONVERSATION";
 /** How many task hops deep this process already is. A primary is `0`. See `DEFAULT_SUBAGENT_DEPTH`. */
 export const TASK_DEPTH_ENV = "SUPER_PI_TASK_DEPTH";
 /**
@@ -379,7 +381,8 @@ WHEN NOT TO USE THIS:
 Usage notes:
 1. Spawning is ASYNCHRONOUS by default: it creates the conversation, enqueues the initial task, and returns the new conversationId immediately. The sibling session runs in the background.
 2. The initial task should provide clear context and goals since the new session starts with a fresh conversation history.
-3. Use session_status with the returned conversationId to check progress, or session_dispatch to send further messages.`;
+3. Use session_status with the returned conversationId to check progress, or session_dispatch to send further messages.
+4. The new session reports completion to its DIRECT parent automatically. 'parentConversationId' optionally selects that parent; by default it is the calling session.`;
 /** Model-facing description for session_status. */
 export const SESSION_STATUS_DESCRIPTION = `Inspect the progress, run state, and latest activity of sibling conversations created by the orchestrator.
 
@@ -390,8 +393,8 @@ WHEN TO USE THIS:
 
 Usage notes:
 1. When 'conversationId' is provided: returns a compact summary for that specific session, including its run status ('idle', 'running', 'waiting', 'stopped', 'failed'), messageCount, turnCount, lastAssistantSnippet, lastUserSnippet, activeTool, and error (if any).
-2. When 'conversationId' is omitted: returns a summary list of ALL sibling conversations spawned by this orchestrator session.
-3. This tool never returns full transcripts; it returns concise summaries and snippets to keep your context window lean.`;
+2. When 'conversationId' is omitted: returns a summary list of sibling conversations whose direct parent is 'parentConversationId' (the calling session by default).
+3. By default it never returns full transcripts; concise summaries keep your context window lean. Set 'includeOutput' with a conversationId to read the final output from its result file, capped to the last 64Ki characters with an explicit truncation notice.`;
 /** Model-facing description for session_dispatch. */
 export const SESSION_DISPATCH_DESCRIPTION = `Send a message, follow-up instructions, or steering guidance to an existing sibling conversation.
 

package/dist/server/time-zone.d.ts

@@ -0,0 +1,20 @@
+/**
+ * THE CLOCK THIS PROCESS SCHEDULES BY.
+ *
+ * A scheduled task's 「每天 09:00」 is a WALL CLOCK, and the wall clock it means is the one this
+ * process runs on - the machine holding the server. The browser that reads the result may be on a
+ * different clock entirely, so a moment computed here and rendered there says one thing in one place
+ * and another thing in the other.
+ *
+ * The name is the IANA zone rather than an offset, because an offset is ambiguous twice a year: it
+ * does not say whether 「09:00」 is the summer or the winter offset, and a task that drifts by an
+ * hour twice a year is the kind of bug nobody reports.
+ */
+export declare function serverTimeZone(): string;
+/**
+ * The zone's short name for the moment, the way a person would say it: 「GMT+8」, 「UTC」.
+ *
+ * Used in the panel next to a time, so the reader can tell WHICH clock they are looking at without
+ * having to know what 「Asia/Shanghai」 means.
+ */
+export declare function timeZoneLabel(at?: number): string;

package/dist/server/time-zone.js

@@ -0,0 +1,32 @@
+/**
+ * THE CLOCK THIS PROCESS SCHEDULES BY.
+ *
+ * A scheduled task's 「每天 09:00」 is a WALL CLOCK, and the wall clock it means is the one this
+ * process runs on - the machine holding the server. The browser that reads the result may be on a
+ * different clock entirely, so a moment computed here and rendered there says one thing in one place
+ * and another thing in the other.
+ *
+ * The name is the IANA zone rather than an offset, because an offset is ambiguous twice a year: it
+ * does not say whether 「09:00」 is the summer or the winter offset, and a task that drifts by an
+ * hour twice a year is the kind of bug nobody reports.
+ */
+export function serverTimeZone() {
+    return Intl.DateTimeFormat().resolvedOptions().timeZone || "UTC";
+}
+/**
+ * The zone's short name for the moment, the way a person would say it: 「GMT+8」, 「UTC」.
+ *
+ * Used in the panel next to a time, so the reader can tell WHICH clock they are looking at without
+ * having to know what 「Asia/Shanghai」 means.
+ */
+export function timeZoneLabel(at = Date.now()) {
+    const zone = serverTimeZone();
+    try {
+        const parts = new Intl.DateTimeFormat("en-US", { timeZone: zone, timeZoneName: "shortOffset" }).formatToParts(at);
+        const name = parts.find((part) => part.type === "timeZoneName")?.value;
+        return name ?? zone;
+    }
+    catch {
+        return zone;
+    }
+}

package/dist/server/types.d.ts

@@ -503,6 +503,9 @@ export type Conversation = {
      * not what is true right now.
      */
     modelNotice?: string;
+    /** Why this conversation started on Pi's default agent instead of the workspace's deleted default.
+     *  Written once at birth, like modelNotice, and rendered verbatim. */
+    agentNotice?: string;
     /** Absent means "Pi's own default", which is why a conversation created before the picker existed still works. */
     model?: ModelSelection;
     thinkingLevel?: string;
@@ -885,6 +888,12 @@ export type AppState = {
      * "nothing collapsed", which is the correct reading of a preference that did not exist yet.
      */
     collapsedConversationIds?: string[];
+    /**
+     * THE CLOCK THIS SERVER SCHEDULES BY. A scheduled task's 「每天 09:00」 is the SERVER's wall clock,
+     * and the panel has to say so, because the browser rendering 「下次」 may be on a different clock
+     * entirely. Without this the two lines in one row quietly mean two different things.
+     */
+    serverTimeZone?: string;
 };
 export type TodoItem = {
     id?: string;
@@ -914,6 +923,9 @@ export type OrchestratorSessionSummary = {
     updatedAt: string;
     createdAt?: number;
     lastProgress?: string;
+    output?: string;
+    outputPath?: string;
+    outputTruncated?: boolean;
 };
 /**
  * What Pi reports about ITS OWN queue, forwarded to the browser as it arrives.

package/dist/server/workflow-engine.d.ts

@@ -3,129 +3,45 @@ import type { Store } from "./store.js";
 import type { ModelSelection, ServerEvent } from "./types.js";
 import { type WorkflowPlan, type WorkflowRun } from "./workflow.js";
 /**
- * Walking an orchestrated plan: the half of the feature that DECIDES anything.
- *
- * WHY THIS FILE HOLDS NO SPAWNING, NO STREAMING AND NO PROCESS TEARDOWN. Every one of those already
- * exists and is already proved - `subagents.ts` spawns and drains, `subagent-runs.ts` records and
- * publishes. The engine's whole job is to call `dispatch` in the right ORDER and decide what to do when
- * a step does not succeed, and `SubagentRunRecorder.dispatch` is the seam that makes that possible: it
- * ALWAYS RESOLVES with a settled record, including for a dispatch that never started (`subagent-runs.ts:159`).
- * So an engine step is `await` one call, read `status` off the record, and move on. There is no error
- * parsing here, no exception handling around a spawn, and no way for a child to be left running because
- * the thing above it threw - which is the entire reason this feature is small.
- *
- * WHAT THE ENGINE IS NOT ALLOWED TO DO, stated as the two rules it is built around:
- *
- * 1. IT DOES NOT DECIDE WHAT A STEP MEANS. `role` is written through to the run record and read by
- *    nobody in this process. A step that says "verify" and a step that says "look at it" execute the same
- *    way. The rules about who does what live in `agents/*.md` and in the model that wrote the plan, not
- *    in a dispatcher holding a table of role names.
- * 2. IT DOES NOT JUDGE RESULTS. A `verifier` step that completes with 结论：失败 has SUCCEEDED, as far as
- *    this loop is concerned, and the plan advances. The verdict lives in the text, and the component that
- *    can read the text - the primary agent - is what decides whether to run another round. A server that
- *    parsed 通过/失败 would be guessing at a convention `verifier.md` states in prose and `scout.md` and
- *    `critic.md` do not have at all, and would have no correct answer when the text said neither.
+ * Recursive descent over the primary's plan. This engine owns execution order and the mechanical `until`
+ * comparison; it does not infer tasks, discover foreach items, or ask a child whether another round should
+ * run. Spawning, streaming and teardown remain behind `SubagentRunRecorder.dispatch`, which always resolves
+ * with a settled record.
  */
-/** What the engine needs from the server around it. Injected, so this file holds no globals. */
 export type WorkflowEngineHooks = {
     store: Store;
-    /** Publishes one event to whoever is listening. A plain function, so a test can pass an array. */
     broadcast: (event: ServerEvent) => void;
 };
-/** Everything one plan needs to run. The plan itself arrives already validated and normalized. */
 export type WorkflowRunInput = {
     conversationId: string;
-    /** The dispatching conversation's workspace, resolved by the caller. Never defaulted to the server's own directory. */
     cwd: string;
     plan: WorkflowPlan;
     model?: ModelSelection;
-    /** Tools the primary agent denied, inherited by every step, exactly as a single dispatch inherits them. */
     denyTools?: readonly string[];
-    /** Cancels the whole plan. Each step is dispatched under it, so one signal reaches the loop and the child. */
     signal?: AbortSignal;
 };
-/** The outcome of a plan, as the endpoint reports it. Always produced, never thrown. */
 export type WorkflowOutcome = {
     workflow: WorkflowRun;
 };
 export declare class WorkflowEngine {
     private readonly recorder;
     private readonly hooks;
-    /**
-     * One controller per in-flight plan.
-     *
-     * NEEDED SEPARATELY FROM THE RECORDER'S, and the difference is what stops a plan between steps. The
-     * recorder's map only holds runs that are executing right now, so a plan halted by a signal while no
-     * child is out would have nothing to abort and would happily start the next one. This map holds the
-     * PLAN, which exists for its whole length, so `stop` reaches it in every phase.
-     */
     private readonly controllers;
+    private readonly owners;
     constructor(recorder: SubagentRunRecorder, hooks: WorkflowEngineHooks);
-    /**
-     * Stops ONE plan, and says whether there was anything to stop.
-     *
-     * `false` for an unknown or already-finished id is deliberate and matches `SubagentRunRecorder.stop`:
-     * the click that produces it raced the plan's own terminal event, and an error reply would put a
-     * failure banner on a timeline that says it finished normally.
-     *
-     * The abort reaches the child too, because every step is dispatched under this controller's signal and
-     * `dispatch` turns it into the same abort-then-killTree the recorder uses. Stopping a plan really does
-     * stop the process it is on.
-     */
     stop(workflowId: string): boolean;
-    /** Stops every plan in flight for one conversation, and returns how many were signalled. */
     stopConversation(conversationId: string): number;
-    /** Aborts every plan in flight. Called on shutdown, so no child outlives the server that owns it. */
     abortAll(): void;
-    /** Waits until aborted plans have committed their terminal state. */
     waitForIdle(): Promise<void>;
-    /** The conversation a plan belongs to, which only this map knows while the plan is running. */
     private conversationOf;
-    /**
-     * Which conversation each in-flight plan belongs to.
-     *
-     * Held beside the controllers rather than read back from the store, because the store is the right
-     * place for what a person may read later and the wrong place for a synchronous lookup in a stop
-     * handler - it clones the entire state, and this runs on a click.
-     */
-    private readonly owners;
-    /**
-     * Executes one plan to a terminal state, and returns the record as it ended.
-     *
-     * ALWAYS RESOLVES, like `dispatch` does and for the same reason: by the time the first await runs, the
-     * whole plan is already on disk, so the honest account of a plan that cannot proceed is a record that
-     * says why, rather than a rejection that leaves it claiming to be running until the next restart.
-     */
     run(input: WorkflowRunInput): Promise<WorkflowOutcome>;
-    /**
-     * Runs one step until it succeeds, is skipped, or stops the plan. Returns whether the PLAN should halt.
-     *
-     * The retry is a loop rather than a recursive call so the bound in the policy is the loop's own
-     * condition and cannot be exceeded by a bug in the call structure - the one property a retry policy has
-     * to have absolutely.
-     */
+    /** Allocates execution rows once per statically known occurrence; loop occurrences are allocated per round. */
+    private materializeNodes;
+    private runNodes;
+    private runLoop;
+    private runForeach;
     private runStep;
-    /**
-     * Marks every step from `from` onward as stopped, because none of them will run.
-     *
-     * LEAVING THEM `pending` WOULD BE A LIE IN THE SPECIFIC DIRECTION THAT MATTERS: a browser renders
-     * "未开始" for a pending step, so a plan that died after step one of three would show three steps with
-     * two still waiting, and a person would reasonably expect the rest to happen. They will not.
-     */
     private haltRemaining;
-    /**
-     * Persists a plan, THEN announces it.
-     *
-     * PERSIST FIRST, ANNOUNCE SECOND, and the order is load-bearing here for exactly the reason it is in
-     * `SubagentRunRecorder.settle`: a browser that is told a step finished while `state.json` still says it
-     * is running will show a timeline a reload immediately contradicts, and the startup reconciliation that
-     * would fix it runs on a SERVER restart, not a page refresh.
-     *
-     * Unlike the recorder, this AWAITS both halves rather than writing fire-and-forget, and that is not an
-     * inconsistency. The recorder cannot await: it publishes on every text delta, and a drain loop that
-     * flushed to disk per token would throttle the child it is streaming. This publishes twice per step -
-     * at most sixteen times for a whole plan - so awaiting costs nothing measurable and buys the strong
-     * version of the guarantee.
-     */
+    /** Persist first, announce second, so a reload never contradicts an event already shown. */
     private commit;
 }