protocol-droid 0.3.0

// `dead_code_pub_in_binary` was promoted to library crates in rust 1.98. The
// library exposes types that downstream users (e.g. an editor that spawns an
// ACP agent and needs an MCP client to talk to its tool servers) consume; the
// workspace's own bin does not use every public type, and the library's own
// test build does not see the integration test crate as a dependent. The
// allow is necessary for the library's test build to pass; it is a no-op for
// the library's normal build (where the lint is "unused" — see
// `unused_attributes` below) and does not propagate to dependents.
#![allow(dead_code_pub_in_binary, unused_attributes)]

//! The `protocol-droid` library: one canonical IR, many per-revision codecs.
//!
//! Application code in this crate speaks a version-agnostic superset IR. Each
//! per-revision codec lifts wire messages into that IR on the way in and
//! lowers them back to the wire on the way out, for whichever revision was
//! negotiated with the peer. Every feature-specific path consults the session's
//! negotiated `FeatureProfile` before it runs.
//!
//! The layer split is the project's hexagonal layout:
//!
//! - [`domain`] — value objects, aggregates and pure functions. No I/O, no
//!   runtime, no framework derives.
//! - [`application`] — one module per use case. Each declares its own narrow
//!   port trait inline, beside the handler that consumes it.
//! - [`adapters::primary`] — driving adapters: the server transports.
//! - [`adapters::secondary`] — driven adapters: the client transports, upstream
//!   peers, clocks, RNG and the filesystem.
//!
//! There is deliberately no `ports` module. Port traits belong to the consumer,
//! so they live in the `application` module that needs them, and are never
//! collected into a shared module.
//!
//! # What the attribute macros need
//!
//! [`schemars`], [`serde`] and [`serde_json`] are re-exported so code generated by
//! `#[server]` names them through this crate. Generated code that
//! spelled `::schemars` and `::serde` would force every user of a macro to
//! depend on both crates themselves, at versions the macro happened to be built
//! against, with no way to disagree — and a mismatch would be a compile error
//! in generated code, which is the worst place to discover a version problem.

pub mod adapters;
pub mod application;
pub mod domain;

pub use protocol_droid_macros::{prompt, resource, server, tool};
pub use schemars;
pub use serde;
pub use serde_json;