Runbook: sweep the nav file too during the version-string review

An end-to-end sandbox cutover surfaced that the content sweep missed the copied
nav data file (_data/nav/openvox_9x.yml): its section headings ('OpenVox 8
Platform') and link text ('Upgrading OpenVox 8') are authored version strings, but
the git grep only covered docs/_openvox_9x. Copy + stage the nav file in step 1 and
include it in the sweep pathspec so those get reviewed too.

Part of #325.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Michael Harp <mike@mikeharp.com>

Author: miharp

MAINTAINING.md

@@ -42,26 +42,31 @@ as needed.
 Do this when the new major has a tag to build against (a prerelease/RC is fine), but
 is **not yet** the stable release. `latest` stays on the current major.
 
-1. **Copy the collection, and stage it** so the sweep in step 2 sees only authored
-   pages:
+1. **Copy the collection and its nav file, and stage them** so the sweep in step 2
+   sees all the authored content:
 
    ```console
    cp -r docs/_openvox_8x docs/_openvox_9x
-   git add docs/_openvox_9x
+   cp _data/nav/openvox_8x.yml _data/nav/openvox_9x.yml
+   git add docs/_openvox_9x _data/nav/openvox_9x.yml
    ```
 
    Generated reference pages are gitignored within the collection, so `git add`
    stages only the authored content — and `git grep` below then skips the generated
    pages automatically (they self-update from the new tag at build time).
 
-2. **Sweep the copied authored pages for version-specific strings** and review each
-   in context (titles, nav headings, prose, compatibility notes, "upgrading from N"
-   pages). Target the **major you're leaving behind** (here, `8`):
+2. **Sweep the copied authored content for version-specific strings** and review each
+   in context (page titles, prose, compatibility notes, "upgrading from N" pages, and
+   the **nav file's** section headings and link text). Target the **major you're
+   leaving behind** (here, `8`):
 
    ```console
-   git grep -nE 'OpenVox 8|8\.x' -- docs/_openvox_9x
+   git grep -nE 'OpenVox 8|8\.x' -- docs/_openvox_9x _data/nav/openvox_9x.yml
    ```
 
+   Don't forget the nav file — its headings (e.g. "OpenVox 8 Platform") and link
+   text ("Upgrading OpenVox 8") are authored strings that won't update on their own.
+
    This is a review, **not** a blind find/replace. The hits fall into two kinds:
    straightforward current-version labels (page titles, "OpenVox 8 uses…") that bump
    to the new major, and version-*specific* content (e.g. "8.x still supports hiera 4
@@ -86,19 +91,18 @@ is **not yet** the stable release. `latest` stays on the current major.
        nav: openvox_9x
    ```
 
-4. **Wire up navigation:**
-   - Create `_data/nav/openvox_9x.yml` (copy from `openvox_8x.yml`; adjust as the
-     9.x structure diverges). Nav links are relative, so they resolve under
-     `/openvox/9.x/...` automatically — no rewriting needed.
-   - Add a **new** entry to `_data/nav_map.yml` whose `nav_key` matches the `nav:`
-     default from step 3 (do *not* add the collection to the existing 8.x entry —
-     `nav: openvox_9x` only resolves against a `nav_key: openvox_9x`):
+4. **Wire up navigation.** The nav file (`_data/nav/openvox_9x.yml`) was already
+   copied and swept in steps 1–2; adjust it further as the 9.x structure diverges
+   (its links are relative, so they resolve under `/openvox/9.x/...` automatically).
+   Then add a **new** entry to `_data/nav_map.yml` whose `nav_key` matches the `nav:`
+   default from step 3 (do *not* add the collection to the existing 8.x entry —
+   `nav: openvox_9x` only resolves against a `nav_key: openvox_9x`):
 
-     ```yaml
-     - nav_key: openvox_9x
-       collections: openvox_9x
-       base: /openvox/9.x/
-     ```
+   ```yaml
+   - nav_key: openvox_9x
+     collections: openvox_9x
+     base: /openvox/9.x/
+   ```
 
 5. **Add the version to `_data/products.yml`** (newest first), keeping `latest: 8x`
    for now: