agent-afk 5.15.10 → 5.15.12

package/README.md

@@ -55,7 +55,7 @@ afk chat "hello"
 
 > **Agent AFK Pro:** Autonomous skill-generation (`/forge`) and the calibrated skill-qualification rubric (`/qualify`) are reserved for Agent AFK Pro and are not part of the open-source build.
 - **Cross-session memory** — Claude remembers preferences, decisions, and procedures across runs. See [Memory](#memory) below.
-- **Background subagent jobs** — dispatch a subagent with `mode:'background'`; `/bgsub` lists running and completed jobs, `/bgsub:join <id>` retrieves the result.
+- **Background subagent jobs** — dispatch a subagent with `mode:'background'`; results auto-deliver into the model's context when they finish. `/bgsub` lists running and completed jobs, `/bgsub:join <id>` replays a result manually.
 
 ## Four surfaces, one session manager
 

package/dist/agent/background-registry.d.ts

@@ -45,6 +45,7 @@ export declare class BackgroundAgentRegistry extends EventEmitter<BackgroundRegi
     get(jobId: string): BackgroundJob | undefined;
     list(): readonly BackgroundJob[];
     join(jobId: string): Promise<SubagentResult>;
+    markDelivered(jobId: string): void;
     cancelJob(jobId: string): Promise<boolean>;
     cancelAll(): Promise<void>;
     appendTranscript(jobId: string, chunk: string): void;

package/dist/agent/subagent.d.ts

@@ -32,6 +32,7 @@ export interface SubagentManagerOptions {
     progressSink?: SubagentProgressSink;
     apiKey?: string;
     baseUrl?: string;
+    parentModel?: string;
     cwd?: string;
     traceWriter?: TraceWriter;
     surface?: Surface;
@@ -44,6 +45,7 @@ export declare class SubagentManager {
     private readonly progressSink;
     private readonly parentApiKey;
     private readonly parentBaseUrl;
+    private readonly parentProvider;
     private parentCwd;
     private readonly parentTraceWriter;
     private readonly parentSurface;

package/dist/agent/tools/child-credential.d.ts

@@ -1,3 +1,4 @@
+import { type BundledProviderName } from '../providers/index.js';
 export declare function isAnthropicCredential(key: string | undefined): key is string;
 export declare function applyParentCredentialFallback(args: {
     childModel: string;
@@ -8,4 +9,5 @@ export declare function applyManagerApiKeyFallback(args: {
     childModel: string | undefined;
     configApiKey: string | undefined;
     parentApiKey: string | undefined;
+    parentProvider?: BundledProviderName | undefined;
 }): string | undefined;

package/dist/agent/tools/system-prompt.d.ts

@@ -1,6 +1,9 @@
 export declare const TOOL_SYSTEM_PROMPT_BASE = "You have access to tools for working with the filesystem and running commands. Follow these conventions:\n\n- Use read_file before editing to verify the exact content you want to change.\n- Prefer edit_file over write_file for modifying existing files \u2014 write_file is for new files or complete rewrites.\n- Quote file paths that contain spaces with double quotes.\n- Do not run destructive shell commands (rm -rf, git reset --hard, etc.) unless the user explicitly asks.\n- Use glob and grep to discover files before reading individual files.\n- When bash output is very long, it may be truncated. If you need the full output, redirect to a file and read it.\n- Use absolute paths for file operations.\n- Prefer `agent` (and `skill`) for multi-file investigation, verification, parallel hypotheses, and any work that would otherwise consume large amounts of inline context. The main session is the coordinator; subagents are the investigators.";
 export declare const SLASH_COMMAND_ROUTING_PROMPT = "When you see a `<command-name>` tag in the current conversation turn, the skill has ALREADY been loaded by the user typing a slash command. Do NOT re-invoke the skill tool to dispatch that same skill again. Instead, treat the `<command-message>` as the skill name and `<command-args>` as its arguments, then follow the instructions in the body block immediately following the tag. You MAY still invoke the skill tool to dispatch OTHER skills that are not the one already loaded.";
 export declare const BASH_PASSTHROUGH_PROMPT = "When a user message contains a `<bash-passthrough>` block, it represents a shell command the **user ran directly** in the REPL using the `!` prefix (e.g. `!ls` or `!&pnpm test`). This is distinct from the `bash` tool you invoke yourself:\n\n- `<bash-passthrough>` = human-initiated shell run, output injected into your context automatically\n- `bash` tool result = model-initiated command you explicitly called\n\nAttributes on the opening tag:\n- `mode=\"foreground\"` \u2014 user waited for the command to finish before the next prompt\n- `mode=\"background\"` \u2014 command ran detached (`!&` prefix); output arrives after it completes\n- `exit=\"N\"` \u2014 shell exit code (0 = success)\n- `reason=\"...\"` \u2014 error category when nonzero: `nonzero-exit`, `abort` (Ctrl+C), `timeout`, `overflow`, `spawn-failed`, `signal-killed`\n- `duration=\"1.3s\"` \u2014 wall-clock runtime\n- `truncated=\"true\"` \u2014 output was capped; full output not available\n\nThe `<command>` child contains the literal command the user typed (XML-escaped). The `<output>` child contains ANSI-stripped, XML-escaped captured stdout/stderr.";
-export declare const TOOL_SYSTEM_PROMPT = "You have access to tools for working with the filesystem and running commands. Follow these conventions:\n\n- Use read_file before editing to verify the exact content you want to change.\n- Prefer edit_file over write_file for modifying existing files \u2014 write_file is for new files or complete rewrites.\n- Quote file paths that contain spaces with double quotes.\n- Do not run destructive shell commands (rm -rf, git reset --hard, etc.) unless the user explicitly asks.\n- Use glob and grep to discover files before reading individual files.\n- When bash output is very long, it may be truncated. If you need the full output, redirect to a file and read it.\n- Use absolute paths for file operations.\n- Prefer `agent` (and `skill`) for multi-file investigation, verification, parallel hypotheses, and any work that would otherwise consume large amounts of inline context. The main session is the coordinator; subagents are the investigators.\n\nWhen you see a `<command-name>` tag in the current conversation turn, the skill has ALREADY been loaded by the user typing a slash command. Do NOT re-invoke the skill tool to dispatch that same skill again. Instead, treat the `<command-message>` as the skill name and `<command-args>` as its arguments, then follow the instructions in the body block immediately following the tag. You MAY still invoke the skill tool to dispatch OTHER skills that are not the one already loaded.\n\nWhen a user message contains a `<bash-passthrough>` block, it represents a shell command the **user ran directly** in the REPL using the `!` prefix (e.g. `!ls` or `!&pnpm test`). This is distinct from the `bash` tool you invoke yourself:\n\n- `<bash-passthrough>` = human-initiated shell run, output injected into your context automatically\n- `bash` tool result = model-initiated command you explicitly called\n\nAttributes on the opening tag:\n- `mode=\"foreground\"` \u2014 user waited for the command to finish before the next prompt\n- `mode=\"background\"` \u2014 command ran detached (`!&` prefix); output arrives after it completes\n- `exit=\"N\"` \u2014 shell exit code (0 = success)\n- `reason=\"...\"` \u2014 error category when nonzero: `nonzero-exit`, `abort` (Ctrl+C), `timeout`, `overflow`, `spawn-failed`, `signal-killed`\n- `duration=\"1.3s\"` \u2014 wall-clock runtime\n- `truncated=\"true\"` \u2014 output was capped; full output not available\n\nThe `<command>` child contains the literal command the user typed (XML-escaped). The `<output>` child contains ANSI-stripped, XML-escaped captured stdout/stderr.";
+export declare const BG_SUBAGENT_RESULT_PROMPT = "When a user message contains a `<background-subagent-result>` block, it is the completed output of a background subagent you previously dispatched with the `agent` tool (`mode: \"background\"`) or that the user backgrounded with Ctrl+B. It was delivered automatically \u2014 no join was needed. Attributes: `jobId`, `status` (`completed`/`failed`), `model`, `duration`. The `<task>` child echoes the dispatch prompt's first 80 chars; `<output>` carries the subagent's final message (XML-escaped, truncated at 16KB with a marker naming `/bgsub:join <jobId>` for the full text). Treat the output as the subagent's compressed findings \u2014 reason over it as you would a foreground `agent` result.";
+export declare const TOOL_SYSTEM_PROMPT = "You have access to tools for working with the filesystem and running commands. Follow these conventions:\n\n- Use read_file before editing to verify the exact content you want to change.\n- Prefer edit_file over write_file for modifying existing files \u2014 write_file is for new files or complete rewrites.\n- Quote file paths that contain spaces with double quotes.\n- Do not run destructive shell commands (rm -rf, git reset --hard, etc.) unless the user explicitly asks.\n- Use glob and grep to discover files before reading individual files.\n- When bash output is very long, it may be truncated. If you need the full output, redirect to a file and read it.\n- Use absolute paths for file operations.\n- Prefer `agent` (and `skill`) for multi-file investigation, verification, parallel hypotheses, and any work that would otherwise consume large amounts of inline context. The main session is the coordinator; subagents are the investigators.\n\nWhen you see a `<command-name>` tag in the current conversation turn, the skill has ALREADY been loaded by the user typing a slash command. Do NOT re-invoke the skill tool to dispatch that same skill again. Instead, treat the `<command-message>` as the skill name and `<command-args>` as its arguments, then follow the instructions in the body block immediately following the tag. You MAY still invoke the skill tool to dispatch OTHER skills that are not the one already loaded.\n\nWhen a user message contains a `<bash-passthrough>` block, it represents a shell command the **user ran directly** in the REPL using the `!` prefix (e.g. `!ls` or `!&pnpm test`). This is distinct from the `bash` tool you invoke yourself:\n\n- `<bash-passthrough>` = human-initiated shell run, output injected into your context automatically\n- `bash` tool result = model-initiated command you explicitly called\n\nAttributes on the opening tag:\n- `mode=\"foreground\"` \u2014 user waited for the command to finish before the next prompt\n- `mode=\"background\"` \u2014 command ran detached (`!&` prefix); output arrives after it completes\n- `exit=\"N\"` \u2014 shell exit code (0 = success)\n- `reason=\"...\"` \u2014 error category when nonzero: `nonzero-exit`, `abort` (Ctrl+C), `timeout`, `overflow`, `spawn-failed`, `signal-killed`\n- `duration=\"1.3s\"` \u2014 wall-clock runtime\n- `truncated=\"true\"` \u2014 output was capped; full output not available\n\nThe `<command>` child contains the literal command the user typed (XML-escaped). The `<output>` child contains ANSI-stripped, XML-escaped captured stdout/stderr.\n\nWhen a user message contains a `<background-subagent-result>` block, it is the completed output of a background subagent you previously dispatched with the `agent` tool (`mode: \"background\"`) or that the user backgrounded with Ctrl+B. It was delivered automatically \u2014 no join was needed. Attributes: `jobId`, `status` (`completed`/`failed`), `model`, `duration`. The `<task>` child echoes the dispatch prompt's first 80 chars; `<output>` carries the subagent's final message (XML-escaped, truncated at 16KB with a marker naming `/bgsub:join <jobId>` for the full text). Treat the output as the subagent's compressed findings \u2014 reason over it as you would a foreground `agent` result.";
 export declare const MEMORY_SYSTEM_PROMPT = "# Cross-Session Memory\n\nYou have three tools for persisting knowledge across sessions: memory_search, memory_update, and procedure_write.\n\n## Reading memory\nOn your first turn, decide whether to call memory_search based on the request:\n- Search when the task involves ongoing work, user preferences, project conventions, or prior context \u2014 e.g. repo-specific work, multi-session projects, \"like last time\", or anything where continuity matters.\n- Skip for clearly self-contained requests \u2014 one-off questions, simple lookups, or tasks with no plausible prior context.\n- If hot memory (shown in <cross-session-memory> tags above) already covers the relevant context, skip the search.\n- Search at most once per session for general context. Search again only if new information surfaces a specific topic worth querying.\n\nUse FTS5 syntax: \"exact phrase\", term1 AND term2, prefix*.\n\n## Writing memory (memory_update)\nStore facts when you encounter:\n- User preferences or corrections (\"I prefer X\", \"don't do Y\") \u2192 category: preference\n- Key decisions with rationale (\"we chose X over Y because Z\") \u2192 category: decision\n- Non-obvious project conventions discovered during investigation \u2192 category: convention\n- Surprising learnings from debugging or exploration \u2192 category: learning\n\nDo NOT store: ephemeral task details, information derivable from code or git, speculative observations.\n\n### Hot memory vs. fact archive\n- target \"fact\" \u2192 searchable SQLite archive. **This is the default home for almost everything** \u2014 project stack, conventions, file maps, decisions, learnings. It is unbounded and searchable. When in doubt, it's a fact.\n- target \"hot\" \u2192 HOT.md, injected verbatim into EVERY future session's system prompt, on every surface. Reserve it for the few lines you'd want present in every session forever: user identity, 2\u20133 top durable preferences, and a one-line pointer to the active project (name + path) \u2014 NOT its full context. Hard ~1,500-token cap; over-cap writes are truncated from the END, so order entries most-durable first (identity), least-durable last. If something doesn't need to be in every prompt, it's a fact, not hot.\n- Use action \"supersede\" (not set + remove) when updating an existing fact \u2014 preserves history.\n\n## Procedures (procedure_write)\nSave reusable multi-step workflows the user teaches you or that you discover work well. Name in kebab-case. Searchable via memory_search.";
 export declare const MEMORY_SYSTEM_PROMPT_READONLY = "# Cross-Session Memory (read-only)\n\nYou have one tool for recalling knowledge from prior sessions: memory_search. Writes (memory_update, procedure_write) are not available in this child session \u2014 only the parent can persist new memory.\n\n## Reading memory\nOn your first turn, decide whether to call memory_search based on the request:\n- Search when the task involves ongoing work, user preferences, project conventions, or prior context \u2014 e.g. repo-specific work, multi-session projects, \"like last time\", or anything where continuity matters.\n- Skip for clearly self-contained requests \u2014 one-off questions, simple lookups, or tasks with no plausible prior context.\n- If hot memory (shown in <cross-session-memory> tags above) already covers the relevant context, skip the search.\n- Search at most once per session for general context. Search again only if new information surfaces a specific topic worth querying.\n\nUse FTS5 syntax: \"exact phrase\", term1 AND term2, prefix*.";
+export declare function resolveToolSystemPrompt(isSkillDispatch: boolean | undefined): string;
+export declare function resolveMemorySystemPrompt(readOnly: boolean | undefined): string;

package/dist/agent/trace/events.d.ts

@@ -191,6 +191,16 @@ export declare const BackgroundAgentJoinedPayloadSchema: z.ZodObject<{
         cancelled: "cancelled";
     }>;
 }, z.core.$strip>;
+export declare const BackgroundAgentDeliveredPayloadSchema: z.ZodObject<{
+    transition: z.ZodLiteral<"delivered">;
+    jobId: z.ZodString;
+    subagentId: z.ZodString;
+    jobStatus: z.ZodEnum<{
+        completed: "completed";
+        failed: "failed";
+        cancelled: "cancelled";
+    }>;
+}, z.core.$strip>;
 export declare const BackgroundAgentPayloadSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
     transition: z.ZodLiteral<"started">;
     jobId: z.ZodString;
@@ -227,6 +237,15 @@ export declare const BackgroundAgentPayloadSchema: z.ZodDiscriminatedUnion<[z.Zo
         failed: "failed";
         cancelled: "cancelled";
     }>;
+}, z.core.$strip>, z.ZodObject<{
+    transition: z.ZodLiteral<"delivered">;
+    jobId: z.ZodString;
+    subagentId: z.ZodString;
+    jobStatus: z.ZodEnum<{
+        completed: "completed";
+        failed: "failed";
+        cancelled: "cancelled";
+    }>;
 }, z.core.$strip>], "transition">;
 export declare const BudgetPayloadSchema: z.ZodObject<{
     kind: z.ZodLiteral<"monetary">;
@@ -597,6 +616,15 @@ export declare const TraceEventInputSchema: z.ZodDiscriminatedUnion<[z.ZodObject
             failed: "failed";
             cancelled: "cancelled";
         }>;
+    }, z.core.$strip>, z.ZodObject<{
+        transition: z.ZodLiteral<"delivered">;
+        jobId: z.ZodString;
+        subagentId: z.ZodString;
+        jobStatus: z.ZodEnum<{
+            completed: "completed";
+            failed: "failed";
+            cancelled: "cancelled";
+        }>;
     }, z.core.$strip>], "transition">;
 }, z.core.$strip>, z.ZodObject<{
     kind: z.ZodLiteral<"budget">;
@@ -881,6 +909,15 @@ export declare const TraceEventSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
             failed: "failed";
             cancelled: "cancelled";
         }>;
