specdbt 0.1.0__tar.gz

specdbt-0.1.0/.claude/skills/specdbt/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: specdbt
+description: Load specdbt's OKF architecture knowledge bundle (docs/knowledge/) as context before answering questions about this repo's design, then offer to refresh any doc that looks stale against current source.
+---
+
+# specdbt Knowledge Bundle
+
+This repo's architecture reference lives in `docs/knowledge/`, an [Open
+Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)
+v0.2 bundle. Use it instead of a fresh grep/read of `src/` when answering
+questions about specdbt's design.
+
+## Steps
+
+1. Read `docs/knowledge/index.md`.
+2. Read every concept doc it links to (`pipeline.md`,
+   `two-tier-design.md`, `adapters.md`, `dbt-integration.md`,
+   `native-unit-tests.md`, `cli.md`, `ai.md`, `gherkin-style-guide.md`,
+   `databricks-validation-checklist.md`).
+3. Answer the user's question grounded in that bundle. If something the
+   user asks about isn't covered, say so rather than guessing, and fall
+   back to reading the relevant source under `src/specdbt/`.
+4. Before finishing, check whether anything you read in `src/` while
+   answering contradicts a concept doc. If so, tell the user which doc
+   looks stale and offer to update it — don't rewrite it automatically.

specdbt-0.1.0/.github/CODEOWNERS

@@ -0,0 +1 @@
+* @SanaVarsi

specdbt-0.1.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,29 @@
+name: Bug report
+description: Something isn't working as expected
+labels: ["bug"]
+body:
+  - type: textarea
+    id: description
+    attributes:
+      label: What happened?
+      description: What you expected instead, and what actually happened.
+    validations:
+      required: true
+  - type: textarea
+    id: repro
+    attributes:
+      label: Minimal reproduction
+      description: A minimal `.feature` file / model / command that reproduces it.
+      render: shell
+  - type: input
+    id: version
+    attributes:
+      label: specdbt version
+      description: Output of `specdbt --version` (or `pip show specdbt`).
+    validations:
+      required: true
+  - type: input
+    id: adapter
+    attributes:
+      label: dbt adapter
+      description: e.g. duckdb, postgres, databricks, snowflake

specdbt-0.1.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability
+    url: https://github.com/SanaVarsi/specdbt/security/advisories/new
+    about: Please report vulnerabilities privately, not as a public issue.

specdbt-0.1.0/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,14 @@
+name: Feature request
+description: Suggest an idea or enhancement
+labels: ["enhancement"]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem does this solve?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed solution

specdbt-0.1.0/.github/dependabot.yml

@@ -0,0 +1,20 @@
+version: 2
+updates:
+  # Keeps the SHA-pinned actions in ci.yml/release.yml current -- Dependabot
+  # bumps the pin and refreshes the version comment together.
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    # Actions run inside CI with ambient trust (secrets, environment
+    # access) -- major bumps get a deliberate look, not auto-approval.
+    # Security-advisory PRs bypass this and land regardless.
+    ignore:
+      - dependency-name: "*"
+        update-types: ["version-update:semver-major"]
+
+  # uv.lock + pyproject.toml.
+  - package-ecosystem: "uv"
+    directory: "/"
+    schedule:
+      interval: "weekly"

specdbt-0.1.0/.github/pull_request_template.md

@@ -0,0 +1,7 @@
+## What & why
+
+## Checklist
+
+- [ ] `just test` (or `uv run pytest`) passes locally
+- [ ] `pre-commit run --all-files` passes locally
+- [ ] Docs/comments updated if behavior changed

