If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Diorser/LiteMonitor shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Missing license — unclear to depend on

• Last commit 8w ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Diorser/LiteMonitor repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Diorser/LiteMonitor.

What it runs against: a local clone of Diorser/LiteMonitor — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Diorser/LiteMonitor | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 85 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Diorser/LiteMonitor. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Diorser/LiteMonitor.git
#   cd LiteMonitor
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Diorser/LiteMonitor and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Diorser/LiteMonitor(\\.git)?\\b" \\
  && ok "origin remote is Diorser/LiteMonitor" \\
  || miss "origin remote is not Diorser/LiteMonitor (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/System/Program.cs" \\
  && ok "src/System/Program.cs" \\
  || miss "missing critical file: src/System/Program.cs"
test -f "src/System/HardwareMonitor.cs" \\
  && ok "src/System/HardwareMonitor.cs" \\
  || miss "missing critical file: src/System/HardwareMonitor.cs"
test -f "src/Plugins/PluginManager.cs" \\
  && ok "src/Plugins/PluginManager.cs" \\
  || miss "missing critical file: src/Plugins/PluginManager.cs"
test -f "src/Core/Settings.cs" \\
  && ok "src/Core/Settings.cs" \\
  || miss "missing critical file: src/Core/Settings.cs"
test -f "src/Core/ThemeManager.cs" \\
  && ok "src/Core/ThemeManager.cs" \\
  || miss "missing critical file: src/Core/ThemeManager.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 85 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~55d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Diorser/LiteMonitor"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

LiteMonitor is a lightweight, customizable Windows desktop and taskbar hardware monitoring tool built in C# that provides real-time CPU, GPU, memory, disk, network, and FPS monitoring with support for custom plugins, multiple display modes (vertical/horizontal/taskbar), theme customization, and memory cleanup utilities. It solves the problem of resource-heavy system monitors by offering a minimal-footprint alternative with high visual and functional configurability via JSON-based themes and plugin definitions. Monolithic WinForms/WPF C# application: core logic in LiteMonitor.csproj, a separate updater utility in LiteMonitor.Updater/, static assets (themes, language files, plugin definitions, screenshots) in /resources/, and manifest configuration (app.manifest) for Windows integration. Configuration and state persists via JSON files (settings.json inferred from README); plugins are JSON objects defining data sources and display rules rather than compiled code.

Windows users who want a lightweight system monitor that won't consume significant resources; power users seeking customizable desktop widgets; developers and system administrators needing real-time hardware telemetry; localization contributors (9 language files suggest active internationalization); plugin developers extending monitoring capabilities (e.g., weather, crypto, stock data via the plugin system in /resources/plugins/).

The project appears actively maintained with structured localization (9 language JSON files), an updater system (LiteMonitor.Updater subproject), plugin infrastructure with documentation (PLUGIN_DEV_GUIDE.md), and multiple screenshot assets suggesting ongoing feature polish. However, without visible GitHub stars/history or CI configuration in the provided file list, the maturity level is difficult to assess definitively—it shows signs of active development but lacks explicit test infrastructure or deployment workflows in the provided data.

