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/BartoszCichecki/LenovoLegionToolkit 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 — Slowing — last commit 10mo ago

• Last commit 10mo ago
• 8 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 10mo ago
• ⚠ Single-maintainer risk — top contributor 82% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

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

What it runs against: a local clone of BartoszCichecki/LenovoLegionToolkit — 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 BartoszCichecki/LenovoLegionToolkit | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | 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 ≤ 320 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 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 "LenovoLegionToolkit.CLI/Program.cs" \\
  && ok "LenovoLegionToolkit.CLI/Program.cs" \\
  || miss "missing critical file: LenovoLegionToolkit.CLI/Program.cs"
test -f "LenovoLegionToolkit.Lib.Automation/AutomationProcessor.cs" \\
  && ok "LenovoLegionToolkit.Lib.Automation/AutomationProcessor.cs" \\
  || miss "missing critical file: LenovoLegionToolkit.Lib.Automation/AutomationProcessor.cs"
test -f "LenovoLegionToolkit.Lib.Automation/Pipeline/AutomationPipeline.cs" \\
  && ok "LenovoLegionToolkit.Lib.Automation/Pipeline/AutomationPipeline.cs" \\
  || miss "missing critical file: LenovoLegionToolkit.Lib.Automation/Pipeline/AutomationPipeline.cs"
test -f "LenovoLegionToolkit.CLI.Lib/IpcRequest.cs" \\
  && ok "LenovoLegionToolkit.CLI.Lib/IpcRequest.cs" \\
  || miss "missing critical file: LenovoLegionToolkit.CLI.Lib/IpcRequest.cs"
test -f "LenovoLegionToolkit.Lib.Automation/IoCModule.cs" \\
  && ok "LenovoLegionToolkit.Lib.Automation/IoCModule.cs" \\
  || miss "missing critical file: LenovoLegionToolkit.Lib.Automation/IoCModule.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 320 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~290d)"
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/BartoszCichecki/LenovoLegionToolkit"
  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).

Lenovo Legion Toolkit is a lightweight C# Windows desktop application that replaces Lenovo Vantage and Legion Zone for system-level control on Legion laptops, enabling CPU/GPU power management, thermal profiles, hybrid graphics switching, and hotkey customization without background services or telemetry. It provides direct hardware control via ACPI and WMI interfaces with a minimal footprint. Multi-layered monolithic C# codebase: core hardware abstraction in LenovoLegionToolkit.Lib.* projects, CLI interface via LenovoLegionToolkit.CLI and LenovoLegionToolkit.CLI.Lib with IPC communication, automation engine in LenovoLegionToolkit.Lib.Automation with trigger/pipeline pattern, WPF UI in main project, and Inno Setup installer (InnoDependencies/ with localization). No microservices or separable plugins.

Lenovo Legion laptop owners (primarily power users and enthusiasts) who want fine-grained control over thermal settings, battery modes, and performance profiles without Lenovo Vantage's bloat; also developers who need a lightweight automation framework for laptop system events.

