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
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
//! The curated Arcature prelude.
//!
//! `use arcature::prelude::*;` brings the normal-user surface into scope: the
//! [`Application`] engine, the low-level [`App`] kernel, the [`Routes`]
//! router alias, routing functions, common extractors and response helpers,
//! the engine [`Result`], and (when the `serde` feature is on) Serde's
//! `Serialize`/`Deserialize`.
//!
//! The prelude is deliberately *curated*, not a glob of every dependency (engine
//! spec §19): it avoids name collisions and wildcard re-exports of entire
//! upstream crates. The full surface of each subsystem lives under its facade
//! module (e.g. `arcature::inertia`, `arcature::db`) — reach for those when you
//! need a type not in the prelude.
//!
//! # Selected capability types
//!
//! When a subsystem feature is enabled, the prelude re-exports its primary
//! entry-point type so normal application code rarely needs a qualified path:
//!
//! | Feature | Prelude export |
//! |------------|----------------|
//! | `inertia` | `Inertia` |
//! | `db` | `Db` |
//! | `auth` | (use `arcature::auth` directly — sessions/CSRF/OAuth are context-dependent) |
//! | `cache` | `Cache` |
//! | `storage` | `Storage` |
//! | `mail` | `Mailer` |
//! | `jobs` | `Jobs` |
//! | `pages` | `Pages` |
//! | `observe` | `RequestId` |
//! | `api` | `Problem` |
//!
//! Enabling a feature *compiles* these APIs through the facade; it does not
//! connect to a runtime service (engine spec §14).
// Framework-owned types (always available — no feature gate).
pub use crateApp;
pub use crateApplication;
pub use crateResult;
pub use crateProxyAction;
pub use crateProxyRequest;
pub use crateRoutes;
// Routing constructors (the certified Axum functions, re-exported so normal
// code never names `axum::` directly).
pub use crate;
// Common HTTP extractors. `State` and `Path` live in `axum-core` and are
// always available. `Json`/`Query`/`Form` require axum's `json`/`query`/`form`
// features, which are activated by the `api` feature (arcature-api enables
// them); they are re-exported only when `api` is on so the minimal kernel
// stays minimal (engine spec §55).
pub use crate;
// Body-decoding extractors — available when the `api` feature activates
// axum's `json`/`query`/`form` features via arcature-api.
//
// `Json` is re-exported from axum here ONLY when the A4 `dx::Json` is not
// available (i.e. when `dx` + `serde` are both on, the higher-level
// `dx::Json` takes precedence and is re-exported below instead). This
// avoids a name collision when both `api` and `dx`+`serde` are enabled.
pub use crate;
pub use crate;
// Common response helpers.
pub use crate;
pub use crate;
// A4: high-level response types. `Empty` is always available when `dx` is on.
// `Json` and `Page` require `serde` (for serialization), so they are gated.
//
// When `dx`+`serde` and `api` are both on, `dx::Json` takes precedence over
// the raw `axum::Json` extractor — the axum re-export is suppressed above in
// that configuration so there is no name collision in the prelude.
pub use crateEmpty;
pub use crateJson;
pub use cratePage;
pub use cratepage;
// A5: the validated request extractor. `Validated<T>` combines JSON body
// extraction + deserialization + validation into one Axum `FromRequest`.
// Behind `dx` + `api` (needs `validator::Validate` and the `arcature-api`
// Problem infrastructure for 422 error responses).
pub use crateValidated;
// A6: page and resource DX macros.
//
// `#[page("name")]` (attribute) and `#[resource]` (attribute) are proc-macro
// attributes re-exported at the crate root and brought into scope here. They
// generate `impl ClientData`, `Serialize` derive, and (for `#[page]`) a
// `PageContract` const.
//
// `page!(...)` constructs a `Page<T>` with a compile-time `ClientData`
// assertion. Rust does not allow a function-like macro and an attribute
// macro to share the same name in one module, so the function-like proc
// macro is named `page_macro` at the crate root. Applications import it with
// a local rename: `use arcature::page_macro as page;` — or call it as
// `arcature::page_macro!(...)`.
pub use cratepage;
pub use cratepage_macro;
pub use crateresource;
// A7: route model binding. `RouteModel` is the trait a type implements to
// be loadable from the database by a route parameter. `Bound<T>` is the
// Axum extractor that loads the model and returns 404 on miss. Behind
// `dx` + `db` (+ `api` for Bound, which produces Problem responses).
pub use crateBound;
pub use crateRouteModel;
pub use crateroute_model;
// A8: typed services/providers (ADR-0004). `#[service]` generates `impl
// Resolve<S>` + `impl Service` + `impl DxComponent`; `#[provider]` generates
// `impl DxComponent` (the developer writes `impl Provider` by hand). `Inject<T>`
// is the Axum extractor that constructs any `T: Resolve<S>` from state. `Resolve`
// is the typed resolution trait — no runtime container (no TypeId/Any).
// `Service` and `Provider` are marker traits for `arc check` graph validation.
// Behind `dx` (services/providers are pure composition, not tied to a subsystem).
pub use crateprovider;
pub use crateservice;
pub use crate::;
// A9: auth/policies/session/flash (ADR-0004). Behind `dx` + `auth`.
// `#[policy]` generates `impl DxComponent` only (the developer writes
// `impl Policy<M>` by hand — the authorization logic is business
// behavior). `Auth<User>`, `OptionalAuth<User>`, `AuthManager<User>`,
// `Session`, and `Flash` are genuine Axum `FromRequestParts` extractors.
// `AuthUser` and `UserLoader` are the application identity contracts.
pub use cratepolicy;
pub use crate::;
// A10: the middleware attribute macro and the global error-mapping function.
// `#[middleware]` validates a function signature and passes it through
// unchanged so it remains a genuine Axum `from_fn` middleware. `ErrorMapFn`
// is installed via `Application::error_mapping(...)`. Behind `dx`.
pub use crateErrorMapFn;
pub use cratemiddleware;
// A11: typed events and the event dispatcher. `#[derive(Event)]` marks a
// struct as a typed event. `#[listener(Event)]` annotates a listener
// function. `Dispatcher` is the in-process event dispatcher. Behind `dx` +
// `serde` (events are type-erased via `serde_json::Value`).
pub use crateEvent;
pub use crate::;
// A12: the jobs/scheduler/commands DX layer. `#[derive(Job)]` declares a
// struct as a typed job. `#[job_handler]` annotates a job handler function.
// `#[command("name")]` annotates an application command function. `Scheduler`
// is the managed recurring-job enqueuer. `CommandRegistry` is the type-erased
// command dispatcher for `arc run`. The binding types (`JobBinding`,
// `CommandBinding`, `ScheduleBinding`, `ScheduleCadence`) support `arc
// check` / `arc modules` / `arc schedule` inspection. Behind `dx` + `jobs`
// (and `serde` for `Job` — the derive macro and the trait share the name
// `Job` in different namespaces, like `serde::Serialize`).
pub use crateJob;
pub use crate::;
// Serde surface (opt-in via the `serde` feature, or transitively via
// `inertia`/`api`). Lets a normal app derive `Serialize`/`Deserialize` for
// props/models without a direct `serde` dependency (engine spec §44).
pub use ;
// A5: the validator trait. `Validate` is re-exported so `#[request]`
// structs' `impl Validate` is accessible through the prelude, and so
// handlers can bound on `T: Validate` if needed. Behind `validation`
// (enabled by `api`).
pub use Validate;
// Selected capability entry points — one primary type per enabled subsystem.
// The full surface of each lives under its facade module (`crate::<subsystem>`).
pub use crateProblem;
pub use crateCache;
pub use crateDb;
pub use crateInertia;
pub use crateJobs;
pub use crateMailer;
pub use crateRequestId;
pub use cratePages;
pub use crateStorage;