External consumers cannot `uses:` the internal engine's actions/reusable
workflows cross-repo (GitHub: "not found"). This local composite instead
pip-installs the pinned engine over HTTPS with a short-lived, engine-scoped
GitHub App token (no stored BOT_ENGINE_PAT), routing pip/npm through the internal
JFrog mirror for the egress-blocked protected runner. Shared by all four bot
workflows.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

Onboard the PR reviewer to the upstream engine (pinned SHA b6205fb), replacing
the previously-vendored scripts/reviewer_bot. Own-job workflows: mint the
review-bot App token, install the engine via the local composite (engine-scoped
App token, no PAT), run reviewer_bot.run_review / .followup. Trigger: every
non-fork PR. .bot/prompts/review/system.md is repo-specific ADDITIVE guidance
appended to the engine-owned base prompt. Verified live — posted a review as
peco-review-bot on this PR.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

Add the engineer bot: author (label an issue) reproduces a bug with a failing
test, fixes the connector, opens a PR; followup addresses review comments on
engineer-bot-labeled PRs. Own jobs (they build/run the connector): mint tokens,
setup-poetry for connector deps (JFrog mirror, egress-safe self-verify env),
install the engine via the local composite (engine-scoped App token, no PAT),
run engineer_bot.run. .bot/config.yaml (flow: bug-fix, poetry pytest allowlist)
+ engineer/engineer-followup prompts, adapted for src/databricks/sql/ + mocked
tests/unit. Verified live — the author agent ran end-to-end to a correct
structured outcome. Design + first-consumer findings in docs/superpowers/specs.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

…kflows

The four bot workflows duplicated ~4 setup steps (mint bot token, mint
engine-scoped token, Setup Node, install engine). Factor them into a local
./.github/actions/bot-prelude composite (inputs: app-id/private-key + engine-ref;
output: token). Each workflow keeps only what genuinely differs: its checkout,
Setup Python (reviewer — interpreter only) vs setup-poetry (engineer — connector
deps for pytest self-verify), and its run/publish tail. bot-prelude calls the
existing local install-bot-engine. Behavior unchanged; token refs now come from
steps.prelude.outputs.token. Headers refreshed to match. Engine feedback on the
duplicated install-bot-engine noted in issue #104.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

…re correct

Two review findings (raised repeatedly) assumed the workflow was wrong; both are
false positives verified against the engine source. Add clarifying comments so
they don't recur:

- `case ... no_change)`: the engine maps the agent's `no_change_needed` to the
  emitted $GITHUB_OUTPUT value `no_change` (run_author.py), so the arm is correct.
- `coverage_pr_url`: engineer_bot.publish emits this key for ALL flows (legacy
  name), not just coverage — correct for bug-fix too.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

…n, reviewer concurrency

Three low-severity review findings (all verified real against the branch):

- engineer-bot.yml: add `github.event.sender.type != 'Bot'` to the author `if:`,
  matching the followup gate — defense-in-depth since a GitHub App with
  `issues: write` could apply the trigger label without a human.
- bot-prelude: derive owner/name from the `engine-repo` input for the
  engine-scoped token mint instead of hardcoding databricks/databricks-bot-engine,
  so the overridable input is honored (a fork/rename gets a correctly-scoped token
  rather than a confusing auth failure).
- reviewer-bot.yml: add a `concurrency:` group (cancel-in-progress) so rapid
  pushes to a PR collapse to one review run, matching the other three workflows.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

Adopt the engine's Issue-Type flow selection (engine PR #107, merged) instead of
running a fixed config-default flow:

- engineer-bot.yml ctx step: fetch the issue via `gh api repos/{o}/{r}/issues/{n}`
  (REST carries `.type.name`; `gh issue view --json type` does not), reject PR
  numbers via `.pull_request`, and derive `--flow` from a pinned Type→flow case
  (`Bug` ⇒ bug-fix, `Feature` ⇒ enhancement; any other/none ⇒ omit).
- author step: pass `--flow` only when derived (empty would fail the CLI's
  `choices`); omitting it keeps the `.bot/config.yaml` `flow: bug-fix` default.
- Bump the pinned engine SHA b6205fb → d24ca21 (includes #107) across all four
  bot workflows so the consumer runs the engine version that ships this behavior.

Note: Issue Types are org-level; databricks-sql-python is org-owned, so this
works. A no-type / other-type issue falls through to the bug-fix config default.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

…step

Review follow-up (F2): the workflows pin engine d24ca21 but the design doc still
said b6205fb, so a reviewer couldn't confirm which engine is installed.

- Update the design doc's operative "Pinned to" line to d24ca21 (post-#107,
  issue-Type flow selection), noting the earlier b6205fb draft.
- Add a comment at each of the four engine-ref pin sites noting the SHA is
  duplicated across all four bot workflows and must be bumped in lockstep.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

Review follow-up (F1): reviewer flagged that engineer-bot-followup passes
PR_BASE_SHA without the base-fetch step the reviewer follow-up has. Verified
against the engine: the engineer follow-up (followup_runner.py / run.py) never
reads PR_BASE_SHA — unlike the reviewer, it does no `git rev-list base..head`
anchor verification. So it was dead env, not a missing-base risk. Remove it
rather than adding an unused base-fetch step.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>

Review follow-up: the JFrog OIDC exchange only validated ACCESS_TOKEN, so a
failed ID_TOKEN mint (missing id-token:write, metadata hiccup → empty or the
string "null") was still POSTed as subject_token and surfaced one step later as
the misleading "Could not extract JFrog access token". Add an empty/null guard
right after the OIDC curl so the diagnostic points at the real cause. Fails
closed either way; this just improves the error message.

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>