feat: post-v0.8 roadmap — extensible agent adapters and execution transports #47

Follows #44 (v0.6), #45 (v0.7), and #46 (v0.8). Begin the extension contract after those adapters and integrations supply evidence for its design.

Motivation

After the Claude/Codex adapters and their delivery semantics are exercised, supporting another coding agent should not require duplicating discovery, SSH dispatch, reply routing, and diagnostics throughout the CLI.

Post-v0.8 direction: an extensible adapter/transport architecture for agents beyond Claude Code and Codex. Do not build a public plugin ABI before the first two adapters expose the capabilities and limitations it needs to represent.

Does the official path already cover it?

Each supported agent's native discovery and messaging interfaces should remain the source of truth. session-peer supplies common routing and presentation across those interfaces; it should not replace native queues, execution policies, or authentication.

Where an agent has no supported inbox or equivalent mechanism, report that capability as unavailable rather than silently using terminal key injection.

Proposed behaviour

• Separate agent adapters (identity, discovery, native enqueue/post, lifecycle capabilities) from host execution transports (local/SSH). Codex and Claude are agents; SSH is a destination execution mechanism. Avoid conflating the two extension boundaries.
• Define a minimal versioned contract for session identity, capabilities, submission results, and typed errors after collecting experience from the previous releases. Wait, wake, and acknowledgement are optional capabilities, not requirements every backend must pretend to implement.
• Route existing CLI, reply addresses, diagnostics, and MCP tools through the same contracts. Preserve agent-prefixed targets and destination-specific context.
• Initially exercise the extension point with built-in adapters and a deterministic test adapter. Specify external-plugin packaging, compatibility/version negotiation, and explicit configuration/trust boundaries before offering external loading.
• Keep standalone Claude/Codex usage lightweight. External plugins must not be downloaded, installed, or executed merely because a received message references an unfamiliar agent or URI.

Acceptance criteria

• An architectural decision records the agent/transport split, result semantics, unsupported capabilities, packaging, and compatibility strategy based on v0.6–v0.8 findings.
• Both existing adapters retain local/SSH behaviour and pass a shared contract suite without breaking current targets or JSON consumers.
• A deterministic third test adapter can be added without editing CLI routing or duplicating SSH dispatch; adding it requires no live model account.
• Optional wait/wake/ack capabilities are advertised and unsupported operations fail clearly.
• Unknown agent names, incompatible plugin contracts, load failures, and plugin errors are contained and tested.
• Extension documentation includes a minimal adapter example and an explicit installation/configuration model; optional dependencies remain separate from the core CLI.

This is a later architectural roadmap item. New concrete agent integrations should get their own issues with native-interface evidence and acceptance tests, following the repository's issue → branch → PR workflow.