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/File-New-Project/EarTrumpet 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 — Single-maintainer risk — review before adopting

• Last commit 1w ago
• 2 active contributors
• Other licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 83% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 File-New-Project/EarTrumpet repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/File-New-Project/EarTrumpet.

What it runs against: a local clone of File-New-Project/EarTrumpet — 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 File-New-Project/EarTrumpet | 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 ≤ 37 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "File-New-Project/EarTrumpet(\\.git)?\\b" \\
  && ok "origin remote is File-New-Project/EarTrumpet" \\
  || miss "origin remote is not File-New-Project/EarTrumpet (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 "EarTrumpet.vs15.sln" \\
  && ok "EarTrumpet.vs15.sln" \\
  || miss "missing critical file: EarTrumpet.vs15.sln"
test -f "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs" \\
  && ok "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs" \\
  || miss "missing critical file: EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs"
test -f "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ActionProcessor.cs" \\
  && ok "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ActionProcessor.cs" \\
  || miss "missing critical file: EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ActionProcessor.cs"
test -f "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/TriggerManager.cs" \\
  && ok "EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/TriggerManager.cs" \\
  || miss "missing critical file: EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/TriggerManager.cs"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"

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

EarTrumpet is a Windows system tray application that provides granular, per-application volume control and audio device management. It replaces Windows' built-in audio mixer with a modern interface featuring multi-channel audio visualization, per-app device routing, and hotkey support—solving the problem that Windows' native volume controls don't let users manage individual application audio levels or route apps to specific audio devices. Composite .NET/WPF architecture: EarTrumpet.Package is the main UWP/MSIX application shell; EarTrumpet.ColorTool is a companion utility for theme customization; .chocolatey/ contains package distribution config; .azure-pipelines.yml and .github/workflows/ orchestrate CI/CD across multiple channels (Store, Chocolatey, GitHub Releases).

Windows power users and content creators who need fine-grained audio control (podcasters routing different apps to different devices, gamers mixing game and chat volumes separately), plus developers contributing to the open-source project via GitHub.

Highly mature and production-ready. The project won Microsoft Store Community Choice Awards in 2022, has 600K+ lines of C# code, maintains active CI/CD pipelines (.azure-pipelines.yml, .github/workflows/), and is marked as actively maintained in 2025. Regular coverage in major tech media (The Verge, Windows Central, Linus Tech Tips) indicates stable, widely-used software.

Standard open source risks apply.

Active development with recent commits updating CI workflows (.github/workflows/main.yml), translation management (translators.yml, Crowdin integration), and issue template configuration. The CHANGELOG.md and maintenance badge (2025) indicate ongoing feature work and bug fixes. Sponsorship workflow suggests revenue/sustainability focus.

See COMPILING.md for the authoritative build guide. Generally: git clone https://github.com/File-New-Project/EarTrumpet.git, open EarTrumpet.sln in Visual Studio 2022+ (C# project), restore NuGet packages, and build. Requires Windows 10/11 and .NET runtime. For testing: run the built executable or deploy via the .Package project.

Daily commands: No traditional dev server. Build the solution in Visual Studio 2022: right-click EarTrumpet.Package → Deploy, or run the compiled .exe. For ColorTool utility: build EarTrumpet.ColorTool.csproj separately. Debug by running with debugger attached in Visual Studio.

• EarTrumpet.vs15.sln — Primary Visual Studio solution file containing all projects; entry point for building and understanding the full codebase architecture.
• EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs — Core abstraction for addon parts system; foundational to understanding the extensible actions/addon framework.
• EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ActionProcessor.cs — Processes action chains and logic flow; critical to how automation/actions execute within the addon system.
• EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/TriggerManager.cs — Manages trigger registration and event handling; orchestrates when actions should fire based on audio/process events.
• .github/workflows/main.yml — CI/CD pipeline definition; essential for understanding build, test, and release processes.
• COMPILING.md — Compilation and development setup guide; required reading for local development environment setup.
• CONTRIBUTING.md — Contribution guidelines and code standards; mandatory for all contributors to understand project conventions.

