VERICORE 0.7.0

Understand. Change. Verify.

Go from a fresh installation to repository-grounded engineering decisions and a repository-bound verification boundary.

01

Install and diagnose

Released archives bundle the Java runtime for normal end-user use. Use setup and doctor before your first analysis.

vericore --version
vericore setup
vericore doctor
02

Analyze a repository

Run deterministic analysis locally. Vericore builds source, dependency, Git, architecture, evolution, and report artifacts.

cd your-project
vericore analyze .
vericore reality . --json
03

Inspect state and evolution

Capture context snapshots, compare them, and inspect Git evolution without treating historical metrics as a semantic reconstruction of every past commit.

vericore context-snapshot /path/to/repository --json
vericore context-diff /path/to/before.json /path/to/after.json --json
vericore evolution /path/to/repository
04

Ask grounded questions

Retrieve bounded evidence for dependency, risk, impact, architecture, PR, or test-oriented questions. AI assistance is optional.

vericore repo-qa "why is PaymentService risky?" --path /path/to/repository
vericore ask "What are the main architectural hotspots in this repository?"
05

Understand change and architecture

Use impact and PR Intelligence for affected areas, then use architecture drift and contracts when an explicit governance baseline exists.

vericore impact /path/to/repository src/main/Service.kt --json
vericore pr-intelligence /path/to/repository --json
vericore architecture-drift /path/to/repository --baseline /path/to/architecture-baseline.json --json
vericore architecture-contract /path/to/repository --contract /path/to/.vericore-architecture-contract.json --json
06

Prepare the change

Generate an evidence-backed engineering plan and a repository-bound Agent Change Contract before implementation begins.

vericore prepare "add payment validation" --path /path/to/repository

The persisted contract becomes the verification boundary.

07

Implement, then verify

Make the change outside Vericore, then verify against the original persisted contract. Do not replace it with a newly generated contract.

vericore verify \
  --path /path/to/repository \
  --plan output/engineering-plan.json \
  --contract output/agent-change-contract.json
08

Integrate locally

Use the local Ktor server or MCP stdio interface for trusted local/internal integrations and AI-agent workflows. Keep REST on loopback unless you provide the missing deployment security boundary.

vericore server --host 127.0.0.1 --port 8080
vericore mcp

Local-first by design

Deterministic first

Repository structure and core intelligence are produced locally and reproducibly.

AI is optional

Configured Gemini/Anthropic workflows can add reasoning without replacing repository evidence.

Persisted safety boundary

The Agent Change Contract captures the prepared change boundary and is the basis for post-change verification.

What gets produced?

The exact artifact set depends on the workflow, but 0.7.0 can produce self-contained HTML reports plus machine-readable snapshots, context, evidence, plans, contracts, provenance, and architecture decision artifacts.

analysis-snapshot.jsonengineering-context.jsonengineering-plan.jsonagent-change-contract.jsonreality / evidence artifacts

Ready to try it?

Start with v0.7.0, inspect the generated artifacts, and follow the prepare → change → verify workflow.