You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-on to #100 (namespace policy), #101 (utility-tier capability class), and #102 (registry search only matches namespace/id substrings, no discovery over what a capability actually does).
The repo owner's verdict, after reviewing that discovery gap directly: without at minimum an MCP surface and/or a searchable web page indexed by use case, the registry doesn't deliver on its actual purpose. Resolved via /brainstorm (2026-07-29) into a concrete build plan. This is the umbrella; see child issues for the independently-completable pieces. Do not claim this as one ticket — same discipline as #69.
Decisions (full reasoning in docs/decision-log.md, entry 40)
Build both a human-facing catalog and an agent-facing search tool — not a brand-new MCP server. traverse-framework/traverse already has a real traverse-mcp crate (spec 209, list_capabilities/get_capability tools) that runs as a local stdio process, the normal way MCP servers work. GitHub Pages is static-hosting only and cannot run a server process, so: GitHub Pages serves the static catalog; traverse-mcp gets a new search_capabilities(query) tool.
Catalog builder dogfoods Traverse: a plain script gathers every capabilities/**/contract.json into one JSON bundle (the WASM ABI only allows one input/one output via fd_read/fd_write, no directory listing, so a capability can't walk the tree itself) — a new Traverse capability (no_std/WASM, same pattern as every agent under agents/) transforms that bundle into the catalog's HTML + a search-index.json.
Schema gains use_cases: contract.json gets a new field, use_cases: [{scenario, input_example, output_example, happy: bool}] — a narrower, search-focused promotion of what the 5 newest capabilities' SPEC.md files already contain (NFRs/interfaces/configuration stay in SPEC.md, not promoted). Governed as a direct amendment to spec 001 (new FR), not a new layered spec — a deliberate one-off exception to the usual "layer, don't edit" precedent (decisions 22/29c), the owner's explicit call this time.
Backfill scope: all 11 existing capabilities, now — not just the 5 newest with ready SPEC.md content. The original 6 reference-app capabilities need genuinely new use-case content authored (never written before).
Relation to Umbrella: gaps blocking LLM MCP kit catalog (workflows, content groups, resolve policy) #99 (the separate, already-open "LLM MCP kit catalog" umbrella, workflow/content-group-focused): kept separate but cross-linked — different scope (capability-level discovery vs. kit-workflow catalog for OS-shell MCP consumers), same underlying search infrastructure worth sharing once both exist.
search_capabilities MCP tool in traverse-mcp (companion issue, traverse-framework/traverse) — cross-repo, out of this repo's scope
Status (2026-07-29)
All four registry-repo children are done. The only remaining item is the traverse-mcp companion piece in traverse-framework/traverse, which is outside this repo's scope. Moving Project 3 status to Blocked on that cross-repo dependency rather than Ready (nothing actionable left here) or Done (the umbrella's own DoD isn't fully met yet).
Summary
Follow-on to #100 (namespace policy), #101 (utility-tier capability class), and #102 (registry search only matches namespace/id substrings, no discovery over what a capability actually does).
The repo owner's verdict, after reviewing that discovery gap directly: without at minimum an MCP surface and/or a searchable web page indexed by use case, the registry doesn't deliver on its actual purpose. Resolved via
/brainstorm(2026-07-29) into a concrete build plan. This is the umbrella; see child issues for the independently-completable pieces. Do not claim this as one ticket — same discipline as #69.Decisions (full reasoning in
docs/decision-log.md, entry 40)traverse-framework/traversealready has a realtraverse-mcpcrate (spec 209,list_capabilities/get_capabilitytools) that runs as a local stdio process, the normal way MCP servers work. GitHub Pages is static-hosting only and cannot run a server process, so: GitHub Pages serves the static catalog;traverse-mcpgets a newsearch_capabilities(query)tool.capabilities/**/contract.jsoninto one JSON bundle (the WASM ABI only allows one input/one output viafd_read/fd_write, no directory listing, so a capability can't walk the tree itself) — a new Traverse capability (no_std/WASM, same pattern as every agent underagents/) transforms that bundle into the catalog's HTML + asearch-index.json.use_cases:contract.jsongets a new field,use_cases: [{scenario, input_example, output_example, happy: bool}]— a narrower, search-focused promotion of what the 5 newest capabilities' SPEC.md files already contain (NFRs/interfaces/configuration stay in SPEC.md, not promoted). Governed as a direct amendment to spec 001 (new FR), not a new layered spec — a deliberate one-off exception to the usual "layer, don't edit" precedent (decisions 22/29c), the owner's explicit call this time.Children
use_casesFR (registry repo) — Amend spec 001 with a use_cases contract field #104, closeduse_casesacross all 11 published capabilities (registry repo) — Backfill use_cases across all 11 published capabilities #107, closed via release(capabilities): backfill use_cases across all 11 published capabilities (#107) #120search_capabilitiesMCP tool intraverse-mcp(companion issue,traverse-framework/traverse) — cross-repo, out of this repo's scopeStatus (2026-07-29)
All four registry-repo children are done. The only remaining item is the
traverse-mcpcompanion piece intraverse-framework/traverse, which is outside this repo's scope. Moving Project 3 status to Blocked on that cross-repo dependency rather than Ready (nothing actionable left here) or Done (the umbrella's own DoD isn't fully met yet).