Skip to main content

ralph_workflow/
lib.rs

1// Lint policy: the style guide is authoritative.
2//
3// See `CODE_STYLE.md`, `docs/code-style/boundaries.md`,
4// `docs/code-style/coding-patterns.md`, `docs/code-style/testing.md`, and
5// `docs/tooling/dylint.md` when fixing violations.
6//
7// This library intentionally keeps boundary-sensitive policy in dylint so
8// domain modules stay strict without blocking legitimate `io/`, `runtime/`,
9// `ffi/`, and `boundary/` code.
10//
11// `unsafe_code` is not denied here because the library contains documented
12// POSIX boundary code that requires small unsafe sections.
13//
14// `clippy::cargo` stays off because it reports ecosystem dependency conflicts
15// rather than code-shape problems contributors can fix locally.
16#![deny(warnings)]
17#![deny(clippy::all)]
18#![deny(
19    // No explicit iterator loops when a more idiomatic form exists
20    clippy::explicit_iter_loop,
21    clippy::explicit_into_iter_loop,
22    // Debug
23    clippy::dbg_macro,
24    // Push toward combinators instead of hand-written control flow
25    clippy::manual_map,
26    clippy::manual_filter,
27    clippy::manual_find,
28    clippy::manual_filter_map,
29    clippy::manual_flatten,
30    clippy::needless_collect
31)]
32// `unwrap_used`, `expect_used`, and blanket panic bans are not enforced at this
33// crate root because the relevant policy is boundary-sensitive. Fix ordinary code
34// to use `Result`, `?`, and explicit state/value transformations; if the code is a
35// real boundary concern, keep it in an explicit boundary module instead of weakening
36// the lint.
37//! Ralph workflow library for AI agent orchestration.
38//!
39//! This crate provides the core functionality for the `ralph` CLI binary,
40//! implementing a reducer-based architecture for orchestrating AI coding agents
41//! through development and review cycles.
42//!
43//! # Quick Start
44//!
45//! Ralph is primarily a CLI binary. For library use (integration testing):
46//!
47//! ```toml
48//! [dev-dependencies]
49//! ralph-workflow = { version = "0.6", features = ["test-utils"] }
50//! ```
51//!
52//! # Architecture
53//!
54//! Ralph uses an **event-sourced reducer architecture**. The core state machine
55//! follows the pattern:
56//!
57//! ```text
58//! State → Orchestrator → Effect → Handler → Event → Reducer → State
59//! ```
60//!
61//! | Component | Pure? | Role |
62//! |-----------|-------|------|
63//! | [`reducer::PipelineState`] | Yes | Immutable progress snapshot, doubles as checkpoint |
64//! | [`reducer::reduce`] | Yes | `(State, Event) → State` |
65//! | [`reducer::determine_next_effect`] | Yes | `State → Effect` |
66//! | [`reducer::EffectHandler`] | No | Executes effects, produces events |
67//!
68//! Business logic lives in reducers (pure). I/O lives in handlers (impure).
69//!
70//! ## Two Effect Layers
71//!
72//! Ralph has two distinct effect types for different pipeline stages:
73//!
74//! | Layer | Module | When | Filesystem Access |
75//! |-------|--------|------|-------------------|
76//! | `AppEffect` | [`app`] | Before repo root known | `std::fs` directly |
77//! | `Effect` | [`reducer`] | After repo root known | Via [`workspace::Workspace`] |
78//!
79//! These layers must never mix: `AppEffect` cannot use `Workspace`, and `Effect`
80//! cannot use `std::fs` directly.
81//!
82//! # I/O Abstractions
83//!
84//! All I/O is abstracted through traits for testability:
85//!
86//! - [`workspace::Workspace`] - Filesystem operations
87//!   - Production: [`workspace::WorkspaceFs`]
88//!   - Tests: `MemoryWorkspace` (with `test-utils` feature)
89//! - [`ProcessExecutor`] - Process spawning
90//!   - Production: [`RealProcessExecutor`]
91//!   - Tests: `MockProcessExecutor` (with `test-utils` feature)
92//!
93//! # Feature Flags
94//!
95//! - `monitoring` (default) - Enable streaming metrics and debugging APIs
96//! - `test-utils` - Enable test utilities (`MockProcessExecutor`, `MemoryWorkspace`, etc.)
97//! - `hardened-resume` (default) - Enable checkpoint file state capture for recovery
98//!
99//! # Key Modules
100//!
101//! **Core Architecture:**
102//! - [`reducer`] - Core state machine with pure reducers and effect handlers
103//! - [`app`] - CLI layer operating before repo root is known (`AppEffect`)
104//! - [`phases`] - Pipeline phase implementations (planning, development, review, commit)
105//!
106//! **I/O Abstractions:**
107//! - [`workspace`] - Filesystem abstraction (`WorkspaceFs` production, `MemoryWorkspace` testing)
108//! - [`executor`] - Process execution abstraction for agent spawning
109//!
110//! **Agent Infrastructure:**
111//! - [`agents`] - Agent configuration, registry, and CCS (Claude Code Switch) support
112//! - [`json_parser`] - NDJSON streaming parsers for Claude, Codex, Gemini, `OpenCode`
113//! - [`prompts`] - Template system for agent prompts
114//!
115//! **Supporting:**
116//! - [`git_helpers`] - Git operations using libgit2 (no CLI dependency)
117//! - [`checkpoint`] - Pipeline state persistence for `--resume` support
118//! - [`config`] - Configuration loading and verbosity levels
119//!
120//! # Error Handling
121//!
122//! Most functions return `anyhow::Result` for flexible error handling with context.
123//! Use `.context()` to add context to errors as they propagate.
124
125pub mod agents;
126pub mod app;
127pub mod banner;
128pub mod boundary;
129pub mod checkpoint;
130pub mod cli;
131pub mod cloud;
132pub mod common;
133pub mod config;
134pub mod config_loading;
135pub mod diagnostics;
136pub mod executor;
137pub mod exit_pause;
138pub mod files;
139pub mod git_helpers;
140pub mod guidelines;
141pub mod interrupt;
142pub mod io;
143pub mod json_parser;
144pub mod language_detector;
145pub mod logger;
146pub mod logging;
147pub mod monitoring;
148pub mod phases;
149pub mod pipeline;
150pub mod platform;
151pub mod prompts;
152pub mod reducer;
153pub mod rendering;
154pub mod review_metrics;
155pub mod runtime;
156pub mod templates;
157pub mod workspace;
158
159#[path = "boundary/executor_reexports_boundary.rs"]
160mod executor_reexports_boundary;
161
162// Benchmarks module - contains public baselines used by integration tests.
163// Benchmark *tests* inside the module remain `#[cfg(test)]`.
164pub mod benchmarks;
165
166// Re-export XML extraction and validation functions for use in integration tests.
167// These functions parse and validate XML output from agent responses (plan, issues, fix results).
168pub use files::llm_output_extraction::extract_development_result_xml;
169pub use files::llm_output_extraction::extract_fix_result_xml;
170pub use files::llm_output_extraction::extract_issues_xml;
171pub use files::llm_output_extraction::validate_continuation_development_result_xml;
172pub use files::llm_output_extraction::validate_development_result_xml;
173pub use files::llm_output_extraction::validate_fix_result_xml;
174pub use files::llm_output_extraction::validate_issues_xml;
175pub use files::llm_output_extraction::validate_plan_xml;
176pub use files::llm_output_extraction::validate_xml_against_xsd;
177
178// Re-export process executor types for dependency injection.
179// See [`executor`] module for documentation.
180pub use executor_reexports_boundary::{
181    AgentChild, AgentChildHandle, AgentCommandResult, AgentSpawnConfig, ChildProcessInfo,
182    ProcessExecutor, ProcessOutput, RealAgentChild, RealProcessExecutor,
183};
184
185/// Re-export mock executor for test-utils feature.
186/// Use MockProcessExecutor to control process behavior in integration tests.
187#[cfg(any(test, feature = "test-utils"))]
188pub use executor_reexports_boundary::{MockAgentChild, MockProcessExecutor};
189
190pub use workspace::Workspace;