Add static adapter dispatch dependencies

Add source-grounded static adapter.dispatch dependency extraction for dxt.

Author: sabino

.agent/research/m2-static-adapter-dispatch-deps.md

@@ -0,0 +1,72 @@
+# M2 Static Adapter Dispatch Dependency Slice
+
+This slice adds static dependency extraction for literal `adapter.dispatch(...)`
+calls. It records `depends_on.macros` only. It does not execute macros, evaluate
+the callable returned by dispatch, implement materializations, parse profiles,
+open adapter connections, or support project `dispatch:` config.
+
+## Upstream References
+
+dbt Core v1, branch `1.latest`, commit `566b75d`:
+
+- `core/dbt/context/providers.py::BaseDatabaseWrapper._get_adapter_macro_prefixes`
+  defines adapter prefix order as adapter type hierarchy plus `default`.
+- `core/dbt/context/providers.py::BaseDatabaseWrapper._get_search_packages`
+  defines dispatch package search: no namespace uses flattened lookup, configured
+  dispatch order wins, and dependency namespace searches root project then the
+  dependency package.
+- `core/dbt/context/providers.py::BaseDatabaseWrapper.dispatch` rejects dotted
+  macro names and deprecated `packages`, then searches
+  `{adapter_prefix}__{macro_name}` candidates.
+- `core/dbt/context/providers.py::ParseProvider` and `RuntimeProvider` expose
+  the adapter wrapper to Jinja contexts. dxt only uses the static dependency
+  shape here.
+
+dbt Core v2 / Fusion foundation, branch `main`, commit `0529e06`:
+
+- `crates/dbt-jinja/minijinja/src/dispatch_object.rs::DispatchObject` and
+  `Object for DispatchObject::call` model dispatch as a callable object.
+- `dispatch_object.rs::get_adapter_prefixes`,
+  `DispatchObject::get_search_packages`, and
+  `macro_namespace_template_resolver` provide the Fusion architecture reference
+  for prefix and namespace lookup.
+
+## dxt Ownership
+
+- `src/project/resolve.zig` owns the static dispatch lookup helper.
+- `src/project/jinja.zig` recognizes literal `adapter.dispatch(...)` while
+  scanning model SQL and macro SQL.
+- `src/project/manifest.zig` already serializes the affected
+  `depends_on.macros` arrays.
+
+## Supported Surface
+
+- `adapter.dispatch("macro_name")`
+- `adapter.dispatch("macro_name", "macro_namespace")`
+- `adapter.dispatch("macro_name", macro_namespace="macro_namespace")`
+
+The first implementation uses the current local default prefix list
+`duckdb`, then `default`, until profile-derived adapter identity exists.
+
+Unsupported shapes fail or remain ignored according to the existing scanner
+boundary: dynamic names, dynamic namespaces, dotted macro names,
+`packages=...`, non-string namespaces, extra args, and malformed nested calls.
+
+## Validation
+
+- Native Zig tests cover prefix precedence, default fallback, package namespace
+  root override before dependency package, dotted-name rejection, unsupported
+  argument shapes, and scanner dependency recording for both model SQL and macro
+  SQL.
+- Pytest fixture `adapter_dispatch_static` validates manifest
+  `depends_on.macros` through the Zig binary.
+- Pytest fixture `adapter_dispatch_missing` validates a missing static dispatch
+  target fails as an unresolved macro.
+
+## Stop Conditions
+
+- Do not execute dispatched macros in this slice.
+- Do not implement adapter profile parsing or dispatch config parsing.
+- Do not add bundled dbt internal macros.
+- Do not add DuckDB connections, materialization execution, `run_results.json`,
+  catalog introspection, or Python product runtime behavior.

PLAN.md

@@ -300,6 +300,15 @@ graph-present internal `dbt` macro lookup for `depends_on.macros`; macro
 execution, adapter dispatch, bundled dbt macros, and materialization lookup
 remain separate M2 work.
 
+Current static adapter dispatch dependency source note:
+`.agent/research/m2-static-adapter-dispatch-deps.md` maps upstream dbt Core v1
+`BaseDatabaseWrapper.dispatch` and Fusion `DispatchObject` behavior to dxt's
+static `depends_on.macros` extraction for literal `adapter.dispatch(...)` calls.
+This slice records dispatch macro dependencies only, using a temporary
+`duckdb`, `default` prefix list until profile-derived adapter identity exists.
+It does not execute dispatched macros, implement project `dispatch:` config,
+parse profiles, or run adapters.
+
 The next source-grounded M1/M2 slices after macro block variant support are:
 
 1. Extend the render-only artifact boundary to adapter-free docs generation:
@@ -666,4 +675,4 @@ Exit criteria:
 - Selector wildcard behavior is currently pinned to observed dbt Core 1.10 behavior. dbt Fusion preview currently differs for resource-type-prefixed wildcard selectors such as `model.<package>.*` and filename-suffix path selectors such as `path:*orders.sql`; a future Fusion-compatibility slice must decide whether to support a selector dialect switch or a compatible superset.
 - Compatibility planning now uses a source-grounded reference map under `.agent/research/dbt-upstream-reference-map.md`; future feature slices should name upstream dbt v1/v2 source references, dxt Zig owners, affected artifact fields, validation gates, and stop conditions before implementation.
 - The committed dbt Core M1 oracle harness lives in `scripts/check_dbt_core_m1_oracle.py`. It is optional developer-side Python tooling that requires `dbt-core` and `dbt-duckdb`, invokes dbt Core through its Python runner, runs `dxt parse` through the Zig binary, and compares stable manifest slices for the supported synthetic M1 fixture ladder. It ignores dbt internal package docs/macros that are outside the current dxt artifact scope, records a known allowed gap for installed-package exposure refs that dbt Core resolves to a root same-name model while dxt currently resolves package-local, and leaves full source-map parity, full artifact schemas, and execution parity for later slices.
-- Before broadening M2 product implementation, close or explicitly re-scope the remaining M1 macro-compatibility behavior gaps. Macro `docs`/`meta` patch fields are covered for the current scalar artifact subset. Macro argument extraction under dbt Core v1 `flags.validate_macro_args` semantics and YAML patch argument validation/replacement are implemented for the manifest artifact surface. Static macro dependency lookup now uses the supported dbt order of current package, root project, other-package fallback for macro bodies, and graph-present internal `dbt` macros; adapter dispatch, macro execution, bundled dbt internal macros, and materialization runtime lookup remain planned. `{% data_test %}` has native source-grounded parser coverage, but the local dbt Core 1.10 oracle rejects that tag before writing artifacts, so dbt-oracle coverage currently pins `{% test %}` and `{% materialization %}` block parity.
+- Before broadening M2 product implementation, close or explicitly re-scope the remaining M1 macro-compatibility behavior gaps. Macro `docs`/`meta` patch fields are covered for the current scalar artifact subset. Macro argument extraction under dbt Core v1 `flags.validate_macro_args` semantics and YAML patch argument validation/replacement are implemented for the manifest artifact surface. Static macro dependency lookup now uses the supported dbt order of current package, root project, other-package fallback for macro bodies, graph-present internal `dbt` macros, and literal `adapter.dispatch(...)` dependency extraction with a temporary `duckdb`, `default` prefix list. Macro execution, bundled dbt internal macros, project `dispatch:` config, profile-derived adapter identity, and materialization runtime lookup remain planned. `{% data_test %}` has native source-grounded parser coverage, but the local dbt Core 1.10 oracle rejects that tag before writing artifacts, so dbt-oracle coverage currently pins `{% test %}` and `{% materialization %}` block parity.

README.md

