dlin-cli 0.2.4rc3__tar.gz → 0.2.5__tar.gz

{dlin_cli-0.2.4rc3 → dlin_cli-0.2.5}/Cargo.lock

@@ -230,12 +230,13 @@ checksum = "d0a5c400df2834b80a4c3327b3aad3a4c4cd4de0629063962b03235697506a28"
 
 [[package]]
 name = "dlin"
-version = "0.2.4-rc.3"
+version = "0.2.5"
 dependencies = [
  "anyhow",
  "clap",
  "dlin-core",
  "filetime",
+ "insta",
  "libc",
  "path-slash",
  "regex",
@@ -247,11 +248,12 @@ dependencies = [
 
 [[package]]
 name = "dlin-core"
-version = "0.2.4-rc.3"
+version = "0.2.5"
 dependencies = [
  "anyhow",
  "clap",
  "colored",
+ "filetime",
  "globset",
  "indexmap",
  "insta",
@@ -413,9 +415,9 @@ dependencies = [
 
 [[package]]
 name = "granit-parser"
-version = "1.0.1"
+version = "1.1.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7c92814c286f45b5ed1498ce9547bc9637b473eba7037f8aee6a4d5a3c1e051c"
+checksum = "4ccd1be9ebf2bd5520dbfcfb72b70ef492f654061299a097056f3e73410e38ec"
 dependencies = [
  "arraydeque",
  "smallvec",
@@ -761,9 +763,9 @@ dependencies = [
 
 [[package]]
 name = "serde-saphyr"
-version = "1.0.1"
+version = "1.1.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "af2c6921c8ce48fb1b052b457619d008834039d80325992ed3bc55bbe6c155ad"
+checksum = "a1ec1f5cac0eb96063c64b28705255a7ed6e7d77f95c1d25e9f8b8c928006ce1"
 dependencies = [
  "annotate-snippets",
  "base64",
@@ -861,7 +863,7 @@ checksum = "67b1b7a3b5fe4f1376887184045fcf45c69e92af734b7aaddc05fb777b6fbd03"
 [[package]]
 name = "sqllineage"
 version = "0.2.0"
-source = "git+https://github.com/funcpp/sqllineage.git?rev=4f6be31ce421af49c7dc87fb22e2b8d6c0156b57#4f6be31ce421af49c7dc87fb22e2b8d6c0156b57"
+source = "git+https://github.com/funcpp/sqllineage.git?rev=b010d8083c60aee977055ea36f8a6807c1d51c62#b010d8083c60aee977055ea36f8a6807c1d51c62"
 dependencies = [
  "serde",
  "serde_json",

{dlin_cli-0.2.4rc3 → dlin_cli-0.2.5}/Cargo.toml

@@ -3,7 +3,7 @@ members = ["crates/*"]
 resolver = "3"
 
 [workspace.package]
-version = "0.2.4-rc.3"
+version = "0.2.5"
 edition = "2024"
 license = "MIT"
 repository = "https://github.com/eitsupi/dlin"
@@ -23,7 +23,7 @@ indexmap = "2"
 minijinja = "2"
 rayon = "1"
 globset = "0.4"
-sqllineage = { git = "https://github.com/funcpp/sqllineage.git", rev = "4f6be31ce421af49c7dc87fb22e2b8d6c0156b57", default-features = false }
+sqllineage = { git = "https://github.com/funcpp/sqllineage.git", rev = "b010d8083c60aee977055ea36f8a6807c1d51c62", default-features = false }
 # Must stay in lockstep with the sqlparser version sqllineage depends on; see
 # `sqlparser_version_matches_sqllineage` in dlin-core.
 sqlparser = { version = "0.62", features = ["serde", "visitor"] }

{dlin_cli-0.2.4rc3 → dlin_cli-0.2.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dlin-cli
-Version: 0.2.4rc3
+Version: 0.2.5
 Classifier: Development Status :: 4 - Beta
 Classifier: Environment :: Console
 Classifier: Intended Audience :: Developers
@@ -30,7 +30,7 @@ dbt model lineage CLI. Parses SQL files directly or reads a compiled `manifest.j
 
 Works for developers navigating live SQL files, analysts exploring a shared manifest, AI agents via CLI prompt or MCP server, and CI pipelines.
 
-Column-level lineage (`dlin column upstream` / `dlin column downstream`) is also available. It requires `manifest.json`.
+Column-level lineage (`dlin column upstream` / `dlin column downstream`) requires a compiled `manifest.json` and is usable in practice while remaining Experimental for coverage reasons.
 
 ## Motivation
 
@@ -40,7 +40,7 @@ dlin is designed to fill that gap: a CLI tool that lets AI agents understand a d
 
 To replace `grep`, speed and size matter. dlin is a small, self-contained binary with no runtime dependencies. It parses SQL directly, evaluates common Jinja patterns without Python, parallelizes file I/O, and caches aggressively.
 
-The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage as fast as possible, and also offers experimental column-level lineage for deeper analysis.
+The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage fast and provides column-level lineage for deeper analysis.
 
 ## Install
 
@@ -94,9 +94,9 @@ git diff --name-only main | dlin graph -o json
 
 dlin supports two source modes for model-level commands.
 
-**SQL parse mode (default)** is for developers working with a live dbt project. dlin reads `ref()` and `source()` calls directly from SQL files without running `dbt compile`. It works immediately as you edit models, with no compilation step needed.
+**SQL parse mode (default)** is for developers editing a live dbt project. It reads `ref()` and `source()` directly from SQL without waiting for `dbt compile`, so model-level lineage quickly identifies the related models. Read the relevant SQL for exact transformation behavior.
 
-**Manifest mode** (`--source manifest`) is for analysts or agents who have access only to a compiled `manifest.json`. A developer runs `dbt compile` once and distributes the result; anyone with that file can then explore the full project structure with dlin without needing SQL files or a Python environment.
+**Manifest mode** (`--source manifest`) is for analysts or agents analyzing compiled state rather than editing live SQL. A developer compiles once and shares `manifest.json`; users explore the resolved graph without SQL or Python. Use column-level lineage when a field-level trace is needed; it requires the compiled manifest.
 
 ```sh
 # SQL parse mode: reads SQL files directly (default)
@@ -111,7 +111,7 @@ For model-name inputs, `manifest.json` is the only file needed in manifest mode.
 
 ### Limitations of SQL parse mode
 
-- `var()` resolves from `dbt_project.yml` only (`--vars` CLI overrides not supported)
+- `var()` resolves from `vars.yml` or `dbt_project.yml` (`--vars` CLI overrides not supported)
 - Runtime context (`target.type`, `env_var()`) is not evaluated
 - Conditional Jinja branches use default values; non-default paths may be missed
 - Generic test IDs are dlin-specific (e.g. `test.not_null.orders.order_id`) and do not match dbt's naming; use manifest mode when exact test IDs matter
@@ -168,7 +168,7 @@ Pass `--dialect` to match your project's SQL dialect for accurate column lineage
 - **Impact analysis with severity**: `dlin impact` scores downstream nodes and flags exposure reachability
 - **Composable**: stdin accepts model names or file paths; pipe with `jq`, `dlin list`, `git diff`, etc.
 - **Agent-friendly**: `--error-format json` emits structured `{"level","what","why","hint"}` on stderr; `--help` is designed for tool discovery
-- **Column-level lineage** (experimental): traces columns across models with transformation classification; requires `manifest.json`
+- **Column-level lineage** (experimental): traces columns across models with transformation classification through the Rust lineage backend; requires `manifest.json`
 
 ## Mermaid diagrams
 
@@ -304,10 +304,7 @@ Output formats: ASCII (default), JSON, Mermaid, Graphviz DOT, Plain, SVG, HTML.
 
 ## Column-level lineage (Experimental)
 
-> [!WARNING]
-> Column-level lineage uses [sqllineage](https://github.com/funcpp/sqllineage) for SQL parsing and lineage extraction. The production backend directly supports Generic, PostgreSQL, MySQL, Hive, Databricks, Snowflake, BigQuery, DuckDB, SQLite, Spark, Trino, Redshift, T-SQL, and ClickHouse. The `dlin` CLI and MCP resolve other recognized dialects to Generic with a warning; direct `dlin-core` API callers receive an unsupported-dialect error instead. Coverage still varies by SQL complexity and dialect, and patterns such as `SELECT *` chains, STRUCT expansion, and some database-specific syntax may remain unresolved.
-
-`dlin column upstream` and `dlin column downstream` trace columns across models. Unlike model-level commands, they always require a compiled `manifest.json`. Run `dbt compile` first.
+`dlin column upstream` and `dlin column downstream` trace columns across models. They require a compiled `manifest.json`, so run `dbt compile` first. Regression fixtures and real dbt project validation show that column-level lineage is usable in practice. Experimental reflects the Rust stack's shorter production history and remaining cross-dialect and complex-SQL coverage gaps, not a prototype-only status.
 
 ```sh
 # Where does each output column of orders come from?
@@ -424,6 +421,18 @@ flowchart LR
 
 `stg_orders.order_id` flows directly into `orders.order_id` and `order_enriched.order_id`. `orders.order_id` is then aggregated into `customers.order_count`. Each edge shows its per-hop transformation type.
 
+### Performance benchmark
+
+Correctness-gated means from the synthetic scalability run (3 runs, 1 warmup):
+
+| Workload | dlin 0.2.4 | [Parrant 0.17.2](https://pypi.org/project/parrant/0.17.2/) | [dbt-meta 0.3.8](https://pypi.org/project/dbt-meta/0.3.8/) |
+| --- | ---: | ---: | ---: |
+| Volume, 100,150 columns, single upstream | 88.9 ms | 37.4 s | build >120 s timeout; query not run |
+| Deep 64, single upstream | 115 ms | 1.42 s | build 4.86 s; query 411 ms |
+| Fan-out 128, downstream | 114 ms | 1.78 s | build 6.47 s; query 363 ms |
+
+These synthetic results use artifacts derived from the real dbt fixture. Native Rust avoids Python startup and dlin showed lower latency here; dlin uses `--no-cache`, Parrant includes parsing, and dbt-meta query excludes build. They are not a general ranking; see the [full results and reproduction](benchmarks/column-lineage/results/published/scalability/summary.md).
+
 ### Known limitations
 
 - **Requires `dbt compile`**: no SQL parse mode fallback; manifest with compiled SQL is always needed

{dlin_cli-0.2.4rc3/crates/dlin → dlin_cli-0.2.5}/README.md

@@ -8,7 +8,7 @@ dbt model lineage CLI. Parses SQL files directly or reads a compiled `manifest.j
 
 Works for developers navigating live SQL files, analysts exploring a shared manifest, AI agents via CLI prompt or MCP server, and CI pipelines.
 
-Column-level lineage (`dlin column upstream` / `dlin column downstream`) is also available. It requires `manifest.json`.
+Column-level lineage (`dlin column upstream` / `dlin column downstream`) requires a compiled `manifest.json` and is usable in practice while remaining Experimental for coverage reasons.
 
 ## Motivation
 
@@ -18,7 +18,7 @@ dlin is designed to fill that gap: a CLI tool that lets AI agents understand a d
 
 To replace `grep`, speed and size matter. dlin is a small, self-contained binary with no runtime dependencies. It parses SQL directly, evaluates common Jinja patterns without Python, parallelizes file I/O, and caches aggressively.
 
-The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage as fast as possible, and also offers experimental column-level lineage for deeper analysis.
+The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage fast and provides column-level lineage for deeper analysis.
 
 ## Install
 
@@ -72,9 +72,9 @@ git diff --name-only main | dlin graph -o json
 
 dlin supports two source modes for model-level commands.
 
-**SQL parse mode (default)** is for developers working with a live dbt project. dlin reads `ref()` and `source()` calls directly from SQL files without running `dbt compile`. It works immediately as you edit models, with no compilation step needed.
+**SQL parse mode (default)** is for developers editing a live dbt project. It reads `ref()` and `source()` directly from SQL without waiting for `dbt compile`, so model-level lineage quickly identifies the related models. Read the relevant SQL for exact transformation behavior.
 
-**Manifest mode** (`--source manifest`) is for analysts or agents who have access only to a compiled `manifest.json`. A developer runs `dbt compile` once and distributes the result; anyone with that file can then explore the full project structure with dlin without needing SQL files or a Python environment.
+**Manifest mode** (`--source manifest`) is for analysts or agents analyzing compiled state rather than editing live SQL. A developer compiles once and shares `manifest.json`; users explore the resolved graph without SQL or Python. Use column-level lineage when a field-level trace is needed; it requires the compiled manifest.
 
 ```sh
 # SQL parse mode: reads SQL files directly (default)
@@ -89,7 +89,7 @@ For model-name inputs, `manifest.json` is the only file needed in manifest mode.
 
 ### Limitations of SQL parse mode
 
-- `var()` resolves from `dbt_project.yml` only (`--vars` CLI overrides not supported)
+- `var()` resolves from `vars.yml` or `dbt_project.yml` (`--vars` CLI overrides not supported)
 - Runtime context (`target.type`, `env_var()`) is not evaluated
 - Conditional Jinja branches use default values; non-default paths may be missed
 - Generic test IDs are dlin-specific (e.g. `test.not_null.orders.order_id`) and do not match dbt's naming; use manifest mode when exact test IDs matter
@@ -146,7 +146,7 @@ Pass `--dialect` to match your project's SQL dialect for accurate column lineage
 - **Impact analysis with severity**: `dlin impact` scores downstream nodes and flags exposure reachability
 - **Composable**: stdin accepts model names or file paths; pipe with `jq`, `dlin list`, `git diff`, etc.
 - **Agent-friendly**: `--error-format json` emits structured `{"level","what","why","hint"}` on stderr; `--help` is designed for tool discovery
-- **Column-level lineage** (experimental): traces columns across models with transformation classification; requires `manifest.json`
+- **Column-level lineage** (experimental): traces columns across models with transformation classification through the Rust lineage backend; requires `manifest.json`
 
 ## Mermaid diagrams
 
@@ -282,10 +282,7 @@ Output formats: ASCII (default), JSON, Mermaid, Graphviz DOT, Plain, SVG, HTML.
 
 ## Column-level lineage (Experimental)
 
-> [!WARNING]
-> Column-level lineage uses [sqllineage](https://github.com/funcpp/sqllineage) for SQL parsing and lineage extraction. The production backend directly supports Generic, PostgreSQL, MySQL, Hive, Databricks, Snowflake, BigQuery, DuckDB, SQLite, Spark, Trino, Redshift, T-SQL, and ClickHouse. The `dlin` CLI and MCP resolve other recognized dialects to Generic with a warning; direct `dlin-core` API callers receive an unsupported-dialect error instead. Coverage still varies by SQL complexity and dialect, and patterns such as `SELECT *` chains, STRUCT expansion, and some database-specific syntax may remain unresolved.
-
-`dlin column upstream` and `dlin column downstream` trace columns across models. Unlike model-level commands, they always require a compiled `manifest.json`. Run `dbt compile` first.
+`dlin column upstream` and `dlin column downstream` trace columns across models. They require a compiled `manifest.json`, so run `dbt compile` first. Regression fixtures and real dbt project validation show that column-level lineage is usable in practice. Experimental reflects the Rust stack's shorter production history and remaining cross-dialect and complex-SQL coverage gaps, not a prototype-only status.
 
 ```sh
 # Where does each output column of orders come from?
@@ -402,6 +399,18 @@ flowchart LR
 
 `stg_orders.order_id` flows directly into `orders.order_id` and `order_enriched.order_id`. `orders.order_id` is then aggregated into `customers.order_count`. Each edge shows its per-hop transformation type.
 
+### Performance benchmark
+
+Correctness-gated means from the synthetic scalability run (3 runs, 1 warmup):
+
+| Workload | dlin 0.2.4 | [Parrant 0.17.2](https://pypi.org/project/parrant/0.17.2/) | [dbt-meta 0.3.8](https://pypi.org/project/dbt-meta/0.3.8/) |
+| --- | ---: | ---: | ---: |
+| Volume, 100,150 columns, single upstream | 88.9 ms | 37.4 s | build >120 s timeout; query not run |
+| Deep 64, single upstream | 115 ms | 1.42 s | build 4.86 s; query 411 ms |
+| Fan-out 128, downstream | 114 ms | 1.78 s | build 6.47 s; query 363 ms |
+
+These synthetic results use artifacts derived from the real dbt fixture. Native Rust avoids Python startup and dlin showed lower latency here; dlin uses `--no-cache`, Parrant includes parsing, and dbt-meta query excludes build. They are not a general ranking; see the [full results and reproduction](benchmarks/column-lineage/results/published/scalability/summary.md).
+
 ### Known limitations
 
 - **Requires `dbt compile`**: no SQL parse mode fallback; manifest with compiled SQL is always needed

{dlin_cli-0.2.4rc3 → dlin_cli-0.2.5}/crates/dlin/Cargo.toml

@@ -33,6 +33,7 @@ tempfile = { workspace = true }
 regex = { workspace = true }
 serde_json = { workspace = true }
 serde-saphyr = { workspace = true }
+insta = { workspace = true }
 
 [lints]
 workspace = true

{dlin_cli-0.2.4rc3/crates/dlin-core → dlin_cli-0.2.5/crates/dlin}/README.md

@@ -8,7 +8,7 @@ dbt model lineage CLI. Parses SQL files directly or reads a compiled `manifest.j
 
 Works for developers navigating live SQL files, analysts exploring a shared manifest, AI agents via CLI prompt or MCP server, and CI pipelines.
 
-Column-level lineage (`dlin column upstream` / `dlin column downstream`) is also available. It requires `manifest.json`.
+Column-level lineage (`dlin column upstream` / `dlin column downstream`) requires a compiled `manifest.json` and is usable in practice while remaining Experimental for coverage reasons.
 
 ## Motivation
 
@@ -18,7 +18,7 @@ dlin is designed to fill that gap: a CLI tool that lets AI agents understand a d
 
 To replace `grep`, speed and size matter. dlin is a small, self-contained binary with no runtime dependencies. It parses SQL directly, evaluates common Jinja patterns without Python, parallelizes file I/O, and caches aggressively.
 
-The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage as fast as possible, and also offers experimental column-level lineage for deeper analysis.
+The key idea behind dlin is that finding the right models fast is what matters most. The hard part for agents is knowing which models to look at in the first place. dlin focuses on making model-level lineage fast and provides column-level lineage for deeper analysis.
 
 ## Install
 
@@ -72,9 +72,9 @@ git diff --name-only main | dlin graph -o json
 
 dlin supports two source modes for model-level commands.
 
-**SQL parse mode (default)** is for developers working with a live dbt project. dlin reads `ref()` and `source()` calls directly from SQL files without running `dbt compile`. It works immediately as you edit models, with no compilation step needed.
+**SQL parse mode (default)** is for developers editing a live dbt project. It reads `ref()` and `source()` directly from SQL without waiting for `dbt compile`, so model-level lineage quickly identifies the related models. Read the relevant SQL for exact transformation behavior.
 
-**Manifest mode** (`--source manifest`) is for analysts or agents who have access only to a compiled `manifest.json`. A developer runs `dbt compile` once and distributes the result; anyone with that file can then explore the full project structure with dlin without needing SQL files or a Python environment.
+**Manifest mode** (`--source manifest`) is for analysts or agents analyzing compiled state rather than editing live SQL. A developer compiles once and shares `manifest.json`; users explore the resolved graph without SQL or Python. Use column-level lineage when a field-level trace is needed; it requires the compiled manifest.
 
 ```sh
 # SQL parse mode: reads SQL files directly (default)
@@ -89,7 +89,7 @@ For model-name inputs, `manifest.json` is the only file needed in manifest mode.
 
 ### Limitations of SQL parse mode
 
-- `var()` resolves from `dbt_project.yml` only (`--vars` CLI overrides not supported)
+- `var()` resolves from `vars.yml` or `dbt_project.yml` (`--vars` CLI overrides not supported)
 - Runtime context (`target.type`, `env_var()`) is not evaluated
 - Conditional Jinja branches use default values; non-default paths may be missed
 - Generic test IDs are dlin-specific (e.g. `test.not_null.orders.order_id`) and do not match dbt's naming; use manifest mode when exact test IDs matter
@@ -146,7 +146,7 @@ Pass `--dialect` to match your project's SQL dialect for accurate column lineage
 - **Impact analysis with severity**: `dlin impact` scores downstream nodes and flags exposure reachability
 - **Composable**: stdin accepts model names or file paths; pipe with `jq`, `dlin list`, `git diff`, etc.
 - **Agent-friendly**: `--error-format json` emits structured `{"level","what","why","hint"}` on stderr; `--help` is designed for tool discovery
-- **Column-level lineage** (experimental): traces columns across models with transformation classification; requires `manifest.json`
+- **Column-level lineage** (experimental): traces columns across models with transformation classification through the Rust lineage backend; requires `manifest.json`
 
 ## Mermaid diagrams
 
@@ -282,10 +282,7 @@ Output formats: ASCII (default), JSON, Mermaid, Graphviz DOT, Plain, SVG, HTML.
 
 ## Column-level lineage (Experimental)
 
-> [!WARNING]
-> Column-level lineage uses [sqllineage](https://github.com/funcpp/sqllineage) for SQL parsing and lineage extraction. The production backend directly supports Generic, PostgreSQL, MySQL, Hive, Databricks, Snowflake, BigQuery, DuckDB, SQLite, Spark, Trino, Redshift, T-SQL, and ClickHouse. The `dlin` CLI and MCP resolve other recognized dialects to Generic with a warning; direct `dlin-core` API callers receive an unsupported-dialect error instead. Coverage still varies by SQL complexity and dialect, and patterns such as `SELECT *` chains, STRUCT expansion, and some database-specific syntax may remain unresolved.
-
-`dlin column upstream` and `dlin column downstream` trace columns across models. Unlike model-level commands, they always require a compiled `manifest.json`. Run `dbt compile` first.
+`dlin column upstream` and `dlin column downstream` trace columns across models. They require a compiled `manifest.json`, so run `dbt compile` first. Regression fixtures and real dbt project validation show that column-level lineage is usable in practice. Experimental reflects the Rust stack's shorter production history and remaining cross-dialect and complex-SQL coverage gaps, not a prototype-only status.
 
 ```sh
 # Where does each output column of orders come from?
@@ -402,6 +399,18 @@ flowchart LR
 
 `stg_orders.order_id` flows directly into `orders.order_id` and `order_enriched.order_id`. `orders.order_id` is then aggregated into `customers.order_count`. Each edge shows its per-hop transformation type.
 
+### Performance benchmark
+
+Correctness-gated means from the synthetic scalability run (3 runs, 1 warmup):
+
+| Workload | dlin 0.2.4 | [Parrant 0.17.2](https://pypi.org/project/parrant/0.17.2/) | [dbt-meta 0.3.8](https://pypi.org/project/dbt-meta/0.3.8/) |
+| --- | ---: | ---: | ---: |
+| Volume, 100,150 columns, single upstream | 88.9 ms | 37.4 s | build >120 s timeout; query not run |
+| Deep 64, single upstream | 115 ms | 1.42 s | build 4.86 s; query 411 ms |
+| Fan-out 128, downstream | 114 ms | 1.78 s | build 6.47 s; query 363 ms |
+
+These synthetic results use artifacts derived from the real dbt fixture. Native Rust avoids Python startup and dlin showed lower latency here; dlin uses `--no-cache`, Parrant includes parsing, and dbt-meta query excludes build. They are not a general ranking; see the [full results and reproduction](benchmarks/column-lineage/results/published/scalability/summary.md).
+
 ### Known limitations
 
 - **Requires `dbt compile`**: no SQL parse mode fallback; manifest with compiled SQL is always needed

dlin_cli-0.2.5/crates/dlin/src/cli/column.rs

@@ -0,0 +1,240 @@
+use std::path::PathBuf;
+
+use super::*;
+use clap::Subcommand;
+
+#[derive(Debug, clap::Args)]
+pub struct ColumnArgs {
+    #[command(subcommand)]
+    pub command: ColumnCommand,
+}
+
+#[derive(Debug, Subcommand)]
+pub enum ColumnCommand {
+    /// Compute column-level lineage for a model (traces upstream sources)
+    #[command(
+        long_about = "\
+Compute column-level lineage for one or more models.
+
+Direction: upstream only. Traces backward from a model's output columns to
+their raw source columns across the full DAG. There are no -u/-d depth flags
+— the entire upstream chain is always traversed automatically.
+
+To find what downstream models or columns would be affected by changing a
+specific column, use `dlin column downstream` instead.
+
+There is no --source flag; manifest.json is the only data source (unlike
+`dlin graph` which supports both SQL files and manifest).
+
+Requires manifest.json with compiled SQL (run `dbt compile` first).
+Use `dlin check-manifest` to verify freshness before querying.
+
+Column resolution order:
+  1. YAML column definitions (schema.yml / models.yml)
+  2. SQL inference from compiled_code (fallback when YAML is absent)
+
+Stdin/pipe support:
+  Accepts model names or file paths on stdin (one per line).
+  File paths (detected by extension or path separator) are resolved to
+  model names using the dbt project configuration.
+
+Output format (-o/--output):
+  json (default)  JSON array per model with the following structure:
+    model             model name
+    traced_columns    number of columns successfully traced
+    total_columns     total number of columns attempted
+    columns[]
+      column          output column name
+      transformation  how the column was derived:
+                        direct       passed through unchanged (including renames)
+                        aggregation  aggregate function (SUM, COUNT, etc.)
+                        expression   arithmetic or other expression
+                        cast         type cast (CAST(x AS INT))
+                        conditional  CASE WHEN expression
+                        unknown      could not classify
+      sources[]
+        table         source model or raw table name; empty string (\"\") when the
+                      value originates from a literal (NULL, constant, UNNEST, etc.)
+                      — rendered as \"(literal)\" in plain/mermaid/dot outputs
+        column        source column name
+        model_path[]  intermediate [model, column, transformation] triples traversed (omitted if empty)
+    errors[]    parse or resolution diagnostics. An indeterminate per-column
+                diagnostic is non-fatal and does not change the exit code;
+                model-level, missing-column, ambiguous, and parse diagnostics
+                are fatal (exit code 1).
+  plain           human-readable text, one model per block
+  mermaid         Mermaid flowchart (LR) with subgraphs per model
+  dot             Graphviz DOT format; models as clusters, columns as nodes
+                  color-coded by transformation type (pipe to `dot -Tsvg`)
+
+Exit codes:
+  0   Success
+  1   Error (model not found, no manifest, fatal analysis errors, etc.)",
+        after_long_help = "\
+Examples:
+  # Column lineage for a single model (JSON output)
+  dlin column upstream orders
+
+  # Human-readable plain output
+  dlin column upstream orders -o plain
+
+  # Mermaid flowchart
+  dlin column upstream orders -o mermaid
+
+  # Specific columns only
+  dlin column upstream orders --column order_id --column status
+
+  # Multiple models
+  dlin column upstream orders stg_orders
+
+  # With explicit manifest path
+  dlin column upstream orders --manifest-path target/manifest.json
+
+  # BigQuery project
+  dlin column upstream orders --dialect bigquery
+
+  # From git diff (pipe changed files)
+  git diff --name-only main | dlin column upstream -o json"
+    )]
+    Upstream(ColumnGraphArgs),
+
+    /// Analyze downstream column-level impact of changing a column
+    #[command(
+        long_about = "\
+Analyze downstream column-level impact of changing a column.
+
+Direction: downstream only. Starting from a specific column, follows forward
+edges to find all dependent models and columns. There are no -u/-d depth flags
+— all downstream dependents are always included.
+
+This is the reverse direction of `dlin column upstream` (which traces upstream
+sources). To trace where a column's data comes from, use `dlin column upstream`.
+
+Takes a single model and one or more --column flags (required).
+
+There is no --source flag; manifest.json is the only data source (unlike
+`dlin graph`/`dlin impact` which support both SQL files and manifest).
+
+Requires compiled SQL in manifest.json — run `dbt compile` first.
+Use `dlin check-manifest` to verify freshness before querying.
+
+Output format (-o/--output):
+  json (default)  JSON array per column with affected downstream columns and models
+  plain           human-readable text, one source column per block
+  mermaid         Mermaid flowchart (LR) showing impacted columns across models
+  dot             Graphviz DOT format; models as clusters, columns as nodes
+                  color-coded by transformation type (pipe to `dot -Tsvg`)
+
+Exit codes:
+  0   Success
+  1   Error (model not found, no manifest, fatal analysis errors, etc.)",
+        after_long_help = "\
+Examples:
+  # Impact of changing a single column (JSON output)
+  dlin column downstream stg_orders --column order_id
+
+  # Human-readable plain output
+  dlin column downstream stg_orders --column order_id -o plain
+
+  # Mermaid flowchart
+  dlin column downstream stg_orders --column order_id -o mermaid
+
+  # Impact of multiple columns
+  dlin column downstream stg_orders --column order_id --column status
+
+  # With explicit manifest path
+  dlin column downstream stg_orders --column order_id --manifest-path target/manifest.json
+
+  # BigQuery project
+  dlin column downstream stg_orders --column order_id --dialect bigquery"
+    )]
+    Downstream(ColumnImpactArgs),
+}
+
+#[derive(Debug, clap::Args)]
+pub struct ColumnGraphArgs {
+    /// Model names or file paths to analyze column lineage for (also accepts stdin)
+    pub model: Vec<String>,
+
+    /// Specific columns to analyze (analyzes all columns if omitted)
+    #[arg(long)]
+    pub column: Vec<String>,
+
+    /// Output format: json (default), plain, mermaid
+    #[arg(short = 'o', long, default_value = "json")]
+    pub output: ColumnOutputFormat,
+
+    /// SQL dialect for parsing compiled SQL.
+    /// Auto-detected from manifest.metadata.adapter_type when omitted. Recognized dialects
+    /// removed from the active backend fall back to Generic with a warning.
+    #[arg(long, value_parser = parse_dialect_arg)]
+    pub dialect: Option<DialectArg>,
+
+    /// Path to dbt project directory
+    #[arg(short = 'p', long = "project-dir", default_value = ".")]
+    pub project_dir: PathBuf,
+
+    /// Path to manifest.json file or directory containing target/manifest.json (default: <project-dir>/target/manifest.json)
+    #[arg(long)]
+    pub manifest_path: Option<PathBuf>,
+
+    /// Directory for caching column lineage results (default: <project-dir>/.dlin_cache)
+    #[arg(long, env = "DLIN_CACHE_DIR")]
+    pub cache_dir: Option<PathBuf>,
+
+    /// Disable column lineage cache
+    #[arg(long, env = "DLIN_NO_CACHE")]
+    pub no_cache: bool,
+
+    /// Discard existing cache and rebuild from scratch
+    #[arg(long, env = "DLIN_REFRESH_CACHE", conflicts_with = "no_cache")]
+    pub refresh_cache: bool,
+
+    /// Suppress warning messages
+    #[arg(short = 'q', long)]
+    pub quiet: bool,
+}
+
+#[derive(Debug, clap::Args)]
+pub struct ColumnImpactArgs {
+    /// Model name to analyze column downstream impact for
+    pub model: String,
+
+    /// Columns to analyze impact for (required)
+    #[arg(long, required = true)]
+    pub column: Vec<String>,
+
+    /// Output format: json (default), plain, mermaid
+    #[arg(short = 'o', long, default_value = "json")]
+    pub output: ColumnOutputFormat,
+
+    /// SQL dialect for parsing compiled SQL.
+    /// Auto-detected from manifest.metadata.adapter_type when omitted. Recognized dialects
+    /// removed from the active backend fall back to Generic with a warning.
+    #[arg(long, value_parser = parse_dialect_arg)]
+    pub dialect: Option<DialectArg>,
+
+    /// Path to dbt project directory
+    #[arg(short = 'p', long = "project-dir", default_value = ".")]
+    pub project_dir: PathBuf,
+
+    /// Path to manifest.json file or directory containing target/manifest.json (default: <project-dir>/target/manifest.json)
+    #[arg(long)]
+    pub manifest_path: Option<PathBuf>,
+
+    /// Directory for caching column lineage results (default: <project-dir>/.dlin_cache)
+    #[arg(long, env = "DLIN_CACHE_DIR")]
+    pub cache_dir: Option<PathBuf>,
+
+    /// Disable column lineage cache
+    #[arg(long, env = "DLIN_NO_CACHE")]
+    pub no_cache: bool,
+
+    /// Discard existing cache and rebuild from scratch
+    #[arg(long, env = "DLIN_REFRESH_CACHE", conflicts_with = "no_cache")]
+    pub refresh_cache: bool,
+
+    /// Suppress warning messages
+    #[arg(short = 'q', long)]
+    pub quiet: bool,
+}