Migrate Pi to Pydantic AI

Preserve observable behavior, not Pi's TypeScript API. Migrate the smallest complete caller path and keep product/host infrastructure in the application.

Trace the source before choosing a target

1. Read repository instructions, package.json, Pi settings, tests, extension/package manifests, and runtime entrypoints. Record the installed Pi, Pydantic AI, and Harness versions.
2. Trace one real request from the Pi CLI, RPC boundary, or createAgentSession().prompt() through resource discovery, system instructions, tools, extensions, model requests, messages, compaction/retry, events, session entries, UI/RPC output, and side effects. Establish a focused baseline or characterization test.
3. Inventory every active extension factory and package resource. For each pi.on(...), registerTool, registerCommand, provider registration, renderer/UI contribution, skill, prompt, and persisted entry, record its firing point, trusted inputs, mutations, output, state owner, and caller-visible effect.
4. Separate these contracts when present:
   • model messages, append-only session entries/tree branches, compaction summaries, and extension state;
   • model-chosen tool input, trusted host context, project trust, approval, authorization, and OS isolation;
   • token deltas, tool lifecycle, Pi extension events, capability events, RPC events, and terminal rendering;
   • agent-loop behavior, CLI/TUI host behavior, provider transport, package distribution, and external side effects.
5. Record each observed contract, its owner, semantic difference, and executable proof. An installed but inactive Pi package feature is not migration scope.

Read Research and concept mapping for the detected features. Read Verification and cutover before implementation.

Treat extensions as capability candidates