Vericore

Documentation Hub

The shortest path to the right Vericore documentation.

Start here

Need	Read
Understand Vericore quickly	README
Install and run Vericore	Getting Started
Use a command	CLI Reference
Understand the system	Architecture
Analyze or review a change	Change Safety
Integrate an AI agent	MCP
Integrate REST	API
Understand repository identity	Engineering Reality
Understand deterministic PR review	PR Intelligence
Review data handling	Data & Privacy
Contribute to Vericore	Development
Check implemented capabilities	Implementation Status
Review the latest published release record	0.8.2 Release Readiness
Review the previous release record	0.8.1 Release Readiness
Review the earlier release record	0.8.0 Release Readiness

Recommended reading paths

New user

README
   ↓
Getting Started
   ↓
CLI Reference

Developer

README
   ↓
Getting Started
   ↓
CLI Reference
   ↓
Architecture
   ↓
Development

Safe code-change workflow

README
   ↓
Engineering Reality
   ↓
Change Safety
   ↓
prepare → change → verify

AI-agent integration

README
   ↓
Architecture
   ↓
MCP
   ↓
Change Safety

Release review

Release Readiness / Release Record
      ↓
Release certification
      ↓
Release workflow

Documentation rules

The documentation set has four purposes:

1. User documentation — installation, commands, APIs, and integrations.
2. Engineering documentation — architecture, safety boundaries, development, and implementation status.
3. Release documentation — release certification evidence and the current release record.
4. Project policy — contribution, security, DCO, conduct, licensing, and trademarks at the repository root.

Historical implementation notes may explain a design decision, but they must not be presented as current product instructions. The main branch may contain unreleased hardening after the latest published tag.

Source of truth

When documents disagree, use this order:

1. implemented code and executable tests;
2. public CLI/API/MCP contracts;
3. architecture and safety documentation;
4. implementation-status and release documents;
5. historical design notes.

A roadmap or historical design note never proves that an unimplemented capability exists.

Command documentation rule

Every user-facing CLI command must have its syntax, options, defaults, outputs, and important failure semantics documented in CLI Reference. Update that document in the same change whenever the CLI contract changes.

Avoid duplication

• Keep the README focused on product behavior and the fastest path to first use.
• Keep Getting Started task-oriented; do not turn it into a second command reference.
• Keep API and MCP documents focused on their respective protocols.
• Prefer links to authoritative contracts instead of copying the same rules into multiple documents.

This site is open source. Improve this page.