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/coreybutler/nvm-windows 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 3w ago
• 14 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 75% of recent commits
• ⚠ 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 coreybutler/nvm-windows repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/coreybutler/nvm-windows.

What it runs against: a local clone of coreybutler/nvm-windows — 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 coreybutler/nvm-windows | 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 | Last commit ≤ 52 days ago | Catches sudden abandonment since generation |

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

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

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

NVM for Windows is a Go-based Node.js version manager that lets Windows developers install, switch between, and manage multiple Node.js versions without conflicts. Unlike the original nvm (Mac/Linux-only), this Windows-specific implementation uses a different architecture optimized for Windows PATH manipulation and installer conventions, endorsed by Microsoft, npm, and Google. Mixed architecture: Go CLI application in src/ with modular packages (src/arch/, src/author/, src/encoding/, src/file/); Windows installer built with Inno Setup (nvm.iss, assets/buildtools/); automation and scripting in batch/VBS (assets/elevate.cmd, assets/setuserenv.vbs) for privilege escalation and environment setup. Build orchestration via build.js and GitHub Actions workflows.

Windows developers who need to work across multiple Node.js projects with different version requirements. Also used by DevOps engineers managing Node.js environments on Windows servers, and CI/CD systems targeting Windows builds.

Production-ready but transitioning. Current stable release is v1.1.12; the repo is actively maintained with v1.2.x as a transition version toward the successor 'Author' project. CI/CD workflows (release.yml, winget.yml, scanner.yml) and GitHub Actions automation indicate serious maintenance. However, the README signals the team is shifting focus to the broader 'Author' platform, so this repo may see slower feature development.

Low-to-medium risk. Single maintainer (coreybutler) is a concentration point. Go dependency count is small (7 direct, 12 indirect), reducing supply-chain risk. The transition toward 'Author' as the successor means this repo could enter maintenance-only mode. No test directory visible in file list suggests test coverage is minimal or absent, increasing regression risk on version management logic.

Active transition toward the 'Author' platform (visible in README and src/author/ package). Recent workflows include autotag.yml, winget.yml (Windows Package Manager distribution), and bot.yml (automation). The repository is not abandoned but is in a strategic shift phase away from pure NVM maintenance toward the broader Author ecosystem.

Clone and build with: git clone https://github.com/coreybutler/nvm-windows.git && cd nvm-windows && go mod download -C src && go build -C src. No npm/Node install needed for the core tool itself (it's pure Go), but Node.js is what nvm-windows manages, not what builds it.

Daily commands: Build the Go binary: cd src && go build -o nvm.exe. The resulting executable is the CLI tool. For development, test individual packages with go test ./... from the src/ directory. The installer (nvm.iss) requires Inno Setup compiler (iscc.exe, bundled in assets/buildtools/) and is built via build.js or GitHub Actions.

• src/go.mod: Declares Go 1.18 requirement and all direct dependencies (semver, fsutil, zenity, toast); critical for reproducible builds and dependency updates.
• nvm.iss: Inno Setup installer configuration; defines how NVM is packaged and installed on Windows, including registry keys and PATH setup.
• src/arch/arch.go: Core version detection and management logic; likely handles Node.js version listing, downloading, and switching.
• src/file/file.go: File system operations for Node.js binaries; handles downloads, extractions, and installation paths.
• assets/setuserenv.vbs: VBScript that modifies Windows user environment variables (PATH); essential for making switched Node versions available in new shells.
• src/author/bridge.go: Integration point to the successor 'Author' platform; signals strategic direction and future architecture.
• .github/workflows/release.yml: Automated release pipeline; shows how binaries are tested, signed, and distributed to GitHub and winget.
• build.js: Node.js build orchestration script; likely coordinates Go compilation, Inno Setup compilation, and artifact staging.

Core logic: src/arch/arch.go (version detection), src/file/file.go (node/npm downloads and installs), src/encoding/encoding.go (config parsing). Installer/UX: nvm.iss for Inno Setup installer steps; assets/elevate.* for privilege escalation flows; src/author/bridge.go for integration with Author platform. Automation: .github/workflows/ for CI/CD; build.js for build orchestration.

