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/zhongyang219/TrafficMonitor 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 — Single-maintainer risk — review before adopting

• Last commit 5w ago
• 10 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 85% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{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 zhongyang219/TrafficMonitor repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/zhongyang219/TrafficMonitor.

What it runs against: a local clone of zhongyang219/TrafficMonitor — 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 zhongyang219/TrafficMonitor | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 62 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of zhongyang219/TrafficMonitor. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/zhongyang219/TrafficMonitor.git
#   cd TrafficMonitor
#
# 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 zhongyang219/TrafficMonitor and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 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 "TrafficMonitor/TrafficMonitor.cpp" \\
  && ok "TrafficMonitor/TrafficMonitor.cpp" \\
  || miss "missing critical file: TrafficMonitor/TrafficMonitor.cpp"
test -f "TrafficMonitor/CommonData.h" \\
  && ok "TrafficMonitor/CommonData.h" \\
  || miss "missing critical file: TrafficMonitor/CommonData.h"
test -f "TrafficMonitor/DisplayItem.h" \\
  && ok "TrafficMonitor/DisplayItem.h" \\
  || miss "missing critical file: TrafficMonitor/DisplayItem.h"
test -f "OpenHardwareMonitorApi/OpenHardwareMonitorImp.cpp" \\
  && ok "OpenHardwareMonitorApi/OpenHardwareMonitorImp.cpp" \\
  || miss "missing critical file: OpenHardwareMonitorApi/OpenHardwareMonitorImp.cpp"
test -f "TrafficMonitor/D2D1Support.h" \\
  && ok "TrafficMonitor/D2D1Support.h" \\
  || miss "missing critical file: TrafficMonitor/D2D1Support.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 62 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~32d)"
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/zhongyang219/TrafficMonitor"
  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).

TrafficMonitor is a Windows desktop floating-window application that displays real-time network speed, CPU/memory utilization, and optionally hardware temperatures (Standard version) or GPU/disk metrics (Lite version). It supports embedding into the taskbar, skin switching, and traffic history statistics, functioning as a lightweight system monitoring overlay written in C++ with optional hardware monitoring via OpenHardwareMonitor interop. Modular monolith: OpenHardwareMonitorApi/ wraps hardware sensor interop (*.dll + C++ adapters like OpenHardwareMonitorImp.cpp), PluginDemo/ demonstrates the plugin architecture (DataManager.cpp, CustomDrawItem.cpp), and the main application likely resides in sibling directories not fully shown. Skin/UI resources and localization (Help.md, Help_en-us.md) are versioned alongside code.

Windows power users and system administrators who need persistent, non-intrusive visibility into network bandwidth and CPU/memory usage without launching heavy resource monitors; also appeals to Chinese users as a Chinese-authored alternative to similar tools.

Actively maintained and production-ready. The project has CI/CD via GitHub Actions (/.github/workflows/main.yml), established release versioning (v1.80+), user-facing documentation in both Chinese and English, and a clear Standard vs. Lite version strategy. The massive C++ codebase (1.36MB) and thoughtful separation of concerns (OpenHardwareMonitorApi/, PluginDemo/) indicate mature architecture. Recent activity visible through versioning notes on temperature monitoring deprecation (post-v1.86).

Moderate risk: single maintainer (zhongyang219), heavy reliance on OpenHardwareMonitor.dll (closed-source binary in OpenHardwareMonitorApi/), Windows-only platform limits community contributions, and requires admin elevation in Standard version. No visible automated test suite (no test/ or Tests/ directory) increases regression risk. Dependency on MSVC runtime (mentioned in README) creates fragile deployment chain.

Recent focus on version 1.86+ lifecycle: consolidating temperature monitoring into a separate plugin, stabilizing Lite version feature parity (GPU/disk monitoring added to Lite), and transitioning users away from admin-elevation requirements. The emergence of TrafficMonitorPlugins (referenced in README) indicates architectural shift toward extensibility.

