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/killercup/cargo-edit 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
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 95% 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 killercup/cargo-edit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/killercup/cargo-edit.

What it runs against: a local clone of killercup/cargo-edit — 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 killercup/cargo-edit | 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 ≤ 50 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "killercup/cargo-edit(\\.git)?\\b" \\
  && ok "origin remote is killercup/cargo-edit" \\
  || miss "origin remote is not killercup/cargo-edit (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 "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "src/manifest.rs" \\
  && ok "src/manifest.rs" \\
  || miss "missing critical file: src/manifest.rs"
test -f "src/bin/add/add.rs" \\
  && ok "src/bin/add/add.rs" \\
  || miss "missing critical file: src/bin/add/add.rs"
test -f "src/bin/upgrade/upgrade.rs" \\
  && ok "src/bin/upgrade/upgrade.rs" \\
  || miss "missing critical file: src/bin/upgrade/upgrade.rs"
test -f "src/dependency.rs" \\
  && ok "src/dependency.rs" \\
  || miss "missing critical file: src/dependency.rs"

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

cargo-edit is a Rust CLI utility that extends Cargo with subcommands (cargo upgrade, cargo set-version, and historically cargo add/cargo rm) to manage dependencies directly from the command line by parsing and modifying Cargo.toml files. It solves the problem of tedious manual version bumping and dependency management in Rust projects, providing programmatic alternatives to manual text editing. Four independent subcommand binaries under src/bin/ (add/, rm/, upgrade/, set-version/), each with its own cli.rs, main.rs, and logic file (add.rs, rm.rs, upgrade.rs, set_version.rs). Shared utilities in src/lib.rs expose core modules: manifest.rs (Cargo.toml parsing/manipulation), dependency.rs (dependency representation), fetch.rs (crate metadata fetching), registry.rs (crates.io integration), and version.rs (semver handling). Tests in tests/ use snapshot-style comparisons with input/output Cargo.toml files.

Rust developers who want to upgrade, downgrade, or modify their project dependencies via CLI without manually editing Cargo.toml. Particularly useful for CI/CD pipelines, batch dependency updates, and developers who prefer command-line workflows over text editing.

Production-ready and actively maintained. The project has been around long enough to integrate cargo add (v1.62+) and cargo rm (v1.66+) into official Cargo, indicating successful feature maturity. It has proper CI/CD via GitHub Actions (build.yml, release.toml), comprehensive test coverage in tests/ directory, and recent releases (currently at v0.13.10). However, it is no longer in heavy active development as core features have been upstreamed.

Low risk for stable operations. The codebase is relatively lightweight (~212KB Rust), has minimal external dependencies (cargo_metadata 0.23.1, concolor-control 0.0.7, reqwest via tame-ind), and includes snapshot tests (cargo-set-version tests with .term.svg files). Main risk: single-author maintenance patterns visible in git history, but community contributions are welcomed per CONTRIBUTING.md. Breaking changes are unlikely given features have stabilized into official Cargo.

Maintenance mode with focus on cargo upgrade and cargo set-version subcommands (cargo add and cargo rm are officially deprecated in favor of built-in Cargo). The project uses automated release workflows (post-release.yml, release-notes.py) and changelog-driven versioning (CHANGELOG.md, release.toml). No active feature development visible—effort is stabilization and dependency updates.

git clone https://github.com/killercup/cargo-edit
cd cargo-edit
cargo build --all-features
cargo install --path . --all-features

On Ubuntu, ensure libssl-dev and pkg-config are installed. Requires rustc 1.44+.

Daily commands:

cargo upgrade                          # Upgrade all dependencies
cargo upgrade -p serde@>=0.9,<2.0    # Upgrade specific crate with version constraint
cargo set-version 0.14.0              # Bump package version in Cargo.toml
cargo set-version --dry-run           # Preview changes without writing

For development: cargo test runs integration tests in tests/, cargo build --all-features compiles all subcommands.

