aonyx_api/lib.rs
1//! # aonyx-api
2//!
3//! The Aonyx Agent **automation API**: a REST + WebSocket surface over the
4//! same core that powers the CLI/TUI. It is a thin transport — every
5//! endpoint bottoms out in the existing `aonyx-*` crates, no agent-loop
6//! logic is reimplemented here.
7//!
8//! This crate is feature-driven by the binary: `aonyx-agent` depends on it
9//! behind its `api` feature and serves [`build_router`] via
10//! `aonyx serve api`. To avoid a dependency cycle, `aonyx-api` never
11//! depends on `aonyx-agent`; the agent loop is injected through a trait
12//! (added in a later phase), exactly like the channel adapters.
13//!
14//! ## Surface (grown phase by phase)
15//! - **V4.1 (this scaffold)** — [`build_router`] with `/v1/health` (open)
16//! and `/v1/info` (bearer-authed), [`ApiState`], [`AuthConfig`],
17//! [`ServerInfo`], and the [`ApiError`] response type.
18//! - V4.2 — sessions + blocking turns.
19//! - V4.3 — WebSocket / SSE streaming.
20//! - V4.4 — memory palace, tools, skills, config, OpenAPI.
21
22#![forbid(unsafe_code)]
23#![warn(missing_docs, rust_2018_idioms)]
24
25mod agent;
26mod auth;
27pub mod error;
28mod memory;
29mod meta;
30mod openai;
31mod routes;
32mod server;
33mod sessions;
34mod state;
35mod streaming;
36
37pub use agent::{ApiAgent, ConfigInfo, SkillInfo, StreamFrame, ToolInfo};
38pub use error::{ApiError, ApiResult};
39pub use routes::build_router;
40pub use server::serve;
41pub use state::{ApiState, AuthConfig, ServerInfo};