Values in angle brackets (, , ...) come from the Vericto dashboard: ask the user for them, or copy this prompt from Dashboard → Integrations → Set up with AI, where they are filled in. You are adding Vericto SQL checks to this repository's CI for the Vericto workspace "". The Vericto CLI analyses SQL files (it never executes them) against the workspace's rules and fails the job when a statement is BLOCKED. Start by checking what is already in place, then only do what is missing or broken. Do not redo steps that already pass. MCP servers you may have: - vericto-account (support, read-only): setup_status, explain_block, search_docs. - vericto (runtime): check_sql, list_rules, show_rule. If vericto-account is not connected, inspect the repository instead and ask me to confirm anything you cannot see. Values (not secrets): dialect = , API URL = https://api.vericto.com, workspace id (for OIDC) = , CLI version = 1.8.2, action = vericto/check-sql@v1. Secrets: the API key is ALWAYS the CI secret named VERICTO_API_KEY. Never ask me to paste it, never print it, never commit it. Step 1 - Check current state. Look for an existing Vericto job: .github/workflows/*.yml using vericto/check-sql or "vericto check", .gitlab-ci.yml with "vericto check", .git/hooks/pre-commit calling vericto, and a .vericto.toml. Find where SQL lives (migrations/, db/, sql/, *.sql) and which dialect it is. If vericto-account is connected, call setup_status to see whether CI checks have already run for this workspace. Report what exists. Step 2 - Credential (a human does this). GitHub: prefer OIDC (no stored secret). Ask me to add a trust policy in the Vericto dashboard with issuer https://token.actions.githubusercontent.com, audience vericto and a subject pattern for this repository, and use oidc: true with workspace: . Otherwise (or on GitLab): ask me to create an API key in https://app.vericto.com/dashboard/api-keys with only the scope ci_dryrun:execute and store it as the CI secret / masked variable VERICTO_API_KEY. Wait for me to confirm. Step 3 - Add the CI job. GitHub Actions: add .github/workflows/vericto.yml triggered on pull_request for **/*.sql, with permissions contents: read, security-events: write and actions: read, a checkout with fetch-depth: 0, and the step - uses: vericto/check-sql@v1 with: api-key: ${{ secrets.VERICTO_API_KEY }} # or oidc: true + workspace: (then the job needs id-token: write) dialect: The action checks the changed *.sql files and uploads SARIF so findings appear on the PR. GitLab CI: add a job with image node:20 that runs "npm install -g @vericto/vericto-cli@1.8.2" and "vericto check --changed --dialect --format gitlab-codequality --output gl-code-quality.json", with VERICTO_API_KEY from the CI variable and artifacts:reports:codequality: gl-code-quality.json. Other CI: the same "vericto check --changed" command; a non-zero exit code fails the job. Show me the diff before committing. Step 4 - Local pre-commit hook (optional, ask me first). If I want it: install the CLI (npm install -g @vericto/vericto-cli@1.8.2), run "vericto login" (browser login, a 30-day key, nothing to paste) and "vericto init --hook", which writes .git/hooks/pre-commit to check staged *.sql files. Run "vericto doctor" and show me its summary. Step 5 - Verify. Run locally, with the key from the environment or after vericto login: echo "DELETE FROM vericto_setup_probe;" | vericto check - --dialect Expected: the statement is reported BLOCKED (missing WHERE) and the command exits with code 1. If it is only FLAGGED and exits 0, the workspace is in observe mode or the rule is not set to block: tell me. This costs one CI check from the monthly allowance. Then call vericto-account.explain_block with the report id from the output (or vericto.show_report) and summarise why it was blocked. Do not commit the probe. Step 6 - Enforce in CI. Confirm the job is required for merging (branch protection / merge request rules) only after I agree. Finish with a checklist: credential, CI job, hook, probe result.