Single language (C#) with monolithic structure and no visible unit test files in the top 60, raising concerns about regression coverage. The updater subsystem (LiteMonitor.Updater.exe in resources/) is bundled as a binary rather than source-built, creating supply-chain risk. Plugin system accepts arbitrary JSON definitions (Crypto.json, Stock.json) which could be exploited if external sources are compromised. No CI/CD pipeline visible in the file list, suggesting manual release management.

Based on the provided file list, recent work includes the plugin system (12 plugin definitions: Bilibili, Crypto, Weather, GitHub, Stock, etc.), horizontal layout mode (横屏模式), traffic history statistics (流量统计), memory cleanup feature, web-based monitoring interface, and an Aurora Dream theme. The PLUGIN_DEV_GUIDE.md suggests active effort to lower the barrier for community contributions.

git clone https://github.com/Diorser/LiteMonitor.git
cd LiteMonitor
# Open LiteMonitor.sln in Visual Studio 2019+ or JetBrains Rider
# Build the solution (Ctrl+Shift+B in VS)
# Run LiteMonitor.exe or press F5 to debug

Daily commands:

1. Open LiteMonitor.sln in Visual Studio 2019+. 2. Set LiteMonitor as the startup project. 3. Press F5 to build and run, or use Build → Rebuild Solution then run bin/Debug/LiteMonitor.exe. Alternatively, directly execute the release binary downloaded from GitHub Releases.

• src/System/Program.cs — Application entry point; initializes the main window, hardware monitoring loop, and plugin system—every contributor must understand the startup flow.
• src/System/HardwareMonitor.cs — Core hardware polling engine that aggregates CPU, GPU, memory, disk, and network metrics—the heart of all monitoring functionality.
• src/Plugins/PluginManager.cs — Manages plugin lifecycle (load, execute, sync)—essential for understanding extensibility and how third-party data integrates into the UI.
• src/Core/Settings.cs — Centralized settings schema and persistence layer—controls all user preferences, thresholds, and alarm configurations.
• src/Core/ThemeManager.cs — Loads and applies themes from JSON files—critical for UI customization and color/styling system.
• src/System/HardwareServices/HardwareScanner.cs — Detects and initializes hardware monitoring libraries (LibreHardwareMonitor API)—foundation for sensor discovery.
• src/Core/LanguageManager.cs — Multilingual string resolution system—required for localization and UI text rendering across 9+ languages.

Add a new hardware metric to the monitoring dashboard

1. Define the metric enum constant in src/System/HardwareServices/SensorMap.cs or add to MetricItem.cs (src/System/HardwareServices/SensorMap.cs)
2. Implement sensor detection and value retrieval in HardwareScanner.cs and HardwareValueProvider.cs (src/System/HardwareServices/HardwareScanner.cs)
3. Add metric label, unit, and formatting rules to MetricUtils.cs or MetricLabelResolver.cs (src/Core/MetricLabelResolver.cs)
4. Register the metric in the main polling loop in HardwareMonitor.cs and expose via Settings.cs visibility toggles (src/System/HardwareMonitor.cs)
5. Add UI display binding and theme color mappings in ThemeManager.cs (src/Core/ThemeManager.cs)

Add a new custom plugin (weather, crypto, API-based data)

1. Create a new JSON file in resources/plugins/ (e.g., MyPlugin.json) with fields: name, url, interval, dataKey, displayLabel (resources/plugins/Weather.json)
2. If custom parsing is needed, add a native processor in src/Plugins/Native/ (e.g., CryptoNative.cs) or rely on PluginProcessor.cs for JSON path extraction (src/Plugins/PluginProcessor.cs)
3. Register the plugin in PluginManager.cs LoadPlugins() to discover and load from resources/plugins/ (src/Plugins/PluginManager.cs)
4. Optionally add localization strings in resources/lang/*.json for the plugin's display name and tooltip (resources/lang/en.json)

Add a new theme variant

1. Create a new JSON theme file in resources/themes/ (e.g., MyTheme.json) with color definitions for CPU, GPU, memory, disk, network, background, text (resources/themes/DarkFlat_Classic.json)
2. Reference the theme schema and test color hex values are valid (e.g., #FF6B6B) (src/Core/ThemeManager.cs)
3. The ThemeManager.cs will auto-discover and load the new theme file on startup; add UI selector or docs (src/Core/ThemeManager.cs)

Add a new language translation

1. Create a new JSON translation file in resources/lang/ (e.g., it.json for Italian) with all key-value string pairs (resources/lang/en.json)
2. LanguageManager.cs auto-discovers and loads all .json files in resources/lang/; set language via Settings.cs culture code (src/Core/LanguageManager.cs)
3. Add the language option to the Settings UI dropdown; translations will be applied immediately (src/Core/Settings.cs)

• WPF (Windows Presentation Foundation) — Native Windows desktop UI framework for taskbar integration, transparency, and layered window rendering; aligns with Windows-only scope.
• LibreHardwareMonitor — Cross-GPU, cross-CPU hardware sensor abstraction library; supports NVIDIA, AMD, Intel GPUs and native CPU/motherboard sensors.
• C# .NET Framework — Windows-native runtime; enables direct Windows API calls (registry, taskbar, WMI) and efficient hardware queries.
• JSON configuration files — Human-readable, version-control-friendly format for themes, plugins, language packs, and settings—no database required.
• HTTP-based plugin system — Decouples plugins from core; allows third-party data sources (weather, stock, crypto) without code compilation or security risks.

• Windows-only (no Linux/macOS support)
  • Why: Taskbar integration, WMI, Performance Counters
  • Consequence: undefined

1. Hardware monitoring permissions: Accessing CPU temperature, GPU data, and disk/network speeds may require administrator privileges or WMI/LibreHardwareMonitor library initialization—check app.manifest and startup code. 2. Plugin data sources: Plugins like Stock.json, Crypto.json, Weather.json fetch from external APIs (not visible in this file list); network/firewall issues or API deprecation can silently break plugins without app code changes. 3. Multi-monitor taskbar integration: The auto-hide and screen-boundary detection (mentioned in README) require careful Windows API calls; edge cases with DPI scaling and multi-screen setups may lurk. 4. Updater binary in resources/: LiteMonitor.Updater.exe is committed as a binary; ensuring it stays in sync with the LiteMonitor.Updater/ source is a manual step—no automated build-and-embed visible in the file list. 5. Language/theme hot-reload: The README mentions 'immediate switch without restarting' but no visible hot-reload infrastructure in the file list; this may be fragile or rely on undocumented config file watcher logic.

• Windows Management Instrumentation (WMI) — LiteMonitor retrieves CPU, memory, disk, and system metrics via WMI queries (System.Management namespace in .NET); understanding WMI classes like Win32_Processor, Win32_VideoController, and Win32_LogicalDisk is essential for extending hardware monitoring without external libraries.
• JSON-driven configuration (declarative plugins & themes) — LiteMonitor decouples UI logic from data sources via JSON plugin definitions and theme files; this zero-code plugin model allows non-programmers to add weather/crypto/stock monitoring without recompilation—a key design pattern for extensibility.
• Windows Taskbar Integration (AppBarData & Shell APIs) — The taskbar display mode and auto-hide features require direct Windows Shell API calls (AppBarData, RegisterWindowMessage); essential for proper docking behavior and multi-monitor compatibility.
• Hardware Sensor Polling & Throttling — Real-time monitoring of CPU/GPU frequencies, temperatures, and power consumption requires periodic polling at 1–5 Hz refresh rates; LiteMonitor must balance update frequency against CPU load—a core performance engineering concern in system monitors.
• DPI Scaling & Dynamic UI Layout — The 'UI scaling' and 'intelligent number formatting' features mentioned in the README indicate responsive layout logic that adapts to Windows DPI settings and window resizing; critical for readable displays on 4K and multi-DPI systems.
• Transparency & Compositing (DWMAPI) — The 'transparent display' and 'rounded corners' features require Windows Desktop Window Manager (DWM) API calls for per-pixel alpha blending and visual effects; enables the 'clean and elegant' aesthetic mentioned in the README.
• Scheduled Tasks API (for auto-start without UAC elevation) — The 'auto-start on boot' feature uses Windows Task Scheduler instead of Registry Run keys to achieve admin-level startup without UAC prompts; a security-conscious pattern for system utilities.

• capnp/capnproto — Cap'n Proto provides efficient serialization; relevant if plugins need fast data marshaling between monitoring threads and UI updates.
• LibreHardwareMonitor/LibreHardwareMonitor — Popular open-source hardware monitoring library for .NET; LiteMonitor likely uses or could integrate this for CPU/GPU/sensor readings across AMD/NVIDIA/Intel hardware.
• ntop/ntopng — Network traffic monitoring tool; relevant for the network/disk I/O monitoring and traffic history features LiteMonitor provides.
• nicolargo/glances — Cross-platform system monitoring tool; similar feature set (CPU, GPU, memory, disk, network) but in Python; shows alternative approach to real-time telemetry UI.
• aristocratos/btop — Terminal-based resource monitor; complementary to LiteMonitor's desktop widget approach; demonstrates alternative UI paradigm for the same monitoring domain.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Core/MetricUtils.cs and Core/MetricLabelResolver.cs

These utility classes handle critical metric calculations and label resolution for the monitoring display. There are no test files visible in the repo structure, making it difficult to validate metric calculations (CPU %, GPU temp, network speeds) and ensure label localization works correctly across the 9 supported languages. Unit tests would prevent regressions when adding new metrics or modifying calculation logic.

• [ ] Create LiteMonitor.Tests project in solution
• [ ] Add test cases for MetricUtils.cs covering metric formatting, unit conversions (bytes to GB, MHz to GHz), and threshold calculations
• [ ] Add test cases for MetricLabelResolver.cs covering label resolution for all 9 languages (zh, en, de, es, fr, ja, ko, ru, zh-tw)
• [ ] Test edge cases: zero values, very large values, missing language files
• [ ] Configure GitHub Actions workflow to run tests on PR

Document plugin system with code examples in resources/plugins/PLUGIN_DEV_GUIDE.md

The PLUGIN_DEV_GUIDE.md exists but the README mentions it supports custom plugins without providing concrete examples. Looking at the plugins directory (Bilibili.json, Crypto.json, Weather.json, etc.), contributors need clear documentation on the JSON schema structure, API endpoints, response parsing, and refresh intervals. This will lower barriers for community plugin contributions.

• [ ] Define and document the complete JSON schema for plugin files (required fields: name, icon, refresh_interval, api_url, parse_rules)
• [ ] Add 2-3 annotated example plugins showing different API patterns (REST API, polling, webhook)
• [ ] Document how to test plugins locally before contributing
• [ ] Add troubleshooting section for common plugin errors
• [ ] Create a plugin submission checklist in PLUGIN_DEV_GUIDE.md

Add GitHub Actions workflow for automated theme validation

The repo contains 10 theme JSON files (AuroraDream_Purple.json, DarkFlat_Classic.json, etc.) in resources/themes/ with no visible validation. Invalid theme JSON or missing required color properties can break the UI at runtime. A CI workflow validating theme structure, required color fields, and hex color format would catch issues before release and enable theme contributions without manual review.

• [ ] Create .github/workflows/validate-themes.yml workflow
• [ ] Define required theme JSON schema (colors object with all required keys: primary, secondary, background, text, accent, etc.)
• [ ] Add validation script (PowerShell or C#) to check JSON syntax and required properties for all files in resources/themes/
• [ ] Add hex color format validation (#RRGGBB pattern)
• [ ] Run workflow on PR to resources/themes/ directory and report validation errors

• Add unit tests for theme JSON parsing: The /resources/themes/ directory contains 1+ theme files but no test files are visible in the top 60. Create a test project (LiteMonitor.Tests.csproj) with xUnit/NUnit tests that validate theme JSON schema loading, missing color key detection, and invalid JSON error handling to prevent broken themes from crashing the app.
• Document plugin API schema with JSON Schema file: PLUGIN_DEV_GUIDE.md exists but no formal JSON Schema (.json schema file) is provided. Create resources/plugins/plugin-schema.json defining the required fields (name, version, url, update_interval, etc.) so plugin authors can validate their JSON in editors (VS Code + JSON Schema extension) before submission.
• Add missing language translations for new UI strings: With 9 language files (en.json, zh.json, ja.json, de.json, es.json, fr.json, ru.json, ko.json, zh-tw.json), compare the key count across all files to identify missing translations. Create an issue template and contribution guide for translators to fill gaps, e.g., 'memory cleanup' or 'plugin manager' strings may not exist in all 9 languages yet.
• Create CI/CD pipeline for multi-platform builds: No .github/workflows/ or CI configuration visible in the file list. Set up a GitHub Actions workflow (build.yml) to automatically compile LiteMonitor.sln on Windows, run tests (once added), and publish release artifacts to GitHub Releases, reducing manual release overhead.

• High · Executable Files in Resources Directory — resources/assets/. The resources folder contains pre-compiled executable files (LiteMonitor.Updater.exe, LiteMonitorFPS.exe, PawnIO_setup.exe) which pose a significant security risk. These binaries could be tampered with, contain malware, or have known vulnerabilities. Distributing executables without proper code signing and verification mechanisms increases supply chain attack risk. Fix: 1) Remove pre-compiled executables from the repository. 2) Implement code signing for all distributed binaries. 3) Use a proper build and release pipeline that generates executables on-demand. 4) Add integrity verification (checksums, digital signatures) for downloaded dependencies. 5) Implement Software Bill of Materials (SBOM) tracking.
• High · Plugin System Without Input Validation — src/Plugins/PluginManager.cs, src/Plugins/PluginProcessor.cs, resources/plugins/. The plugin system (resources/plugins/) loads external JSON configurations for plugins that execute API calls and external services. Without proper validation and sandboxing, malicious or compromised plugin files could lead to arbitrary code execution, data theft, or denial of service attacks. Fix: 1) Implement strict schema validation for all plugin JSON files. 2) Use a whitelist of allowed plugin sources. 3) Implement plugin sandboxing to restrict resource access. 4) Add cryptographic signature verification for plugins. 5) Implement content security policies for plugin-provided data. 6) Add comprehensive logging and monitoring of plugin activities.
• High · Network Requests Without HTTPS Enforcement — resources/plugins/ (Crypto.json, Stock.json, Weather.json, Exchange.json, etc.), src/Plugins/PluginExecutor.cs. Multiple plugins reference external API endpoints (Crypto, Stock, Weather, Exchange, GitHub, etc.) in JSON configurations. Without enforcing HTTPS and certificate pinning, these requests are vulnerable to man-in-the-middle (MITM) attacks that could expose user data or inject malicious data. Fix: 1) Enforce HTTPS only for all external API calls. 2) Implement certificate pinning for critical services. 3) Validate SSL/TLS certificates properly. 4) Add request timeout mechanisms. 5) Implement request signing and verification where applicable. 6) Add monitoring for suspicious external connections.
• Medium · Updater Component Security Risks — LiteMonitor.Updater/, resources/version.json. The LiteMonitor.Updater component handles application updates without visible security mechanisms. Updates are critical attack vectors if not properly secured. Vulnerabilities include: lack of HTTPS enforcement for update checks, missing signature verification, and potential for downgrade attacks. Fix: 1) Implement cryptographic signature verification for all updates. 2) Enforce HTTPS with certificate pinning for update endpoints. 3) Prevent downgrade attacks by validating version numbers. 4) Implement secure rollback protection. 5) Add detailed update logging and audit trails. 6) Consider using a secure update framework like Squirrel or Microsoft Update.
• Medium · Hardcoded API Endpoints in Plugin Configurations — resources/plugins/Stock.json, resources/plugins/Crypto.json, resources/plugins/Weather.json, resources/plugins/Exchange.json. Plugin JSON files contain hardcoded API endpoints (e.g., Stock.json, Crypto.json, Weather.json). These endpoints lack visibility into security practices, SSL/TLS configuration, and data handling. API keys or sensitive parameters could be exposed if plugins are poorly configured. Fix: 1) Implement secure API endpoint management (separate from code). 2) Use environment variables for sensitive API configurations. 3) Validate all API endpoints against a whitelist. 4) Implement API key management and rotation strategies. 5) Add request/response encryption where applicable. 6) Implement rate limiting and request quotas.
• Medium · Missing Input Validation in Web Actions — src/Core/Actions/WebActions.cs. WebActions.cs handles web-based operations that could be vulnerable to injection attacks (XSS, HTML injection) if user input or external data is not properly validated and sanitized before being processed. Fix: 1) Implement strict input validation for all web-based operations. 2) Use parameterized requests and prepared statements. 3) Sanitize all output destined for web contexts. 4) Implement Content Security Policy (CSP) headers. 5) Use templating engines

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.