support pydantic-ai<=1.92.0

Author: fswair

.agents/skills/acpkit-sdk/resources/intro.md

@@ -69,6 +69,10 @@ Use these seams intentionally:
   advertise image, audio, or embedded context unless the runtime can honor them
 - only one `PrepareToolsMode(..., plan_mode=True)` is allowed
 - `plan_tools=True` is how a non-plan execution mode keeps plan progress tools visible
+- `PrepareOutputToolsBridge` is the separate seam for structured-output tool preparation in
+  current Pydantic AI
+- `HookBridge` covers output-tool preparation, output validation, output processing, and
+  deferred tool-call observation
 - `/thinking` only exists when `ThinkingBridge()` is configured
 - native ACP plan state and `PlanProvider` are separate ownership paths
 - permission card rendering is `NativeApprovalBridge.tool_call_builder`, not an `AdapterConfig`

.agents/skills/pydantic-acp/SKILL.md

@@ -116,6 +116,12 @@ High-value public seams:
 - `NativeApprovalBridge`
 - `PermissionToolCallBuilder`
 - `ApprovalPolicyStore`
+- `PrepareToolsBridge`
+- `PrepareToolsMode`
+- `PrepareOutputToolsBridge`
+- `PrepareOutputToolsMode`
+- `ThinkingBridge`
+- `HookBridge`
 - `SlashCommandProvider`
 - `StaticSlashCommandProvider`
 - `ExternalHookEventBridge`
