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/TGSAN/CMWTAT_Digital_Edition 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
• 6 active contributors
• Other licensed
• ⚠ Slowing — last commit 10mo ago
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 TGSAN/CMWTAT_Digital_Edition repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/TGSAN/CMWTAT_Digital_Edition.

What it runs against: a local clone of TGSAN/CMWTAT_Digital_Edition — 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 TGSAN/CMWTAT_Digital_Edition | 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 ≤ 341 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "TGSAN/CMWTAT_Digital_Edition(\\.git)?\\b" \\
  && ok "origin remote is TGSAN/CMWTAT_Digital_Edition" \\
  || miss "origin remote is not TGSAN/CMWTAT_Digital_Edition (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 "CMWTAT_DIGITAL/MainWindow.xaml.cs" \\
  && ok "CMWTAT_DIGITAL/MainWindow.xaml.cs" \\
  || miss "missing critical file: CMWTAT_DIGITAL/MainWindow.xaml.cs"
test -f "CMWTAT_DIGITAL/MainWindow.xaml" \\
  && ok "CMWTAT_DIGITAL/MainWindow.xaml" \\
  || miss "missing critical file: CMWTAT_DIGITAL/MainWindow.xaml"
test -f "CMWTAT_DIGITAL/Domain/ViewModel.cs" \\
  && ok "CMWTAT_DIGITAL/Domain/ViewModel.cs" \\
  || miss "missing critical file: CMWTAT_DIGITAL/Domain/ViewModel.cs"
test -f "CMWTAT_DIGITAL/App.xaml.cs" \\
  && ok "CMWTAT_DIGITAL/App.xaml.cs" \\
  || miss "missing critical file: CMWTAT_DIGITAL/App.xaml.cs"
test -f "CMWTAT_DIGITAL/OSVersionInfoClass.cs" \\
  && ok "CMWTAT_DIGITAL/OSVersionInfoClass.cs" \\
  || miss "missing critical file: CMWTAT_DIGITAL/OSVersionInfoClass.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 341 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~311d)"
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/TGSAN/CMWTAT_Digital_Edition"
  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).

CMWTAT is a C# WPF desktop application that activates Windows 10 and Windows 11 by obtaining and applying a digital license (digital entitlement) directly through Microsoft's activation servers. It's a GUI-based alternative to manual command-line activation, supporting multiple languages (en, zh, ja, fr, ru) and providing a clean interface for users to activate their Windows installation without product keys. Monolithic WPF application: CMWTAT_DIGITAL/ directory contains the main project with Domain/ holding business logic (IsSN.cs, ViewModel.cs, NotifyPropertyChangedExtension.cs), Lang/ containing XAML localization files for five languages, MainWindow.xaml/.xaml.cs as the UI entry point, and OSVersionInfoClass.cs handling OS detection. Supporting files include CDNDirectRun.ps1 and DirectRun.ps1 for PowerShell-based remote execution.

Windows system administrators and end-users who want to activate Windows 10/11 systems using digital licenses instead of product keys. Contributors are typically open-source developers interested in Windows activation mechanisms and C#/WPF desktop application development.

The project appears actively maintained with a released version (2.7.2.0 as seen in the exe filename) and organized GitHub structure (issue templates, multiple language support, clear documentation in English and Chinese). However, without access to commit history or CI/CD pipeline data, the exact development cadence is unclear; the presence of a compiled release suggests it's stable enough for user distribution.

