RELEASES

Everything in this release came out of the founder running 0.2.60 on his own project the day it shipped. The catalog first: dbt docs serve hosts dbt's catalog exactly as it always has, because DVT no longer writes anything over dbt's index.html or manifest.json; dvt docs serve is back and hosts DVT's catalog alone — the themed one, with the engine under every node, the target and engine of every model on a custom target, and the source, database, schema, table and connection of every source; and the suite's /catalog is the same catalog. Both DVT fronts are live the way dbt's is: the manifest they serve is DVT's view of dbt's current manifest, built on request, so a refresh after any run or parse shows the new graph. dvt serve now knows which dvt-core a running suite is, and restarts one left over from another version instead of quietly reusing it. The run log reads as one log: every DVT line on dbt's clock, every warning printed once. Snowflake's two loader crossings — integers landing NUMBER(38,0), uuids landing VARCHAR(36) — are measured and documented, so a Snowflake landing no longer warns on every model. uv projects keep their drivers, because sync records the adapter extras where uv can see them; the sling wrapper is pinned in dvt-core's own dependencies so no upgrade can drift it; the catalog asks each connection one question for all its schemas instead of one per schema; and sources.yml files DVT writes put meta where dbt 1.12 wants it.

Four findings from the founder's own Arabian Shield project, run purely on DVT, each closed by a rule rather than a patch. A view over a federated model on the default target was being pulled into federation and rebuilt as a table; the founder's rule is dbt's: a dependent of a model that lands on the default target is an ordinary model with a parent that exists there, and dbt builds it. Only a parent that lands on another connection pulls its dependents along. When a federated load meets a view standing at its name, DVT now does what dbt's own materialization does — asks the adapter what stands there and drops it through the adapter — rather than any per-engine catalog logic. dvt parse on an environment that has not been synced says so in one line and names the fix, before dbt runs, instead of a forty-line traceback. And DVT has its own manifest now: target/dvt_manifest.json carries the engine stamps, connections and the real database of every source bound elsewhere, while dbt's manifest.json is left byte-for-byte dbt's so every dbt tool keeps working; the served catalog reads DVT's view. Linux arm64 wheels join the release, built on GitHub's native arm64 runner.

Two classes of drift closed by the same method — measure the whole matrix, then decide once in one place — plus the flip's one lane and the federated snapshot. Casing first: six rulings had fixed identifier case one hop at a time, each a fold predicted from a table meeting a real engine. A casing gauntlet measured an identifier corpus across every live engine, every way a relation is created and read (232 cells), and three laws replaced the predictions. Then types, the same way: a column crosses type systems twice on the federation path and every door re-inferred it — decimals widening to (24,6), timestamps with time zone landing as plain datetimes, Oracle booleans landing as strings, watermarks losing their microseconds. One type home now carries every column as Arrow, pins every column DVT can type on every engine, pins declared shapes on extraction, renders literals with precision, and documents the crossings an engine forces instead of fighting them. The metadata store gained DVT's own world: what every lane declared for every landed column and what the engine's catalog reports, verified after each load and exported as Landed and Mapping sheets. The flip has exactly one translator now — the AI lane, machine-judged, engine-compiled; the deterministic transpiler is gone. f_snapshot joins f_table and f_incremental as the federated type-2 snapshot. And the ring that judges all of it grew: client-owned fixtures, a source that moves between builds, hooks audited, landed types verified on every hop.

A DVT project has two worlds. sources.yml is the client's — systems DVT reads and never writes. Everything DVT lands is DVT's, recorded in the ledger. A relation is never both. The founder's demo showed what happens when the line blurs: seven federated models fed by client sources, and seven base views fed by… those models' own outputs, declared back as sources and depended on as if they were the client's. The catalog drew two disconnected layers; retract's declared-source protection would have shielded DVT's own tables from DVT. The founder's ruling — 'dvt should have failed to create them' — is now law: dvt parse refuses a model that reads a DVT-landed relation through source(), in dbt's own error shape, naming the model, the source, the owning model and the fix. config-checkup names the same state as repairable and config-fix rewrites the call to ref(), restoring lineage in one command. Identity is the relation (connection + landed name), never the bare name — a client table and a same-named model on another engine are two different things.

