Name the appliance check for what it proves

.github/workflows/tests.yml

@@ -34,15 +34,21 @@ jobs:
     # https://mirror.keellinux.org/layers, verified, assembled into a
     # scratch rootfs, booted in LXC and checked by tests/boot-test.sh.
     # Nothing is built there; the build host publishes the layer
-    # (docs/releases-host.md of the keel repository).
+    # (docs/releases-host.md of the keel repository). So what boots is the
+    # layer the mirror publishes, never this branch: a pull request that
+    # changes the recipe is not exercised by this check, which is why the
+    # reusable job is called boot-published-layer.
     #
     # test-appliance.yml targets the labels "self-hosted, keel-lxc"; a job
     # aimed at a label no runner carries stays queued until GitHub cancels
     # it after 24 hours, so the reusable workflow's contract is that
     # callers gate on the organization variable KEEL_LXC_RUNNER
-    # (docs/ci-cd.md section 5 of the keel repository). While the layer is
-    # not published the job skips with a notice and passes. This job
-    # produces the check "appliance / build-and-boot".
+    # (docs/ci-cd.md section 5 of the keel repository). A layer that has
+    # never been published fails this job instead of passing it; the
+    # bootstrap exemption for a repository whose first layer does not exist
+    # yet is allow_unpublished, and this layer is published, so it is not
+    # used here. This job produces the check
+    # "appliance / boot-published-layer".
     if: vars.KEEL_LXC_RUNNER == 'true'
     uses: keel-linux/.github/.github/workflows/test-appliance.yml@main
     with:

COVERAGE.md

@@ -48,11 +48,15 @@ client will use.
 
 ## The appliance gate
 
-`appliance / build-and-boot` runs through the organization's
+`appliance / boot-published-layer` runs through the organization's
 `test-appliance.yml` on the self-hosted `keel-lxc` runner, which fetches
 the published layer from `https://mirror.keellinux.org/layers`, verifies
 it, assembles it, boots it in LXC and runs `tests/boot-test.sh`. Nothing is
-built there.
+built there, so what boots is the published layer and not this branch: a pull
+request that changes the recipe is not exercised by this check, which is why
+the job is `boot-published-layer` and not the old `build-and-boot`. A layer
+that has never been published fails it rather than passing it
+(keel-linux/.github pull request 12).
 
 ### What the gate found once the layer booted (2026-09-27)
 
@@ -100,7 +104,7 @@ becomes a required status on `main` then.
 
 ## Plan
 
-- Publish the layer, then require `appliance / build-and-boot` on `main`.
+- Require `appliance / boot-published-layer` on `main` under its new name.
 - Measure `conf.d/main`. A build time script that runs inside a chroot as
   root is the case decision 0003 splits, and what is left here after the
   logic moved to `lib/postgresql.sh` is SQL, three assertions about the