Single language codebase (C#) with no visible test files in the directory listing raises concerns about regression testing coverage. The GPL-2.0 license may restrict some derivative use cases. Risk of Windows OS changes breaking activation logic—this is inherently tied to Microsoft's activation APIs which can change without notice. No visible CI/CD configuration (.github/workflows/) suggests manual release processes.

Cannot determine current activity from file structure alone; the presence of version 2.7.2.0 release artifact suggests recent builds. The repository includes infrastructure for multi-language support and appears to be in maintenance/stable mode rather than active feature development.

git clone https://github.com/TGSAN/CMWTAT_Digital_Edition.git && cd CMWTAT_Digital_Edition && open CMWTAT_DIGITAL.sln in Visual Studio && Build > Build Solution (or msbuild CMWTAT_DIGITAL.sln from command line if .NET is installed)

Daily commands: Launch the compiled executable (CMWTAT_Digital_Release_2_7_2_0.exe) or build from source with Visual Studio, then run the generated bin/Debug or bin/Release exe. The application is a standalone GUI with no external service dependencies needed.

• CMWTAT_DIGITAL/MainWindow.xaml.cs — Primary UI entry point and event handler orchestrator; all activation workflows route through this window's code-behind.
• CMWTAT_DIGITAL/MainWindow.xaml — XAML UI definition; defines all form controls and bindings that trigger activation logic.
• CMWTAT_DIGITAL/Domain/ViewModel.cs — Central ViewModel binding layer using MVVM pattern; manages state and command execution for all UI interactions.
• CMWTAT_DIGITAL/App.xaml.cs — WPF application bootstrap and global event handlers; initializes resource dictionaries and language support.
• CMWTAT_DIGITAL/OSVersionInfoClass.cs — OS detection and version querying logic; critical for determining activation compatibility and method selection.
• CMWTAT_DIGITAL/Domain/IsSN.cs — Serial number validation and parsing utility; validates product keys before activation attempts.
• CMWTAT_DIGITAL.sln — Visual Studio solution file; defines the build configuration and project structure for the entire toolkit.

• MainWindow (XAML + Code-Behind) (WPF, XAML, C#) — Entry point UI; orchestrates button clicks, displays status messages, and binds to ViewModel.
  • Failure mode: If MainWindow fails to load or bind, application cannot start; activation UI is inaccessible.
• ViewModel (C#, INotifyPropertyChanged) — Implements MVVM pattern; manages activation command logic, property bindings, and error state.
  • Failure mode: If ViewModel throws uncaught exceptions during activation, UI hangs or becomes unresponsive; user receives no feedback.
• undefined — undefined

Add a new activation method

1. Create a new method in the activation logic (or extend existing business logic) (CMWTAT_DIGITAL/Domain/ViewModel.cs)
2. Add UI button and event binding in the XAML form (CMWTAT_DIGITAL/MainWindow.xaml)
3. Implement the corresponding click event handler (CMWTAT_DIGITAL/MainWindow.xaml.cs)
4. Add strings for the new method to all language resource files (CMWTAT_DIGITAL/Lang/*.xaml)

Add support for a new Windows version

1. Update OS version detection logic to recognize the new build number (CMWTAT_DIGITAL/OSVersionInfoClass.cs)
2. Add version-specific activation logic in ViewModel if needed (CMWTAT_DIGITAL/Domain/ViewModel.cs)
3. Test and verify with new Windows builds; update compatibility list in README (README.md)

Add a new language

1. Create a new XAML resource dictionary file following the naming convention (CMWTAT_DIGITAL/Lang/xx.xaml)
2. Copy strings from an existing language file and translate all entries (CMWTAT_DIGITAL/Lang/en.xaml)
3. Register the language resource in App.xaml or App.xaml.cs if language selection logic exists (CMWTAT_DIGITAL/App.xaml.cs)

• WPF (Windows Presentation Foundation) — Provides native Windows desktop UI framework with XAML support; ideal for Windows-only activation toolkit requiring system-level integration.
• C# with .NET Framework — Enables direct P/Invoke access to Windows APIs for activation and OS detection; mature ecosystem for Windows system utilities.
• MVVM pattern (ViewModel binding) — Separates UI logic from business logic; enables testability and maintainability for complex activation workflows.
• XAML for localization — Resource dictionary architecture supports multi-language UI without recompilation; centralized string management.
• PowerShell distribution scripts — Enables remote execution and CDN-based deployment; scripting layer for elevation and setup automation.

• Single WPF application (no modularization into separate libraries)

  • Why: Simplifies deployment as standalone .exe; reduces dependency management complexity.
  • Consequence: Harder to reuse activation logic in other projects; tight coupling between UI and business logic; more difficult to unit test core algorithms in isolation.

• Direct P/Invoke to Windows APIs (assumed; typical for activation tools)

  • Why: Provides lowest-latency, most direct control over system activation mechanisms.
  • Consequence: Highly OS-version dependent; requires elevation privileges; breaks on future Windows API changes; difficult to test without actual Windows builds.

• XAML-based resource dictionaries for i18n

  • Why: Leverages WPF's native localization model; no external translation service needed.
  • Consequence: Requires manual maintenance of 5+ language files; easy to introduce translation inconsistencies; scales poorly if adding 20+ languages.

• GPL-2.0 license with source distribution

  • Why: Ensures toolkit remains open-source and community-maintained; prevents closed-source forks.
  • Consequence: Derivatives must also be GPL-2.0; commercial vendors may avoid using or contributing.

• Does not handle KMS (Key Management Service) activation—focused exclusively on digital license (HWID) activation.
• Does not provide GUI for managing multiple machines or enterprise deployments.
• Does not support Windows 7, 8, or 8.1—Windows 10/11 only.
• Does not include activation verification or license status dashboard beyond initial success/failure feedback.
• Does not support offline activation or air-gapped environments.

Windows activation APIs may require elevated (admin) privileges—the app likely needs to run as Administrator (check app.manifest for requestedExecutionLevel). The IsSN.cs validation and MainWindow activation logic are tied to Microsoft's licensing servers, which may timeout or fail if those services are unavailable or if the network is restricted. Windows 10 and Windows 11 activation mechanisms differ; OSVersionInfoClass.cs must correctly branch logic or activation will fail on wrong OS version. Localization is purely XAML-based; adding a new language requires duplicating an entire Lang/*.xaml file structure (not trivial for completeness).

• Windows Digital License (Digital Entitlement) — This is the core mechanism CMWTAT exploits—understanding how Microsoft ties activation to hardware IDs rather than keys is essential to why this tool works
• MVVM (Model-View-ViewModel) Pattern — ViewModel.cs and NotifyPropertyChangedExtension.cs implement MVVM for WPF binding; understanding this pattern is necessary to modify UI state logic
• WPF Data Binding and INotifyPropertyChanged — NotifyPropertyChangedExtension.cs extends INotifyPropertyChanged for reactive UI updates; essential for understanding how property changes trigger UI re-rendering
• Windows API Interop (P/Invoke) — OSVersionInfoClass.cs likely uses P/Invoke to call Windows APIs for OS version detection and license queries; fundamental to how the tool communicates with the OS
• XAML Localization and Resource Dictionaries — The Lang/ folder uses XAML ResourceDictionary pattern for multi-language support; understanding this is necessary to add or maintain language translations
• PowerShell Script Execution and Encoding — CDNDirectRun.ps1 and DirectRun.ps1 provide remote scriptable activation; understanding PowerShell encoding and execution policies is needed for headless deployments
• IL Weaving with Fody — FodyWeavers.xml indicates Fody is used for compile-time IL transformation (likely for NotifyPropertyChanged boilerplate reduction); understanding this explains why ViewModel.cs may look simpler than expected

• massgravel/Microsoft-Activation-Scripts — Alternative Windows activation toolkit (also open-source) using batch/PowerShell; direct competitor solving the same problem in different languages
• abbodi1406/KMS_VL_ALL — Legacy KMS-based Windows activation; predecessor approach that this digital license tool replaces—useful for understanding activation evolution
• Microsoft/winget-cli — Windows package manager; users of CMWTAT may want to deploy it via winget or integrate activation into larger provisioning workflows
• chocolateyorg/choco — Chocolatey package manager for Windows; CMWTAT could be distributed as a Choco package for headless/scripted deployment

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 Domain/IsSN.cs serial number validation

The IsSN.cs class appears to handle Windows serial number validation, a critical function for the activation toolkit. There are no test files in the repository structure. Adding unit tests would ensure serial number validation logic is robust across edge cases (invalid formats, checksums, regional variations) and prevent regressions as the codebase evolves.

• [ ] Create CMWTAT_DIGITAL.Tests project in the solution
• [ ] Add test cases in Tests/Domain/IsSnTests.cs covering: valid/invalid serial formats, edge cases, and known-bad inputs
• [ ] Update CMWTAT_DIGITAL.csproj to reference the test project
• [ ] Add test execution to CI pipeline (see next suggestion)

Implement GitHub Actions CI workflow for .NET build and test

The repo lacks automated CI/CD. With a multi-language toolkit (en/fr/ja/ru/zh) and Windows-specific activation logic, automated builds would catch regressions, localization issues, and platform-specific problems early. A .github/workflows/dotnet.yml would build, test, and validate the solution on each PR.

• [ ] Create .github/workflows/dotnet.yml
• [ ] Configure job to restore NuGet packages (reference packages.config), build CMWTAT_DIGITAL.sln, run unit tests from IsSN tests (once created), and validate for multiple .NET Framework versions
• [ ] Add workflow status badge to README.md and README.en.md
• [ ] Test locally with act CLI to ensure Windows-specific paths work

Extract and document activation logic from MainWindow.xaml.cs into separate service classes

MainWindow.xaml.cs likely contains mixed UI and business logic for the core activation functionality. Extracting activation, KMS, and license validation into dedicated service classes (e.g. ActivationService.cs, LicenseService.cs) in CMWTAT_DIGITAL/Domain would improve testability, reusability, and maintainability. This enables easier unit testing and clearer separation of concerns for new contributors.

• [ ] Review MainWindow.xaml.cs to identify activation logic blocks (KMS calls, license checks, digital license operations)
• [ ] Create CMWTAT_DIGITAL/Domain/Services/ directory with ActivationService.cs and LicenseService.cs
• [ ] Move activation methods from MainWindow.xaml.cs to services, keeping UI calls in code-behind
• [ ] Update MainWindow.xaml.cs to instantiate and call the new services
• [ ] Add XML documentation comments to service methods for clarity

• Add unit tests for IsSN.cs validation logic—currently no tests are visible in the file structure; write xUnit or NUnit tests to cover serial number format and SKU edge cases
• Create a CONTRIBUTING.md with localization guidelines—the Lang/ folder has 5 languages but no docs explaining how to add a 6th language or update strings consistently across all files
• Document the activation flow in MainWindow.xaml.cs with inline comments—the core activation logic lacks explanation of which API calls map to which UI steps, making it hard for new contributors to understand the workflow

• Critical · Windows Activation Toolkit - Potential Legal and Compliance Risk — Repository root - entire project. This codebase is a Windows 10/11 digital license activation tool that may violate Microsoft's Terms of Service and licensing agreements. The tool appears designed to circumvent legitimate Windows licensing mechanisms, which could constitute unauthorized software activation. Fix: Ensure compliance with Microsoft licensing terms. Consider consulting legal counsel regarding the legality of this tool in your jurisdiction. Users should be clearly informed of legal implications.
• High · Missing Dependency Information — CMWTAT_DIGITAL/packages.config. The packages.config file is referenced but content is not provided. Unable to assess for known vulnerable NuGet dependencies. C# projects commonly use outdated or vulnerable third-party libraries that could introduce security risks. Fix: Provide a comprehensive dependency audit. Use tools like OWASP Dependency-Check or NuGet vulnerability scanner to identify outdated packages. Implement regular dependency updates and maintain a Software Bill of Materials (SBOM).
• High · Unverified Remote Script Execution — CDNDirectRun.ps1, DirectRun.ps1. PowerShell scripts (CDNDirectRun.ps1 and DirectRun.ps1) are present and appear to download/execute code from remote sources. This is a common attack vector for malware distribution and supply chain attacks. Fix: Review script contents for secure coding practices. Implement code signing for PowerShell scripts. Use restricted execution policies. Avoid downloading and executing untrusted remote code. Consider using hash verification if remote execution is necessary.
• Medium · Executable File in Repository Root — CMWTAT_Digital_Release_2_7_2_0.exe. A compiled executable (CMWTAT_Digital_Release_2_7_2_0.exe) is committed to the repository. Binary artifacts should not be version controlled as they cannot be code-reviewed and may pose distribution/integrity risks. Fix: Remove binary files from source control. Use release management systems (GitHub Releases, artifact repositories) for distributing compiled executables. Add .exe and .dll files to .gitignore.
• Medium · Manifest Configuration Not Reviewed — CMWTAT_DIGITAL/app.manifest. Windows application manifest (app.manifest) exists but content is not visible. Manifest files can contain elevation requests and security-related configurations that need review. Fix: Review app.manifest for appropriate privilege elevation requests. Ensure it only requests necessary permissions. Remove 'requireAdministrator' if not essential. Document all privilege escalation requirements.
• Medium · Hardcoded Configuration and API Endpoints — CMWTAT_DIGITAL/app.config. app.config file is present. Potential risk of hardcoded API endpoints, connection strings, or configuration values that may expose sensitive information or infrastructure details. Fix: Review app.config for hardcoded secrets. Extract sensitive configuration to environment variables or secure configuration management systems. Never commit API keys, URLs pointing to internal systems, or credentials.
• Medium · XAML Resource Files - Potential XSS/Code Injection — CMWTAT_DIGITAL/Lang/*.xaml, MainWindow.xaml. Multiple XAML resource files (language files, UI definition files) exist. If these files are loaded dynamically or modified by user input, they could be vulnerable to XAML injection attacks. Fix: Ensure XAML files are only loaded from trusted, signed sources. Validate any dynamic XAML loading. Do not parse user-supplied input as XAML. Use XAML readers with appropriate security settings.
• Low · Source Code Analysis Limitations — All C# source files (.cs). Actual source code content not provided for detailed analysis. This assessment is based on file structure and naming conventions only. Deeper vulnerabilities may exist in the implementation. Fix: Conduct a comprehensive code review focusing on: P/Invoke declarations for Windows APIs, system process handling, registry modifications, and privilege escalation techniques. Use static analysis tools like SonarQube or Roslyn analyzers.
• Low · User Settings File May Contain Sensitive Data — undefined. Settings.settings file may persist user preferences or cached data that could contain sensitive information Fix: undefined

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.