dxkit

A deterministic stop condition and code-graph context layer for AI coding agents.

Autonomous coding loops face two control problems: orienting in the code while
they make a change, and deciding whether that change made the repository worse
before they stop.

dxkit addresses both. While the agent works, it provides a code graph of
callers, callees, blast radius, and the files a change touches. Then, when the
agent tries to stop, dxkit baselines existing findings, reruns trusted checks,
and blocks only net-new detector-backed regressions with a concrete repair
reason.

In our loop benchmark, vanilla Claude Code-style loops stopped with net-new
debt in 11 of 16 runs. A prompt that told the agent to self-check still
escaped 9 of 16. With dxkit's Stop-gate, we observed 0 of 16 escapes:
when the loop tried to stop dirty, dxkit blocked, handed back the exact net-new
finding, and the agent repaired before stopping clean.

_{Recorded from a real run on a synthetic repo, shortened for readability. Blocked and repaired inside the same warm loop.}

dxkit does not reinvent detection. It runs trusted open source scanners
(gitleaks, Semgrep, OSV, npm audit, and more), and it can ingest results from
Snyk and CodeQL. What dxkit adds is the agent-loop layer around those tools: a
per-stop, baseline-relative verdict of whether this change introduced a new
finding, returned to the agent with the exact repair reason while the loop is
still warm.

npm init @vyuhlabs/dxkit -- --claude-loop --yes   # install dxkit + register the Claude Code Stop hook
npx vyuh-dxkit baseline create                    # grandfather today's findings
npx vyuh-dxkit loop doctor                         # verify the gate is wired

The stop verdict has no model in the path: same input, same verdict.
Existing debt stays grandfathered; only net-new regressions block.

Read the benchmark · Try it on your repo · Run the fixture gate

---

The problem: loops do not know when they made things worse

An autonomous loop runs until the agent decides it is done. The common checks in
that loop (tests, linters, scanners, CI-style commands) usually answer whether
something is broken or flagged. They do not, by themselves, maintain a
brownfield baseline and answer the loop-level question: did this change
introduce something net-new? So an agent can add a feature, leave a new untested
path or a hardcoded credential behind, run the tests, see green, and declare
success.

In our benchmark this happened in most vanilla runs, and telling the agent to
check its own work only helped a little.

What dxkit does

1. Build a structural code graph. dxkit gives the agent callers, callees,
   blast radius, and relevant files so it can orient before editing.
2. Baseline today's debt. baseline create records current findings, so
   pre-existing issues are grandfathered and never block.
3. Run a deterministic Stop-gate on every stop. A Claude Code Stop hook
   reruns the guardrail against that baseline. Same input gives the same
   verdict; no model decides whether the gate passes.
4. Feed net-new findings back to the agent. If the change introduced a
   finding, the gate blocks the stop and hands the agent the exact finding to
   fix: do not refresh the baseline, do not touch unrelated debt, fix what this
   branch introduced. The loop stops only when clean.

Why only net-new findings?

Grandfathered does not mean accepted.

dxkit blocks only net-new findings for two reasons: agent-loop attribution and
brownfield adoption.

First, an autonomous coding loop needs a scoped stop condition. When an agent
tries to declare done, the relevant question is not "is this entire repository
debt-free?" It is:

did this loop make the repository worse than the baseline?

If the gate asks the agent to fix every pre-existing finding before it may stop,
the repair target becomes noisy and unbounded. The agent may churn unrelated
code, spend context on old debt, or refresh the baseline to escape. dxkit instead
holds the loop accountable for the change it just made: fix what this branch
introduced, do not touch unrelated debt, and do not move the baseline.

Second, dxkit is designed for brownfield repositories. Existing debt may include
hundreds or thousands of findings. If the first gate required a repo to reach
zero findings, most teams could not adopt agentic development workflows until
after a large cleanup project. That is backwards. The first control invariant is
simpler and stricter:

this agent must not make the repository worse than the baseline.

baseline create records the current state so existing findings remain visible
and auditable, but they do not block the current loop. When an agent changes the
repo, dxkit blocks only findings introduced by that change. This lets teams adopt
agentic workflows immediately, prevent regression from day one, and pay down the
old baseline as a separate, deliberate workstream.

A baseline refresh is a governance action, not a repair action. If the Stop-gate
blocks, the agent should fix the net-new finding it introduced and should not move the
baseline.

