Security & Performance Review

Reviewer: Automated analysis
Scope: src/ui/local_header.rs (40 additions, 12 deletions)
Result: No issues found

Security Analysis

No security concerns. This PR modifies only format strings for TUI display output. There are no changes to:

• External input parsing or user-supplied data handling
• Network I/O, file I/O, or system calls
• Authentication, authorization, or credential handling
• Command execution or shell interaction
• Dependencies or unsafe code

The formatting functions (format_pct, format_temp, power formatting) operate on hardware-sourced numeric values (f64, u32) that are never user-controllable. The output goes to a terminal buffer (crossterm::queue!), not to any persistent storage or network endpoint.

Performance Analysis

No performance concerns. The changes are strictly cosmetic adjustments to format!() macro calls:

• format_pct: One format! call per render tick per metric (CPU%, GPU%). The addition of {v:>5.1} right-alignment padding has negligible cost -- std::fmt handles width padding internally without additional allocation beyond what the original {v:.1} already required.

• format_temp: Same analysis -- {v:>3.0} vs {v:.0} is equivalent in cost.

• draw_power_sparkline: {power_watts:>5.1}W -- same analysis.

• draw_ram_sparkline: The new code computes total_str once and uses its .len() for the dynamic width. This adds one extra format! call for total_str, but it is a trivial integer-to-string conversion that occurs once per render tick. No measurable impact.

None of these paths are hot loops. They execute once per TUI refresh cycle (typically every 1-6 seconds depending on configuration).

Edge Case Note

The fixed-width fields will overflow their padding if values exceed the field width (e.g., power over 999.9W, temperature over 999C). This is acceptable because:

1. These are local machine metrics, not aggregated cluster values
2. No real hardware produces temperatures above 999C or local power above 999.9W
3. Rust's format! gracefully expands the field (no truncation, no panic), so the only consequence would be the same jitter the PR is fixing -- which only manifests for physically impossible values

Tests

All 12 local_header tests pass, including the two new tests (test_format_pct_fixed_width, test_format_temp_fixed_display_width) that assert stable display widths across digit boundaries. Clippy and cargo fmt --check are clean.

Verdict

Approved -- no changes needed.

Implementation Review Summary

Intent

Stabilize the local-mode header metric row width by using fixed-width formatted fields for CPU%, GPU%, temperature, power, and RAM values, preventing horizontal jitter when values cross digit boundaries.

Findings Addressed

None required -- the implementation is correct and complete as submitted.

Remaining Items

None.

Verification

• All stated requirements implemented
• No placeholder/mock code remaining
• Integrated into project code flow
• Project conventions followed
• Existing modules reused where applicable
• No unintended structural changes
• Tests pass (all 732 tests pass, 0 failures)

Review Details

Correctness: All four formatting changes produce stable display widths across digit boundaries:

• format_pct(): right-aligned 5-char numeric + % = 6 display columns for all values 0.0 through 100.0. The N/A case is also padded to 6 columns.
• format_temp(): right-aligned 3-char numeric + °C = 5 display columns for all values 0 through 999. The ° character is 2 bytes in UTF-8 but 1 display column, and the test correctly uses exact string comparison rather than byte-length comparison to verify.
• Power: right-aligned 5-char numeric + W = 6 display columns for values 0.0 through 999.9.
• RAM: used value padded to match total value digit width, keeping the / separator fixed.

Test coverage: Two new tests (test_format_pct_fixed_width and test_format_temp_fixed_display_width) specifically validate width stability across digit boundaries. Existing tests updated with correct expected values. All 12 local_header tests pass.

Convention consistency: The right-aligned fixed-width format specifiers ({:>N.M}) are consistent with the existing patterns used throughout the UI code (e.g., widgets.rs, chassis_renderer.rs, memory_renderer.rs).

Edge case note: Power values above 999.9W would exceed the 5-char field width, but this is acceptable for the local header context (single-machine monitoring). The dashboard mode handles multi-kilowatt aggregation separately with kW formatting.

Quality checks: cargo clippy clean, cargo fmt --check clean.

PR Finalization Complete

Summary

• Tests: Added 2 new tests — test_format_power_fixed_width and test_format_ram_fixed_separator_position — covering the inline formatting logic in draw_power_sparkline and draw_ram_sparkline. The RAM test also caught a subtle point: used is padded to the digit-width of total (not to a fixed constant), so " 0/16GB" rather than "0/16GB". All 14 module tests pass.
• Documentation: No changes needed — existing doc comments on the formatting helpers and module-level doc accurately describe the behavior.
• Lint/Format: Fixed one clippy::uninlined_format_args violation introduced by the new tests (format argument inlined per Rust 1.58+ style).

All checks passing. Ready for merge.