v0.1.0 — semanticSearch learns what a definition is

semanticSearch now fuses a third retrieval signal: SCIP symbol-definition matches. A query naming an identifier ranks that identifier's definition site above chunks that merely mention it — using the compiler-grade symbol data jarvis already publishes but retrieval never touched.

Install

Claude Code plugin:

/plugin install jarvis@phuongddx/jarvis-dist

Standalone (uv / uvx):

uvx --from jarvis-mcp jarvis-server

Index a repo:

uvx --from jarvis-mcp jarvis index /path/to/repo --slug my-repo

What changed

• New symbol_search module turns a natural-language query into ranked definition locations: token extraction (stopword filtering, adjacent-token bigrams so "zoekt lifecycle" finds ZoektLifecycle, dotted suffixes like Class.method), case-insensitive matching against the SCIP name map, ranking by matched-token count → kind priority (types > methods > terms) → shorter dotted path, then resolution through defn_enclosing_ranges.
• The signal enters the existing reciprocal rank fusion unweighted alongside vector and Zoekt hits, and merges into a vector chunk when that chunk contains the definition line. sources may now include "symbol"; symbol-only hits carry content: "" with symbolName set to the definition's dotted path.
• Strictly additive: search-only repos, partial indexes, or any failure inside the signal degrade to the previous two-signal result, byte-identical. No MCP tool signature or response-shape change.
• Fixed in review before shipping: SCIP's 0-based line numbers now convert to jarvis's 1-based convention at the SymbolHit seam — without this, a definition's symbol hit missed its own chunk by exactly one line.

Caveat: Swift repos gain nothing from this signal — scip-swift emits clang USR strings as symbol names, which NL tokens never match (same limitation as bare-name resolution in the nav tools).

See CHANGELOG.md.