Migrate specials.rs (History, ToolCall, NoTool) to typed architecture

[darinkishore]

Context

core/specials.rs currently defines:

• History — schemars-derived placeholder
• ToolCall — schemars-derived placeholder (name-collides with rig::message::ToolCall)
• NoTool / NoToolError — rig::Tool impl placeholder

These are features, not dead code — History and Tools are important for the DSPy programming model. But they're wired to the old schemars plumbing, not the BamlType/Facet/SignatureSchema typed path.

DSPy Python has:

• dspy.Tool — wraps Python functions, auto-extracts name + args schema from type hints
• dspy.ToolCalls — output field type for tool call results
• list[dspy.Tool] as an input field type recognized by the Adapter
• Native function calling detection: if model supports it, tools go via LM API; otherwise formatted in prompt text

What's needed

Migrate types to BamlType + Facet

• History → #[derive(BamlType, Facet)] instead of #[derive(Serialize, JsonSchema)]
• ToolCall → rename to avoid collision with rig's ToolCall, derive BamlType + Facet
• These should be recognizable as special field types in SignatureSchema

Adapter-level tool awareness

• ChatAdapter should detect Tool/ToolCalls fields in a signature
• If model supports native function calling → route via LM API tools
• Otherwise → format tool descriptions in prompt text (like DSPy's fallback)

Wire NoTool properly

• Or remove it if rig's tool abstraction is sufficient
• Current NoTool is a rig::Tool impl that returns "No tool" — placeholder

Post-schemars

• Once this + field!/sign! macros are migrated, schemars dep can be dropped

Related

• fully remove untyped signatures #52 (remove untyped signatures)
• derive macro typed issues #54 (derive macro typed issues)
• LM tool loop treats max_tool_iterations=1 as immediate failure #61 (tool loop bug)

[darinkishore]

Codebase audit — current state of specials.rs

// core/specials.rs — 44 lines total
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

#[derive(Serialize, JsonSchema, Clone)]
pub struct History;

#[derive(Deserialize, JsonSchema, Clone)]
pub struct ToolCall;  // name-collides with rig::message::ToolCall

pub struct NoTool;
// ... rig::tool::Tool impl that returns "No tool"

What needs to happen:

1. History → #[BamlType] derive. Needs to be recognizable by ChatAdapter as a special field type that gets formatted as conversation history in the prompt (DSPy injects few-shot demos here).

2. ToolCall → rename to DsrsToolCall or ToolCallOutput to avoid collision with rig::message::ToolCall. Derive #[BamlType]. Should represent the output type when tools are used.

3. NoTool → evaluate if still needed. The rig::Tool impl is a placeholder. If LM::call() already handles the no-tools case (it does — tools param is Vec<Arc<dyn ToolDyn>>), then NoTool might be deletable.

4. Adapter-level tool awareness — ChatAdapter should detect when a signature has Tool/ToolCall fields and:

   • If model supports native function calling → route via API tools param
   • Otherwise → format tool descriptions as text in the prompt (DSPy's fallback path)

This is small but has design implications for how tools integrate with the typed signature system. The type itself is easy to migrate; the adapter integration is the real work.