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/mamba-org/mamba 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 the board

• Last commit 4d ago
• 14 active contributors
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 74% 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 mamba-org/mamba repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mamba-org/mamba.

What it runs against: a local clone of mamba-org/mamba — 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 mamba-org/mamba | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mamba-org/mamba(\\.git)?\\b" \\
  && ok "origin remote is mamba-org/mamba" \\
  || miss "origin remote is not mamba-org/mamba (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause 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"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "libmamba/CMakeLists.txt" \\
  && ok "libmamba/CMakeLists.txt" \\
  || miss "missing critical file: libmamba/CMakeLists.txt"
test -f "libmamba-spdlog/include/mamba/spdlog/logging_spdlog.hpp" \\
  && ok "libmamba-spdlog/include/mamba/spdlog/logging_spdlog.hpp" \\
  || miss "missing critical file: libmamba-spdlog/include/mamba/spdlog/logging_spdlog.hpp"
test -f "docs/source/developer_zone/internals.rst" \\
  && ok "docs/source/developer_zone/internals.rst" \\
  || miss "missing critical file: docs/source/developer_zone/internals.rst"
test -f "CONTRIBUTING.rst" \\
  && ok "CONTRIBUTING.rst" \\
  || miss "missing critical file: CONTRIBUTING.rst"

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

Mamba is a C++ reimplementation of the conda package manager that dramatically accelerates dependency resolution and package installation through parallel downloading, libsolv-based solver integration, and native C++ performance. It maintains conda compatibility while offering both a full-featured mamba distribution and a statically-linked micromamba standalone executable for containerized/CI environments. Hybrid C++/Python monorepo: core solver and package management in C++ (likely src/ directory with CMakeLists.txt at root), Python bindings via libmambapy for integration, CLI frontends in both languages. Build driven by CMake (CMakeLists.txt, CMakePresets.json, cmake/ modules). Development split between Unix (cmake/unix_impl.yml) and Windows (windows_impl.yml) implementations with shared core logic.

Data scientists, DevOps engineers, and CI/CD practitioners who use conda/conda-forge ecosystems but need faster package resolution and installation, particularly those building containerized environments or requiring minimal dependencies. Contributors typically come from the conda-forge community and have C++/Python polyglot experience.

Production-ready and actively maintained. The codebase shows 5M+ lines of C++, comprehensive GitHub Actions CI across Windows/Unix (tests.yml, coverage.yml, static_build.yml), pre-commit hooks, and standard tooling (.clang-format, .flake8, CMake build system). Recent activity visible in workflow files and developer environment configs (dev/environment-dev.yml) indicates ongoing development with quality standards.

Low-to-moderate risk for production use, but C++ codebases carry inherent complexity. Dependency risk exists via libsolv integration (FindLibsolv.cmake) and multi-platform build complexity (Windows, Unix variants). The split between mamba and micromamba creates maintenance surface area. Watch for breaking changes in conda compatibility layers and monitor libsolv upstream.

Active CI/CD pipeline work evident from GitHub Actions workflows (label_check.yml, set_pr_label.yml, bot_issue_template.md indicating automated PR management). Static build optimization (static_build.yml) and coverage reporting (coverage.yml) are ongoing priorities. Dependabot configuration suggests dependency maintenance is automated and tracked.

git clone https://github.com/mamba-org/mamba.git
cd mamba
conda env create -f dev/environment-dev.yml
conda activate mamba-dev
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j$(nproc)

Daily commands:

# Development build
cd build && make
# Run micromamba (static build)
./micromamba --version
# Run tests
ctest

See dev/CMakePresets*.json for preset build configurations (Unix vs Mamba-specific variants).

