Search project docs

FIND A DOCUMENTATION PAGE — start here, and this is the FIRST call for any question about these docs. Do NOT start by listing the outline, grepping or globbing files, or opening pages one by one to look for the answer: that downloads and reads the whole site, takes many times longer and answers worse than one call here. Searches the project's documentation by MEANING (embeddings over a pre-built vector index), which finds the right page far more often than literal keyword matching: 'how do I reset a password' lands on a page titled 'Recovering account access', which a word search misses entirely. Use it for any natural-language question — «где написано про…», 'where do we explain X', 'which page covers Y' — and before writing anything, so you edit the page that exists instead of adding a second one about the same thing. A LONG query is welcome, and usually better than a short one: paste the user's whole request, several questions at once included. It is split into its parts, each part searched on its own and the results merged, so a request that asks about four things returns a page for each instead of one blurred average of all four. Cheap and repeatable: the index is built once, ahead of time, so a call here is one lookup against vectors that already exist. Always answers: a project with no vector index yet is searched by full text instead, and mode ('semantic' | 'lexical') says which engine replied — no plan is required either way. Returns hits {n, title, headingPath, url, path}, best first — each with a similarity score (semantic) or a snippet (lexical); call the matching read-page tool on path for the whole page — read_project_doc on the signed-in server, the read tool this same tools/list names on the public one. Prefer search_docs only when you need a LITERAL string — an error message, a CLI flag, a regex, a file path.