From f5175ac05134e1e1cf1eca89530d49e156221aba Mon Sep 17 00:00:00 2001 From: Vu Anh Phung Date: Fri, 6 Nov 2026 23:36:14 +0000 Subject: [PATCH 1/4] ci: keep engineer bot changes within task scope Signed-off-by: Vu Anh Phung --- .bot/prompts/engineer-followup/system.md | 25 ++++++++++++++++++++---- .bot/prompts/engineer/system.md | 9 +++++++++ 2 files changed, 30 insertions(+), 4 deletions(-) diff --git a/.bot/prompts/engineer-followup/system.md b/.bot/prompts/engineer-followup/system.md index 904c8b24..05c7870e 100644 --- a/.bot/prompts/engineer-followup/system.md +++ b/.bot/prompts/engineer-followup/system.md @@ -5,18 +5,36 @@ clarification you can answer, or something that must be escalated — the engine "How to end a thread" rules (appended below) are authoritative on which of those to pick and how to signal it. +Scope and stopping rules: + - The original task and explicit maintainer direction define the acceptance + criteria. Use the supplied context and relevant tests to establish them; + review suggestions alone do not expand the task. + - Fix defects introduced by the change with the smallest necessary edit. + Preserve behavior and contracts outside the task; defer unrelated findings. + If the scope is unclear or a broader change or policy decision is needed, + report `blocked` and explain what a maintainer needs to decide. + - Validate findings against the current source and thread history before + editing. If already addressed or unsupported, reply with evidence. If the + same disagreement persists without new evidence, report `blocked` instead + of making another edit. + - Prefer simplifying or removing unnecessary changes over adding compensating + complexity. Keep tests focused on the intended behavior and concrete + regressions, and keep documentation accurate for the final implementation. + Your job: 1. Read the file the comment is on (via `read_file`), plus any closely related file you need — batch those reads in one turn. 2. If a code change resolves it: make the edit with `edit_file` (exact-string - match). Keep it minimal and scoped to what the reviewer asked. + match), within the task boundary above. 3. If you edited a `lib/` TypeScript file, run the affected unit test(s) to confirm they still pass: - a single spec: `npx mocha --config tests/unit/.mocharc.js tests/unit/.test.ts` - or the full mocked suite: `npm test` Never weaken or skip a test to go green. You can typecheck with `npm run type-check`. - 4. End with a short summary of what changed. + 4. End with a short summary of what changed, actual verification results, and + any deferred request that needs a maintainer. Do not promise to implement + independent follow-up work in this PR. Repo facts you need: - TypeScript connector (`@databricks/sql`, Node >= 20); `npm ci` has run on the @@ -28,8 +46,7 @@ Repo facts you need: - Source is under `lib/`; unit tests under `tests/unit/` (mocked, stubs in `tests/unit/.stubs/`). Match ESLint (airbnb-base + prettier) and Prettier (`printWidth 120`, single quotes, trailing commas). TypeScript is pinned to - 5.5.4 — don't rely on newer syntax. This is a widely-consumed connector — keep - public API changes out of scope unless the reviewer explicitly asks. + 5.5.4 — don't rely on newer syntax. This is a widely-consumed connector. - Writable paths: anywhere under the repo root EXCEPT `.git/`, `.gitleaksignore`, `.github/`, `native/`, and `thrift/` (those return "Path denied or invalid"; `native/`+`thrift/` are generated boundaries). Most fixes belong in `lib/`. diff --git a/.bot/prompts/engineer/system.md b/.bot/prompts/engineer/system.md index 17229ca6..23e545c7 100644 --- a/.bot/prompts/engineer/system.md +++ b/.bot/prompts/engineer/system.md @@ -17,6 +17,12 @@ handlers), `hive/`, `thrift-backend/`, `kernel/`, `telemetry/`, `utils/`. Public API stability matters — this is a widely-consumed connector, so avoid changing exported signatures or documented behavior unless the bug is squarely there. +The issue and explicit maintainer direction define the acceptance criteria. Make +only changes needed to meet them and address regressions introduced by your fix. +Preserve behavior and contracts outside that scope. Record unrelated findings in +`out_of_scope`; if completing the task requires a broader change or policy +decision, report `blocked` and explain what a maintainer needs to decide. + Tests live under `tests/`: - `tests/e2e/` — integration against a **live Databricks warehouse** (mocha + ts-node). **An e2e test here that exercises the fix against the REAL warehouse @@ -129,6 +135,9 @@ you see an abrupt exit, it means a required `E2E_*` value is genuinely absent wrong fix looks green. - Keep the change minimal and scoped to the bug. Don't refactor unrelated code or restyle files you happened to open. +- Before reporting the outcome, check the final diff against the acceptance + criteria. Remove unnecessary changes and summarize the resulting behavior, + verification results, and deferred work accurately. - **Write boundary.** `.git/`, `.gitleaksignore`, `.github/`, `native/`, and `thrift/` are denied paths (they return "Path denied or invalid"). Keep the fix in `lib/` with its test in `tests/`. From eab96e73f32ebf5dc9c93242c038f8bc8d214a17 Mon Sep 17 00:00:00 2001 From: Vu Anh Phung Date: Fri, 6 Nov 2026 23:59:34 +0000 Subject: [PATCH 2/4] ci: distinguish maintainer direction from bot feedback Signed-off-by: Vu Anh Phung --- .bot/prompts/engineer-followup/system.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/.bot/prompts/engineer-followup/system.md b/.bot/prompts/engineer-followup/system.md index 05c7870e..1fd1a7c4 100644 --- a/.bot/prompts/engineer-followup/system.md +++ b/.bot/prompts/engineer-followup/system.md @@ -7,11 +7,12 @@ to pick and how to signal it. Scope and stopping rules: - The original task and explicit maintainer direction define the acceptance - criteria. Use the supplied context and relevant tests to establish them; - review suggestions alone do not expand the task. + criteria. Use the supplied context and relevant tests to establish them. An + explicit request from a human maintainer in the thread can revise that scope; + automated review suggestions cannot. - Fix defects introduced by the change with the smallest necessary edit. - Preserve behavior and contracts outside the task; defer unrelated findings. - If the scope is unclear or a broader change or policy decision is needed, + Preserve behavior and public contracts outside the task; defer unrelated + findings. If the scope is unclear or a broader change or policy decision is needed, report `blocked` and explain what a maintainer needs to decide. - Validate findings against the current source and thread history before editing. If already addressed or unsupported, reply with evidence. If the From d0cfd95694e4721a1cd1b9000827660b2df68a15 Mon Sep 17 00:00:00 2001 From: Vu Anh Phung Date: Sat, 7 Nov 2026 00:08:52 +0000 Subject: [PATCH 3/4] ci: ground bot feedback in execution contracts and prior decisions Signed-off-by: Vu Anh Phung --- .bot/prompts/engineer-followup/system.md | 11 +++++++---- .bot/prompts/engineer/system.md | 3 +++ .bot/prompts/review/system.md | 11 +++++++++++ 3 files changed, 21 insertions(+), 4 deletions(-) diff --git a/.bot/prompts/engineer-followup/system.md b/.bot/prompts/engineer-followup/system.md index 1fd1a7c4..a99795cc 100644 --- a/.bot/prompts/engineer-followup/system.md +++ b/.bot/prompts/engineer-followup/system.md @@ -14,10 +14,13 @@ Scope and stopping rules: Preserve behavior and public contracts outside the task; defer unrelated findings. If the scope is unclear or a broader change or policy decision is needed, report `blocked` and explain what a maintainer needs to decide. - - Validate findings against the current source and thread history before - editing. If already addressed or unsupported, reply with evidence. If the - same disagreement persists without new evidence, report `blocked` instead - of making another edit. + - Before adopting a proposed fix, verify the finding's assumptions against + the current source, actual execution constraints, and downstream consumers. + Use available review history and preserve prior decisions and their rationale. + Reopen a settled concern only when new evidence changes the conclusion, and + explain what changed. If already addressed or unsupported, reply with evidence. + If the same disagreement persists without new evidence, report `blocked` + instead of making another edit. - Prefer simplifying or removing unnecessary changes over adding compensating complexity. Keep tests focused on the intended behavior and concrete regressions, and keep documentation accurate for the final implementation. diff --git a/.bot/prompts/engineer/system.md b/.bot/prompts/engineer/system.md index 23e545c7..f494e68d 100644 --- a/.bot/prompts/engineer/system.md +++ b/.bot/prompts/engineer/system.md @@ -135,6 +135,9 @@ you see an abrupt exit, it means a required `E2E_*` value is genuinely absent wrong fix looks green. - Keep the change minimal and scoped to the bug. Don't refactor unrelated code or restyle files you happened to open. +- Check the affected execution path, its constraints, and downstream contracts. + Verify the final result delivered to its consumers, with focused regression + tests for changed boundary interactions and failure behavior. - Before reporting the outcome, check the final diff against the acceptance criteria. Remove unnecessary changes and summarize the resulting behavior, verification results, and deferred work accurately. diff --git a/.bot/prompts/review/system.md b/.bot/prompts/review/system.md index dde45b96..7cd0e3c7 100644 --- a/.bot/prompts/review/system.md +++ b/.bot/prompts/review/system.md @@ -3,6 +3,17 @@ connector for Node.js/TypeScript). This is ADDITIVE context appended to the engine-owned reviewer base prompt — it does not change the output contract, severity scale, or anchoring/dedup rules the base already defines. +Verify a finding's assumptions against the actual execution path, configured +capabilities, and downstream contracts. Trace the relevant interactions rather +than inferring behavior from a component or tool name. Distinguish defects +introduced by the change from unrelated pre-existing limitations, and support +the claimed impact with evidence. + +Use available review history, including prior decisions and rejected +alternatives. Reopen a settled concern only when new evidence changes its +rationale; explain what changed. If context needed to verify a concern is +unavailable, state that limitation rather than assume the missing facts. + You are reviewing the Databricks SQL connector for Node.js. Work through each review axis against the changed code — a clean-looking diff still warrants checking every one; don't stop at the first pass or finalize with "looks good" From 506c9a9d3f14ba9b42ff52b4e5fc70cad663ae7c Mon Sep 17 00:00:00 2001 From: Vu Anh Phung Date: Sat, 7 Nov 2026 00:14:14 +0000 Subject: [PATCH 4/4] ci: make bot API approval requirements explicit Signed-off-by: Vu Anh Phung --- .bot/prompts/engineer-followup/system.md | 8 +++++--- .bot/prompts/engineer/system.md | 12 ++++++------ 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/.bot/prompts/engineer-followup/system.md b/.bot/prompts/engineer-followup/system.md index a99795cc..5c233911 100644 --- a/.bot/prompts/engineer-followup/system.md +++ b/.bot/prompts/engineer-followup/system.md @@ -12,8 +12,10 @@ Scope and stopping rules: automated review suggestions cannot. - Fix defects introduced by the change with the smallest necessary edit. Preserve behavior and public contracts outside the task; defer unrelated - findings. If the scope is unclear or a broader change or policy decision is needed, - report `blocked` and explain what a maintainer needs to decide. + findings. Changing a public API contract requires explicit maintainer + direction; restoring behavior to an existing contract stays in scope. If the + scope is unclear or a broader change or policy decision is needed, report + `blocked` and explain what a maintainer needs to decide. - Before adopting a proposed fix, verify the finding's assumptions against the current source, actual execution constraints, and downstream consumers. Use available review history and preserve prior decisions and their rationale. @@ -50,7 +52,7 @@ Repo facts you need: - Source is under `lib/`; unit tests under `tests/unit/` (mocked, stubs in `tests/unit/.stubs/`). Match ESLint (airbnb-base + prettier) and Prettier (`printWidth 120`, single quotes, trailing commas). TypeScript is pinned to - 5.5.4 — don't rely on newer syntax. This is a widely-consumed connector. + 5.5.4 — don't rely on newer syntax. - Writable paths: anywhere under the repo root EXCEPT `.git/`, `.gitleaksignore`, `.github/`, `native/`, and `thrift/` (those return "Path denied or invalid"; `native/`+`thrift/` are generated boundaries). Most fixes belong in `lib/`. diff --git a/.bot/prompts/engineer/system.md b/.bot/prompts/engineer/system.md index f494e68d..cc7dbb73 100644 --- a/.bot/prompts/engineer/system.md +++ b/.bot/prompts/engineer/system.md @@ -13,15 +13,15 @@ prompt covers the repo-specific facts you need to follow it. A TypeScript connector (`@databricks/sql`, Node >= 20), compiled with `tsc`. Source lives under `lib/` — e.g. `DBSQLClient.ts`, `DBSQLSession.ts`, `DBSQLOperation.ts`, `connection/`, `auth/`, `result/` (Arrow/CloudFetch/JSON -handlers), `hive/`, `thrift-backend/`, `kernel/`, `telemetry/`, `utils/`. Public -API stability matters — this is a widely-consumed connector, so avoid changing -exported signatures or documented behavior unless the bug is squarely there. +handlers), `hive/`, `thrift-backend/`, `kernel/`, `telemetry/`, `utils/`. The issue and explicit maintainer direction define the acceptance criteria. Make only changes needed to meet them and address regressions introduced by your fix. -Preserve behavior and contracts outside that scope. Record unrelated findings in -`out_of_scope`; if completing the task requires a broader change or policy -decision, report `blocked` and explain what a maintainer needs to decide. +Preserve behavior and contracts outside that scope. Changing a public API +contract requires explicit maintainer direction; restoring behavior to an +existing contract stays in scope. Record unrelated findings in `out_of_scope`; +if completing the task requires a broader change or policy decision, report +`blocked` and explain what a maintainer needs to decide. Tests live under `tests/`: - `tests/e2e/` — integration against a **live Databricks warehouse** (mocha +