🤖 [AI][Claude Code] Deferred from PR review of #2155 (FinOps multitool) — three non-urgent polish items, none blocking that PR's merge.
1. Diagnostic message misattributes non-RBAC storage errors
src/powershell/Private/FinOpsMultitool/modules/helpers/Resolve-CostDataSource.ps1, Test-HubStorageAccess (~lines 305-319). When Get-AzStorageAccount throws for any reason other than missing access, the result is unconditionally classified Blocker = 'NoRbac' with remediation "Grant Reader on the hub storage account." A transient network/timeout failure gets the same (wrong) remediation hint as an actual permissions problem. The raw exception text is still surfaced in Detail, so this is a UX/diagnostic-accuracy issue, not silent failure.
2. No static guard enforces the "read-only tool" invariant
src/powershell/Tests/Unit/MultitoolSafety.Tests.ps1. The suite asserts scanner modules only call commands that resolve (no undefined commands), and has strong local file-system safety coverage (path traversal, symlink rejection, ACLs), but nothing asserts that no scanner module or helper calls a mutating Az cmdlet (Set-Az*, New-Az*, Remove-Az*, Invoke-AzResourceAction, etc.). Today's code is confirmed read-only by manual grep across all 30 scanner modules and helpers, but that invariant is enforced by review discipline, not by a test — a future PR could add a mutating call to a scanner module and nothing here would catch it. Suggest a static-AST guard similar in spirit to the existing "no undefined commands" check.
3. Invoke-FinOpsMultitool (the primary entry point) has no comment-based help
src/powershell/Private/FinOpsMultitool/Invoke-FinOpsMultitool.ps1, lines 10-27. The banner is a plain #-line comment block, not <# #>, so Get-Help Invoke-FinOpsMultitool -Full returns nothing useful for -SubscriptionId, -OutputPath, -Scans, -DataSource, -NonInteractive, etc. It's a Private function, so lower priority than a public cmdlet, but it's the tool's actual interactive entry point per the README quick-start.
Source: PR #2155
🤖 [AI][Claude Code] Deferred from PR review of #2155 (FinOps multitool) — three non-urgent polish items, none blocking that PR's merge.
1. Diagnostic message misattributes non-RBAC storage errors
src/powershell/Private/FinOpsMultitool/modules/helpers/Resolve-CostDataSource.ps1,Test-HubStorageAccess(~lines 305-319). WhenGet-AzStorageAccountthrows for any reason other than missing access, the result is unconditionally classifiedBlocker = 'NoRbac'with remediation "Grant Reader on the hub storage account." A transient network/timeout failure gets the same (wrong) remediation hint as an actual permissions problem. The raw exception text is still surfaced inDetail, so this is a UX/diagnostic-accuracy issue, not silent failure.2. No static guard enforces the "read-only tool" invariant
src/powershell/Tests/Unit/MultitoolSafety.Tests.ps1. The suite asserts scanner modules only call commands that resolve (no undefined commands), and has strong local file-system safety coverage (path traversal, symlink rejection, ACLs), but nothing asserts that no scanner module or helper calls a mutating Az cmdlet (Set-Az*,New-Az*,Remove-Az*,Invoke-AzResourceAction, etc.). Today's code is confirmed read-only by manual grep across all 30 scanner modules and helpers, but that invariant is enforced by review discipline, not by a test — a future PR could add a mutating call to a scanner module and nothing here would catch it. Suggest a static-AST guard similar in spirit to the existing "no undefined commands" check.3.
Invoke-FinOpsMultitool(the primary entry point) has no comment-based helpsrc/powershell/Private/FinOpsMultitool/Invoke-FinOpsMultitool.ps1, lines 10-27. The banner is a plain#-line comment block, not<# #>, soGet-Help Invoke-FinOpsMultitool -Fullreturns nothing useful for-SubscriptionId,-OutputPath,-Scans,-DataSource,-NonInteractive, etc. It's aPrivatefunction, so lower priority than a public cmdlet, but it's the tool's actual interactive entry point per the README quick-start.Source: PR #2155