[kvlonge]

Why

dbt v2 can cache between runs when asked (--partial-parse, hidden in 2.0.9; --partial-load; --dirty compiles only changed models and descendants), so timing only its default is unfair. Strict analysis is only in the dbt distribution and can fall back silently, so the workflow must prove it ran. dbt Core is a reference only.

Changes

• bench.sh: dbt v2 cached, --dirty and default variants, each also strict. v2_compile_strict_remote reads source schemas from the warehouse; sqb_norules_full added. .cmd per run.
• write_dbt_dense.py: sources declare schema_origin: local (like SQLBuild); dbt-remote/ keeps dbt's default. warehouse.duckdb holds every source and model relation, empty, typed, matching materialization.
• check_strict.py, run by the workflow after correctness (before the benchmark) and after it: the seeded unknown column fails strict with dbt0227 in default, remote, cached and --dirty modes; plain compile passes it; clean passes strict; every timed strict run exits 0; no strict output matches the listed fallback patterns.
• summarize.py: labelled rows (SQLBuild default first; dbt v2 cached, --dirty, default, strict alongside), "warm (replay)", full-parse fallback and skipped analysis noted.
• Defaults SQLBuild and dbt v2 only; dbt Core installed only for core_*.
• README: warehouse, sources, v2 modes, strict proof patterns and equivalence notes.

Verification

• 50 models: correctness matrix and check_strict.py correctness pass; a fake fallback line or a passing strict run fails it.
• 100 models: all eleven default variants exit 0; check_strict.py runs passes; local sources download no schemas.
• sqb compile output identical without the warehouse.
• actionlint, ruff, hygiene scan pass.