Add a New Trigger Type

1. Create a new enum value in DataModel/Enum/ directory (e.g., CustomEventKind.cs) to define the trigger event type (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Enum/)
2. Implement a trigger handler inheriting from TriggerManager or create specialized manager in Processing/ directory (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/TriggerManager.cs)
3. Register the trigger in the appropriate event subscription system (AudioTriggerManager or ProcessWatcher) (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/AudioTriggerManager.cs)
4. Add UI control in Controls/ directory if user configuration is needed for the trigger (EarTrumpet/Addons/EarTrumpet.Actions/Controls/)

Add a New Action Type

1. Create enum value in Enum/ directory (e.g., CustomActionKind.cs) to identify the new action (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Enum/)
2. Create Part subclass or implement IPartWithVolume/IPartWithDevice as appropriate (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs)
3. Add action execution logic to ActionProcessor.cs to handle the new action type (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ActionProcessor.cs)
4. Create XAML view and code-behind in Controls/ for action configuration UI (EarTrumpet/Addons/EarTrumpet.Actions/Controls/MenuButton.cs)

Add a New Condition Type

1. Add enum value (e.g., ComparisonBoolKind.cs) or extend existing condition enums (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Enum/ComparisonBoolKind.cs)
2. Implement condition evaluation logic in ConditionProcessor.cs (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Processing/ConditionProcessor.cs)
3. Create Part subclass implementing the condition interface if state tracking is needed (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/Part.cs)
4. Add UI control in Controls/ for condition configuration if user input is required (EarTrumpet/Addons/EarTrumpet.Actions/Controls/)

Add a New WPF UI Control

1. Create new .cs file in Controls/ directory implementing custom control or user control (EarTrumpet/Addons/EarTrumpet.Actions/Controls/MenuButton.cs)
2. Define or update XAML styling in AddonResources.xaml for consistent theming (EarTrumpet/Addons/EarTrumpet.Actions/AddonResources.xaml)
3. Register control in parent ViewModel or container using dependency injection patterns (EarTrumpet/Addons/EarTrumpet.Actions/DataModel/)

• WPF (Windows Presentation Foundation) — Native Windows UI framework for rich desktop UI; enables custom controls and real-time volume visualization. Tight Windows OS integration for audio device access.
• C# .NET Framework — Primary language for Windows audio APIs (Windows.Media.Control, NAudio); enables managed interop with Windows Core Audio APIs and OS event systems.

Windows-only development: no WSL, no cross-platform testing—requires actual Windows 10/11 or VM. Audio APIs (Core Audio, WASAPI) are Windows-specific and undocumented in places; relies on reverse-engineering and community knowledge. Chocolatey install script (chocolateybeforemodify.ps1) likely modifies system state—test packaging changes carefully. Microsoft Store deployment has certification requirements (AppX manifest, privacy policy, signing certs) not visible in repo. ColorTool uses separate .xaml UI markup that must be kept in sync with main app theming changes.

• WASAPI (Windows Audio Session API) — Core API EarTrumpet uses to enumerate audio devices, route per-app audio, and visualize channel levels; understanding this is essential for modifying audio control logic.
• MVVM (Model-View-ViewModel) Pattern — Used throughout the codebase (visible in ColorViewModel.cs, ColorItemViewModel.cs); essential for understanding how data binding and UI state management work in EarTrumpet's WPF architecture.
• UWP/MSIX Packaging — EarTrumpet.Package targets Microsoft Store via MSIX format; contributors need to understand manifest configuration, certificate signing, and Store certification requirements.
• WPF (Windows Presentation Foundation) — UI framework used for EarTrumpet's interface; XAML-based declarative UI markup in .xaml files drives the visual layer.
• Core Audio Device Topology — Windows audio model with capture/render devices, endpoints, and session categories; essential for understanding how EarTrumpet isolates and controls per-app audio streams.
• Fluent Design System (Accent Colors & Light/Dark Mode) — EarTrumpet supports configurable accent colors and light/dark themes (mentioned in features); the ColorTool utility manages Fluent Design resources, affecting XAML color bindings throughout the app.
• Multi-DPI Scaling & Asset Variants — The Assets/ directory contains tiles and icons at 100-400% scales for Windows DPI awareness; incorrect scaling can break appearance on high-resolution displays.

