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/JustArchiNET/ArchiSteamFarm 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 all four use cases

• Last commit today
• 4 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits

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

What it runs against: a local clone of JustArchiNET/ArchiSteamFarm — 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 JustArchiNET/ArchiSteamFarm | 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 main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JustArchiNET/ArchiSteamFarm(\\.git)?\\b" \\
  && ok "origin remote is JustArchiNET/ArchiSteamFarm" \\
  || miss "origin remote is not JustArchiNET/ArchiSteamFarm (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main 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 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/JustArchiNET/ArchiSteamFarm"
  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).

ArchiSteamFarm (ASF) is a C# application that automates Steam card farming across multiple accounts simultaneously using the Steam client protocol. It logs into Steam accounts, manages their idle time on games to generate card drops, and handles the complete farming lifecycle—making it the primary open-source tool for headless Steam card farming at scale. Modular monorepo with a core ASF engine, three official plugin systems (OfficialPlugins/ItemsMatcher, CustomPlugins/ExamplePlugin, CustomPlugins/PeriodicGC, CustomPlugins/SignInWithSteam), and comprehensive CI/CD workflows. The .github/ directory contains issue templates, release automation, and Crowdin translation configuration. Docker multi-stage builds support release variants (latest, main, stable, released).

Power users and administrators who operate multiple Steam accounts and want to automate card farming without manual interaction; also developers building Steam automation tools who reference ASF's Steam protocol implementation and plugin architecture.

Production-ready with 14k+ GitHub stars, active CI/CD pipelines (.github/workflows/ci.yml, docker-publish-*.yml, publish.yml), comprehensive testing infrastructure, and recent commits. The presence of official plugins (ItemsMatcher, SignInWithSteam) and example plugins demonstrates stability and extensibility. Actively maintained with Docker releases and crowdin translation support.

Single-maintainer project (JustArchiNET) creates knowledge concentration risk. Direct Steam protocol dependency means breaking changes in Valve's protocol require rapid response. The plugin system (ArchiSteamFarm.CustomPlugins.*) is relatively new and third-party plugins may lack maintenance. Large C# codebase (1.7M LOC) and .NET platform lock-in could impact cross-platform availability.

Active Docker publishing pipeline with separate workflows for main/stable/released branches (docker-publish-main.yml, docker-publish-stable.yml, docker-publish-released.yml). Crowdin translation workflow (crowdin-ci.yml, crowdin.yml) indicates ongoing localization. Qodana code quality checks (.github/qodana.yaml) and Renovate dependency management (renovate.json5) show continuous maintenance. Recent plugin additions suggest expanding plugin ecosystem.

Check README for instructions.

Daily commands: dotnet run --project ArchiSteamFarm for console app; Docker: docker-compose if available, or docker run -it justarchi/archisteamfarm:latest. Configuration via JSON config files (standard ASF pattern, not shown but implied by farming nature).

• ArchiSteamFarm/ArchiSteamFarm.csproj: Core project file defining dependencies, framework version (.NET), and compilation settings for the main farming engine
• .github/workflows/ci.yml: Continuous integration pipeline defining build, test, and release steps on every commit
• ArchiSteamFarm.OfficialPlugins.ItemsMatcher/Backend.cs: Reference implementation of plugin system for trading/matching, demonstrates official plugin architecture pattern
• ArchiSteamFarm.CustomPlugins.ExamplePlugin/ExamplePlugin.cs: Template for third-party plugin developers, shows IPlugin interface implementation and ASP.NET Core controller integration
• .github/workflows/docker-publish-stable.yml: Docker release pipeline for stable distribution, critical for containerized deployments
• .editorconfig: C# code style consistency rules enforced across contributors
• .github/crowdin.yml: Localization workflow configuration for multi-language support

