Re-vendor the merge gate and convert the docs to reference links

.markdownlint-cli2.jsonc

@@ -3,7 +3,8 @@
         // Prose paragraphs and data-heavy tables/URLs are intentionally long.
         // Reflowing at 80 cols hurts readability and churns diffs.
         "MD013": false,
-        // MD033 (inline HTML) stays enabled: HTML comments (reference-link dividers) pass it, and elements are flagged so native markdown wins.
+        // MD033 (inline HTML) stays enabled so native markdown wins - HTML comments (reference-link dividers) pass it, and details/summary are allowed for GitHub collapsibles, which have no markdown equivalent. Every other element still flags.
+        "MD033": { "allowed_elements": ["details", "summary"] },
         // Require fenced code blocks over the legacy 4-space-indented style.
         "MD046": { "style": "fenced" },
         // MD060 (table column style) is not enforced - allow both compact

AGENTS.md

@@ -60,7 +60,7 @@ A state-changing GitHub call is the highest-blast-radius thing an agent does her
 
 ## Release Model
 
-The **two-phase model is the default**: PRs build fast, publishing is batched. See [README "Release Distribution Model"](./WORKFLOW.md) for the full rationale. The load-bearing rules follow. The auto-publish paths (bot push, schedule) apply to `release` repos. **Operational** repos differ - dispatch-only release, no auto-publish - see "Operational Repositories".
+The **two-phase model is the default**: PRs build fast, publishing is batched. See [`WORKFLOW.md`](./WORKFLOW.md) for the full rationale. The load-bearing rules follow. The auto-publish paths (bot push, schedule) apply to `release` repos. **Operational** repos differ - dispatch-only release, no auto-publish - see "Operational Repositories".
 
 - **PRs smoke-test only.** [`test-pull-request.yml`](./.github/workflows/test-pull-request.yml) always runs unit tests, then a `dorny/paths-filter` `changes` job gates a **reduced** build of only the changed targets (Docker `linux/amd64` only, executable on a representative runtime subset), never pushing. Build-workflow files are intentionally not in the path filters - a filter can't tell a logic change from an action-version bump - so a workflow-only change isn't smoke-built; the reusable workflows are exercised by the next run that uses them (a later code PR's smoke build, or the scheduled/publish run). Workflow YAML is still linted in CI by the lint job's `actionlint` step; also run `actionlint` locally before pushing to catch issues early.
 - **A human merge never auto-publishes.** [`publish-release.yml`](./.github/workflows/publish-release.yml) is the sole publisher; each run builds the **single trigger branch** (`main` a release, `develop` a prerelease). A first `plan` job decides once whether the run publishes and every other job gates on its output. It publishes on a **`workflow_dispatch`** of `main`/`develop` (the human-initiated release), a **code-affecting bot push to `main`** (the codegen App merges every Dependabot/codegen PR, so `github.actor` is the gate - a human merge/promotion to `main` skips), or a **weekly `schedule`** (Docker only, to refresh the base image). The `push` is main-only and paths-filtered, so a develop bot merge and an Actions-only bump publish nothing. A source-only repo publishes on dispatch only.
@@ -215,7 +215,7 @@ The repo runs a review loop on every PR: local agent iteration plus remote autom
 **Do not merge - and do not enable auto-merge - unless ALL of these hold:**
 
 1. Required status checks are green (`mergeStateStatus: CLEAN`), **and**
-2. A Copilot review is confirmed on the **current head SHA** (not an earlier push), **and**
+2. A Copilot review is confirmed on the **current head SHA** by matching the review's commit SHA to the head, not an earlier push - a push makes required checks go green **before** the re-review lands, so a green merge-state can precede the current-head review and never signals readiness on its own, **and**
 3. **Every** Copilot finding on that head SHA is closed out - all review threads resolved, **and** any issue-level Copilot comments (which have no resolve action) triaged and replied to - so zero outstanding findings remain, **and**
 4. The maintainer has given **explicit** permission to merge.
 

CODESTYLE.md

@@ -361,10 +361,10 @@ This is the style guide for any **Python project(s)** in this repo.
 - **Disabled markdownlint rules** - repo-specific; `.markdownlint-cli2.jsonc` at the repo root is the source of truth, not any example rule named here.
 - **VS Code config home** - editor **settings/extensions** may live in `.vscode/*.json` **or** the `<Repo>.code-workspace`; **tasks / launch / debug** configs can only be external `.vscode/*.json` (they cannot live in the workspace file). A `[vscode-tasks]` reference must point wherever the repo actually keeps `tasks.json`.
 
-**Two profiles.** A repo's Python is one of two shapes, and the rest of this section (uv project, `uv.lock`, `uv run`, `src` layout, pytest coverage) describes the **project** profile. The two differ by whether the Python has **third-party runtime dependencies**, which shows up structurally in `pyproject.toml`, so the audit detects the profile there (`python.profile.detect`):
+**Two profiles.** A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated against the `pyproject.toml` shape. The rest of this section (uv project, `uv.lock`, `uv run`, `src` layout, pytest coverage) describes the **Project** shape (the `build` profile). The two differ by whether the Python has **third-party runtime dependencies**, which shows up structurally in `pyproject.toml`, so the audit reads the shape there (`python.profile.detect`):
 
 - **Project** - the Python has third-party runtime dependencies, or is the repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed `uv.lock` (pinned LF - see [Line Endings][line-endings]); CI runs `uv sync --frozen` + `uv run <tool>`, so the lockfile pins tool versions.
-- **Scripts** - stdlib-only utility scripts embedded in a **non-Python** repo (e.g. a Python tooling subtree of a `csharp` app). Run the tools with **`uvx`** (no project install, no lockfile): the `pyproject.toml` carries **only** tool config (here `[tool.ruff]` plus a `[tool.pyright]` editor block) - no `[project]`, no `[build-system]`, no `uv.lock` (that metadata would misrepresent it as a shippable package). **In this repo** (`easystart/python`, the standalone BLE monitor) **ruff is the only CI gate**, and a `[tool.pyright]` block in **standard** mode keeps Pylance quiet in the editor. There is no mypy gate: the subtree is a single script importing an untyped BLE library, so there is nothing for a second type checker to add over Pylance. CI pins the tool version, **`uvx ruff@0.15.22`**, and the VS Code tasks carry the same pin so the two cannot drift. That pin is a deliberate divergence from the fleet default of running `uvx <tool>@latest` unpinned - the fleet reasons that a manual pin Dependabot does not track goes stale silently, while this repo reasons that an unpinned linter turns an upstream release into a surprise CI failure on an unrelated change. The divergence is raised with the fleet rather than settled locally, so expect this paragraph to move once that is decided. `.py` files follow the repo's line-ending default (LF here - see [Line Endings][line-endings]). There is no pytest suite, so the coverage expectation is N/A.
+- **Scripts** (the `lint-only` profile) - stdlib-only utility scripts embedded in a **non-Python** repo (e.g. a Python tooling subtree of a `csharp` app). Run the tools with **`uvx`** (no project install, no lockfile): the `pyproject.toml` carries **only** tool config (here `[tool.ruff]` plus a `[tool.pyright]` editor block) - no `[project]`, no `[build-system]`, no `uv.lock` (that metadata would misrepresent it as a shippable package). **In this repo** (`easystart/python`, the standalone BLE monitor) **ruff is the only CI gate**, and a `[tool.pyright]` block in **standard** mode keeps Pylance quiet in the editor. There is no mypy gate: the subtree is a single script importing an untyped BLE library, so there is nothing for a second type checker to add over Pylance. CI pins the tool version, **`uvx ruff@0.15.22`**, and the VS Code tasks carry the same pin so the two cannot drift. That pin is a deliberate divergence from the fleet default of running `uvx <tool>@latest` unpinned - the fleet reasons that a manual pin Dependabot does not track goes stale silently, while this repo reasons that an unpinned linter turns an upstream release into a surprise CI failure on an unrelated change. The divergence is raised with the fleet rather than settled locally, so expect this paragraph to move once that is decided. `.py` files follow the repo's line-ending default (LF here - see [Line Endings][line-endings]). There is no pytest suite, so the coverage expectation is N/A.
 
 ### Toolchain
 

ESPHome-Config.code-workspace

@@ -41,7 +41,8 @@
 			"ms-vscode-remote.vscode-remote-extensionpack",
 			"ms-vscode.vscode-serial-monitor",
 			"redhat.vscode-yaml",
-			"streetsidesoftware.code-spell-checker"
+			"streetsidesoftware.code-spell-checker",
+			"xaver.clang-format"
 		]
 	}
