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/PCL-Community/PCL-CE 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.

GO — Healthy across the board

• Last commit 1d ago
• 13 active contributors
• Distributed ownership (top contributor 24% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ 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 PCL-Community/PCL-CE repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/PCL-Community/PCL-CE.

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

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

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

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

# 3. Default branch
git rev-parse --verify dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev 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 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/PCL-Community/PCL-CE"
  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).

PCL Community Edition is a community-maintained fork of Plain Craft Launcher 2, a .NET 8-based Minecraft launcher for Windows that provides mod management, Java version control, and resource pack support. It adds features and improvements not yet in the upstream PCL repository, distributed as a standalone Windows executable without requiring manual .NET installation. Monolithic C# .NET 8 WPF application: main launcher code in 'Plain Craft Launcher 2/' directory, separate test suite in 'PCL.Core.Test/' with focused test files for features (DiffTest.cs, DynamicJsonTest.cs, MavenTest.cs, McPing.cs), and a C# source generator project 'PCL.Core.SourceGenerators/' for compile-time code generation (configs, dependency injection, interop). Build outputs configured via GitHub Actions workflows targeting Windows 10+ (build 17763+).

Chinese Minecraft players and modding enthusiasts who want a feature-rich launcher with support for custom resource packs, mod loaders, and multi-account management. Open-source contributors maintaining community improvements to the original PCL launcher.

Production-ready and actively maintained: 4.7M lines of C# code, organized CI/CD pipelines (build-test, beta/stable release workflows), comprehensive GitHub issue templates for bug reports and feature requests, and active community support groups (3 QQ groups + Telegram). Regular releases with documented versions indicate healthy release cadence.

Low risk for end-users due to active maintenance and .NET 8 Runtime requirement ensuring controlled environments. Moderate risk for contributors: single-project structure (no monorepo separation) makes large changes impact the entire launcher, Windows-only official support (macOS/Linux experimental), and community-driven testing means edge cases may emerge post-release.

Active development with multiple release workflows: beta and stable publish pipelines in GitHub Actions, mirror/backup upload automation (mirrorchyan_uploading.yml), and community contribution review. .NET version pinned to 8, Windows compatibility focused on 10 (build 17763) and higher with legacy support considerations for Windows 8.

Clone and build via .NET SDK: git clone https://github.com/PCL-Community/PCL-CE.git && cd PCL-CE && dotnet restore && dotnet build. Requires .NET 8 SDK installed. For testing: dotnet test PCL.Core.Test/PCL.Core.Test.csproj. Contribution: read CONTRIBUTING.md and check GitHub wiki for development guide (referenced in README).

Daily commands: After dotnet restore, run dotnet build for debug build, or dotnet publish -c Release for standalone release. The .github/workflows/reusable-build.yml shows the official build pipeline: targets net8.0-windows, generates self-contained executables. For development iteration: dotnet run --project 'Plain Craft Launcher 2/PlainCraftLauncher.csproj'.

• PCL.Core.SourceGenerators/LifecycleScopeGenerator.cs: Generates dependency injection container code at compile-time, critical for launcher initialization and service lifecycle management
• PCL.Core.Test/PCL.Core.Test.csproj: Test project configuration defining test framework, target frameworks, and dependencies—entry point for understanding testing strategy
• .github/workflows/reusable-build.yml: Reusable build workflow defining official compilation, testing, and packaging steps for all release pipelines
• PCL.Core.Test/Minecraft/McPing.cs: Example test for Minecraft server communication, shows integration testing pattern for external dependencies
• .github/workflows/release-stable_publish.yml: Stable release pipeline orchestrating versioning, artifact creation, and distribution—defines release process
• PCL.Core.SourceGenerators/SharedConstants.cs: Shared constants for code generation, indicates centralized configuration strategy for generators

Feature work: examine 'Plain Craft Launcher 2/' structure for UI components and logic. Cryptography/networking: PCL.Core.Test/ subdirs (Encryption/, Network/, Minecraft/) show expected module interfaces—implement alongside tests. Source generation: modify PCL.Core.SourceGenerators/ .cs files, add new generators by inheriting IIncrementalGenerator. Tests: create new .cs file in PCL.Core.Test/ matching feature area (e.g., MyFeatureTest.cs), use existing test patterns (BaseXTest.cs, DynamicJsonTest.cs).

