Add opt-in write-audit-publish for Snowflake table models

[athvin]

Problem

Today, dbt build replaces a table before running its data tests. If those tests fail, downstream dbt tasks can stop, but other consumers can already see the failed data.

This PR proposes an opt-in publication gate for Snowflake SQL table models and includes an implementation for maintainer review. The goal is to agree on the behavior and limited initial scope before considering broader warehouse or materialization support.

Solution

{{ config(materialized='table', wap=true) }}

For an opted-in model, dbt build:

1. Builds a uniquely named working table in the model's existing database and schema.
2. Runs every required model-owned data audit against that working table. At least one enabled audit is required, and omitting an enabled audit from selection rejects the build.
3. Publishes with Snowflake CREATE OR REPLACE TABLE … CLONE … only when every required audit reports PASS.
4. Finalizes grants and configured clustering, cleans up the successful working table, and releases downstream tasks.

Failed or warning audits leave the existing published table unchanged and retain the working table for inspection. An audit failure on a first build leaves the published table absent. No additional schema is created. The model's public relation, manifest identity, and ordinary downstream ref() calls stay unchanged.

The first version supports only native permanent/transient Snowflake SQL models using the built-in table materialization. The flag defaults to false and supports project inheritance. Incremental and other materializations, custom materializations, model hooks, SQL headers, and multi-relation audits are outside this initial scope.

dbt run and dbt clone reject selected WAP models; standalone dbt test continues to test published data. Retry creates a fresh working table and reruns all required audits. The implementation adds a publication dependency to scheduling, scopes working-table references to audits, and prevents cached SQL or audit results from bypassing the gate.

The branch includes design and implementation notes and live acceptance instructions.

Tradeoffs and requested feedback

• Working tables share the existing schema and may inherit future grants; they are not private or hidden.
• Publication is atomic per table. It does not provide a transaction across models or serialize concurrent builds.
• Errors after a confirmed clone report that publication occurred and stop downstream execution. An ambiguous submission error directs operators to Snowflake query history.
• Streams on replaced tables and arbitrary manually attached table properties are outside this version.
• Cloning initially shares storage; transformations, audits, and retained working tables still incur normal Snowflake costs.

Maintainer feedback is requested on the wap configuration, strict PASS gate, command behavior, and limited initial scope. An associated feature issue and interface approval are still needed before merge.

Validation

• 77 focused Rust tests pass under Nextest, and 25 Python tests pass (20 acceptance-runner checks and 5 real CLI integration tests).
• Scoped Clippy checks pass with --all-targets -- -D warnings; formatting and git diff --check pass.
• CI now explicitly builds dbt and runs all 25 offline Python checks, with an executable check that prevents silent CLI-test skips.
• Coverage includes configuration and selection, delayed audits and scheduler failure propagation, publication failures and cleanup, actual Snowflake table/CTAS and clone-macro SQL, grants, quoting, ref isolation, cache reuse, and retry.
• The live Snowflake acceptance runner covers permanent/transient tables, transformation errors, failed and warning audits, first publication, retry, standalone tests after failure, same-schema candidates, and preservation of existing downstream data. It has not been run against Snowflake because credentials are unavailable.

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have manually verified this against a live Snowflake project.
• This PR includes tests.
• The new configuration interface has received Product/DX feedback and approval.

[cla-bot]

Thanks for your pull request, and welcome to our community! We require contributors to sign our Contributor License Agreement and we don't seem to have your signature on file. Check out this article for more information on why we have a CLA.

In order for us to review and merge your code, please submit the Individual Contributor License Agreement form attached above above. If you have questions about the CLA, or if you believe you've received this message in error, please reach out through a comment on this PR.

CLA has not been signed by users: @bmoore813

[cla-bot]

Thanks for your pull request, and welcome to our community! We require contributors to sign our Contributor License Agreement and we don't seem to have your signature on file. Check out this article for more information on why we have a CLA.

In order for us to review and merge your code, please submit the Individual Contributor License Agreement form attached above above. If you have questions about the CLA, or if you believe you've received this message in error, please reach out through a comment on this PR.

CLA has not been signed by users: @bmoore813