Summary
traverse-cli registry sync --workspace <id> --json downloads the public index to .traverse/workspaces/<id>/registry/public/index.json, but there's no CLI command to list, search, or filter it afterward — you have to cat/parse the raw file yourself. Each record is deliberately a thin pointer (id/version/digest/contract_url/contract_digest, no summary or description — consistent with the contract-first design decided in #44), which means evaluating whether an existing capability fits a given need requires manually fetching and reading each candidate's contract_url one at a time.
Evidence
Verified hands-on: ran registry sync, confirmed its own JSON output only reports a record_count and state_path; the actual capability list is only visible by reading the written index file directly. No list/search subcommand exists under traverse-cli registry today (only sync).
Impact
"Does something like X already exist in the registry?" — a basic, expected first step before building a new capability — currently requires hand-rolling JSON parsing plus N manual HTTP fetches of contract_url values, rather than a single command.
Suggested fix
Add a traverse-cli registry list (and/or search <keyword>) command that reads the synced index and, optionally, resolves and caches each entry's contract summary/description locally so a user can browse what's available without reimplementing the two-hop lookup by hand. This doesn't require weakening the contract-first index design from #44 — it's a client-side convenience layer on top of the same two real steps (sync, then resolve).
Summary
traverse-cli registry sync --workspace <id> --jsondownloads the public index to.traverse/workspaces/<id>/registry/public/index.json, but there's no CLI command to list, search, or filter it afterward — you have tocat/parse the raw file yourself. Each record is deliberately a thin pointer (id/version/digest/contract_url/contract_digest, no summary or description — consistent with the contract-first design decided in #44), which means evaluating whether an existing capability fits a given need requires manually fetching and reading each candidate'scontract_urlone at a time.Evidence
Verified hands-on: ran
registry sync, confirmed its own JSON output only reports arecord_countandstate_path; the actual capability list is only visible by reading the written index file directly. Nolist/searchsubcommand exists undertraverse-cli registrytoday (onlysync).Impact
"Does something like X already exist in the registry?" — a basic, expected first step before building a new capability — currently requires hand-rolling JSON parsing plus N manual HTTP fetches of
contract_urlvalues, rather than a single command.Suggested fix
Add a
traverse-cli registry list(and/orsearch <keyword>) command that reads the synced index and, optionally, resolves and caches each entry's contract summary/description locally so a user can browse what's available without reimplementing the two-hop lookup by hand. This doesn't require weakening the contract-first index design from #44 — it's a client-side convenience layer on top of the same two real steps (sync, then resolve).