-}
+}

OPERATIONS.md

@@ -159,14 +159,14 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 
 ### Debugging in the DevContainer
 
-- Complete the [VSCode setup](#vscode-setup).
+- Complete the [VSCode setup][vscode-setup].
 - Open the workspace and clone into the devcontainer volume.
 - TODO: serial port forwarding configuration.
 
 ### Debugging on Windows
 
 - Install Python from the Microsoft Store.
-- Complete the [VSCode setup](#vscode-setup).
+- Complete the [VSCode setup][vscode-setup].
 - Compile a project: `esphome compile test/adafruit-esp32-s3-feather.yaml`.
 - Plug in the device, holding Boot and pressing Reset when required.
 - List COM ports from PowerShell:
@@ -191,7 +191,7 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
   - WSL: `ls /dev/tty*`, for example `/dev/ttyACM0`, `/dev/ttyUSB0`
 - Install VSCode and the Remote Explorer extension.
 - Open a VSCode Remote WSL Ubuntu session.
-  - Complete the [VSCode setup](#vscode-setup) in the remote WSL session.
+  - Complete the [VSCode setup][vscode-setup] in the remote WSL session.
   - List ports: `ls /dev/tty*`.
   - Upload firmware: `esphome run --device /dev/ttyUSB0 test/esp32-s3-devkitc.yaml`
 - Unbind the serial port.
@@ -200,7 +200,7 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 
 ### Debugging in PlatformIO
 
-- Complete the [VSCode setup](#vscode-setup) and install the PlatformIO extension.
+- Complete the [VSCode setup][vscode-setup] and install the PlatformIO extension.
 - Compile the project with `esphome compile [project]`.
 - Launch the PlatformIO extension and open the project folder, for example `./.esphome/build/esp32-s3-test`.
 - PlatformIO opens a new instance of VSCode for that project.
@@ -226,12 +226,13 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 [garage-presence-sensor]: ./garage-presence-sensor.yaml
 [templates]: ./templates/
 [test-workflow]: ./.github/workflows/test-pull-request.yml
+[vscode-setup]: #vscode-setup
 
 <!-- External -->
 
 [dashboard-link]: http://localhost:6052/
-[esp-idf-framework-link]: https://esphome.io/components/esp32#esp-idf-framework
-[esphome-cli-link]: https://esphome.io/guides/cli
+[esp-idf-framework-link]: https://esphome.io/components/esp32/#esp-idf-framework
+[esphome-cli-link]: https://esphome.io/guides/cli/
 [esphome-nonroot-link]: https://github.com/ptr727/ESPHome-NonRoot
 [espressif32-versions-link]: https://registry.platformio.org/platforms/platformio/espressif32/versions
 [framework-espidf-link]: https://registry.platformio.org/tools/platformio/framework-espidf