1. Windows-only official binaries: HLSL shaders (5.6K lines) compiled for DirectX/DXGI on Windows, non-trivial to port. 2) .NET 8 Runtime pinned version: launcher requires specific .NET 8 Desktop Runtime, distribution not bundled by default—users must install separately. 3) Source generators require Visual Studio 2022+ or SDK with Roslyn support; local builds may fail on older tooling. 4) GitHub Actions workflow uses 'mirrorchyan' automation (mirrorchyan_release_note.yml, mirrorchyan_uploading.yml) suggesting external mirror sync—network-dependent release process. 5) No visible package.json equivalent—pure .csproj/.sln project, must use dotnet CLI, not npm. 6) Test projects reference external services (DoHQueryTest.cs, MavenTest.cs, WebServerTest.cs) requiring network access or mock servers during CI.

• Incremental Code Generation (IIncrementalGenerator) — PCL uses Roslyn's newer incremental generator API (vs legacy ISourceGenerator) in ConfigGenerator.cs and others—efficient, cacheable, required for understanding how dependency injection and config are bootstrapped at compile-time
• Dependency Injection Container (Lifecycle Scope) — LifecycleScopeGenerator.cs auto-generates DI container code; understanding scoped/singleton lifetimes is critical for memory management in a long-running desktop app handling mod downloads and server connections
• HLSL Pixel/Vertex Shaders — 5.6K lines of HLSL in repo enable GPU-accelerated rendering (likely blur, animations, visual effects); required knowledge for any GPU-related performance improvements or visual feature additions
• Platform Interop (P/Invoke) — EnvironmentInteropGenerator.cs auto-generates Windows API P/Invoke declarations; essential for features like system tray integration, file associations, and Java runtime detection
• WPF Data Binding & MVVM — UI layer built on WPF with implicit data binding; understanding MVVM patterns and binding errors is necessary for UI feature development and debugging layout issues
• Minecraft Protocol & Server Pinging — McPing.cs test shows integration with Minecraft server protocol for status querying (player count, MOTD, version negotiation); needed for launcher features like server discovery and version compatibility checking
• Maven Repository Integration — MavenTest.cs indicates fetching artifacts from Maven Central (likely Forge/Fabric dependencies, Java libs); understanding Maven coordinate resolution is necessary for mod dependency resolution features

• Meloong-Git/PCL — Official upstream repository—PCL CE is a direct fork maintaining feature parity while adding community improvements
• MultiMC/Launcher — Alternative multi-instance Minecraft launcher written in C++/Qt; shares same problem space (mod management, Java control, profile switching)
• PojavLauncherTeam/PojavLauncher — Cross-platform Minecraft launcher (Java-based); demonstrates portable alternative to Windows-only PCL approach
• PCL-Community/PCL2CEHelp — Community documentation repository for PCL CE, referenced in README—essential companion for user guides and troubleshooting
• dotnet/roslyn — Roslyn compiler platform used by PCL.Core.SourceGenerators for compile-time code generation; understanding Roslyn is prerequisite for generator contribution

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 comprehensive unit tests for PCL.Core.SourceGenerators

The PCL.Core.SourceGenerators directory contains 7 critical source generator files (ConfigGenerator.cs, DependencyCollectorGenerator.cs, EnvironmentInteropGenerator.cs, LifecycleScopeGenerator.cs, LifecycleServiceTypesGenerator.cs) but there are no corresponding test files in PCL.Core.Test. Source generators are error-prone and require validation that they produce correct output. This would catch regressions early.

• [ ] Create PCL.Core.Test/SourceGenerators/ directory
• [ ] Add unit tests for ConfigGenerator.cs validating generated config properties
• [ ] Add unit tests for DependencyCollectorGenerator.cs validating dependency resolution output
• [ ] Add unit tests for EnvironmentInteropGenerator.cs validating interop code generation
• [ ] Add unit tests for LifecycleScopeGenerator.cs and LifecycleServiceTypesGenerator.cs
• [ ] Integrate tests into PCL.Core.Test.csproj

Expand Minecraft/Network integration tests with real-world scenarios

PCL.Core.Test/Minecraft/McPing.cs and PCL.Core.Test/Network/ exist but appear incomplete. Given this is a Minecraft launcher, there should be comprehensive tests for server pinging, DoH resolution fallbacks, and connection scenarios. Adding tests for timeout handling, protocol version negotiation, and network failure recovery would improve reliability.

• [ ] Expand McPing.cs with tests for different Minecraft protocol versions (1.7-1.20+)
• [ ] Add tests for ping timeout scenarios and connection refused errors
• [ ] Add integration tests in Network/ for DoH query fallback behavior when standard DNS fails
• [ ] Add tests for WebServerTest.cs covering edge cases like port conflicts and malformed requests
• [ ] Document expected behaviors in test comments for future maintainers