• src/lib.rs — Core library entry point exporting all public APIs; all contributors must understand the public interface and module organization
• src/manifest.rs — Handles Cargo.toml parsing and manipulation; critical for any feature modifying dependencies
• src/bin/add/add.rs — Implements cargo-add subcommand logic; most common user-facing operation for adding dependencies
• src/bin/upgrade/upgrade.rs — Implements cargo-upgrade subcommand logic; handles version resolution and crate registry interaction
• src/dependency.rs — Defines the Dependency struct and version resolution logic; foundational for all dependency operations
• src/registry.rs — Manages crate registry queries and version fetching; critical for upgrade and add operations
• Cargo.toml — Project manifest with all dependencies; defines build configuration and binary targets

Add a New Subcommand

1. Create new subcommand directory and files at src/bin/{subcommand}/ (src/bin/{subcommand}/main.rs)
2. Define CLI argument structure in cli.rs using clap or similar (src/bin/{subcommand}/cli.rs)
3. Implement business logic in {subcommand}.rs that uses public APIs from src/ (src/bin/{subcommand}/{subcommand}.rs)
4. Call the subcommand from main.rs and handle errors (src/bin/{subcommand}/main.rs)
5. Add binary target to Cargo.toml [[bin]] section with same name (Cargo.toml)

Support a New Registry Source

1. Extend Registry trait with new registry-specific methods if needed (src/registry.rs)
2. Create new struct implementing Registry trait (e.g., struct MyRegistry) (src/registry.rs)
3. Implement async methods: latest_version(), versions(), to fetch metadata from your registry (src/registry.rs)
4. Update Dependency::fetch_latest() to instantiate your registry type (src/dependency.rs)
5. Add integration tests in tests/ with sample registry responses (tests/)

Enhance Version Resolution Logic

1. Examine current version matching logic in version.rs (src/version.rs)
2. Add new version constraint variants to version parsing (src/version.rs)
3. Update Dependency::matches_version() logic to handle new constraints (src/dependency.rs)
4. Add unit tests for new version constraint parsing (src/version.rs)

Add Support for New Manifest Features

1. Review current TOML structures in manifest.rs (src/manifest.rs)
2. Extend Manifest struct or dependency table representations (src/manifest.rs)
3. Update read_manifest() and write_manifest() to handle new fields (src/manifest.rs)
4. Update relevant subcommand logic (add.rs, upgrade.rs) to use new feature (src/bin/add/add.rs)
5. Add integration tests with sample Cargo.toml files (tests/cargo-set-version/)

• TOML (toml-rs crate) — Native format of Cargo.toml; enables direct parsing and serialization of manifest files without custom parsing
• Async Rust (tokio) — Network calls to crates.io registry require non-blocking I/O; allows fetching multiple crate versions concurrently
• clap CLI framework — Declarative argument parsing with validation, help text, and subcommand support; reduces boilerplate per subcommand
• Git2 (for index access) — Some registries provide sparse git indices; allows efficient querying without downloading entire registry

• Fetch metadata from crates.io API rather than git index by default

  • Why: Simpler network layer and faster for most users; avoids large git clones
  • Consequence: Dependency on crates.io availability; git index option available but not primary path

• Modify Cargo.toml in-place with TOML round-trip

  • Why: Preserves comments, formatting, and structure more reliably than re-writing entire file
  • Consequence: TOML library must preserve formatting; some edge-case formatting may be lost

• Single-threaded manifest mutation per operation

  • Why: Avoids race conditions when multiple subcommands run simultaneously
  • Consequence: Sequential operations on same manifest; no true parallel dependency resolution within one command

• Does not resolve transitive dependency conflicts; only manages direct dependencies in Cargo.toml
• Does not perform full build/compilation; only modifies manifest files
• Does not provide GUI or interactive TUI (command-line only)
• Does not handle authentication to private registries with API keys or credentials
• Does not manage workspace member creation or deletion (only version updates)

Feature flags required to build subcommands: cargo build --features upgrade or --all-features needed to compile cargo-upgrade and cargo-set-version binaries. Default features may not include all tools. TOML round-tripping: manifest.rs must preserve formatting/comments when modifying Cargo.toml; uses toml crate which may lose whitespace fidelity. Registry API rate limits: fetch.rs queries crates.io; no built-in retry logic visible, requests may fail on slow networks. Snapshot test updates: Integration tests under tests/ use golden file comparisons (.term.svg); modifying behavior requires explicit test file updates (see Contributing guidelines). Rust edition constraint: Edition 2024 is very recent; may cause issues with older Rust toolchains despite 1.44+ claim.

