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/google/or-tools 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 2d ago
• 8 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

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

What it runs against: a local clone of google/or-tools — 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 google/or-tools | 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 stable exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "google/or-tools(\\.git)?\\b" \\
  && ok "origin remote is google/or-tools" \\
  || miss "origin remote is not google/or-tools (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 stable >/dev/null 2>&1 \\
  && ok "default branch stable exists" \\
  || miss "default branch stable no longer exists"

# 4. Critical files exist
test -f "BUILD.bazel" \\
  && ok "BUILD.bazel" \\
  || miss "missing critical file: BUILD.bazel"
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "WORKSPACE.bzlmod" \\
  && ok "WORKSPACE.bzlmod" \\
  || miss "missing critical file: WORKSPACE.bzlmod"
test -f "MODULE.bazel" \\
  && ok "MODULE.bazel" \\
  || miss "missing critical file: MODULE.bazel"
test -f ".github/workflows/amd64_linux_bazel.yml" \\
  && ok ".github/workflows/amd64_linux_bazel.yml" \\
  || miss "missing critical file: .github/workflows/amd64_linux_bazel.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 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
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/google/or-tools"
  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).

Google OR-Tools is an open-source C++ library for solving combinatorial optimization problems at scale, providing constraint programming solvers (CP-SAT, legacy CP), linear programming solvers (Glop simplex, PDLP), and specialized algorithms for TSP/VRP, bin packing, and graph problems. It ships with production-grade Python, Java, C#, and Go bindings via SWIG, enabling developers to use high-performance optimization in their preferred language. Monolithic C++ core (ortools/base, ortools/algorithms, ortools/graph, ortools/linear_solver, ortools/glop, ortools/sat) with SWIG-generated language bindings. Three build systems in parallel: Makefile (legacy), CMake (recommended, ~384KB), and Bazel (BUILD.bazel, MODULE.bazel). Language-specific entry points: ortools/python for Python, ortools/java for JVM, ortools/dotnet for C#. Extensive samples under ortools/*/samples/ demonstrate solver usage per domain.

Operations research engineers, logistics companies optimizing vehicle routing and delivery schedules, supply chain planners solving bin packing and scheduling, and data scientists building optimization features into Python/Java applications who need commercial-grade solver performance without vendor lock-in.

Highly mature: Google-backed since inception, continuous CI/CD across 40+ GitHub Actions workflows covering Linux/macOS/Windows on x86/ARM, multiple build systems (Bazel/CMake/Make), and published to PyPI, NuGet, and Maven Central. Active development evident from extensive platform-specific workflows (aarch64_toolchain.yml, arm64_macos_*.yml) and system dependency integration tests.