specdbt-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,100 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+  workflow_call: # lets release.yml re-run this same suite before publishing
+
+# Least-privilege default; jobs escalate only what they individually need.
+permissions:
+  contents: read
+
+jobs:
+  gitleaks:
+    # Separate from `test`: the pre-commit gitleaks hook below only
+    # scans the staged diff (`--pre-commit --staged`), which is empty
+    # on `pre-commit run --all-files` against a clean CI checkout --
+    # it always passes trivially there regardless of what the repo
+    # actually contains. This job does the real full-history scan the
+    # pre-commit hook can't, via gitleaks-action, which needs full
+    # git history (fetch-depth: 0) to see past commits, not just HEAD.
+    runs-on: ubuntu-latest
+    # gitleaks-action only understands push/pull_request -- release.yml
+    # calls this workflow with github.event_name still "release" (it
+    # propagates from the caller), which the action rejects outright.
+    # Code reaching a release already went through this scan on its
+    # original push/PR, so skipping here is a no-op, not a gap.
+    if: github.event_name == 'push' || github.event_name == 'pull_request'
+    permissions:
+      contents: read
+      # gitleaks-action calls the GitHub API to list the PR's commits and
+      # scope the scan to them on a pull_request event -- without this,
+      # the default token has no pull-requests scope and the call 403s.
+      pull-requests: read
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          fetch-depth: 0
+      - uses: gitleaks/gitleaks-action@e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e # v3.0.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+  test:
+    runs-on: ubuntu-latest
+    services:
+      postgres:
+        image: postgres:16
+        env:
+          POSTGRES_USER: specdbt
+          POSTGRES_DB: specdbt_test
+          POSTGRES_PASSWORD: ${{ secrets.SPECDBT_PG_SECRET }}
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd pg_isready
+          --health-interval 10s
+          --health-timeout 5s
+          --health-retries 5
+    steps:
+      # Full history + tags -- hatch-vcs derives the package version from
+      # the nearest git tag, which a shallow checkout can't see.
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          fetch-depth: 0
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@20cfd1bf945f4377ade1205e4dbc17946fc9a30d # v10.0.1
+        with:
+          enable-cache: true
+          # Pinned to match the uv-pre-commit hook's uv version below --
+          # an unpinned uv here could rewrite uv.lock to a newer lockfile
+          # revision than the hook's `uv lock --check` expects, failing
+          # it for a reason that has nothing to do with an actual drift.
+          version: "0.11.25"
+
+      - name: Install dependencies
+        run: uv sync --all-extras
+
+      - name: Cache pre-commit environments
+        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
+        with:
+          path: ~/.cache/pre-commit
+          key: pre-commit-${{ hashFiles('.pre-commit-config.yaml') }}
+
+      - name: Pre-commit hooks (lint, formatting, type-check, hygiene)
+        run: uv run pre-commit run --all-files --show-diff-on-failure
+
+      - name: Install dbt_utils for the example project
+        working-directory: examples/jaffle_shop
+        run: uv run --project ../.. dbt deps --profiles-dir profiles
+
+      - name: Test
+        env:
+          SPECDBT_TEST_POSTGRES: "1"
+          SPECDBT_PG_HOST: localhost
+          SPECDBT_PG_PORT: "5432"
+          SPECDBT_PG_USER: specdbt
+          SPECDBT_PG_DBNAME: specdbt_test
+          SPECDBT_PG_SECRET: ${{ secrets.SPECDBT_PG_SECRET }}
+        run: uv run pytest -v