git clone https://github.com/zhongyang219/TrafficMonitor.git
cd TrafficMonitor
# Open TrafficMonitor.sln in Visual Studio 2017+ (inferred from .vcxproj structure)
# Build → Select 'Release' for Standard or 'LiteLess' config for Lite version
# Exe outputs to bin/ (convention; exact path in .sln)

(No package.json; Windows/.NET environment required.)

Daily commands: No web server; this is a desktop GUI app. Build .sln in Visual Studio → launch .exe. For dev iteration: edit source → Build (F7) → Run (F5) within Visual Studio. For runtime testing, Standard version requires runas /admin or UAC elevation; Lite version runs normally.

• TrafficMonitor/TrafficMonitor.cpp — Main application entry point and window manager; every contributor must understand the primary message loop and initialization flow
• TrafficMonitor/CommonData.h — Central data structure holding all monitoring metrics (CPU, memory, traffic); shared across all UI and logic layers
• TrafficMonitor/DisplayItem.h — Core abstraction for configurable display elements; defines how monitored data is rendered in the UI
• OpenHardwareMonitorApi/OpenHardwareMonitorImp.cpp — Hardware sensor abstraction layer interfacing with LibreHardwareMonitor.dll; critical for CPU/memory data collection
• TrafficMonitor/D2D1Support.h — Direct2D rendering abstraction; enables skin system and floating window graphics pipeline
• TrafficMonitor/BaseDialog.h — Base class for all dialog windows (settings, about, skinning); establishes UI framework conventions
• TrafficMonitor.sln — Visual Studio solution file; defines project structure and build dependencies for the entire application

Add a new monitored metric (e.g., GPU usage, disk I/O)

1. Add enum value for new metric type in CommonData.h (around data structure definitions) (TrafficMonitor/CommonData.h)
2. Extend OpenHardwareMonitorImp.cpp to query new sensor from hardware API and populate CommonData (OpenHardwareMonitorApi/OpenHardwareMonitorImp.cpp)
3. Create new DisplayItem configuration entries in display settings to allow users to enable/disable the metric (TrafficMonitor/DisplayTextSettingDlg.cpp)
4. Update rendering logic in TrafficMonitor.cpp to include new metric in floating window and taskbar display (TrafficMonitor/TrafficMonitor.cpp)

Create a new skin theme

1. Create skin definition file (XML or binary format) following existing skin structure in the skins directory (TrafficMonitor/CSkinPreviewView.cpp)
2. Add skin metadata to skin selection dialog to enable user to browse and load the new skin (TrafficMonitor/CSkinPreviewView.cpp)
3. Implement color and font rendering using Direct2D in D2D1Support for theme-specific rendering (TrafficMonitor/D2D1Support.cpp)
4. Test skin with taskbar and floating window rendering to ensure visual consistency (TrafficMonitor/ClassicalTaskbarDlg.cpp)

Add a new settings option to the Options dialog

1. Define new configuration field in CommonData.h or a settings structure (TrafficMonitor/CommonData.h)
2. Add UI control (checkbox, dropdown, spinner) in OptionsDlg.cpp and link to data field (TrafficMonitor/OptionsDlg.cpp)
3. Implement save/load logic in BaseDialog.cpp or OptionsDlg.cpp to persist setting to config file (TrafficMonitor/BaseDialog.cpp)
4. Update main application logic in TrafficMonitor.cpp to respect new setting during monitoring and rendering (TrafficMonitor/TrafficMonitor.cpp)

Add a plugin to extend functionality

1. Create new .cpp/.h files in PluginDemo or new plugin directory following PluginDemo structure (PluginDemo/PluginDemo.cpp)
2. Implement DataManager to manage plugin state and data collection (PluginDemo/DataManager.cpp)
3. Create custom dialog if needed (e.g., OptionsDlg.cpp) for plugin configuration (PluginDemo/OptionsDlg.cpp)
4. Register plugin in main application load sequence to integrate with CommonData and UI pipeline (TrafficMonitor/TrafficMonitor.cpp)

