The Open Engine Company
Layer 02 · Constraints · Live

Opcore.

A deterministic, local, changed-file robustness gate for coding agents. It reads your code without touching it and tells any agent whether a changed set of files holds.

GitHub
opcore check --changed --jsonusage

What Opcore does

  • Rust graph core reads your repo. Read-only.

  • One changed-file gate. One JSON verdict. Stable exit codes.

  • Coverage before findings. Deep TS/JS, useful Rust, experimental Python.

  • Signals linters miss: dead exports, untested surface, fan-in.

  • Deterministic: same inputs, byte-identical findings.

  • Runs local, in the agent loop, before CI.

The gate, running

How it works.

01Clean edit · cleared
# an agent adds Cart.count(), a clean edit
$ opcore check --changed --json
OPCORE · CHANGEDvs HEAD · № 001
1 file changed · checks passedCLEARED
typescript.syntax · types · imports · relevant-testsall PASS
within tolerance · 0 findings · exit 0
02Regression · blocked
# a bad edit slips in: count() returns "free" ← wrong type
$ opcore check --changed --json
OPCORE · CHANGEDvs HEAD · № 001
1 file changed · 1 check failedBLOCKED ✗
FAILtypescript.typessrc/cart.ts:9TS2322
Type 'string' is not assignable to type 'number'.
out of tolerance · 1 finding · exit 1 · agent-safe JSON on stdout
03Fixed · cleared
# the type is fixed, the gate clears again
$ opcore check --changed --jsonCLEARED · 0 findings · exit 0

A controlled sample on a small TS repo (shop-core), a real, re-runnable gate, not a named-OSS run.

The objection

Why not just tsc + clippy in CI?

Because an agent needs one gate, in its inner loop, before CI. tsc and clippy are great, but separate, per-language, and downstream. Opcore is one unified changed-file gate with a single stable JSON/exit-code contract, plus graph-backed signals individual linters can't produce: untested public surface, dead exports, fan-in hotspots. The agent calls opcore check --changed after it writes and before it hands you the diff. CI still runs. Opcore just moves the catch 20 minutes earlier.

Order of operations

Coverage before findings.

Coverage first. Findings second. A verdict last. Opcore reports what it can check before what it found, so a clean result never hides a blind spot.

Coverage tiers

deepTypeScript / JavaScript
usefulRust
exp.Python (degraded-honest)
noneeverything else, counted, never faked

Reproducibility

Two runs. Same toolchain, same inputs. Byte-identical findings.

sha25698eb35d5…sha25698eb35d5…

normalized findings · example run · environment-specific

Determinism you can hash, not a promise you have to trust. (Cross-machine results vary with your toolchain versions, and we say so.)

One honest number

<1.5s

A budget · not a measured p50

Held to a <1.5s warm changed-file target on small repos, trend-gated in CI.

The contract

Stable exit codes: 0 ok · 1 findings/error · 2 not-implemented · 64 unsupported. A documented JSON gate contract, built for the agent inner loop.

Honesty

What Opcore does not do.

  • Not a security scanner. No SAST, no vulnerability claims.

  • No quality score. No number to argue with, only counts you can drill into.

  • Does not fix your code. It reports; you and your agent decide.

  • Does not claim every stack. Unreadable languages are counted as unsupported, never silently passed.

  • Does not detect who or what wrote the code.

  • Does not replace your linters, tests, or CI. It gates the change before they run.

Install Opcore

Install Opcore.

GitHubSee it run

Follow the build

Release notes and new engine drops: no noise, only when a layer ships.