Who this is for

Use dxkit if you let coding agents:

• run unattended or semi-attended,
• fix CI or review comments in loops,
• touch brownfield repos that already carry debt,
• or work where "new debt" matters more than "all debt."

What dxkit is, and is not

It is a deterministic verification layer. It baselines today's findings,
fingerprints them across churn, and blocks only net-new regressions.

It is not a scanner replacement. It runs and ingests scanners (gitleaks,
Semgrep, CodeQL, Snyk, SARIF) and makes their findings enforceable. It does not
claim to find more bugs than they do.

It is not an LLM judge. No model decides whether the gate passes. The model
can repair findings. The gate itself is deterministic, and the prompt does not
grow as the baseline grows.

It is not a guarantee of safe code. It blocks detector-backed net-new
findings it can observe. You still need tests, review, scanners, and judgment.

Built on tools you already trust

dxkit is an orchestration and enforcement layer, not another scanner. It runs
established open source tools and treats their output as one stream. Which tools
run depends on the languages in your repo. dxkit covers 8 ecosystems
(TypeScript / JavaScript, Python, Go, Rust, C# / .NET, Java, Kotlin, Ruby).

Universal, on every repo:

• secrets: gitleaks
• code patterns: Semgrep
• dependency advisories: OSV.dev
• size, duplication, and the code graph: cloc, jscpd, graphify

Per language, dxkit adds that ecosystem's own linter and audit tool. For
example, npm audit + ESLint (JS / TS), pip-audit + ruff (Python), govulncheck +
golangci-lint (Go), cargo-audit + clippy (Rust), dotnet list --vulnerable
(C#), osv-scanner + PMD (Java), osv-scanner + detekt (Kotlin), and
bundler-audit + RuboCop (Ruby). The full per-language matrix is in Per-pack
capabilities below.

For deep interprocedural analysis, it ingests findings from Snyk Code and
CodeQL (or any SARIF file), fingerprints them the same way as native
findings, and runs them through the same baseline and gate. You keep the
detectors you already have. dxkit makes their findings enforceable inside CI
and inside the agent loop.

Layer	Examples	Job
Detection	gitleaks, Semgrep, OSV, npm audit, Snyk, CodeQL, SARIF	Find issues
dxkit	baseline, fingerprint matcher, Stop-gate, loop ledger	Decide whether this change introduced something net-new
Agent	Claude Code or another coding loop	Repair the exact finding and try to stop again

Try it on your repo

The Stop hook runs dxkit on every stop, so install dxkit into the repo. This
one command adds it as a devDependency and registers the hook additively, so your
existing .claude settings are preserved:

npm init @vyuhlabs/dxkit -- --claude-loop --yes
npx vyuh-dxkit baseline create      # grandfather today's findings
npx vyuh-dxkit loop doctor          # verify the gate is wired safely and dxkit resolves
# then run Claude Code as you normally would. The Stop-gate fires on every stop.
npx vyuh-dxkit loop ledger summarize  # afterwards: blocked vs allowed, repaired-after-block

When the agent tries to stop, dxkit runs the net-new gate against the baseline.
Existing findings are grandfathered; only findings this change introduced block.

Run a local fixture gate

Want to see the Stop-gate before installing dxkit into your repo?

npx -y @vyuhlabs/dxkit@latest demo loop-guardrail

This runs the real gate on a temporary fixture repo: baseline → introduce a
net-new secret → BLOCK → repair → CLEAN, then it tears the fixture down. No API
key and no Claude Code, and your own repo is never touched. It needs gitleaks
installed and takes about 20 seconds; without gitleaks it shows a clearly
labelled illustration instead. (It does a one-time npx download, so it is not
fully offline, though the gate itself is.)

Presets: what blocks the loop

security-only  (default)  secrets and critical or high vulnerabilities. Bounded, must-fix, cheap to gate.
full-debt      (opt-in)   also gates test gaps and maintainability regressions. Repairs can be expensive.

The default is security-only. The headline escape-rate benchmark used
full-debt (it gated both the secret trap and the test-gap trap); the default
install starts narrower so a first run does not trap users in expensive
test-generation loops. Switch with
npm init @vyuhlabs/dxkit -- --claude-loop --loop-preset full-debt.

Give the agent a map, not just a gate

The Stop-gate controls what a loop is allowed to ship. The code graph controls
how the agent does the work in between. When dxkit scaffolds a repo it builds a
code graph and installs skills that drive real development off it, so the agent
orients by querying structure instead of grepping and re-reading whole files.

• Build a feature (dxkit-feature skill): query the graph for where the
  feature plugs in, what patterns already exist, and what the change will
  touch, then implement against those patterns and run the analyzers on the
  result before it stops.
• Fix a finding (dxkit-action skill): take a flagged finding, pull its
  callers, callees, and blast radius from the graph, repair it, and confirm the
  change did not introduce something net-new.

The agent gets callers, callees, and blast radius up front as a budget-bounded
slice, not a pile of file reads. It is the same graph, the same baseline, and
the same identity contract the gate already uses.

What the benchmarks actually show is predictable spend, not guaranteed cheaper
spend. On a large repo the median was roughly tied, the worst-case session used
about 57% fewer tokens, and the variance was roughly halved. On a small
repo the overhead was about zero. The graph caps the expensive tail. It does
not promise a lower average, and it does not make the agent write better code on
its own.

This is a different axis from detection. Snyk, SonarQube, and CodeQL tell you
what is wrong. They do not give the agent a map of the code or bound how much it
spends finding its way around. dxkit does both: the gate bounds what the loop
ships, the graph bounds how the loop works.

The numbers

Three independent benchmark results, one theme: dxkit makes agent work more
predictable.

Layer	What it bounds	Observed result
Stop-gate	net-new detector-backed debt	vanilla loops escaped 11/16 times, prompt-only checklist escaped 9/16, dxkit escaped 0/16
Deterministic identity	false "net-new" findings under churn	caught all 3 seeded regressions with 0/2 false blocks on clean edits; 0 false net-new on tested line shifts and renames
Graph context	large-repo exploration tails	median roughly tied, but large-repo mean tokens 30% lower, worst case 57% lower, variance roughly halved

Deferral has a re-orientation cost. A fourth arm of the
loop-safety study measured the "detect on CI, fix later" model: on the test-gap
task, deferring a net-new finding to a cold session cost ~49% more in
equivalent cost and ~51% more turns than repairing it inside the warm loop,
because the cold fixer has to re-orient in a context it no longer holds. (The
secret-task premium pointed the same way but was weak (mean +19%, median
slightly negative), so we lean on the robust test-gap result.) So the gate is not
just safer than deferring, it is plausibly cheaper too.

And the gate is fast enough to run on every stop. dxkit 2.14.0 scopes the
Stop-gate scan to the active preset's blockable finding kinds and re-scans only
the changed files, reusing cached results for everything unchanged. The verdict
is identical to a full scan; the cost is seconds per stop, not minutes, even on
large repositories.

Benchmark caveats: the loop-safety study uses controlled synthetic tasks
plus real-repo validation, detector-backed findings, and Sonnet runs. It is
not a CVE corpus, not a claim of better detection, and not a guarantee that
dxkit catches every possible bug. The claim is narrower: for findings the
detector observes, dxkit gives the loop a deterministic net-new stop decision.

Full methodology, reproducibility notes, artifact status, and caveats are in
docs/benchmarks.md.

Why not just Snyk, SonarQube, or CodeQL?

Use them. dxkit can ingest their findings. The difference is tempo and control,
not detection. Cloud scanners are strong detection engines, and they usually
run on a CI or PR cadence. A coding-agent loop needs a local stop decision
every time the agent tries to declare done.

Loop Stop-gate need	dxkit	Cloud or CI scanners
Runs locally on every stop, in seconds	yes	usually CI or cloud cadence
Deterministic verdict, no model in the gate	yes	varies (some add an LLM judge)
Grandfathers existing debt	yes	tool-dependent
Feeds the exact block reason back to the warm agent session	yes	usually a human-facing dashboard or PR

The goal is not to replace scanners. It is to make their findings enforceable
at the speed of the agent loop.

Beyond loops

The same deterministic core powers the rest of dxkit: pre-push and CI
guardrails, brownfield baselines, durable finding identity, SARIF, CodeQL, and
Snyk ingest, a six-dimension health report, code-graph context, and a set of
Claude Code skills. See the docs.

Languages

dxkit covers 8 ecosystems. Detection is automatic from your manifests and
source; each language brings its own native linter, dependency-audit tool, and
coverage parser, layered on the universal scanners (gitleaks, Semgrep, OSV,
cloc, jscpd, graphify).

Language	Detected by	Native linter + audit
TypeScript / JavaScript	package.json	ESLint, npm audit
Python	pyproject.toml, *.py	ruff, pip-audit
Go	go.mod	golangci-lint, govulncheck
Rust	Cargo.toml	clippy, cargo-audit
C# / .NET	*.csproj, *.sln	dotnet-format, dotnet list --vulnerable
Java	pom.xml, src/main/java/	PMD, osv-scanner
Kotlin	*.gradle{.kts,}, *.kt	detekt, osv-scanner
Ruby	Gemfile, *.rb	RuboCop, bundler-audit

Per-pack capabilities: coverage import, import-graph, severity tiers (click to expand)

Language	Detection	Coverage import	Import-graph	Native tools	Lint severity tiers	Vuln severity tiers
TS / JS	package.json	✅ Istanbul	✅ import/require/re-export	eslint, npm audit, vitest-coverage	✅ ESLint rule ID	✅ npm audit native
Python	pyproject.toml, setup.py, *.py	✅ coverage.py	✅ import/from	ruff, pip-audit, coverage	✅ ruff code prefix	✅ pip-audit + OSV.dev (CVSS v3+v4)
Go	go.mod	✅ coverprofile	✅ import blocks	golangci-lint, govulncheck	✅ FromLinter family	✅ govulncheck embedded + OSV.dev
Rust	Cargo.toml	✅ lcov + cobertura	⚠️ use statements, extracted only¹	clippy, cargo-audit, cargo-llvm-cov	✅ clippy group	✅ cargo-audit native
C#	*.csproj, *.sln	✅ cobertura XML	⚠️ using declarations, extracted only¹	dotnet-format (formatter)	⚠️ format-only²	✅ dotnet list --vulnerable
Kotlin	gradle/*.gradle{.kts,}, *.kt	✅ JaCoCo XML	⚠️ import statements, extracted only¹	detekt, osv-scanner (Maven)	✅ detekt severity	✅ osv-scanner + OSV.dev (Maven)
Java	pom.xml, src/main/java/, *.java	✅ JaCoCo XML	⚠️ import statements, extracted only¹	PMD, osv-scanner (Maven)	✅ PMD priority tiers	✅ osv-scanner + OSV.dev (Maven)
Ruby	*.rb	✅ SimpleCov JSON	⚠️ require/require_relative, extracted only¹	rubocop, bundler-audit, osv-scanner	✅ rubocop severity	✅ bundler-audit + osv-scanner (Gemfile.lock)

¹ Rust, C#, Kotlin, Java, and Ruby populate imports.extracted but the
file-level resolver is a no-op. Downstream analyses that need an edge graph
(reachability, import-graph test-gap credit) degrade to conservative
defaults for those packs. Resolvers are tracked on the roadmap.

² C# uses dotnet-format for formatting violations only. A real
severity-tiered C# linter (Roslyn analyzers or StyleCop) is on the
roadmap. Today every C# formatting violation is counted at low tier
so it does not inflate the Code Quality score.

Reproduce the deterministic tier

The deterministic results (the net-new gate decision and the finding-identity
matcher) reproduce offline with no API key, so you do not have to trust our
numbers. These harnesses live in benchmarks/:

node benchmarks/bench-guardrail.mjs config.json        # block/allow on seeded findings
node benchmarks/bench-netnew-isolation.mjs config.json # net-new isolation under churn
node benchmarks/bench-matcher.mjs config.json          # false net-new on line shifts + renames

See benchmarks/README.md to point them at a repo. The agent-driven harnesses
(loop safety, cost of deferral, gate-vs-LLM, and the graph-context sessions) need
a model subscription or API key and are published under benchmarks/agentic/.
Full methodology, the per-study reports, caveats, and repro steps:
docs/benchmarks.md.

Credits

dxkit stands on excellent open source tools. It orchestrates them, it does not
replace them. Thank you to the maintainers of
graphify (the code graph),
gitleaks,
Semgrep,
OSV-Scanner,
jscpd, and
cloc. Each tool is installed separately and
keeps its own license.

Contributing and roadmap

• Contributing guide: CONTRIBUTING.md
• Roadmap: docs/roadmap.md
• License: MIT