traverse-framework/registry is a git-based, CI-validated, PR-published registry of capability contracts. It's where traverse-registry — the runtime crate — actually resolves capabilities from. Nothing gets in without a review.
Counted directly from contract.json files in the repo — 38 published version files across 11 distinct capabilities, 15 of them already deprecated in favor of a newer version. That churn is a feature: it means the immutability and versioning rules are actually being exercised, not just declared.
The live site at registry.traverse-framework.com is a static site — plain HTML, CSS, and vanilla JS on GitHub Pages, no framework. A Rust/WASM build step (catalog-builder) generates the data behind it from the actual repo contents, not hand-maintained copy.
One card per capability — version count, real test-coverage badge, use-case count. A checkbox hides deprecated versions.
Free-text search across the catalog — no need to know the exact namespace up front.
A hash-routed detail view per version: description, use cases, real cargo llvm-cov coverage percentages, input/output JSON Schemas, and version history.
A collapsible raw contract.json on every detail page — the actual file, not a rendered summary of it.
An author runs traverse-cli capability publish, which validates the contract locally and opens a PR automatically. CI then runs deterministic checks — schema validation, semver correctness, digest integrity, namespace-collision detection. A human still has to approve it: automated checks alone can never merge a publish. Once merged, a published version is immutable — fixes go through yanking or deprecating a version, never an in-place edit.
Check the registry before authoring a new capability — something close enough to reuse or extend might already exist.