specdbt-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,166 @@
+name: Release
+
+# Trusted publishing to PyPI (OIDC, no API token secret). One-time setup:
+#   1. On pypi.org, add a *pending* trusted publisher for project "specdbt"
+#      naming this owner/repo, workflow filename "release.yml", and
+#      environment "pypi" -- exactly, all three are load-bearing.
+#   2. Create a GitHub Environment named "pypi" on this repo.
+#
+# Two ways to release, both land here:
+#   - Actions tab -> Run workflow -> pick a bump (or type an exact
+#     version). The `tag` job below computes the next vX.Y.Z, tags it,
+#     and opens the GitHub Release itself, then this same run continues
+#     into test/build/publish -- a release created by a workflow's own
+#     GITHUB_TOKEN can't trigger other workflows (GitHub's anti-loop
+#     protection), so continuing in-run is what makes this work without
+#     a personal access token.
+#   - Publishing a GitHub Release by hand (a human token, which *does*
+#     trigger events) fires this directly via `release: published`; the
+#     `tag` job just skips itself since the tag already exists.
+#
+# Either way, pyproject.toml's version is derived from the tag via
+# hatch-vcs -- nothing to hand-edit or keep in sync.
+on:
+  release:
+    types: [published]
+  workflow_dispatch:
+    inputs:
+      bump:
+        description: "Version bump (ignored if 'version' is set)"
+        type: choice
+        options: [patch, minor, major]
+        default: patch
+      version:
+        description: "Exact version to release instead, e.g. 1.2.0 (optional)"
+        type: string
+        default: ""
+
+# Least-privilege default; jobs escalate only what they individually need.
+permissions:
+  contents: read
+
+jobs:
+  tag:
+    if: github.event_name == 'workflow_dispatch'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write # to create the tag + GitHub Release
+    outputs:
+      version: ${{ steps.next.outputs.version }}
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          fetch-depth: 0 # need full tag history to find the latest release
+
+      - name: Compute next version
+        id: next
+        run: |
+          set -euo pipefail
+          if [ -n "${{ inputs.version }}" ]; then
+            next="${{ inputs.version }}"
+          else
+            latest="$(git tag --list 'v*' --sort=-v:refname | head -1)"
+            latest="${latest#v}"
+            latest="${latest:-0.0.0}"
+            IFS='.' read -r major minor patch <<< "$latest"
+            case "${{ inputs.bump }}" in
+              major) next="$((major + 1)).0.0" ;;
+              minor) next="$major.$((minor + 1)).0" ;;
+              patch) next="$major.$minor.$((patch + 1))" ;;
+            esac
+          fi
+          if git rev-parse "v$next" >/dev/null 2>&1; then
+            echo "tag v$next already exists" >&2
+            exit 1
+          fi
+          echo "version=$next" >> "$GITHUB_OUTPUT"
+
+      - name: Tag + publish release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          NEXT: ${{ steps.next.outputs.version }}
+        run: |
+          set -euo pipefail
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git tag -a "v$NEXT" -m "specdbt v$NEXT"
+          git push origin "v$NEXT"
+          gh release create "v$NEXT" \
+            --title "v$NEXT" \
+            --generate-notes \
+            --repo "${{ github.repository }}"
+
+  # Reruns the same suite ci.yml runs on every push/PR -- a merged, green
+  # commit doesn't guarantee the exact tagged ref is still green, and this
+  # is the last gate before an irreversible PyPI upload.
+  test:
+    needs: tag
+    if: always() && (needs.tag.result == 'success' || needs.tag.result == 'skipped')
+    uses: ./.github/workflows/ci.yml
+    secrets: inherit
+    # ci.yml's gitleaks job needs pull-requests: read for its own scan --
+    # a called workflow can't exceed what the caller grants it here.
+    permissions:
+      contents: read
+      pull-requests: read
+
+  build:
+    needs: [tag, test]
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      # Full history + tags -- hatch-vcs derives the package version from
+      # the tag. Pin explicitly to it when the `tag` job ran (workflow_dispatch)
+      # so a commit landing on main between tagging and this checkout can't
+      # slip in ahead of the release it's building; a release-event run
+      # already has the tag as github.ref.
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          fetch-depth: 0
+          ref: ${{ needs.tag.outputs.version && format('v{0}', needs.tag.outputs.version) || github.ref }}
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@20cfd1bf945f4377ade1205e4dbc17946fc9a30d # v10.0.1
+        with:
+          enable-cache: true
+          version: "0.11.25"
+
+      - name: Build sdist + wheel
+        run: uv build
+
+      - name: Built version matches release tag
+        # Catches hatch-vcs silently falling back to a dev version (e.g.
+        # the tag wasn't actually visible to the checkout above) before it
+        # reaches PyPI -- the one thing the old hand-written version field
+        # let us check directly. sdist filename is specdbt-X.Y.Z.tar.gz.
+        env:
+          TAGGED_VERSION: ${{ needs.tag.outputs.version }}
+        run: |
+          tag="${TAGGED_VERSION:-${GITHUB_REF_NAME#v}}"
+          built="$(basename dist/specdbt-*.tar.gz .tar.gz | sed 's/^specdbt-//')"
+          if [ "$tag" != "$built" ]; then
+            echo "release tag v$tag does not match built version $built"
+            exit 1
+          fi
+
+      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write # OIDC for trusted publishing -- no token secret needed
+      contents: read
+      attestations: write # PEP 740 build provenance attestation
+    steps:
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: dist
+          path: dist/
+
+      - uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # release/v1