• C++ MFC (Microsoft Foundation Classes) — Windows-native UI framework for rapid desktop application development with native look and feel; well-suited for system monitoring tools
• Direct2D (D2D1) — Hardware-accelerated 2D graphics for smooth, high-performance rendering of skins and animations in floating window and taskbar
• LibreHardwareMonitor.dll — Cross-platform hardware sensor abstraction for reliable CPU temperature and usage data without direct WMI/kernel access complexity
• Windows Taskbar Integration (Shell API) — Native OS integration for taskbar embedding, enabling always-visible compact monitoring in system taskbar
• Plugin System (DLL-based) — Extensibility mechanism allowing third-party developers to add custom metrics/displays without modifying core application

• MFC instead of modern UWP/WinUI

  • Why: MFC is mature, stable, and widely understood by Windows developers; UWP has sandboxing constraints unsuitable for low-level hardware monitoring
  • Consequence: Codebase feels legacy; no modern Fluent Design, but achieves 100% Windows version compatibility and minimal runtime dependencies

• Direct2D for rendering over GDI

  • Why: Direct2D offers hardware acceleration and superior animation performance for skin effects
  • Consequence: Requires Windows 7+ with graphics drivers; slightly higher CPU overhead during idle, but smoother visual experience

• Polling (WM_TIMER) instead of event-driven metrics collection

  • Why: Simpler implementation; network adapter stats are polled-only API anyway; consistent refresh cadence for UI
  • Consequence: Fixed refresh latency (~1s typical); not real-time, but adequate for monitoring use case

• Single-threaded UI with blocking hardware queries

  • Why: Avoids synchronization complexity; MFC message loop is inherently single-threaded
  • Consequence: Brief UI freezes during hardware query spikes; mitigated by fast hardware API calls (~50ms)

• Linux or macOS support (Windows-only via native APIs and MFC)
• Real-time kernel-level event notification (polling-based metrics only)
• Cloud sync or remote monitoring (local system monitoring only)
• High-frequency data logging (designed for live display, not data warehouse)
• Authentication or multi-user profiles (single-user desktop app)

Admin elevation requirement: Standard version fails silently on non-admin launch (no graceful fallback shown). OpenHardwareMonitor.dll versioning: LibreHardwareMonitorLib.dll/xml in OpenHardwareMonitorApi/ is a managed .NET assembly; C++ must use COM interop, not direct P/Invoke—mismatch breaks hardware queries. Taskbar integration: Windows 11 taskbar APIs differ from Windows 10; no version guards visible in file list. Plugin DLL loading: PluginDemo implies runtime DLL discovery; missing or malformed plugins likely crash silently. No visible config file parsing: Help.md and code structure suggest INI or registry storage for skin/settings; undocumented persistence layer.

• COM Interop — TrafficMonitor bridges unmanaged C++ and managed .NET (OpenHardwareMonitor.dll) via COM; understanding marshaling, reference counting, and HRESULT error handling is essential to debug or extend hardware sensor queries
• Win32 API Floating Window & Taskbar Integration — The core UI is a frameless floating window registered with the Windows taskbar notification area; requires WinEventHook, SetWindowPos, and WM_* message handling for drag, minimize, and tray interaction
• Visitor Pattern — UpdateVisitor.cpp implements the Visitor pattern to traverse a hardware sensor tree; understanding this design is critical to add new sensor types or optimize data collection
• DLL Plugin Architecture — PluginDemo demonstrates runtime DLL loading and interface contracts for plugins; essential for adding custom data sources without recompiling the main application
• WMI (Windows Management Instrumentation) — OpenHardwareMonitorImp likely uses WMI queries to detect hardware; understanding WMI classes (Win32_OperatingSystem, Win32_NetworkAdapterConfiguration) helps debug sensor detection failures
• Resource Files (.rc) and Localization — Help.md and Help_en-us.md existence alongside .rc resource files indicate UI strings, icons, and menu layouts are resource-compiled; modifying language strings requires RC editor or RC syntax knowledge
• Admin Elevation & UAC (User Account Control) — Standard version requires admin to access raw hardware sensors; Lite version avoids this—understanding requestedExecutionLevel in manifest files and fallback strategies is critical for cross-version deployment

