Crate warble_cli 

warble_cli — the native host library behind the warble binary.

Holds the pieces the binary and the golden integration tests share. The headline is compile_project_to_ir: the real front-end host path — read a Warble project’s files, resolve the declared context kind into a ContextLoader via BuiltinContextResolver, and run the sans-IO core compiler with it injected. Resolving a kind is all this host does; it reads no semantic format, so a layer reaches it as a prepared-context document the producer wrote. (The binary’s dispatch/render/manifest/eval subcommands stay in main.rs.)

blast_radius_for_project reuses the same project-resolution path to answer a blast_radius query without running a full compile — the host side of the warble blast-radius subcommand.

Component resolution — turning a profile’s use: <id> mount into a directory to read component.yml/steps from — is entirely a host concern (see ComponentSource / resolve_component_dir): the core compiler never touches a filesystem, it only ever sees the already-resolved HashMap<String, ComponentFile> this module builds.

This is the crate that becomes the warble binary itself — end users install just this one. It links in both dispatcher back-ends (warble-claude-code, warble-vercel) and nothing that speaks a semantic format; neither of those two crates is a standalone tool, and warble dispatch --target ... simply selects which linked-in back-end handles the compiled IR.

Modules

gate

Gate-decision policy over an impact the bound layer supplied (Phase 4a — the mutating guardrail described in blast-radius.md §6). Pure, no I/O: the layer’s owner computes the impact and crate::blast_radius_for_project fetches it, then this module turns it plus an authored threshold into a decision the host can act on (allow the apply, escalate to human approval, or hard-block it).

hub_fetch

Fetches the Hub component library over the network into a per-user cache, when there is no in-repo hub/components/ to prefer instead (see the crate’s in_repo_hub_dir helper and crate::default_component_sources).

overlay

A patch applied to a parsed profile.yml before the compiler ever sees it.

Structs

BuiltinContextResolver

The context kinds this checkout resolves without help: raw_source (read natively), external (read nothing) and prepared (read a projection the host already resolved). A host that needs another kind wraps this — delegating the ones it knows and handling its own.

ComponentSource

One explicitly-configured place a mounted component’s files may live: components_dir is a directory whose immediate children are <id>/component.yml (+ its steps/*). The host builds the full ordered/kinded list up front (see compile_project_to_ir_with_sources) — resolution never discovers sources on its own (no ancestor/filesystem-root walk).

Enums

SourceKind

The precedence class a ComponentSource belongs to. Precedence is a fixed rule between kinds — Local always outranks Hub — not derived from the order sources happen to be listed in. There is deliberately no rule within a kind: if the same component id is found in two sources of the same kind, resolve_component_dir treats that as ambiguous rather than guessing (e.g. “first in the list wins”), because nothing declares which of two equally-ranked sources should win.

Traits

ContextResolver

Turns a parsed context/binding.yml into the ContextLoader the compiler probes.

Functions

asset_dir_for_ir

The directory an IR’s assets live in, derived from the IR’s own path.

blast_radius_for_project

Fetch the bound layer’s reported impact for node. Resolves the context the same way compile_project_to_ir does (profile.yml → context binding → ContextLoader), but stops short of a full compile. Nothing is computed here: the answer is whatever the layer supplied, and a layer that supplied no analysis is an error rather than an empty radius.

blast_radius_for_project_with

As blast_radius_for_project, resolving the context binding through a caller-supplied ContextResolver. Kept in step with compile_project_to_ir_with so a host kind is bindable on both paths — a lineage query over a context only the host can load is no less valid than a compile over it.

check_compliance_ir_version

warble_eval_runner::ComplianceIr (the type eval compliance deserializes into) is deliberately narrower than WarbleIr — its own doc comment says so, so a compiled-in warble_ir_version field never belongs on that type. But eval compliance is not fed an arbitrary subset: every real caller hands it the same complete ir.json dispatch/manifest consume (confirmed by eval/golden/compliance/ground_truth.yaml’s own comment — its two golden IRs, examples/mutate-agent/ir.golden.json and examples/analysis-agent/ir.golden.json, are “reused as-is, not new fixtures”). So the version gate belongs here, at the CLI boundary, checked on the raw JSON before ComplianceIr ever sees it — against the same warble_claude_code::ir::SUPPORTED_IR_VERSION that the binary’s own load_ir already gates dispatch/manifest against, so every CLI-level IR consumer rejects an out-of-range version the same way.

compile_project_to_ir

Compile a Warble project directory into its IR JSON, resolving the context binding through BuiltinContextResolver and using the default component source list (project-local components/ + this checkout’s Hub — see default_component_sources). This is what every in-repo example/eval profile and integration test compiles through.

compile_project_to_ir_with

As compile_project_to_ir_with_sources, resolving the context binding through a caller-supplied ContextResolver instead of BuiltinContextResolver. This is the seam a host uses to bind a context kind this checkout cannot read — the context-side counterpart of passing your own ComponentSource list.

compile_project_to_ir_with_assets

Compile, and also hand back the asset content the manifest names.

compile_project_to_ir_with_overlay

As compile_project_to_ir_with, additionally applying an overlay document to the parsed profile before compiling — see crate::overlay for what a patch may touch and why.

compile_project_to_ir_with_sources

Compile a Warble project directory into its IR JSON, resolving mounted components against an explicit, caller-supplied source list instead of the in-repo default (see ComponentSource). This is the seam a host outside this checkout uses to mount its own local component library alongside (or instead of) the Hub — e.g. [ComponentSource::local(my_components), ComponentSource::hub(path_to_warble_hub)]. All filesystem reads happen here; the core compiler stays sans-IO — it only ever receives the resolved HashMap<String, ComponentFile> built below.

default_component_sources

The default two-source list used by compile_project_to_ir: the project’s own components/ (Local, highest precedence — lets a profile deliberately diverge from the Hub, e.g. an eval/demo substrate with intentionally different anatomy) plus the Hub (Hub, fallback) — see the crate’s private default_hub_source helper for how the Hub source itself is resolved. A host mounting an additional local component library (e.g. a product-specific one, alongside the Hub) extends this list — see compile_project_to_ir_with_sources.

default_component_sources_with_hub_version

Same as default_component_sources, but lets the caller pick which Hub version to fetch when default resolution needs the network (i.e. no in-repo hub/components on disk). This is the seam the CLI’s --hub-version flag threads through; None means “this binary’s own version”, the ordinary default.

land_assets

Land the assets an IR’s components declare into out_dir, verifying each against its manifest.

write_assets

Write compiled asset content under root, as <root>/<component-id>/<authored path>.

Type Aliases

CompiledAssets

A component’s asset content, keyed by component id, each entry the authored relative path and the file’s bytes.