specdbt-0.1.0/.gitignore

@@ -0,0 +1,30 @@
+__pycache__/
+*.py[cod]
+.venv/
+*.egg-info/
+dist/
+build/
+.pytest_cache/
+.ruff_cache/
+.DS_Store
+
+# Local tool config/state, not project source
+.serena/
+.superpowers/
+.claude/settings.local.json
+local_work/
+
+# dbt example projects (examples/**): real dbt run artifacts, never source
+examples/**/dbt_packages/
+examples/**/logs/
+examples/**/target/
+examples/**/*.duckdb
+examples/**/.user.yml
+# Test runs with a relative `path:` in a scratch profiles.yml resolve it
+# against the process cwd, not --project-dir -- stray .duckdb files can end
+# up at the repo root when tests run from here. Not committed either way,
+# but keep them out of `git status` noise.
+/*.duckdb
+logs/
+.worktrees/
+.env

specdbt-0.1.0/.pre-commit-config.yaml

@@ -0,0 +1,48 @@
+repos:
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.16.5
+    hooks:
+      - id: ruff-check
+      - id: ruff-format
+
+  - repo: https://github.com/astral-sh/ty-pre-commit
+    rev: v0.0.75
+    hooks:
+      - id: ty
+
+  - repo: https://github.com/astral-sh/uv-pre-commit
+    rev: "0.11.25"
+    hooks:
+      - id: uv-lock
+
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+      - id: check-toml
+      - id: check-ast
+      - id: check-added-large-files
+      - id: check-merge-conflict
+      - id: debug-statements
+      - id: mixed-line-ending
+
+  - repo: https://github.com/crate-ci/typos
+    rev: v1.50.0
+    hooks:
+      - id: typos
+        # docs/ holds prose specs/plans with technical shorthand typos
+        # flags; examples/ has generated dbt_packages/target dirs that
+        # are gitignored but present locally during a run.
+        exclude: ^(docs/|examples/.*/(dbt_packages|target|logs)/)
+
+  - repo: https://github.com/abravalheri/validate-pyproject
+    rev: v0.25
+    hooks:
+      - id: validate-pyproject
+
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.30.1
+    hooks:
+      - id: gitleaks

specdbt-0.1.0/AGENTS.md

@@ -0,0 +1,20 @@
+# specdbt — Agent Notes
+
+For any question about this repo's design, conventions, or testing
+approach, consult the OKF knowledge bundle at
+[`docs/knowledge/`](docs/knowledge/index.md) first — it is the source of
+truth for this repo's architecture and conventions. Only fall back to
+reading `src/specdbt/` from scratch when the bundle doesn't cover what
+you need.
+
+## Conventions
+
+- Tests mirror `src/specdbt/` under `tests/`, with the package level
+  flattened (e.g. `src/specdbt/runner.py` -> `tests/test_runner.py`,
+  `src/specdbt/dbt_integration/fixture_sql.py` ->
+  `tests/dbt_integration/test_fixture_sql.py`) — not always 1:1; some
+  source files share a test file or split across several.
+- Gherkin scenario style: see
+  [`docs/knowledge/gherkin-style-guide.md`](docs/knowledge/gherkin-style-guide.md).
+- Databricks-specific test considerations: see
+  [`docs/knowledge/databricks-validation-checklist.md`](docs/knowledge/databricks-validation-checklist.md).