• CMakeLists.txt — Root build configuration defining the entire project structure, dependencies, and compilation flags for mamba and micromamba across platforms.
• libmamba/CMakeLists.txt — Core library build configuration; defines libmamba as the foundational C++ package manager implementation that both mamba and micromamba depend on.
• libmamba-spdlog/include/mamba/spdlog/logging_spdlog.hpp — Logging abstraction layer used throughout the codebase; critical for debugging and observability in a complex package resolution system.
• docs/source/developer_zone/internals.rst — Developer documentation explaining mamba's internal architecture, solver, and package resolution logic that every contributor must understand.
• CONTRIBUTING.rst — Contribution guidelines and development workflow; essential onboarding document for all new contributors.
• libmamba/data/bin2header.py — Build-time utility that embeds activation scripts and data files into the binary; critical for understanding self-contained binary deployment.
• .github/workflows/tests.yml — CI/CD pipeline definition; shows how tests are run across platforms and which test suites gate merges.

Add a new command-line subcommand to mamba

1. Define command logic in libmamba C++ core (package resolution, package operations) (libmamba/CMakeLists.txt)
2. Expose C++ functionality via Python bindings or CLI interface in mamba entry point (CMakeLists.txt)
3. Add tests for the new command in test suite (.github/workflows/tests.yml)
4. Document the new command in user guide (docs/source/user_guide/mamba.rst)

Add a new dependency resolver or solver feature

1. Implement resolver logic in libmamba core using libsolv (libmamba/CMakeLists.txt)
2. Update package resolution documentation (docs/source/advanced_usage/package_resolution.rst)
3. Add solver tests to CI pipeline (.github/workflows/tests.yml)
4. Document API changes in solver documentation (docs/source/api/solver.rst)

Add a new platform-specific feature (Windows/Linux/macOS)

1. Implement platform detection and feature in libmamba C++ code (libmamba/CMakeLists.txt)
2. Add platform-specific activation script if needed (libmamba/data/activate.bat)
3. Add platform-specific tests to CI (.github/workflows/unix_impl.yml)
4. Update Windows or cross-platform workflow if needed (.github/workflows/windows_impl.yml)

Add logging/instrumentation to a component

1. Include logging header in component source files (libmamba-spdlog/include/mamba/spdlog/logging_spdlog.hpp)
2. Emit log calls using the configured spdlog interface (libmamba-spdlog/include/mamba/spdlog/logging_spdlog_impl.hpp)
3. Add tests verifying log output in test suite (libmamba-spdlog/tests/test_logging_spdlog.cpp)

• C++ (libmamba core) — Provides performance-critical package resolution and dependency solving much faster than pure Python conda; enables micromamba as lightweight standalone binary.
• libsolv (SAT solver) — Industry-standard dependency resolution library; handles complex constraint satisfaction for package compatibility across versions and platforms.
• CMake build system — Enables true cross-platform compilation (Windows, Linux, macOS) with consistent configuration; supports both shared libraries and static binary builds.
• spdlog logging — Fast, header-only C++ logging library; provides structured logging without runtime performance penalties in a performance-critical package manager.
• Shell scripts (bat, PowerShell, bash) — Platform-native activation and environment setup; integrates naturally with user shells without requiring additional runtime dependencies.

• Reimplemented conda in C++ instead of extending Python conda

  • Why: Achieves 10–100× faster package resolution and enables lightweight standalone binary (micromamba) with zero Python dependencies.
  • Consequence: Higher maintenance burden of two package managers; more complex codebase for contributors; compatibility testing against Python conda required.

• Single-threaded sequential downloads with parallel tarball extraction instead of concurrent downloads

  • Why: Simplifies progress reporting and error handling; reduces connection overhead from many parallel threads.
  • Consequence: Network latency is not fully parallelized; slower on high-latency connections; opportunities for further optimization.

• Static embedding of activation scripts in binary (via bin2header.py)

  • Why: Enables truly self-contained standalone executable; no external file dependencies; guarantees scripts match binary version.
  • Consequence: Requires rebuild to update activation logic; larger binary size; more complex build pipeline.

• Support both mamba (full-featured) and micromamba (lightweight standalone) from same codebase

  • Why: Reduces duplication; allows featureful Python-integrated tool and
  • Consequence: undefined

libsolv discovery: Ensure libsolv development headers are installed (FindLibsolv.cmake may fail silently on fresh systems without them). Multi-platform builds: Windows and Unix use distinct CMAKE_BUILD_TYPE and compiler chains; CrossPlatformCompile in cmake/Checks.cmake may have platform-specific bugs. Python binding version: libmambapy may require matching Python ABI version; check environment.yml carefully. Static linking for micromamba: static_build.yml reveals full static linking is non-trivial; missing -DCMAKE_EXE_LINKER_FLAGS=-static can cause runtime failures in containers. Conda compatibility lock: Mamba aims full conda CLI compatibility; breaking changes to conda's transaction format will require updates to compatibility layer.

• SAT Solver (Boolean Satisfiability) — Mamba's core advantage: libsolv uses SAT solving for dependency resolution, replacing conda's slower graph-traversal solver with a state-of-the-art constraint satisfaction engine
• libsolv Package Manager Library — The hidden engine in Mamba; understanding libsolv's API (constraint modeling, solution reporting) is essential for modifying the solver behavior or debugging resolution failures
• Cross-compilation & CMake Module System — Mamba targets Windows, macOS, and Linux from one codebase; CMake modules (cmake/modules/) handle platform detection, compiler flags, and dependency discovery across toolchains
• Static Linking & Binary Portability — Micromamba's key feature: static_build.yml and related configs enable shipping a single executable without runtime dependencies; requires careful dependency resolution and symbol management
• Conda Package Format & Transaction Semantics — Mamba must replicate conda's package validation, transaction ordering, and rollback guarantees; compatibility issues here break existing conda environments
• Parallel Multi-threaded I/O (libcurl) — Mamba's speed boost comes from parallel repository metadata and package downloads; thread pool coordination and progress reporting are non-trivial in package managers
• Python C++ Bindings (pybind11 likely) — libmambapy exposes C++ solver to Python CLI; understanding the C++/Python boundary is essential for debugging hangs or crashes in the binding layer

• conda/conda — Direct predecessor and compatibility reference; Mamba reimplements conda's CLI and transaction logic while replacing the dependency solver
• mamba-org/quetz — Official companion project in the mamba-org ecosystem; Quetz is the package server that works seamlessly with mamba as the client
• conda-forge/miniforge — Distributes mamba as a pre-configured conda/miniforge variant; primary deployment method for end users
• pypa/pip — Alternative Python package manager with overlapping goals; reference for Python-only environments versus conda's polyglot approach
• openSUSE/libsolv — Upstream dependency providing the SAT solver at Mamba's core; maintained by openSUSE for RPM package management

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 documentation for libsolv integration and dependency resolution internals

The repo has cmake/modules/FindLibsolv.cmake and docs/source/advanced_usage/package_resolution.rst, but there's no detailed documentation explaining how libsolv is integrated into mamba's solver, what the whatprovides.svg diagram represents, or how to contribute to solver logic. This is a high-friction area for new contributors wanting to understand the core solving mechanism.

• [ ] Expand docs/source/developer_zone/internals.rst with a 'Solver Architecture' section referencing cmake/modules/FindLibsolv.cmake
• [ ] Create docs/source/developer_zone/libsolv_integration.rst explaining the C++ binding layer to libsolv
• [ ] Document the whatprovides algorithm with docs/source/advanced_usage/whatprovides.rst referencing the existing SVG diagram
• [ ] Add code examples showing how to trace through a resolution problem using mamba's debug output

Implement missing pre-commit hooks for CMake and YAML validation

The repo has .pre-commit-config.yaml with flake8, isort, and markdownlint configured, but CMakePresets.json, CMakeLists.txt, and multiple YAML workflows (in .github/workflows/) lack automated linting. Given .cmake-format.json exists, cmake-format should be enforced pre-commit. This prevents formatting inconsistencies and CI failures.