No visible test files: No src/**/*_test.go or testing/ directory in file list; adding tests requires understanding test conventions in this codebase. Elevation required: Many operations (PATH modification, registry changes) demand administrator privileges; setuserenv.vbs and elevate.cmd handle this, but local dev testing may fail without UAC bypass setup. Windows-only: Symlinks, PATH format, and elevation APIs are Windows-specific; cross-platform testing is impossible on non-Windows. Inno Setup learning curve: The installer (nvm.iss) uses ISS syntax and assets/buildtools/ custom DLLs; changes require Inno Setup knowledge, not just Go. Author migration: The codebase is in transition; src/author/ and README references suggest incomplete migration to the Author platform, creating potential for orphaned or conflicting code paths.

• Windows PATH environment variable manipulation — NVM's core mechanic is switching Node.js versions by reordering PATH entries; understanding how setuserenv.vbs modifies HKCU\Environment and broadcasts WM_SETTINGCHANGE is critical to understanding version switching behavior.
• User Access Control (UAC) and privilege escalation — modifying PATH and registry keys requires administrator privileges; assets/elevate.vbs and elevate.cmd implement UAC prompting, a Windows-specific pattern not present in Unix tools.
• Semantic Versioning (semver) parsing and comparison — The github.com/blang/semver dependency enables NVM to compare version strings (e.g., v16.13.0 vs v18.0.0) and resolve constraints; critical for 'use' commands and version listing.
• Windows installer frameworks (Inno Setup) — NVM is distributed as a .exe installer built with Inno Setup (nvm.iss); understanding ISS syntax, custom DLLs in assets/buildtools/, and the installation flow is essential for packaging and deployment.
• File system abstraction in Go (os.File, io/fs) — src/file/file.go handles downloading, verifying, and extracting Node.js binaries; Go's file I/O patterns and the coreybutler/go-fsutil wrapper are foundational to this operation.
• Windows Registry (HKEY_CURRENT_USER) — NVM reads and writes registry keys to manage Node.js paths and user environment settings; setuserenv.vbs leverages WScript.Shell.RegWrite for persistence.
• Cross-platform version constraint resolution — Users may specify versions as ranges (e.g., 16.x, >=14.0.0); the semver library and constraint matching logic in src/arch/arch.go resolve these to concrete releases.

• nvm-sh/nvm — The original Node.js version manager for Mac/Linux; spiritual predecessor and constant comparison point for NVM Windows features.
• coreybutler/author — The successor platform that NVM Windows is migrating toward; represents the future of Node.js version management on Windows.
• microsoft/nodejs-guidelines — Microsoft's official Node.js setup guidance; NVM Windows is the recommended tool in Microsoft docs, making this the authoritative reference.
• nvm-windows/nvm-windows — Community fork(s) and alternatives; other Windows Node managers that solve the same problem with different approaches.
• fnm-io/fnm — Fast Node Manager, a Rust-based version manager gaining traction on Windows; a modern alternative using a different language and approach.

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 semver package (src/semver/semver.go)

The semver package is critical for version comparison and management logic but has no visible test file (semver_test.go). This is a core component that determines which Node versions are installed/used. Adding comprehensive tests would catch regressions and make version matching logic verifiable, especially important given the dependency on github.com/blang/semver.

• [ ] Create src/semver/semver_test.go with test functions for version parsing, comparison, and range matching
• [ ] Test edge cases like pre-release versions, build metadata, and invalid version strings
• [ ] Ensure test coverage for semver operations used by src/node/node.go
• [ ] Run tests locally with 'go test ./src/semver' and add to CI pipeline

Add integration tests for node installation workflow (src/node/node.go)

The node package handles the critical path of downloading, installing, and managing Node versions. There's no visible test file (node_test.go) despite this being the core functionality. Integration tests would validate the full install/uninstall/switch lifecycle without mocking, catching real-world issues with file operations and version detection.

• [ ] Create src/node/node_test.go with integration tests for install, uninstall, and version switching
• [ ] Test interaction with file system operations from src/file/file.go and web downloads from src/web/web.go
• [ ] Add tests for error handling (corrupt downloads, permissions issues, disk space)
• [ ] Consider adding GitHub Actions workflow step to run node integration tests on Windows runners

Add GitHub Actions workflow for cross-platform build validation

Currently .github/workflows contains release.yml, scanner.yml, and winget.yml, but no dedicated workflow for validating Go builds on each pull request. With src/arch/arch.go handling architecture detection and the project supporting multiple Windows architectures, automated build validation ensures PRs don't break compilation for x86/x64/ARM.