specdbt-0.1.0/CLAUDE.md

@@ -0,0 +1,5 @@
+@AGENTS.md
+
+Claude Code users: the `/specdbt` skill (`.claude/skills/specdbt/`) loads
+the `docs/knowledge/` bundle referenced above as context on demand — use
+it instead of re-reading `src/specdbt/` from scratch.

specdbt-0.1.0/CONTRIBUTING.md

@@ -0,0 +1,71 @@
+# Contributing to specdbt
+
+Issues, ideas, and PRs are welcome.
+
+## Before you start
+
+[`docs/knowledge/index.md`](docs/knowledge/index.md) is the source of
+truth for this repo's architecture and conventions — read it (or have
+your agent load it via the `/specdbt` skill) before making non-trivial
+changes. `AGENTS.md` covers test-file layout and links the
+[Gherkin style guide](docs/knowledge/gherkin-style-guide.md) for writing
+`.feature` scenarios.
+
+The `ExecutionAdapter` interface (`src/specdbt/adapters/base.py`) is the
+extension point for a new backend — one new class, not a rewrite.
+
+## Local setup
+
+```bash
+just setup   # uv sync + pre-commit install (see `just doctor` if uv/Docker is missing)
+just test    # full test suite
+```
+Without `just`: `uv sync && uv run pre-commit install && uv run pytest`.
+
+Pre-commit runs ruff, ty, uv-lock, typos, gitleaks, and hygiene checks on
+every commit; CI runs the identical set (`pre-commit run --all-files`).
+Exception: `gitleaks` pre-commit only scans the staged diff, so CI also
+runs a separate `gitleaks-action` job over full history.
+
+`uv run pytest` alone only exercises DuckDB. Two more test files cover
+other adapters, both skipped unless you opt in:
+
+**Postgres** (CI-verified, runnable locally with Docker):
+```bash
+just postgres-up     # starts Postgres in Docker, writes .env if missing
+just test-postgres   # exports the right env vars, runs the test
+```
+Manual path: create a gitignored `.env` with `POSTGRES_USER`,
+`POSTGRES_PASSWORD`, `POSTGRES_DB`; `docker compose up -d postgres`; then
+export those same values as `SPECDBT_PG_USER`/`SPECDBT_PG_SECRET`/
+`SPECDBT_PG_DBNAME` plus `SPECDBT_PG_HOST=localhost SPECDBT_PG_PORT=5432
+SPECDBT_TEST_POSTGRES=1` and run `uv run pytest
+tests/test_dbt_adapter_postgres.py -v` (see `tests/conftest.py` for why
+the names differ).
+
+**Databricks** (manual, needs your own workspace, no CI): see
+`docs/knowledge/databricks-validation-checklist.md`.
+
+## Pull requests
+
+- Keep tests mirroring `src/specdbt/` under `tests/` (see `AGENTS.md`).
+- `uv run pre-commit run --all-files` and `uv run pytest` clean before
+  pushing.
+- Describe the behavior change, not just the diff — a scenario or test
+  demonstrating it is the strongest review evidence.
+
+## Release process (maintainers)
+
+Versioning is manual. Bump `version` in `pyproject.toml`, then tag and
+publish a GitHub Release from that commit. The tag must be `vX.Y.Z`,
+matching the `pyproject.toml` value exactly.
+
+The release workflow then runs on publish: full CI suite against that
+tag, build, and a PyPI publish step using trusted publishing, so there is
+no stored API token.
+
+One-time repo setup this depends on, all separate from anything in this
+repo's code:
+- a PyPI trusted publisher entry pointing at this repo
+- a GitHub environment named `pypi`
+- a repo secret the CI Postgres job reads (see `ci.yml`)