dvt_project.yml carries the founder's port law: suite_port is where dvt serve lives, defined there and nowhere else. This release closes the one crack in that law. If you edited suite_port while your suite was still running, the next dvt serve would silently reuse the old port — the running process outvoting the file that is supposed to be the only source. Now the pin is read before the reuse check, and a live suite is reused only while its port agrees with the file. Disagreement is a refusal, not an eviction: DVT never stops a running suite behind your back — the message states both facts and hands you both commands (dvt kill, which stops only this project's suite, then dvt serve). Your configuration always wins; your server never dies uninvited; moving is always your own explicit act.

Found in the founder's first real deployment, hours after 0.2.55: seven federation models landed their tables on Snowflake and then every post-hook failed with 002003 — on the very tables that had just landed — while the staging root printed the same refusal twelve times. The disease was a split personality around identifier case: a mixed-case profile schema (BRONZE_trial) rode to the bulk loader verbatim and landed quoted-and-case-preserved, while every unquoted SQL surface — post-hooks' {{ this }}, staging, the DVT stage — upfolded straight past it, Snowflake-style. The read side of this class was fixed in the ring (retract speaks every spelling); the landing convention itself was the missing half. Now every object DVT names on Snowflake upfolds — the same one-convention-per-engine rule Oracle's upfold and Trino's downfold already follow — proven live against a real Snowflake account with the exact failing shape: mixed-case schema, update-{{ this }} hook, landed, hook green, idempotent, zero staging warnings.

Found live, in the founder's own demo: a dbt project that existed before DVT has no dvt_project.yml — dvt init rightly refuses to touch an existing project, but config-checkup answered 'every config tells the truth' over a file that didn't exist at all, leaving every DVT decision (compute path, suite port, AI, telemetry) running on silent defaults with no written record. A missing key was always a finding; a missing file was invisible. Now the file itself is the finding, and one dvt config-fix writes the complete init scaffold — every key at its real default, each with the comment that teaches it, named after your project. Adopting DVT in an existing dbt project is now: install, config-fix, done.

A fast follow with one job: the Sling engine DVT installs is now pinned to the exact version the 110-transition ring campaign proved — and the pin is enforced, not assumed. Hours after 0.2.53 shipped, upstream's three-day-old Sling v1.6.0 — released with an empty changelog — walked into a live environment through the old uncapped version floor and stalled a first sync on a 100MB engine fetch. That's the second uncapped-floor disease in two releases (a Cython regression was the first), so the fix is now doctrine: pin what's proven, track upstream actively, and adopt new releases at the speed of proof — changelog review, then the battery, then the pin moves.

The ring proved the engine; this release proves the cockpit. Every app on the suite port — hub and settings, catalog, explorer, profiling, scheduler, API portal, Chat with Martin, dashboards, executions — was walked through a functional battery against a real project on live engines: connections tested on both layers, a grid edit applied through the previewed-DML lane and verified on the warehouse, a scheduler job created, fired and deleted, an API endpoint enabled, keyed and called live, Martin answering with federated results and proposing parse-verified files, a Martin asset landing on a dashboard tile and refreshing live, and a real run watched heartbeat-by-heartbeat into history. Alongside the battery, Martin's grounding got materially smarter — and a standing law now keeps it that way: docs are release-notes-equal, and the expert corpus that ships inside every wheel is refreshed and re-verified before any release is tagged.

The ring closed. Every one of the 110 engine-to-engine transitions among DVT's eleven live engines — Postgres, MySQL, MariaDB, MySQL 5.7, SQL Server, Oracle, ClickHouse, Trino, DuckDB, Snowflake and Databricks — is now proven green in both directions, each under the same 27-command battery against real databases: flip, parse, seed, build twice, snapshot twice, idempotence, row counts and named values against canonical truth, docs, sources, metadata, base views, a native statement, a zero-residual retract, a landed branch. The second half of the walk crossed into the clouds, and the clouds fought back: warehouses that suspend themselves mid-build, connectors that declare one type and write another, transpiler artifacts that are load-bearing on one engine and fatal on the next, and a whole family of diseases that only wake on an engine's second or third visit — which is precisely what an exhaustive walk exists to force. Every fix below carries the hop that found it.

