@@ -5,18 +5,42 @@ 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. 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 public contracts outside the task; defer unrelated
+    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.
+    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.
+
 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/<file>.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 +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 — keep
-    public API changes out of scope unless the reviewer explicitly asks.
+    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/`.
 
@@ -13,9 +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. 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 +
@@ -129,6 +135,12 @@ 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.
 - **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/`.
 
@@ -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"