session-indexer — семантична пам'ять сесій для Claude Code

Go SQLite Ollama bge-m3 Cobra FTS5
session-indexer — семантична пам'ять сесій для Claude Code preview

session-indexer — Семантичний пошук по історії сесій для кожного проєкту окремо

Посилання:

Семантичний пошук по історії сесій Claude Code, ізольований для кожного проєкту. Індексує JSONL-транскрипти в локальне сховище SQLite; пошук через bge-m3 embeddings (Ollama) з fallback на FTS5 BM25. Автоматично підвантажує релевантний контекст на старті сесії — без централізованого сервера, без спільного стану між проєктами.


Проблема

Повернення до проєкту через тиждень і спроба згадати «що ми вирішили щодо X» серед десятків минулих сесій Claude Code — реальна проблема. Простий хронологічний журнал дає відповідь «на чому я зупинився минулого разу», але не відповідає на «що ми взагалі обговорювали на цю тему».

Чому не централізований інструмент пам’яті? Такі рішення, як mempalace чи agentmemory, тримають одне спільне сховище для всіх проєктів і агентів одразу. У цієї архітектури є фатальна вада: якщо центральне сховище падає — падає все. Пошкоджений індекс чи впалий MCP-сервер вирубає пам’ять одразу для всіх ваших проєктів, і відновлення нетривіальне.

session-indexer — per-project та append-only: .claude/sessions.db живе всередині .claude/ директорії самого проєкту. Найгірший сценарій — втратити БД одного проєкту, і це повністю відновлюється повторним запуском mine на наявних JSONL-транскриптах (ідемпотентно за дизайном). Кожен проєкт ізольований; те, що відбувається в одному, не може зламати інший.


Як це працює

Систему підключають два хуки Claude Code:

  • Stop hook (session-index.sh) — індексує щойно завершену сесію з JSONL-транскрипту в .claude/sessions.db, ембедить кожен фрагмент через bge-m3, якщо доступний Ollama.
  • SessionStart hook (session-recall.sh) — формує пошуковий запит з поточної git-гілки та останніх комітів, шукає в індексі та підвантажує найрелевантніші фрагменти як контекст сесії — автоматично, без ручного запиту.

Ручний пошук доступний у будь-який момент:

session-indexer search "config validation approach" --db .claude/sessions.db
# або з середини Claude Code:
/recall config validation approach

CLI

session-indexer mine   <jsonl-path> --db .claude/sessions.db
session-indexer search <query>      --db .claude/sessions.db [--limit N] [--json]
session-indexer embed               --db .claude/sessions.db
session-indexer stats               --db .claude/sessions.db

mine працює з дедлайном у 50 секунд (запас під 60-секундний бюджет Stop-хука) — збереження швидке й безумовне, ембединг враховує дедлайн. Фрагменти, що не встигли до дедлайну, все одно зберігаються, але позначаються для довантаження через embed — нічого не втрачається тихцем.

Якість пошуку

Коли доступні Ollama + bge-m3, пошук ранжує за косинусною подібністю на 1024-вимірних мультимовних embeddings (англійська й українська обидві працюють добре). Якщо Ollama недоступний або сховище ще без embeddings, пошук автоматично переходить на FTS5 BM25 за ключовими словами — без налаштування, без жорсткої залежності від зовнішнього сервісу.


Технологічний стек

  • Go 1.26 — єдиний статичний бінарник, без залежностей рантайму
  • SQLite (modernc.org/sqlite, чистий Go, без cgo) — сховище на проєкт
  • Ollama + bge-m3 — опційні векторні embeddings для семантичного пошуку
  • Cobra — CLI-фреймворк
  • FTS5 — автоматичний fallback на пошук за ключовими словами

Чому це важливо

Більшість AI-асистентів для розробки або забувають усе між сесіями, або приліплюють централізований сервіс пам’яті, який стає єдиною точкою відмови для всього вашого робочого процесу. session-indexer іде протилежним шляхом: нудний, per-project, append-only SQLite — той самий архітектурний інстинкт, що робить надійним сам Git. Якщо щось ламається — ламається поодиноко, і самозагоюється повторним індексуванням транскриптів, які й так лежать на диску.

Відкритий код, ліцензія MIT, зроблено для форків і адаптації.

🔗 https://github.com/valpere/session-indexer