📝 Document the CPU identification table and the rule that keeps it honest

README.md

@@ -57,6 +57,17 @@ for every tool on that platform.
 WebSocket feed and Prometheus exporter are part of the normal build. Bind it to
 loopback for local scripting or to your LAN for a headless box.
 
+**The CPU names itself, even when the part is new.** On x86 the System Summary
+decodes the CPUID signature into a microarchitecture codename — *Raphael (Zen
+4)*, *Arrow Lake*, *Granite Ridge (Zen 5)* — and every entry in that table is
+traceable to a primary source: Intel's `arch/x86/include/asm/intel-family.h` and
+libcpuid's `recog_amd.c`. That reaches parts the sensor library underneath
+cannot name: LibreHardwareMonitor's own CPU table matches only families 06h and
+0Fh, so Intel's newest families — Nova Lake (12h) and Diamond Rapids (13h) —
+are structurally unreachable for it, and several family-6 parts sit past the end
+of its model list. Where no source names a specific part, SensorView prints the
+*generation* it can prove instead of inventing a codename.
+
 **Honest blanks.** Where a value genuinely isn't available on a platform — CPUID
 on ARM, ACPI tables on Apple Silicon, S.M.A.R.T. behind Apple's storage
 controller — the field renders `—` rather than a plausible-looking guess.
@@ -69,7 +80,10 @@ controller — the field renders `—` rather than a plausible-looking guess.
 - Dense, sortable **Sensors Status** table with current / min / max / average
   columns, per-type icons, draggable column widths and font zoom
 - Per-sensor **history graphs** in their own windows
-- **System Summary** — CPU, motherboard, memory, GPU, drives, OS, ISA feature grid
+- **System Summary** — CPU (CPUID signature and microarchitecture codename on
+  x86), motherboard, memory modules with their real SMBIOS type — LPDDR4 and
+  LPDDR5 read as themselves, not as a generic "DRAM" — GPU, drives, OS and
+  the ISA feature grid
 - **Hex Viewer** for raw firmware blobs (ACPI/SMBIOS on Windows and Linux)
 - Configurable poll interval, min/max reset, light/dark/grey themes
 

TODO.md

@@ -167,6 +167,16 @@ missed:
   process down.
 - **`settings.val_col_width`** is declared, persisted and never read.
 
+- **`cpuid_info` applies ExtendedModel unconditionally** (`app/src/sysinfo.rs:49`).
+  Both the Intel SDM and the AMD APM say the ExtendedModel field is only to be
+  folded into the model number when the *base* family is 6h or Fh; the code does
+  `(ext_model << 4) | base_model` for every family. It is benign today, because
+  every family the codename table names has base family 6 or Fh, so the computed
+  model is the correct one in each case. It would start lying if a vendor
+  shipped a part on some other base family with a non-zero ExtendedModel. The
+  fix is a one-line guard; it was deliberately left out of the codename restore
+  so that a bug-fix PR stayed a restore.
+
 ## Release
 
 - **`release.yml` has never completed successfully.** The last manual run failed

app/PROJECT_SUMMARY.md

@@ -72,7 +72,8 @@ app/
     │   ├── mod.rs        # SensorSource trait, Diagnostics, default_source()
     │   ├── lhm_bridge.rs # spawn/parse the .NET sidecar (Windows)
     │   └── demo.rs       # synthetic data — driverless fallback / CI / non-Windows
-    ├── sysinfo.rs        # WMI static info, CPUID, is_elevated()  (~427 lines)
+    ├── sysinfo.rs        # per-platform static info, CPUID decode, SMBIOS memory
+    │                    # types, is_elevated()  (~1300 lines)
     ├── settings.rs       # AppSettings (JSON in %APPDATA%\SensorView\settings.json)
     ├── logging.rs        # CsvLogger
     ├── report.rs         # write_report() → SensorView_Report_<stamp>.txt
@@ -190,7 +191,7 @@ stats, history, graph windows, and CSV columns.
 | --- | --- | --- |
 | **Main** | `main_window.rs` | Toolbar (Summary / Save Report / Sensors / Memory / About / Settings), left device tree with painted icons (`Computer, Central Processor(s), Motherboard, Memory, Video Adapter, Drives, Network`), right "Feature" detail pane fed by `sysinfo`, machine-name status bar |
 | **Sensors Status** | `sensors_window.rs` | HWiNFO flow-column dense sensor table: grouped bands, Current/Min/Max/Average columns, type-colored values, collapsible groups, right-click → Show Graph, CSV logging toggle, uptime clock, **diagnostic banners** |
-| **System Summary** | `summary_window.rs` | CPU / motherboard / memory-module / GPU / drive panels from WMI + CPUID |
+| **System Summary** | `summary_window.rs` | CPU / motherboard / memory-module / GPU / drive panels from WMI + CPUID. The CPU panel prints the raw CPUID signature *and* the decoded microarchitecture codename (`sysinfo::codename_for`); memory modules print the decoded SMBIOS type-17 code (`sysinfo::smbios_memory_type`), so LPDDR parts name themselves instead of collapsing to "DRAM" |
 | **Settings** | `settings_dialog.rs` | 5 tabs: *General / User Interface* (live), *Safety* (stub), *SMBus / I2C* (stub), *Driver Management* (live — shows real ring0 report + elevation), *License Management* (stub) |
 | **Graph** (n instances) | `graph_window.rs` | One deferred viewport per sensor identifier in `Shared.graphs`; hand-painted autoscaled polyline (no plotting dependency) |
 

app/README.md

@@ -49,6 +49,26 @@ The data model mirrors OpenHardwareMonitor's `Hardware/ISensor.cs` and
 `Hardware/IHardware.cs`, so the C# reference in the repository root and this port
 share a vocabulary.
 
+## Adding a CPU codename
+
+`sysinfo.rs` decodes the CPUID signature into a microarchitecture name. Two
+rules keep that table honest, and both are enforced by tests:
+
+1. **Cite the source in the comment.** Intel entries come from
+   `arch/x86/include/asm/intel-family.h`, AMD entries from libcpuid's
+   `recog_amd.c`. If neither names the part, do not invent a codename — extend
+   the family's catch-all arm, which reports only the generation.
+2. **Match a single model unless a whole block really is one part.** A
+   `0x00..=0x0f` range written around one sourced model silently swallows its
+   neighbours. AMD families 17h, 19h and 1Ah each ship a Threadripper at model
+   `08h` right beside the server part at `01h`/`02h`; three such ranges had all
+   three Threadrippers reporting an EPYC codename. See the
+   `a_threadripper_is_not_an_epyc` test.
+
+`intel-family.h` writes its family numbers in **decimal**. Family 18 in that
+header is 12h, not 18h — and 19h is AMD's Zen 3/Zen 4 family, so the mistake
+reads as a real entry.
+
 ## Checks
 
 These are exactly what CI runs: