loopengine 0.0.21 → 0.1.2

package/dist/core/session-store.js

@@ -75,11 +75,13 @@ function hasUnresolvedToolCall(message) {
         Array.isArray(message.content) &&
         message.content.some((block) => block.type === 'tool_use'));
 }
+// Exported so resumeAgent (run-agent.ts) can strip this exact message
+// back out when it turns out the "interruption" wasn't a crash at all —
+// see that constant's own doc comment for why the two can't be told
+// apart at the point sessionknit's own resume() runs.
+export const CRASH_RECOVERY_CONTINUATION = '[session resumed after an interruption — the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]';
 function buildContinuation() {
-    return {
-        role: 'user',
-        content: '[session resumed after an interruption — the assistant had requested tool calls but the process stopped before any results were recorded; treat those tools as not having run]',
-    };
+    return { role: 'user', content: CRASH_RECOVERY_CONTINUATION };
 }
 /** Wraps a SessionKnit log behind the flat load/run/append contract
  * runAgent's callers use. Shared by both the file- and Redis-backed

package/dist/core/system-skills/system-skills/composio-large-outputs/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: composio-large-outputs
+description: How to retrieve a gateway tool's real output when its result says storedInFile is true instead of returning the data inline.
+---
+
+# Gateway tools with a large result
+
+Some gateway tools (Composio-sourced ones in particular) return a small
+pointer object instead of their real output when the actual result is
+too large to return inline:
+
+```
+{
+  "successful": true,
+  "storedInFile": true,
+  "tokenCount": 10234,
+  "outputFilePath": "/tmp/.../SOME_TOOL_OUTPUT_xxxxx.json"
+}
+```
+
+When you see `storedInFile: true` in a tool result, the real data is
+**not** in that object — it's in the file at `outputFilePath`. Call
+`system_read_file` with that exact path to retrieve the actual content
+before answering. Don't guess at an answer, summarize from the pointer
+alone, or claim you don't have the data — read the file first.

package/dist/core/system-tools/ask_user.d.ts

@@ -1,20 +1,75 @@
-import type { ToolDefinition } from '../agent-config.js';
-export interface PendingQuestion {
-    id: string;
-    question: string;
-    /** Suggested answers, if the model gave any — never the only allowed
-     * answer, a human can still type free text either way (see
-     * answerQuestion, which takes any string). */
-    options?: string[];
-    /** Which agent raised this — always known (config.name), so listing can
-     * always at least be scoped per-agent even without a session id. */
-    agent: string;
-    /** Which conversation raised this, if the caller has one (see
-     * RunAgentOptions.sessionId's own doc comment for when it doesn't) —
-     * lets listQuestions scope down to exactly one conversation instead of
-     * every question raised by this agent, or this whole process. */
-    sessionId?: string;
-    requestedAt: string;
+import type { DurableQuestionHandler, LiveQuestionHandler, PendingQuestion, QuestionHandler, ToolDefinition } from '../agent-config.js';
+export type { PendingQuestion } from '../agent-config.js';
+/** The live-side sibling of the webhook-backed `DurableQuestionHandler`
+ * (`core/http-notify-triggers/webhook.ts`'s `WebhookNotifier`) — same
+ * relationship actauth's own `WebchatApprover` has to `WebhookApprover`:
+ * this one holds the actual `Promise` open and resolves it directly, no
+ * webhook, no `pendingId` handed back to a durable resolve route. Named
+ * to match `WebchatApprover`'s own shape (a `pending` map, `requestX()`,
+ * `list()`, `decide()`) even though the underlying registration/timeout
+ * logic already existed here before this class did — this just gives it
+ * an instantiable, testable home instead of leaving it as bare
+ * module-level state.
+ *
+ * One real, deliberate difference from `WebchatApprover`: `onPending` is
+ * taken per-call (an argument to `requestQuestion`), not baked in at
+ * construction. `WebchatApprover` gets a *fresh instance per turn* precisely
+ * so each one's constructor-time `onPending` can target that turn's own
+ * SSE connection (see web/web-approver.ts's createTrackedApprover) — but
+ * a question only ever needs *one* registry, unlike approvals (see the
+ * default instance below): `onPending` here is just an optional extra
+ * notification layered on top of registration, not a routing key, so
+ * every question is answerable via `decide()`/`list()` on this same
+ * instance regardless of whether anything was listening for `onPending`
+ * when it was raised. A caller that genuinely wants per-turn isolation
+ * (its own registry, not sharing the default one) can still construct
+ * its own `WebchatQuestionHandler` instance directly. */
+export declare class WebchatQuestionHandler implements LiveQuestionHandler {
+    private readonly pending;
+    private readonly timeoutMs;
+    constructor(options?: {
+        timeoutMs?: number;
+    });
+    /** Registers a pending question and returns a Promise that resolves
+     * once `decide()` is called with its id (or the timeout sentinel, if
+     * nobody does). `onPending`, when given, fires synchronously with the
+     * full entry — see this class's own doc comment for why that's a
+     * per-call argument, not a constructor option. */
+    requestQuestion(question: string, options: string[] | undefined, agent: string, sessionId: string | undefined, onPending?: (question: PendingQuestion) => void): Promise<string>;
+    /** Oldest first, same ordering reasoning web/web-approver.ts's
+     * listApprovals uses. Unfiltered (both omitted) returns every question
+     * pending on this instance — real uses (an operator's own admin view,
+     * say) should filter, since that's every conversation's questions
+     * mixed together. */
+    list(filter?: {
+        agent?: string;
+        sessionId?: string;
+    }): PendingQuestion[];
+    /** Peek at a pending question's own entry without answering it — same
+     * "look before you decide" reasoning web/web-approver.ts's findApproval
+     * exists for. */
+    find(id: string): PendingQuestion | undefined;
+    /** Returns false for an unknown/already-answered/timed-out id, so the
+     * caller can report that distinctly (a 404) instead of silently
+     * no-opping — same convention web/web-approver.ts's decideApproval
+     * uses. */
+    decide(id: string, answer: string): boolean;
+}
+/** The cli-channel default — blocks on the terminal it's already attached
+ * to, same fallback actauth's own `ConsoleApprover` is for a permission
+ * ask with nowhere else to go. Unlike `WebchatQuestionHandler`, this needs
+ * no `pending` map, no `list()`/`decide()`: nothing outside this one call
+ * ever answers it — the terminal that asked is the terminal that
+ * answers, synchronously, in the same `rl.question()`. `agent`/
+ * `sessionId`/`onPending` are accepted (not just `question`/`options`)
+ * purely so this has the same call shape `WebchatQuestionHandler.requestQuestion`
+ * does — a caller (createAskUserTool below) doesn't need to know which
+ * kind of questionHandler it's holding, it just calls `requestQuestion` either
+ * way — but none of the three do anything here: there's no registry to
+ * tag with `agent`/`sessionId`, and no separate channel to push
+ * `onPending` onto besides the prompt itself. */
+export declare class CliQuestionHandler implements LiveQuestionHandler {
+    requestQuestion(question: string, options: string[] | undefined): Promise<string>;
 }
 /** Builds the ask_user ToolDefinition for one runAgent() call.
  *
@@ -28,14 +83,21 @@ export interface PendingQuestion {
  * onEvent forwards straight onto that turn's SSE connection — see
  * playground.ts's own inline card for it) finds out immediately instead
  * of having to poll listQuestions(). It's a notification only, not a
- * routing key: the question is registered in the same shared
- * questionsById either way, so answerQuestion() works regardless of
- * whether anything was listening for onPending in the first place.
+ * routing key: the question is registered on the same shared
+ * WebchatQuestionHandler instance either way, so answerQuestion() works
+ * regardless of whether anything was listening for onPending in the
+ * first place.
  *
  * Omitted entirely (a plain CLI run, or any caller with no live channel
- * of its own) falls back to a blocking terminal prompt instead of a
- * pending entry nothing could ever answer — same reasoning
- * ConsoleApprover exists for permission asks with nowhere else to go.
+ * of its own) falls back to CliQuestionHandler's blocking terminal
+ * prompt instead of a pending entry nothing could ever answer — same
+ * reasoning ConsoleApprover exists for permission asks with nowhere else
+ * to go. adapters/cli.ts passing `channel: 'cli'` but no `onQuestionPending`
+ * is exactly this case — the cli channel's real default, in other words,
+ * even though nothing threads `options.channel` through to this
+ * function directly (it doesn't need to: the *presence* of `onPending`
+ * already is that signal, one level up in run-agent.ts's own
+ * RunAgentOptions.onQuestionPending doc comment).
  *
  * Named `system_ask_user`, not the bare `ask_user` an agent author would
  * naturally reach for on their own — see system-tools/read_file.ts's own
@@ -52,11 +114,9 @@ export declare function createAskUserTool(context: {
     agent: string;
     sessionId?: string;
 }, onPending?: (question: PendingQuestion) => void): ToolDefinition;
-/** Oldest first, same ordering reasoning web/web-approver.ts's listApprovals
- * uses — whichever question has been waiting longest surfaces first.
- * Unfiltered (both omitted) returns every question pending anywhere in
- * this process — real uses (an operator's own admin view, say) should
- * filter, since that's every conversation's questions mixed together. */
+/** Thin wrapper over the default WebchatQuestionHandler's own list() — see
+ * that class's own doc comment for why one shared instance, not a fresh
+ * one per call, is the right default for questions. */
 export declare function listQuestions(filter?: {
     agent?: string;
     sessionId?: string;
@@ -66,7 +126,13 @@ export declare function listQuestions(filter?: {
  * calling answerQuestion() below, to know which turn's early-return race
  * (see its own sessionTurns) to resume once this one's answered. */
 export declare function findQuestion(id: string): PendingQuestion | undefined;
-/** Returns false for an unknown/already-answered/timed-out id, so the
- * caller can report that distinctly (a 404) instead of silently
- * no-opping — same convention web/web-approver.ts's decideApproval uses. */
+/** Thin wrapper over the default WebchatQuestionHandler's own decide(). */
 export declare function answerQuestion(id: string, answer: string): boolean;
+/** Duck-types on the one method DurableQuestionHandler actually needs —
+ * same "no eval, just an explicit structural check" spirit as actauth's
+ * own isDurableApprover, which this mirrors: run-agent.ts's loop calls
+ * this on the resolved QuestionHandler (see RunAgentOptions.questionHandler's
+ * own doc comment) to decide which branch a system_ask_user call takes,
+ * the same way Gate uses isDurableApprover to decide which branch a
+ * gated tool call takes. */
+export declare function isDurableQuestionHandler(questionHandler: QuestionHandler): questionHandler is DurableQuestionHandler;

package/dist/core/system-tools/ask_user.js

@@ -1,7 +1,7 @@
 // The system ask_user tool (see this folder's own index.ts, and
 // run-agent.ts's tools merge) — lets a model pause mid-turn and ask the
 // human operator a genuinely ambiguous question instead of guessing, the
-// same reasoning WebApprover exists for permission 'ask' decisions
+// same reasoning WebchatApprover exists for permission 'ask' decisions
 // (web/web-approver.ts), just generalized from a fixed allow/deny to an open
 // answer. No companion skill the way read_file has
 // system-skills/composio-large-outputs — that skill exists to bridge an
@@ -18,30 +18,127 @@
 // same reasoning applied to approvals.
 import { randomUUID } from 'node:crypto';
 import { createInterface } from 'node:readline/promises';
-// One shared, global registry — unlike WebApprover's pending approvals
-// (split across a shared instance and a fresh one per streamed turn, so
-// each turn's onPending can target its own SSE connection), a question
-// only ever needs *one* place to live: onPending here is just an optional
-// extra notification layered on top, not a routing key, so every
-// question — from any call, streamed or not — is always answerable via
-// answerQuestion()/listQuestions() below regardless of how it was raised.
-const questionsById = new Map();
 const DEFAULT_TIMEOUT_MS = 5 * 60_000;
-/** Blocking terminal prompt — the same fallback actauth's own
- * ConsoleApprover uses for a permission ask with nowhere else to go
- * (see createAskUserTool below for when this applies). */
-async function promptOnConsole(question, options) {
-    console.log(`\n[ask_user] ${question}`);
-    if (options?.length)
-        console.log(`  options: ${options.join(', ')}`);
-    const rl = createInterface({ input: process.stdin, output: process.stdout });
-    try {
-        return (await rl.question('> ')).trim();
+/** The live-side sibling of the webhook-backed `DurableQuestionHandler`
+ * (`core/http-notify-triggers/webhook.ts`'s `WebhookNotifier`) — same
+ * relationship actauth's own `WebchatApprover` has to `WebhookApprover`:
+ * this one holds the actual `Promise` open and resolves it directly, no
+ * webhook, no `pendingId` handed back to a durable resolve route. Named
+ * to match `WebchatApprover`'s own shape (a `pending` map, `requestX()`,
+ * `list()`, `decide()`) even though the underlying registration/timeout
+ * logic already existed here before this class did — this just gives it
+ * an instantiable, testable home instead of leaving it as bare
+ * module-level state.
+ *
+ * One real, deliberate difference from `WebchatApprover`: `onPending` is
+ * taken per-call (an argument to `requestQuestion`), not baked in at
+ * construction. `WebchatApprover` gets a *fresh instance per turn* precisely
+ * so each one's constructor-time `onPending` can target that turn's own
+ * SSE connection (see web/web-approver.ts's createTrackedApprover) — but
+ * a question only ever needs *one* registry, unlike approvals (see the
+ * default instance below): `onPending` here is just an optional extra
+ * notification layered on top of registration, not a routing key, so
+ * every question is answerable via `decide()`/`list()` on this same
+ * instance regardless of whether anything was listening for `onPending`
+ * when it was raised. A caller that genuinely wants per-turn isolation
+ * (its own registry, not sharing the default one) can still construct
+ * its own `WebchatQuestionHandler` instance directly. */
+export class WebchatQuestionHandler {
+    pending = new Map();
+    timeoutMs;
+    constructor(options = {}) {
+        this.timeoutMs = options.timeoutMs ?? DEFAULT_TIMEOUT_MS;
+    }
+    /** Registers a pending question and returns a Promise that resolves
+     * once `decide()` is called with its id (or the timeout sentinel, if
+     * nobody does). `onPending`, when given, fires synchronously with the
+     * full entry — see this class's own doc comment for why that's a
+     * per-call argument, not a constructor option. */
+    requestQuestion(question, options, agent, sessionId, onPending) {
+        const id = randomUUID();
+        const entry = { id, question, options, agent, sessionId, requestedAt: new Date().toISOString() };
+        return new Promise((resolve) => {
+            const timer = setTimeout(() => {
+                this.pending.delete(id);
+                resolve('(no answer — timed out)');
+            }, this.timeoutMs);
+            this.pending.set(id, { entry, resolve, timer });
+            onPending?.(entry);
+        });
+    }
+    /** Oldest first, same ordering reasoning web/web-approver.ts's
+     * listApprovals uses. Unfiltered (both omitted) returns every question
+     * pending on this instance — real uses (an operator's own admin view,
+     * say) should filter, since that's every conversation's questions
+     * mixed together. */
+    list(filter) {
+        return [...this.pending.values()]
+            .map((p) => p.entry)
+            .filter((q) => (!filter?.agent || q.agent === filter.agent) && (!filter?.sessionId || q.sessionId === filter.sessionId))
+            .sort((a, b) => a.requestedAt.localeCompare(b.requestedAt));
+    }
+    /** Peek at a pending question's own entry without answering it — same
+     * "look before you decide" reasoning web/web-approver.ts's findApproval
+     * exists for. */
+    find(id) {
+        return this.pending.get(id)?.entry;
     }
-    finally {
-        rl.close();
+    /** Returns false for an unknown/already-answered/timed-out id, so the
+     * caller can report that distinctly (a 404) instead of silently
+     * no-opping — same convention web/web-approver.ts's decideApproval
+     * uses. */
+    decide(id, answer) {
+        const entry = this.pending.get(id);
+        if (!entry)
+            return false;
+        clearTimeout(entry.timer);
+        this.pending.delete(id);
+        entry.resolve(answer);
+        return true;
     }
 }
+// One shared, global instance — unlike WebchatApprover's pending approvals
+// (split across a shared instance and a fresh one per streamed turn),
+// createAskUserTool below always registers into this same one regardless
+// of which call raised it, so every question is always answerable via
+// the module-level listQuestions()/answerQuestion()/findQuestion()
+// functions below, whether it came from a streamed turn, the plain
+// route's fallback, or anywhere else — see WebchatQuestionHandler's own doc
+// comment for the full reasoning.
+const defaultQuestionHandler = new WebchatQuestionHandler();
+/** The cli-channel default — blocks on the terminal it's already attached
+ * to, same fallback actauth's own `ConsoleApprover` is for a permission
+ * ask with nowhere else to go. Unlike `WebchatQuestionHandler`, this needs
+ * no `pending` map, no `list()`/`decide()`: nothing outside this one call
+ * ever answers it — the terminal that asked is the terminal that
+ * answers, synchronously, in the same `rl.question()`. `agent`/
+ * `sessionId`/`onPending` are accepted (not just `question`/`options`)
+ * purely so this has the same call shape `WebchatQuestionHandler.requestQuestion`
+ * does — a caller (createAskUserTool below) doesn't need to know which
+ * kind of questionHandler it's holding, it just calls `requestQuestion` either
+ * way — but none of the three do anything here: there's no registry to
+ * tag with `agent`/`sessionId`, and no separate channel to push
+ * `onPending` onto besides the prompt itself. */
+export class CliQuestionHandler {
+    async requestQuestion(question, options) {
+        console.log(`\n[ask_user] ${question}`);
+        if (options?.length)
+            console.log(`  options: ${options.join(', ')}`);
+        const rl = createInterface({ input: process.stdin, output: process.stdout });
+        try {
+            return (await rl.question('> ')).trim();
+        }
+        finally {
+            rl.close();
+        }
+    }
+}
+// The two live-channel defaults — cli gets a blocking prompt, http/
+// http_stream share one live registry — both single, shared instances
+// for the same reason defaultQuestionHandler above is: neither needs
+// per-turn isolation the way WebchatApprover's fresh-instance-per-turn does
+// (see WebchatQuestionHandler's own doc comment).
+const defaultCliQuestionHandler = new CliQuestionHandler();
 /** Builds the ask_user ToolDefinition for one runAgent() call.
  *
  * context identifies *whose* question this is (see PendingQuestion's own
@@ -54,14 +151,21 @@ async function promptOnConsole(question, options) {
  * onEvent forwards straight onto that turn's SSE connection — see
  * playground.ts's own inline card for it) finds out immediately instead
  * of having to poll listQuestions(). It's a notification only, not a
- * routing key: the question is registered in the same shared
- * questionsById either way, so answerQuestion() works regardless of
- * whether anything was listening for onPending in the first place.
+ * routing key: the question is registered on the same shared
+ * WebchatQuestionHandler instance either way, so answerQuestion() works
+ * regardless of whether anything was listening for onPending in the
+ * first place.
  *
  * Omitted entirely (a plain CLI run, or any caller with no live channel
- * of its own) falls back to a blocking terminal prompt instead of a
- * pending entry nothing could ever answer — same reasoning
- * ConsoleApprover exists for permission asks with nowhere else to go.
+ * of its own) falls back to CliQuestionHandler's blocking terminal
+ * prompt instead of a pending entry nothing could ever answer — same
+ * reasoning ConsoleApprover exists for permission asks with nowhere else
+ * to go. adapters/cli.ts passing `channel: 'cli'` but no `onQuestionPending`
+ * is exactly this case — the cli channel's real default, in other words,
+ * even though nothing threads `options.channel` through to this
+ * function directly (it doesn't need to: the *presence* of `onPending`
+ * already is that signal, one level up in run-agent.ts's own
+ * RunAgentOptions.onQuestionPending doc comment).
  *
  * Named `system_ask_user`, not the bare `ask_user` an agent author would
  * naturally reach for on their own — see system-tools/read_file.ts's own
@@ -90,47 +194,42 @@ export function createAskUserTool(context, onPending) {
             const question = String(input.question);
             const options = Array.isArray(input.options) ? input.options.map(String) : undefined;
             if (!onPending)
-                return promptOnConsole(question, options);
-            const id = randomUUID();
-            const entry = { id, question, options, agent: context.agent, sessionId: context.sessionId, requestedAt: new Date().toISOString() };
-            return new Promise((resolve) => {
-                const timer = setTimeout(() => {
-                    questionsById.delete(id);
-                    resolve('(no answer — timed out)');
-                }, DEFAULT_TIMEOUT_MS);
-                questionsById.set(id, { entry, resolve, timer });
-                onPending(entry);
-            });
+                return defaultCliQuestionHandler.requestQuestion(question, options);
+            return defaultQuestionHandler.requestQuestion(question, options, context.agent, context.sessionId, onPending);
         },
     };
 }
-/** Oldest first, same ordering reasoning web/web-approver.ts's listApprovals
- * uses — whichever question has been waiting longest surfaces first.
- * Unfiltered (both omitted) returns every question pending anywhere in
- * this process — real uses (an operator's own admin view, say) should
- * filter, since that's every conversation's questions mixed together. */
+/** Thin wrapper over the default WebchatQuestionHandler's own list() — see
+ * that class's own doc comment for why one shared instance, not a fresh
+ * one per call, is the right default for questions. */
 export function listQuestions(filter) {
-    return [...questionsById.values()]
-        .map((p) => p.entry)
-        .filter((q) => (!filter?.agent || q.agent === filter.agent) && (!filter?.sessionId || q.sessionId === filter.sessionId))
-        .sort((a, b) => a.requestedAt.localeCompare(b.requestedAt));
+    return defaultQuestionHandler.list(filter);
 }
 /** Peek at a pending question's own entry (its agent/sessionId, in
  * particular) without answering it — adapters/http.ts needs this *before*
  * calling answerQuestion() below, to know which turn's early-return race
  * (see its own sessionTurns) to resume once this one's answered. */
 export function findQuestion(id) {
-    return questionsById.get(id)?.entry;
+    return defaultQuestionHandler.find(id);
 }
-/** Returns false for an unknown/already-answered/timed-out id, so the
- * caller can report that distinctly (a 404) instead of silently
- * no-opping — same convention web/web-approver.ts's decideApproval uses. */
+/** Thin wrapper over the default WebchatQuestionHandler's own decide(). */
 export function answerQuestion(id, answer) {
-    const pending = questionsById.get(id);
-    if (!pending)
-        return false;
-    clearTimeout(pending.timer);
-    questionsById.delete(id);
-    pending.resolve(answer);
-    return true;
+    return defaultQuestionHandler.decide(id, answer);
+}
+/** Duck-types on the one method DurableQuestionHandler actually needs —
+ * same "no eval, just an explicit structural check" spirit as actauth's
+ * own isDurableApprover, which this mirrors: run-agent.ts's loop calls
+ * this on the resolved QuestionHandler (see RunAgentOptions.questionHandler's
+ * own doc comment) to decide which branch a system_ask_user call takes,
+ * the same way Gate uses isDurableApprover to decide which branch a
+ * gated tool call takes. */
+export function isDurableQuestionHandler(questionHandler) {
+    return typeof questionHandler.notifyPendingQuestion === 'function';
 }
+// The webhook-backed DurableQuestionHandler that used to live here
+// (WebhookQuestionHandler) moved to core/http-notify-triggers/webhook.ts's
+// WebhookNotifier — merged with the approval-sending side that used to
+// be actauth's own WebhookApprover, since sending a signed webhook POST
+// was never actually approval-specific or question-specific, just
+// under a different header. See that file's own header comment for the
+// full reasoning.

package/dist/core/system-tools/index.d.ts

@@ -1,3 +1,3 @@
 import type { ToolDefinition } from '../agent-config.js';
 export declare const systemTools: ToolDefinition[];
-export { createAskUserTool, listQuestions, answerQuestion, findQuestion, type PendingQuestion } from './ask_user.js';
+export { createAskUserTool, listQuestions, answerQuestion, findQuestion, CliQuestionHandler, WebchatQuestionHandler, isDurableQuestionHandler, type PendingQuestion, } from './ask_user.js';

package/dist/core/system-tools/index.js

@@ -9,4 +9,4 @@
 // re-exported here instead of an instance.
 import { readFile } from './read_file.js';
 export const systemTools = [readFile];
-export { createAskUserTool, listQuestions, answerQuestion, findQuestion } from './ask_user.js';
+export { createAskUserTool, listQuestions, answerQuestion, findQuestion, CliQuestionHandler, WebchatQuestionHandler, isDurableQuestionHandler, } from './ask_user.js';

package/dist/package.json

@@ -0,0 +1,6 @@
+{
+  "type": "module",
+  "imports": {
+    "#*": "./*"
+  }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "loopengine",
-  "version": "0.0.21",
+  "version": "0.1.2",
   "type": "module",
   "description": "Runtime for tool-using AI agents with a transparent ReAct loop.",
   "license": "MIT",
@@ -18,6 +18,7 @@
     "#*": "./*"
   },
   "files": [
+    "dist/package.json",
     "dist/index.js",
     "dist/index.d.ts",
     "dist/bin/cli.js",
@@ -46,21 +47,30 @@
     "dist/core/agent-as-tool.d.ts",
     "dist/core/gateway-tools.js",
     "dist/core/gateway-tools.d.ts",
+    "dist/core/budget.js",
+    "dist/core/budget.d.ts",
+    "dist/core/compaction.js",
+    "dist/core/compaction.d.ts",
+    "dist/core/recovery.js",
+    "dist/core/recovery.d.ts",
+    "dist/core/http-notifier.js",
+    "dist/core/http-notifier.d.ts",
+    "dist/core/http-notify-triggers",
     "dist/core/system-tools",
-    "core/system-skills",
+    "dist/core/system-skills",
     "protocol/loop-event.schema.json",
     "PROTOCOL.md",
     "LICENSE"
   ],
   "scripts": {
-    "build": "tsc; s=$?; chmod +x dist/bin/cli.js; exit $s",
+    "build": "tsc; s=$?; chmod +x dist/bin/cli.js; cp -r core/system-skills dist/core/system-skills; tsx scripts/write-dist-package-json.ts; exit $s",
     "prepublishOnly": "npm run build",
     "start": "node --env-file-if-exists=.env dist/adapters/http.js",
     "test": "vitest run"
   },
   "dependencies": {
     "@anthropic-ai/sdk": "^0.116.0",
-    "actauth": "^0.0.7",
+    "actauth": "^0.0.12",
     "ioredis": "^6.0.0",
     "mcpplug": "^0.0.1",
     "openai": "^7.4.0",

package/protocol/loop-event.schema.json

@@ -11,7 +11,7 @@
     { "$ref": "#/$defs/toolStarted" },
     { "$ref": "#/$defs/toolResult" },
     { "$ref": "#/$defs/toollaneResult" },
-    { "$ref": "#/$defs/skillLoad" },
+    { "$ref": "#/$defs/skillLoaded" },
     { "$ref": "#/$defs/loopSkipped" },
     { "$ref": "#/$defs/loopMaxTurns" },
     { "$ref": "#/$defs/loopDenied" },
@@ -132,7 +132,7 @@
       "additionalProperties": false
     },
 
-    "skillLoad": {
+    "skillLoaded": {
       "type": "object",
       "description": "Engine. A Skill tool_use block was resolved to a real skill body via SkillGarden's own lazy load. Not gated by ActAuth — Skill invocation isn't a real tool call.",
       "required": ["type", "skill"],