vmariiechko · vmariiechko · Jul 26, 2026 · Jul 26, 2026
@@ -22,7 +22,7 @@ Run the command from the root of your bundle project. The CLI will prompt for an
 | `monitoring-sql-warehouse` | Small, dedicated serverless SQL warehouse (2X-Small, `auto_stop_mins: 1`) for scheduled Databricks Alerts and monitoring queries. Keeps cost proportional to actual query time instead of idle warm-up. | Stable | [README](assets/monitoring-sql-warehouse/README.md) |
 | `sdp-quarantine-pattern` | Lakeflow SDP pipeline demonstrating the inverse-expectations quarantine pattern on `samples.nyctaxi.trips`: critical (drop) expectations route bad rows into a separate quarantine table (silver schema), valid rows flow to silver, warn expectations log to a queryable event log. NULL-safe predicates keep the silver/quarantine split a clean partition. Ships a companion agent skill (`SKILL.md`) that adapts the pattern to your own dataset and self-verifies it. | Stable | [README](assets/sdp-quarantine-pattern/README.md) |
 | `pyspark-test-runner` | Single-file Python wrapper around `pytest` for local PySpark suites that prints a bounded, agent-friendly digest (counts, runnable failing node ids, failures deduplicated by signature) and keeps full output in a log file, so a suite that floods with repetitive failures does not burn a coding agent's context window. Ships a `SKILL.md` for agent integration. | Stable | [README](assets/pyspark-test-runner/README.md) |
-| `sdp-expectation-notifications` | Per-expectation data-quality notification for Lakeflow SDP as a validated pair: a native event hook notifies the moment a WARN expectation result is logged (fast, best-effort by platform design, throttled to at most one notification per expectation per window via a two-layer time-aware de-dup with optional UC Volume marker state), and one DABs-managed Alert v2 sweeps the published pipeline event log over a past-time window on a schedule (guaranteed, one email per state change). Webhook payloads for Slack, Teams, or generic receivers, with secret-scope URL resolution. Demo pipeline on `samples.nyctaxi.trips` fires both paths on the first run. Ships a companion agent skill (`SKILL.md`) that wires the pattern into your own SDP pipelines. | Stable | [README](assets/sdp-expectation-notifications/README.md) |
+| `sdp-expectation-notifications` | Per-expectation data-quality notification for Lakeflow SDP as a validated pair: a native event hook notifies the moment an expectation result with failed records is logged, covering `warn` and `drop` alike (fast, best-effort by platform design, throttled to at most one notification per expectation per window via a two-layer time-aware de-dup with optional UC Volume marker state), and one DABs-managed Databricks SQL alert sweeps the published pipeline event log over a past-time window on a schedule (guaranteed, one email per state change). Webhook payloads for Slack, Teams, or generic receivers, with secret-scope URL resolution. Demo pipeline on `samples.nyctaxi.trips` fires both paths on the first run. Ships a companion agent skill (`SKILL.md`) that wires the pattern into your own SDP pipelines. | Stable | [README](assets/sdp-expectation-notifications/README.md) |
 
 ## What an asset is not
 

@@ -7,6 +7,18 @@ and this project adheres to [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+## [1.12.1] - 2026-07-26
+
+### Changed
+- **Asset `sdp-expectation-notifications` (docs only)**: seven corrections grounded in two live verification sessions (2026-07-26 drop/destination testing and the 2026-07-17/18 hygiene build), none changing behavior.
+  - **Drop coverage documented.** The hook filters purely on `failed_records > 0` and never inspects the expectation's action type, so `warn` and `drop` rules notify identically; the README previously framed the pattern as WARN-only. Live 2026-07-26: a `drop` expectation on the same source and tripwire produced the same passed/failed shape as the shipped WARN row (18929/3003 on 21,932 rows), the hook fired with a matching driver-log line, the update reported `COMPLETED` while discarding 13.7% of rows, `dropped_records` (DROP-only) read 3003 vs 0 on WARN, and the backstop's sweep summed both expectations additively (6,006).
+  - **Naming corrected.** "Alert v2" and "Alerts v2" replaced with "Databricks SQL alert(s)" throughout the README, in-bundle doc, skill files, and install prompt text, matching current Databricks docs (legacy alerts is the prior version); `alerts-v2` is kept only where it names an actual CLI command.
+  - **Notification destinations clarified.** Destinations serve only Databricks SQL and jobs, not the event hook, and a destination is a wrapper around a webhook, not a substitute for one (Slack needs a webhook URL, OAuth token, and channel id plus Slack app-install rights; Teams needs a webhook URL, App ID, Auth Secret, Channel URL, and Tenant ID plus Microsoft Copilot Studio and Entra ID permissions). Measured live: a destination alongside `user_email` on the same address sends two independent, non-deduplicated notifications.
+  - **No-webhook guidance added.** Readers and the companion skill are now steered to deploy the backstop alone when there is no Slack, Teams, or webhook target, since print-only hook output has no advantage over the event log the backstop already sweeps.
+  - **Backstop cron tied to pipeline mode.** The shipped daily cron fits a triggered pipeline; guidance now flags that a continuous pipeline (10-seconds-to-a-few-minutes freshness) needs a tighter cron and window, at the cost of more warehouse wake-ups, pointing at the `monitoring-sql-warehouse` asset.
+  - **Grace-period claim softened.** "Terminates compute within roughly 20 seconds" overclaimed precision two runs never measured; replaced with the honest bound (compute alive at ~8s in one run, dead before ~23s in another, neither designed to measure the timer) and the actionable rule: keep hook work in single-digit seconds.
+  - **Skill gains a CLI gotcha.** `databricks notification-destinations create` prints a spurious `unknown field` warning and echoes back a config that looks empty even though the destination was created correctly; documented in `adapt-the-pattern.md` since the skill is what would run this command.
+
 ## [1.12.0] - 2026-07-18
 
 ### Changed

@@ -51,7 +51,7 @@ Modular sub-templates installable via `databricks bundle init <repo-url> --templ
 - `monitoring-sql-warehouse`: Dedicated serverless SQL warehouse tuned for bursty workloads (scheduled Alerts, monitoring queries) with `auto_stop_mins: 1`
 - `sdp-quarantine-pattern`: Lakeflow SDP pipeline demonstrating the inverse-expectations quarantine pattern (drop expectations route bad rows to a separate quarantine table) on `samples.nyctaxi.trips`, with medallion schema separation, a queryable event log, and NULL-safe predicates. Ships a companion agent skill that adapts the pattern to the user's own dataset and self-verifies it
 - `pyspark-test-runner`: Single-file Python wrapper around `pytest` for local PySpark suites that prints a bounded, agent-friendly digest (counts, runnable failing node ids, failures deduplicated by signature) and keeps full output in a log file, so a suite flooding with repetitive failures does not burn a coding agent's context window. Ships a `SKILL.md` for agent integration
-- `sdp-expectation-notifications`: Per-expectation data-quality notification for Lakeflow SDP as a pair: an in-pipeline event hook fires the moment a WARN expectation result is logged (since v1.12.0 throttled to at most one notification per expectation per window via a two-layer time-aware de-dup with optional UC Volume marker state, with Slack/Teams/generic webhook formats and secret-scope URL resolution), backed by one DABs-managed Alert v2 sweeping the published event log on a schedule (hook delivery is best-effort by platform design; the alert is the guarantee, one email per state change). Ships a companion agent skill that wires the pattern into the user's own pipelines
+- `sdp-expectation-notifications`: Per-expectation data-quality notification for Lakeflow SDP as a pair: an in-pipeline event hook fires the moment an expectation result with failed records is logged, covering `warn` and `drop` alike (since v1.12.0 throttled to at most one notification per expectation per window via a two-layer time-aware de-dup with optional UC Volume marker state, with Slack/Teams/generic webhook formats and secret-scope URL resolution), backed by one DABs-managed Databricks SQL alert sweeping the published event log on a schedule (hook delivery is best-effort by platform design; the alert is the guarantee, one email per state change). Ships a companion agent skill that wires the pattern into the user's own pipelines
 
 **Possible future assets** (ideas for contributors, not commitments):
 - `etl-pipeline`: Medallion-layered Declarative Pipeline with Bronze/Silver layers and DLT expectations
@@ -85,7 +85,40 @@ These are larger features that require more design work and community input befo
 
 ### Pre-commit Hooks
 
-<fill-in from `https://www.waitingforcode.com/databricks/pre-commit-hook-declarative-automation-bundles-example/read`>
+**Status**: Proposed
+**Target**: v2.0
+
+Optional git pre-commit hook that runs `databricks bundle validate` locally before a commit, catching DAB syntax and configuration errors before they reach CI/CD. Off by default: it requires a local Databricks CLI profile with workspace auth already configured, and like any pre-commit hook it can be bypassed with `--no-verify`, so it complements the CI/CD pipeline's validation step rather than replacing it.
+
+**Scope:**
+- New `include_pre_commit_hook` prompt (`yes` / `no`, default `no`)
+- Generates `.pre-commit-config.yaml` wiring a hook that runs `databricks bundle validate -t <target>` and fails the commit on validation errors
+- Documentation note on installing the `pre-commit` framework and running `pre-commit install`
+
+**Open questions:**
+- Which target does the local validate run against by default: `user`, or whichever the developer has authenticated to?
+- Does the hook need a dependency on `pre-commit` (plus a task runner like Poe) in the generated project, or can it ship as a lighter shell-script hook with no extra Python framework?
+- How should the hook behave when a developer has no local CLI auth configured yet: skip gracefully, or hard fail?
+
+Inspired by: [Pre-commit hook for Declarative Automation Bundles](https://www.waitingforcode.com/databricks/pre-commit-hook-declarative-automation-bundles-example/read)
+
+### Shared Bundles Support
+
+**Status**: Proposed
+**Target**: v2.0
+
+Scaffold a generated project to consume an existing external "shared" bundle path, a separate repo or directory holding common libraries, compute configs, or variables reused across multiple bundles, using Databricks' native `sync.paths` / `include` mechanism rather than anything template-specific. Useful for organizations running several bundles that want centralized cluster configs, shared code, or shared variable definitions instead of duplicating them per bundle.
+
+**Scope:**
+- New `shared_bundle_path` prompt (optional; blank by default, no change to current single-bundle behavior)
+- When set, wires the path into `sync.paths` and `include` in `databricks.yml.tmpl` (for example `../shared/*.yml`, `../shared` as a sync path)
+- Documentation on the prerequisites (DBR 14+ or serverless for certain shared Python path operations; permissions must be configured at both bundle and target level for all consumers) and on running `databricks bundle validate` to confirm inheritance before deploying
+
+**Open questions:**
+- Should the template scaffold the shared bundle itself as a second generated project, or only wire an existing one in?
+- How does this interact with the existing service-principal and permissions model per environment target?
+
+Reference: [Share code and configuration between bundles](https://docs.databricks.com/aws/en/dev-tools/bundles/sharing)
 
 ### Advanced Permissions Profiles