trusty_review/lib.rs
1//! `trusty-review` — fast local PR-review service.
2//!
3//! Why: orchestrates LLM-backed code review as a standalone crate within the
4//! trusty-tools workspace, consuming trusty-search (context retrieval) and an
5//! LLM provider (OpenRouter or Bedrock) to produce structured review verdicts.
6//!
7//! What: exposes `config`, `llm`, `models`, `integrations`, and `pipeline`.
8//! Stage-1 delivered config + LLM provider abstraction; Stage-2 adds the
9//! integration clients (GitHub App auth, trusty-search/analyze HTTP clients);
10//! Stage-3 adds the MVP review pipeline and the `run`/`compare` CLI commands;
11//! Stage-4 adds the `service` module — axum HTTP server with /health, /status,
12//! /review, and /pr/github/webhook (gated behind the `http-server` feature).
13//!
14//! Test: each public module carries its own unit tests; see each submodule.
15
16pub mod config;
17pub mod integrations;
18pub mod llm;
19pub mod models;
20pub mod pipeline;
21// Why: coverage ingestion and verdict-gating (issue #1014). Always compiled —
22// no feature gate — because `CoveragePolicy` is a pure data type used by
23// `ReviewConfig` and the runner in all modes. The feature is off by default
24// (opt-in via `TRUSTY_REVIEW_COVERAGE_ENABLED=true`).
25pub mod coverage;
26// Why: the voice module holds the 3-layer prompt composition types and logic
27// (stock → principles → voice). Always compiled — no feature gate — because
28// VoiceConfig is a pure data type used by the prompt builder in all modes.
29pub mod voice;
30// Why: Phase 1 (#582) adds live posting, which needs a durable cross-process
31// dedup claim store (redb) and an in-process in-flight guard. These storage
32// and concurrency concerns live in their own module, separate from the
33// pipeline. Always compiled — no feature gate (no axum/HTTP dependency).
34pub mod store;
35// Why: longitudinal contributor profiling (epic #558) requires a dedicated
36// module for data models, identity resolution, period assembly, and diff
37// sampling. Gated behind the `profile` feature because it pulls in tga and
38// rusqlite (heavy deps with vendored C libraries) that users who only need the
39// core review pipeline should not have to compile.
40#[cfg(feature = "profile")]
41pub mod profile;
42
43// Why: the service module is gated behind `http-server` so library consumers
44// that only need the pipeline (CLI one-shot, unit tests) do not pull in the
45// full axum + tower-http stack.
46#[cfg(feature = "http-server")]
47pub mod service;
48
49// Why: the MCP module is gated behind the `mcp` feature so library consumers
50// that do not need the stdio JSON-RPC loop do not pull in trusty-common's MCP
51// primitives. Enabled by default in the binary so `serve --stdio` is always
52// available. The `mcp` feature implies `http-server` (AppState is defined there).
53#[cfg(feature = "mcp")]
54pub mod mcp;