3.5.0 release prep: version bump, changelog cut, review prompt fix (#2243)

.github/workflows/claude-review.yml

@@ -41,8 +41,9 @@ jobs:
             REPO: ${{ github.repository }}
             PR NUMBER: ${{ github.event.pull_request.number }}
 
-            Review this pull request. Follow the conventions in CLAUDE.md and the T-SQL style
-            guide it points to. This repository ships two apps that must stay in parity — Lite
+            Review this pull request. Follow the conventions in CONTRIBUTING.md — including
+            its T-SQL style section (AS on table aliases, column_name = expression aliasing,
+            OPTION(RECOMPILE) on collector queries). This repository ships two apps that must stay in parity — Lite
             and Darling — so flag any change made to one but not its counterpart. Focus on:
             - Correctness: bugs, edge cases, null/error handling at system boundaries
             - Lite/Darling parity drift

CHANGELOG.md

@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [3.5.0] - 2026-08-19
+
 ### Added
 - **`cpu_attribution` on the top-CPU rankings: what fraction of the box the ranking explains** ([#2320]) - the last unshipped item from #2235's wishlist. `get_top_queries_by_cpu` and `get_top_procedures_by_cpu` (both SKUs) now return the returned rows' summed CPU-seconds, the SQL process's measured CPU-seconds for the same window (avg `cpu_utilization` % x core count x window - both stores already collect every piece), and `attributed_cpu_ratio`. Pre-#2290 the reads explained ~10% of the box and nothing said so - a caller chased the visible tenth assuming it was everything; and the ratio catches impossible claims at a glance (an external comparison died the moment its worker_time sum divided out to 137% of the box's available CPU-seconds - above the process's own measured consumption the note now says to distrust the numbers rather than presenting them). Below half, a note explains where unattributable CPU goes (evictions between snapshots, rows outside the top-N, zero-cost rows, non-query CPU). The degrade rule is explicit: missing CPU series, missing core count, or a series covering under 90% of the window omits the ratio rather than inventing one. One computation in `PerformanceMonitor.Common` (`CpuAttribution`), pinned by the same decision table in both test projects; the denominator read windows on `collection_time` with the same bounds as the rankings, so numerator and denominator share collection gaps.
 - **`get_query_store_health`: the MCP read for the new collector, both SKUs** ([#2319]) - the promised follow-up to the `query_store_health` collector: one browsable tool (beside `get_database_scoped_config`, whose latest-snapshot shape it mirrors) returning per-database actual vs desired state with the mismatch pre-folded into `state_matches_desired`, `readonly_reason` both raw and decoded, storage used vs cap with `pct_of_cap`, cleanup mode/thresholds, and the runtime-stats interval length; also exposed as a `/api/read` web endpoint. The `readonly_reason` bit table now lives ONCE in `PerformanceMonitor.Common` (`QueryStoreReadonlyReason`) and both viewers' grids and both MCP servers decode through it - the labels were miswritten from memory once during #2319 review, so a single source is the fix. While counting the tools for the instructions doc, the census sentence turned out to have silently drifted (it said ninety tools while the server exposed one hundred); it is rewritten with accurate digit counts (101 total / 76 shared with Lite / 25 Darling-only) and a new cross-app pin test parses it against the scanned inventory so it can never drift again.

Darling/PerformanceMonitor.Darling.Service/PerformanceMonitor.Darling.Service.csproj

@@ -5,7 +5,7 @@
     <ImplicitUsings>disable</ImplicitUsings>
     <RootNamespace>PerformanceMonitor.Darling.Service</RootNamespace>
     <AssemblyName>PerformanceMonitor.Darling.Service</AssemblyName>
-    <Version>3.4.0</Version>
+    <Version>3.5.0</Version>
     <!-- #2113: <Version> is the ONE hand-set version. AssemblyVersion / FileVersion /
          InformationalVersion derive from it at build time - the 3.4.0 release bumped only
          <Version> and shipped binaries still STAMPED 3.3.0.0, because four hand-maintained

Darling/PerformanceMonitor.Darling.Viewer/PerformanceMonitor.Darling.Viewer.csproj

@@ -15,7 +15,7 @@
          hooks go unhandled. It is a harmless no-op for the co-located (non-Velopack) viewer that
          ships inside the service zip. -->
     <StartupObject>PerformanceMonitor.Darling.Viewer.Program</StartupObject>
-    <Version>3.4.0</Version>
+    <Version>3.5.0</Version>
     <!-- #2113: <Version> is the ONE hand-set version. AssemblyVersion / FileVersion /
          InformationalVersion derive from it at build time - the 3.4.0 release bumped only
          <Version> and shipped binaries still STAMPED 3.3.0.0, because four hand-maintained

Lite/PerformanceMonitorLite.csproj

@@ -8,7 +8,7 @@
     <AssemblyName>PerformanceMonitorLite</AssemblyName>
     <RootNamespace>PerformanceMonitorLite</RootNamespace>
     <Product>SQL Server Performance Monitor Lite</Product>
-    <Version>3.4.0</Version>
+    <Version>3.5.0</Version>
     <!-- #2113: <Version> is the ONE hand-set version. AssemblyVersion / FileVersion /
          InformationalVersion derive from it at build time - the 3.4.0 release bumped only
          <Version> and shipped binaries still STAMPED 3.3.0.0, because four hand-maintained

deprecated/Dashboard/Dashboard.csproj

@@ -7,7 +7,7 @@
     <StartupObject>PerformanceMonitorDashboard.Program</StartupObject>
     <AssemblyName>PerformanceMonitorDashboard</AssemblyName>
     <Product>SQL Server Performance Monitor Dashboard</Product>
-    <Version>3.3.0</Version>
+    <Version>3.5.0</Version>
     <AssemblyVersion>3.3.0.0</AssemblyVersion>
     <FileVersion>3.3.0.0</FileVersion>
     <InformationalVersion>3.3.0</InformationalVersion>