@evandu/super-pi 0.1.164 → 0.1.166

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-1hS3wVqF.js"></script>
-    <link rel="stylesheet" crossorigin href="/assets/index-Wtlj0s4R.css">
+    <script type="module" crossorigin src="/assets/index-dARLbQ-8.js"></script>
+    <link rel="stylesheet" crossorigin href="/assets/index-C6YWfUu2.css">
   </head>
   <body>
     <div id="root"></div>

package/dist/server/agents.d.ts

@@ -175,6 +175,16 @@ export interface ResolveAgentDirectoriesOptions {
     env?: NodeJS.ProcessEnv;
     rootDir?: string;
 }
+/**
+ * The agents directory that ships WITH the package: the definitions Super Pi itself carries.
+ *
+ * WHY IT IS A FUNCTION AND NOT A CONSTANT. The package root is not the same directory in every
+ * layout - it is the repository root in a checkout and the installed package root in an npm install
+ * - so the path is derived from the same `rootDir` the discovery uses, and both sides of the
+ * "is this built-in?" question ask THIS function. If the two ever disagreed, a user agent could be
+ * filed as built-in and a built-in one as the user's, and the picker would sort them wrongly.
+ */
+export declare function builtinAgentsDir(rootDir?: string): string;
 /**
  * Resolves the ordered list of directories to discover agents from:
  * 1. Custom directories configured by the user in app settings (or options)
@@ -187,6 +197,7 @@ export interface ResolveAgentDirectoriesOptions {
 export declare function resolveAgentDirectories(options?: ResolveAgentDirectoriesOptions): string[];
 export declare function readAgents(directory: string | readonly string[], options?: {
     mode?: AgentModeFilter;
+    builtinDir?: string;
 }): Promise<AgentScan>;
 /** Parses one definition file, or returns the reason it is not a usable agent. */
 export declare function parseDefinition(file: string, source: string): AgentDefinition | AgentProblem;

package/dist/server/agents.js

@@ -392,6 +392,18 @@ export function expandTilde(filepath) {
     }
     return filepath;
 }
