diff --git a/.github/workflows/parity.yml b/.github/workflows/parity.yml
index a9cc20c..cc23b9e 100644
--- a/.github/workflows/parity.yml
+++ b/.github/workflows/parity.yml
@@ -90,6 +90,29 @@ jobs:
       - name: Verify oracle version
         run: devcontainer --version
 
+      # 024 Phase 7: an EXPLICIT BuildKit precondition, landed before the runner starts
+      # depending on it so the runner change is never the thing that reddens the lane.
+      #
+      # Declarative cases with a `build` operation need BuildKit. The GitHub runner ships
+      # buildx today, so this step is mostly an assertion — which is the point: the
+      # alternative was an outcome-conditional assertion inside the case data, tolerating
+      # "succeeded OR failed" because BuildKit's presence was unknown. That was nearly
+      # vacuous, since every one of those invocations passes `--output-format json` and
+      # deacon's JSON ERROR document also contains `"outcome"`. Establishing the
+      # precondition here, and checking it in `prereq::require_buildkit()`, dissolves the
+      # need for that assertion shape entirely.
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Verify BuildKit is available
+        # Fail LOUD and early rather than letting a `build` case report a divergence that
+        # is really a missing builder. `require_buildkit()` performs the same check inside
+        # the harness for local runs.
+        run: |
+          docker buildx version
+          docker buildx inspect --bootstrap >/dev/null
+          echo "BuildKit is available"
+
       - name: Build deacon
         run: cargo build -p deacon