@@ -40,7 +40,7 @@ Implemented pre-alpha commands:
 ./zig-out/bin/dxt docs generate --project-dir tests/fixtures/docs_blocks --target-path target-dxt
 ```
 
-`parse`, `ls`, `compile`, `run`, `build`, and `docs generate` currently support only the documented M1/M2 parser and render-only subset: `dbt_project.yml` name/model paths/seed paths/macro paths/target path, `flags.validate_macro_args` for macro manifest argument validation, and top-level scalar `vars`, CLI `--vars` scalar overrides, SQL model discovery, CSV seed discovery, installed package SQL model and CSV seed discovery from `dbt_packages`, source discovery, installed package source discovery, exposure discovery, installed package exposure discovery, project macro discovery, installed package macro discovery from `dbt_packages`, project and package docs block discovery, literal and narrow scalar `var('name')` / `var('name', 'default')`-backed `ref` to models or seeds, two-argument package refs, package-local refs in installed package models and exposures, dbt-style fallback from unqualified refs to a unique installed-package model or seed, literal and narrow scalar `var('name')` / `var('name', 'default')`-backed `source`, package-local sources in installed package models, dbt-style fallback from unqualified sources to a unique installed-package source, literal `doc` in descriptions, package-qualified, package-local, root-fallback, macro-body other-package fallback, and graph-present internal `dbt` macro dependencies, basic inline `config`, narrow project and package YAML model properties and macro properties including patched macro `docs`, scalar `meta`, YAML `arguments`, and dbt Core v1-style macro argument annotation warnings, project and package model/seed `+docs.node_color`, root-project model config overrides for installed packages, simple columns, tags, materialization and disabled SQL models, dbt-shaped generic test nodes for `unique`, `not_null`, `accepted_values`, and `relationships`, model/test `refs` and `sources` artifact fields, deterministic partial `manifest.json`, and basic name/tag/path/package/resource/config materialization selectors with exact `package:`/`package:this`, comma intersections, whitespace unions, multi-argument selector lists, repeated selector flags, and graph expansion. This is not full dbt `var()` compatibility yet: `vars.yml`, nested/package-scoped vars, non-string values, `var.has_var`, Jinja-rendered var values, profile/project rendering with vars, and general `var()` usage remain planned. `compile` applies selectors/excludes to enabled SQL models, writes supported compiled SQL to `target/compiled/<package>/...`, and emits compile fields for compiled models. `run` and `build` are truthful execution preflight commands: they parse, resolve, apply selectors/excludes, compile supported selected models, write `manifest.json`, and then fail before execution with a clear adapter-runner boundary error. They do not run SQL, materialize relations, run tests, or write `run_results.json`. `docs generate` uses the same render-only compiler, writes `manifest.json`, writes compiled SQL for selected enabled SQL models, and emits an adapter-free empty `catalog.json` until relation introspection exists. The compiler currently renders only `config`, literal and narrow scalar var-backed `ref`, and literal and narrow scalar var-backed `source` calls; macro execution, adapter dispatch, materializations, tests, real `run`/`build` execution, non-empty catalog introspection, and `docs serve` remain planned.
+`parse`, `ls`, `compile`, `run`, `build`, and `docs generate` currently support only the documented M1/M2 parser and render-only subset: `dbt_project.yml` name/model paths/seed paths/macro paths/target path, `flags.validate_macro_args` for macro manifest argument validation, and top-level scalar `vars`, CLI `--vars` scalar overrides, SQL model discovery, CSV seed discovery, installed package SQL model and CSV seed discovery from `dbt_packages`, source discovery, installed package source discovery, exposure discovery, installed package exposure discovery, project macro discovery, installed package macro discovery from `dbt_packages`, project and package docs block discovery, literal and narrow scalar `var('name')` / `var('name', 'default')`-backed `ref` to models or seeds, two-argument package refs, package-local refs in installed package models and exposures, dbt-style fallback from unqualified refs to a unique installed-package model or seed, literal and narrow scalar `var('name')` / `var('name', 'default')`-backed `source`, package-local sources in installed package models, dbt-style fallback from unqualified sources to a unique installed-package source, literal `doc` in descriptions, package-qualified, package-local, root-fallback, macro-body other-package fallback, graph-present internal `dbt` macro dependencies, and literal `adapter.dispatch(...)` macro dependencies using a temporary `duckdb`, `default` prefix list, basic inline `config`, narrow project and package YAML model properties and macro properties including patched macro `docs`, scalar `meta`, YAML `arguments`, and dbt Core v1-style macro argument annotation warnings, project and package model/seed `+docs.node_color`, root-project model config overrides for installed packages, simple columns, tags, materialization and disabled SQL models, dbt-shaped generic test nodes for `unique`, `not_null`, `accepted_values`, and `relationships`, model/test `refs` and `sources` artifact fields, deterministic partial `manifest.json`, and basic name/tag/path/package/resource/config materialization selectors with exact `package:`/`package:this`, comma intersections, whitespace unions, multi-argument selector lists, repeated selector flags, and graph expansion. This is not full dbt `var()` compatibility yet: `vars.yml`, nested/package-scoped vars, non-string values, `var.has_var`, Jinja-rendered var values, profile/project rendering with vars, and general `var()` usage remain planned. `compile` applies selectors/excludes to enabled SQL models, writes supported compiled SQL to `target/compiled/<package>/...`, and emits compile fields for compiled models. `run` and `build` are truthful execution preflight commands: they parse, resolve, apply selectors/excludes, compile supported selected models, write `manifest.json`, and then fail before execution with a clear adapter-runner boundary error. They do not run SQL, materialize relations, run tests, or write `run_results.json`. `docs generate` uses the same render-only compiler, writes `manifest.json`, writes compiled SQL for selected enabled SQL models, and emits an adapter-free empty `catalog.json` until relation introspection exists. The compiler currently renders only `config`, literal and narrow scalar var-backed `ref`, and literal and narrow scalar var-backed `source` calls; macro execution, project `dispatch:` config, profile-derived adapter identity, materializations, tests, real `run`/`build` execution, non-empty catalog introspection, and `docs serve` remain planned.
 
 ## Development