@poncho-ai/sdk 1.9.0 → 1.11.0

package/.turbo/turbo-build.log

@@ -1,5 +1,5 @@
 
-> @poncho-ai/sdk@1.9.0 build /home/runner/work/poncho-ai/poncho-ai/packages/sdk
+> @poncho-ai/sdk@1.11.0 build /home/runner/work/poncho-ai/poncho-ai/packages/sdk
 > tsup src/index.ts --format esm --dts
 
 CLI Building entry: src/index.ts
@@ -8,7 +8,7 @@
 CLI Target: es2022
 ESM Build start
 ESM dist/index.js 17.24 KB
-ESM ⚡️ Build success in 23ms
+ESM ⚡️ Build success in 21ms
 DTS Build start
-DTS ⚡️ Build success in 1448ms
-DTS dist/index.d.ts 27.76 KB
+DTS ⚡️ Build success in 1385ms
+DTS dist/index.d.ts 29.09 KB

package/CHANGELOG.md

@@ -1,5 +1,75 @@
 # @poncho-ai/sdk
 
+## 1.11.0
+
+### Minor Changes
+
+- [`1adaae2`](https://github.com/cesr/poncho-ai/commit/1adaae2d4cc55800f01d602f2a7d6ecc65031443) Thanks [@cesr](https://github.com/cesr)! - harness: device-dispatch mode for tools that execute on a connected client
+
+  Tools can now be marked `dispatch: "device"` on `loadedConfig.tools`. When
+  the model calls such a tool the dispatcher pauses the run, emits a new
+  `tool:device:required` event, and checkpoints with the new
+  `kind: "device"` discriminator on `pendingApprovals` — same plumbing as
+  the approval flow, different trigger and different resume payload.
+  Consumers (e.g. PonchOS for iOS device tools) drive the external
+  execution and feed the result back via `continueFromToolResult`.
+
+  Approval can be combined: `{access: "approval", dispatch: "device"}`
+  yields the approval card first, then on resume falls through to the
+  device-required event. The wire vocabulary for approvals
+  (`approvalId` etc.) is unchanged; the `pendingApprovals` column /
+  field name stays.
+
+  `ToolAccess` is broadened to accept both the legacy string `"approval"`
+  and the new `{access?, dispatch?}` object form. Existing configs keep
+  working unchanged.
+
+## 1.10.0
+
+### Minor Changes
+
+- [#104](https://github.com/cesr/poncho-ai/pull/104) [`9616060`](https://github.com/cesr/poncho-ai/commit/96160607502c2c0b05bc60b67b8fc012f4052ef1) Thanks [@cesr](https://github.com/cesr)! - dev: add a Files mode to the sidebar with VFS browsing, preview, and uploads
+
+  The web UI sidebar now has a Chats / Files segmented control. Switching to
+  Files reveals a folder-tree view of the agent's VFS — the same storage the
+  agent reads and writes via `read_file`, `write_file`, and the virtualized
+  `bash` tool. Folders expand inline with the same caret/dropdown pattern as
+  the Cron jobs section. Clicking a file previews it in the main panel:
+  - Text / JSON / source code render as a wrapped `<pre>` (5 MB cap), with an Edit button for inline editing (last-write-wins via PUT).
+  - Images render inline.
+  - PDFs render in an embedded iframe.
+  - Audio and video render with native controls.
+  - Anything else shows a placeholder card with a Download button.
+
+  Files can be added directly from the UI: an Upload button (multi-file
+  picker), drag-and-drop onto the explorer or onto a specific folder row, and
+  a New folder button. Files and folders are deletable via a hover-X with a
+  two-step confirm. Conflicts prompt to overwrite. Four new HTTP routes back
+  this UI: `GET /api/vfs-list`, `PUT /api/vfs/{path}`, `DELETE /api/vfs/{path}`,
+  and `POST /api/vfs-mkdir`. URLs of the form `/f/{path}` deep-link to a file
+  preview; the chat composer is hidden while previewing a file.
+
+  The same routes are exposed on `AgentClient` for programmatic use:
+  `listDir`, `writeFile`, `deleteFile`, and `mkdir` (alongside the existing
+  `readFile`). New shared types `ApiVfsEntry`, `ApiVfsListResponse`, and
+  `ApiVfsWriteResponse` are exported from `@poncho-ai/sdk`.
+
+### Patch Changes
+
+- [`524df41`](https://github.com/cesr/poncho-ai/commit/524df411904bd00c07901695eda6d4dd07dde972) Thanks [@cesr](https://github.com/cesr)! - fix: persist harness messages on cancelled runs so the agent doesn't lose context
+
+  When a run was cancelled (Stop button, abort signal), `conversation.messages`
+  was updated with the partial assistant turn but `conversation._harnessMessages`
+  — the canonical history `loadCanonicalHistory` hands to the model on the next
+  turn — was left holding a snapshot from the _previous_ successful run. The
+  agent had no memory of the cancelled work, even though the user-facing UI
+  still showed it. The new verbose-mode harness toggle made this divergence
+  directly visible.
+
+  The fix plumbs an in-flight `messages` snapshot through the `run:cancelled`
+  event, trims it to a model-valid prefix (no orphan `tool_use`), and persists
+  it as `_harnessMessages` on every cancel path in the CLI.
+
 ## 1.9.0
 
 ### Minor Changes

package/dist/index.d.ts

@@ -595,6 +595,27 @@ interface ApiSlashCommand {
     description: string;
     type: "command" | "skill";
 }
+interface ApiVfsEntry {
+    name: string;
+    type: "file" | "directory" | "symlink";
+    size: number;
+    mimeType: string | null;
+    updatedAt: number | null;
+}
+interface ApiVfsListResponse {
+    path: string;
+    entries: ApiVfsEntry[];
+    usage: {
+        fileCount: number;
+        totalBytes: number;
+    };
+}
+interface ApiVfsWriteResponse {
+    path: string;
+    size: number;
+    mimeType: string | null;
+    updatedAt: number;
+}
 
 declare const LEVELS: {
     readonly debug: 10;
@@ -770,6 +791,7 @@ type AgentEvent = {
 } | {
     type: "run:cancelled";
     runId: string;
+    messages?: Message[];
 } | {
     type: "run:error";
     runId: string;
@@ -836,6 +858,32 @@ type AgentEvent = {
         name: string;
         input: Record<string, unknown>;
     }>;
+} | {
+    /**
+     * Tool wants to execute on a connected client device (e.g. iOS).
+     * The consumer of the harness is responsible for routing this event
+     * to the appropriate WebSocket and POSTing the tool's result back via
+     * `resumeRunFromCheckpoint`. Carries the same envelope as the
+     * approval-required event; `requestId` plays the role of `approvalId`.
+     */
+    type: "tool:device:required";
+    tool: string;
+    input: unknown;
+    requestId: string;
+} | {
+    type: "tool:device:checkpoint";
+    approvals: Array<{
+        approvalId: string;
+        tool: string;
+        toolCallId: string;
+        input: Record<string, unknown>;
+    }>;
+    checkpointMessages: Message[];
+    pendingToolCalls: Array<{
+        id: string;
+        name: string;
+        input: Record<string, unknown>;
+    }>;
 } | {
     type: "browser:frame";
     data: string;
@@ -888,4 +936,4 @@ type AgentEvent = {
     reason: string;
 };
 
-export { type AgentEvent, type AgentFailure, type ApiApprovalResponse, type ApiCompactResponse, type ApiCreateThreadRequest, type ApiCreateThreadResponse, type ApiSecretEntry, type ApiSlashCommand, type ApiStopRunResponse, type ApiSubagentSummary, type ApiThreadListResponse, type ApiThreadSummary, type ContentPart, FEATURE_DOMAIN_ORDER, type FeatureDomain, type FileContentPart, type FileInput, type JsonSchema, type Logger, type Message, ONBOARDING_FIELDS, type OnboardingField, type OnboardingFieldCondition, type OnboardingFieldKind, type OnboardingFieldTarget, type OnboardingOption, type OnboardingScope, type Role, type RunInput, type RunResult, type TextContentPart, type TokenUsage, type ToolContext, type ToolDefinition, type ToolHandler, type VfsAccess, createLogger, defineTool, fieldsForScope, formatError, getTextContent, muted, num, setLogLevel, url };
+export { type AgentEvent, type AgentFailure, type ApiApprovalResponse, type ApiCompactResponse, type ApiCreateThreadRequest, type ApiCreateThreadResponse, type ApiSecretEntry, type ApiSlashCommand, type ApiStopRunResponse, type ApiSubagentSummary, type ApiThreadListResponse, type ApiThreadSummary, type ApiVfsEntry, type ApiVfsListResponse, type ApiVfsWriteResponse, type ContentPart, FEATURE_DOMAIN_ORDER, type FeatureDomain, type FileContentPart, type FileInput, type JsonSchema, type Logger, type Message, ONBOARDING_FIELDS, type OnboardingField, type OnboardingFieldCondition, type OnboardingFieldKind, type OnboardingFieldTarget, type OnboardingOption, type OnboardingScope, type Role, type RunInput, type RunResult, type TextContentPart, type TokenUsage, type ToolContext, type ToolDefinition, type ToolHandler, type VfsAccess, createLogger, defineTool, fieldsForScope, formatError, getTextContent, muted, num, setLogLevel, url };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@poncho-ai/sdk",
-  "version": "1.9.0",
+  "version": "1.11.0",
   "description": "Core types and utilities for building Poncho skills",
   "repository": {
     "type": "git",

package/src/api-types.ts

@@ -75,3 +75,24 @@ export interface ApiSlashCommand {
   description: string;
   type: "command" | "skill";
 }
+
+export interface ApiVfsEntry {
+  name: string;
+  type: "file" | "directory" | "symlink";
+  size: number;
+  mimeType: string | null;
+  updatedAt: number | null;
+}
+
+export interface ApiVfsListResponse {
+  path: string;
+  entries: ApiVfsEntry[];
+  usage: { fileCount: number; totalBytes: number };
+}
+
+export interface ApiVfsWriteResponse {
+  path: string;
+  size: number;
+  mimeType: string | null;
+  updatedAt: number;
+}

package/src/index.ts

@@ -166,7 +166,7 @@ export interface AgentFailure {
 export type AgentEvent =
   | { type: "run:started"; runId: string; agentId: string; contextWindow?: number }
   | { type: "run:completed"; runId: string; result: RunResult; pendingSubagents?: boolean }
-  | { type: "run:cancelled"; runId: string }
+  | { type: "run:cancelled"; runId: string; messages?: Message[] }
   | { type: "run:error"; runId: string; error: AgentFailure }
   | { type: "step:started"; step: number }
   | { type: "step:completed"; step: number; duration: number }
@@ -196,6 +196,30 @@ export type AgentEvent =
       checkpointMessages: Message[];
       pendingToolCalls: Array<{ id: string; name: string; input: Record<string, unknown> }>;
     }
+  | {
+      /**
+       * Tool wants to execute on a connected client device (e.g. iOS).
+       * The consumer of the harness is responsible for routing this event
+       * to the appropriate WebSocket and POSTing the tool's result back via
+       * `resumeRunFromCheckpoint`. Carries the same envelope as the
+       * approval-required event; `requestId` plays the role of `approvalId`.
+       */
+      type: "tool:device:required";
+      tool: string;
+      input: unknown;
+      requestId: string;
+    }
+  | {
+      type: "tool:device:checkpoint";
+      approvals: Array<{
+        approvalId: string;
+        tool: string;
+        toolCallId: string;
+        input: Record<string, unknown>;
+      }>;
+      checkpointMessages: Message[];
+      pendingToolCalls: Array<{ id: string; name: string; input: Record<string, unknown> }>;
+    }
   | { type: "browser:frame"; data: string; width: number; height: number }
   | {
       type: "browser:status";