specdbt-0.1.0/Justfile

@@ -0,0 +1,90 @@
+# One-command local dev setup. Install `just` first:
+#   macOS:  brew install just
+#   other:  https://github.com/casey/just#installation
+# Then: `just setup` once, `just` (no args) to list targets.
+
+default:
+    @just --list
+
+# Bootstrap everything needed to develop: python deps, git hooks.
+setup:
+    #!/usr/bin/env bash
+    set -euo pipefail
+    command -v uv >/dev/null 2>&1 || {
+        echo "uv not found. Install: curl -LsSf https://astral.sh/uv/install.sh | sh"
+        exit 1
+    }
+    uv sync
+    uv run pre-commit install
+    echo "Setup done. Try: just test"
+
+# Check for tools this repo uses and print an install hint for anything missing.
+doctor:
+    #!/usr/bin/env bash
+    set -euo pipefail
+    ok=1
+    check() {
+        if command -v "$1" >/dev/null 2>&1; then
+            echo "  ok    $1"
+        else
+            echo "  MISSING  $1  -- $2"
+            ok=0
+        fi
+    }
+    check uv     "curl -LsSf https://astral.sh/uv/install.sh | sh"
+    check docker "https://docs.docker.com/get-docker/  (only needed for 'just postgres-up')"
+    [ "$ok" = 1 ] && echo "All required tools present." || { echo "Fix the above, then re-run 'just doctor'."; exit 1; }
+
+# Full test suite -- DuckDB only, no external services required.
+test:
+    uv run pytest
+
+# Scaffold DIR with an example .feature file + canned result (default: features/).
+init dir="features":
+    uv run specdbt init {{dir}}
+
+# Run .feature files under TARGET (--engine fake by default); ARGS pass through to `specdbt run`.
+run target="features" *args:
+    uv run specdbt run {{target}} {{args}}
+
+# Run the bundled jaffle_shop example against real dbt+DuckDB (both tiers).
+run-example:
+    #!/usr/bin/env bash
+    set -euo pipefail
+    (cd examples/jaffle_shop && uv run dbt deps --profiles-dir profiles)
+    uv run specdbt run examples/jaffle_shop/features \
+        --engine dbt \
+        --project-dir examples/jaffle_shop \
+        --profiles-dir examples/jaffle_shop/profiles
+
+# Start local Postgres in Docker for the adapter test (generates .env on first run).
+postgres-up:
+    #!/usr/bin/env bash
+    set -euo pipefail
+    command -v docker >/dev/null 2>&1 || {
+        echo "docker not found. Install: https://docs.docker.com/get-docker/"
+        exit 1
+    }
+    if [ ! -f .env ]; then
+        generated="$(openssl rand -hex 12)"
+        {
+            echo "POSTGRES_USER=specdbt"
+            printf 'POSTGRES_%s=%s\n' "PASSWORD" "$generated"
+            echo "POSTGRES_DB=specdbt_test"
+        } > .env
+        echo "Wrote .env with a freshly generated local-only credential (gitignored)."
+    fi
+    docker compose up -d postgres
+    echo "Postgres is up on localhost:5432. Next: just test-postgres"
+
+# Run the Postgres adapter test against the container from 'postgres-up'.
+test-postgres:
+    #!/usr/bin/env bash
+    set -euo pipefail
+    [ -f .env ] || { echo "No .env found -- run 'just postgres-up' first."; exit 1; }
+    set -a; source .env; set +a
+    export SPECDBT_PG_USER="$POSTGRES_USER"
+    export SPECDBT_PG_SECRET="$POSTGRES_PASSWORD"
+    export SPECDBT_PG_DBNAME="$POSTGRES_DB"
+    export SPECDBT_PG_HOST=localhost SPECDBT_PG_PORT=5432 SPECDBT_TEST_POSTGRES=1
+    uv run pytest tests/test_dbt_adapter_postgres.py -v

specdbt-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 SanaVarsi
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.