//! Authoring surfaces — the four front-ends that all lower to one
//! [`crate::ir::Pipeline`].
//!
//! Þund's design decision (see `.nornir/thund.md`) is **all-over-one-IR**:
//!
//! 1. **Typed Rust builder** — the [`crate::ir`] types *are* the builder:
//! `Pipeline::new(..).with_dataset(..).with_flow(..)`. Compile-time typed,
//! testable, the canonical form. No separate builder type is needed because
//! the IR's `with_*` chaining already is one.
//! 2. **Thin declarative DSL** ([`dsl`], feature `dsl`) — a RON serialization
//! of the IR for config-as-code / LLM-authoring / warehouse-historized
//! defs. It is a *pure (de)serialization* of the same IR, never a second
//! model, so there is no drift.
//! 3. **facett graph editor** — the visual node-graph editor reuses the
//! existing `knut-pipelines` facett `PipelineView`; it edits the IR's
//! `(dataset, flow)` graph directly and emits the same [`crate::ir::Pipeline`].
//!
//! 4. **SQL** ([`sql`], feature `sql`) — SDP-style DDL (`CREATE MATERIALIZED
//! VIEW` / `STREAMING TABLE` / `FLOW`) parsed by an `sqlparser-rs` extension
//! built the way DataFusion's own `DFParser` is. Like RON it is a *view* of
//! the IR, not a second model, so `SQL -> IR -> RON -> IR -> SQL`
//! round-trips.
//!
//! Because all four produce the identical IR, a pipeline can be drawn in
//! facett, exported to RON, hand-tuned in Rust, written as SQL, and run on
//! either backend — the IR is the single contract.