// @generated by jacquard-lexicon. DO NOT EDIT.
//
// This file was automatically generated from Lexicon schemas.
// Any manual changes will be overwritten on the next regeneration.

//! Generated AT Protocol Lexicon bindings.
//!
//! This crate contains Rust bindings generated from Lexicon schemas. Most
//! application code uses these types through the `jacquard::api` re-export,
//! alongside `jacquard::Client` or one of the higher-level session helpers.
//!
//! ## Finding things
//!
//! Lexicon NSIDs map to Rust modules by replacing dots with module separators
//! and using snake_case for Rust identifiers. For example,
//! `app.bsky.feed.getTimeline` is generated under
//! `app_bsky::feed::get_timeline`.
//!
//! Top-level namespace modules are feature-gated. Enable the feature matching
//! the top-level namespace module, such as `app_bsky` or `com_atproto`, to use
//! those bindings.
//!
//! ## String backing
//!
//! Many generated data types are generic over a string backing type,
//! usually written as `S: BosStr = DefaultStr`. The generic is part of the
//! public API: use the default owned backing when you do not need to choose,
//! or select another backing such as `String`, `&str`, or `CowStr<'_>` when
//! that is useful for your code.
//!
//! Common examples omit the generic because the default is inferred in the
//! usual request/response paths.
//!
//! ## XRPC endpoints
//!
//! Endpoint modules contain request parameter/input structs, output structs,
//! error enums, and marker types implementing
//! `jacquard_common::xrpc::{XrpcRequest, XrpcResp, XrpcEndpoint}`. High-level
//! client code normally constructs the request struct or marker type and sends
//! it with `jacquard::Client`, then uses response helpers such as
//! `into_output()` for default-backed output.
//!
extern crate alloc;

#[cfg(feature = "app_bsky")]
pub mod app_bsky;
pub mod builder_types;


#[cfg(feature = "com_atproto")]
pub mod com_atproto;


#[cfg(feature = "space_polymodel")]
pub mod space_polymodel;