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/cmliu/SubsCheck-Win-GUI 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.

AVOID — Looks unmaintained — solo project with stale commits

• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Solo or near-solo (1 contributor active in 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 cmliu/SubsCheck-Win-GUI repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cmliu/SubsCheck-Win-GUI.

What it runs against: a local clone of cmliu/SubsCheck-Win-GUI — 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 cmliu/SubsCheck-Win-GUI | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 411 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "cmliu/SubsCheck-Win-GUI(\\.git)?\\b" \\
  && ok "origin remote is cmliu/SubsCheck-Win-GUI" \\
  || miss "origin remote is not cmliu/SubsCheck-Win-GUI (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"

# 4. Critical files exist
test -f "Form1.cs" \\
  && ok "Form1.cs" \\
  || miss "missing critical file: Form1.cs"
test -f "Program.cs" \\
  && ok "Program.cs" \\
  || miss "missing critical file: Program.cs"
test -f "EditURLs.cs" \\
  && ok "EditURLs.cs" \\
  || miss "missing critical file: EditURLs.cs"
test -f "App.config" \\
  && ok "App.config" \\
  || miss "missing critical file: App.config"
test -f "subs-check.win.gui.csproj" \\
  && ok "subs-check.win.gui.csproj" \\
  || miss "missing critical file: subs-check.win.gui.csproj"

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

SubsCheck-Win-GUI is a Windows Forms C# GUI wrapper around the subs-check Go utility, which batch-tests proxy subscription URLs and measures connection speeds, outputting results in YAML, JSON, and base64 formats compatible with proxy clients like v2rayN and Clash. It provides a desktop interface for network testing and subscription validation without command-line interaction. Single-window WinForms desktop application split across Form1.cs (main UI), EditURLs.cs (URL management), MoreYAML.cs (YAML config editor), and CheckUpdates.cs (version checking). Core state lives in Form1 with direct file I/O to config/ and output/ directories; no separation of concerns or MVC pattern.

Windows users (10/11) who manage proxy subscriptions and need a graphical tool to validate URL lists and test network speeds; intermediate users comfortable with proxy clients (Clash, v2rayN) who want automated subscription checking without CLI complexity.

Actively maintained but niche; single primary maintainer (cmliu) with a working GUI, explicit 24-hour research-use time limit in terms, and no visible CI/test infrastructure in the file list. Production-ready for its intended educational/testing use case, but lacks automated testing and formal release process.

High single-maintainer risk with no evidence of CI/CD pipelines or unit tests in the file list. Explicitly licensed for educational/research use only with mandatory 24-hour deletion requirement, creating legal/compliance risk for production deployment. Depends on external Go binary (subs-check.exe) and GitHub Proxy for asset loading, adding supply-chain dependencies and network reliability concerns.

No specific recent activity visible in the file list. The repo includes support for multiple output backends (R2 storage, GitHub Gist, WebDAV, local) and integrates with sub-store (Node.js service bundled in output/), but no active PR/issue details are provided.

Clone the repository and open subs-check.win.gui.sln in Visual Studio 2019+ with .NET Framework 4.7.2+ installed. Build the solution (the compiled EXE will include the subs-check.exe Go binary and required DLLs like YamlDotNet.dll and Newtonsoft.Json.dll). Run subs-check.win.gui.exe; ensure config/config.yaml and config/more.yaml exist in the same directory.

Daily commands: Double-click subs-check.win.gui.exe. No dev server; this is a desktop GUI app. If building from source: (1) ensure subs-check.exe exists in the executable directory, (2) ensure config/config.yaml is present, (3) run the compiled DLL/EXE. The GitHub Proxy URL (likely in Form1.cs or CheckUpdates.cs) must be accessible for update checks.

• Form1.cs — Main application window and primary UI entry point; contains core logic for subscription checking and result display
• Program.cs — Application entry point and initialization; sets up the main form and application lifecycle
• EditURLs.cs — Dialog for managing subscription URLs; critical for user input and data persistence
• App.config — Application configuration file; contains runtime settings and dependency paths for subs-check core
• subs-check.win.gui.csproj — Project file defining all build dependencies, target framework (.NET 4.7.2), and build configuration
• CheckUpdates.cs — Update checking logic; manages software version verification and update notifications

• Form1 (Main Window) (WinForms, C#, System.Diagnostics.Process) — Orchestrates workflow: loads URLs, triggers speed test, parses results, displays in grid, manages user interactions
  • Failure mode: If subs-check executable not found or crashes, test cannot run; UI becomes unresponsive; no graceful degradation
• EditURLs Dialog (WinForms, XML config, System.Xml) — CRUD operations for subscription URLs; persists to config; validates URL format
  • Failure mode: Config file corruption results in lost URLs; no backup or version control; no transaction safety
• subs-check (Go Backend) (Go 1.19+, HTTP, concurrent goroutines) — Core testing logic: connects to proxy nodes, runs speed tests, returns results in JSON/YAML
  • Failure mode: Hangs on unresponsive proxies; timeout handling depends on Go version; Windows 7 unsupported
• CheckUpdates Dialog (WinForms, HTTP requests, version comparison) — Verifies latest version availability; notifies user of updates
  • Failure mode: Network timeout silently fails; no fallback mechanism; no auto-update capability

• EditURLs.cs → App.config — User saves subscription URLs to configuration file
• App.config → Form1.cs — Main form loads URLs at startup
• Form1.cs → subs-check executable — Spawns subs-check process, passes URLs and test parameters
• subs-check executable → Form1.cs — Returns speed test results (JSON/YAML) via stdout
• Form1.cs → DataGridView control — Parses and displays results in tabular format with sorting/filtering
• Properties/Settings.settings → All forms — Persists user preferences (window size, column widths, theme settings)

Add a New Settings Dialog

1. Create a new form class inheriting from Form (e.g., NewSettings.cs) (NewSettings.cs)
2. Use Visual Designer to build the UI in NewSettings.Designer.cs (NewSettings.Designer.cs)
3. Create a corresponding .resx file for form resources (e.g., NewSettings.resx) (NewSettings.resx)
4. In Form1.cs, add a button handler that instantiates and shows the new form as a dialog (Form1.cs)
5. Add corresponding menu or button items to Form1.Designer.cs (Form1.Designer.cs)

Add a New Subscription Check Feature

1. Add input controls (TextBox, CheckBox, etc.) for the feature in Form1.Designer.cs (Form1.Designer.cs)
2. Implement the feature logic in Form1.cs, likely invoking the subs-check backend process (Form1.cs)
3. If persisting settings, add new properties to Properties/Settings.settings (Properties/Settings.settings)
4. Update App.config if new configuration keys are required for the backend (App.config)

Internationalize UI Text

1. Extract all hardcoded strings from Form1.cs and other form files into resource keys (Properties/Resources.resx)
2. Create satellite resource files for each language (e.g., Resources.zh-CN.resx) (Properties/Resources.Designer.cs)
3. In Form1.cs and other forms, replace string literals with Properties.Resources.[KeyName] (Form1.cs)
4. Ensure subs-check.win.gui.csproj includes appropriate culture settings in the build configuration (subs-check.win.gui.csproj)

• .NET Framework 4.7.2 & WinForms — Native Windows desktop development; provides mature UI framework with native look-and-feel for Windows 10/11
• Go (subs-check backend) — High-performance concurrent HTTP requests for subscription speed testing; compiled executable for portability
• YAML configuration — Human-readable proxy/subscription configuration format; standard in network testing tools

• Wrapping a Go backend (subs-check) in a C# WinForms GUI

  • Why: subs-check is the proven, battle-tested core; building UI in WinForms provides better native Windows UX than cross-platform alternatives
  • Consequence: Tight coupling to Windows; requires Go executable as external dependency; inter-process communication overhead

• No database or persistence layer; using App.config and Properties/Settings

  • Why: Simplicity for a lightweight utility; minimal footprint and no external service dependencies
  • Consequence: Config stored in plain text or registry; no encryption; unsuitable for sensitive data; limited scalability

• Single-threaded UI with synchronous subs-check invocation

  • Why: Easier to understand and debug; avoids race conditions in form state
  • Consequence: UI blocks during testing; poor responsiveness on slow networks; no progress granularity

• Cross-platform support (Windows-only by design per README)
• Real-time subscription monitoring (one-shot testing utility)
• User authentication or multi-user support (single-user desktop app)
• Encrypted credential storage (uses plaintext config)
• Production-grade error recovery (educational/research tool)

• Synchronous blocking subprocess invocation (Medium) — Form1.cs: Form1 likely calls Process.Start() and WaitForExit() synchronously, freezing the UI during subs-check execution (30–60 seconds)
• Plaintext configuration storage — App.config, EditURLs.cs: Subscription URLs and settings stored unencrypted in App.config;

subs-check.exe (Go binary) must be in the same directory as the GUI EXE at runtime; missing it will silently fail or crash during testing. GitHub Proxy URL is hard-coded somewhere (likely Form1.cs or CheckUpdates.cs) — network blocks or proxy downtime will break update checks. config/config.yaml must exist; no auto-generation visible in the file list. The 24-hour usage limit in the README is a legal/terms-of-service constraint, not enforced in code, but creates compliance risk. Sub-store service (output/node.exe) requires Node.js or bundled runtime to be available.

• WinForms GUI Framework — SubsCheck-Win-GUI is built entirely on .NET WinForms (Form1.cs, Designer.cs files); understanding event-driven UI patterns, control binding, and form lifecycle is essential to modify the interface
• YAML Configuration Serialization — The app reads/writes config/config.yaml and config/more.yaml using YamlDotNet; understanding YAML syntax and how YamlDotNet maps objects to YAML is critical for config handling
• Process Invocation and I/O Redirection — Form1.cs launches subs-check.exe as a subprocess and likely captures stdout/stderr; understanding .NET's System.Diagnostics.Process is needed to modify testing workflow or error handling
• Proxy Subscription Format Standards — The app outputs results in multiple formats (base64, YAML, JSON) compatible with Clash/v2rayN; understanding proxy client subscription specs is needed to validate output correctness
• GitHub Proxy Pattern — CheckUpdates.cs uses a GitHub Proxy service to accelerate asset downloads and bypass rate limits; this is a workaround for GitHub API/CDN limitations specific to network-constrained regions
• Modal Dialog Patterns in WinForms — EditURLs.cs and MoreYAML.cs are modal dialogs that persist state back to the parent Form1; understanding ShowDialog(), DialogResult, and form communication is needed for multi-window features

• beck-8/subs-check — Direct upstream dependency; the Go CLI tool that SubsCheck-Win-GUI wraps; contains the actual subscription testing and speed measurement logic
• 2dust/v2rayN — Ecosystem companion; v2rayN is a compatible proxy client that consumes the YAML/JSON outputs generated by SubsCheck-Win-GUI
• mihomo-party-org/mihomo-party — Another ecosystem client; SubsCheck-Win-GUI outputs Clash-compatible config files (output/mihomo.yaml) for use in Clash derivatives like mihomo-party
• cmliu/CF-Workers-GitHub — Companion project by the same maintainer; enables self-hosted GitHub Proxy to replace the hard-coded proxy URL, avoiding single-point-of-failure in update checks
• bestruirui/BestSub — Original predecessor; the first version of the subs-check concept before beck-8 and cmliu's derivatives

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.

Extract repeated form initialization logic from Form1.cs, CheckUpdates.cs, EditURLs.cs, MoreYAML.cs, and about.cs into a shared FormBase class

All 5 form classes (.cs files) follow similar Designer/resx patterns with duplicated initialization code. Creating a FormBase class would reduce code duplication, improve maintainability, and make future UI changes easier to propagate across all forms. This is a concrete refactoring that will measurably reduce SLOC and improve consistency.

• [ ] Create new FormBase.cs class inheriting from Form in Properties/FormBase.cs
• [ ] Identify common initialization patterns in Form1.Designer.cs, CheckUpdates.Designer.cs, EditURLs.Designer.cs, MoreYAML.Designer.cs, and about.Designer.cs
• [ ] Move common properties (fonts, colors, margins, button styles) to FormBase
• [ ] Update each form class to inherit from FormBase instead of Form
• [ ] Update Form1.Designer.cs and other Designer files to call base initialization
• [ ] Add unit tests in new Tests/FormBaseTests.cs to verify inheritance works correctly

Add GitHub Actions workflow for .NET build, code analysis, and executable packaging

The .sln and .csproj files indicate this is a C# WinForms project, but there's no CI/CD pipeline visible. A GitHub Actions workflow should build the project on each push, run static analysis, and package the executable. This ensures code quality and makes releases reproducible.

• [ ] Create .github/workflows/build.yml with steps to: restore NuGet packages from packages.config, build subs-check.win.gui.csproj in Release mode, and publish the executable
• [ ] Add FxCop or StyleCop static analysis step to check code quality violations
• [ ] Add step to create Release build artifact (executable .exe file)
• [ ] Test workflow triggers on push to main and pull requests
• [ ] Add build status badge to README.md

Create comprehensive README sections for installation, building from source, and configuration guide for Form1.cs settings

The README.md is incomplete (ends mid-sentence at '操作系统: Wind') and lacks critical sections: installation instructions, how to build from source, how to configure proxy URLs via the UI (EditURLs.cs), and what settings are persisted in Properties/Settings.settings. New users cannot easily get started.

• [ ] Complete the '系统要求' section and add .NET Framework version requirement
• [ ] Add '📥 安装' section with download/release links and system prerequisites
• [ ] Add '🔨 从源代码构建' section with: clone steps, NuGet restore command, Visual Studio build instructions, and output location
• [ ] Add '⚙️ 配置指南' section documenting the Form1.cs main window, EditURLs.cs URL management, CheckUpdates.cs version checking, and MoreYAML.cs configuration
• [ ] Document what settings are stored in App.config and Properties/Settings.settings with examples
• [ ] Add troubleshooting section for common WinForms/.NET runtime issues

• Add unit tests for YAML parsing and validation (YamlDotNet integration) in Form1.cs and MoreYAML.cs to prevent corruption of config.yaml on invalid input.
• Create a dedicated config manager class to centralize file I/O logic currently scattered across Form1.cs and other dialogs, reducing duplication and improving testability.
• Add error handling and user feedback for missing subs-check.exe or network failures during GitHub Proxy version checks (currently no visible exception handling in CheckUpdates.cs).

• High · Missing Dependency Information — packages.config. The packages.config file content is not provided for analysis. Unable to assess for vulnerable or outdated NuGet packages that could contain known security vulnerabilities. Fix: Provide packages.config content and regularly audit all dependencies using tools like NuGet Package Security Auditor, Snyk, or WhiteSource. Keep all packages updated to latest patched versions.
• High · Insufficient Input Validation in WinForms Application — Form1.cs, EditURLs.cs, MoreYAML.cs. WinForms applications (Form1.cs, EditURLs.cs, MoreYAML.cs) may be vulnerable to injection attacks if user input from text fields or URLs is not properly validated before being processed or passed to backend systems. Fix: Implement strict input validation and sanitization for all user inputs. Use parameterized queries if database operations are involved. Validate URL formats before processing.
• High · Potential Command Injection via Unvalidated Input — Form1.cs, MoreYAML.cs (URL and YAML processing). SubsCheck processes subscription URLs and YAML configurations. If these inputs are passed to system processes or external commands without proper validation, command injection attacks are possible. Fix: Avoid using Process.Start() with unsanitized user input. Use parameterized APIs instead. Implement whitelist-based validation for URLs and YAML content.
• Medium · Insecure Deserialization Risk — MoreYAML.cs. YAML configuration parsing (MoreYAML.cs) may be vulnerable to deserialization attacks if using unsafe YAML parsers without proper restrictions. Fix: Use secure YAML parsing libraries with restricted object instantiation. Avoid deserializing untrusted YAML content. Validate schema against a known-good specification.
• Medium · Missing Security Headers in GUI Application — App.config, CheckUpdates.cs. While this is a WinForms desktop application, if it contains any embedded web functionality or makes HTTP requests, security headers should be configured properly. Fix: Ensure all HTTP communications use HTTPS. Add proper certificate validation. Implement timeout controls for network requests.
• Medium · Update Check Vulnerability — CheckUpdates.cs. CheckUpdates.cs handles software updates. If updates are downloaded from insecure sources or without signature verification, this could enable man-in-the-middle attacks. Fix: Use HTTPS for update URLs. Implement cryptographic signature verification for downloaded updates. Consider using established update frameworks.
• Medium · Insufficient Logging and Monitoring — Form1.cs, CheckUpdates.cs, EditURLs.cs. No visible logging mechanisms for security-relevant events such as failed validations, update failures, or suspicious inputs. Fix: Implement comprehensive logging for all security events. Include timestamps, user actions, and error details. Ensure logs are stored securely.
• Low · Hardcoded Configuration Values — App.config. App.config may contain hardcoded values, URLs, or API endpoints that could be reverse-engineered from the compiled binary. Fix: Avoid hardcoding sensitive configuration. Use environment variables or encrypted configuration files. Exclude sensitive data from version control.
• Low · No Evidence of Code Signing — subs-check.win.gui.csproj. While the README mentions digital signatures and addresses false positives, the actual code signing implementation is not visible in the provided files. Fix: Implement and verify code signing for release binaries. Include a valid code signing certificate from a trusted CA to prevent tampering and improve user trust.
• Low · Limited Visibility on Exception Handling — Form1.cs, EditURLs.cs, CheckUpdates.cs, MoreYAML.cs. Without access to actual code implementation, potential unhandled exceptions or over-verbose error messages could leak sensitive information. Fix: Implement proper exception handling with user-friendly messages. Avoid exposing stack traces or sensitive system information to end users. Log detailed

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.