ci.yml

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  rust:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: paradedb/paradedb:latest-pg17
        env:
          POSTGRES_USER: verity
          POSTGRES_PASSWORD: verity
          POSTGRES_DB: verity
        ports:
          - 5433:5432
        options: >-
          --health-cmd "pg_isready -U verity -d verity"
          --health-interval 5s
          --health-timeout 3s
          --health-retries 20
      # SpiceDB is NOT a service container: GitHub Actions can't override a
      # service image's command, and the authzed/spicedb image no longer
      # defaults to `serve` (a `:latest` drift that silently broke this job),
      # so the env-var approach printed help and the container died at init.
      # It's started as an explicit `docker run ... serve` step below instead,
      # mirroring deploy/docker-compose.yml exactly.
    steps:
      - uses: actions/checkout@v4
      - name: Start SpiceDB (explicit serve; runs during the build below)
        run: |
          docker run -d --name spicedb \
            -p 8443:8443 -p 50051:50051 \
            authzed/spicedb serve \
            --grpc-preshared-key verity-dev-key --http-enabled
      - uses: dtolnay/rust-toolchain@stable
        with:
          components: rustfmt, clippy
      - uses: Swatinem/rust-cache@v2
      - run: cargo fmt --all --check
      - run: cargo clippy --all-targets -- -D warnings
      - run: cargo build --workspace
      # Integration suite incl. the scope-soundness fuzzer (SPEC §7e): any
      # cross-scope result on any read path fails the build. Also the ER
      # precision gate (design §8/§9E): resolution_precision_fuzz +
      # resolution_precision_gate (pure, ≥0.99 precision / 0.0 false-merge-rate)
      # and resolution_scope_fuzz (DSN; a mis-linked entity surfacing across
      # scope handles fails the build).
      - name: Wait for SpiceDB HTTP gateway
        run: |
          for i in $(seq 1 40); do
            code=$(curl -s -o /dev/null -w "%{http_code}" \
              -X POST http://localhost:8443/v1/schema/read \
              -H "authorization: bearer verity-dev-key" \
              -H "content-type: application/json" -d '{}' || true)
            # Any HTTP status (200 or a 4xx "no schema written yet") means it is
            # serving; only 000 (connection refused) means not up yet.
            if [ -n "$code" ] && [ "$code" != "000" ]; then
              echo "SpiceDB responding (HTTP $code)"; exit 0
            fi
            sleep 2
          done
          echo "SpiceDB did not become healthy:"; docker logs spicedb || true; exit 1
      - run: cargo test --workspace
        env:
          VERITY_TEST_DSN: postgres://verity:verity@localhost:5433/verity
          # SpiceDB HTTP gateway + preshared key: makes the ReBAC / restricted-
          # tier / post-revocation soundness tests RUN (they now hard-error, not
          # skip, without an engine — M0 deliverables #1/#2).
          VERITY_SPICEDB_URL: http://localhost:8443
          VERITY_SPICEDB_KEY: verity-dev-key

  # Framework conformance harness (task #29): the six adapter packages driven
  # through REAL framework machinery (retrievers, BaseStore, unified Memory,
  # BaseMemoryService, Session protocol) against a live verity-server + Parade
  # DB. Framework churn is detected here and in framework-canary.yml — by CI,
  # not by users. Runs standalone (no `needs:`) so it parallelizes with the
  # rust job.
  integrations-e2e:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: paradedb/paradedb:latest-pg17
        env:
          POSTGRES_USER: verity
          POSTGRES_PASSWORD: verity
          POSTGRES_DB: verity
        ports:
          - 5433:5432
        options: >-
          --health-cmd "pg_isready -U verity -d verity"
          --health-interval 5s
          --health-timeout 3s
          --health-retries 20
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - uses: Swatinem/rust-cache@v2
      - run: cargo build --release -p verity-server
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install adapter packages (pinned floors) + test deps
        run: |
          python -m pip install --upgrade pip
          python -m pip install pytest respx \
            ./integrations/verity-llamaindex \
            ./integrations/verity-langchain \
            ./integrations/verity-langgraph \
            ./integrations/verity-crewai \
            ./integrations/verity-adk \
            ./integrations/verity-openai-agents
      # The default run must stay mock-only: pytest.ini deselects `e2e`.
      - name: Mock suites (e2e excluded by default)
        run: python -m pytest -q
        working-directory: integrations
      - name: e2e conformance harness
        run: bash integrations/run_e2e.sh
        env:
          VERITY_TEST_DSN: postgres://verity:verity@localhost:5433/verity

  # SRB metric 6 — consolidation precision/recall regression gate
  # (docs/design/knowledge-merge-tuning.md §4, Phase 0). Scores the labeled
  # statement-pair eval set (docs/benchmark/consolidation-pairs.jsonl) with the
  # CURRENT merge decision and fails if the false-merge rate FP/(FP+TN) at the
  # operating threshold exceeds the target. A false merge fabricates
  # cross-customer support (§1's governing asymmetry: a false merge is far worse
  # than a missed one), so any tuning that raises this rate must fail the build.
  # Needs no database — the merge decision is encoder + cosine only; the job
  # downloads the MiniLM-L6 ONNX model (~90MB) on first run. Runs standalone
  # (no `needs:`) so it parallelizes with the other jobs.
  #
  # Phase-0 baseline (2026-07-10, docs/benchmark/RESULTS-consolidation-2026-07-10):
  # at the shipped 0.85 threshold the decision merges 0/94 true paraphrase pairs
  # (recall 0.0, precision 1.0, false-merge rate 0.0). Target here is <= 1%
  # false-merge rate, matching §4's precision >= 0.99 contract; the current
  # cosine-only decision passes with a 0% margin. Bump the threshold argument in
  # lockstep with VERITY_KNOWLEDGE_MERGE_THRESHOLD when the cascade lands so the
  # gate always measures the shipped operating point.
  consolidation-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - uses: Swatinem/rust-cache@v2
      - run: cargo build --release -p verity-bench
      - name: consolidation false-merge-rate gate (<= 1%)
        run: |
          ./target/release/verity-bench consolidation-gate \
            --threshold 0.85 \
            --max-false-merge-rate 0.01