feat(bots): onboard reviewer-bot to pinned databricks-bot-engine

[eric-wang-1990]

Summary

Onboards both bots on databricks-sql-python to the upstream
databricks/databricks-bot-engine, pinned to engine SHA d24ca21 (post-#107 —
author flow selected from the issue Type) and fully PAT-free (App-auth).
This repo is the first clean consumer of the engine; onboarding friction is
captured as feedback (see the design doc + engine #97).

Design doc: docs/superpowers/specs/2026-07-14-onboard-bot-engine-design.md.

Reviewer bot (was vendored → now engine reusables, App-auth)

• Replaced the vendored scripts/reviewer_bot + scripts/shared with thin
  callers of the engine's reviewer-bot.reusable.yml / -followup.reusable.yml.
• engine-auth: app + no engine-pat: the reusable mints an engine-scoped App
  token from the review-bot App creds (engine PR sqlalchemy > 2.0.0 #100).
• Trigger unchanged: every non-fork PR.

Engineer bot (new — flow from issue Type)

• engineer-bot.yml (author, label an issue) + engineer-bot-followup.yml
  (reply on an engineer-bot-labeled PR). Own jobs (they build/run the
  connector), each minting an engine-scoped App token for a PAT-free REF install.
• Author flow chosen from the issue Type (per engine SQLAlchemy Dialect Compliance Tests #107): Bug ⇒ bug-fix,
  Feature ⇒ enhancement, any other type / none ⇒ the .bot/config.yaml
flow: bug-fix default.
• environment: azure-prod; explicit poetry install so the agent can run
  poetry run python -m pytest tests/unit to self-verify its red→green fix.
• .bot/config.yaml + engineer prompts, ported from the engine dogfood and
  rewritten for the connector (src/databricks/sql/, mocked tests/unit).

Secrets (all provisioned)

REVIEW_BOT_APP_ID/PRIVATE_KEY, ENGINEER_BOT_APP_ID/PRIVATE_KEY,
DATABRICKS_HOST, DATABRICKS_TOKEN. No BOT_ENGINE_PAT — App-auth
replaces it.

Prerequisite (engine-repo admin) — ✅ done

The review-bot and engineer-bot GitHub Apps are installed on
databricks-bot-engine with contents: read (required, else the App-auth
engine install fails for both bots).

Verification

• All workflow YAML + .bot/config.yaml parse; .bot/ tree complete; vendored
  code fully removed with no dangling references.
• Engine engine-auth: app install path validated end-to-end (engine PR sqlalchemy > 2.0.0 #100).
• Known follow-up: on the workflow_dispatch (manual) reviewer path the
  explore-tool read root falls back to the default branch — the automatic
  pull_request path (the normal case) is unaffected. Tracked separately.

This pull request and its description were written by Isaac.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[eric-wang-1990]

🚧 Held as draft pending an engine-side fix.

This onboarding is blocked on databricks/databricks-bot-engine#97: the reusable
reviewer workflow can only install the internal engine via a stored
BOT_ENGINE_PAT, and we've chosen to go PAT-free (mint an engine-scoped
GitHub App token instead). Once #97 lands in a merged engine release we'll:

1. Bump the pinned engine SHA here to the post-fix commit.
2. Switch the reviewer workflows to engine-auth: app and drop engine-pat.
3. Restore the pull_request triggers and mark ready for review.

The engineer-bot onboarding (bug-fix flow, PAT-free via its own job) will be
added to this PR in the same change so both bots land together.

Prerequisite for either bot: the review/engineer GitHub App must be installed on
databricks-bot-engine with contents: read.

[eric-wang-1990]

✅ Live verification progress (reviewer)

After installing both bot Apps on databricks-sql-python and
databricks-bot-engine, the reviewer run now clears every infrastructure step:

Step	Result
Set up job	✅
Checkout	✅
Mint review-bot App token	✅ (App now installed on this repo)
Setup Python / Node	✅
Mint engine-scoped install token	✅
Install engine + Claude SDK/CLI	✅ PAT-free pip-install of the private engine works
Resolve trigger inputs	✅
Run reviewer	🔄 running (the agent itself)

This validates the whole onboarding chain: local-composite install (no cross-repo
uses:), App-token auth on both repos, and the PAT-free engine install. Only the
agent execution remains to confirm.

[peco-review-bot]

Verdict: 1 High · 1 Medium · 2 Low

Mostly workflow/config plumbing for onboarding the review + engineer bots; no product (src/) code changes. Main concerns: a TEMP e2e workflow the PR itself marks DO-NOT-MERGE is still in the diff (F1), a stray doubly-nested setup-jfrog/setup-jfrog action that nothing references and duplicates the real one (F2), plus a couple of comment/outcome-string mismatches (F3, F4).

[peco-review-bot]

Verdict: 1 Medium · 1 Low

Onboarding PR is almost entirely CI/workflow/config with no connector src/ changes, so risk is scoped to the GitHub Actions. Two issues worth addressing before merge: a self-declared TEMP "DO NOT MERGE" e2e workflow that is still in the diff (medium), and an orphaned double-nested setup-jfrog/setup-jfrog/action.yml duplicate that nothing references (low). Nit: the reviewer-bot.yml header comment still says the token is passed "as engine-pat to install-bot-engine", but the composite input is engine-token — stale wording, worth a one-line fix.

[eric-wang-1990]

✅ Ready for review — both bots onboarded and verified live

Squashed to 3 signed-off commits (DCO green). Both bots run against the upstream
databricks-bot-engine (pinned b6205fb), PAT-free (engine-scoped App tokens).

Verified end-to-end:

• Reviewer — posted a real review on this PR as peco-review-bot (inline findings).
• Engineer (author) — ran 41 turns to a correct structured no_change_needed
  (via a temporary branch-only harness, since issues/dispatch triggers register
  from main; harness removed).

Key design point (first clean consumer): an external repo cannot uses: the
internal engine's actions/reusable workflows cross-repo. So the engine is
installed via a local install-bot-engine composite that pip installs it over
HTTPS with an App token, and connector deps come from the repo's own
setup-poetry (JFrog mirror, egress-safe). Documented in the design doc + engine
issue #104 / doc-PR #105.

Superseded: the vendored reviewer-bot stack (#832/#833/#834) — closed.

[peco-review-bot]

Verdict: 1 Medium

Mostly workflow/config plumbing that reads carefully and is well-commented. One medium concern: the engineer-bot issue-comment case matches no_change, while the prompt and the design doc's live-verification note both use the token no_change_needed — a mismatch that would mislabel a real no-change outcome as a failure. Worth confirming the engine's exact outcome-enum string before merge.

[peco-review-bot]

Verdict: 1 Medium · 1 Low

Solid infra onboarding PR — no security or correctness issues in the token-minting / gating logic, which is carefully done. One medium concern: the issue-comment case in engineer-bot.yml matches no_change but the author actually emits no_change_needed (per this PR's own prompt and design doc), so no-change runs post a misleading "could not complete a fix" comment. Plus one low: the coverage_pr_url output name looks like a copy-paste from a coverage flow and should be confirmed against the engine's bug-fix publish output.

[peco-review-bot]

Verdict: 1 Low

Looks good overall — this is CI/workflow + .bot/ prompt plumbing with no src/ changes, so the correctness/test axes are limited. Vendored-code removal is clean (grep confirms no dangling scripts.reviewer_bot/scripts.shared references), token handling in install-bot-engine is careful (job-local git extraheader, masking, SHA pin validation), and the security gates are sound. One low-severity gate inconsistency noted inline.

Nits (no inline anchor needed): (1) install-bot-engine/action.yml hardcodes sdk-version: 0.2.102 / cli-version: 2.1.61 defaults that must be manually kept in sync with the engine at the pinned SHA — the comments flag this, but it's a standing drift risk worth a periodic check. (2) The JFrog OIDC block relies on the friendly ACCESS_TOKEN empty-check for error messaging, but under set -euo pipefail a missing ACTIONS_ID_TOKEN_REQUEST_TOKEN would abort at the curl | jq pipe before that check fires; since a

[...truncated to keep verdict scannable]

[peco-review-bot]

Verdict: 2 Low

Looks good overall — a clean, well-documented bot-onboarding PR (workflow YAML, local composite actions, prompts, config; no product code touched). Two low-severity consistency notes: the bot-prelude engine-repo input isn't honored by the engine-token mint step, and the initial reviewer workflow lacks the per-PR concurrency group its siblings have. Security-sensitive paths (untrusted issue/PR input via files + env heredocs, digits-only validation, PAT-free git-auth masking, fork gates) are handled carefully.

[peco-review-bot]

Verdict: 1 Low

Looks good — clean, well-documented onboarding PR. Vendored-bot deletions are confirmed (no dangling references), the four workflows are internally consistent (shared bot-prelude/install-bot-engine composites, PAT-free App-auth, consistent MODEL_ENDPOINT, bot-login prefixes matching .bot/config.yaml), and the untrusted-input handling (digits-only issue/PR validation, heredoc-delimiter collision guard, issue body via file not shell) is careful. One low-confidence note about the workflow_dispatch checkout ref for the reviewer, posted inline.

[peco-review-bot]

Verdict: 1 Low

Onboarding-only PR: four bot workflows + two local composite actions + .bot/ config/prompts, no connector source touched. Auth (engine-scoped App token via git extraheader, PAT-free), input hardening (digits-only validation, untrusted issue body → file, heredoc-delimiter collision check), and the fork/open-PR/label gates all look sound. One low finding: the actually-pinned engine SHA (d24ca217...) matches nowhere in the PR description or design doc (which cite b6205fb / d780b2d), and is duplicated across all four workflows.

[peco-review-bot]

Verdict: 1 Low

Looks good — bot/CI onboarding only, no connector source touched; auth flow, fork gates, and untrusted-input handling are careful and well-commented. One low inline note: engineer-bot-followup.yml passes PR_BASE_SHA but (unlike reviewer-bot-followup.yml) never ensures the base commit is fetched. Meta nit for the author, not inline: the PR description states the engine is pinned to SHA b6205fb, but all four workflows pin d24ca2171d191a652a67f4f43995f0959c9a5791 (the design doc's later update confirms b6205fb was an earlier draft) — update the description so reviewers/maintainers see the engine version that actually runs.

[peco-review-bot]

Verdict: 1 Low

Solid, carefully-written bot-onboarding infra — vendored code is fully removed (no dangling refs outside the design doc), setup-poetry supplies the interpreter the engine install needs, and security handling (40-char SHA pin validation, masked tokens, git extraheader instead of in-URL creds, argv-prefix bash allowlist, untrusted-input-to-file) is thorough. One low error-handling nit inline. Nits (summary-only): the PR title/description states the engine is pinned to b6205fb, but all four workflows pin d24ca2171d191a652a67f4f43995f0959c9a5791 (the description's later "Update" sections clarify b6205fb was an earlier draft — worth aligning the title). Similarly, the design doc's "Engine pin" section still names d780b2da… while its own later updates use d24ca217…; harmless but stale.

[peco-review-bot]

Verdict: 1 Medium

Solid, carefully-gated onboarding PR — no connector source changes, and the workflow/token/security logic is well-reasoned and thoroughly commented. One medium consistency gap: the .bot/config.yaml templates (name, branch_prefix, pr_title_template, commit_message_template) are all bug-fix-only, but engineer-bot.yml now routes Feature issues to the enhancement flow, which would emit fix:/bugfix-labelled PRs, commits, and branches for enhancements.

[peco-review-bot]

Verdict: 1 Low

Infrastructure onboarding PR (bot workflows, two local composite actions, engineer-bot config + prompts, design doc). Well-structured and heavily annotated with security reasoning; the token minting, digits-only issue/PR validation, $GITHUB_ENV heredoc-delimiter guard, SHA-pin validation, and fork/open-PR gates all look sound, and no dangling references to the removed vendored bot code remain in the workflows. One low note on the git diff bash-allowlist claim; otherwise looks good.

[peco-review-bot]

🔵 Low — The allowlist entry [git, diff, HEAD] is an argv prefix match, so git diff HEAD --no-index <pathA> <pathB> also matches the prefix. The adjacent comment argues a bare (git, diff) prefix must be avoided because it would allow git diff --no-index /etc/passwd /dev/null to read arbitrary absolute paths bypassing safe_path. Pinning to HEAD narrows but does not obviously eliminate that class: an argv beginning git diff HEAD ... still passes the prefix check, and whether git then rejects the trailing --no-index <abs> <abs> depends on git's arg parsing, not on the allowlist. If the engine's bash sandbox truly validates only the argv prefix (as the config comments state), consider confirming git actually errors on git diff HEAD --no-index …, or constrain the entry further (e.g. only permit the exact forms git diff HEAD, git diff HEAD~<n>, git diff --cached). Low severity since exploiting it requires the agent to be adversarial and the runner is ephemeral, but the comment asserts a stronger guarantee than the prefix rule provides.