• [ ] Create .github/workflows/build.yml that runs 'go build' for windows/amd64, windows/386, and windows/arm64 targets
• [ ] Add linting step using 'golangci-lint' or 'go vet' to catch code quality issues early
• [ ] Run tests from src/semver and src/node (once created) as part of PR validation
• [ ] Ensure workflow triggers on pull_request and push to main branch, reporting results on PRs

• Add semver-aware version constraint validation in src/arch/arch.go to warn users when installing deprecated Node.js versions (e.g., EOL versions). This improves UX without major refactoring and uses the existing github.com/blang/semver dependency.
• Create integration tests for src/file/file.go download and extraction logic by adding a src/file/file_test.go with mock HTTP responses and temp directory fixtures. This fills the visible gap in test coverage for the most critical operation (fetching Node.js binaries).
• Document the Inno Setup build process in CONTRIBUTING.md with step-by-step instructions for building nvm.iss locally, including how to invoke iscc.exe and what assets/buildtools/ contains. This lowers friction for Windows installer contributions.

• High · Outdated Go Version — src/go.mod. The project targets Go 1.18, which was released in March 2022 and is now significantly outdated. Go 1.18 has reached end-of-life and no longer receives security patches. Current Go versions (1.22+) include critical security fixes for various vulnerabilities. Fix: Update the Go version to the latest stable release (1.22 or higher). Run 'go mod tidy' after upgrading to ensure compatibility.
• High · Outdated Dependency: golang.org/x/sys — src/go.mod (golang.org/x/sys v0.25.0). The golang.org/x/sys v0.25.0 dependency is outdated. This package contains low-level system interfaces and has historically contained security vulnerabilities. The version specified (0.25.0) is from 2024 but may have known vulnerabilities. Fix: Update to the latest version of golang.org/x/sys using 'go get -u golang.org/x/sys'. Run security audits with 'go list -json -m all | nancy' to identify known vulnerabilities.
• Medium · Outdated Dependency: github.com/go-toast/toast — src/go.mod (github.com/go-toast/toast). The go-toast/toast library (v0.0.0-20190211030409-01e6764cf0a4) is pinned to a commit from 2019. This old timestamp suggests the package may not be actively maintained and could contain unpatched vulnerabilities. Fix: Check for active maintenance of this dependency. If available, upgrade to the latest version or consider replacing with a more actively maintained notification library.
• Medium · Outdated Dependency: github.com/ncruces/zenity — src/go.mod (github.com/ncruces/zenity v0.10.14). The zenity library is pinned to v0.10.14, which may be outdated. UI libraries are common targets for security issues, particularly those dealing with native dialogs and file operations. Fix: Update to the latest version of zenity using 'go get -u github.com/ncruces/zenity'. Review the changelog for security fixes.
• Medium · Outdated Dependency: github.com/saintfish/chardet — src/go.mod (github.com/saintfish/chardet). The chardet library is pinned to v0.0.0-20230101081208-5e3ef4b5456d. Character detection libraries can be vulnerable to DoS attacks or encoding-based exploits if not properly maintained. Fix: Verify the latest version is being used. Consider running 'go get -u github.com/saintfish/chardet' and test character encoding handling.
• Medium · Potential Command Execution Risks — assets/elevate.cmd, assets/elevate.vbs, assets/run.cmd, assets/setuserenv.vbs, assets/unsetuserenv.vbs. The project includes several shell script assets (elevate.cmd, elevate.vbs, run.cmd, setuserenv.vbs, unsetuserenv.vbs) that are executed as part of the installation/upgrade process. If these scripts process user-controlled input without proper validation, they could be vulnerable to command injection. Fix: Audit all shell scripts for input validation. Ensure environment variables and user paths are properly quoted and escaped. Use parameterized approaches instead of string concatenation for constructing commands.
• Medium · VBS Script Security Risks — assets/elevate.vbs, assets/setuserenv.vbs, assets/unsetuserenv.vbs. VBScript-based elevation scripts (elevate.vbs, setuserenv.vbs, unsetuserenv.vbs) are known attack vectors on Windows. These scripts execute with elevated privileges and could be exploited if not properly secured. Fix: Review VBScript code for injection vulnerabilities. Consider replacing with PowerShell scripts that support stricter execution policies. Digitally sign scripts where possible. Implement ASLR and DEP protections.
• Medium · Unsigned Installation Scripts — undefined. The 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.