//! # rutster (lib) — slice-1 binary library target
//!
//! Thin library surface re-exporting the modules the `main.rs` binary
//! and the `tests/api_integration.rs` integration test both need.
//!
//! # Why a `lib.rs` *and* a `main.rs`?
//!
//! Pure binary crates (`src/main.rs` only) do not surface items via the
//! crate's external path (`rutster::routes::router`) — Cargo's
//! integration tests (`tests/*.rs`) link against the *library* target,
//! not the binary target. With `pub mod` declared only in `main.rs`,
//! `use rutster::routes::router` in the integration test fails to
//! resolve (`E0433`). The library/binary split (the standard Cargo
//! pattern: a crate compiles both `lib.rs` → `librutster` and `main.rs`
//! → `rutster`, with the binary linking the library) makes the same
//! `pub mod` declarations visible to both consumers. `main.rs` then
//! imports them via `use rutster::...` paths exactly as the brief's
//! Step 6 sketches.
//!
//! ## Architecture refs
//!
//! - [slice-1 spec §4](../../docs/superpowers/specs/2026-06-28-slice-1-webrtc-loopback-design.md)
//! - [ARCHITECTURE.md](../../docs/ARCHITECTURE.md) — fused vertical.

pub mod config;
pub mod event_sink;
pub mod media_thread;
pub mod metrics;
pub mod routes;
pub mod serve;
pub mod serve_tls;
pub mod session_map;
pub mod tap_engine;
pub mod tls_acceptor;
pub mod tool_registry;
pub mod valkey_sink;