@@ -128,6 +134,19 @@ Package entrypoint:
 
 - [Package entrypoint](https://github.com/vcoderun/acpkit/blob/main/packages/adapters/pydantic-acp/src/pydantic_acp/__init__.py)
 
+## Current Pydantic AI Compatibility
+
+`pydantic-acp` currently targets `pydantic-ai-slim==1.92.0`.
+
+When working on this surface, remember:
+
+- `PrepareToolsBridge` owns function-tool preparation and mode-specific plan tool visibility
+- `PrepareOutputToolsBridge` owns structured-output tool preparation and session metadata for output-tool modes
+- `HookBridge` covers output-tool preparation, output validation, output processing, and deferred tool-call observation
+- prompt runtime passes ACP session identity through Pydantic AI `conversation_id` and run `metadata`
+- `run_stream_events()` returns an async context manager in current Pydantic AI; keep direct async-iterable fallback only for tests and compatibility fakes
+- `OpenAICompactionBridge` must not pass deprecated `instructions=` into upstream `OpenAICompaction`
+
 ## Module Guide
 
 | Subsystem | Key files | Use them for |
@@ -190,7 +209,7 @@ It supports:
 - mode switching
 - config options
 - ACP-native plans
-- tool-based or structured plan generation
+- `Tool Plans` or `Structured Plans` plan generation
 - custom slash command providers
 - session replay and fork/resume/load/close/list lifecycle
 - slash command discovery and rendering
@@ -205,6 +224,10 @@ This package should be the reference answer whenever the question is:
 
 High-value bridges include:
 
+- `PrepareToolsBridge`
+- `PrepareOutputToolsBridge`
+- `ThinkingBridge`
+- `HookBridge`
 - `ThreadExecutorBridge`
 - `SetToolMetadataBridge`
 - `IncludeToolReturnSchemasBridge`

COVERAGE

@@ -1,2 +1,2 @@
-Line coverage: 100.00% (8781 / 8781)
-Branch coverage: 100.00% (2942 / 2942)
+Line coverage: 100.00% (8957 / 8957)
+Branch coverage: 100.00% (2998 / 2998)

VERSION

@@ -1 +1 @@
-0.9.3
+0.9.4

docs/api/pydantic_acp.md

@@ -78,6 +78,10 @@ This page documents the public surface re-exported by `pydantic_acp`.
 
 ::: pydantic_acp.PrepareToolsMode
 
+::: pydantic_acp.PrepareOutputToolsBridge
+
+::: pydantic_acp.PrepareOutputToolsMode
+
 ::: pydantic_acp.ThinkingBridge
 
 ::: pydantic_acp.HookBridge

docs/bridges.md

@@ -260,6 +260,19 @@ Use it for:
 
 It is the bridge most real coding-agent setups start with.
 
+### `PrepareOutputToolsBridge`
+
+Shapes output-tool availability per mode.
+
+Use it when:
+
+- structured-output tools should be filtered separately from normal function tools
+- ACP session metadata should expose the active output-tool mode
+- output-tool preparation should emit ACP-visible progress and failure updates
+
+This mirrors `PrepareToolsBridge`, but targets Pydantic AI's
+`PrepareOutputTools` capability.
+
 ### `ThinkingBridge`
 
 Exposes Pydantic AI’s `Thinking` capability through ACP session config.
@@ -275,6 +288,10 @@ Adds a `Hooks` capability into the active agent.
 
 Useful when you want ACP-visible hook updates that come from bridge-owned hooks rather than only from hooks already attached to the source agent.
 
+The bridge covers the current Pydantic AI hook surface, including tool
+preparation, output-tool preparation, output validation, output processing, and
+deferred tool-call observation.
+
 You can also suppress noisy default hook rendering with:
 
 ```python

docs/llms-full.txt

@@ -1362,21 +1362,25 @@ If you are integrating `pydantic-acp` in a real product:
 
 ## Version Compatibility And Private Upstream APIs
 
-`pydantic-acp` currently pins `pydantic-ai-slim==1.83.0`.
+`pydantic-acp` currently pins `pydantic-ai-slim==1.92.0`.
 
 That is not accidental. The adapter relies on a specific, tested Pydantic AI
 surface and should still be upgraded deliberately.
 
-However, ACP Kit no longer imports Pydantic AI private history-processor
-modules directly. History processor support is expressed through ACP Kit's own
-callable aliases and passed into the public
-`Agent(..., history_processors=...)` interface.
+The current compatibility surface includes function-tool preparation,
+output-tool preparation, output validation/processing hooks,
+deferred-tool-call hooks, run metadata, and conversation IDs.
+
+ACP Kit also no longer imports Pydantic AI private history-processor modules
+directly. History processor support is expressed through ACP Kit's own callable
+aliases and passed into the public `Agent(..., history_processors=...)`
+interface.
 
 What this means in practice:
 
 - the adapter is less exposed to private upstream type-module churn
-- upgrades are still compatibility work, but the history-processor integration
-  is no longer a direct private-import dependency
+- upgrades are still compatibility work, but Pydantic AI integration points stay
+  isolated behind ACP Kit bridge and runtime seams
 
 ### LangChain ACP Overview
 URL: https://vcoderun.github.io/acpkit/langchain-acp/
@@ -1464,10 +1468,13 @@ called inside `graph_factory=...`.
 - `AdapterConfig`
 - explicit session stores and transcript replay
 - provider-owned models, modes, and config options
+- prompt capability advertisement
 - native ACP plan state with `TaskPlan`
-- approval bridging
+- approval bridging with projection-aware permission cards
 - capability bridges
+- built-in and host-defined slash commands
 - projection maps and event projection maps
+- external hook event projection
 - ACP-facing type exports in `langchain_acp.types`
 
 The important difference is upstream shape, not ACP Kit architecture. On the LangChain side the adapter deals in graphs and middleware instead of model profiles and tool preparers.
@@ -1513,6 +1520,51 @@ The point is not to make the adapter magical. The point is to keep the host,
 the graph, and the ACP surface aligned without inventing runtime state the graph
 cannot really honor.
 
+## Prompt Capabilities And Slash Commands
+
+Prompt capability advertisement is configurable instead of hardcoded:
+
+```python
+from langchain_acp import AdapterConfig, AdapterPromptCapabilities
+
+config = AdapterConfig(
+    prompt_capabilities=AdapterPromptCapabilities(
+        audio=False,
+        image=False,
+        embedded_context=True,
+    )
+)
+```
+
+The adapter also owns an ACP-native slash-command layer:
+
+- mode commands such as `/ask`
+- `/model`
+- `/tools`
+- `/mcp-servers`
+- custom host commands through `slash_command_provider`
+
+```python
+from acp.schema import AvailableCommand
+from langchain_acp import (
+    AdapterConfig,
+    SlashCommandResult,
+    StaticSlashCommand,
+    StaticSlashCommandProvider,
+)
+
+config = AdapterConfig(
+    slash_command_provider=StaticSlashCommandProvider(
+        commands=[
+            StaticSlashCommand(
+                command=AvailableCommand(name="ping", description="Return pong."),
+                handler=lambda _request: SlashCommandResult(text="pong"),
+            )
+        ]
+    )
+)
+```
+
 ## Session Lifecycle And Replay
 
 Session lifecycle is first-class:
@@ -1589,10 +1641,23 @@ The adapter surface is:
 
 - `ApprovalBridge`
 - `NativeApprovalBridge`
+- `ProjectionAwareApprovalBridge`
+- `PermissionToolCallBuilder`
+- `ApprovalPolicyStore`
 - ACP permission requests and resume flow
 
 When the runtime really pauses for approval, the ACP session pauses for approval too.
 
+Remembered approval choices and permission card rendering live on `NativeApprovalBridge`:
+
+```python
+from langchain_acp import NativeApprovalBridge
+
+config = AdapterConfig(
+    approval_bridge=NativeApprovalBridge(enable_persistent_choices=True),
+)
+```
+
 ## Capability Bridges And Graph Build Contributions
 
 ACP Kit's bridge architecture remains intact in the LangChain adapter.
@@ -1604,6 +1669,7 @@ Built-in bridges:
 - `ConfigOptionsBridge`
 - `ToolSurfaceBridge`
 - `DeepAgentsCompatibilityBridge`
+- `ExternalHookEventBridge`
 
 Graph-build contributions are aggregated through:
 
@@ -3432,6 +3498,19 @@ Use it for:
 
 It is the bridge most real coding-agent setups start with.
 
+### `PrepareOutputToolsBridge`
+
+Shapes output-tool availability per mode.
+
+Use it when:
+
+- structured-output tools should be filtered separately from normal function tools
+- ACP session metadata should expose the active output-tool mode
+- output-tool preparation should emit ACP-visible progress and failure updates
+
+This mirrors `PrepareToolsBridge`, but targets Pydantic AI's
+`PrepareOutputTools` capability.
+
 ### `ThinkingBridge`
 
 Exposes Pydantic AI’s `Thinking` capability through ACP session config.
@@ -3447,6 +3526,10 @@ Adds a `Hooks` capability into the active agent.
 
 Useful when you want ACP-visible hook updates that come from bridge-owned hooks rather than only from hooks already attached to the source agent.
 
+The bridge covers the current Pydantic AI hook surface, including tool
+preparation, output-tool preparation, output validation, output processing, and
+deferred tool-call observation.
+
 You can also suppress noisy default hook rendering with:
 
 ```python
@@ -6169,6 +6252,10 @@ This page documents the public surface re-exported by `pydantic_acp`.
 
 ::: pydantic_acp.PrepareToolsMode
 
+::: pydantic_acp.PrepareOutputToolsBridge
+
+::: pydantic_acp.PrepareOutputToolsMode
+
 ::: pydantic_acp.ThinkingBridge
 
 ::: pydantic_acp.HookBridge

docs/pydantic-acp.md

@@ -270,18 +270,22 @@ If you are integrating `pydantic-acp` in a real product:
 
 ## Version Compatibility And Private Upstream APIs
 
-`pydantic-acp` currently pins `pydantic-ai-slim==1.83.0`.
+`pydantic-acp` currently pins `pydantic-ai-slim==1.92.0`.
 
 That is not accidental. The adapter relies on a specific, tested Pydantic AI
 surface and should still be upgraded deliberately.
 
-However, ACP Kit no longer imports Pydantic AI private history-processor
-modules directly. History processor support is expressed through ACP Kit's own
-callable aliases and passed into the public
-`Agent(..., history_processors=...)` interface.
+The current compatibility surface includes function-tool preparation,
+output-tool preparation, output validation/processing hooks,
+deferred-tool-call hooks, run metadata, and conversation IDs.
+
+ACP Kit also no longer imports Pydantic AI private history-processor modules
+directly. History processor support is expressed through ACP Kit's own callable
+aliases and passed into the public `Agent(..., history_processors=...)`
+interface.
 
 What this means in practice:
 
 - the adapter is less exposed to private upstream type-module churn
-- upgrades are still compatibility work, but the history-processor integration
-  is no longer a direct private-import dependency
+- upgrades are still compatibility work, but Pydantic AI integration points stay
+  isolated behind ACP Kit bridge and runtime seams

packages/adapters/langchain-acp/VERSION

@@ -1 +1 @@
-0.9.3
+0.9.4

packages/adapters/langchain-acp/src/langchain_acp/_version.py

@@ -2,4 +2,4 @@
 
 __all__ = ("__version__",)
 
-__version__ = "0.9.3"
+__version__ = "0.9.4"