Every fix in this release was found by a machine walking between engines, not by a human reading code. The ring is a campaign that visits ordered pairs of engines — DuckDB to Postgres, Postgres to MySQL, DuckDB to Trino — and at each stop runs the entire command surface against real databases: flip the project onto the new engine, parse, seed, build twice, snapshot twice, check idempotence, reconcile row counts AND named values, generate docs, generate sources, generate base views, execute a native statement, retract everything, land a branch. Twenty-seven commands per hop. A hop is green only when all twenty-seven pass; anything less is a bug to fix, not a result to record. Sixteen hops are green so far, and they produced the fifty-odd fixes below — a silent row-duplication bug, a segfault that killed every Python model on macOS, a retract that deleted the project's own source tables, quoting that broke on seven engine-and-role combinations, and a bulk loader that landed different column names than the ordinary one. Most of these had passed every test suite DVT had.

The simplification release. Everything DVT runs on now lives in ONE environment — the per-engine private runtimes are gone, and with them the entire class of drift, provenance and missing-adapter failures they bred. Eighteen engines are supported out of one install: Postgres, Redshift, Snowflake, BigQuery, Athena, Databricks, DuckDB (and MotherDuck), Trino, ClickHouse, Oracle, SQL Server, Fabric, SQLite, StarRocks, Exasol, MySQL, MySQL 5.7 and MariaDB — every one validated against its real engine. dvt sync is now one install with a collision guard: it sets up the engine core, every adapter, your drivers and the Sling engine, self-heals a corrupted download, and removes conflicting packages with a stated reason. On top of the simpler engine room: seeds honor selection exactly as you'd expect — graph selectors included — --fail-fast stops a run at the first failure, the health surface guards every scaffolded setting in dvt_project.yml, and retract tells the truth about what it dropped, where it actually landed.

The write release. DVT has always read across every engine — now it writes across them too, through one battle-tested lane: dbt-compatible pre- and post-hooks on federated models (pre-hooks on SOURCE engines, post-hooks on targets — including pinned custom targets), dvt exec for one engine-native statement on any connection, an Explorer grid editor that previews the exact SQL before an explicit APPLY, and opt-in, key-gated DML endpoints on the api-portal. Underneath: every secret moved out of loose files into one machine store, the app suite always serves the project you launched it from, and a full audit closed every gap between the connection surface Settings advertises and what every lane actually honors — nothing connects silently wrong anymore, and nothing fails silently either.

The trust release. dvt config-checkup makes model configs tell the truth — the engine's own federation classification applied to your files, provable problems fixed automatically, ambiguous ones offered as choices (AI-chat style, in the terminal and in Martin's cards alike). flip-target-to runs it first, always. Settings learns every authentication method your adapters speak — keypair Snowflake included, on BOTH lanes — and gains a TEST CONNECTIONS button that probes every connection on both layers and shows you exactly what's healthy. Underneath: an Oracle federation milestone, visible execution paths, and one clock.

The default target stops being a commitment. dvt init scaffolds a project with a DuckDB warehouse out of the box — dvt build is green seconds after pip install, no warehouse account, no prompts — and dvt flip-target-to migrates the whole project to any engine's dialect in one deterministic command when you outgrow the laptop, with an AI rescue pass for the models determinism can't touch. Around that headline: generate-sources learns to read buckets, Martin delivers many charts in one answer and narrates his steps, Data Explorer joins the suite, and Dashboards grow folders, richer formatting, and chart types that know what your columns can express.

The agent leaves the browser: dvt martin puts the same Martin — same tools, same streaming work ledger, same APPLY gates — in your terminal. He also learns to manage the project itself (scheduled jobs, connection health, maintenance runs — never your credentials), generate-sources learns the whole profile in one sweep, and the DVT mark now sits in every app's topbar, one click from the hub.

A release forged in the trial fleet: every generate-sources failure reproduced against real engines and fixed at the root, four field bugs down (including one that silently hid bucket sources), sources.yml generation promoted to a first-class CLI command, DVT Dashboards live on :46108 fed by your saved chat assets, and Martin now streams his work as it happens — with automatic recovery when your gateway's model catalog shifts under him. Rolls up 0.2.34 and 0.2.35.