• Semantic Versioning (SemVer) constraints — cargo-edit parses and validates semver constraints (e.g., ^1.2.3, >=0.9,<2.0) to determine valid upgrade paths; core to dependency version resolution in src/version.rs and src/dependency.rs
• TOML parsing and serialization — Cargo.toml files are TOML format; cargo-edit must round-trip (parse and rewrite) TOML while preserving comments/whitespace, implemented in src/manifest.rs using the toml crate
• Crates.io Registry API (JSON REST) — src/registry.rs and src/fetch.rs query crates.io REST API to fetch available versions and metadata; critical for upgrade command to find latest versions
• Cargo.lock vs Cargo.toml distinction — cargo-edit modifies Cargo.toml (manifest), not Cargo.lock (lock file); users must understand this differs from cargo update which updates .lock. Explained in README under cargo-upgrade differences.
• Golden file / snapshot testing — Integration tests in tests/cargo-set-version/ use snapshot comparisons (in/ vs out/ Cargo.toml files, .term.svg terminal output); maintainers must manually verify and update golden files when behavior changes
• Feature flags (Cargo features) — Cargo.toml uses required-features per [[bin]] to conditionally compile subcommands (add/rm/upgrade/set-version); allows minimal builds for users who only need specific tools
• cargo_metadata crate for workspace introspection — Dependency (cargo_metadata 0.23.1) provides structured access to Cargo project metadata (dependencies, versions, workspaces); used to query current dependency state before upgrades

• rust-lang/cargo — Official Cargo implementation; cargo-edit's cargo add and cargo rm were upstreamed into Cargo 1.62 and 1.66. This repo is the historical predecessor for those features.
• tamasfe/ra-multiplex — Another Cargo plugin CLI tool; demonstrates pattern for extending Cargo with custom subcommands via Rust binaries.
• EmbarkStudios/cargo-deny — Peer Cargo plugin that validates and audits dependencies; complements cargo-edit for dependency management workflows.
• rayon-rs/rayon — Frequently used dependency in Rust projects; example crate that cargo-edit users often upgrade or manage via this tool.
• serde-rs/serde — De facto standard serialization library in Rust; cargo-edit itself uses serde patterns indirectly through toml crate for Cargo.toml manipulation.

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 integration tests for cargo-add subcommand

The test suite in tests/ has comprehensive coverage for cargo-set-version with organized test cases (downgrade_error, dry_run, ignore_dependent, etc.), but cargo-add lacks similar structured integration tests. This would improve reliability and catch regressions when modifying src/bin/add/add.rs and src/bin/add/cli.rs.

• [ ] Create tests/cargo-add/ directory structure mirroring tests/cargo-set-version/
• [ ] Add test cases for: basic dependency addition, version specification, git dependencies, path dependencies
• [ ] Create in/out Cargo.toml fixtures and src/lib.rs stubs for each test case
• [ ] Add mod.rs files following the pattern in tests/cargo-set-version/downgrade_error/mod.rs
• [ ] Generate stdout/stderr snapshot files using the existing test infrastructure

Add integration tests for cargo-rm subcommand

Similar to cargo-add, the cargo-rm command (src/bin/rm/rm.rs and src/bin/rm/cli.rs) lacks structured integration tests. Testing dependency removal with various scenarios (dev-dependencies, optional features, workspace members) would ensure the feature works reliably.

• [ ] Create tests/cargo-rm/ directory with test subdirectories (remove_dev_dep, remove_optional, remove_with_workspace, etc.)
• [ ] Create in/out fixtures showing before/after Cargo.toml states for each scenario
• [ ] Implement mod.rs test harness following tests/cargo-set-version/mod.rs pattern
• [ ] Add error case tests (removing non-existent dependency, malformed arguments)

Add missing test coverage for cargo-upgrade with workspace scenarios

