@@ -101,8 +101,7 @@ cuda-bindings floor" in `cuda_core/AGENTS.md`. Check the floors instead:
   `cuda-bindings==<floor>`, and no "predates ... headers" line. Standard
   CI does not install the CUDA 12 floor: its rows use the 12.9.x backport
   build.
-- The release notes list every floor move since the last release under
-  "Breaking Changes".
+- The release notes list every floor move since the last release.
 
 Update the `cuda-core` pin in `cuda_python/setup.py` to the new minor
 series (`cuda-core~=X.Y.0`), and plan a `cuda-python` release right after
 
@@ -83,9 +83,9 @@ bump:
    pre-commit hook `check-cuda-core-bindings-floor`
    (`toolshed/check_cuda_core_bindings_floor.py`) checks the pins. It also
    checks that no documentation page spells a floor out by hand.
-3. Add to the release notes a "Breaking Changes" entry that names the new
-   floors. The support-policy table in `docs/source/support.rst` reads the
-   floors and the release version at docs-build time. It needs no edit.
+3. Add to the release notes an entry that names the new floors. The
+   support-policy table in `docs/source/support.rst` reads the floors and the
+   release version at docs-build time. It needs no edit.
 4. If the pins moved past what the pixi lock files resolve, refresh the lock
    files.
 5. Pin `cuda-bindings` to match in the conda-forge `cuda-core` feedstock. The
 
@@ -107,7 +107,7 @@ all read them from there.
 A floor moves only for one of two reasons. A ``cuda-core`` release needs a newer
 ``cuda-bindings`` API or fix, or its wheels are built against a newer CUDA minor version. A new
 ``cuda-bindings`` release alone does not move a floor, and a ``cuda-core`` release alone does
-not. The :doc:`release notes <release>` list every move under "Breaking Changes".
+not. The :doc:`release notes <release>` list every move.
 
 Python Version Support
 ----------------------