diff --git a/tests/cmc-upgrade-kernel-test.md b/tests/cmc-upgrade-kernel-test.md
index 25fe66b..7a4c552 100644
--- a/tests/cmc-upgrade-kernel-test.md
+++ b/tests/cmc-upgrade-kernel-test.md
@@ -79,7 +79,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
 - Do not power off, delete, or otherwise tear down the clone until the final latest-kernel migration/session validation is complete and recorded. The latest-kernel reboot or reinstall is not the end of the test.
 
 ## Execution Checklist
-- Treat this checklist as the run ledger for the test. Check off each item only after the supporting evidence has been gathered.
+- Treat this checklist as the run ledger for the test. Figuratively check off the items in the checklist to ensure we do and confirm each step.
 - Do not skip ahead, collapse, or reorder checklist items.
 - Do not begin teardown until every item below is checked complete.
 - If any checklist item cannot be checked, stop the test and record the blocker.
@@ -88,7 +88,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
 - [ ] 2. Remove offline hosts in `skidamarink` using MCP offline-host cleanup.
 - [ ] 3. Confirm source host is powered on for the inspection phase.
 - [ ] 4. SSH to the source host and check available kernel versions on the source before cloning.
-- [ ] 5. Build source-host kernel candidate list from all available versions and refresh package metadata first.
+- [ ] 5. Build source-host kernel candidate list from all available versions after a fresh package metadata refresh. On Ubuntu, inspect the generic track first, then confirm candidate availability with alternate package listing methods if needed before deciding whether the generic track is usable.
 - [ ] 6. Apply the candidate scope rule: same major OS family only, with same minor stream preferred.
 - [ ] 7. Verify at least 2 upgrade candidates exist in the filtered candidate list.
 - [ ] 8. If fewer than 2 candidates, hard stop and end run before clone creation.
@@ -158,8 +158,8 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
 4. SSH to the source host and check available kernel versions on the source before cloning.
 5. Build source-host kernel candidate list from all available versions (include intermediate versions, not just the latest from `check-update`).
    - On package-managed distros, first force a fresh metadata refresh using the package manager's normal refresh command, then use the distro-appropriate tooling to list all available kernel candidates before selecting a target.
-   - On Ubuntu, prefer the generic kernel track first: use `apt-cache madison` and/or `apt list -a` for `linux-image-generic` and `linux-headers-generic` after `apt update`.
-   - If the generic track returns no usable upgrade candidates, pause and ask the operator whether to continue with alternate Ubuntu kernel tracks.
+   - On Ubuntu, inspect the generic kernel track first after `apt update`, using more than one discovery method before concluding what is available. Use `apt-cache madison`, `apt list -a`, and `apt-cache policy` for `linux-image-generic` and `linux-headers-generic`; if needed, repeat those checks for `linux-generic` and the relevant HWE meta packages.
+   - If the refreshed generic-track view still returns no usable upgrade candidates, pause and ask the operator whether to continue with alternate Ubuntu kernel tracks.
    - When prompting for alternate Ubuntu tracks, display the other available kernel candidates, including `linux-image-generic-hwe-24.04` / `linux-headers-generic-hwe-24.04` when present, and wait for explicit operator confirmation before proceeding.
 6. Candidate scope rule:
    - Include only kernels in the same major OS family as the current machine (no major-version upgrades).