arcature 2026.2.0

Arcature application framework: a high-level Application facade over the certified Arcature subsystems, with the low-level Axum/Tower escape hatch preserved.
Documentation 
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65

//! The Arcature system-check framework (AP2.1-7).
//!
//! A Django-inspired self-diagnostic layer: each contributor (the framework,
//! a subsystem the application uses, the application itself) declares a
//! `&'static` slice of [`SystemCheck`] trait objects, and [`run`] (see
//! `registry`) aggregates them into one [`SystemCheckReport`] consumed by
//! `arc doctor --checks` and, later, the MCP `system_checks` tool (AP2.1-9).
//!
//! # Why here, not in the CLI
//!
//! The trait lives in `arcature` so the framework and the application can
//! contribute checks without depending on the CLI. The CLI consumes the
//! framework's checks (see `framework_checks`) and the application's own
//! checks; it does not own the trait. Subsystem crates (`arcature-db`, …)
//! CANNOT depend on `arcature` (the dependency direction is facade →
//! subsystem — AGENTS.md §16), so a subsystem contributes its checks
//! through the application's bootstrap: the app collects `&'static`
//! slices from each subsystem it uses. That application-side aggregation
//! is future work gated on AP2.1-6 (Data) and the subsystem phases.
//!
//! # No global mutable state (AGENTS.md §20)
//!
//! There is no `inventory`/`linkme` distributed slice, no global registry,
//! no lazy static. The "registry" is a pure function over the slices the
//! caller passes. The application wires its slices at bootstrap; the
//! wiring is visible and auditable at that one site.
//!
//! # No secret in output
//!
//! A check's `context` and `fix_hint` are framework / application strings.
//! The framework does not double-redact check output (a check is not
//! hostile protocol input); a check author redacts any value before
//! placing it in the result. The Inspector redaction layer
//! (`arcature_observe::redact::inspector`) is the foundation the served
//! `/_arc` UI will apply to all displayed values when it lands.
//!
//! # Feature gating
//!
//! The trait, IDs, severity, category, and the non-serializable
//! `CheckResult` / `SystemCheckReport` are always available (no feature
//! gate). The JSON-serializable views (`CheckResultJson`,
//! `SystemCheckReportJson`, `SystemCheckReport::to_json_view`) require the
//! `serde` feature, matching the established `Json<T>` / `Page<T>` pattern
//! (A4). The framework's own checks are always available;
//! `SpanContractCheck` additionally requires `observe` (it reads the
//! observe subsystem's span contract).

pub mod category;
pub mod check;
pub mod framework_checks;
pub mod id;
pub mod registry;
pub mod report;
pub mod severity;

pub use category::CheckCategory;
pub use check::SystemCheck;
pub use framework_checks::CHECKS as FRAMEWORK_CHECKS;
pub use id::{CheckId, CheckIdError};
pub use registry::run;
pub use report::{CheckResult, CheckStatus, SystemCheckReport};
pub use severity::CheckSeverity;

#[cfg(feature = "serde")]
pub use report::{CheckResultJson, SystemCheckReportJson};