• zhongyang219/TrafficMonitorPlugins — Official companion repo for extending TrafficMonitor with third-party hardware monitoring and custom data plugins; users must reference this to add features post-v1.86
• LibreHardwareMonitor/LibreHardwareMonitor — Source project for the OpenHardwareMonitor.dll dependency; if you need to add new sensor types or fix hardware detection bugs, patches upstream go here
• open-hardware-monitor/open-hardware-monitor — Original predecessor to LibreHardwareMonitor; historical context and alternative sensor APIs if LibreHardwareMonitor doesn't support your hardware
• obsproject/obs-studio — Comparable modular plugin architecture and skin system; good reference for extending TrafficMonitor's plugin API design patterns
• PortabilityChecker/PortabilityChecker — Another Windows system-monitoring float window; alternative architecture for comparison if considering refactoring TrafficMonitor's UI layer away from Win32

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.

Create comprehensive plugin development documentation and API reference

The repo contains PluginDemo/ with plugin infrastructure, but Help.md and Help_en-us.md lack specific plugin development guidelines. New contributors cannot easily understand the plugin API surface. This would reduce friction for third-party plugin developers and increase ecosystem adoption.

• [ ] Create Plugin_Development_Guide.md documenting the plugin interface exposed by TrafficMonitor
• [ ] Document the callback signatures and data structures used in PluginDemo/PluginSystemDate.cpp and PluginSystemTime.cpp
• [ ] Add code examples showing how to create a minimal plugin (similar to the date/time demos)
• [ ] Include build instructions specific to plugin development in the existing build system

Add cross-platform build and testing CI workflow for plugin compilation

.github/workflows/main.yml exists but the OpenHardwareMonitorApi/ and PluginDemo/ subprojects appear to need separate compilation verification. There's no visible CI ensuring plugins build successfully across releases, risking regressions in the plugin SDK.

• [ ] Extend .github/workflows/main.yml to compile OpenHardwareMonitorApi/OpenHardwareMonitorApi.vcxproj
• [ ] Add a separate job to verify PluginDemo/PluginDemo.vcxproj builds without errors
• [ ] Include a step to validate the LibreHardwareMonitorLib.dll dependency is correctly resolved
• [ ] Document in .github/workflows/main.yml what each build target tests

Consolidate and deduplicate skin/screenshot documentation across language variants

Screenshots/ contains both README.md-referenced images and Screenshots/en_us/ variants, plus Help.md and Help_en-us.md. There's no centralized index of available skins or visual documentation structure. This creates maintenance burden and unclear asset relationships.

• [ ] Create a skins_catalog.md that indexes all available skins with preview images (reference Screenshots/skins.PNG)
• [ ] Document the skin file format and directory structure for contributors wanting to submit new skins
• [ ] Create a symlink or reference system to eliminate duplication between Screenshots/ directories
• [ ] Update Help.md and Help_en-us.md to reference the centralized skin documentation instead of repeating information

• Add unit tests for OpenHardwareMonitorImp.cpp: The hardware abstraction layer has no visible test suite; create a mock IHardwareMonitor interface and test sensor value parsing and caching logic to catch WMI query regressions.
• Document the plugin API in code: PluginDemo/ exists but lacks inline API documentation; add Doxygen comments to DataManager.h and PluginDemo.h interfaces so external plugin developers don't reverse-engineer from example code.
• Implement graceful degradation for non-admin users in Standard version: Currently no fallback when Standard version runs without elevation; stub out temperature/frequency sensors to return 'N/A' and continue, or auto-recommend Lite version.