The tests/cargo-set-version/ directory shows comprehensive workspace testing (ignore_dependent pattern), but tests/cargo-upgrade appears to be missing from the file structure. Given src/bin/upgrade/upgrade.rs handles complex version resolution, workspace scenarios should be explicitly tested to prevent regressions.

• [ ] Create tests/cargo-upgrade/ directory structure
• [ ] Add test cases for: basic upgrade, workspace member upgrades, pre-release handling, dry-run mode
• [ ] Include workspace fixtures with multiple Cargo.toml files demonstrating workspace dependency handling
• [ ] Reference src/bin/upgrade/cli.rs flags in test scenarios (--aggressive, --allow-prerelease, etc.)
• [ ] Ensure tests validate that src/dependency.rs and src/version.rs version logic works correctly across workspace packages

• Add integration tests for cargo-set-version with invalid semver inputs (e.g., 'cargo set-version notaversion'). Currently no test visible in tests/cargo-set-version/ covering error cases beyond downgrade_error.: tests/cargo-set-version/ and src/bin/set-version/errors.rs: Small—pattern already exists in downgrade_error test directory
• Document the feature flag system in CONTRIBUTING.md or README. Currently no explanation of why cargo build --features upgrade is needed or how to add a new feature-gated subcommand.: CONTRIBUTING.md and README.md: Trivial—add 5-10 lines explaining Cargo.toml [[bin]] + required-features pattern
• Add snapshot test for cargo-upgrade with --dry-run flag (parallel to set-version/dry_run). Tests directory shows only set-version tests; cargo-upgrade lacks similar dry-run validation.: tests/cargo-upgrade/ (new directory) and src/bin/upgrade/upgrade.rs: Medium—requires creating test structure and validating dry-run output formatting

The cargo-edit codebase has several configuration issues that require immediate attention. The primary concerns are the invalid Rust edition (2024) and malformed dependency declaration (tame-ind) which will prevent compilation. These are critical configuration errors rather than runtime security vulnerabilities. The project appears to be a legitimate Cargo utility with reasonable dependency choices, but the manifest issues need resolution. No obvious injection vulnerabilities, hardcoded secrets, or infrastructure misconfigurations were detected in the visible file structure. Regular dependency auditing and security policy documentation are recommended.

• High · Invalid Rust Edition in Cargo.toml — Cargo.toml - [package] section. The Cargo.toml specifies edition = '2024' which is not a valid Rust edition. Valid editions are 2015, 2018, and 2021. This will cause build failures and may indicate a configuration error or typo that could mask other issues. Fix: Change edition to a valid value: '2021' (recommended for modern projects) or '2018'. Verify this change against the actual codebase compatibility.
• High · Incomplete Dependency Declaration — Cargo.toml - [dependencies] section, 'tame-ind' entry. The dependency 'tame-ind' in Cargo.toml is incomplete - it has no version specification and no closing brace. This is a malformed dependency declaration that will prevent compilation. Fix: Complete the dependency declaration with proper version specification, e.g., 'tame-index = { version = "0.x.x" }' (assuming this was meant to be 'tame-index'). Verify the correct dependency name and version.
• Medium · Dependency on Unsigned/Unverified Package — Cargo.toml - [dependencies] section. The crate relies on 'cargo_metadata' (version 0.23.1) which provides metadata about cargo projects. While this is a legitimate use case for cargo-edit, ensure the version is up-to-date as older versions may contain unpatched vulnerabilities. Fix: Regularly audit and update dependencies using 'cargo audit' and 'cargo outdated'. Consider pinning to specific tested versions rather than using flexible version constraints.
• Low · Potential Feature Flag Configuration Issue — Cargo.toml - [[bin]] sections. Multiple binary targets require specific feature flags (add, rm, upgrade, set-version) but no [features] section is visible in the provided Cargo.toml snippet. This could lead to incomplete builds if features are not properly defined. Fix: Verify that all required features (add, rm, upgrade, set-version) are properly defined in a [features] section of Cargo.toml. Ensure default features are correctly configured.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md or security policy file is visible in the repository structure, making it unclear how users should report security vulnerabilities. Fix: Create a SECURITY.md file documenting the vulnerability disclosure process and contact information for security issues. Consider adding a .github/SECURITY.md as well.

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.