Meet Martin — DVT's data agent. Ask your project a question in English; Martin writes the SQL, DVT guards it and answers it live through federation. Chat with Martin ships on port 46104 with the whole suite: a code-verified expert corpus inside the wheel, a / palette over your actual models and sources, sessions that persist per project, canvas charts, and assets you save for the Dashboards to come. One AI outlet: AI-Proxy — your existing subscriptions or fully offline Ollama behind one gateway.

meta.connection goes on every source — including ones on the default target. The docs now say it in one voice everywhere, and the engine backs it up: a source without meta.connection gets a clear warning naming the fallback it triggered, and a failed resolution names the real cause instead of a generic 'output not found'.

Two scheduling modes: jobs can now be MANUAL ONLY — a saved dvt command with no cron at all, run when you need it — chosen with a schedule-mode flip right in the ADD JOB form. And the whole schedule gets a master ON/OFF: pause every cron firing without touching a single job definition; RUN NOW keeps working throughout.

The scheduler grows up: kill the whole suite but keep the schedule firing (dvt kill --exclude scheduler), stop any running job dead with a KILL button that takes its whole process tree, and read every run on a LOGS page that tells you what went well, what warned, and exactly what the error was — parsed from dvt's own output, with the full raw log one click away.

Two scheduler refinements: custom cron schedules become five labeled dropdowns — minute, hour, day, month, weekday, in plain words — and job history survives dvt kill. A run in flight when the suite goes down finishes on its own (kill spares running work), and the history now says exactly that instead of losing the record.

The first roadmap tile goes live: DVT Scheduler on :46106. Your dvt commands on a cron — nightly builds, hourly syncs, scheduled retracts — with per-run history, full logs, an overlap guard, and RUN NOW. Jobs are verb-whitelisted dvt commands executed directly (never a shell), and the whole thing arrives with dvt serve like the rest of the suite.

The Connections tab becomes a real credential manager: pick any of the 19 supported engines and buckets from a dropdown, get that adapter's own pre-filled form (filesystem gets a folder picker), and every finished connection lands as an editable card — add another, set the default target, delete with guardrails, then SYNC SOURCES. Full CRUD on profiles.yml, scoped to your project's profile, backup on every write, duplicates rejected. Plus AI-Proxy credentials get real fields.

The hub grows DVT Settings — one card, five tabs, everything about this machine and this project. Account and subscription with offline activation for air-gapped servers, machine specs framed as federation sizing, a profile-scoped connection manager that edits only your project's credentials with a backup on every write, AI keys for the features ahead, and a hosting map for network admins.

A small finishing cut on the suite's chrome: each app names itself — DATA CATALOG, API PORTAL — while the hub alone carries the full DATA VIRTUALIZATION TOOL brand. And the theme circle now holds the same far-right slot on every page, catalog included.

The suite starts feeling like one product: the hub, catalog and api-portal share a single top bar — logo far left at the same coordinates, one pill language for buttons, the theme circle always the far-right element. The catalog's search makes room for the same chrome, the ⌂ HUB back-link appears only when the hub is actually running, and the hub itself now shows the roadmap: six planned apps, one port each.

Light mode stops blinding: the hub, catalog and api-portal (and getdvt.net itself) move to a two-tone grey — the page on a darker whitish grey, panels on a brighter one, zero pure white anywhere, secondary text darkened for real contrast. Plus cohesive chrome: the theme switch sits at the far top right of every app, and the catalog gains a hub back-link like the portal's.

Column attribution goes scope-aware: pruning and pushdown now resolve per SELECT scope instead of one global alias map. Two UNION branches can read same-named tables on two different engines — unaliased — and each branch still prunes its columns and pushes its own filters. Plus a subtle correctness hardening the scope work surfaced: a table read twice in one model never gets one read's filter pushed into their shared extraction.

The extraction engine is rebuilt around syntax trees. Identifiers carry the model's own quoting end-to-end, every extraction renders once in its target dialect, and pushdown is now formally an optimization: anything a source engine can't express is simply computed in DuckDB instead — never an error, never approximated SQL shipped to an engine. Backed by a new transpilation-limits battery pinning the guarantees across ten dialects.

