API: cross-run search — q across explicit runs, grouped by chain - #17
Merged
Conversation
The web front end's search box queries /api/agents?run=&q=, which is scoped to one run — one chain. Now that the census spans four chains, a search for a BSC agent silently returns nothing when the directory defaults to Base. This adds GET /api/search: the same q over several caller-named runs, results grouped per run and never blended. The caller names the runs because this API has no notion of a "published" run — that editorial choice lives in the web repo's published-runs.json. The run list is capped at 16, items at 5 per run (with a per-run total alongside), ranked by the same relevance the directory uses. Match semantics are shared, not copied: the q predicate and relevance expression move into q_match_sql/q_relevance_sql in routes/agents.rs, and both endpoints splice the same fragment, so "a match" can never mean two different things depending on which box the text was typed into. The on-chain agentWallet is deliberately not part of a match: no table stores it (rung 1 evidence carries ownerOf, not getAgentWallet), so indexing it needs a sweep-time read into a real column first — noted in q_match_sql's doc, not half-shipped as a JSONB scan. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 2, 2026
NemboKid
added a commit
to AgentCount/agentcount-web
that referenced
this pull request
Aug 2, 2026
The masthead search posted to /directory, which searches one chain's run — the default chain held 17% of the census, and an owner address from any other chain returned nothing. The new /search page sends one query to the API's /api/search across the canonical run set (the runs this app is willing to quote — publication is a git fact the API cannot see, so the run ids travel with the request) and renders the matches grouped by chain, with a link into the per-chain directory when a group has more than its first five. Against an API that predates the endpoint the page degrades to per-chain links rather than erroring, so a deploy-ordering window never takes search down. The empty state carries the same two escape hatches the directory's does: permalinks for a numeric id, and the owner-not-agentWallet explanation for an 0x paste. The homepage's "Search all N agents" label comes back — it was removed because it promised a search that did not exist, and now it exists. Requires AgentCount/agentcount#17 on the API side for full behavior; degrades cleanly without it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
NemboKid
added a commit
to AgentCount/agentcount-web
that referenced
this pull request
Aug 2, 2026
The masthead search posted to /directory, which searches one chain's run — the default chain held 17% of the census, and an owner address from any other chain returned nothing. The new /search page sends one query to the API's /api/search across the canonical run set (the runs this app is willing to quote — publication is a git fact the API cannot see, so the run ids travel with the request) and renders the matches grouped by chain, with a link into the per-chain directory when a group has more than its first five. Against an API that predates the endpoint the page degrades to per-chain links rather than erroring, so a deploy-ordering window never takes search down. The empty state carries the same two escape hatches the directory's does: permalinks for a numeric id, and the owner-not-agentWallet explanation for an 0x paste. The homepage's "Search all N agents" label comes back — it was removed because it promised a search that did not exist, and now it exists. Requires AgentCount/agentcount#17 on the API side for full behavior; degrades cleanly without it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 2, item 8b of the post-review work order (API half).
GET /api/search?q=<text>&runs=<uuid>,...— same match semantics as/api/agents?q=(the predicate is now a shared fragment both endpoints splice, so they cannot drift), groups returned in caller order, top 5 items per run + total, zero-match runs keep their group, unknown run ids dropped rather than erroring (canonical-set skew must not break search on the other chains). Caps: 16 runs. The web tier passes its canonical run set, which keeps "published" where it lives — in git, not the API.agentWallet: not stored anywhere queryable (no column, not in evidence JSONB; nothing calls
getAgentWallet). Per the work order's fallback, no JSONBLIKEwas shipped; the proper migration (a nullableagent_snapshots.agent_walletpopulated at sweep time + index, inherited by both endpoints through the shared fragment) is written up in the code.cargo build/test -p api(17 passed)/clippy/fmtall clean.🤖 Generated with Claude Code