Add validation test coverage for all Validator classes with edge cases

PCL.Core.Test/Validate/ contains 9 validator test files but they appear to have minimal coverage based on file sizes. Validators (BlacklistValidator, FileNameValidator, FolderPathValidator, HttpValidator, etc.) are critical security-sensitive components. Each needs comprehensive edge case testing including null inputs, unicode characters, path traversal attempts, and boundary conditions.

• [ ] Audit existing validator tests in PCL.Core.Test/Validate/ for coverage gaps
• [ ] Expand FileNameValidatorTest.cs with reserved names (CON, PRN, AUX), special chars, and length limits
• [ ] Expand FolderPathValidatorTest.cs with UNC paths, symlinks, and permission scenarios
• [ ] Expand HttpValidatorTest.cs with IPv6, internationalized domains, and port edge cases
• [ ] Add BlacklistValidatorTest.cs for bypass attempts and performance with large blacklists
• [ ] Add integration test combining multiple validators in real-world scenarios

• Add XML documentation comments to all public methods in PCL.Core.SourceGenerators/*.cs files (ConfigGenerator.cs, DependencyCollectorGenerator.cs, etc.)—improves IDE IntelliSense for maintainers and reduces onboarding friction. Currently minimal docs visible.
• Create integration test suite for 'Plain Craft Launcher 2/Images/icon.ico' asset pipeline—verify icon renders correctly on various Windows DPI settings (96, 120, 144 DPI). No existing tests cover UI asset scaling, common pain point in WPF apps.
• Refactor PCL.Core.Test/Network/DoHQueryTest.cs to use mocked DNS responses (instead of live DoH queries)—eliminates test flakiness from network latency, reduces CI runtime, improves contributor experience. Currently integration-style, should be unit-testable.

The PCL Community Edition codebase demonstrates moderate security posture. Positive aspects include the use of GPG signing, presence of comprehensive input validation framework, and organized test structure. Primary concerns are the inability to audit dependencies without manifest files, custom cryptographic implementations that should be reviewed, and custom source generators that could introduce build-time vulnerabilities. The project should implement automated dependency scanning (NuGet auditing), conduct security code review of custom crypto and generator code, and ensure all web-facing components include appropriate security headers. No obvious hardcoded credentials or SQL injection patterns were detected in the file structure analysis.

• Medium · Missing Dependencies File for Vulnerability Analysis — Project root - Missing dependency manifest. The package/dependencies file (such as packages.json, .csproj, or similar) was not provided for analysis. This prevents comprehensive identification of known vulnerable dependencies and their versions. Fix: Provide package dependency files (.csproj, packages.config, or NuGet.lock.json) for automated vulnerability scanning using tools like NuGet Auditor, Snyk, or OWASP Dependency-Check
• Medium · Source Generators in Build Pipeline — PCL.Core.SourceGenerators/. The codebase contains custom source generators (PCL.Core.SourceGenerators) that execute during compilation. These could potentially introduce security risks if they process untrusted input or generate code with vulnerabilities. Fix: Audit all source generators for input validation, code injection risks, and ensure they follow secure coding practices. Implement unit tests for generator output validation
• Low · Cryptographic Implementations in Test Suite — PCL.Core.Test/Encryption/. Custom cryptographic implementations are present in test files (AesGcmTest.cs, ChaCha20.cs, ChaCha20Poly1305.cs). Using custom crypto implementations instead of validated libraries increases vulnerability risk. Fix: Ensure all cryptographic operations use well-tested, standard libraries (.NET's built-in cryptography classes or established NuGet packages). Have custom implementations peer-reviewed by security experts
• Low · No Evidence of Security Headers Configuration — PCL.Core.Test/Network/WebServerTest.cs. The file structure does not show explicit security header configuration, especially important given the web server test components (WebServerTest.cs) that suggest HTTP server functionality. Fix: Implement security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, etc.) in any web server components
• Low · Input Validation Framework in Place but Requires Verification — PCL.Core.Test/Validate/. Multiple validator classes exist (FileNameValidator, FolderNameValidator, HttpValidator, etc.) suggesting input validation is attempted. However, the actual implementations were not reviewed for completeness. Fix: Ensure all validators properly handle edge cases, null inputs, and malicious payloads. Use whitelist-based validation approaches rather than blacklist
• Info · GPG Public Key Present — GPG-PUBLIC-KEY.asc. The repository contains a GPG-PUBLIC-KEY.asc file, indicating signed commits and releases are in use. This is a positive security practice. Fix: Continue using code signing and commit verification. Ensure all releases are signed and verification is enforced in release workflows

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.