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 b6205fb 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 — bug-fix flow)

• 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.
• 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.

⚠️ Hard prerequisite (engine-repo admin)

The review-bot and engineer-bot GitHub Apps must be installed on
databricks-bot-engine with contents: read, or 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.
• Not yet exercised end-to-end — gated on the App-on-engine-repo install.
  First live signals: a test PR (reviewer) and a labelled throwaway issue
  (engineer author). Will report actual outcomes, not assume success.

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.

[peco-review-bot]

Verdict: 1 Medium · 2 Low

Onboarding PR — workflows, local composite action, and .bot prompts/config only; no connector source touched. Looks mostly solid, but one stray dead action file at a doubly-nested path (setup-jfrog/setup-jfrog/) should be removed, and two engine-output-name assumptions in engineer-bot.yml (no_change case arm, coverage_pr_url) are worth confirming against the pinned engine since a mismatch would silently misreport outcomes on the tracking issue. Nit: the reviewer-bot.yml header comment still says the App token is passed "as engine-pat to install-bot-engine", but the local composite's input is engine-token — stale wording worth fixing.

[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]

🔵 Low — On the workflow_dispatch path this job checks out the default branch (the checkout step uses no ref:, so on dispatch it resolves to the repo default branch rather than the target PR), while HEAD_SHA for the run is separately resolved via gh pr view "$RAW_PR" --json headRefOid. On the pull_request trigger the default ref is the PR merge ref (correct), but on a manual dispatch of an arbitrary pr_number the working tree and HEAD_SHA diverge — the reviewer's read_paths/grep would then read default-branch code while the diff/anchors reference the PR head.

If run_review fetches/reads content purely via the GitHub API keyed on HEAD_SHA, this is harmless; if it relies on the local checkout for context, a dispatched review targets the wrong tree. Worth confirming against the engine's run_review behavior, or checking out HEAD_SHA explicitly on the dispatch path. (Low: the automatic pull_request path — the normal case — is correct; only manual dispatch is affected.)