diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 823a217..9f75932 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -25,6 +25,7 @@
traverse-framework/claude-skills hosts Claude Skills for building apps with Traverse — starting with traverse-app-builder, which checks the registry for a capability that already fits, authors a new one as a real JSON-Schema contract only when nothing does, compiles it to genuinely executable, ABI-compliant WASM, composes several into a multi-node workflow, and validates and runs all of it against the real traverse-cli. It also states this platform's current limitations plainly, since a skill that overclaims what Traverse can run today is worse than no skill at all.
Before authoring anything new, check the Registry Catalog — every published capability, browsable with real coverage and use-case data, not just a raw JSON index.
+Before authoring anything new, check the Registry — every published capability, browsable with real coverage and use-case data, not just a raw JSON index.
See the skill → diff --git a/src/pages/registry.astro b/src/pages/registry.astro new file mode 100644 index 0000000..5962ed3 --- /dev/null +++ b/src/pages/registry.astro @@ -0,0 +1,119 @@ +--- +import SubpageLayout from '@layouts/SubpageLayout.astro'; + +const _body = `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.
+ +