New feature: Add to ArchiSteamFarm/ main project or create custom plugin in ArchiSteamFarm.CustomPlugins.YourPlugin/. Official plugin: Extend ArchiSteamFarm.OfficialPlugins.ItemsMatcher/ pattern. Commands/API: Edit Controllers in existing plugins (e.g., SignInWithSteamController.cs). Workflows: Modify .github/workflows/*.yml. Tests: Follow .NET xUnit pattern (not shown; check if ArchiSteamFarm.Tests exists in full repo).

Steam account credentials: Configuration requires storing Steam login credentials securely—ASF likely uses encrypted config files (pattern not visible in file list but essential for production). Rate limiting: Steam API has strict rate limits; incorrect configuration can trigger temporary account locks. .NET version: Project targets specific .NET versions; using wrong SDK version locally vs. CI can cause subtle build failures. Plugin loading: Custom plugins must match ASF's exact version and API surface; version mismatch causes silent load failures. Docker volumes: State persists in container volumes (accounts, config); missing volume mounts lose farming progress. Two-factor authentication: Steam 2FA is required for most operations; setup with shared secrets is non-obvious.

• Steam Protocol (CSGO/Dota 2 GameCoordinator protocol) — ASF's entire card farming mechanism depends on reverse-engineered Steam protocol messages; understanding message structure and state machines is critical for debugging farming failures
• Plugin Architecture (IPlugin interface & dependency injection) — ASF's extensibility relies on plugins implementing IPlugin; contributors adding features should extend via plugins rather than monolith to maintain modularity
• Async/Await concurrency model — ASF manages multiple concurrent Steam connections (one per account); C# async/await prevents blocking I/O and enables thousands of accounts per process
• Account encryption at rest (credential storage) — Steam credentials must be encrypted in config files; ASF uses cryptographic vaults to prevent credentials leaking in backups or logs
• Rate limiting & backoff strategies — Steam enforces request rate limits per account; ASF implements exponential backoff to avoid temporary bans during mass card farming operations
• Multi-stage Docker builds — ASF's Dockerfile architecture (.github/workflows/docker-* files) uses build-cache optimization; understanding layers reduces deployment size and speeds CI/CD
• Shared state synchronization (inter-bot coordination) — When running multiple ASF instances, bots must coordinate inventory/trading without race conditions; ASF uses backend coordination (ItemsMatcher plugin) to prevent duplicate trade attempts

• DoctorMcKay/node-steam-user — JavaScript Steam client library; alternative for non-.NET environments with similar card farming capabilities
• DoctorMcKay/node-steamcommunity — Companion library to node-steam-user, handles Steam Community trade/market operations that ASF integrates
• Revadike/UnturnedSteamUnlocker — Similar Steam automation project; reference implementation of Steam protocol interaction patterns
• JustArchiNET/ASF-WebConfigGenerator — Official companion web tool for generating ASF configuration files; reduces manual JSON editing errors
• dotnet/runtime — .NET runtime dependency; ASF requires specific .NET versions for cross-platform execution

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 ArchiSteamFarm.OfficialPlugins.ItemsMatcher plugin

The ItemsMatcher plugin is a critical official plugin with complex backend logic (Backend.cs), inventory matching algorithms (AssetForMatching.cs), and multiple data models. There are no visible test projects in the file structure for this plugin. Adding unit tests would validate the core matching logic, cache behavior (BotCache.cs), and backend API interactions, reducing regressions in this frequently-used functionality.

• [ ] Create ArchiSteamFarm.OfficialPlugins.ItemsMatcher.Tests project alongside the plugin
• [ ] Add unit tests for Backend.cs covering matching algorithms and API response handling
• [ ] Add unit tests for BotCache.cs covering inventory caching and expiration logic
• [ ] Add integration-style tests for the full workflow in ItemsMatcherPlugin.cs
• [ ] Ensure tests cover the Data models (AssetForMatching, AssetForListing, SetPart, etc.) serialization/deserialization

Add localization completeness validation to CI pipeline

The repo has extensive localization support (Strings.be-BY.resx, Strings.de-DE.resx, etc. in ItemsMatcher plugin alone). There's currently no visible workflow to validate that all .resx language files have matching keys or flag missing translations. This prevents contributors from accidentally breaking translations. A new CI workflow could validate RESX file consistency across all supported languages.

• [ ] Create .github/workflows/localization-validate.yml workflow
• [ ] Implement or use existing tool to validate all .resx files in Localization/ directories have consistent key sets
• [ ] Add check to ensure no language files are missing keys present in the base language (en)
• [ ] Configure workflow to run on PRs modifying any .resx files
• [ ] Document expected localization process in .github/CONTRIBUTING.md localization section

Create missing unit test project for ArchiSteamFarm.CustomPlugins.SignInWithSteam

The SignInWithSteam plugin implements authentication logic with external API interactions (Data/SignInWithSteamRequest.cs, SignInWithSteamController.cs). Authentication code is security-sensitive and should have dedicated unit tests covering the request/response handling, controller endpoints, and edge cases. This plugin currently has no visible test coverage.

• [ ] Create ArchiSteamFarm.CustomPlugins.SignInWithSteam.Tests project
• [ ] Add unit tests for SignInWithSteamPlugin.cs covering initialization and lifecycle
• [ ] Add tests for SignInWithSteamController.cs covering HTTP endpoint validation and error handling
• [ ] Add serialization/deserialization tests for SignInWithSteamRequest.cs and SignInWithSteamResponse.cs
• [ ] Add integration tests validating the full authentication flow with mocked Steam responses

• Add comprehensive XML documentation comments to public API methods in ArchiSteamFarm/Core/ classes—currently missing for plugin developers: Medium: Improves plugin developer onboarding and IDE IntelliSense
• Create integration test suite in ArchiSteamFarm.Tests/ covering plugin loading and IPlugin interface contract validation: Medium: Prevents plugin API breaking changes and validates third-party plugins
• Document environment variable configuration options in a dedicated CONFIGURATION.md file with examples for Docker deployment: Low: Reduces Docker user confusion about required vs. optional settings

ArchiSteamFarm demonstrates reasonable security practices with multi-stage Docker builds, GitHub security documentation, and a structured codebase. Primary concerns are: (1) unpinned base image versions in Dockerfile creating supply chain risks, (2) lack of clarity around plugin system security boundaries for a multi-account sensitive application, and (3) missing container health checks for production deployment. No obvious hardcoded credentials or injection vulnerabilities detected in the visible file structure. The presence of security policy documentation (.github/SECURITY.md) and organized CI/CD workflows is positive. Recommend implementing strict image pinning, formalizing plugin security policies, and adding runtime health monitoring for improved production security posture.

• Medium · Use of Node.js LTS without pinned version — Dockerfile - FROM --platform=$BUILDPLATFORM node:lts${IMAGESUFFIX} AS build-node. The Dockerfile uses 'node:lts' without a specific version tag. This allows automatic updates to any LTS version, which could introduce breaking changes or security issues without explicit review. The tag should be pinned to a specific LTS version (e.g., node:20-lts). Fix: Pin the Node.js image to a specific LTS version: 'FROM --platform=$BUILDPLATFORM node:20-lts${IMAGESUFFIX} AS build-node' and regularly update with explicit version changes.
• Medium · Use of .NET SDK without pinned version — Dockerfile - FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0${IMAGESUFFIX} AS build-dotnet. The Dockerfile uses 'mcr.microsoft.com/dotnet/sdk:10.0' without a specific patch version. This allows automatic updates that could introduce unexpected behavior or security issues. It should be pinned to a specific patch version (e.g., 10.0.0). Fix: Pin to a specific patch version: 'mcr.microsoft.com/dotnet/sdk:10.0.0${IMAGESUFFIX}' and establish a regular update schedule for security patches.
• Medium · Multi-stage build leaks compilation artifacts — Dockerfile - build stages (build-node and build-dotnet). The Dockerfile uses COPY commands with --link flag to transfer build artifacts. While this improves layer efficiency, intermediate build stages may contain development dependencies or temporary files. Ensure the final runtime stage doesn't include unnecessary build tools or sensitive data. Fix: Verify the final runtime image only includes necessary runtime dependencies. Consider using a minimal base image for the final stage and ensure build artifacts are properly cleaned.
• Low · Missing HEALTHCHECK in Dockerfile — Dockerfile - Missing HEALTHCHECK directive. The provided Dockerfile snippet does not show a HEALTHCHECK instruction. For a production application managing multiple Steam accounts, health checks are important for orchestration systems to detect and restart unhealthy containers. Fix: Add a HEALTHCHECK instruction to monitor the application's availability, e.g., 'HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 CMD curl -f http://localhost:1200/api/type || exit 1'
• Low · Potential sensitive data in git submodules — .gitmodules and ASF-ui submodule. The repository uses git submodules (ASF-ui) as indicated by '.gitmodules' file. Submodules can inadvertently include sensitive configuration or credentials if not properly managed. Fix: Review .gitignore rules to ensure sensitive files (credentials, keys, config files with secrets) are excluded from the ASF-ui submodule. Regularly audit submodule content for accidental secrets.
• Low · Plugin system trust boundary unclear — ArchiSteamFarm.CustomPlugins.* and ArchiSteamFarm.OfficialPlugins.*. The application supports custom plugins (CustomPlugins directory structure visible) and bundled official plugins. The security boundary for plugin execution and isolation is not evident from the provided file structure. Fix: Document and enforce plugin sandboxing requirements. Implement plugin signature verification and capability restrictions. Review plugin loading mechanisms for arbitrary code execution risks.

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.