teapot-coding-agent 0.27.0 → 0.27.2

package/dist/agent/agent.js

@@ -439,7 +439,26 @@ export class Agent {
      * (#59) — the same trap #38 documented for editing history.
      */
     isLive() {
-        return this.status === "running" || this.parkedByTool || this.pendingPrompts.length > 0;
+        // #127: a MANUAL compaction on an idle agent was rewriting `messages` — a
+        // large, non-cancellable operation — while `isLive()` reported false, so the
+        // UI offered "start".
+        //
+        // #133: and the reverse — after a STOP with prompts still queued, `live` stayed
+        // true forever, so the controls kept offering "stop" for an agent that was
+        // already stopped, and no amount of reloading helped. Measured:
+        //
+        //   after stop : status = stopped   live = true   pendingPrompts = 1
+        //
+        // A queued prompt is not work in progress: it is waiting for the operator to
+        // press start. #9 settled that a stop must neither deliver nor silently
+        // DISCARD those prompts, so they are kept — but keeping them must not make the
+        // agent read as running. A stop outranks them.
+        if (this.stopRequested)
+            return false;
+        return (this.status === "running" ||
+            this.parkedByTool ||
+            this.pendingPrompts.length > 0 ||
+            this.compactPhase !== "");
     }
     /**
      * A background shell (bash background=true) finished. Two channels:
@@ -2927,14 +2946,40 @@ export class Agent {
     }
     /** Ask the model for dense continuation notes over the compacted range. */
     async summarize(old, onDelta) {
-        const transcript = old
+        const full = old
             .map((m) => {
             const who = m.role === "tool" ? "tool" : m.role;
             const tc = m.tool_calls?.map((t) => `\n[calls ${t.function.name}(${t.function.arguments})]`).join("");
             return `${who}: ${m.content ?? ""}${tc}`;
         })
-            .join("\n\n")
-            .slice(-120_000);
+            .join("\n\n");
+        // #127: this was a bare `.slice(-120_000)` — the TAIL only.
+        //
+        // The question the issue raises is the right one: when a compaction starts,
+        // the context window opens dramatically, and the summarizer saw only the last
+        // 120k characters of what it was asked to summarise. Anything older was not
+        // summarised and not kept — it was silently DISCARDED. So the original user
+        // requirement, which sits at the very front of the history, was the single
+        // most likely thing to be lost, and losing it is the one failure compaction
+        // cannot recover from: the summary is now the only record.
+        //
+        // Head + tail, with the seam marked so the model can tell a gap from a
+        // boundary. The head is where the goal, the constraints and the original ask
+        // live; the tail is where the recent state and any in-flight error do.
+        const BUDGET = 120_000;
+        const HEAD = Math.floor(BUDGET * 0.35);
+        const TAIL = BUDGET - HEAD;
+        let transcript;
+        if (full.length <= BUDGET) {
+            transcript = full;
+        }
+        else {
+            transcript = [
+                full.slice(0, HEAD),
+                `\n\n[... ${full.length - BUDGET} characters elided from the middle of this history ...]\n\n`,
+                full.slice(full.length - TAIL),
+            ].join("");
+        }
         const fn = this.opts.chatFn ?? chat;
         // Structured sections (Claude Code style): fixed headings survive MULTIPLE
         // successive compactions far better than free-form prose — each pass knows

package/dist/agent/tools.js

@@ -1664,11 +1664,14 @@ export const TOOLS = [
     },
     {
         name: "message_agent",
-        description: "Send a message to a specific sub-agent (steer it mid-flight or answer its ask_user question).",
+        description: "Send a message to another agent. Use it to steer a sub-agent mid-flight, to answer its " +
+            "ask_user question, or to message your OWN PARENT (pass its id) — a sub-agent may ask its " +
+            "parent a question or hand back a partial result, which is how you report progress without " +
+            "ending your turn. You may NOT message a sibling or an unrelated agent.",
         parameters: {
             type: "object",
             properties: {
-                id: { type: "string", description: "sub-agent id" },
+                id: { type: "string", description: "sub-agent id, or your parent's id" },
                 text: { type: "string" },
             },
             required: ["id", "text"],

package/dist/master.js

@@ -16,6 +16,8 @@ import { bus } from "./bus.js";
 import { fetchModelList, contextLengthFor, isReasoningEffort, } from "./model-meta.js";
 /** how deep sub-agent spawning may nest (parent=0, its subs=1, …) */
 const MAX_SPAWN_DEPTH = 3;
+/** statuses that mean a child has finished working, for #130 */
+const SETTLED = new Set(["idle", "stopped", "waiting", "error"]);
 /**
  * Skills shipped with the package — resolved relative to this module so it
  * works from a global `npm install -g` install, an npx cache, or a repo
@@ -259,6 +261,14 @@ export class Master {
     replacementPid = null;
     tasks = [];
     childWaiters = new Map();
+    /**
+     * Children that have actually started, for #130.
+     *
+     * A child is `idle` between `addAgent` and `start()`, and that is its FIRST
+     * status transition — so without this the parent is told a brand-new sub-agent is
+     * idle before it has done anything.
+     */
+    reportedRunning = new Set();
     startedAt = Date.now();
     config;
     configPath;
@@ -543,8 +553,27 @@ export class Master {
             // the waiter re-checks whether ITS targets are all settled, so waking on
             // every movement is correct and cheap
             this.wakeParentWaiters(ac.parent);
-            if (status === "idle" || status === "stopped" || status === "waiting" || status === "error")
+            // #130: only report a SETTLED child, never its birth.
+            //
+            // A freshly spawned child is `idle` for a moment before `start()` runs, and
+            // the FIRST status transition it ever makes is therefore idle->running via
+            // that idle. Reporting it told the parent "[harness] @kid is now idle" the
+            // instant the child existed — before it had done anything at all. Measured:
+            // transitions after a spawn are ["idle","running","idle"], so the first is
+            // always the spurious one.
+            //
+            // So the message waits for a child that has actually STARTED. A real
+            // completion still reports (it goes running -> idle), and the wake above is
+            // unconditional, so `wait_children` is unaffected either way.
+            // #130: a spawned child is `idle` until start() runs, and that lazy-load
+            // flip is its FIRST transition — so requiring a prior `running` is what stops
+            // the parent being told the child settled before it began.
+            if (this.reportedRunning.has(agentId) && SETTLED.has(status))
                 parent.enqueuePrompt(`[harness] @${agentId} is now ${status}. Continue your task, or finish() if the work is done.`, "harness");
+            if (status === "running")
+                this.reportedRunning.add(agentId);
+            else if (SETTLED.has(status))
+                this.reportedRunning.delete(agentId);
         };
         // sub-agent management hooks — only when this agent can legally spawn
         if (myDepth < this.maxSpawnDepth()) {
@@ -810,8 +839,32 @@ When this task is done (or truly blocked), call finish() with a summary for @${p
         const owned = this.sessionById(childId);
         if (owned)
             targetId = owned.agentId;
-        const cfg = this.config.agents.find((a) => a.id === targetId);
-        if (!cfg || cfg.parent !== parentId) {
+        // #132: a sub-agent must be able to message its OWN PARENT.
+        //
+        // The rule below only ever permitted parent -> child, so a child asking its
+        // parent a question was refused with the actively misleading
+        //
+        //     not your sub-agent: p1. no such sub-agent exists.
+        //
+        // — naming the parent as nonexistent, when it is the caller's own parent and
+        // plainly listed in config.agents. The parent link is the trust boundary: a
+        // child may address its parent, a parent may address its children, and
+        // NOTHING may address a sibling or an unrelated agent.
+        const caller = this.config.agents.find((a) => a.id === parentId);
+        const target = this.config.agents.find((a) => a.id === targetId);
+        const childToParent = target?.parent === parentId;
+        if (target && caller?.parent === targetId) {
+            const p = this.agents.get(targetId);
+            if (!p)
+                throw new Error(`sub-agent not running: ${targetId}`);
+            // mirrored wording, so the recipient knows who is writing
+            p.enqueuePrompt(`[harness] Message from sub-agent @${parentId}:\n\n${text}`, "harness");
+            if (p.status !== "running")
+                p.start(`message from sub-agent ${parentId}`);
+            return;
+        }
+        const cfg = target;
+        if (!cfg || (!childToParent && cfg.parent !== parentId)) {
             // Scoping is correct — only the DIRECT parent may message a child, so a
             // grandchild is rightly refused. But "not your sub-agent: <id>" reads
             // like a bug when the agent simply guessed the wrong level of the tree.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "teapot-coding-agent",
-  "version": "0.27.0",
+  "version": "0.27.2",
   "description": "A lightweight, always-on multi-agent harness for AI coding agents",
   "type": "module",
   "license": "AGPL-3.0-or-later",