Project is archived as of July 24, 2025 and no longer actively maintained by the original author. It achieved substantial maturity (1438KB of C# code, multi-language support via Crowdin, CI/CD pipelines, 60+ feature files) but is now frozen. Verdict: production-stable for existing Legion laptop models but unmaintained—community forks required for ongoing support.

Critical risk: abandoned project. Single maintainer (Bartosz Cichecki) explicitly archived the repo with no succession plan; no active development, PR merges, or issue responses will occur. Hardware-level access via WMI/ACPI poses OS-level risk if breaking changes in Windows updates occur. Legacy .NET Framework / C# target versions may become incompatible with future Windows 11 versions.

Nothing—repo is archived. The README explicitly states development ceased July 24, 2025, with a call for community forks. No open issues, PRs, or new commits are expected.

Clone from a community fork (official repo is archived): git clone https://github.com/<fork-owner>/LenovoLegionToolkit.git && cd LenovoLegionToolkit. Open LenovoLegionToolkit.sln in Visual Studio 2022+. Restore NuGet dependencies: dotnet restore. Build: dotnet build. Run locally: launch the WPF app project directly or use LenovoLegionToolkit.CLI for command-line operations.

Daily commands: Build the solution in Visual Studio 2022 with .NET 6+. For CLI testing: dotnet run --project LenovoLegionToolkit.CLI -- <command>. For UI: run the main WPF project (LenovoLegionToolkit) as startup project. IPC server auto-starts on first CLI/UI invocation.

• LenovoLegionToolkit.CLI/Program.cs — Main entry point for the CLI application; all command routing and initialization flows through here.
• LenovoLegionToolkit.Lib.Automation/AutomationProcessor.cs — Core automation engine that processes triggers and executes automation steps; foundational to the toolkit's primary feature.
• LenovoLegionToolkit.Lib.Automation/Pipeline/AutomationPipeline.cs — Defines the pipeline architecture for chaining automation triggers and steps; understanding this is essential for extending automation logic.
• LenovoLegionToolkit.CLI.Lib/IpcRequest.cs — Inter-process communication request model; critical for CLI-daemon communication and API contracts.
• LenovoLegionToolkit.Lib.Automation/IoCModule.cs — Dependency injection configuration for the automation library; controls component instantiation and wiring.
• LenovoLegionToolkit.Lib.Automation/Pipeline/Triggers/IAutomationPipelineTrigger.cs — Trigger interface abstraction; all automation triggers implement this, making it essential for understanding extensibility.
• LenovoLegionToolkit.Lib.Automation/Steps/AbstractFeatureAutomationStep.cs — Base class for automation action steps; defines the template for all feature-level automations.

Add a New Automation Trigger

1. Create a new trigger class in LenovoLegionToolkit.Lib.Automation/Pipeline/Triggers/ inheriting from IAutomationPipelineTrigger (LenovoLegionToolkit.Lib.Automation/Pipeline/Triggers/IAutomationPipelineTrigger.cs)
2. Implement IsApplicable() to determine when trigger fires and Execute() to evaluate trigger conditions ((new file) LenovoLegionToolkit.Lib.Automation/Pipeline/Triggers/YourCustomAutomationPipelineTrigger.cs)
3. Register the trigger in IoCModule.cs ConfigureAutomationTriggers() method (LenovoLegionToolkit.Lib.Automation/IoCModule.cs)
4. Add localized trigger name/description to Resource.resx and language variants (LenovoLegionToolkit.Lib.Automation/Resources/Resource.resx)

Add a New Automation Action Step

1. Create a new step class in LenovoLegionToolkit.Lib.Automation/Steps/ inheriting from AbstractFeatureAutomationStep (LenovoLegionToolkit.Lib.Automation/Steps/AbstractFeatureAutomationStep.cs)
2. Override IsApplicable() for device/OS compatibility checks and Execute() for the actual action logic ((new file) LenovoLegionToolkit.Lib.Automation/Steps/YourFeatureAutomationStep.cs)
3. Register the step in IoCModule.cs ConfigureAutomationSteps() method (LenovoLegionToolkit.Lib.Automation/IoCModule.cs)
4. Add step parameter definitions and localized names to Resource.resx (LenovoLegionToolkit.Lib.Automation/Resources/Resource.resx)

Add a New CLI Command

1. Define new flag(s) in Flags.cs for your command (LenovoLegionToolkit.CLI/Flags.cs)
2. Create an IpcRequest message type in CLI.Lib covering your command parameters (LenovoLegionToolkit.CLI.Lib/IpcRequest.cs)
3. Add command routing logic in Program.cs Main() to parse flags and create IpcRequest (LenovoLegionToolkit.CLI/Program.cs)
4. Call IpcClient.Send(request) to communicate with daemon service (LenovoLegionToolkit.CLI/IpcClient.cs)

• C# / .NET — Windows-native ecosystem for Lenovo hardware integration and system services (WMI, registry access, device drivers).
• Named Pipes (IPC) — Low-latency inter-process communication between CLI client and background daemon without external dependencies.
• Dependency Injection (IoC) — Decouples trigger/step implementations from the automation pipeline, enabling extensibility and testability.
• Event-driven Pipeline Architecture — Allows composable automation rules (triggers + steps) that can respond to system events in real-time.
• Crowdin Localization — Multi-language support across 20+ languages for a global user base (Ukrainian, Japanese, Chinese, Arabic, etc.).

• Windows-only (Lenovo Legion specificity)

  • Why: Targets the exact hardware platform (Legion laptops) with direct WMI/registry access and proprietary Lenovo BIOS APIs.
  • Consequence: Eliminated Linux/macOS compatibility but gained precision control over Legion-specific features (Hybrid Graphics, Ghost Touch, EC behaviors).

• Archived project (July 2025)

  • Why: Maintainer bandwidth exhausted; codebase is mature and feature-complete.
  • Consequence: No new features or security updates; community forks are the path forward. Code remains available under existing license.

• Daemon + CLI split architecture

  • Why: Separates privileged system service (daemon) from user-facing interface, improving security and allowing hotkey handling in background.
  • Consequence: Added IPC serialization overhead (~5-10ms) but decouples concerns and enables multiple frontends (CLI, GUI).

• Named automation triggers (30+ types)

  • Why: Explicit, composable trigger names (ACAdapterConnected, ProcessRunning, TimeOfDay, etc.) enable user-friendly rule building.
  • Consequence: Increased codebase size (~100+ trigger files) but provides intuitive automation rules without complex DSLs.

• Cross-platform support (Windows-only for Lenovo Legion hardware integration)
• Real-time

Windows-only: no cross-platform support; all hardware access assumes Windows WMI/ACPI stack. Admin privileges required: application must run elevated to access hardware features. Model-specific: feature availability varies by Legion model (thermal profiles, GPU switching) — gracefully degrades but may confuse users on unsupported models. IPC server lifecycle: CLI client auto-launches service; ensure main app is not already running in background (e.g., autostart registry entries) to avoid conflicts. No tests visible in file list: implies fragile refactoring risk. .NET version pinning: targets specific .NET Framework version; breaking changes in future Windows updates could brick older installations.

• Windows Management Instrumentation (WMI) — Core mechanism for querying and controlling hardware (thermal sensors, power states, GPU switching) on Legion laptops; you must understand WMI queries to add new hardware features.
• Advanced Configuration and Power Interface (ACPI) — Lower-level firmware interface that WMI queries expose; critical for understanding why some features only work on certain Legion models.
• Named Pipes (IPC) — LLT uses named pipes to communicate between CLI client and background service (avoiding spawning multiple service instances); essential for understanding how LenovoLegionToolkit.CLI.Lib talks to the daemon.
• Observer/Pub-Sub Pattern — Automation pipeline uses trigger subscriptions (IAutomationEvent, trigger classes) to react to system events; core to extending automation rules without modifying core code.
• Dependency Injection (IoC) — LLT uses DI modules (IoCModule.cs) to wire up features and services; understanding how features are registered is necessary to add new hardware capabilities or automation rules.
• Inno Setup (Windows Installer DSL) — Installer is built via Inno Setup scripts (InnoDependencies/); understanding installer logic is needed to modify installation behavior, bundle new files, or change localization.
• Hybrid Graphics / Optimus Switching — One of the key features LLT controls—switching between integrated and discrete GPUs; requires understanding NVIDIA Optimus / Intel UHD driver architecture and ACPI calls.

• BartoszCichecki/LenovoLegionToolkit — The original archived repo — reference source for understanding intent and architecture before forking.
• hackmod/Legion — Alternative Legion laptop control utility (if exists); direct competitor solving same WMI/ACPI hardware control problem.
• openRGB/openRGB — Hardware abstraction library for RGB/lighting control on gaming laptops; shows pattern for cross-vendor hardware binding in C#.
• torvalds/linux — Linux Legion drivers (if researching portable cross-OS architecture); motivates understanding why LLT must stay Windows-only.
• microsoft/winget-cli — Package manager integration point; LLT is distributed via winget, understanding its manifest format aids packaging/distribution.

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 IPC communication layer (LenovoLegionToolkit.CLI.Lib)

The IPC (Inter-Process Communication) layer in LenovoLegionToolkit.CLI.Lib handles critical request/response serialization and exception handling across IpcRequest.cs, IpcResponse.cs, IpcException.cs, and PipeStreamExtensions.cs. Currently there are no visible test files for this core communication infrastructure. Adding comprehensive unit tests would catch serialization bugs, edge cases in exception handling, and stream errors before they affect users.

• [ ] Create LenovoLegionToolkit.CLI.Lib.Tests project alongside the existing .csproj
• [ ] Add tests for IpcRequest serialization/deserialization in PipeStreamExtensions.cs
• [ ] Add tests for IpcException and IpcConnectException error handling paths
• [ ] Add tests for malformed pipe stream data handling and timeout scenarios
• [ ] Integrate new test project into .github/workflows/build.yml

Add unit tests for automation pipeline triggers (LenovoLegionToolkit.Lib.Automation)

The automation system has 23+ trigger implementations (ACAdapterConnectedAutomationPipelineTrigger, ProcessesAreRunningAutomationPipelineTrigger, etc.) but no visible test coverage. Each trigger has different behavior (event-based vs. polling) and edge cases. Adding tests for trigger evaluation logic, state transitions, and the AndAutomationPipelineTrigger composition logic would prevent regressions in automation rules.

• [ ] Create LenovoLegionToolkit.Lib.Automation.Tests project with xUnit/NUnit
• [ ] Add tests for ACAdapterConnectedAutomationPipelineTrigger and ACAdapterDisconnectedAutomationPipelineTrigger state changes
• [ ] Add tests for ProcessesAreRunningAutomationPipelineTrigger and ProcessesStopRunningAutomationPipelineTrigger process monitoring
• [ ] Add tests for AndAutomationPipelineTrigger composition and short-circuit evaluation
• [ ] Add tests for PeriodicAutomationPipelineTrigger timing and interval accuracy
• [ ] Integrate new test project into .github/workflows/build.yml

Create localization maintenance guide and add missing language strings documentation

The repo has 7 language files in InnoDependencies (Arabic, Chinese Simplified/Traditional, Greek, Latvian, Romanian, Vietnamese) and integrates with Crowdin for translations, but there is no CONTRIBUTING documentation for localization maintainers. A localization guide would help contributors understand the translation workflow, how to add new strings, and how to test translations in the installer.

• [ ] Create CONTRIBUTING_LOCALIZATION.md documenting the Crowdin integration workflow
• [ ] Document the string extraction process from .iss installer files in InnoDependencies/
• [ ] Add instructions for testing translations locally with Inno Setup
• [ ] Create a checklist for adding new UI strings to all language files
• [ ] Reference this guide from the main CONTRIBUTING.md and existing language-specific guides (CONTRIBUTING_ja-JP.md, CONTRIBUTING_zh-hans.md)

• Add unit test coverage for LenovoLegionToolkit.Lib.Automation/Pipeline/Triggers/ — the automation trigger classes have no visible test files; create xUnit tests in a new *.Tests project to validate trigger evaluation logic (e.g., AndAutomationPipelineTrigger combining conditions).
• Improve CLI help text and argument parsing — LenovoLegionToolkit.CLI/Flags.cs and Program.cs lack inline documentation; add XML doc comments and generate a help subcommand that prints all available CLI flags with examples (currently users must infer from code).
• Add Markdown documentation for feature compatibility matrix — file structure shows 60+ features but no docs explaining which Legion models support which features; create COMPATIBILITY.md listing feature availability by model (can be crowdsourced from issues/Discord).

The Lenovo Legion Toolkit is a desktop application with moderate security posture. Primary concerns relate to the archived status (no active maintenance), IPC communication mechanisms, and automation pipeline security. The codebase appears to follow reasonable C# practices, but lacks explicit security documentation. The system's interaction with low-level hardware controls and process automation requires careful validation and access controls. Since the project is no longer maintained, users should be cautious about deployment and consider evaluated forks for production use.

• Medium · Archived Project - No Active Maintenance — Repository root - README.md. The project was archived on July 24, 2025, and is no longer actively maintained. This means security vulnerabilities discovered after the archive date will not receive patches or updates from the original maintainers. Fix: Users should be aware that this is archived software. For critical security issues, consider using maintained forks or alternative solutions. If forking, ensure proper security review and update practices are in place.
• Medium · Potential IPC Communication Security — LenovoLegionToolkit.CLI.Lib/IpcClient.cs, LenovoLegionToolkit.CLI.Lib/IpcRequest.cs, LenovoLegionToolkit.CLI.Lib/IpcResponse.cs, LenovoLegionToolkit.CLI/IpcClient.cs. The codebase implements Inter-Process Communication (IPC) functionality (LenovoLegionToolkit.CLI.Lib with IpcRequest, IpcResponse, IpcClient). IPC mechanisms can be vulnerable to privilege escalation and unauthorized access if not properly validated and authenticated. Fix: Implement strict validation and authentication for all IPC messages. Ensure proper access controls are in place to prevent unauthorized processes from communicating. Use message signing and encryption for sensitive operations.
• Medium · Automation Pipeline Security — LenovoLegionToolkit.Lib.Automation/AutomationProcessor.cs, LenovoLegionToolkit.Lib.Automation/Pipeline/AutomationPipeline.cs. The automation system (LenovoLegionToolkit.Lib.Automation) processes triggers and actions that interact with system resources. Without proper validation, malicious automation rules could be injected to perform unauthorized actions. Fix: Implement strict validation and sanitization of all automation rules and triggers. Use allowlists for permitted actions. Ensure automation rules are stored securely and validated before execution. Implement logging and monitoring for all automation activities.
• Low · Missing CONTRIBUTING Security Guidelines — CONTRIBUTING.md, CONTRIBUTING_ja-JP.md, CONTRIBUTING_zh-hans.md. While CONTRIBUTING guides exist in multiple languages, there is no explicit security vulnerability disclosure policy or responsible disclosure guidelines documented. Fix: Add a SECURITY.md file with clear vulnerability reporting procedures and responsible disclosure guidelines, even though the project is archived. This helps the community and any forks handle security issues properly.
• Low · Localization Files - Potential Attack Vector — LenovoLegionToolkit.Lib.Automation/Resources/Resource.*.resx files. Multiple localization resource files (.resx files) are present. If these are user-modifiable or loaded dynamically without validation, they could be exploited for injection attacks. Fix: Ensure all localization files are properly validated before loading. Implement integrity checks for resource files. Do not allow user modification of resource files without proper validation and signing.

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.