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
//! # `noetl-executor` — shared utilities and types for CLI + worker
//!
//! Hosts the type definitions, template rendering, condition
//! evaluation, capability validation, and event-emission shape that
//! the NoETL CLI's `noetl run --runtime local` path AND the
//! `noetl-worker` NATS daemon share.
//!
//! ## What this crate is
//!
//! A **utilities-and-types** crate. See Appendix H of the global
//! hybrid cloud blueprint at
//! <https://noetl.dev/docs/architecture/noetl_global_hybrid_cloud_grid_distributed_architecture_blueprint>
//! and especially § H.10 (the tree-walker vs pull-model finding)
//! for the architectural rationale.
//!
//! ## What this crate is NOT
//!
//! A **control-loop crate**. The CLI keeps its recursive tree
//! walker in `repos/cli/src/playbook_runner.rs` — that shape is the
//! natural fit for local YAML execution. The worker keeps its
//! NATS pull loop. These control loops are fundamentally different;
//! attempts to unify them produce more abstraction than they remove.
//!
//! ## Module layout
//!
//! - [`playbook`] — Pydantic-like YAML playbook types (R-1.1 PR-2a).
//! - [`template`] — `render_template`, `render_template_with_result`,
//! `get_json_path`, `json_to_rhai`, `rhai_to_json_string` (R-1.1 PR-2b).
//! - [`condition`] — `evaluate_condition`, `evaluate_rhai_condition`
//! (R-1.1 PR-2b).
//! - [`capabilities`] — `validate_capabilities` + `ValidationReport`
//! (R-1.1 PR-2b).
//! - [`runtime`] — `ExecutionContext`, `CredentialResolver` trait
//! (R-1.1 PR-1, kept; concrete CLI / worker contexts live in their
//! own crates).
//! - [`events`] — `ExecutorEvent`, `EventSink` trait, `NoopSink`,
//! `EventEmitter` helper (R-1.1 PR-1).
//! - [`tools_bridge`] — adapter layer onto the `noetl-tools` registry
//! (R-1.1 PR-2c-1 onwards). Wires `Tool::Rhai` / `Tool::Shell` /
//! `Tool::Http` / `Tool::DuckDb` through the registry; supplies pure
//! helpers (`prepare_sub_playbook_vars`, `resolve_auth_to_bearer`,
//! `auth_context_updates`, `format_sink_payload`, `json_to_csv`)
//! for the inline tool kinds (`Tool::Playbook` / `Tool::Auth` /
//! `Tool::Sink`) that stay in the CLI by design per § H.10.
//! - [`worker`] — worker-only abstractions: [`worker::source`]
//! contains the `Command` struct + `CommandSource` trait. The CLI
//! does NOT consume these; they exist for the worker's NATS pull
//! loop.
//!
//! ## Stability
//!
//! `0.1.x` is pre-production. Public API churns through R-1.1's
//! sub-PRs and stabilises around R-1.3 (worker depends on the
//! crate). Treat as internal until then; the crate ships with
//! `publish = false`.
/// Re-exports for downstream crates (the CLI and the worker) so they
/// can import from the crate root.
pub use ;
pub use ;