chore: scaffold standalone stackable-odbc-core repository

.gitattributes

@@ -0,0 +1,16 @@
+# Check every text file out with LF endings on every platform.
+#
+# Windows git defaults to `core.autocrlf=true`, and GitHub's `windows-latest`
+# runners ship that default — so without this line `actions/checkout` writes CRLF
+# into the working tree even though the repository stores LF. That is not a
+# cosmetic difference: `the_set_of_group_lock_acquisition_sites_is_closed`
+# (`src/handles/registry.rs`) reads the source tree and splits each file on a
+# pattern containing a newline, and CRLF made that pattern miss, so the audit
+# counted the test modules and failed on Windows alone. The test normalises line
+# endings itself now; this stops the next reader of a file from having to.
+#
+# `text=auto` still lets git detect and leave binary content alone, so the
+# wildcard is safe for anything added later. Every file currently tracked is
+# text — no images, and no `.bat`/`.cmd`/`.ps1`, which are the ones that would
+# want CRLF kept.
+* text=auto eol=lf

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,106 @@
+name: Bug report
+description: Something in stackable-odbc-core behaves differently from the ODBC spec, or from its own documentation.
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        `stackable-odbc-core` is a **library**, not a loadable ODBC driver — it
+        is the database-independent half. A concrete driver crate implements
+        the `Backend` and `StatementBackend` traits and exports the C ABI.
+
+        If the wrong behaviour is in how a particular data source is queried,
+        it probably belongs in that driver's repository. If you are not sure
+        which side it falls on, file it here and say so.
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened
+      description: What the driver did, and what you expected instead.
+    validations:
+      required: true
+
+  - type: textarea
+    id: call-sequence
+    attributes:
+      label: ODBC call sequence
+      description: >
+        The calls that lead to it, in order, with the arguments that matter.
+        Most bugs in this crate are about a specific function under a specific
+        prior state, so the sequence is usually more useful than a stack trace.
+      placeholder: |
+        SQLAllocHandle(SQL_HANDLE_STMT, ...)
+        SQLExecDirectW(stmt, L"SELECT ...", SQL_NTS)   -> SQL_SUCCESS
+        SQLFetch(stmt)                                 -> SQL_ERROR, expected SQL_SUCCESS
+    validations:
+      required: true
+
+  - type: input
+    id: sqlstate
+    attributes:
+      label: SQLSTATE and message
+      description: >
+        From `SQLGetDiagRecW`, if the call returned `SQL_ERROR` or
+        `SQL_SUCCESS_WITH_INFO`. A wrong SQLSTATE is itself a bug worth
+        reporting, even when the call otherwise does the right thing.
+      placeholder: "07009 — Column number 3 out of range (have 5 columns)"
+
+  - type: input
+    id: spec-reference
+    attributes:
+      label: Spec reference
+      description: >
+        Link to the function's page on Microsoft Learn, and quote the row or
+        sentence you think is not being honoured. Optional, but it is what
+        makes a report immediately actionable — and pay attention to whether
+        the row carries a `(DM)` marker, which means the Driver Manager owes
+        it rather than the driver.
+      placeholder: "https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlfetch-function"
+
+  - type: input
+    id: version
+    attributes:
+      label: Version or commit
+      description: The `stackable-odbc-core` version, or the commit if building from source.
+    validations:
+      required: true
+
+  - type: input
+    id: driver
+    attributes:
+      label: Driver crate
+      description: Which driver is built on core here, and at what version.
+
+  - type: dropdown
+    id: driver-manager
+    attributes:
+      label: Driver Manager
+      description: >
+        The Windows Driver Manager is considerably stricter than unixODBC, and
+        several behaviours differ between them.
+      options:
+        - unixODBC
+        - Windows Driver Manager
+        - None (calling the exported entry points directly)
+        - Other / not sure
+    validations:
+      required: true
+
+  - type: input
+    id: platform
+    attributes:
+      label: Platform
+      description: OS and architecture, and the application if one is involved.
+      placeholder: "Ubuntu 24.04 x86_64, pyodbc 5.1 / isql"
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Driver log
+      description: >
+        Set `ODBC_LOG_LEVEL=trace` and `ODBC_LOG_FILE=/path/to/log`, reproduce,
+        and attach the relevant part. **Check it before posting** — a
+        connection string may appear in it. Passwords are redacted, but other
+        connection parameters are not.
+      render: text

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Question or discussion
+    url: https://github.com/orgs/stackabletech/discussions
+    about: For usage questions and anything that is not yet a specific defect.
+  - name: Community chat
+    url: https://discord.gg/7kZ3BNnCAF
+    about: Stackable's Discord, for a faster back-and-forth.
+  - name: Report a security vulnerability
+    url: https://github.com/stackabletech/stackable-odbc-core/security/advisories/new
+    about: Please report vulnerabilities privately rather than in an issue.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,62 @@
+name: Feature request
+description: An ODBC function, attribute or info type that core does not implement yet, or a change to the Backend trait.
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Most additions here are driven by the ODBC spec rather than invented:
+        a function that is stubbed, an attribute that is accepted and ignored,
+        an info type answered with a default. Saying which one it is, and
+        quoting the spec, usually settles the design.
+
+  - type: textarea
+    id: what
+    attributes:
+      label: What is missing
+      description: What you need core to do that it does not do today.
+    validations:
+      required: true
+
+  - type: textarea
+    id: use-case
+    attributes:
+      label: What it unblocks
+      description: >
+        The application or driver that needs it, and what it does instead
+        today. A concrete blocked case is the strongest argument.
+    validations:
+      required: true
+
+  - type: input
+    id: spec-reference
+    attributes:
+      label: Spec reference
+      description: >
+        The relevant page on Microsoft Learn, if there is one. For an info
+        type or attribute, quote its description — the stated *purpose* often
+        decides the design, and has more than once here.
+      placeholder: "https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetinfo-function"
+
+  - type: dropdown
+    id: layer
+    attributes:
+      label: Which side should own it
+      description: >
+        Core holds no database-specific code. A capability only the data source
+        can answer belongs on a `Backend` method, so the compiler asks the
+        driver author rather than core guessing — a value core invents is wrong
+        for some real driver, and wrong silently.
+      options:
+        - Core owns it entirely (same answer for every driver)
+        - A new or changed Backend trait method (each driver answers)
+        - Not sure
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: breaking
+    attributes:
+      label: Compatibility
+      options:
+        - label: This would change an existing public API or trait method (a breaking change for driver crates)