The TrafficMonitor codebase presents moderate security concerns, primarily centered around external binary dependencies (LibreHardwareMonitorLib.dll) without visible integrity verification, an unsandboxed plugin system, and missing modern hardening configurations. The application's need for elevated privileges to monitor system resources requires careful access control. While the core architecture appears reasonable for a system monitoring utility, the lack of dependency verification, plugin isolation, and security build flags are the main risk factors. Immediate priorities should be implementing DLL signature verification, sandboxing the plugin system, and enabling OS-level security hardening features in the build configuration.

• High · Use of External Hardware Monitoring Library — OpenHardwareMonitorApi/LibreHardwareMonitorLib.dll. The codebase includes LibreHardwareMonitorLib.dll, an external DLL dependency for hardware monitoring. This introduces potential risks: (1) the DLL source and build process are not visible in the repository, (2) no signature verification or integrity checks are apparent, (3) supply chain attack vector if the DLL is compromised, (4) potential privilege escalation risks from hardware access. Fix: Verify DLL integrity using cryptographic signatures, document the exact version and source, implement DLL whitelisting/code signing validation, consider open-source alternatives with audited code, or compile the library from source.
• Medium · Binary Dependencies Without Verification — OpenHardwareMonitorApi/. Pre-compiled binary DLL files are included in the repository without apparent integrity verification, version pinning in a manifest, or hash validation. This makes the codebase vulnerable to supply chain attacks and makes it difficult to audit the actual code being executed. Fix: Implement DLL signing and verification, maintain a SBOM (Software Bill of Materials), use dependency management tools, document exact versions and sources, and consider removing binaries from repo in favor of package managers or build scripts.
• Medium · Insufficient Access Control on System Resources — TrafficMonitor/ (application root). The application monitors CPU, memory, and network traffic, potentially requiring elevated privileges. No evidence of privilege escalation protections, capability restrictions, or UAC (User Account Control) handling is visible in the analyzed file structure. This could allow malicious actors to abuse the application for unauthorized system monitoring. Fix: Implement minimal privilege execution principles, use Windows capability restrictions, properly handle UAC prompts with clear user consent, document privilege requirements, and validate all system API calls for proper error handling.
• Medium · Plugin System Without Apparent Sandboxing — PluginDemo/. The PluginDemo directory shows a plugin architecture with DLL-based plugins. Without visible sandboxing or isolation mechanisms, malicious plugins could access arbitrary system resources, monitor sensitive data, or perform privilege escalation. Fix: Implement plugin sandboxing using AppContainers or similar OS-level isolation, validate and sign all plugins before loading, use capability-based security model for plugin permissions, implement runtime monitoring of plugin behavior, and provide clear plugin permissions UI to users.
• Low · Missing Security Headers and Hardening Configuration — OpenHardwareMonitorApi/OpenHardwareMonitorApi.vcxproj, PluginDemo/PluginDemo.vcxproj, TrafficMonitor/ (project files). No evidence of security hardening configurations such as ASLR (Address Space Layout Randomization), DEP (Data Execution Prevention), stack canaries, or control flow guard (CFG) enablement in the Visual Studio project files is visible. Fix: Enable /DYNAMICBASE (ASLR), /NXCOMPAT (DEP), /GS (buffer security check), /guard:cf (Control Flow Guard), and /SAFESEH flags in compiler settings. Use Code Analysis and SDL (Security Development Lifecycle) tools.
• Low · Resource Script Files Without Input Validation — OpenHardwareMonitorApi/app.rc, PluginDemo/PluginDemo.rc. RC (resource) files are present (.rc, .h files) which may contain hardcoded strings, icons, and dialogs. If these are manipulated or if resource loading doesn't validate integrity, it could lead to UI spoofing attacks. Fix: Validate resource integrity at runtime, use resource signing, implement UI element validation, and audit resource files for suspicious content during builds.

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.