Remove LENS workbook references from module text (PR #66 follow-up)

Vendor-internal naming should not appear in publicly-shipped module
text or PR metadata. Scrubbed all "LENS"/"LENS-Workbook"/"LENS-vocab"
/"LENS-style"/"Azure/AzureLocal-LENS-Workbook" mentions from:

- AzLocal.UpdateManagement.psd1 (v0.7.96 ReleaseNotes section header)
- CHANGELOG.md ([0.7.96] entry, 3 hits)
- README.md (v0.7.96 appendix entry)
- docs/release-history.md (v0.7.96 entry, 2 hits)
- Automation-Pipeline-Examples/docs/appendix-pipelines.md (Step 7 + Step 8 rows)
- Automation-Pipeline-Examples/README.md (Step.7 bullet)
- Private/Get-DeepestErrorMessage.ps1 (docstring)
- Private/Format-AzLocalUpdateRun.ps1 (2 inline comments)
- Automation-Pipeline-Examples/github-actions/Step.7_monitor-updates.yml
- Automation-Pipeline-Examples/azure-devops/Step.7_monitor-updates.yml
- Automation-Pipeline-Examples/github-actions/Step.8_fleet-update-status.yml
- Automation-Pipeline-Examples/azure-devops/Step.8_fleet-update-status.yml
- Automation-Pipeline-Examples/github-actions/Step.4_fleet-connectivity-status.yml

Replaced with neutral equivalents: "Azure portal Update Manager",
"Azure portal Update Manager `state` filter", "portal 'Status' filter
value", "coalesce(...) recursion". No behaviour change; comment/text only.

Pester: 824 Passed / 0 Failed / 1 Skipped (~2m20s).

Author: NeilBird

AzLocal.UpdateManagement/Automation-Pipeline-Examples/README.md

@@ -64,7 +64,7 @@ By the end of this guide you will have:
   - **Fleet Connectivity Status** (Step.4, v0.7.79+, enhanced in v0.7.85) - read-only daily snapshot of Arc agent connectivity, physical NIC health, Azure Resource Bridge status, and the node-count reconciliation between cluster `reportedProperties.nodes` and Arc-tagged physical machines. *Scheduled daily 05:30 UTC + manual.*
   - **Assess Update Readiness** (Step.5) - pre-flight, report-only readiness + blocking-health snapshot, published as JUnit XML. *Manual only.*
   - **Apply Updates** (Step.6) - apply updates to a single `UpdateRing` wave at a time, with WhatIf / dry-run support. *Manual only by default - **you must add a schedule** that lines up with your cluster `UpdateStartWindow` tags, see [Step 6 - Apply Updates](docs/appendix-pipelines.md#step-6---apply-updates) and [section 8](#8-scheduling-maintenance-windows-and-change-freeze-periods).*
-  - **Monitor In-Flight Updates** (Step.7, v0.7.90; v0.7.96 surfaces `Status` + deepest `ErrorMessage` columns, adds the `StepError` stuck-step JUnit type for runs that have hit an error inside a step without crossing the long-running threshold, and renders portal-linked Cluster Name / Update Name cells in the markdown summary). Operational snapshot during an active wave: lists each cluster whose latest update run is `InProgress`, with current step, progress (`completed/total steps`), elapsed duration, the LENS-vocab `Status` (`Success`/`Error`/`InProgress`/...), and the deepest `errorMessage` walked out of the nested ARM `steps[]` tree; flags long-running runs (default >6h) AND step-errored stuck runs as JUnit failures in the Checks tab. *Scheduled 5x/day at 20:00, 22:00, 00:00, 02:00, 04:00 UTC (every 2h across the typical overnight maintenance window) + manual; default cadence is editable in `Step.7_monitor-updates.yml` (v0.7.92+).*
+  - **Monitor In-Flight Updates** (Step.7, v0.7.90; v0.7.96 surfaces `Status` + deepest `ErrorMessage` columns, adds the `StepError` stuck-step JUnit type for runs that have hit an error inside a step without crossing the long-running threshold, and renders portal-linked Cluster Name / Update Name cells in the markdown summary). Operational snapshot during an active wave: lists each cluster whose latest update run is `InProgress`, with current step, progress (`completed/total steps`), elapsed duration, the `Status` column (`Success`/`Error`/`InProgress`/...), and the deepest `errorMessage` walked out of the nested ARM `steps[]` tree; flags long-running runs (default >6h) AND step-errored stuck runs as JUnit failures in the Checks tab. *Scheduled 5x/day at 20:00, 22:00, 00:00, 02:00, 04:00 UTC (every 2h across the typical overnight maintenance window) + manual; default cadence is editable in `Step.7_monitor-updates.yml` (v0.7.92+).*
   - **Fleet Update Status** (Step.8, formerly Step.7; v0.7.96 promotes `NeedsAttention` into the **Update Failed** bucket, adds a new **Action Required** bucket for `PreparationFailed`, and folds `PreparationInProgress` into **Update In Progress**). Scheduled daily snapshot of fleet update state, surfaced in the Tests tab. Markdown summary's `📜 Update Run History and Error Details` table now also carries portal-linked Cluster Name / Update Name cells plus the deepest-step `ErrorMessage`. *Scheduled daily 06:00 UTC + manual.*
   - **Fleet Health Status** (Step.9, formerly Step.8) - scheduled daily snapshot of 24-hour system health-check failures, surfaced in the Tests tab. *Scheduled daily 07:00 UTC + manual.*
 - An end-to-end "ring-based" rollout pattern: Pilot -> Wave2 -> Production, with each ring gated on the previous wave's success.

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/Step.7_monitor-updates.yml

@@ -260,8 +260,8 @@ stages:
               $hasStepError = ($progressStatus -eq 'Error' -and $r.State -eq 'InProgress')
               # Portal links (v0.7.96): cluster -> .../updates blade; update run -> the
               # AzureStackHCI portal extension SingleInstanceHistoryDetails ReactView.
-              # Pattern verified against the official Azure/AzureLocal-LENS-Workbook
-              # Update Progress workbook so URLs match what the portal builds itself.
+              # URL pattern verified against the Azure portal Update Manager view so
+              # the rendered links match what the portal builds itself.
               $clusterPortalUrl = if ($r.ClusterResourceId) { 'https://portal.azure.com/#@/resource' + [string]$r.ClusterResourceId + '/updates' } else { '' }
               $updateRunPortalUrl = ''
               if ($r.PSObject.Properties['RunResourceId'] -and $r.RunResourceId -and $r.ClusterResourceId) {

AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/Step.8_fleet-update-status.yml

@@ -266,8 +266,8 @@ stages:
           #            OR SBE prerequisite blocked
           #   PASSED = everything else
           # v0.7.96: PreparationFailed + NeedsAttention previously fell into the 'Other' bucket and
-          # were invisible to operators. They are now first-class failure signals (matches the LENS
-          # Update Manager workbook 'state' filter).
+          # were invisible to operators. They are now first-class failure signals (matches the
+          # Azure portal Update Manager 'state' filter).
           $failureStates = @('Failed','UpdateFailed','NeedsAttention','PreparationFailed')
           $failures = @($readiness | Where-Object { $_.HealthState -eq "Failure" -or ($_.UpdateState -in $failureStates) -or $_.HasPrerequisiteUpdates -ne "" }).Count
           $criticalHealthPassed = $totalTests - $failures

AzLocal.UpdateManagement/Automation-Pipeline-Examples/docs/appendix-pipelines.md

@@ -161,7 +161,7 @@ The table below is the ground truth for what each shipped YAML does **out of the
 
 | Aspect | Value |
 |---|---|
-| **Purpose** | In-flight observability for an active update wave. Reports clusters whose latest update run is currently `InProgress` with the CURRENT STEP each cluster is on, the PROGRESS (`completed/total steps`), and the ELAPSED DURATION. Long-running runs are flagged via the `long_running_threshold_hours` input (default 6h) so an operator can spot a stuck cluster without waiting for the next daily `fleet-update-status` snapshot. **No new ARM calls**: data source is `Get-AzLocalUpdateRuns -Latest` (one row per cluster) - the same call already made by `fleet-update-status`. **v0.7.96 enhancements:** (1) every in-flight row now carries the LENS-vocab `Status` column from `properties.progress.status` (`Success` / `Error` / `InProgress` / `NotStarted` / `Skipped` / `Cancelled` / `Unknown`); (2) a new `ErrorMessage` column surfaces the deepest non-empty `errorMessage` walked from the nested `properties.progress.steps[]` tree (mirrors the LENS-Workbook `coalesce(e9Msg..e1Msg)` pattern via the new private `Get-DeepestErrorMessage` helper); (3) runs whose `Status='Error'` but elapsed time is BELOW `long_running_threshold_hours` (the stuck-but-still-fresh Arizona-shaped case) now generate a new `failureType='StepError'` JUnit entry so they appear in the Checks tab WITHOUT needing the long-running threshold to fire; (4) the always-shown Failed-runs block carries an MS Learn TSG link plus the Progress Status column; (5) markdown summary's Cluster Name and Update Name cells render as `<a href="https://portal.azure.com/...">` deep-links to the cluster's Updates blade and the single-instance update-run history view. |
+| **Purpose** | In-flight observability for an active update wave. Reports clusters whose latest update run is currently `InProgress` with the CURRENT STEP each cluster is on, the PROGRESS (`completed/total steps`), and the ELAPSED DURATION. Long-running runs are flagged via the `long_running_threshold_hours` input (default 6h) so an operator can spot a stuck cluster without waiting for the next daily `fleet-update-status` snapshot. **No new ARM calls**: data source is `Get-AzLocalUpdateRuns -Latest` (one row per cluster) - the same call already made by `fleet-update-status`. **v0.7.96 enhancements:** (1) every in-flight row now carries a new `Status` column from `properties.progress.status` (`Success` / `Error` / `InProgress` / `NotStarted` / `Skipped` / `Cancelled` / `Unknown`); (2) a new `ErrorMessage` column surfaces the deepest non-empty `errorMessage` walked from the nested `properties.progress.steps[]` tree (uses a `coalesce(e9Msg..e1Msg)` recursion via the new private `Get-DeepestErrorMessage` helper); (3) runs whose `Status='Error'` but elapsed time is BELOW `long_running_threshold_hours` (the stuck-but-still-fresh Arizona-shaped case) now generate a new `failureType='StepError'` JUnit entry so they appear in the Checks tab WITHOUT needing the long-running threshold to fire; (4) the always-shown Failed-runs block carries an MS Learn TSG link plus the Progress Status column; (5) markdown summary's Cluster Name and Update Name cells render as `<a href="https://portal.azure.com/...">` deep-links to the cluster's Updates blade and the single-instance update-run history view. |
 | **Inputs** | `scope` (`all-clusters` (default) or `by-update-ring`), `update_ring` (only used when `scope=by-update-ring`; single ring, `Prod;Ring2` semicolon-list, or `***` wildcard), `long_running_threshold_hours` (0-48, default 6), `module_version` (optional). |
 | **Trigger** | **Manual only by default** (`workflow_dispatch` / **Run pipeline** button). A commented-out `schedule: cron '*/30 * * * *'` (GH) / `schedules: cron '*/30 * * * *'` (ADO) sample is shipped inside the `# BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers` block - uncomment it for the duration of an active wave, then re-comment it once the wave drains, so you do not generate 48 empty runs per day between waves. |
 | **Cmdlets invoked** | `Get-AzLocalUpdateRuns`, `Get-AzLocalClusterInventory` (used for ring-scope mode). |
@@ -177,7 +177,7 @@ The table below is the ground truth for what each shipped YAML does **out of the
 
 | Aspect | Value |
 |---|---|
-| **Purpose** | Daily fleet-wide snapshot of cluster update state. Read-only. **v0.7.90 pivots the Version Distribution markdown table by YYMM** (leading column `Version` = `2511`, `2604`, ...; new `Update Versions` column lists each distinct full version installed within that YYMM as `<version> x <count>` separated by `<br>`; rows sorted ascending by YYMM so the oldest YYMM is at the top). The underlying `<testsuite name="Fleet Version Distribution">` JUnit XML is unchanged - still one `<testcase>` per distinct full `CurrentVersion` - so machine-readable consumers and CI test-reporters are unaffected. **v0.7.96 reworks the Primary Status bucket cascade to align with the LENS workbook vocabulary:** `NeedsAttention` is now promoted into the **Update Failed** bucket; `PreparationFailed` lands in a new **Action Required** bucket (with its own actionable guidance in the Actions Required callout because the run never started, so re-arming is required); `PreparationInProgress` is folded into **Update In Progress**. The new bucket surfaces via (1) a new `<property name="primaryActionRequired" value="$stActionRequired"/>` JUnit attribute on the primary testsuite, (2) per-testcase `failureType='PreparationFailed'` instead of the generic `UpdateFailure`, (3) a new `ACTION_REQUIRED` `GITHUB_OUTPUT` (`actionRequired` pipeline variable in ADO), (4) `Summary.UpdateFailures` + `Summary.ActionRequired` in `readiness-status.json`, and (5) a new "Action Required (PreparationFailed)" row in the Primary Status markdown table with separate actionable prose in the Actions Required callout. The `📜 Update Run History and Error Details` markdown table renders Cluster Name and Update Name cells as `<a href="https://portal.azure.com/...">` deep-links (cluster's Updates blade + the single-instance update-run history view) - same linking as the Step.7 in-flight table. |
+| **Purpose** | Daily fleet-wide snapshot of cluster update state. Read-only. **v0.7.90 pivots the Version Distribution markdown table by YYMM** (leading column `Version` = `2511`, `2604`, ...; new `Update Versions` column lists each distinct full version installed within that YYMM as `<version> x <count>` separated by `<br>`; rows sorted ascending by YYMM so the oldest YYMM is at the top). The underlying `<testsuite name="Fleet Version Distribution">` JUnit XML is unchanged - still one `<testcase>` per distinct full `CurrentVersion` - so machine-readable consumers and CI test-reporters are unaffected. **v0.7.96 reworks the Primary Status bucket cascade to align with the Azure portal Update Manager `state` filter:** `NeedsAttention` is now promoted into the **Update Failed** bucket; `PreparationFailed` lands in a new **Action Required** bucket (with its own actionable guidance in the Actions Required callout because the run never started, so re-arming is required); `PreparationInProgress` is folded into **Update In Progress**. The new bucket surfaces via (1) a new `<property name="primaryActionRequired" value="$stActionRequired"/>` JUnit attribute on the primary testsuite, (2) per-testcase `failureType='PreparationFailed'` instead of the generic `UpdateFailure`, (3) a new `ACTION_REQUIRED` `GITHUB_OUTPUT` (`actionRequired` pipeline variable in ADO), (4) `Summary.UpdateFailures` + `Summary.ActionRequired` in `readiness-status.json`, and (5) a new "Action Required (PreparationFailed)" row in the Primary Status markdown table with separate actionable prose in the Actions Required callout. The `📜 Update Run History and Error Details` markdown table renders Cluster Name and Update Name cells as `<a href="https://portal.azure.com/...">` deep-links (cluster's Updates blade + the single-instance update-run history view) - same linking as the Step.7 in-flight table. |
 | **Inputs** | Scope (`-AllClusters` or `-ScopeByUpdateRingTag`), `throttle_limit` (optional). v0.7.4-style ITSM toggles are also exposed: `raise_itsm_ticket`, `itsm_config_path`, `itsm_dry_run`, `itsm_force_create` (all optional, default off). |
 | **Trigger** | Manual (`workflow_dispatch` / **Run pipeline** button) **plus** scheduled daily at 06:00 UTC (`cron '0 6 * * *'`). Edit the cron in the YAML to change cadence. |
 | **Cmdlets invoked** | `Get-AzLocalClusterInventory`, `Get-AzLocalClusterUpdateReadiness`, `Get-AzLocalUpdateSummary`, `Get-AzLocalAvailableUpdates`, `Get-AzLocalUpdateRuns`, `Get-AzLocalUpdateRunFailures`, `Get-AzLocalLatestSolutionVersion`. When ITSM is enabled: `Get-AzLocalItsmConfig`. |

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/Step.4_fleet-connectivity-status.yml

@@ -373,9 +373,9 @@ jobs:
             $sev = Get-ArbSeverity $r.ArbStatus
             $portal = "https://portal.azure.com/#@/resource$($r.ArbId)"
             # ClusterId / ClusterName may be a comma-separated list when the
-            # ARB's resource group hosts multiple HCI clusters (LENS-style
-            # multi-cluster-per-RG collapse). Use the first cluster for the
-            # portal URL and keep the full list in the body / properties.
+            # ARB's resource group hosts multiple HCI clusters (multi-cluster-
+            # per-RG collapse). Use the first cluster for the portal URL and
+            # keep the full list in the body / properties.
             # NOTE: the [string[]] cast is required - without it, when
             # Where-Object yields a single scalar, the if-as-expression
             # collapses $clusterIdList to a bare [string] and indexing it

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/Step.7_monitor-updates.yml

@@ -292,8 +292,8 @@ jobs:
               $hasStepError = ($progressStatus -eq 'Error' -and $r.State -eq 'InProgress')
               # Portal links (v0.7.96): cluster -> .../updates blade; update run -> the
               # AzureStackHCI portal extension SingleInstanceHistoryDetails ReactView.
-              # Pattern verified against the official Azure/AzureLocal-LENS-Workbook
-              # Update Progress workbook so URLs match what the portal builds itself.
+              # URL pattern verified against the Azure portal Update Manager view so
+              # the rendered links match what the portal builds itself.
               $clusterPortalUrl = if ($r.ClusterResourceId) { 'https://portal.azure.com/#@/resource' + [string]$r.ClusterResourceId + '/updates' } else { '' }
               $updateRunPortalUrl = ''
               if ($r.PSObject.Properties['RunResourceId'] -and $r.RunResourceId -and $r.ClusterResourceId) {

AzLocal.UpdateManagement/Automation-Pipeline-Examples/github-actions/Step.8_fleet-update-status.yml

@@ -274,8 +274,8 @@ jobs:
         #            OR SBE prerequisite blocked
         #   PASSED = everything else
         # v0.7.96: PreparationFailed + NeedsAttention previously fell into the 'Other' bucket and
-        # were invisible to operators. They are now first-class failure signals (matches the LENS
-        # Update Manager workbook 'state' filter).
+        # were invisible to operators. They are now first-class failure signals (matches the
+        # Azure portal Update Manager 'state' filter).
         $failureStates = @('Failed','UpdateFailed','NeedsAttention','PreparationFailed')
         $failures = @($readiness | Where-Object { $_.HealthState -eq "Failure" -or ($_.UpdateState -in $failureStates) -or $_.HasPrerequisiteUpdates -ne "" }).Count
         $criticalHealthPassed = $totalTests - $failures

AzLocal.UpdateManagement/AzLocal.UpdateManagement.psd1

@@ -226,7 +226,7 @@ Documentation-only release. The three Markdown files that ship inside the publis
 
 Apply via `Install-Module AzLocal.UpdateManagement -Force` (or `Update-Module`). If you only consume the cmdlets there is no behaviour change vs v0.7.96 - this is a docs-correctness republish. If you have copied the bundled YAMLs into your CI repo via `Update-AzLocalPipelineExample`, re-run it to refresh the version pin (pin-only short-circuit from v0.7.95 means `-Force` is not required).
 
-## Version 0.7.96 - LENS-workbook parity: Status field, ErrorMessage column, StepError JUnit type, always-show unresolved Failed, Step.8 ActionRequired bucket
+## Version 0.7.96 - Portal-parity: Status field, ErrorMessage column, StepError JUnit type, always-show unresolved Failed, Step.8 ActionRequired bucket
 
 For full v0.7.96 release notes see:
 https://github.com/NeilBird/Azure-Local/blob/main/AzLocal.UpdateManagement/CHANGELOG.md