Low risk for core optimization solvers, but multi-language support (C++/Python/Java/C#/Go via SWIG) creates maintainability complexity; SWIG bindings (.swg files) are fragile across major language version upgrades. Dependency on external solvers (SCIP, GLPK, CoinOR) via optional cmake flags means version pinning and licensing compliance are user responsibility. No single-point-of-failure risk given Google's investment.

Active multi-platform support expansion: recent workflows for ARM64 macOS (arm64_macos_cmake_*.yml), system dependency testing (amd64_linux_cmake_system_deps.yml), and FreeBSD compatibility (amd64_freebsd_cmake.yml). SCIP solver integration togglable via cmake (-DUSE_SCIP=ON). Presubmit and format checking automated (check_format.yml, presubmit.yml with clang-format enforcement).

git clone https://github.com/google/or-tools.git
cd or-tools
# CMake build (recommended for Python/Java/C++):
mkdir build && cd build
cmake -DBUILD_PYTHON=ON -DBUILD_JAVA=ON ..
make -j$(nproc)
# Or use Bazel:
bazel build //ortools/...
# Python wheel install (from PyPI):
pip install ortools

Daily commands:

# Development build with all tests:
bazel test //ortools/... --test_output=errors
# Python samples:
python3 ortools/linear_solver/samples/simple_lp_program.py
# C++ sample:
bazel run //ortools/sat/samples:simple_lp_solver
# Java sample (if built with BUILD_JAVA=ON):
java -cp bazel-bin/ortools/java/com/google/ortools/Loader.jar:... SimpleVrp

• BUILD.bazel — Root Bazel build configuration; defines the entire build system and all target dependencies across the project.
• CMakeLists.txt — Root CMake configuration; alternative build system entry point required for cross-platform C++/Java/.NET builds.
• WORKSPACE.bzlmod — Bazel workspace and module definitions; declares all external dependencies and workspace layout.
• MODULE.bazel — Bazel module configuration for dependency management; critical for version pinning and transitive dependency resolution.
• .github/workflows/amd64_linux_bazel.yml — Primary CI/CD pipeline; validates that the core Bazel build and Linux platform work for every commit.
• cmake/CMakeLists.txt — CMake build orchestration; mirrors Bazel functionality for developers using CMake on Windows/macOS/Linux.
• Version.txt — Single source of truth for OR-Tools version; referenced by all build systems and package managers.

Add a new C++ solver target

1. Define the new solver library in the appropriate BUILD.bazel file with cc_library rule. (BUILD.bazel)
2. Add CMake equivalent cc_library target in the corresponding CMakeLists.txt. (CMakeLists.txt)
3. If using external solver (e.g., proprietary solver), create FindXXX.cmake module in cmake/ directory. (cmake/FindSCIP.cmake)
4. Add solver dependency to Dependencies.txt for documentation. (Dependencies.txt)
5. Create a GitHub Actions workflow to test the new solver on Linux, Windows, and macOS. (.github/workflows/amd64_linux_bazel.yml)

Add Python bindings for a new C++ module

1. Create a .i SWIG interface file defining the C++ → Python translation layer. (bazel/swig_java.bzl)
2. Define Bazel py_library and swig rules in BUILD.bazel to generate Python bindings. (BUILD.bazel)
3. Add corresponding CMake targets using SWIG.CMakeLists.txt.in template. (cmake/dependencies/SWIG.CMakeLists.txt.in)
4. Update the Python package build workflow to include new module in wheel distribution. (.github/workflows/amd64_linux_cmake_python.yml)
5. Verify Python bindings build in the PyPI distribution workflow. (.github/workflows/amd64_macos_cmake_python.yml)

Add support for a new Linux distribution

1. Create a new Dockerfile in bazel/docker/ or cmake/docker/ for the target distribution. (bazel/docker/ubuntu/Dockerfile)
2. Install necessary build tools, compilers, and OR-Tools dependencies in the Dockerfile. (cmake/docker/almalinux/Dockerfile)
3. Create a GitHub Actions workflow YAML file for CI on the new distribution. (.github/workflows/amd64_docker_bazel.yml)
4. Update .bazelrc or cmake/ccache.cmake if new distribution requires different compiler flags. (.bazelrc)
5. Test the workflow against the new Docker image to validate build and test success. (.github/workflows/presubmit.yml)

Release a new version of OR-Tools

1. Update Version.txt with the new semantic version number. (Version.txt)
2. Verify all CI/CD workflows pass for Linux, Windows, and macOS builds. (.github/workflows/amd64_linux_bazel.yml)
3. Ensure Python wheels are built and published to PyPI via the Python workflow. (.github/workflows/amd64_linux_cmake_python.yml)
4. Verify NuGet package (.NET) is built and published to NuGet.org. (.github/workflows/amd64_windows_cmake_dotnet.yml)
5. Confirm Maven package (Java) is published to Maven Central. (.github/workflows/amd64_linux_cmake_java.yml)

• Bazel — Provides hermetic, reproducible builds with fine-grained dependency management across C++, Python, Java, and .NET; critical for multi-language monorepo.
• CMake — Standard build system for C++ projects; enables OR-Tools to integrate into enterprise and academia workflows that rely on CMake-based builds.
• SWIG — Auto-generates language bindings (Python, Java, .NET) from C++ interface files; reduces hand-written wrapper code and maintains API consistency.
• GitHub Actions — Tight integration with GitHub; enables matrix testing across OS (Linux/macOS/Windows) and architectures (amd64/arm64) without external CI infrastructure.
• Docker — Standardizes build environments across distributions; ensures reproducibility and allows testing on AlmaLinux, Debian, Ubuntu, Alpine without host machine impact.

SWIG version sensitivity: Python/Java bindings require specific SWIG versions (check Dockerfile for pinned version); mismatches cause silent runtime failures. Solver licensing: SCIP requires SCIPOptSuite license agreement if linked; default build excludes it (USE_SCIP=OFF) to avoid compliance issues. Multi-arch build cache: Bazel caches are arch-specific; cross-compiling (e.g., x86→ARM) requires clean rebuild. Python version mismatch: wheels on PyPI are versioned per Python release; pip install ortools on Python 3.13 may fail if not yet built. Protobuf version lock: .proto files tied to specific protobuf compiler version; upgrading protoc without regenerating *.pb.cc breaks builds.

• Constraint Programming (CP-SAT) — OR-Tools' flagship solver uses SAT relaxation and lazy constraint propagation; understanding CP vs. LP fundamentals helps you choose the right solver for scheduling, assignment, and combinatorial problems
• Simplex Algorithm (Glop) — OR-Tools' linear programming solver Glop implements revised simplex with pricing strategies; knowing simplex internals helps you diagnose LP solver convergence issues and numerical stability problems
• Vehicle Routing Problem (VRP) — OR-Tools routing.h solves TSP/VRP variants with time windows and capacity constraints; VRP is the main real-world use case in logistics, so understanding problem formulation is essential for deployment
• Integer Linear Programming (ILP/MIP) — OR-Tools wraps multiple ILP solvers (SCIP, CoinOR Cbc); ILP models many practical optimization problems but are NP-hard, so understanding relaxations and branch-and-bound is critical for troubleshooting performance
• SWIG Language Bindings — OR-Tools uses SWIG .i files to auto-generate Python/Java/C# wrappers from C++ headers; understanding SWIG's type mapping and %include directives is necessary when extending bindings or debugging binding bugs
• Protocol Buffers (Protobuf) — OR-Tools solver models (CPModelProto, LinearProto) are defined as .proto messages; Protobuf serialization enables language-agnostic model passing and logging, so knowing .proto syntax is required for model inspection
• Min-Cost Max-Flow — OR-Tools graph algorithms include min-cost flow solvers; many optimization problems (assignment, circulation, generalized flow) reduce to min-cost flow, making this a powerful modeling pattern

• coin-or/Cbc — Mixed-integer linear programming solver that OR-Tools wraps as optional backend; Cbc is the open-source MIP solver OR-Tools delegates to when COIN-OR is enabled
• scipopt/scip — Constraint integer programming solver integrated as optional OR-Tools solver; SCIP provides tighter bounds for difficult integer programs than OR-Tools' native solvers
• google/absl-cpp — Abseil C++ foundational library used throughout OR-Tools for status codes, logging, and container utilities; required dependency for building
• protocolbuffers/protobuf — Serialization format for OR-Tools solver models (cp_model.proto, linear_solver.proto); .proto schemas are the API contracts between language bindings
• optlang/optlang — Python symbolic optimization modeling layer that uses OR-Tools as execution backend; provides higher-level modeling API compared to ortools-python's direct solver calls

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 CI workflow for arm64 Linux CMake builds

The repo has extensive CI coverage for arm64 macOS (arm64_macos_.yml) and aarch64 toolchain testing, but is missing arm64 Linux CMake workflows. Given the presence of amd64_linux_cmake_.yml variants (python, java, dotnet, cpp, glpk, coinor, system_deps, scip variants) and the multiplatform nature of OR-Tools, adding arm64 Linux equivalents would improve cross-platform reliability and catch ARM-specific issues early.

• [ ] Create .github/workflows/arm64_linux_cmake_cpp.yml based on amd64_linux_cmake_cpp.yml pattern
• [ ] Create .github/workflows/arm64_linux_cmake_python.yml for Python bindings on ARM64 Linux
• [ ] Create .github/workflows/arm64_linux_cmake_java.yml for Java bindings on ARM64 Linux
• [ ] Ensure workflows use appropriate arm64 Linux runner or qemu emulation setup
• [ ] Reference existing arm64_macos_cmake_*.yml for consistency in job structure

Add missing Dockerfile validation and security scanning workflow

The repo maintains multiple Dockerfiles in bazel/docker/ for different Linux distributions (almalinux, alpine, archlinux, debian, fedora, opensuse) plus .github/workflows/Dockerfile, but lacks a CI workflow to validate and scan these for security vulnerabilities. This is critical for a widely-used optimization library where users may build custom Docker images.

• [ ] Create .github/workflows/docker_security_scan.yml
• [ ] Add hadolint linting for all Dockerfiles in bazel/docker/*/Dockerfile
• [ ] Integrate container image scanning (e.g., Trivy) for the built Docker images
• [ ] Validate that each Dockerfile builds successfully without errors
• [ ] Test that the base OR-Tools binaries work correctly in each Docker variant

Add FreeBSD CMake Python and Java binding workflows

The repo has amd64_freebsd_cmake.yml for C++ testing but lacks FreeBSD Python and Java binding workflows. Since the repo publishes PyPI and Maven packages, testing FreeBSD compatibility for these language bindings is valuable. The existing pattern in amd64_linux_cmake_.yml and amd64_macos_cmake_.yml variants provides a clear template.

• [ ] Create .github/workflows/amd64_freebsd_cmake_python.yml for Python bindings on FreeBSD
• [ ] Create .github/workflows/amd64_freebsd_cmake_java.yml for Java bindings on FreeBSD
• [ ] Follow the test structure from amd64_linux_cmake_python.yml and amd64_linux_cmake_java.yml
• [ ] Ensure FreeBSD runner availability or use appropriate VM setup
• [ ] Validate Maven and pip package integrity on FreeBSD

• Add missing unit tests for ortools/algorithms/samples/ (sample files exist but most lack corresponding test_*.cc files in ortools/algorithms/ directory). Good entry point: write a simple test that instantiates a sampler and validates output shape.
• Document cmake configuration flags (USE_SCIP, BUILD_PYTHON, BUILD_JAVA, etc.) in a CMake-specific README under cmake/; currently scattered across CMakeLists.txt comments. Helps new Windows/macOS users understand available options.
• Implement Go binding generation: go.proto SWIG template and ortools/go/ module exist but are incomplete; finish wrapping routing.h and sat/cp_model.proto for Go users (see ortools/java/com/google/ortools/ for reference structure).

The OR-Tools repository has a moderate security posture with some areas requiring attention. The primary concerns are outdated Java version (1.8) in the build configuration, insecure dependency version ranges without upper bounds, and potential Docker image supply chain risks from unpinned base images. The project shows good practices with Dependabot configuration visible (.github/dependabot.yml) and multiple security workflow checks. Recommended actions: (1) upgrade Java compiler target to 11+, (2) pin Maven dependency versions with upper bounds, (3) use Docker image digests instead of tags, and (4) implement comprehensive CODEOWNERS and branch protection policies.

• High · Insecure Dependency Version Range in pom.xml — Dependencies/pom.xml - JUnit dependency. The Maven pom.xml uses a version range [4.13.1,) for JUnit without an upper bound. This allows any version >= 4.13.1 to be used, including potentially vulnerable future versions. Version ranges without upper bounds can introduce breaking changes or security issues. Fix: Specify an explicit upper bound for the dependency version, e.g., [4.13.1,4.14) or use a fixed version like 4.13.2. Regularly audit and update dependencies to patch security vulnerabilities.
• Medium · Outdated Maven Compiler Target — Dependencies/pom.xml - maven.compiler.source and maven.compiler.target properties. The pom.xml specifies Java 1.8 as both source and target compiler version. Java 8 reached end-of-life in March 2022 and no longer receives security updates. This exposes the project to known Java vulnerabilities. Fix: Upgrade to a supported Java LTS version (11, 17, or 21). Update maven.compiler.source and maven.compiler.target to at least 11.
• Medium · Multiple Docker Workflow Files Without Base Image Pinning — .github/workflows/Dockerfile and bazel/docker/* Dockerfile files. The repository contains numerous Docker workflow files (.github/workflows/Dockerfile and docker configuration files) that likely use unpinned base images. This can lead to supply chain attacks if base images are compromised or contain vulnerabilities. Fix: Pin all Docker base images to specific digest hashes (e.g., FROM ubuntu@sha256:...) rather than using tags. Regularly scan base images for vulnerabilities and update digests when security patches are released.
• Low · No CODEOWNERS File for Access Control — .github/. The repository structure shows .github/ISSUE_TEMPLATE but no CODEOWNERS file is mentioned. This makes it difficult to enforce code review requirements and security controls over sensitive components. Fix: Create a .github/CODEOWNERS file to assign review requirements for critical paths (security, cryptography, build scripts). This helps ensure security-sensitive changes are reviewed by appropriate team members.
• Low · Potential Security Configuration Gaps in CI/CD — .github/workflows/. Multiple platform-specific CI/CD workflows (.github/workflows/*.yml) are present but their configurations cannot be fully assessed. Missing configurations like branch protection rules, secret scanning, or artifact signing could introduce security risks. Fix: Ensure all CI/CD workflows implement: (1) branch protection requiring PR reviews, (2) GitHub secret scanning enabled, (3) dependency scanning (Dependabot configured), (4) artifact signature verification, (5) least-privilege secrets management.

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.