.github/dependabot.yml

@@ -0,0 +1,30 @@
+---
+# Every `uses:` in this repository is pinned to a full commit SHA, which is only
+# safe if something keeps those pins current. Without this file they freeze
+# permanently, and Cargo.lock drifts toward advisories cargo-deny will start
+# failing on with no PR available to fix them.
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+    groups:
+      actions:
+        patterns: ["*"]
+
+  - package-ecosystem: cargo
+    directory: /
+    schedule:
+      interval: weekly
+    groups:
+      cargo:
+        patterns: ["*"]
+        update-types: ["minor", "patch"]
+
+  # fuzz/ is a separate Cargo workspace (libFuzzer needs nightly), so the root
+  # ecosystem entry above does not cover it.
+  - package-ecosystem: cargo
+    directory: /fuzz
+    schedule:
+      interval: monthly

.github/pull_request_template.md

@@ -0,0 +1,47 @@
+<!-- markdownlint-disable-file MD041 -->
+<!--
+MD041 wants a top-level heading first. This file is not a document: its
+content is pasted into a pull request body, where GitHub supplies the title,
+so an H1 here would only duplicate it. The rule stays on everywhere else.
+
+Delete any section that does not apply. The checklist is a reminder, not a
+gate — CI enforces what it can, and the rest is what a reviewer would
+otherwise have to ask for.
+-->
+
+## What this changes
+
+<!-- What behaviour differs after this, and why. -->
+
+## Spec basis
+
+<!--
+For anything touching an FFI entry point: link the function's page on Microsoft
+Learn and quote the row or sentence this implements.
+
+Two things worth stating explicitly, because both have caused rework here:
+- whether a SQLSTATE's row carries a **(DM)** marker, which means the Driver
+  Manager owes it and the driver must not return it; and
+- what the attribute or info type's description says its *purpose* is, which
+  has decided the design more than once.
+-->
+
+## Checklist
+
+- [ ] `pre-commit run --all-files` passes — this is the single source of truth for what must pass.
+- [ ] `CHANGELOG.md` has an entry under `## [Unreleased]`, if this is user-facing. Any change to a public type, trait method or exported FFI contract counts, since driver crates consume them.
+- [ ] Doc comments on any FFI function touched list every SQLSTATE from its spec diagnostics table, saying for each whether the driver returns it or why not.
+- [ ] New tests were checked by breaking the line they cover and watching them fail. A test that cannot fail reports coverage that does not exist.
+
+### If it applies
+
+- [ ] Miri, for anything touching raw pointers: `MIRIFLAGS="-Zmiri-disable-isolation" cargo +nightly miri test -p stackable-odbc-core --lib -- --skip proptest`
+- [ ] loom, for anything touching handle locking: `RUSTFLAGS="--cfg loom" cargo test --lib loom_tests`
+- [ ] Breaking changes for driver crates are called out above, so the drivers can be updated alongside.
+
+## Notes for the reviewer
+
+<!--
+Anything you decided rather than derived — a spec sentence you read two ways,
+a case left unhandled on purpose, a TODO(spec) you added.
+-->