+    }, z.core.$strip>, z.ZodObject<{
+        transition: z.ZodLiteral<"delivered">;
+        jobId: z.ZodString;
+        subagentId: z.ZodString;
+        jobStatus: z.ZodEnum<{
+            completed: "completed";
+            failed: "failed";
+            cancelled: "cancelled";
+        }>;
     }, z.core.$strip>], "transition">;
 }, z.core.$strip>, z.ZodObject<{
     ts: z.ZodString;

package/dist/agent/trace/types.d.ts

@@ -95,7 +95,13 @@ export interface BackgroundAgentJoinedPayload {
     subagentId: string;
     jobStatus: 'completed' | 'failed' | 'cancelled';
 }
-export type BackgroundAgentPayload = BackgroundAgentStartedPayload | BackgroundAgentCompletedPayload | BackgroundAgentFailedPayload | BackgroundAgentCancelledPayload | BackgroundAgentJoinedPayload;
+export interface BackgroundAgentDeliveredPayload {
+    transition: 'delivered';
+    jobId: string;
+    subagentId: string;
+    jobStatus: 'completed' | 'failed' | 'cancelled';
+}
+export type BackgroundAgentPayload = BackgroundAgentStartedPayload | BackgroundAgentCompletedPayload | BackgroundAgentFailedPayload | BackgroundAgentCancelledPayload | BackgroundAgentJoinedPayload | BackgroundAgentDeliveredPayload;
 export interface BudgetPayload {
     kind: 'monetary';
     runningCostUsd: number;

package/dist/cli/commands/interactive/afk-push.d.ts

@@ -2,6 +2,7 @@ import { pushIfConfigured } from '../../../telegram/push.js';
 import type { ToolEvent } from '../../slash/types.js';
 import type { TerminalState } from './terminal-state.js';
 export declare const MAX_PUSHES_PER_SESSION = 20;
+export declare const MAX_RAW_BODY_FALLBACK_CHARS = 500;
 export declare const DONE_EVIDENCE_TOOLS: ReadonlySet<string>;
 export declare function doneHasCorroboratingEvidence(toolEvents: readonly ToolEvent[]): boolean;
 export declare function formatTerminalStateForTelegram(state: TerminalState, opts?: {

package/dist/cli/commands/interactive/bg-result-notifier.d.ts

@@ -0,0 +1,18 @@
+import type { BackgroundAgentRegistry, BackgroundJob } from '../../../agent/background-registry.js';
+export declare const MAX_INJECTION_BYTES: number;
+export interface PendingBgAgentNotification {
+    job: BackgroundJob;
+}
+export declare function buildBgResultInjection(job: BackgroundJob): string;
+export declare function isAutoDeliverEnabled(raw: string | undefined): boolean;
+export declare class BgResultNotifier {
+    private readonly registry;
+    private pendingInjections;
+    private pendingNotifications;
+    private readonly onSettled;
+    constructor(registry: BackgroundAgentRegistry);
+    drainInjections(): string;
+    drainNotifications(): readonly PendingBgAgentNotification[];
+    reset(): void;
+    dispose(): void;
+}

package/dist/cli/commands/interactive/footer-subsystems.d.ts

@@ -4,6 +4,7 @@ import { createVerdictLedger } from './verdict-ledger.js';
 import { BackgroundStatusBar } from '../../background-status-bar.js';
 import { LoopStageBar } from './loop-stage.js';
 import { ShellPassthrough } from './shell-passthrough.js';
+import { BgResultNotifier } from './bg-result-notifier.js';
 import type { TurnState } from './repl-loop-shared.js';
 export interface FooterSubsystems {
     contextPane: ReturnType<typeof createContextPane>;
@@ -11,5 +12,6 @@ export interface FooterSubsystems {
     loopStageBar: LoopStageBar;
     verdictLedger: ReturnType<typeof createVerdictLedger>;
     shellPassthrough: ShellPassthrough;
+    bgResultNotifier: BgResultNotifier;
 }
 export declare function setupFooterSubsystems(ctx: InteractiveCtx, turnState: TurnState): FooterSubsystems;

package/dist/cli/commands/interactive/shared.d.ts

@@ -58,6 +58,7 @@ export interface InteractiveCtx {
     getInFlight?: () => boolean;
     requestResume?: (target: ResolvedResumeTarget) => Promise<ResumeSwapResult>;
     clearVerdictLedger?: () => void;
+    clearBgResultBuffer?: () => void;
     preArmAnchorRow?: number;
     inputSurfaceRef?: {
         current: import('../../input/input-surface.js').InputSurface | null;