OrangePro

See which code your tests really protect. Prove it by breaking the code on purpose.

---

OrangePro maps every public function in your repository, links each one to the tests that actually call it, and ranks what's left by what it can break. For a test you care about, it breaks the function in an isolated copy and checks that the test fails. It runs on your machine, uses no AI model for scoring, and sends nothing to OrangePro. Mapping, gap ranking and proof work with no model key. Drafting a runnable test needs a provider. orangepro_generate_tests with provider set to deterministic runs with no key and returns placeholders only: the body is expect(true).toBe(true); // placeholder — replace with a concrete assertion, runnable is false, and there is no suggested_path, run_command or prove_run. That mode smoke-tests the pipeline.

npx -y @orangepro/mcp-server@latest start .

---

Contents

• What you get
• Why developers use it
• Quick start
• Evidence tiers
• How the ranking works
• Prove a test
• Use with your coding agent
• Configuration
• Language support
• Requirements and limits
• Privacy and network use
• Feedback
• Reference

---

What you get

Every run writes two reports and a spreadsheet of tests to .orangepro/:

Every function gets one of four things to do:

The one-page summary

The detailed report

*Both from OrangePro run on its own repository at commit 64a5213, without a model key, so no tests were drafted. With a key, each of the top 20 shows two drafted tests, and the side panel shows their steps and code.*

---

Why developers use it

• It tells you what a test actually checks, not just what it runs. A test that calls a function isn't necessarily checking it. opro prove replaces the function body with a fixed return value in an isolated copy and reruns your own test, unchanged. If the test still passes, it wasn't protecting that function.
• It puts consequences first. One filter shows the code paths that reach a delete or purge (cache evictions don't count); others show code that changes often, has many callers or runs on a schedule.
• It's honest about evidence. A function is "linked" only when a test calls that exact function. A test with a similar name is a lead, never coverage. Tests that only check mocks don't count.
• It's repeatable. Same commit, full git history, same config and same version give the same ranking. Each report records fingerprints, so you can tell when a change in results came from the code and when it came from the tool.
• Your coding agent can drive it. As an MCP server it gives Claude Code, Cursor, Copilot, Codex and others the ranked gaps, the suggested test location and the proof step in one loop.
• It's free, local and open source (MIT). No account, no API key for analysis, and no upload.

---

Quick start

cd /path/to/your/repo

install the repo's own dependencies first (npm ci, uv sync, go mod download, ...)

npx -y @orangepro/mcp-server@latest start . open .orangepro/short_behavior-coverage.html

Mapping, gap ranking and proof work with no model key. Drafting a runnable test needs a provider (see Model setup). Deterministic mode returns placeholders only, as described above.

Tips for the most accurate run:

• Use a full clone, not a shallow one. Change history drives part of the ranking, and the report says when history was partial.
• Exclude what isn't product code with rank_exclude_paths (see Configuration).
• Rerun after a change. Each report says what changed since the last one. When nothing changed (same commit, files, settings, coverage and proofs), start reuses the last reports at once and says so; --fresh runs in full anyway.

What's written:

.orangepro/

├── short_behavior-coverage.html ← one-page summary ├── behavior-coverage.html ← detailed report: worklist, map, run details ├── tests.csv ← drafted tests, one row per test ├── report-data.json ← the data both reports show (used to compare and reuse runs) ├── run-key.json, last-start.json ← what the last run saw, so an unchanged repo is not analysed again ├── graph.json ← the evidence graph (deterministic) ├── ledger.json ← proof certificates ├── rtm.md ← traceability matrix └── config.json ← optional per-repo settings

orangepro_generated/ ← generated tests (a runnable draft needs a provider; deterministic mode returns placeholders only); your files are never edited

---

Evidence tiers

Every function gets exactly one evidence label. The four things to do above are read from it.

A proof that ran and did not catch the break turns the function into Write; a proof made before the code changed turns it back into Prove.

A successful orangepro_prove sets the oracle field proven to true and writes the ledger status reproven. That status is used the first time too. The report's Proven count is how many behaviors still match one of those certificates. The traceability row says Reproven (this run). That label does not mean the function was proved earlier.

What OrangePro doesn't count, so linked numbers are a floor, not a coverage percentage:

• tests that only assert on mocks;
• calls made over HTTP or from end-to-end suites;
• in Python, objects that reach a test only through a fixture.

Check the tests before writing new ones for a flagged path.

"Proven 0" is normal on a first run. Proof runs your tests, so it happens only for the functions you choose, or within the attempt budget of opro start.

---

How the ranking works

Each unproven function gets an OrangePro Risk Score, ORS = P × I × D:

• P: how likely it is to change. Change history, fan-out, new code and size.
• I: what it can break. Incoming references, entry-point position, data sensitivity, and a floor for paths that reach a delete or purge within two calls.
• D: how hard a break would be to notice. Evidence tier (a linked test or a coverage run makes a break easier to notice than a name match or nothing), and whether it runs unattended (jobs and schedulers).

The score sets the order of work. It is not a defect probability. The weights are fixed and no AI model is involved. The report shows the inputs behind every row.

---

Prove a test

# Python: the mutation value is derived from the function (return annotation or its observed result)

opro prove-loop --target-symbol 'sym:app/billing/invoices.py#void_invoice' \ --test 'tests/test_invoices.py::test_void_marks_invoice_void' --replacement sentinel

TypeScript / JavaScript: give the inert body to substitute

opro prove-loop --target-symbol 'sym:src/orders.service.ts#OrdersService.cancel' \ --test src/orders.service.spec.ts --replacement 'return null;'

- **Proven:** the test passes on the original code and fails at its own assertion on the broken copy. The oracle then says `proven: true`. The ledger stores that attempt as `reproven`, including the first time, and the traceability row says Reproven (this run).

• Not proven: the test still passes on the broken copy, so it doesn't protect that function. That's a finding too.
• Unrunnable: setup failed. This is never counted either way.

Arguments for orangepro_prove

For a JavaScript or TypeScript function the call needs:

• target_symbol: sym: # . A bare name is refused.
• test_path: the test file, relative to the repo.
• replacement: empty, or a single return of a literal, such as return null;. A throw, a call, or any other statement is refused.
• replacement_mode: return-json for a normal function (the default). promise-json when the function is async, so the literal is returned as a resolved promise.
• runner: jest, vitest, mocha, or auto. Use the runner the repo uses.

Worked example for an async run in index.js, tested with Jest:

{

"target_symbol": "sym:index.js#run", "test_path": "index.test.js", "replacement": "return null;", "replacement_mode": "promise-json", "runner": "jest" }

Go