• File-New-Project/VolumeLocker — Likely a sibling project from the same author organization for Windows audio/system functionality.
• foobar2000/foobar2000 — Industry-standard audio player with per-device routing; EarTrumpet users often pair it with fine-grained audio control like EarTrumpet provides.
• ToastNotifications/Desktop.Notifications — Companion utility for Windows toast notification control; users managing per-app audio often also want to manage notification sounds and system sounds separately.
• microsoft/WindowsAppSDK — Microsoft's official framework for modern Windows apps; EarTrumpet uses WPF (legacy) but future versions may migrate to WinAppSDK or WASDK for newer capabilities.
• chocolatey/choco — Package manager used for EarTrumpet distribution; understanding Chocolatey manifest structure (.nuspec files) is essential for contributors handling packaging.

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 GitHub Action workflow for automated Chocolatey package validation

The repo has a Chocolatey package (.chocolatey/eartrumpet.nuspec) but no CI workflow validates the package structure, version consistency, or checksums before release. This prevents broken package deployments and ensures the nuspec metadata stays in sync with actual releases.

• [ ] Create .github/workflows/chocolatey-validate.yml workflow
• [ ] Add step to validate .chocolatey/eartrumpet.nuspec against schema
• [ ] Add step to verify LICENSE.txt and VERIFICATION.txt are present in .chocolatey/tools/
• [ ] Add step to check version in nuspec matches version in main codebase/CHANGELOG.md
• [ ] Trigger on PR changes to .chocolatey/ directory

Create COMPILING.md guide section for building and testing the ColorTool utility

COMPILING.md exists but likely lacks specific build instructions for the EarTrumpet.ColorTool project. This is a separate WPF application with its own .csproj that maintainers and contributors need to understand for color theme modifications and testing.

• [ ] Review current COMPILING.md content and identify gaps for EarTrumpet.ColorTool/EarTrumpet.ColorTool.csproj
• [ ] Document prerequisites (Visual Studio workloads, .NET SDK versions needed)
• [ ] Add step-by-step instructions to build ColorTool separately and run it
• [ ] Document how ColorTool output is consumed by main EarTrumpet application
• [ ] Add troubleshooting section for common ColorTool build failures

Add automated asset validation workflow for Windows package icons and tile sizes

The EarTrumpet.Package/Assets/ directory contains many scale variants (100, 125, 150, 200, 400) and formats (png, altform, targetsize) for Store compliance. No CI validates these follow Microsoft's UWP asset requirements, risking Store submission failures due to missing or incorrectly-sized images.

• [ ] Create .github/workflows/asset-validation.yml
• [ ] Add step to verify all required icon sizes exist (16, 24, 32, 48, 256 px)
• [ ] Add step to verify all scale variants (100, 125, 150, 200, 400) exist for main tiles
• [ ] Add image dimension validation using a tool like ImageMagick or python pillow
• [ ] Add check for naming convention compliance per Microsoft Store guidelines
• [ ] Trigger on PR changes to EarTrumpet.Package/Assets/ directory

