Skip to main content
Every number here imports STATUS from /snippets/_status-snapshot.mdx. Mixed provenance, and worth knowing which is which: version and lastUpdated are auto-derived from the published release by scripts/mintlify-snapshot.sh; the counts are a hand-maintained periodic snapshot of the engine’s canonical scripts/refresh-status.sh block. The engine’s hygiene vector 23 guards that block inside the engine repo — it cannot see this one. So a fresh lastUpdated is not evidence that the counts are fresh.Counts as of engine main · branch {STATUS.branch} · snapshot refreshed .

​
At a glance

Admitted

crates past 12 gates

Library tests

passing · clippy warnings

Hygiene

vectors gate every push

ADRs

total · Accepted · Proposed

Providers

LLM providers in the catalog

Capability rules

rules in model-capabilities.toml

​
Canonical block

The engine’s refresh-status.sh emits this block inside the engine repo (ROADMAP.md, .claude/CLAUDE.md). The rows below are a hand-copy of it, taken at {STATUS.head}. A per-vector green/yellow/red breakdown is deliberately absent: it is a live CI result, not a docs constant. Run bash scripts/hygiene/check-all.sh --format=json in the engine repo for it.

​
How to refresh

​
Drift protection, stated honestly

Engine hygiene vector 23 (check-status-claims-sync.sh) parity-checks the block against ROADMAP.md and .claude/CLAUDE.md within the engine repo. It has no visibility into this repo, so nothing fails CI when the counts here go stale. scripts/mintlify-snapshot.sh only rewrites version and lastUpdated — it will happily bump the date on a page whose counts are months old. Treat a recent lastUpdated as evidence about the release, never about the crate, test, or ADR numbers.

​
What’s admitted today

Diamond crates are admitted, with WIP . The admitted set spans the foundation crates, kernel traits, local/effect crates, providers, all four verbs, runtime, LSP, MCP, and CLI surfaces needed for the first public release candidate.

​
What’s locked (decisions the project won’t revisit)

  • Crate count is a projection, never a gate: ADR-037 revised the old 40-42 target to a horizon (hard cap ); crates are admitted when they pass the 12 gates, reached additively across 1.x minors.
  • Real semver toward 1.0: 0.90.0 is the first public release-candidate; 1.0 ships when release gates are green. Quality over speed.
  • Layer discipline: L0 zero I/O, L0.5 traits only, strict downward deps, cargo-deny enforced. See Layers.
  • 12 gates per crate: no exceptions. See Admission.
  • Zero .unwrap() / .expect( in src/: ? propagation; workspace.lints.clippy.unwrap_used = "deny".
  • Not an extraction: every crate written fresh, legacy as reference only.
  • TDD with mutation ≥ 90%: RED before GREEN; cargo mutants -p <crate> gates admission.
  • #[non_exhaustive] on every public type: see Forward-compat invariants.

​
What’s next

The remaining Diamond target crates are additive hardening work, not prerequisites for the shipped 0.90 release-candidate surface. See the roadmap for the exact current sequence.
The user-facing front door is already installable. The 1.0 work is about proving the release checklist, docs, editor setup, and shadow-zone gates stay true end-to-end.
Separate count from the Diamond crate horizon. 11 crates: 1 L2 orchestrator (nika-connectome) + 10 L1 satellites (hnsw, bm25, rrf, rerank, fsrs, rdfs-reasoner, temporal, graph-algos, autodesc-minimal, autodesc-full). Plugs into MemoryStore / EmbeddingProvider trait reservations in nika-kernel. No breaking changes. Design tracked via ADR-004 + ADRs 029-032.

​
What’s NOT in scope

Explicitly removed or deferred by POST_AUDIT_REVISIONS 2026-04-14:

​
See also

Constellation

Visual map of admitted / WIP / planned crates by layer.

Admission

The 12 gates every crate passes before joining.

Error codes

NIKA-XXX code reference per crate range.

CHANGELOG

Every crate admission with verified numbers.

​
The Nika ecosystem