Leapstone：修復 API 及 SDK 破壞性變更的開源命令列智能體

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Leapstone is an open-source command-line agent that fixes your code when an API or SDK you depend on ships a breaking change.

When a vendor ships a breaking release, thousands of teams read the same migration guide and make the same mechanical edits by hand. Dependabot bumps the version number, but nothing fixes the code. Leapstone does: it scans your repo for affected call sites, applies exact rewrites, asks a model only for the parts that need judgment, runs your own tests, and opens a reviewable pull request with an honest confidence report.

Who would pay: engineering teams that depend on many fast-moving APIs, and API vendors who want customers to adopt new versions without support tickets. The core is free (Apache-2.0). The paid side, Leapstone Pro, adds pack drafting from changelogs, pack signing, multi-repo batch runs, a team dashboard, and native Claude with managed API-key profiles. It's an open-core side hustle. There are no sales yet.

The idea comes from the "Self-Maintaining APIs" request for startups: API providers shouldn't just announce changes, they should apply them.

Demo

Try the whole pipeline offline in about a minute (a scripted stand-in plays the model, so no GPU or key is needed):

git clone https://github.com/Armansiddiqui9/leapstone-core && cd leapstone-core
pip install .
make demo     # scan, then a dry-run migration of a sample repo
make test     # 97 tests

run is a dry run by default: it prints the diff and a report, and changes nothing in your repo.

Code

Armansiddiqui9 / leapstone-core

Dependabot for breaking API changes. Leapstone finds the code a new SDK version breaks, fixes it, runs your tests, and opens a pull request, using a model you run yourself. Open source, Apache-2.0.

🪨 Leapstone

Hop to the new version, safely.

Leapstone is an open-source command-line agent that fixes your code when an API or SDK you depend on ships a breaking change. It finds every affected spot, fixes the exact ones with deterministic rewrites, asks an AI model (that you run, on your own machine) only for the parts that need judgment, runs your own tests, and then hands you a reviewable pull request with an honest confidence report.

Status: alpha (v0.3.0). The pipeline is built and tested (97 automated tests). How well real open models perform has not been measured yet. The bundled evaluation uses a scripted stand-in, not an AI. See docs/STATUS.md for exactly what is and is not verified.

Why

When a vendor ships a breaking release, every customer scrambles to update. The vendor writes a migration guide, thousands of teams read it, and thousands of developers make…

How I Built It

• Open models, any runtime. Leapstone bundles no model. It talks to any OpenAI-compatible endpoint you run (Ollama, vLLM, llama.cpp server, LM Studio) with a plain standard-library HTTP client. The only dependency is PyYAML.
• Migration Packs. A vendor describes a breaking release in one YAML file. Exact renames become deterministic codemods. Changes in meaning become an instruction plus a before/after example for the model.
• The pipeline: scan, codemod, model edit for judgment calls, your tests, retry, pull request. In repair mode the model sees its own failing edit and the test output.
• Safety by design. Edits only apply if the search text matches exactly once, inside code the model was shown. Secrets are replaced with placeholders before prompting. Pull requests go on a new branch only. There are hard limits on files, diff size and retries, and every run saves a revert.patch.
• Extensible. A plugin entry point and a --provider hook let extensions add commands and model providers. That's how the paid Pro package plugs in.
• Built with help from Claude as a coding assistant.

Honest status: alpha. The pipeline is tested (97 automated tests), but how well real open models perform has not been measured yet. The bundled evaluation uses a scripted stand-in, not an AI.

Why Does Open Innovation Matter?

Fixing someone's source code means reading it. With a closed API, every team would have to send its private code to a third party, and many companies can't do that. Open-weight models run through Ollama or vLLM keep the code on the developer's machine, so this tool can exist for those teams at all.

Open also means you can swap models as better ones appear, run offline, and audit the safety rules (strict edits, secret redaction, new-branch-only PRs) instead of trusting a black box. And because Migration Packs are plain YAML files with free signature verification, anyone can contribute a pack for the API they know best.