Federation models are written in DuckDB SQL — double quotes for identifiers, one dialect for every model — and DVT re-quotes everything per engine on the way out. This release closes the last gap in that promise: column names with spaces or true mixed case now survive the pruned extraction path on every engine, exactly as they already did in pushdown predicates.

dvt --version now tells you what you're actually connected to: every adapter your profile uses — including the ones living in dvt's isolated environments — with its version, and deliberately without upgrade nags: dvt owns those environments, so there's nothing for you to manage. Also, `dvt version` (the bare word) is gone; only the flag exists, exactly like dbt.

The api-portal sheds its cramped side drawer: every model gets a full page — columns, named endpoints, and a test console that runs APIs live and renders the rows as a data table. Plus the theme finally follows you: toggle light or dark once, and the hub, catalog and portal all agree.

The api-portal stops reading tables and starts virtualizing: every API call executes the model's logic live against its sources through the federation engine. Change a source row, the API answers differently — no dvt run. Plus named endpoints with locked row filters, dialect-correct identifier quoting, and a consumer console with snippets for four languages.

DVT grows a serving layer: switch any model on for REST consumption from a themed local portal — column-level access control, optional API keys, live queries against the model's own engine. Around it, the new DVT app suite on ports 46100–46109: one dvt serve starts the hub, the catalog, and the api-portal.

Every result line now carries its own story — rows inserted in green, coercion notes in yellow, no warning wall — and errors finally say what actually broke. Underneath: three engine fixes surfaced by real pipeline reshaping, and environments that heal their own Rosetta relics.

dvt kill grows into the one command you type when things feel stuck: catalogs come down, suspended runs (and the locks they hold) are reaped, and --force terminates running work deliberately.

Suspending a run doesn't kill it — it leaves a frozen process holding the federation cache lock, and the next run used to fail every model. DVT now detects the suspended run, reclaims the cache, warns you once, and carries on.

Protection by acceptance: a standard model that reads federated sources can never run through dbt alone — so DVT now runs it as federated, with a warning, instead of failing. The dag stays dbt's, the magic stays yours. Plus two extraction fixes the case exposed.

dvt retract is now the true mirror of dvt build — stored test failures come down with the models — and dvt run closes the last cross-connection escape hatch: standard materializations are refused foreign sources, not just foreign targets.

dvt retract grows up: dialect-correct drops on every engine, relations resolved exactly where the loader put them, bucket objects actually deleted, a --target override — and output that finally reads like dvt run.

A platform release: wheels for Python 3.13 and 3.14, Apple Silicon environments go native-arm64 only (Rosetta's days are numbered), and the catalog UI's light theme is rebuilt from the ground up as a true mirror of the dark one.

dvt version draws the actual DVT mark in full color (fastfetch-style), offline machine-bound licenses arrive, dvt retract returns by popular founder demand, dvt kill ends catalog-chasing, and the catalog UI gets a light theme.

Two foundations in one release. First: the dbt incremental experience, across engines — is_incremental() and {{ this }} now work in f_incremental models, your SQL owns the delta, and a tiny persisted index replaces full source replicas. Second: every dbt adapter now runs in its own isolated environment with its own dbt-core version — adapter version conflicts are structurally extinct. (0.2.6 was an internal milestone; all of its environment-isolation work ships here.)

The biggest performance release yet — homogeneous federated models now skip DuckDB entirely and stream source → target in a single hop — plus the new short materialization names, a hard guard against silently misrouted models, and an ASCII banner you'll actually want to run.

dvt seed grows into the simplest bulk loader you'll use: every Sling format, any target including buckets, and column names that behave identically on every engine.

dvt docs builds one catalog and one lineage graph across every engine in your project — and DVT's execution output becomes byte-for-byte dbt-style.

The federation pipeline becomes production-grade: parallel-safe caching, correct connection handling for the tricky engines, and incremental federation that holds up.

The first release of DVT as a wrapper around stock dbt-core: dbt runs everything it can, DVT federates the rest. No fork, no patched internals — dbt compatibility by construction.