admin/.mappa/share/runbooks/search.md

title: Runbook — search/граф и общая память summary: Поиск в mappa: карточный search/entity_search/wiki_search (без тел), правила К1–К4 (поиск до угадывания), скоуп-резолюция project/shared, анти-паттерн wiki_get(slug) на shared-слое, граф (backlinks/neighbors/path) для реляционных вопросов, mode='recall' (общая память: поиск → граф-кластер, depth/related). type: runbook tags: [mappa, runbook, search, agent, memory]

runbooks/search — как искать в mappa

Процедура «найти сущность/страницу, не угадывая» + «восстановить контекст/память». Канон-контекст: canon/gates Г3 (поиск до угадывания). Обновляется при изменениях поиска.

1. Поиск до угадывания (К1–К4)

• Не знаешь ref/существование → entity_search(q) / wiki_search(q) (карточки: ref/type/project/slug/snippet). Никогда не «угадывать» slug/номер.
• Скоупы: project=X (жёсткий) | shared | all (boost текущего). Результат карточки несёт project — переключайся по нему.
• Префиксы каталога: слаги живут под canon/, methodology/, runbooks/, concepts/, docs/ — не перебирать префиксы, искать.
• Тип-фильтры: types=[task|wiki|inbox|brainstorm|…] — сузить до нужного.
• Карточка найдена → полное тело: entity_get(ref, full=true) (не «собрать по кусочкам»).

2. Скоуп-резолюция (project vs shared)

• wiki_get(slug) без project = shared-скоуп. Для проектной страницы — wiki_get(project, slug).
• Одна и та же тема может жить в shared (канон/методология/рунбуки) И в проекте (спека/ретро) — сначала search, потом читать правильный скоуп.

3. Анти-паттерн: wiki_get(slug) для shared-слоя (после task:2073)

Анти-паттерн: wiki_get(slug) для shared-канона/рунбуков (canon/*, methodology/*, runbooks/*) мис-резолвится → 404 или чужая страница. Если увидел 404/не-тот контент — это shared-слой → переключись на entity_search(scope='shared') → entity_get(ref, full=true). Не повторяй wiki_get(slug) (21.7% ошибок на /wiki/:slug по телеметрии, дайджест 2069).

4. Граф (когда «кто ссылается / связь»)

• «Кто ссылается на X» → graph_backlinks(ref); «куда ведёт X» → graph_neighbors(ref); «связь X–Y» → graph_path(from, to).

5. Общая память — mode='recall' (поиск → граф-кластер)

Это и есть «общая память» mappa (intent:4, task:2570). Агент получает память запросом, а не подсовыванием.

• Когда: хочешь не «найти страницу по названию», а восстановить контекст вокруг темы: поиск-кластер сущностей и связей между ними. search(q, mode='recall', scope=…).
• Что вернёт: карточки кластера с полем depth (0 = сид, 1 = сосед, 2–3 = дальше по рёбрам; relevance затухает 1/(1+depth)) и related[] (внутрикластерные связи). Лимит ~50.
• Пайплайн (память как восстановление):
  1. search(q, mode='recall') → кластер (сиды + depth + related);
  2. выбрать 1–3 ядра; entity_get(ref, full=true) → полное тело;
  3. graph_neighbors/graph_backlinks → развернуть вглубь по рёбрам;
  4. graph_path(A, B) → связать два полюса.
• Без mode='recall' — обычный карточный поиск (регресс-контракт, depth нет). Ищешь mode='recall' тогда, когда ответ — это «связка сущностей», а не «одна страница».
• Опора качества: recall опирается на FTS-safe (task:2572) + тег-канал (task:2573) для релевантности — если сырой ввод/спецсимволы ломают поиск, используй чистый запрос.

6. Handoff как снимок памяти (после task:2571)

• handoff_write(project, session_id, status, summary, open_treks?, ask_user?, guards?, recent_commits?) — писать можно в любой момент сессии (reactive-чекпоинт), не только в closing ritual.
• Рёбра handoff → session (in_session) / project (belongs_to) / task материализуются при write → handoff не сирота.
• Восстановление после разрыва: search(type='handoff', project=X, limit=1, sort=recency) → последний → entity_get(handoff:N, full=true) → снимок: что сделано / что открыто. Канон-контекст: canon/gates Г3/Г9.

Связи: runbooks/index · canon/gates · canon/index · runbooks/session · task:2073 · task:2570 · task:2571 · intent:4 · requirements:32 · concepts/memdb-recall-search-patterns (wiki:3395)