• Add localization strings for a missing language: the project uses Crowdin for i18n (mentioned in README) but currently supports 20+ languages—pick an unsupported locale and add .resx resource files for it in the main package's Properties/ directory, following the pattern of existing translations.
• Expand the ColorTool utility: ColorViewModel.cs and ColorItemViewModel.cs are minimal; add a feature to export/import color presets as JSON files (matching the Fluent Design color palette) and wire it into MainWindow.xaml buttons—this improves theming workflow.
• Document the Core Audio API integration: README mentions 'multi-channel aware peaking' but the audio visualization logic is not exposed in the top-60 files; create a ARCHITECTURE.md explaining how WASAPI (Windows Audio Session API) is used for per-app volume control, device enumeration, and metering.

The EarTrumpet codebase shows moderate security posture with one critical concern: a certificate private key file (.pfx) appears to be in version control, which poses immediate risk. Additional medium-severity issues include unreviewed PowerShell scripts for package installation and CI/CD pipeline security. The WPF/UWP application architecture introduces XAML deserialization risks. No hardcoded secrets or SQL injection patterns are immediately evident from file structure alone. Recommend: (1) Immediately remove and rotate the exposed certificate, (2) audit all PowerShell and CI/CD workflows, (3) validate XAML handling security, (4) implement comprehensive security scanning in the build pipeline.

• High · Certificate Private Key Exposure — EarTrumpet.Package/EarTrumpet.Package_StoreKey.pfx. The file 'EarTrumpet.Package/EarTrumpet.Package_StoreKey.pfx' appears to be a certificate private key file (.pfx). If this is a real certificate with a private key, committing it to version control represents a critical security risk. This key could be used to sign malicious packages or impersonate the application. Fix: Remove the .pfx file from the repository immediately. Store certificate private keys in secure vaults (Azure Key Vault, GitHub Secrets). Add *.pfx to .gitignore. Consider rotating the certificate if this key was exposed.
• Medium · Potential Unvalidated PowerShell Scripts in Chocolatey Package — .chocolatey/tools/. The Chocolatey installation scripts (.chocolateyinstall.ps1, .chocolateybeforemodify.ps1, .chocolateyuninstall.ps1) may contain code that executes with elevated privileges. Without visible code review, there's potential for injection vulnerabilities if any user input is processed unsanitized. Fix: Review all PowerShell scripts for: 1) Input validation and sanitization, 2) Avoid using Invoke-Expression or similar dynamic code execution, 3) Use explicit parameter validation, 4) Apply principle of least privilege.
• Medium · Missing HTTPS Enforcement in CI/CD — .github/workflows/main.yml, .github/workflows/sponsors.yml, .github/workflows/translators.yml. The presence of multiple workflow files (.github/workflows/) suggests CI/CD pipelines. Without reviewing the actual workflow content, there's risk of insecure artifact handling, missing credential validation, or unencrypted secret transmission. Fix: Ensure all GitHub Actions workflows: 1) Use HTTPS for all external dependencies, 2) Validate artifact signatures and checksums, 3) Use GitHub's encrypted secrets feature, 4) Implement OIDC token authentication where possible, 5) Audit third-party actions for vulnerabilities.
• Low · Potential Information Disclosure via Package Metadata — EarTrumpet.Package/Package.StoreAssociation.xml, EarTrumpet.Package/Package.xml. The file 'EarTrumpet.Package/Package.StoreAssociation.xml' and 'Package.xml' may contain sensitive metadata about the application distribution or store association details. Fix: Review these configuration files to ensure no sensitive information (internal identifiers, developer accounts, telemetry keys) is exposed. Consider if these files should be in version control or stored in secure configuration management.
• Low · XAML Deserialization Risk — EarTrumpet.ColorTool/ (and throughout the codebase). The presence of numerous .xaml files (UI markup) and corresponding .xaml.cs files suggests WPF/UWP application. XAML deserialization can be exploited if untrusted XAML is processed without proper validation. Fix: Ensure: 1) XAML parsing only occurs for trusted, internal markup files, 2) External XAML sources are validated before parsing, 3) Use XamlReader with safe settings, 4) Implement input validation for any dynamic XAML generation.

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.