diff --git a/docs/guides/ha-cluster/readme.md b/docs/guides/ha-cluster/readme.md
index 63bc47b..8eacd7f 100644
--- a/docs/guides/ha-cluster/readme.md
+++ b/docs/guides/ha-cluster/readme.md
@@ -20,6 +20,7 @@ NNF software supports provisioning of Red Hat GFS2 (Global File System 2) storag
   - [Installation](#installation)
   - [STONITH Configuration](#stonith-configuration)
   - [Configuration Options](#configuration-options)
+  - [NNF Software Configuration](#nnf-software-configuration)
   - [Verifying Configuration](#verifying-configuration)
 - [Request/Response Protocol](#requestresponse-protocol)
   - [Request File Format](#request-file-format)
diff --git a/docs/guides/storage-profiles/readme.md b/docs/guides/storage-profiles/readme.md
index db84d1a..2932050 100644
--- a/docs/guides/storage-profiles/readme.md
+++ b/docs/guides/storage-profiles/readme.md
@@ -48,7 +48,7 @@ kubectl get nnfstorageprofiles -n nnf-system
 
 Example output:
 
-```
+```text
 NAME        DEFAULT   AGE
 default     true      14d
 high-perf   false     7d
@@ -199,6 +199,9 @@ data:
     userCommands:
       postSetup:
       - chown $USERID:$GROUPID $MOUNT_PATH
+      # Optional: run diagnostics after block device teardown (Rabbit only)
+      # postTeardown:
+      # - /usr/bin/dlm-diagnostics.sh $VG_NAME
 
     capacityScalingFactor: "1.0"
     allocationPadding: 300MiB
@@ -338,7 +341,7 @@ Target layout options control how Lustre targets (MGT, MDT, OST) are distributed
 Each target type (mgtOptions, mdtOptions, mgtMdtOptions, ostOptions) supports:
 
 | Option | Description |
-|--------|-------------|
+| -------- | ------------- |
 | `count` | Static number of targets to create |
 | `scale` | Dynamic value (1-10) that the WLM uses to determine target count |
 | `colocateComputes` | If true, targets are placed on Rabbits connected to job's compute nodes |
@@ -349,11 +352,13 @@ Each target type (mgtOptions, mdtOptions, mgtMdtOptions, ostOptions) supports:
 ### Understanding colocateComputes
 
 When `colocateComputes: true`:
+
 - Storage is restricted to Rabbit nodes with physical connections to the job's compute nodes
 - This typically means Rabbits in the same chassis as the compute nodes
 - Best for minimizing network hops and maximizing bandwidth
 
 When `colocateComputes: false`:
+
 - Storage can be placed on any available Rabbit node
 - Useful for separating metadata targets from data targets
 - Required for `create_persistent` directives since they may not have compute nodes
@@ -361,11 +366,13 @@ When `colocateComputes: false`:
 ### Scale vs Count
 
 **Scale** is useful when you want storage to automatically adjust based on job size:
+
 - Value of 1: Minimum targets needed to satisfy capacity
 - Value of 10: Maximum targets, potentially one per Rabbit connected to the job
 - The WLM interprets scale values based on allocation size, compute count, and Rabbit count
 
 **Count** is useful when you need precise control:
+
 - Specific number of targets regardless of job size
 - Consistent performance characteristics across different jobs
 - Useful for single-shared-file workloads with low metadata requirements
@@ -373,6 +380,7 @@ When `colocateComputes: false`:
 ### Example Layouts
 
 **High-performance scaled to job size:**
+
 ```yaml
 ostOptions:
   scale: 10
@@ -383,6 +391,7 @@ mdtOptions:
 ```
 
 **Static Configuration:**
+
 ```yaml
 ostOptions:
   count: 4
@@ -461,7 +470,7 @@ There are two categories of user commands with different execution contexts:
 The user commands in `blockDeviceCommands` and `fileSystemCommands` are run when storage is being activated/deactivated and mounted/unmounted for use:
 
 | Location | Workflow Phase | Description |
-|----------|----------------|-------------|
+| ---------- | ---------------- | ------------- |
 | Rabbit | DataIn | Storage is activated and mounted for data staging into the allocation |
 | Rabbit | DataOut | Storage is activated and mounted for data staging out of the allocation |
 | Rabbit | PreRun | Storage is activated and mounted for access in a user container |
@@ -470,6 +479,7 @@ The user commands in `blockDeviceCommands` and `fileSystemCommands` are run when
 | Compute | PostRun | Storage is unmounted and deactivated after the user's application completes |
 
 These commands are useful for operations that need to happen each time storage is accessed, such as:
+
 - Setting up environment-specific configurations
 - Running health checks before/after use
 - Synchronizing data or caches
@@ -537,13 +547,15 @@ xfsStorage:
 The `userCommands` section at the storage level (e.g., `xfsStorage.userCommands`) contains commands that run during the **setup and teardown phases** of the workflow. These run on the Rabbit nodes when storage is first provisioned and when it is finally destroyed.
 
 | Command | Phase | Description |
-|---------|-------|-------------|
+| --------- | ------- | ------------- |
 | `postSetup` | Setup | Runs after storage is fully provisioned and the file system is mounted on the Rabbit |
 | `preTeardown` | Teardown | Runs before storage is destroyed, while the file system is still mounted |
+| `postTeardown` | Teardown | Runs after storage is destroyed — file system and block devices are already removed. Runs on the Rabbit only |
 | `postActivate` | Setup | Runs after the file system is activated during initial setup |
 | `preDeactivate` | Teardown | Runs before the file system is deactivated during final teardown |
 
 These commands are useful for one-time operations such as:
+
 - Setting ownership and permissions on newly created storage
 - Initializing directory structures
 - Cleaning up or archiving data before destruction
@@ -560,6 +572,11 @@ xfsStorage:
     # Run once before storage is torn down (file system still mounted)
     preTeardown:
     - echo "Final cleanup of $MOUNT_PATH"
+
+    # Run once after storage is destroyed (file system and block devices already removed)
+    # Runs on the Rabbit only. $MOUNT_PATH is NOT available — use block device variables.
+    postTeardown:
+    - echo "Post-teardown check for $VG_NAME"
     
     # Run once after file system is activated during setup
     postActivate:
@@ -616,6 +633,8 @@ lustreStorage:
     - lfs setstripe -E 64K -L mdt -E -1 -c -1 $MOUNT_PATH
     rabbitPreTeardown:
     - lfs getstripe $MOUNT_PATH
+    rabbitPostTeardown:
+    - echo "Lustre teardown complete"
 
   # Commands run on MGT after all targets are up
   preMountMGTCommands:
@@ -632,7 +651,7 @@ Storage profile commands can use variables that are expanded at runtime. Variabl
 Available in all commands:
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
@@ -644,13 +663,13 @@ Available in all commands:
 #### Physical Volume Commands
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$DEVICE` | Path to allocated device (e.g., `/dev/nvme0n1`) |
 
 #### Volume Group Commands
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$VG_NAME` | Volume group name (controlled by Rabbit software) |
 | `$DEVICE_LIST` | Space-separated list of devices |
 | `$DEVICE_NUM` | Count of devices |
@@ -661,7 +680,7 @@ Available in all commands:
 #### Logical Volume Commands
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$VG_NAME` | Volume group name |
 | `$LV_NAME` | Logical volume name |
 | `$DEVICE_NUM` | Count of devices |
@@ -676,13 +695,13 @@ Available in all commands:
 #### XFS/Raw mkfs
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$DEVICE` | Path to the logical volume device |
 
 #### GFS2 mkfs
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$DEVICE` | Path to the logical volume device |
 | `$CLUSTER_NAME` | Cluster name (controlled by Rabbit software) |
 | `$LOCK_SPACE` | Lock space key (controlled by Rabbit software) |
@@ -691,7 +710,7 @@ Available in all commands:
 #### Mount/Unmount
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$DEVICE` | Device path to mount |
 | `$MOUNT_PATH` | Path to mount on |
 
@@ -700,7 +719,7 @@ Available in all commands:
 #### zpool create
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$POOL_NAME` | Pool name (controlled by Rabbit software) |
 | `$DEVICE_LIST` | Space-separated list of devices |
 | `$DEVICE_NUM` | Count of devices |
@@ -709,7 +728,7 @@ Available in all commands:
 #### zpool replace
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$POOL_NAME` | Pool name |
 | `$DEVICE_LIST` | List of devices |
 | `$DEVICE_NUM`, `$DEVICE_NUM-1`, `$DEVICE_NUM-2` | Device counts |
@@ -719,7 +738,7 @@ Available in all commands:
 #### Lustre mkfs
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$FS_NAME` | Lustre fsname picked by NNF software |
 | `$MGS_NID` | NID of the MGS |
 | `$ZVOL_NAME` | ZFS volume name (`pool/dataset`) |
@@ -730,7 +749,7 @@ Available in all commands:
 #### Lustre Client
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$MGS_NID` | NID of the MGS |
 | `$FS_NAME` | File system name |
 | `$MOUNT_PATH` | Client mount path |
@@ -745,7 +764,7 @@ Available in all commands:
 For system storage allocations:
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$COMPUTE_HOSTNAME` | Hostname of the compute node using the allocation |
 
 ### User Command Variables
@@ -757,7 +776,7 @@ Different variables are available depending on which user command hook is being
 The following variables are available to `blockDeviceCommands.rabbitCommands.userCommands` and `blockDeviceCommands.computeCommands.userCommands` (preActivate, postActivate, preDeactivate, postDeactivate):
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
@@ -769,7 +788,7 @@ The following variables are available to `blockDeviceCommands.rabbitCommands.use
 The following variables are available to `fileSystemCommands.rabbitCommands.userCommands` and `fileSystemCommands.computeCommands.userCommands` (preMount, postMount, preUnmount, postUnmount):
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
@@ -781,18 +800,34 @@ The following variables are available to `fileSystemCommands.rabbitCommands.user
 The following variables are available to `userCommands` at the storage level (postSetup, preTeardown, postActivate, preDeactivate):
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
 | `$MOUNT_PATH` | Path where the file system is mounted |
 
+For `postTeardown`, the file system and block devices have already been destroyed, so `$MOUNT_PATH` is **not** available. Instead, the following block device and workflow variables are available:
+
+| Variable | Description |
+| ---------- | ------------- |
+| `$VG_NAME` | Volume group name |
+| `$LV_NAME` | Logical volume name |
+| `$LV_INDEX` | Allocation index |
+| `$LV_SIZE` | Logical volume size |
+| `$DEVICE_NUM` | Number of physical devices |
+| `$DEVICE_LIST` | Space-separated list of device paths |
+| `$JOBID` | Job ID from the Workflow |
+| `$USERID` | User ID of the job submitter |
+| `$GROUPID` | Group ID of the job submitter |
+| `$ALLOCATION_COUNT` | Number of allocations on this Rabbit |
+| `$HOST_COUNT` | Total host count (computes + Rabbit) |
+
 #### Lustre Target User Commands
 
 The following variables are available to Lustre target commands (mgtCommandlines, mdtCommandlines, mgtMdtCommandlines, ostCommandlines) for postActivate and preDeactivate:
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$MOUNT_PATH` | Path where the target is mounted |
 | `$FS_NAME` | Lustre file system name |
@@ -805,7 +840,7 @@ The following variables are available to `clientCommandLines` user commands:
 **For rabbitPreMount, rabbitPostMount, rabbitPreUnmount, rabbitPostUnmount, computePreMount, computePostMount, computePreUnmount, computePostUnmount:**
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
@@ -816,7 +851,7 @@ The following variables are available to `clientCommandLines` user commands:
 **For rabbitPostSetup and rabbitPreTeardown:**
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$USERID` | User ID of the job submitter |
 | `$GROUPID` | Group ID of the job submitter |
@@ -829,12 +864,27 @@ The following variables are available to `clientCommandLines` user commands:
 | `$NUM_OSTS` | Number of OSTs |
 | `$NUM_NNFNODES` | Number of NNF nodes |
 
+**For rabbitPostTeardown:**
+
+Runs on the Rabbit after the Lustre file system and zpool are destroyed. `$MOUNT_PATH` and Lustre-specific variables are **not** available. The following variables are available:
+
+| Variable | Description |
+| ---------- | ------------- |
+| `$POOL_NAME` | Zpool name |
+| `$DEVICE_NUM` | Number of physical devices |
+| `$DEVICE_LIST` | Space-separated list of device paths |
+| `$JOBID` | Job ID from the Workflow |
+| `$USERID` | User ID of the job submitter |
+| `$GROUPID` | Group ID of the job submitter |
+| `$ALLOCATION_COUNT` | Number of allocations on this Rabbit |
+| `$HOST_COUNT` | Total host count (computes + Rabbit) |
+
 #### Lustre preMountMGTCommands
 
 The following variables are available to `preMountMGTCommands`:
 
 | Variable | Description |
-|----------|-------------|
+| ---------- | ------------- |
 | `$JOBID` | Job ID from the Workflow |
 | `$FS_NAME` | Lustre file system name |
 
@@ -844,8 +894,7 @@ The `variableOverride` fields in a storage profile allow overriding the default
 
 When a variable is overridden, the NNF software uses the new value internally when manipulating block devices and file systems; not just for expanding `$VARIABLE` references in command lines. For example, overriding `$LV_NAME` changes the actual logical volume name that the NNF software uses to perform checks and run internal commands.
 
-Variables are expanded recursively so that variable values can reference other variables. This allows building values based on job, workflow, and directive identifiers in a similar way to what the NNF software does internally. 
-
+Variables are expanded recursively so that variable values can reference other variables. This allows building values based on job, workflow, and directive identifiers in a similar way to what the NNF software does internally.
 
 #### Overridable Variables by File System Type
 
@@ -861,7 +910,7 @@ xfsStorage:
 ```
 
 | Variable | Default | Description |
-|----------|---------|-------------|
+| ---------- | --------- | ------------- |
 | `$JOBID` | From workflow | Job ID from the workflow |
 | `$USERID` | From workflow | User ID of the job submitter |
 | `$GROUPID` | From workflow | Group ID of the job submitter |
@@ -892,7 +941,7 @@ lustreStorage:
 **Target-level variables (mgtOptions, mdtOptions, mgtMdtOptions, ostOptions):**
 
 | Variable | Default | Description |
-|----------|---------|-------------|
+| ---------- | --------- | ------------- |
 | `$JOBID` | From workflow | Job ID from the workflow |
 | `$USERID` | From workflow | User ID of the job submitter |
 | `$GROUPID` | From workflow | Group ID of the job submitter |
@@ -909,7 +958,7 @@ lustreStorage:
 **Client-level variables (clientOptions):**
 
 | Variable | Default | Description |
-|----------|---------|-------------|
+| ---------- | --------- | ------------- |
 | `$JOBID` | From workflow | Job ID from the workflow |
 | `$USERID` | From workflow | User ID of the job submitter |
 | `$GROUPID` | From workflow | Group ID of the job submitter |
@@ -1059,4 +1108,4 @@ When a workflow references a storage profile, the NNF software creates a "pinned
 - The exact configuration is preserved for the workflow's lifetime
 - Profiles marked as `pinned: true` cannot also be `default: true`
 
-**Note:** Do not manually set `pinned: true` on profiles you create.
\ No newline at end of file
+**Note:** Do not manually set `pinned: true` on profiles you create.
diff --git a/docs/repo-guides/release-nnf-sw/readme-manual-steps.md b/docs/repo-guides/release-nnf-sw/readme-manual-steps.md
index bc1c64c..ad83c7f 100644
--- a/docs/repo-guides/release-nnf-sw/readme-manual-steps.md
+++ b/docs/repo-guides/release-nnf-sw/readme-manual-steps.md
@@ -24,6 +24,7 @@ other components.
   - [NearNodeFlash/lustre-fs-operator](https://github.com/NearNodeFlash/lustre-fs-operator)
   - [NearNodeFlash/nnf-mfu](https://github.com/NearNodeFlash/nnf-mfu)
   - [NearNodeFlash/nnf-ec](https://github.com/NearNodeFlash/nnf-ec)
+  - [NearNodeFlash/nnf-storedversions-maint](https://github.com/NearNodeFlash/nnf-storedversions-maint)
   - [NearNodeFlash/nnf-sos](https://github.com/NearNodeFlash/nnf-sos)
   - [NearNodeFlash/nnf-dm](https://github.com/NearNodeFlash/nnf-dm)
   - [NearNodeFlash/nnf-integration-test](https://github.com/NearNodeFlash/nnf-integration-test)
diff --git a/docs/repo-guides/release-nnf-sw/release-all.md b/docs/repo-guides/release-nnf-sw/release-all.md
index 83237aa..0508f0b 100644
--- a/docs/repo-guides/release-nnf-sw/release-all.md
+++ b/docs/repo-guides/release-nnf-sw/release-all.md
@@ -14,14 +14,15 @@ other components.
 
 - [NearNodeFlash/nnf-deploy](https://github.com/NearNodeFlash/nnf-deploy)
 
-    - [DataWorkflowServices/dws](https://github.com/DataWorkflowServices/dws)
-    - [HewlettPackard/lustre-csi-driver](https://github.com/HewlettPackard/lustre-csi-driver)
-    - [NearNodeFlash/lustre-fs-operator](https://github.com/NearNodeFlash/lustre-fs-operator)
-    - [NearNodeFlash/nnf-mfu](https://github.com/NearNodeFlash/nnf-mfu) *(standalone repo, not a submodule)*
-    - [NearNodeFlash/nnf-ec](https://github.com/NearNodeFlash/nnf-ec) *(standalone repo, not a submodule)*
-    - [NearNodeFlash/nnf-sos](https://github.com/NearNodeFlash/nnf-sos)
-    - [NearNodeFlash/nnf-dm](https://github.com/NearNodeFlash/nnf-dm)
-    - [NearNodeFlash/nnf-integration-test](https://github.com/NearNodeFlash/nnf-integration-test)
+  - [DataWorkflowServices/dws](https://github.com/DataWorkflowServices/dws)
+  - [HewlettPackard/lustre-csi-driver](https://github.com/HewlettPackard/lustre-csi-driver)
+  - [NearNodeFlash/lustre-fs-operator](https://github.com/NearNodeFlash/lustre-fs-operator)
+  - [NearNodeFlash/nnf-mfu](https://github.com/NearNodeFlash/nnf-mfu) *(standalone repo, not a submodule)*
+  - [NearNodeFlash/nnf-ec](https://github.com/NearNodeFlash/nnf-ec) *(standalone repo, not a submodule)*
+  - [NearNodeFlash/nnf-storedversions-maint](https://github.com/NearNodeFlash/nnf-storedversions-maint) *(standalone repo, not a submodule)*
+  - [NearNodeFlash/nnf-sos](https://github.com/NearNodeFlash/nnf-sos)
+  - [NearNodeFlash/nnf-dm](https://github.com/NearNodeFlash/nnf-dm)
+  - [NearNodeFlash/nnf-integration-test](https://github.com/NearNodeFlash/nnf-integration-test)
 
 - [NearNodeFlash/NearNodeFlash.github.io](https://github.com/NearNodeFlash/NearNodeFlash.github.io)
 
@@ -33,11 +34,12 @@ tool enforces the following order:
 3. `lustre-fs-operator`
 4. `nnf-mfu`
 5. `nnf-ec`
-6. `nnf-sos` (depends on dws, nnf-mfu, nnf-ec)
-7. `nnf-dm` (depends on dws, nnf-sos, nnf-mfu)
-8. `nnf-integration-test` (depends on dws, nnf-sos, nnf-dm, lustre-fs-operator)
-9. `nnf-deploy` (packages all submodules)
-10. `NearNodeFlash.github.io` (documentation, version matches nnf-deploy)
+6. `nnf-storedversions-maint` *(standalone repo)*
+7. `nnf-sos` (depends on dws, nnf-mfu, nnf-ec)
+8. `nnf-dm` (depends on dws, nnf-sos, nnf-mfu)
+9. `nnf-integration-test` (depends on dws, nnf-sos, nnf-dm, lustre-fs-operator)
+10. `nnf-deploy` (packages all submodules)
+11. `NearNodeFlash.github.io` (documentation, version matches nnf-deploy)
 
 ## Overview of release-all tool
 
@@ -48,7 +50,7 @@ tool enforces the following order:
 The following tools must be installed and available in your PATH:
 
 | Tool | Purpose | Notes |
-|------|---------|-------|
+| --- | --- | --- |
 | `gh` | GitHub CLI for PRs, releases | Requires `GH_TOKEN` env var (see below) |
 | `yq` | YAML processing | Must be the [Go version](https://github.com/mikefarah/yq), not the Python version |
 | `jq` | JSON processing | Used by `final-release-notes.sh` |
@@ -60,7 +62,7 @@ The following tools must be installed and available in your PATH:
 
 **Environment variables:**
 
-- `GH_TOKEN` — A GitHub classic personal access token with `repo` scope. Required by `gh` and by the `release-push`, `create-pr`, `merge-pr`, and `tag-release` phases.
+- `GH_TOKEN` — A GitHub **classic** personal access token (not fine-grained) with `repo` scope. The token is 40 characters, starting with `ghp_`. Required by `gh` and by the `release-push`, `create-pr`, `merge-pr`, and `tag-release` phases.
 
 **SSH access:**
 
@@ -87,12 +89,13 @@ The following tools must be installed and available in your PATH:
 
     The output will show the repos in dependency order:
 
-    ```
+    ```text
     dws
     lustre_csi_driver
     lustre_fs_operator
     nnf_mfu
     nnf_ec
+    nnf_storedversions_maint
     nnf_sos
     nnf_dm
     nnf_integration_test
@@ -102,6 +105,14 @@ The following tools must be installed and available in your PATH:
 
 1. **Check Vendoring:** For each repo's master/main branch; determine whether any of them need to be re-vendored.
     > **Note:** Ensure each repo is error-free before proceeding to the next repo in `repo-list`
+    >
+    > **Note:** `nnf_sos` requires the `-M` flag because it vendors multiple API versions of `dws`:
+    >
+    > ```bash
+    > ./release-all.sh -P master -R nnf_sos -M
+    > ```
+    >
+    > **Important:** Run vendoring checks on **all** repos, not just the ones you plan to release. This catches stale submodule pointers in `nnf-deploy` (e.g., a force-push on a submodule repo can leave the pointer at an orphaned commit SHA).
 
     ```bash
     For each repo in `repo-list`
@@ -110,6 +121,17 @@ The following tools must be installed and available in your PATH:
 
 2. **Create Trial Release Branch:** Create the new release branch, merge master/main to that release branch, but don't push it yet. The point of this step is to look for merge conflicts between master/main and the release branch.
 
+    > **Note:** `nnf_mfu` and `nnf_storedversions_maint` may report "No new changes to release" if master/main has no commits since the last release. This is normal — skip them in subsequent steps.
+    >
+    > **Note:** `nnf_doc` must be deferred until after `nnf_deploy` is tagged and its GitHub Release is published. The `nnf_doc` script updates `mkdocs.yml` with the latest `nnf-deploy` release version by querying GitHub Releases (not just tags). Follow this sequence:
+    >
+    > 1. Complete Steps 2–3d for all repos through `nnf_deploy`
+    > 2. **Wait ~60 seconds** for `nnf_deploy`'s "Handle Release Tag" GitHub Actions workflow to publish the GitHub Release
+    > 3. Verify: `gh release view $NNF_RELEASE -R NearNodeFlash/nnf-deploy` should succeed
+    > 4. Then run `nnf_doc` through Steps 2–3d
+    >
+    > **Important:** `nnf_doc`'s repo is `NearNodeFlash/NearNodeFlash.github.io` and uses the `main` branch (not `master`).
+
     ```bash
     For each repo in `repo-list`
         ./release-all.sh -P release -R $repo
@@ -153,6 +175,14 @@ The following tools must be installed and available in your PATH:
     **Step 3c** — Merge PR for the pushed release branch:
 
     > **Warning:** Do NOT manually merge the PR. Let `release-all.sh` merge it. If you accidentally merge manually, the `tag-release` phase may not find the expected merge commit message — use `-x force-tag=vX.Y.Z` to recover (see step 3d).
+    >
+    > **Note:** `merge-pr` may produce no visible output even on success. Verify the merge completed:
+    >
+    > ```bash
+    > gh api repos/<owner>/<repo>/pulls/<pr_number> 2>&1 | grep -o '"merged":[^,]*'
+    > ```
+    >
+    > Expected output: `"merged":true`
 
     ```bash
     ./release-all.sh -P merge-pr -R <repo>
@@ -161,6 +191,8 @@ The following tools must be installed and available in your PATH:
     **Step 3d** — Tag the release:
 
     > **Important:** This creates an **annotated** git tag. The CI/CD workflow (`handle_release_tag.yaml`) verifies that the tag is annotated and will reject lightweight tags. After tagging, the CI/CD workflow automatically creates the GitHub release with auto-generated release notes and attaches build artifacts (e.g., `manifests.tar` for `nnf-deploy`).
+    >
+    > **Note:** `tag-release` output will include "Bypassed rule violations for refs/tags/...". This is expected. All NNF repos have tag protection rulesets that block creation, update, and deletion of `v*` tags by default. Your account bypasses these rules because it has an admin or maintain role in the ruleset's bypass list. The tags are created correctly.
 
     ```bash
     ./release-all.sh -P tag-release -R <repo>
@@ -194,32 +226,40 @@ Finalize the release by updating the `nnf-deploy` release notes to include the r
 
 After all repos are released and release notes are finalized, compare the new NNF release manifest to the previous release manifest. This is a recommended verification step to confirm the release contains the expected changes and catch any problems.
 
-```console
-./compare-releases.sh v0.1.6 v0.1.7
-```
-
-The output:
+Use the `-i` flag to display image version changes inline:
 
 ```console
-Manifest diffs for v0.1.6 to v0.1.7 are in workingspace/manifest-v0.1.6-to-v0.1.7.diff
+./compare-releases.sh -i $PREVIOUS_RELEASE $NNF_RELEASE
 ```
 
-Peruse the release manifest differences:
+Example output:
 
 ```console
-less workingspace/manifest-v0.1.6-to-v0.1.7.diff
+Manifest diffs for v0.1.26 to v0.1.27 are in workingspace/manifest-v0.1.26-to-v0.1.27.diff (21426 lines, 8 files changed)
+Changed files:
+Files v0.1.26/nnf-dm/nnf-dm.yaml and v0.1.27/nnf-dm/nnf-dm.yaml differ
+Files v0.1.26/nnf-sos/nnf-sos.yaml and v0.1.27/nnf-sos/nnf-sos.yaml differ
+...
+
+Image version changes:
+-        image: ghcr.io/nearnodeflash/nnf-dm:0.1.25
++        image: ghcr.io/nearnodeflash/nnf-dm:0.1.26
+-        image: ghcr.io/nearnodeflash/nnf-sos:0.1.31
++        image: ghcr.io/nearnodeflash/nnf-sos:0.1.32
 ```
 
-Quickly see which submodules were updated between the releases:
+Use `-d` to display the full diff inline. The diff file is always saved to `workingspace/manifest-<ver1>-to-<ver2>.diff`.
+
+Peruse the release manifest differences:
 
 ```console
-grep image: workingspace/manifest-v0.1.6-to-v0.1.7.diff
+less workingspace/manifest-v0.1.26-to-v0.1.27.diff
 ```
 
 Quickly determine the scope of the differences between the releases:
 
 ```console
 brew install patchutils diffstat
-lsdiff workingspace/manifest-v0.1.6-to-v0.1.7.diff
-diffstat workingspace/manifest-v0.1.6-to-v0.1.7.diff
+lsdiff workingspace/manifest-v0.1.26-to-v0.1.27.diff
+diffstat workingspace/manifest-v0.1.26-to-v0.1.27.diff
 ```
diff --git a/mkdocs.yml b/mkdocs.yml
index 5748a49..07126d4 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -1,4 +1,4 @@
-# Release: 0.1.27
+# Release: 0.1.28
 site_name: NNF
 site_description: 'Near Node Flash'
 docs_dir: docs/