1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
//! Core types, traits, manifest parser, and plan computation for repolith.
//!
//! This crate is the foundation of the workspace. It carries **no `tokio`
//! runtime dependency** — only lightweight runtime-agnostic combinators
//! from `futures` (used inside `Plan::compute` to fan probes out
//! concurrently). The orchestrator + executor live one crate up in
//! `repolith-engine`, which pulls in `tokio`. The split lets downstream
//! consumers (CLI, future TUI/LSP, telemetry) pull the lightweight types
//! here without dragging the runtime tree.
//!
//! # Modules at a glance
//!
//! - [`types`] — value types: `ActionId`, `Sha256`, `BuildEvent`, `Ctx`
//! (carries the `CancellationToken`), `BuildError`, `ExecMode`.
//! - [`action`] — `trait Action`: `id`, `deps`, `input_hash`, `execute`.
//! - [`cache`] — `trait Cache` + `CacheError`. Implementations live in
//! `repolith-cache`.
//! - [`plan`] — `Plan::compute` (Kahn topological sort + cascading
//! staleness via `ChangeReason`).
//! - [`manifest`] — `Manifest::from_toml` (parse + validate
//! `repolith.toml`).
//!
//! # Typical use
//!
//! ```ignore
//! use repolith_core::manifest::Manifest;
//!
//! let toml = std::fs::read_to_string("repolith.toml")?;
//! let manifest = Manifest::from_toml(&toml)?;
//! for id in manifest.action_ids() {
//! println!("{id}");
//! }
//! ```
//!
//! Actually executing the plan happens through `repolith-engine`'s
//! `Orchestrator`, which consumes the types defined here.
/// Value types used across the workspace.
/// `Action` trait — one unit of orchestrated work.
/// `Cache` trait + `CacheError`. Concrete backends live in dependent crates.
/// Layered execution plan with cascading staleness reasons.
/// Manifest schema and parser (`repolith.toml`).