@astralyn/pi 0.87.5 → 0.99.0

package/docs/bundled/tasks.md

@@ -0,0 +1,141 @@
+# Tasks
+
+Tasks is a built-in session capability. The `tasks` tool and `/tasks` panel inspect and control native Bash, PowerShell, and extension-owned work. Execution, retained results, and completion delivery have separate core owners; no Background extension is required.
+
+## Start or detach work
+
+Start Bash through the native `bash` tool (the optional native Windows `powershell` tool accepts the same fields and follows the same lifecycle):
+
+```json
+{ "command": "npm run build", "timeout": 120, "background": true }
+```
+
+Omitting `background` keeps the normal foreground wait. A background submission returns an execution reference, not a successful final outcome. `bg create` has been removed; old stored create results and background notifications still render in transcripts.
+
+In interactive mode, **Ctrl+B** moves all eligible foreground managed tasks to the background. Once a foreground execution has run for ten seconds and can still move, the statusline shows `Ctrl+B to background`. It works even when `/tasks` owns focus. The same execution continues: no cancellation, restart or timeout reset. It does not detach ordinary file tools, or user `!` shell commands.
+
+When nothing is eligible, the key is not consumed: it falls through to other bindings instead of reporting a no-op.
+
+Configure `app.tasks.detach` in `keybindings.json` to change or disable the shortcut. The default `tui.editor.cursorLeft` is now `left`, freeing Ctrl+B. To restore Emacs cursor behavior, disable or rebind detach before assigning Ctrl+B to cursor-left.
+
+Hosts can prohibit background execution with `backgroundAllowed: false`. This restriction survives runtime replacement and does not depend on task kind; foreground execution remains available.
+
+## Management tool
+
+`tasks` observes existing Bash, PowerShell, and extension-owned tasks:
+
+| Action | Parameters | Behavior |
+|---|---|---|
+| `list` | — | Lists active and up to five retained finished records, at most 100 rows; foreground executions are omitted with a count (they deliver inline in the transcript) |
+| `read` | `taskId`, optional `mode`, `bytes` | Reads bounded output/report while running or after completion |
+| `wait` | `taskId`, optional `waitMs`, `sinceBytes` | Waits within a deadline and returns status plus bounded output/report |
+| `kill` | `taskId` | Requests cancellation of the selected task |
+
+Use the execution ID returned by the native tool or `tasks list`. An unknown or stale `taskId` fails with the session's current tasks listed inline (active first, then recent finishes), so the next call can use a real ID without a separate list call; an ambiguous prefix lists exactly the tasks it matched.
+
+```json
+{ "action": "read", "taskId": "<execution-id>", "mode": "tail", "bytes": 8192 }
+```
+
+Reads default to an 8KB tail. `bytes` clamps between 256 bytes and 50KB at the tool boundary (the core currently limits the actual slice to 48KB); `mode` can be `head` or `tail`. A Bash output path is included when available. Report tasks return their authoritative bounded result.
+
+```json
+{ "action": "wait", "taskId": "<execution-id>", "waitMs": 20000, "sinceBytes": 4096 }
+```
+
+`waitMs` defaults to 20 seconds and clamps between 1 and 60 seconds. Wait output is limited to 32KB, optionally starting after `sinceBytes`. Expiry or cancellation ends only the wait, not execution. Continue independent work instead of sleep-polling or repeatedly reading; wait when the next step genuinely depends on the result.
+
+```json
+{ "action": "kill", "taskId": "<execution-id>" }
+```
+
+A cancellation request is not proof that execution has stopped. The task can remain `stopping` during cleanup. Read its later terminal status for the outcome. Partial, failed, cancelled and timeout outcomes are not displayed as successful completion.
+
+All model-facing management responses, including listings and error messages, are bounded to 50KB and 2,000 lines overall. Repeated reads do not add usage or restart execution. Completion delivery and usage accounting belong to the host, not panel refreshes.
+
+## `/tasks` panel
+
+The fullscreen panel lists only **ongoing tasks**, including queued, running and stopping work in both foreground (`fg`) and background (`bg`) modes. Completed tasks leave the list immediately. If the selected task finishes, its final view stays on the right until another task is selected or the panel closes. Opening the panel again does not list finished work; results remain available in the transcript and through `tasks read` / `tasks wait`.
+
+At 100 columns or more, the left task list sits beside two independently scrollable regions: **Information** above **Output**. Narrow terminals stack the regions. The panel owns selection, focus, scrolling and cancellation; the execution module owns its information and output components:
+
+- Bash and PowerShell show their command, directory, log path and exit code, with live plain-text output.
+- Other extensions can register their own structure. A missing or failing renderer falls back to the saved task information and result text.
+
+| Default key | Action |
+|---|---|
+| Left | Focus the task list |
+| `i` | Focus information |
+| Right / Enter | Focus output |
+| Up / Down | Select a task or scroll the focused region |
+| Page Up / Page Down | Page the focused list or region |
+| `k`, then `y` | Request cancellation of the selected ongoing task; any other key cancels confirmation |
+| Escape | Return to the list, then close |
+| Ctrl+B | Detach eligible foreground executions through the host |
+
+Shell output initially follows the tail. Scrolling up enters **browsing** and keeps a bounded output snapshot while status continues updating. Explicit downward scrolling to the bottom resumes **following**. Scrolling and closing never pause, reattach or cancel execution. Information scrolls independently, so long commands and parameters remain accessible. Task selection and each task's reading positions survive unrelated updates.
+
+The panel polls only selected tail output once per second, up to 48 KiB per read; navigation can request an immediate refresh. A settled selected task gets a final read; browsing defers that read until following resumes. The output range describes the bounded preview, not the entire log. Selecting a task retains its result and log without delaying completion notifications. Closing releases the view, subscriptions, retention lease and timers.
+
+Controls use `app.tasks.focusList`, `app.tasks.focusInfo`, `app.tasks.focusPreview`, `app.tasks.kill` and `app.tasks.detach`. List paging uses `tui.select.pageUp` / `pageDown`; information and output paging use `tui.editor.pageUp` / `pageDown`. All are configurable.
+
+## Extension-owned task views
+
+Register a `TaskViewProvider` in `session_start` with `ctx.tasks.views.register(kind, provider)`. The returned function unregisters it. Registrations belong to the current runtime and are cleared on shutdown or replacement; duplicate registrations for a kind are rejected. Native Bash and PowerShell providers are installed by the interactive host.
+
+A provider declares `outputMode: "snapshot" | "tail"` and implements `create({ theme, requestRender })`, returning:
+
+- `info` and `output`: TUI components whose content the panel wraps and scrolls.
+- `update(task, output?)`: receives the latest detached task snapshot and, for tail providers, the bounded `TaskRead`.
+- Optional `dispose()`: releases view-owned resources on selection change, provider removal or panel close.
+
+The panel consumes navigation keys and forwards remaining keys to the focused component. Providers can request a repaint without polling or owning the execution. Use semantic theme colors. Keep log source lines unwrapped when possible so the panel can preserve their scroll anchors across resize.
+
+An executor can publish independent, versioned display data:
+
+```typescript
+control.publishView({
+  version: 1,
+  data: { phase: "Scanning", findings: [{ path: "src/main.ts", count: 2 }] },
+});
+```
+
+This becomes `task.viewData`. Its version and fields belong to the execution module. Only plain JSON data is accepted, with a 120 KiB storage budget and bounded nesting. Invalid or oversized data is rejected before replacing the previous value; callbacks and accessors cannot enter snapshots. The executor should publish a useful plain tool result as well, which remains readable without its provider.
+
+On settlement, `viewData` is saved in the session JSONL's `task-result` entry. Renderers and live processes are never serialized. The existing completion projection remains separate: changing a panel view does not change tool schemas, model-facing results or notification structure. Built-in views may use the existing saved task fields and projection directly.
+
+## Completion notifications
+
+Interactive `task-completion` messages have a compact collapsed summary: outcome, execution kind, short ID, and a command or group brief. Failures retain a short reason; log paths, output and worker reports stay out of the collapsed view. In fullscreen mode, left-click the notification to expand or collapse that message independently. The blank spacer above it is not a click target. The configured tool-output expansion binding (default Ctrl+O) remains available for toggling output expansion across the transcript.
+
+Expanded shell notifications separate **Command**, **Directory**, **Result** or **Error**, a bounded plain-text **Output** tail, **Log** and the full execution ID. Expanded report completions show executor-provided items and Markdown reports; failures keep their reason separate from any partial report. Each saved output/report carries an explicit truncation flag. Screen line limits are independent of source truncation, and every report item retains an allowance. These are previews of the saved bounded completion.
+
+Rendering reads the self-contained `TaskCompletionSnapshot` in message `details`, so `/reload`, history eviction, expired logs and restart do not require a live task lookup. The session generates model-facing `content` from the same facts; `details` never enters model context or usage accounting. Commands containing `Output:`, worker reports containing headings or error-wrapper examples, and literal truncation notices remain ordinary data. See the [snapshot contract](../session-format.md#background-records).
+
+Only the current structured completion format is specialized. Older text-only completions and malformed details receive a bounded plain **Details** view; no text reconstruction or migration is performed. Legacy `background-task` notifications keep their existing renderer. HTML export and `/tree` selector labels continue to display the saved message content.
+
+## Lifetime
+
+Background execution belongs to the current session runtime, not a daemon. Parent-turn cancellation still cancels foreground-owned work; after detach it does not cancel background work. Shutdown, `/reload`, `/new`, `/resume`, and `/fork` close admission, stop delivery, cancel work and perform bounded cleanup. `/tree` cancels executions whose launch anchor is absent from the destination branch and suppresses their completion delivery there; navigating back to a branch revives its undelivered completions, and ordinary conversation progress along the same branch does not cancel them. A completion already handed to the prompt queue when its run was aborted is not recalled — the next run delivers it, like any other queued message. Active processes and workers are not reattached across process restart or copied into a fork.
+
+The panel is an observer, not a cleanup engine. Admission, bounded history/output retention, completion delivery and headless exit policy are enforced by the core service and hosting mode.
+
+Interactive mode enables Background. Built-in print, JSON, and RPC modes and ordinary SDK sessions leave it disabled and reject `background: true`; normal foreground execution remains available. An SDK embedding can explicitly enable it via `session.bindExtensions({ tasksEnabled: true })`, but must own cancellation, bounded draining, result-driven turns, and shutdown. See [SDK Background execution](../sdk.md#background-execution).
+
+Managed shell output is collected continuously from startup, including before detach. Background shell output is capped at 20 MiB; crossing the cap fails and stops the command. Foreground output retains its existing uncapped log behavior: detaching a command already over the background budget stops it without deleting the prior bytes. No timeout is supplied by default, and a supplied timeout remains measured from command startup, in seconds, across detach.
+
+Managed logs are ephemeral: they are retained with the runtime record and cleaned up when that record is evicted or the runtime shuts down. Save needed output elsewhere before then. The core defaults to eight active managed executions and two independent terminal histories: 32 reports/background log tasks, plus 32 foreground log records. Report tasks count toward the first history in either mode. Foreground shell traffic can only evict older foreground shell records. Pending delivery, pins, active reads and cleanup use a separate allowance within the bounded total; pins temporarily defer history eviction, not runtime shutdown. These are service limits, not new user settings.
+
+Terminal snapshots persist as version-2 `task-result` custom entries, including the presentation projection and optional executor-owned `viewData`; usage remains in independent version-1 `task-usage` entries. The runtime restores version-2 terminal history from the selected branch for programmatic reads, selecting the newest records independently for each history. The panel lists ongoing work only. Older result records are left in the session file and are not migrated or restored. Live execution never resumes after restart, and restoration does not replay accounting or completion events. A saved log path is not a durable attachment. See [session format](../session-format.md#background-records).
+
+Delivered history outside the selected branch can be released and restored on return, so it does not fill the new branch's history budget. Undelivered completions stay protected while their branch is hidden. Pending delivery, pins and active reads use a separate allowance within the total runtime retention cap; restoration respects the same cap.
+
+Completion delivery follows the same queueing path as interactive input. While the agent is running, a completion is steered into that run, so it lands right after the current tool batch — exactly like a message the user types mid-run, and behind any already queued steering. An idle session starts a completion turn instead. User preflight (input hooks, model and authentication checks, compaction) still holds delivery, so a user message is always the first thing a new run sees. One bounded completion is in flight at a time. Each execution produces one completion. A terminal `tasks wait` coordinates with automatic delivery only after its tool result is persisted: while `tasks wait` prepares a result for persistence, that task is not announced, and aborting during output reading does not lose the pending completion. Direct SDK waits remain observational until explicitly acknowledged. Plain reads and panel selection retain output without delaying notifications. Progress and repeated reads do not inject messages or add usage. `agent_settled` still describes the main agent, not the end of all background executions.
+
+Failed completion delivery leaves the terminal result available for inspection rather than silently discarding it, and warns through the extension error channel. The next user prompt retries delivery automatically; SDK hosts can also call `session.retryTaskNotifications()` explicitly after resolving the failure. There is no infinite timer retry loop. A completion that a run emitted but never persisted, and a completion dropped by clearing the queue, fail the same way; one still sitting in the queue when its run ends stays claimed, because the next run delivers that same message.
+
+Queued extension `nextTurn` context accompanies completion turns and stays queued until each message is persisted. A failed or partially persisted turn therefore retries only the context that has not been saved.
+
+If an executor ignores cancellation and settles after bounded cleanup has retired its runtime or branch, the old session quarantines its bounded result and reported usage: the latest 32 records remain in memory, and persisted sessions also append `<session-file>.tasks-late.jsonl`. These audit records are excluded from active totals and are not automatically reconciled. A completed cleanup grace period is not proof that an uncooperative executor stopped.
+
+The previous extension-owned interactive-prompt stall watchdog was not ported. Pi no longer automatically flags a prompt-looking shell tail as `waiting for input` or sends stall remediation notifications. Use non-interactive commands and inspect/stop stalled work manually; legacy stall notifications still render from saved transcripts.

package/docs/bundled/tool-presentation.md

@@ -1,45 +1,58 @@
 # Native tool presentation
 
-The `@astralyn/pi` package uses Pi's native tool transcript presentation rather than replacing it with a separate `tools-view` extension.
+The `@astralyn/pi` package draws every tool call in the interactive transcript as one compact block: a status dot and a rail. Tools in the transcript are not cards, have no background color, and show no timers of their own.
 
 ## Visual language
 
 ```text
-● ToolName(args)
-│ first result line
-│ second result line
+I'll look at the code.
+
+● read src/app.ts:1-80
+● grep /useState/ in src
+● edit src/app.ts
+│  1 const a = 0
+│ -2 const b = 1
+│ +2 const b = 2
+● $ npm test
+│ ... (14 earlier lines, ctrl+o to expand)
+│ FAIL a.test.ts
 │
-│ final result line
+│ Command exited with code 1
+│
+│ Took 4.2s
+
+The tests failed.
 ```
 
-The dim result rail continues through every visual line; an empty output line renders as a bare `│`. Calls keep their status in the leading dot: warning while pending or running, green after success, and red after failure. For bash commands that are still running after two seconds, the shell adds a live result row such as `Running… (2.1s)` and removes it when the call settles. Other tools with live progress render it themselves; tools using `renderShell: "self"` continue to own their entire presentation.
+- The dot is the tool's state: the warning color while the call is pending or running, green after success, and red after failure.
+- The rail continues through every visual line that belongs to the same tool. A blank output line renders as a bare `│`.
+- Tool blocks sit directly under each other with no blank line. Text before or after a run of tools keeps one blank line.
+- `read`, `grep`, `find`, and `ls` show only their header until expanded. A failed call always shows its error.
+- Consecutive calls never merge into a group. Every call keeps its own row, and the configured expand-tools key (`Ctrl+O` by default) or a click on the row shows its complete result.
 
-Time-driven renderers schedule their own repaints: while a result is partial they arm a timer in renderer state and call the render context's `invalidate()`, clearing the timer on the first settled render. Renderers compute elapsed/countdown values from absolute timestamps or deadlines, so a delayed repaint never changes the underlying wall-clock meaning.
+The bash renderer shows its own `Elapsed` line while a command runs and a fixed `Took` line after it settles. The shell adds no progress row, and other renderers that refresh over time schedule their own repaints: they arm a timer in renderer state, call the render context's `invalidate()`, and clear the timer on the first settled render. The shell calls `state.dispose()` when a row is disposed, so a timer never outlives its row.
 
-## Implementation boundary
+The `Ctrl+B` background hint is not part of a tool row. Once a foreground managed execution has run for ten seconds and can still move, the built-in Tasks UI shows `Ctrl+B to background` in the statusline, next to the `tasks N active` count.
 
-The native tool presentation owns:
+## Implementation boundary
 
-- the default call/result shell;
-- pending, success, and error states;
-- call titles and generic argument summaries;
-- collapsed and expanded result behavior;
-- generic fallback rendering;
-- image placement and conversion.
+The look is defined in one place, `src/modes/interactive/tool-view/style.ts`: the marker and rail glyphs, their colors, the spacing between blocks, and which tools fold their result. `FramedComponent` in the same file hangs a component's lines off the marker or the rail and derives the gutter width from the glyphs.
 
-Built-in renderers remain responsible for semantic content such as file paths, syntax highlighting, search results, Diff previews, and command output. The outer shell is native so built-in tools, bundled extensions, and compatible third-party tools share the same presentation.
+`tool-view/tool-execution.ts` owns one call's lifecycle: pending, success and error states, expansion, image placement and Kitty conversion, and renderer disposal. `tool-view/chat.ts` owns the chat container that removes the blank line between consecutive tool rows and disposes rows when the chat clears. Extension tools and built-in tools use the same shell, so a third-party tool gets the same dot and rail without any change.
 
-Consecutive tools may opt into a shared collapsed group through `toolGroup`. Built-in `read`, `find`, `grep`, and `ls` calls use the `explore` group, and the bundled `todo` tool uses the `todo` group: their call rows render as one compact run with a single leading gap, while the configured expand-tools key (`Ctrl+O` by default) restores each tool's complete call and result. Collapsed Todo rows are result-aware: successful v2 snapshots report actual created IDs and subjects, update status and automatic active-task demotion, list counts, or deleted IDs rather than only echoing arguments. Failures include a sanitized reason capped at 120 characters; missing, malformed, or older result details fall back safely to the call summary.
+Built-in renderers remain responsible for semantic content such as file paths, syntax highlighting, search results, Diff previews, and command output. They return plain components; the shell frames them.
 
 ## Renderer inheritance
 
 | Tool definition | Behavior |
 |---|---|
-| No `renderCall`/`renderResult` | Uses the package's native call and result fallback. |
+| No `renderCall`/`renderResult` | Uses the native call and result fallback. |
 | Custom renderer with the default shell | Uses the native shell around the custom content. |
 | `renderShell: "self"` | Keeps complete ownership of the tool's layout. |
 
-Built-in tool definitions are also used when an extension overrides only one renderer slot. A custom call renderer can inherit the built-in result renderer, and vice versa.
+Built-in tool definitions are also used when an extension overrides only one renderer slot. A custom call renderer can inherit the built-in result renderer, and vice versa. An extension that overrides a built-in tool with its own result renderer controls what that row shows, including when it is collapsed.
+
+The inherited Bash result renderer keeps its elapsed time even with a custom call renderer. Call and result renderers share `state`; a renderer that adds a `dispose()` callback must also call the previous callback so both renderers can release their resources.
 
 Renderer failures fall back to native generic output rather than breaking the transcript.
 
@@ -49,29 +62,25 @@ When no semantic renderer is available:
 
 - arguments are serialized into a bounded one-line summary;
 - output is collapsed to the most recent ten visual lines;
-- a shared hint above the tail reports the number of hidden earlier lines and the configured expand key;
+- a hint above the tail reports the number of hidden earlier lines and the configured expand key;
 - expanding restores the complete output;
 - historical tools that are no longer registered still receive the same shell;
-- failed calls use the error-colored bullet while result details keep the result rail.
+- failed calls use the error-colored dot while result details keep the rail.
 
 The fallback does not change tool schemas, execution logic, or result protocols.
 
 ## Built-in behavior preserved
 
-The native path continues to preserve:
+The presentation continues to preserve:
 
 - `read`, `bash`, `grep`, `find`, `ls`, `write`, and `edit` semantics;
 - faithful width-aware raw command previews for Bash, with honest multi-line and width truncation markers;
-- shell-wide running duration after the two-second progress threshold, with lifecycle-safe refresh disposal and no permanent completion timer;
-- path links and consistent search flags/limits across built-in renderers;
-- Diff statistics plus a ten-line collapsed Diff preview for `edit`, with the complete Diff restored on expand;
+- a ten-line collapsed Diff preview for `edit`, with the complete Diff restored on expand;
 - syntax highlighting;
 - image output and Kitty conversion;
-- native collapsed/expanded handling;
+- click to expand and collapse;
 - custom UI explicitly using `renderShell: "self"`;
-- independently refreshed custom elapsed time and retry countdowns without a duplicate generic progress row.
-
-Built-in result truncation hints share the same `… (N earlier/more lines, … to expand)` language and correct singular/plural forms. `edit` uses the native outer shell while keeping its asynchronous Diff preview and final Diff result.
+- independently refreshed custom elapsed time and retry countdowns.
 
 ## Deliberately rejected approaches
 
@@ -81,6 +90,7 @@ The package does not use:
 - same-name re-registration to replace built-in tools;
 - a global renderer registry exposed through Extension API;
 - a restored `tools-view` extension;
-- forced decoration of third-party tools that explicitly own their shell.
+- forced decoration of third-party tools that explicitly own their shell;
+- merging consecutive calls into a collapsed group, or a shell-level progress row.
 
-Those approaches either depend on private runtime internals, change execution ownership, or cannot reliably cover independently loaded extensions.
+Those approaches either depend on private runtime internals, change execution ownership, cannot reliably cover independently loaded extensions, or add presentation that the compact block does not need.

package/docs/custom-provider.md

@@ -614,3 +614,47 @@ interface ProviderModelConfig {
 `openrouter` sends `reasoning: { effort }`. `deepseek` sends `thinking: { type: "enabled" | "disabled" }` and `reasoning_effort` when enabled. `together` sends `reasoning: { enabled }` and also `reasoning_effort` when `supportsReasoningEffort` is enabled. `qwen` is for DashScope-style top-level `enable_thinking`. Use `qwen-chat-template` for local Qwen-compatible servers that read `chat_template_kwargs.enable_thinking` and need `preserve_thinking`. Use `chat-template` for configurable `chat_template_kwargs`, for example DeepSeek V3.x behind vLLM with `chatTemplateKwargs: { "thinking": { "$var": "thinking.enabled" } }`. Use `thinkingFormat: "baseten"` with `chatTemplateArgs` when the provider expects toggle values under `chat_template_args` and optionally supports top-level `reasoning_effort`.
 `thinkingTokenBudgetField` sends a clamped per-level thinking budget as a top-level request field (`thinking_token_budget` on vLLM, `thinking_budget` on Qwen/SGLang, `thinking_budget_tokens` on llama.cpp). `supportsThinkingTokenBudget: true` is an alias for the vLLM field name. Do not combine it with `reasoning_effort` on DashScope Qwen models.
 `cacheControlFormat: "anthropic"` applies Anthropic-style `cache_control` markers to the system prompt, last tool definition, and last user, assistant, or tool-result text content.
+
+## Image and classifier operations
+
+Registering only `baseUrl` or `headers` for an existing provider preserves its built-in models. Supplying `models` in the legacy form replaces that provider's models across chat, image, and classifier operations. An omitted `type` means `"chat"`; image and classifier models require explicit discriminants and implementations keyed by their `api` values through the `images` and `classifiers` fields.
+
+For example, a mixed-operation provider can register non-chat models and their implementations together:
+
+```typescript
+pi.registerProvider("media-tools", {
+  apiKey: "$MEDIA_TOOLS_API_KEY",
+  models: [
+    {
+      type: "image",
+      id: "image-v1",
+      name: "Image V1",
+      api: "media-images",
+      baseUrl: "https://media.example.com/v1",
+      input: ["text"],
+      output: ["image"],
+      cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
+    },
+    {
+      type: "classifier",
+      id: "classifier-v1",
+      name: "Classifier V1",
+      api: "media-classifier",
+      baseUrl: "https://media.example.com/v1",
+      input: ["text"],
+      cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
+      contextWindow: 64000,
+    },
+  ],
+  images: {
+    "media-images": { generateImages: async (model, context, options) => result },
+  },
+  classifiers: {
+    "media-classifier": { classify: async (model, context, options) => result },
+  },
+});
+```
+
+Model-level `baseUrl` values take precedence over the provider endpoint. If no `models` list is supplied, built-in models of every operation remain registered. Equal model IDs in different operations remain distinct, including their model-specific headers.
+
+Await `options.onProviderStreamEvent?.(providerEvent, model)` before normalizing each parsed stream event. Chat models need context and output limits; classifiers need a context window; image models declare output modalities. Legacy `refreshModels` returns a mixed-operation catalog.

package/docs/docs.json

@@ -57,8 +57,8 @@
           "path": "bundled/README.md"
         },
         {
-          "title": "Background",
-          "path": "bundled/extensions/background.md"
+          "title": "Tasks",
+          "path": "bundled/tasks.md"
         },
         {
           "title": "BTW",
@@ -80,10 +80,6 @@
           "title": "Statusline",
           "path": "bundled/extensions/statusline.md"
         },
-        {
-          "title": "Subagent",
-          "path": "bundled/extensions/subagent.md"
-        },
         {
           "title": "Todo",
           "path": "bundled/extensions/todo.md"
@@ -132,6 +128,14 @@
         {
           "title": "Custom Providers",
           "path": "custom-provider.md"
+        },
+        {
+          "title": "MCP Servers",
+          "path": "mcp.md"
+        },
+        {
+          "title": "Virtual Models",
+          "path": "virtual-models.md"
         }
       ]
     },