@@ -166,4 +166,8 @@ until a human merges it. The engineer author phase reads this log (see
 - **Context:** PR #995 fixed `ArrowInvalid: Can't unify schema with duplicate field names` in `_concat_arrow_tables` (src/databricks/sql/utils.py), a regression from switching to `pyarrow.concat_tables(promote_options="default")`. Duplicate column names are valid SQL (`SELECT 1 AS a, 2 AS a`, `SELECT * FROM a JOIN b`), but Arrow's schema promotion always invokes schema unification, which rejects duplicate field names even when no promotion is actually required.
   **Rule:** When concatenating Arrow tables/chunks, only pass `promote_options`/`promote` when chunk schemas actually differ (guard with `all(t.schema.equals(chunks[0].schema) ...)`); unconditional promotion triggers schema unification that fails on duplicate column names even though plain `concat_tables` would succeed.
 
+### 2026-10-28: learnings since 2026-10-27T17:26:56Z
+- **Context:** PR #1001 (kernel async readers) switched same-connection re-fetch and concurrent polling to call `ExecutedAsyncStatement.reader()`, a post-1.3.0 kernel API, while `pyproject.toml` still declared the floor as `databricks-sql-kernel ^1.3.0`. The reviewer flagged that a resolver picking 1.3.0 raises `NotSupportedError` on a path that previously worked via `attach_async_statement` — a pure regression for standard sessions.
+  **Rule:** When code starts calling a newly-added API from a dependency, bump the version floor in packaging metadata (pyproject/setup) to the first release that actually ships that API; a capability requirement stated only in comments/README/PR text — not in the dependency graph — lets the resolver pick a non-capable version and regress previously-working code paths.
+
 --- *Add new entries above this line (oldest→newest); newest sections sort to the bottom.* ---