+/**
+ * The agents directory that ships WITH the package: the definitions Super Pi itself carries.
+ *
+ * WHY IT IS A FUNCTION AND NOT A CONSTANT. The package root is not the same directory in every
+ * layout - it is the repository root in a checkout and the installed package root in an npm install
+ * - so the path is derived from the same `rootDir` the discovery uses, and both sides of the
+ * "is this built-in?" question ask THIS function. If the two ever disagreed, a user agent could be
+ * filed as built-in and a built-in one as the user's, and the picker would sort them wrongly.
+ */
+export function builtinAgentsDir(rootDir) {
+    return resolve(join(rootDir ?? resolve(import.meta.dirname, "../.."), "agents"));
+}
 /**
  * Resolves the ordered list of directories to discover agents from:
  * 1. Custom directories configured by the user in app settings (or options)
@@ -433,11 +445,25 @@ export function resolveAgentDirectories(options = {}) {
         catch {
             // homedir() might throw in restricted sandbox environments
         }
-        const root = options.rootDir ?? resolve(import.meta.dirname, "../..");
-        add(join(root, "agents"));
+        add(builtinAgentsDir(options.rootDir));
     }
     return dirs;
 }
+/**
+ * Whether two paths name the same directory.
+ *
+ * WHY THE COMPARISON IS NOT A PLAIN `===`. The paths that reach here were built by joining and
+ * resolving, so they are already absolute - but Windows paths are case-insensitive and a directory
+ * typed by hand (`d:\agents`) is the same directory as the one the app resolved itself
+ * (`D:\Agents`). Comparing them as strings would call the package's own agents directory "the user's"
+ * and put the built-in agents at the bottom of the picker, which is the defect this whole change is
+ * about.
+ */
+function sameDirectory(left, right) {
+    const a = resolve(left);
+    const b = resolve(right);
+    return process.platform === "win32" ? a.toLowerCase() === b.toLowerCase() : a === b;
+}
 export async function readAgents(directory, options = {}) {
     const mode = options.mode ?? "primary";
     const rawDirs = Array.isArray(directory) ? directory : [directory];
@@ -445,6 +471,9 @@ export async function readAgents(directory, options = {}) {
     const agents = [];
     const problems = [];
     const seenIds = new Set();
+    // The directory whose definitions are the PACKAGE'S OWN. Everything else is the user's, and the
+    // two are listed separately so the package's agents can come first (see the sort at the end).
+    const builtinDir = options.builtinDir ?? builtinAgentsDir();
     for (const dir of dirs) {
         let entries;
         try {
@@ -455,6 +484,7 @@ export async function readAgents(directory, options = {}) {
                 continue;
             throw error;
         }
+        const isBuiltin = sameDirectory(dir, builtinDir);
         for (const file of entries.filter((name) => name.toLowerCase().endsWith(".md")).sort()) {
             // A FILE THAT CANNOT BE READ IS THE SAME KIND OF PROBLEM AS ONE THAT CANNOT BE PARSED.
             //
@@ -487,17 +517,31 @@ export async function readAgents(directory, options = {}) {
             else {
                 if (!seenIds.has(parsed.id)) {
                     seenIds.add(parsed.id);
-                    agents.push({ ...parsed, sourceDir: dir });
+                    agents.push({ ...parsed, sourceDir: dir, builtin: isBuiltin });
                 }
             }
         }
     }
     // The half that was NOT asked for is filtered out here rather than marked in the UI: sub-agents are
     // invoked BY an agent and never chosen by a human, so listing one in the picker would promise a role
-    // the runtime cannot honour. The remainder is alphabetical by id, so either roster reads as a list
-    // rather than as a directory listing.
+    // the runtime cannot honour.
+    //
+    // The remainder is the PACKAGE'S OWN agents first, then the user's, each group alphabetical by id.
+    //
+    // WHY THE BUILT-IN GROUP COMES FIRST. The picker used to sort purely by id, which scattered the
+    // package's own agents - the ones drawn with a colour dot - among the user's own with no visible
+    // rule to say which was which. The built-in group is now a group, so the colours read as "these are
+    // the ones that ship with Super Pi" instead of as noise.
+    //
+    // WHY THE GROUP ORDER DOES NOT TOUCH THE OVERRIDE RULE. The rule that decides WHICH definition of
+    // an id survives was applied above, while reading: the first directory to offer an id wins, and the
+    // user's directories are read before the package's own. Sorting here only reorders definitions that
+    // already survived that decision, so a user's copy of a built-in agent still wins - and it is then
+    // listed as the user's, because it IS the user's file.
     return {
-        agents: agents.filter((agent) => agent.mode === mode).sort((a, b) => a.id.localeCompare(b.id)),
+        agents: agents
+            .filter((agent) => agent.mode === mode)
+            .sort((a, b) => (a.builtin === b.builtin ? a.id.localeCompare(b.id) : a.builtin ? -1 : 1)),
         problems,
     };
 }

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

@@ -1,8 +1,39 @@
 import type { Store } from "../store.js";
 import type { Project, ProjectEscalation, ProjectMode, ProjectReport, ProjectRisk, ProjectSummary, ProjectTask, SessionProfile } from "../types.js";
 import type { SessionOrchestratorService } from "./session-orchestrator-service.js";
+/**
+ * WHAT THE PROJECT LEADER IS TOLD WHEN IT STARTS.
+ *
+ * The two prompts are kept apart on purpose. The standard one is the shape the project flow has
+ * always had - decompose, delegate, review. The lightweight one is a different set of
+ * instructions about a different shape: one session, no decomposition, no reviewer. Writing one
+ * prompt with holes in it would mean every sentence had to carry a condition, and the model would
+ * have to work out which shape it was in.
+ *
+ * THE ESCALATION RULE IS SAID ONCE, IN ONE VOICE. The standard leader used to be told two
+ * opposite things about the same event - "your subordinates' escalations come to you first, you
+ * decide whether to handle them yourself or report them up" AND "you must not resolve escalations
+ * yourself" - and a model reading both has no way to pick, so it hesitates between them. The
+ * rule is now one sentence with three parts: handle it at your own level, escalate only what
+ * really needs the Boss, and never decide for the Boss or drop an escalation. The lightweight
+ * leader has no subordinates at all, so it is told the second half only - it must not decide
+ * alone either - and is never told about subordinates it does not have.
+ */
+export declare const STANDARD_LEADER_PROMPT = "\u4F60\u662F\u76F4\u63A5\u5411 Boss \u8D1F\u8D23\u7684\u9879\u76EE Leader\uFF0C\u517C\u4EFB\u79D8\u4E66\u3002\u5148\u8C03\u7528 project(action=get, projectId) \u4E86\u89E3\u6700\u65B0\u72B6\u6001\u3002\u5C0F\u9879\u76EE\u53EA\u62C6\u6700\u5C11\u5FC5\u8981\u4EFB\u52A1\uFF0C\u5927\u9879\u76EE\u6309\u4EA4\u4ED8\u8FB9\u754C\u5206\u5DE5\u3002\u7528 add_task \u767B\u8BB0\u4EFB\u52A1\uFF08\u660E\u786E\u76EE\u6807\u3001\u4EA4\u4ED8\u7269\u3001\u9A8C\u6536\u6807\u51C6\u3001\u4F9D\u8D56\uFF09\uFF1Badd_task / update_task \u65F6\u53EF\u4EE5\u5E26 executorProfile \u4E0E reviewerProfile\uFF08\u652F\u6301\u6307\u5B9A agentId\u3001cwd\u3001model\u3001thinkingLevel\u3001watchdogTimeoutSeconds\uFF09\uFF0C\u6309\u4EFB\u52A1\u6027\u8D28\u5C06\u6267\u884C\u4E0E\u590D\u6838\u59D4\u6D3E\u7ED9\u6700\u5408\u9002\u7684\u5458\u5DE5\uFF0C\u4E0D\u6307\u5B9A\u5219\u7EE7\u627F\u9879\u76EE\u9ED8\u8BA4\uFF1B\u9700\u8981\u7EE7\u7EED\u62C6\u89E3\u7684\u5DE5\u4F5C\u8BBE role=leader\uFF0C\u53F6\u5B50\u6267\u884C\u4EFB\u52A1\u8BBE role=executor\uFF0C\u5B50 Leader \u7528 parentTaskId \u767B\u8BB0\u81EA\u5DF1\u7684\u5B50\u4EFB\u52A1\uFF0Cdispatch \u542F\u52A8\u6267\u884C\u5B50\u4F1A\u8BDD\uFF1B\u4E0D\u8981\u7528 session_spawn/session_dispatch \u6216 task/workflow \u7ED5\u8FC7\u9879\u76EE\u8D44\u6E90\u9650\u5236\u3002\u6536\u5230\u4EA4\u4ED8\u540E\u7528 request_review \u542F\u52A8\u72EC\u7ACB\u590D\u6838\u3002\u5B50\u4F1A\u8BDD\u7ED3\u675F\u4F1A\u81EA\u52A8\u56DE\u62A5\u7ED9\u4F60\uFF0C\u5C4A\u65F6\u7EE7\u7EED\u6D3E\u53D1 ready \u4EFB\u52A1\u3001\u590D\u6838\u5F85\u9A8C\u6536\u4EFB\u52A1\u6216\u6309 review.summary \u8FD4\u5DE5\u3002\u4E0D\u8981\u8F6E\u8BE2\u7B49\u5F85\uFF0C\u4E0D\u8981\u53CD\u590D\u65E0\u8FDB\u5C55\u91CD\u8BD5\uFF0C\u5E76\u53D1\u6EE1\u65F6\u7ED3\u675F\u5F53\u524D\u56DE\u590D\u7B49\u5F85\u56DE\u62A5\u3002\u7528 report \u767B\u8BB0\u5173\u952E\u8FDB\u5C55\u3002\u4F60\u7684\u4E0B\u5C5E\u7684\u5347\u7EA7\u5148\u5230\u4F60\u8FD9\u91CC\uFF1A\u4F60\u5728\u81EA\u5DF1\u8FD9\u4E00\u5C42\u5904\u7406\uFF0C\u80FD\u81EA\u5DF1\u89E3\u51B3\u7684\u81EA\u5DF1\u89E3\u51B3\uFF1B\u53EA\u6709\u786E\u5B9E\u9700\u8981 Boss \u51B3\u7B56\u7684\uFF08\u91CD\u5927\u504F\u5DEE\u3001\u6743\u9650\u6216\u9884\u7B97\u95EE\u9898\uFF09\u624D\u7528 escalate \u4EA4\u7ED9 Boss\u3002\u4F60\u4E0D\u80FD\u66FF Boss \u505A\u51B3\u5B9A\uFF0C\u4E5F\u4E0D\u8981\u628A\u6CA1\u5904\u7406\u7684\u5347\u7EA7\u538B\u4E0B\u53BB\u4E0D\u7406\u3002\u6240\u6709\u4EFB\u52A1\u9A8C\u6536\u540E\uFF0C\u7528 complete \u63D0\u4EA4\u5E26\u8BC1\u636E\u7684\u6700\u7EC8\u4EA4\u4ED8\u603B\u7ED3\u3002\u4E0A\u4E0B\u6587\u6709\u9650\uFF0C\u660E\u786E\u5047\u8BBE\uFF0C\u4E3B\u52A8\u5BFB\u627E\u53CD\u8BC1\u3002\u53EA\u5728\u672C\u6B21\u89E6\u53D1\u8303\u56F4\u5185\u5DE5\u4F5C\u3002";
+export declare const LIGHTWEIGHT_LEADER_PROMPT = "\u4F60\u662F\u76F4\u63A5\u5411 Boss \u8D1F\u8D23\u7684\u9879\u76EE Leader\uFF0C\u8FD9\u662F\u4E00\u4E2A\u8F7B\u91CF\u9879\u76EE\uFF1A\u8FD9\u4E2A\u9879\u76EE\u7531\u4F60\u4EB2\u81EA\u5B8C\u6210\uFF0C\u4E0D\u8981\u62C6\u5B50\u4EFB\u52A1\u3001\u4E0D\u8981\u6D3E\u53D1\u7ED9\u522B\u4EBA\u3001\u4E5F\u6CA1\u6709\u72EC\u7ACB\u590D\u6838\u3002\u5148\u8C03\u7528 project(action=get, projectId) \u4E86\u89E3\u6700\u65B0\u72B6\u6001\u3002\u7528 add_task \u767B\u8BB0\u4EFB\u52A1\uFF08\u660E\u786E\u76EE\u6807\u3001\u4EA4\u4ED8\u7269\u3001\u9A8C\u6536\u6807\u51C6\u3001\u4F9D\u8D56\uFF09\uFF0C\u4EFB\u52A1\u4E00\u5F8B\u767B\u8BB0\u4E3A\u6267\u884C\u4EFB\u52A1\uFF1Arole=leader \u6216\u5E26 parentTaskId \u90FD\u4F1A\u88AB\u62D2\u7EDD\u3002dispatch \u4F1A\u628A\u4EFB\u52A1\u4EA4\u56DE\u7ED9\u4F60\u81EA\u5DF1\uFF0C\u4F60\u4EB2\u81EA\u505A\u5B8C\uFF1B\u505A\u5B8C\u540E\u8C03\u7528 project(action=submit, projectId, taskId, output, evidenceRefs) \u63D0\u4EA4\u4EA4\u4ED8\uFF0C\u63D0\u4EA4\u5373\u5B8C\u6210\uFF0C\u4E0D\u4F1A\u6709\u4EBA\u56DE\u6765\u590D\u6838\uFF0C\u8BC1\u636E\u5FC5\u987B\u9644\u4E0A\u3002\u4E0D\u8981\u7528 session_spawn/session_dispatch \u6216 task/workflow \u7ED5\u8FC7\u9879\u76EE\u8D44\u6E90\u9650\u5236\u3002\u4E0D\u8981\u8F6E\u8BE2\u7B49\u5F85\uFF0C\u4E0D\u8981\u53CD\u590D\u65E0\u8FDB\u5C55\u91CD\u8BD5\u3002\u7528 report \u767B\u8BB0\u5173\u952E\u8FDB\u5C55\uFF0C\u7528 escalate \u5C06\u91CD\u5927\u504F\u5DEE\u3001\u6743\u9650\u6216\u9884\u7B97\u95EE\u9898\u4EA4\u7ED9 Boss\uFF0C\u4E0D\u5F97\u81EA\u884C\u89E3\u51B3\u5347\u7EA7\u4E8B\u9879\u3002\u6240\u6709\u4EFB\u52A1\u4EA4\u4ED8\u540E\uFF0C\u7528 complete \u63D0\u4EA4\u5E26\u8BC1\u636E\u7684\u6700\u7EC8\u4EA4\u4ED8\u603B\u7ED3\u3002\u4E0A\u4E0B\u6587\u6709\u9650\uFF0C\u660E\u786E\u5047\u8BBE\uFF0C\u4E3B\u52A8\u5BFB\u627E\u53CD\u8BC1\u3002\u53EA\u5728\u672C\u6B21\u89E6\u53D1\u8303\u56F4\u5185\u5DE5\u4F5C\u3002";
 export declare const profile: (value: unknown, label: string) => SessionProfile | undefined;
 export declare const mergeProfile: (taskProfile?: SessionProfile, projectDefault?: SessionProfile) => SessionProfile | undefined;
+/**
+ * THE PROJECTS ONE LIST CALL ANSWERS WITH, AND HOW MANY THERE REALLY ARE.
+ *
+ * `projects` is the capped list, newest update first. `total` is how many projects the session
+ * is related to, counted BEFORE the cap, and `returned` is how many of them are in the list.
+ */
+export type ProjectListPage = {
+    projects: ProjectSummary[];
+    total: number;
+    returned: number;
+};
 export type CreateProjectInput = {
     workspaceId: string;
     title: string;
@@ -56,6 +87,7 @@ export declare class ProjectService {
     private readonly queues;
     constructor(store: Store, orchestrator?: (Pick<SessionOrchestratorService, "spawn" | "dispatch"> & Partial<Pick<SessionOrchestratorService, "stopSubtree">>) | undefined);
     static taskView(task: ProjectTask, project: Pick<Project, "defaultExecutorProfile" | "defaultReviewerProfile">): ProjectTask;
+    private filterEscalations;
     private projectView;
     /**
      * THE NUMBER THE ONE-CLICK PATH OFFERS.
@@ -72,6 +104,25 @@ export declare class ProjectService {
     private event;
     private change;
     private live;
+    /**
+     * WAKING THE OTHER SIDE MUST NOT TAKE THE REPORT DOWN WITH IT.
+     *
+     * The report, the escalation or the decision is already written to the store by the time the
+     * other side is woken, so a dispatch that fails - a session that was archived, stopped or never
+     * existed - must NOT fail the request. It would: the caller would be told the whole thing
+     * failed although it succeeded, it would try again, and the same report would be written twice.
+     *
+     * So the wake is wrapped, the failure is written down, and the record is returned as the
+     * success it is.
+     *
+     * AND THE FAILURE IS NOT SILENT. A report nobody was told about is a report nobody will ever
+     * handle, so the project's own timeline gets an event saying exactly that, and the log line
+     * names the project and the escalation so the case can be found again later.
+     */
+    private wake;
+    /** THE TIMELINE SAYS THAT NOBODY COULD BE TOLD. Written after the fact, so it never loses the
+     *  record that was already saved. */
+    private noteUnreachable;
     private leader;
     private topLevelAuthor;
     private manager;
@@ -92,14 +143,54 @@ export declare class ProjectService {
     private requiredComplete;
     private task;
     private member;
+    isMember(p: Project, actor?: string): boolean;
+    directSupervisor(p: Project, actor?: string, taskId?: string): string | undefined;
+    /**
+     * THE PROJECT A SESSION BELONGS TO RIGHT NOW.
+     *
+     * `projectForSession` answers a different question - "which project is this session part of" -
+     * and it counts the finished projects too, because the history of a project has to stay visible
+     * to the people who worked on it. This method answers the narrower question the QUESTION path
+     * needs: "is this session inside a project that is still running".
+     *
+     * WHY THAT DISTINCTION MATTERS. A conversation that took part in a project which has since been
+     * completed is not a project member any more - it is a conversation that happens to have a
+     * finished project in its history. The old lookup mixed the two, so asking the Boss a question
+     * from such a conversation was refused with "a project member may not ask the Boss directly",
+     * which is not what was true: the project was over, and nobody was being bypassed. The finished
+     * project is still found and still visible in the history; it just does not block the question.
+     *
+     * A session that is in a running project AND in a finished one belongs to the running one - it
+     * is the one that is still in charge of it.
+     */
+    private liveProjectForSession;
+    canAskQuestion(conversationId: string): {
+        ok: boolean;
+        reason?: string;
+    };
     private reconcile;
     private resources;
     list(workspaceId?: string): Project[];
-    headline(p: Project): string;
+    headline(p: Project, actor?: string): string;
     private isActorRelated;
     private projectSummary;
-    listForActor(workspaceId: string, actor: string): ProjectSummary[];
-    get(id: string, workspaceId?: string): Project;
+    /**
+     * THE PROJECTS AN ACTOR IS PART OF, AND HOW MANY OF THEM THERE ARE.
+     *
+     * The list is capped, because the list is what goes into an agent's context: a workspace that
+     * has been alive for a year has hundreds of finished projects, and handing all of them over
+     * answers the question "how are my projects doing" with a wall of history. The cap is on the
+     * RECENT ones - the same order the list has always had, newest update first - so what the
+     * agent reads first is what actually changed.
+     *
+     * AND THE COUNT IS TOLD, NOT IMPLIED. `total` is how many projects the session is really
+     * related to, counted BEFORE the cut, and `returned` is how many came back. An agent that sees
+     * total 57 and returned 20 knows the workspace has more history than it was shown, and says so
+     * instead of telling the Boss the workspace only has 20 projects. A silently truncated list
+     * would be a lie the agent could not see through.
+     */
+    listForActor(workspaceId: string, actor: string, limit?: number): ProjectListPage;
+    get(id: string, workspaceId?: string, actor?: string): Project;
     /**
      * THE PROJECT AS A REPORT A HUMAN CAN READ.
      *
@@ -175,7 +266,7 @@ export declare class ProjectService {
     raiseBudgetAndContinue(id: string, workspaceId: string, callerConversationId?: string): Promise<BudgetRaiseResult>;
     addReport(id: string, input: Omit<ProjectReport, "id" | "projectId" | "createdAt">, workspaceId?: string, actor?: string): Promise<ProjectReport>;
     addEscalation(id: string, input: Pick<ProjectEscalation, "reason" | "severity" | "taskId">, workspaceId?: string, actor?: string): Promise<ProjectEscalation>;
-    resolveEscalation(id: string, escalationId: string, decision: string, status: "resolved" | "dismissed", workspaceId?: string): Promise<ProjectEscalation>;
+    resolveEscalation(id: string, escalationId: string, decision: string, status: "resolved" | "dismissed", workspaceId?: string, actor?: string): Promise<ProjectEscalation>;
     complete(id: string, summary: string, evidenceRefs: unknown, workspaceId: string, actor?: string): Promise<Project>;
     /**
      * The tasks an initiator hands over with create. A dependency names the TITLE of another task in