• [ ] Add cmake-format pre-commit hook to .pre-commit-config.yaml pointing to .cmake-format.json configuration
• [ ] Add yamllint pre-commit hook to validate .github/workflows/*.yml and .readthedocs.yml
• [ ] Add CMakePresets.json validation using a JSON schema linter in .pre-commit-config.yaml
• [ ] Document the new hooks in CONTRIBUTING.rst with setup instructions

Add integration tests for cross-platform static builds referenced in workflows

The repo has .github/workflows/static_build.yml and dev/environment-micromamba-static.yml, but there's no documented test suite specifically for static build artifacts. The .github/workflows/windows_impl.yml and unix_impl.yml suggest platform-specific implementation details that should have explicit test coverage to catch regressions.

• [ ] Create tests/integration/test_static_builds.py with fixtures using dev/environment-micromamba-static.yml
• [ ] Add tests verifying static binary portability (e.g., dependency linking, library bundling) on both Unix and Windows
• [ ] Document static build testing procedures in docs/source/developer_zone/dev_environment.rst
• [ ] Create a GitHub Actions workflow (tests_static_artifacts.yml) that runs these integration tests on release branches

• Add docstring coverage for C++ libsolv wrapper classes (visible via Doxygen config in docs/Doxyfile); start in the main solver interface files to improve docs/source generation
• Expand test coverage for Windows-specific package resolution in .github/workflows/windows_impl.yml — currently Unix testing is more mature; add Windows-specific edge cases for path handling
• Document the migration path from conda to mamba in docs/source/ directory (referenced in readthedocs.yml); add troubleshooting for common conda environment compatibility issues

Mamba demonstrates reasonable security foundations with responsible disclosure (SECURITY.md), automated testing (CI/CD workflows), and dependency management (Dependabot). However, the security posture lacks explicit SAST integration in the visible CI/CD configuration, and the SECURITY.md could be more comprehensive. No critical vulnerabilities are evident from the static file structure analysis, but deeper code review and configuration audits of CMake, CI/CD workflows, and dependency chains are recommended. The C++ codebase should have automated security scanning integrated into the build pipeline.

• Low · Missing SECURITY.md disclosure details — SECURITY.md. While a SECURITY.md file exists, it only contains email addresses for responsible disclosure without clear response timelines or security policy details. Best practices recommend including expected response times, vulnerability handling procedures, and scope information. Fix: Expand SECURITY.md to include: expected response timeline (e.g., 48-72 hours), vulnerability severity classification, scope of security policy, and link to bug bounty program if applicable.
• Low · Dependabot configuration present but not fully visible — .github/dependabot.yml. A .github/dependabot.yml file exists, indicating dependency monitoring is configured. However, without viewing its contents, the specific settings and coverage of dependencies cannot be verified. Improper configuration could miss vulnerable dependencies. Fix: Review dependabot.yml to ensure: all package managers are covered (pip, npm, cargo, etc.), update frequency is appropriate, and security updates are prioritized.
• Low · Pre-commit hooks configured but content not reviewed — .pre-commit-config.yaml. A .pre-commit-config.yaml file exists which suggests security checks (linting, formatting) are in place. However, the specific hooks and their configurations cannot be verified from the file listing alone. Fix: Ensure pre-commit hooks include security scanning tools such as: bandit, semgrep, or similar SAST tools for the primary language (C++).
• Low · No visible static analysis in CI/CD pipeline — .github/workflows/. While .github/workflows directory contains multiple workflow files (tests.yml, coverage.yml, linters.yml), there is no explicit evidence of SAST (Static Application Security Testing) tools in the visible workflow names. Security scanning may not be automated. Fix: Add dedicated security scanning to CI/CD pipeline: integrate tools like CodeQL, Coverity, or clang-analyzer for C++ static analysis. Consider adding container scanning for Docker images if applicable.
• Low · CMake configuration files present - potential build system risks — CMakeLists.txt, cmake/ directory, dev/CMakePresets*.json. Multiple CMakeLists.txt and CMake configuration files exist throughout the project. CMake files can contain hard-coded paths, credentials, or unsafe external dependencies if not properly reviewed. Fix: Review all CMake files to: avoid hard-coded credentials or sensitive paths, use secure package sources, implement proper dependency verification, and validate external URLs.

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.