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/emoacht/Monitorian 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 2w ago
• 4 active contributors
• MIT licensed
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ 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 emoacht/Monitorian repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/emoacht/Monitorian.

What it runs against: a local clone of emoacht/Monitorian — 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 emoacht/Monitorian | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 43 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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"

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

Monitorian is a Windows desktop application (WPF/C#) that adjusts brightness and contrast of multiple monitors simultaneously via DDC/CI protocol, including external monitors. It solves the problem of controlling non-built-in display settings without manufacturer utilities by directly communicating with monitor firmware. Modular WPF project structure: Source/Monitorian.Core contains platform-agnostic DDC/CI and monitor enumeration logic; Source/Monitorian.Wpf wraps the UI layer; Source/IconImage is a helper utility for rendering app icons; Source/Installer is WiX-based MSI packaging. Observable collections and MVVM patterns (BindableBase) enable real-time multi-monitor state binding.

Windows users with multiple monitors (especially external/USB displays) who need centralized brightness control, plus power users wanting keyboard shortcuts and ambient light sensor integration. Also relevant to accessibility users needing fine-grained display adjustment.

Mature and actively maintained: the codebase shows 581K lines of C# with a stable architecture across 6+ years of development. Presence of WiX installer, multi-language support (20+ locales), Microsoft Store distribution, and consistent folder structure (Core, Wpf projects) indicate production-ready status. Recent evidence of i18n maintenance suggests active stewardship.

Low to moderate risk: single maintainer (emoacht) creates bus factor concerns. No visible CI/CD pipeline files (.yml, Makefile) in the listed structure suggests manual builds/testing. Windows API surface (DDC/CI, WMI, Win32 interop) can be fragile across OS versions; .NET Framework 4.8 dependency (not Core) limits future modernization flexibility.

The visible file structure shows recent maintenance in multi-language support (20+ language files likely under Source/Monitorian.Wpf/Resources/) and UI refinement (contrast, range, unison mode screenshots dated ~2022). No active PR or issue data provided, but the presence of contrast adjustment and range customization features suggests iterative UI/UX work.

Clone the repo: git clone https://github.com/emoacht/Monitorian.git. Open Source/Monitorian.sln in Visual Studio 2019+ (requires .NET Framework 4.8 SDK). Restore NuGet packages via dotnet restore or Visual Studio's NuGet Package Manager. Build the solution; the main executable will appear in the bin folder.

Daily commands: In Visual Studio, set Monitorian.Wpf as startup project and press F5 (Debug). For release builds: dotnet build -c Release in Source/ directory. The WiX installer (Source/Installer/Installer.wixproj) can be built separately to create an MSI with dotnet build Source/Installer/Installer.wixproj.

• Source/Monitorian.Core/AppControllerCore.cs: Core orchestrator for monitor enumeration, brightness/contrast state management, and DDC/CI command execution — central to all brightness control logic
• Source/Monitorian.Core/Collections/ObservableDictionary.cs: Custom observable collection enabling real-time UI binding to multi-monitor state changes without heavy LINQ
• Source/Monitorian.Core/Common/BindableBase.cs: Base class implementing INotifyPropertyChanged for all ViewModels — critical to MVVM data binding throughout the app
• Source/Installer/Product.wxs: WiX source file defining MSI package structure, file layout, registry entries, and uninstall behavior for Windows installer
• Source/IconImage/: Dedicated utility project for rendering light/dark theme app icons at scale; decoupled from main app to enable icon generation without full UI framework
• Source/Directory.Build.props: Central MSBuild configuration for all projects (version, targets, common properties) — single point of truth for build settings

Adding monitor features: edit Source/Monitorian.Core/AppControllerCore.cs (core monitor management) and corresponding View/ViewModel in Source/Monitorian.Wpf/. UI changes: modify XAML in Source/Monitorian.Wpf/Views/ and update ViewModel properties in Source/Monitorian.Wpf/ViewModels/. Localization: add language-specific .resx files under Source/Monitorian.Wpf/Resources/ following existing locale patterns (ja-JP, de, fr, etc.). DDC/CI protocol tweaks: modify monitor communication layer in Source/Monitorian.Core/ (likely in a Monitor or DDCProxy class not listed in detail).

DDC/CI availability: not all monitors support DDC/CI; the app silently degrades on unsupported hardware. Enabling may require monitor OSD toggle (Dell example in Images/). Windows API permission: DDC/CI communication may fail on some Windows editions or with device filters; no graceful fallback in UI. .NET Framework 4.8 locked-in: upgrading to .NET 6+ would require WPF migration (still viable but non-trivial with all the WMI/Win32 interop). Multi-monitor detection: relies on WMI EDID parsing, which can be unreliable on USB-C, Thunderbolt, or virtual displays. Keyboard hook for shortcuts: if implemented in AppKeeper.cs, requires low-level Win32 hooks that conflict with UAC-elevated apps.

• DDC/CI (Display Data Channel/Command Interface) — Core protocol enabling Monitorian to communicate with monitor firmware for brightness/contrast adjustment; understanding its limitations (not all displays support it, timeout behavior, command format) is essential for debugging monitor detection failures
• MVVM (Model-View-ViewModel) Pattern — Fundamental architectural pattern used throughout the codebase (BindableBase, ObservableCollections); critical for understanding data flow between UI and monitor state management
• WMI (Windows Management Instrumentation) — Used for enumerating physical monitors and their EDID (Extended Display Identification Data); essential for understanding how Monitorian discovers connected displays on Windows
• EDID (Extended Display Identification Data) — Binary format embedded in monitors containing resolution, refresh rate, and DDC/CI capability flags; parsing EDID is how Monitorian detects which displays support brightness control
• INotifyPropertyChanged / Observable Collections — WPF binding mechanism enabling real-time UI updates when monitor brightness changes; understanding these interfaces is critical for adding new bindable properties or fixing UI sync issues
• Win32 API Interop (P/Invoke) — Direct calling of unmanaged Windows APIs (likely for DDC/CI I2C communication, window hooks in AppKeeper); requires careful marshaling and error handling for stability
• WiX Toolset (Windows Installer XML) — Used to package Monitorian as an MSI installer (Source/Installer/); understanding .wxs syntax is needed for modifying installation behavior, file associations, or registry entries

• emoacht/Wifinian — Companion utility by same author for WiFi management; shares same MVVM/WPF patterns and AppKeeper infrastructure as Monitorian
• ddccli/ddccli — Cross-platform CLI tool for DDC/CI monitor control; provides alternative reference implementation of DDC/CI protocol for interoperability testing
• sofaer/brightness-controller — Similar brightness control app (though less maintained); useful for understanding alternate WPF/Windows API approaches to multi-monitor brightness
• microsoft/WPF-Samples — Official Microsoft WPF samples covering MVVM, data binding, and async patterns — directly relevant to modernizing Monitorian's UI layer
• PeterWone/WindowsDisplayAPI — Managed C# wrapper around Windows Display Driver Model (WDDM); potential dependency for future monitor enumeration improvements over WMI

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 Monitor model classes (DdcMonitorItem, HdrMonitorItem, DisplayConfig)

The Source/Monitorian.Core/Models/Monitor directory contains critical classes for monitor detection and brightness control, but there's no visible test project in the file structure. This is a Windows interop-heavy codebase where DDC-CI communication and display configuration are error-prone. Unit tests would catch regressions in monitor enumeration, brightness value parsing, and EDID info extraction.

• [ ] Create Source/Monitorian.Core.Tests project (.xunit or .mstest)
• [ ] Add tests for DdcMonitorItem.cs covering brightness get/set operations
• [ ] Add tests for DisplayConfig.cs covering monitor enumeration logic
• [ ] Add tests for EdidInfo.cs parsing with various EDID data formats
• [ ] Add tests for DeviceConversion.cs coordinate and scaling calculations
• [ ] Update Directory.Build.props to include test project in solution

Document DDC-CI communication flow and troubleshooting in CONTRIBUTING.md

The repo handles hardware-level DDC-CI monitor control (evident from DdcMonitorItem.cs and Dell_ddcci.jpg in Images), but there's no CONTRIBUTING.md file. New contributors need guidance on how DDC-CI works in this codebase, common failure modes, and how to test against real hardware. This significantly lowers the barrier for contributors wanting to improve monitor detection or brightness control.

• [ ] Create CONTRIBUTING.md at repo root
• [ ] Document the DDC-CI communication flow referencing Source/Monitorian.Core/Models/Monitor/DdcMonitorItem.cs
• [ ] Add troubleshooting section for common monitor detection issues
• [ ] Document how to test changes against physical monitors or simulators
• [ ] Include setup instructions for building the WiX installer (Source/Installer/Installer.wixproj)
• [ ] Reference the display configuration pipeline: DisplayMonitorProvider.cs → DisplayInformationProvider.cs → DeviceContext.cs

Add GitHub Actions CI workflow for building and testing the WiX installer project

The repo includes a WiX installer project (Source/Installer/Installer.wixproj) but there's no visible CI configuration. Building the installer requires WiX toolset setup and is platform-specific (Windows-only). A CI workflow would catch installer configuration regressions early and ensure release artifacts are built consistently. This is critical for a tool distributed as an installer.

• [ ] Create .github/workflows/build-installer.yml
• [ ] Add steps to install WiX toolset (wixtoolset or similar action)
• [ ] Add MSBuild step to build Source/Installer/Installer.wixproj
• [ ] Add step to build Source/Monitorian.Core and associated projects first (dependency)
• [ ] Configure artifact upload for the generated .msi file
• [ ] Add conditional triggers (on: push to main, pull_request, manual dispatch)

• Add unit tests for Source/Monitorian.Core/Helper/ArraySearch.cs and other Helper utilities — currently no visible test projects (.csproj) in the repo structure, a significant gap for a stable tool
• Document the DDC/CI protocol implementation details in a README or wiki page under Source/Monitorian.Core/; currently the exact monitor communication code is not visible in the file list and lacks inline guidance
• Add a troubleshooting guide for common DDC/CI failures (monitor not detected, brightness stuck, driver conflicts) — the main README mentions DDC/CI requirement but has no how-to-enable section for each major monitor vendor

Monitorian is a desktop brightness control utility with a reasonably secure architecture. Primary concerns include: (1) Windows API interop safety - requires careful review of P/Invoke declarations and pointer operations, (2) Input validation on sensor data and serialized settings, (3) Missing dependency vulnerability scan data. No hardcoded credentials, SQL injection risks, XSS vulnerabilities, or infrastructure issues were identified. The application uses standard Windows desktop patterns and XAML/WPF which are generally safe. Recommendation: Perform code review of Monitor-related Windows API calls, implement comprehensive input validation throughout, run SAST tools (e.g., Roslyn analyzers), and maintain dependency updates.

• Medium · Potential Unsafe Windows API Interop — Source/Monitorian.Core/Models/Monitor/*.cs (DeviceContext.cs, DisplayConfig.cs, MonitorConfiguration.cs, PowerManagement.cs). The codebase contains multiple Monitor and Device-related files that likely use P/Invoke and Windows API calls (DeviceContext, DisplayConfig, MonitorConfiguration, PowerManagement). Windows API interop can be vulnerable to unsafe pointer operations and incorrect marshaling if not properly validated. Fix: Review all P/Invoke declarations for correct marshaling attributes, validate all pointer operations, use SafeHandle wrappers where applicable, and ensure proper bounds checking on arrays passed to unmanaged code.
• Medium · Unvalidated Serialization/Deserialization — Source/Monitorian.Core/Helper/SimpleSerialization.cs. The SimpleSerialization.cs helper class appears to handle serialization of settings. Without code inspection, there's risk of insecure deserialization if user-controlled data is processed without validation. Fix: Implement strict input validation before deserialization, use only safe serialization formats, avoid deserializing untrusted data, and consider using type-safe serialization methods.
• Medium · Sensor Data Without Validation — Source/Monitorian.Core/Models/Sensor/LightSensor.cs. The LightSensor.cs component processes sensor input data which could be manipulated or contain unexpected values if the sensor interface is not properly validated. Fix: Add comprehensive input validation for all sensor readings, implement range checks, add error handling for sensor failures, and log suspicious sensor values.
• Low · Missing Dependency Information — Project-wide / NuGet dependencies. No package dependency file (packages.config, .csproj with package references, or packages.lock.json) was provided for analysis. This prevents verification of known vulnerabilities in third-party dependencies. Fix: Provide complete dependency manifest files and run regular vulnerability scans using tools like OWASP Dependency-Check, Snyk, or built-in NuGet security audit tools. Keep all dependencies updated.
• Low · No Visible Authentication/Authorization — Source/Monitorian.Core/AppControllerCore.cs, Source/Monitorian.Core/AppKeeper.cs. While this is a desktop application, there's no visible authentication mechanism. If multiple users access the system, there could be privilege escalation concerns. Fix: Implement per-user settings isolation, consider OS-level privilege checks if administrative operations are required, and validate user permissions before critical operations.
• Low · Logger Implementation Security — Source/Monitorian.Core/Models/Logger.cs. The Logger.cs component may log sensitive information (monitor settings, sensor data) without sanitization or access controls. Fix: Ensure logs do not contain sensitive data, implement proper log file permissions (restrict to owner only), consider log rotation, and sanitize user-provided input before logging.

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.