Celmis

Размещаемый у себя интеллект для работы с кодом — задавайте вопросы своим кодовым базам, рецензируйте pull request’ы и формируйте доказательства, которые запросит аудитор

celmis-labs.github.io · Документация · Быстрый старт · Результаты

Celmis один раз читает ваши репозитории и сохраняет их граф символов. Всё остальное — вопросы, рецензирования, аудит зависимостей, генерируемая документация — это разные способы чтения этого графа. Он работает на одной машине под управлением docker compose, с выбранным вами провайдером моделей за ним, и за пределы вашей сети ничего не уходит, кроме тех вызовов, которые вы настроили.

В древнейшем предании Келмис был плавильщиком — одним из трёх идейских дактилей, наряду с Дамнаменеем-молотом и Акмоном-наковальней, которым приписывали обработку железа. Индекс здесь выполняет восстановление; поверхности — это то, что обрабатывает результат.

Что это даёт такого, чего не может инструмент, работающий только с diff

Задайте вопрос, охватывающий два репозитория, — и ответ процитирует оба:

Это не результат поиска. Шлюз и платёжный сервис — отдельные репозитории без общего кода, и ответ прослеживает цепочку вызовов между ними, а затем, без дополнительной просьбы, замечает, что имя Kafka-топика жёстко прописано в обоих и что изменение одного незаметно ломает другой.

Рецензент, который структурно читает только diff, не может этого сказать. У него никогда не был открыт другой репозиторий.

Related MCP server: OpenCodeHub MCP Server

Семь вещей, которые люди с ним делают

Первые три — это то, чего инструмент рецензирования кода вообще не делает, и именно поэтому это платформа, а не рецензент: индексируйте один раз, а затем читайте этот индекс с той стороны работы, на которой вы находитесь.

Три числа

Последний показатель намеренно нелестный, и он остаётся. Он измеряет одну из описанных ниже поверхностей — рецензирование pull request на изолированных PR в пределах одного репозитория, — а в этом наборе нет соседнего сервиса, в котором у символа могли бы быть потребители, так что то, вокруг чего построен этот продукт, в цифре вообще не отражено. Таблица, аудит каждого вывода, который система пометила ложным, и команда, воспроизводящая и то и другое, — в разделе Результаты.

Содержание

• Что это даёт такого, чего не может инструмент, работающий только с diff

• Семь вещей, которые люди с ним делают

• Три числа

• Быстрый старт

• Первый пользователь и администратор

• Подключение репозитория

• Спросить код

• Рецензирование pull request

• Зависимости, SBOM и комплект доказательств

• Исправить отсюда

• Кто что видит

• Языки и форматы

• Детерминированные проверки — без модели и ложных срабатываний

• Подключение Claude Code и других MCP-клиентов

• Результаты

• Аудит ложных срабатываний

• Тестовые репозитории

• Конфигурация

• Эксплуатация

• Локальная разработка

• Справочник CLI

• Архитектура

• Устранение неполадок

• Структура проекта

• Происхождение и права

Быстрый старт

Что вам понадобится

Postgres и Qdrant входят в комплект — внешний кластер разворачивать не нужно. Для запуска через Docker не требуется установка Python или Node.js.

Запуск

git clone <your-fork-url> celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

Откройте http://localhost.

Здесь ничего не собирается. Три образа загружаются из реестра, заданного переменной CELMIS_REGISTRY, по тегу из CELMIS_TAG, для linux/amd64 и linux/arm64 — и Apple Silicon, и ARM-сервер получают нативный образ. Сборка на самой машине, где они работают, была измерена: 485 секунд и 4.2 ГБ диска только для api, именно поэтому установка больше не означает компиляцию.

Порт 80, а не 3000: обратный прокси размещает приложение и его API на одном origin и обслуживает API по адресу /backend. Это не предпочтение по развёртыванию — браузерный бандл запрашивает относительный путь, и это единственный способ, которым один опубликованный образ может обслуживать любую установку, а не только ту, на которой он был собран.

Чтобы работать НАД Celmis, а не просто запускать его, добавьте dev-оверлей — и локальная сборка снова станет доступна:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

init-env.sh --check сообщает, что ещё не заполнено, ничего при этом не записывая.

Это рендер записанной сессии, а не запись экрана, — цифры в нём те, что получены в ходе запуска 26 августа 2026 года, а вывод compose дословно взят из logs/03-up.log в отчёте об установке. Он нарисован, а не сфотографирован, потому что второй стек нельзя поднять рядом с работающим: в docker-compose.yml зафиксирован container_name, поэтому имена конфликтуют.

Остановка

docker compose down       # stop, keep your data
docker compose down -v    # stop and DELETE every volume

Первый пользователь и администратор

Форма регистрации на /login работает, как только стек переходит в рабочее состояние. Такая учётная запись — обычный пользователь: регистрация не даёт прав администратора, даже первому вошедшему.

Глобальный администратор задаётся через окружение: войдите с CELMIS_MASTER_EMAIL и CELMIS_MASTER_KEY (в качестве пароля) — обе переменные находятся в .env. Администратором является тот, кто запускает сервер, — это модель, которая нужна self-hosted-установке, а не тот, кто первым добрался до формы. Этот путь не существует, пока не заданы обе переменные, и каждое его использование записывается в журнал аудита.

Чтобы повысить обычную учётную запись:

docker compose exec api analyzer auth make-admin you@example.com

Подключение репозитория

1. Settings → LLM Setup — вставьте ключ провайдера. Он шифруется с помощью CREDENTIAL_MASTER_KEY до того, как попадёт в базу данных, а интерфейс снова показывает вам только первые и последние четыре символа.

2. Connections — добавьте токен GitHub, GitLab или Bitbucket. Используйте служебную учётную запись (machine account), а не личную: персональный токен открывает доступ ко всем репозиториям, которые вы видите, а токены попадают в резервные копии, журналы и скриншоты.

3. Repositories → Add — выберите репозитории у провайдера или вставьте URL клонирования. Индексация становится в очередь; задача появляется на той же странице.

Индексация по одному и тому же checkout строит две вещи: граф символов (определения, вызовы, импорты — то, на чём строят рассуждения агенты рецензирования) и эмбеддинги в Qdrant (то, что извлекает Q&A). Репозиторий со 120 тысячами символов обрабатывается около минуты на четырёх ядрах.

Двадцать три языка разбираются в граф. Файл на языке, для которого нет парсера, объявляется об этом явно, а не молча пропускается — analyzer graph-stats перечисляет, что было прочитано, а что нет.

Спросить код

Вопрос в чате — ответ приходит с цитатами вида файл:строка из стольких репозиториев, сколько вы укажете. Ответы транслируются по мере их написания.

Сгруппируйте репозитории в проект — и вопрос будет задан всей группе:

Ответы цитируют настоящий код, и только тот код, который спрашивающему разрешено видеть, — именно поэтому вопрос можно безопасно передать человеку вне команды, владеющей репозиторием. См. Кто что видит.

Рецензирование pull request

Агенты читают дифф и публикуют замечания в GitHub, GitLab или Bitbucket. Вместо того чтобы показывать это на скриншоте данного интерфейса, ревью остаются там, где были опубликованы, — пятьдесят пул-реквестов в реальных проектах, с комментариями, всё ещё привязанными к строкам, к которым они относились. Они перечислены в разделе Тестовые репозитории, и вывод там не редактировался, включая замечания, которые аудит ниже помечает как ошибочные.

Там, где граф построен, ревью также несёт то, чего дифф не показывает: кто ещё вызывает изменяемый символ, в том числе из другого репозитория. Там, где граф не построен, ревью всё равно выполняется — просто отвечает на более узкий вопрос, который и измерял бенчмарк.

Каждое замечание, которое бенчмарк оценил как ложное, было открыто в исходном коде и опубликовано с вердиктом. Тридцать три из семидесяти девяти оказались реальными дефектами, которых нет в золотом наборе. Эта работа находится в разделе Аудит ложных срабатываний — с кодом и постоянной ссылкой для каждого, так что вы можете не согласиться с любым из них.

Зависимости, SBOM и комплект доказательств

Аудит зависимостей детерминирован: нативные аудиторы там, где установлен инструмент, OSV во всех остальных случаях, без участия модели. Языковая модель, если дать ей ключ, пишет сводку — но не решает, что уязвимо.

Из каждого аудита получаются два файла, и ни одному не нужен ключ LLM:

• SBOM — инвентаризация CycloneDX каждой зависимости, её версии, URL пакета и известных для неё уязвимостей. Это тот файл, который имеют в виду, когда говорят «пришлите нам ваш SBOM».

• Комплект доказательств — аудит как подшивка: каждый SBOM, каждое замечание, хронология прошлых запусков и sha256 каждого файла, чтобы третья сторона могла проверить, что ничего не было отредактировано задним числом, не доверяя нам. Папка, содержимое которой можно изменить позже, ничего не доказывает; манифест — вот что делает её доказательством.

Рядом с ними — сгенерированная техническая документация: модульные PRD, описания функций и руководства по интеграции, написанные по коду. Она остаётся вашей и продолжает работать после завершения любой подписки.

Почему это существует сейчас. С 11 сентября 2026 года EU Cyber Resilience Act требует от производителя сообщать в ENISA об активно эксплуатируемой уязвимости в течение 24 часов. Формальное требование SBOM вступает в силу в декабре 2027 года, но вы не можете ответить на вопрос о 24 часах без видимости на уровне компонентов — чтобы сообщить, что затронуто, нужно знать, что внутри.

Celmis не заявляет о соответствии и не будет. Он создаёт артефакты, необходимые для подачи документов. Достаточна ли подшивка — суждение юриста, и инструмент, намекающий на обратное, продаёт ложное чувство безопасности.

Ещё одна вещь, которую страница аудита проговаривает вслух, потому что это сбой, которого никто не ищет: экосистема, которую никто не сканировал, сообщает о нуле уязвимостей точно так же, как чистая. Рядом с замечаниями показано покрытие: какой аудитор получил каждый результат и, что полезнее, что осталось непроверенным и почему.

Исправление отсюда

Найти проблему — это половина цикла. Встроенная сессия Claude Code запускается внутри инсталляции, правит рабочую копию, а раннер коммитит изменения, пушит ветку и открывает пул-реквест.

Уязвимость в аудите зависимостей сопровождается кнопкой Fix with Claude. Она открывает не пустой чат — она передаёт сессии репозиторий, пакет, обе версии и границы задачи уже описанными:

Вот один такой цикл целиком, на реальном замечании — lodash 4.17.11 с известной уязвимостью. 220 секунд от Start session до открытого пул-реквеста, за пять ходов:

Read package.json
  → "Only package.json has lodash; no requirements.txt/pyproject/go.mod exist here."
Edit package.json: "lodash": "4.17.11" → "4.18.0"
mcp__exec__run: cat package.json | grep -A2 lodash; ls
  → "Confirmed no other manifest files exist, so no other changes were needed."

Ветка, которую он запушил, и пул-реквест, который он открыл, на GitHub:

Посмотрите, чего нет в этом диффе. axios 0.21.1, minimist 1.2.0, node-fetch 2.6.0 находятся на строках непосредственно выше и ниже — все устаревшие, все отмечены в том же аудите — и все нетронуты. Задача гласила: только манифесты, и агент, прибравший заодно ещё три, был бы худшим результатом для ревью, а не лучшим.

Это живой пул-реквест, а не скриншот: celmis-demo-gateway#6 — ветка celmis-agent/b8960e01, один коммит, +1/-1.

В этом транскрипте две детали ценнее самого диффа. Агент не предполагал, что других манифестов нет, — он выполнил команду в песочнице, чтобы проверить. И задача гласила: «только манифесты, не трогайте посторонние зависимости», поэтому изменение — ровно одна строка.

Что раннер разрешает, а что нет

Это решает раннер, а не промпт, — и эту часть стоит прочитать, прежде чем давать агенту любые права:

• Никакой собственной оболочки. Bash, WebFetch, WebSearch и редактирование блокнотов запрещены. Команды выполняются через контейнер песочницы, который представляет собой отдельный сервис со своим uid и доступной только для чтения корневой файловой системой.

• Git — работа раннера. Агент никогда не коммитит и не пушит. Когда работа завершена — или когда вы нажимаете Finish & push — раннер создаёт коммит, пушит ветку и открывает PR. Никогда не в ветку по умолчанию.

• Лимит провайдера — это пауза, а не потеря. Первая попытка запуска выше упёрлась в недельный лимит аккаунта в середине сессии. Сессия не умерла: она перешла в состояние paused, сохранила свою работу возобновляемой на четырнадцать дней и показала собственное сообщение провайдера, а не общий сбой. Второй ключ довёл её до конца.

• За сессией можно наблюдать. Вывод транслируется через SSE с возможностью повтора, так что при переподключении воспроизведение продолжается с места разрыва, а не начинается с пустоты.

Подключение — это установочный токен, который хранится для каждого пользователя или рабочего пространства. API никогда не возвращает его после сохранения — только то, есть ли он и работает ли он до сих пор.

Кто что видит

Доступ определяется для каждого репозитория и каждой команды и управляет сразу всеми поверхностями — Q&A, граф, поиск, MCP:

Именно это делает сценарий соседней команды работающим, а не обещанием: загрузите репозиторий, дайте другой команде право задавать вопросы и запретите пути, которые нельзя читать. Они получают ответы; эти файлы отклоняются у источника, а не отфильтровываются из ответа, который их уже содержал.

Языки и форматы

Семнадцать графовых модулей плюс универсальный путь через tree-sitter tag-запросы для языков без такого модуля:

Код — Python, TypeScript, JavaScript, Go, Java, C#, C++, PHP, Vue и другие через универсальный путь.

Инфраструктура — Dockerfile, docker-compose, Helm, манифесты Kubernetes, Terraform и CI-пайплайны. Это та часть, которую большинство инструментов анализа кода пропускает, и именно поэтому вопрос может перейти от функции к определению сервиса, который её запускает.

Детерминированные проверки — без модели, без ложных срабатываний

Каждая проверка ниже решается чтением файлов. Ни одна языковая модель не участвует в решении, что что-то не так, поэтому доля ложных срабатываний равна нулю по построению, а не по настройке.

Именно в этом различии вся суть. Около двадцати процентов ложных срабатываний — это тот порог, после которого разработчики вообще перестают читать комментарии инструмента: одно стоит секунд внимания, тысяча стоит вам команды, которая научилась пропускать всё, что говорит инструмент. Модель здесь используется для объяснения и приоритизации, но никогда для обнаружения.

Обычное сканирование CVE намеренно отсутствует в этом списке. OSV-Scanner уже делает это, он бесплатен и является стандартом де-факто — Celmis запускает его (плюс собственный аудитор каждой экосистемы: pip-audit, npm audit, govulncheck, cargo audit) и считает результат входными данными, а не фичей.

О соответствии. Celmis создаёт артефакты, которые запрашивает аудит: CycloneDX SBOM, реестр зависимостей, историю замечаний с временными метками и доказательства, на которых основано каждое замечание. Он не утверждает, что ваша подшивка достаточна, и ни один инструмент честно не может: то, что принимает аудитор, зависит от вашей отрасли, вашей юрисдикции и ваших собственных контролей. Создавайте артефакты; пусть те, чья это работа, их оценивают.

Подключение Claude Code и других MCP-клиентов

Celmis предоставляет свой индекс через MCP, так что агент может искать символы, читать API-поверхности и находить потребителей, вместо того чтобы грепать рабочую копию, которой у него нет.

По HTTP (работающий стек отдаёт его по адресу /mcp/):

# Mint a token (or issue one from Settings → MCP in the UI)
docker compose exec api analyzer mcp issue-token \
  --scopes "read:graph read:groups" --duration 86400

// ~/.claude.json  (or .mcp.json in a project)
{
  "mcpServers": {
    "celmis": {
      "type": "http",
      "url": "http://localhost:8000/mcp/",
      "headers": { "Authorization": "Bearer <the token you just minted>" }
    }
  }
}

По stdio, без HTTP-перехода:

{
  "mcpServers": {
    "celmis": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "api", "analyzer", "mcp", "serve"]
    }
  }
}

Что агент может спросить

HTTP-интерфейс предоставляет 18 инструментов. Они отвечают на вопросы, на которые grep не может:

Два транспорта — это не один и тот же набор. analyzer mcp serve через stdio предоставляет 13 более старых инструментов, работающих с графом (find_symbol, find_callers, query_graph); HTTP-версия предоставляет 18 инструментов из таблицы выше. Ни один из них не является подмножеством другого — выбирайте транспорт под нужные вам инструменты.

Пошаговое руководство с областями видимости, которые нужны каждому инструменту, и сценариями отказов находится в .claude/skills/celmis-mcp/SKILL.md. Claude Code подхватывает его автоматически, когда этот репозиторий открыт.

Что агент может запросить

Один вызов search_symbols, один контрактный символ — и ответ приходит из двух репозиториев на двух языках клиенту, который не клонировал ни один из них. Граница, которую никогда не пересекает diff, — именно её этот вызов делает обычным делом.

Восемнадцать инструментов, доступных через Streamable HTTP по адресу /mcp/ и аутентифицируемых тем же bearer-токеном, что и /api/:

cross_repo_edges — тот инструмент, который стоит понять, потому что именно ради него этот продукт вообще содержит граф символов. Ревьюер, работающий только с diff, — как и любой инструмент из таблицы бенчмарка выше, включая этот, когда граф пуст, — может сказать вам, что сигнатура функции изменилась. Но он не может сказать, что сервис в другом репозитории всё ещё вызывает старую форму, потому что этот репозиторий у него никогда не был открыт. Сгруппируйте репозитории один раз — и этот вопрос становится разрешимым:

> which services outside this repo call PaymentGateway.charge?

Это также причина, по которой наш ранг в бенчмарке преуменьшает продукт, а не описывает его: набор бенчмарка — это изолированные pull request'ы из одного репозитория, поэтому рядом нет репозитория-«соседа», через границу которого мог бы пройти вызов. Эта возможность реальна, но бенчмарк её не видит — это утверждение о бенчмарке, а не заявление, которое стоит принимать на веру. Направьте MCP-клиент на свою группу и проверьте.

Результаты

Celmis запускался на офлайн-наборе Martian Code Review Bench: 50 отобранных pull request'ов, 173 написанных человеком эталонных комментария, оценённых против золотого набора LLM-судьёй. Измерено на e0db376 с gemini-3.6-flash при температуре 0.1, без токенов рассуждения.

F1 меняется на 4,8 пункта в зависимости от того, кто судит. Место не меняется вовсе — семнадцатое у всех трёх. Ниже нас во всех трёх: CodeRabbit (19/25/23), все версии Greptile (26–29), Kodus (21/23/21), Copilot, Claude Code, Gemini и CodeAnt.

Весь прогон стоил $5.88 — $0.118 за pull request — и дал 153 находки, 3.06 на PR (дефекты 114, безопасность 27, контракты 6, структурные 6).

Почему это сравнение честное. Martian публикует в репозитории бенчмарка собственные оценки 49 инструментов, полученные теми же тремя судьями на тех же 50 PR против тех же эталонов. Мы никого не переоценивали: их строки взяты в том виде, в каком они опубликованы, а наша добавлена. Воспроизвести всю таблицу можно так:

python3 autoloop/offline_table.py anthropic_claude-sonnet-4-5-20250929

Офлайн — это не публичная таблица лидеров. Martian запускает два бенчмарка. Публичная таблица лидеров — онлайн-бенчмарк: 200 000 реальных pull request'ов, оценённых по тому, что разработчики фактически исправили. Эта таблица — офлайн-бенчмарк: 50 отобранных PR, оценённых по золотому набору. Они измеряют разные вещи, и числа не взаимозаменяемы. Утверждения вида «инструмент X — №1 на Martian» обычно относятся к онлайн-таблице, другой метрике или другому судье.

Чего в этом числе нет. Граф был пуст для всех 50 PR (graph_status null, drift пуст в каждом), потому что набор бенчмарка — это изолированные pull request'ы из одного репозитория: нет соседнего сервиса, в котором у символа могли бы быть потребители. Межрепозиторный дрейф — то, ради чего этот продукт содержит граф символов, — не внёс в оценку выше ровно ничего. Здесь он неизмерим, и мы не заявляем его на основании этой таблицы. Смотрите Тестовые репозитории, чтобы увидеть его работу на реальном коде.

Аудит ложных срабатываний

У оценки в бенчмарке есть структурное ограничение: судья сопоставляет наш комментарий с конечным списком написанных человеком эталонов, поэтому корректная находка, которую аннотатор не записал, считается ложной по построению. Мы открыли все 79 наших находок в исходном коде на измеренном коммите и вынесли вердикт по каждой.

Из 79 находок, засчитанных как ложные срабатывания, 33 — реальные дефекты, которых нет в золотом наборе, 38 — действительно ошибочны, а 8 невозможно однозначно оценить по коду. Это означает, что истинная точность этого прогона составляет от 69.7% до 75.0%, а не измеренные 48.0%, — но эту скорректированную цифру нельзя сравнивать ни с чем из таблицы выше, потому что никто не проверял другие инструменты тем же способом, и в их ложных срабатываниях почти наверняка есть сопоставимая доля реальных дефектов; для сравнения с другими инструментами честным числом являются измеренные 48.0%, потому что это тот же метод, применённый ко всем.

Двадцать четыре из 38 действительно ошибочных находок имеют четыре общие корневые причины, и ни одна из них не сводится к «слабой модели» — все четыре касаются того, что было показано модели. Самая массовая причина — идентификатор, объявленный в том же файле, но вне фрагмента, который получил агент: параметр метода на 26 строк выше, импорт на строке 3, attr_reader на строке 18.

В полном отчёте по каждой из 79 находок приведены утверждение, код на том коммите, вердикт, обоснование и permalink, так что любой вердикт можно оспорить, имея перед собой те же доказательства.

Тестовые репозитории

Все ревью из прогона выше до сих пор активны и публичны. Это настоящие pull request'ы из реальных проектов, форкнутые вместе с историей и содержащие инлайн-комментарии, которые написал Celmis:

Стоит открыть в первую очередь:

• keycloak#17 — разыменование null и вопрос об индексации кода восстановления в тестовом провайдере хранилища Keycloak

• grafana#16 — сбой Storage, записанный в метрику Legacy, один из трёх случаев той же ошибки в этом файле

• cal.diy#11 — forEach с асинхронным колбэком: удаления выполняются в режиме fire-and-forget, и окружающий try не ловит ничего

• sentry#11 — семь инлайн-комментариев в одном PR про Kafka consumer

Вы читаете неотредактированный вывод, включая находки, которые аудит выше помечает как ошибочные. После оценки ничего не удалялось.

Конфигурация

./scripts/init-env.sh записывает .env из .env.example и генерирует все секреты. В примере каждый секрет намеренно пуст: в предыдущей версии команда генерации стояла рядом с переменной, в dotenv-файлах нет инлайн-комментариев, и каждая установка, скопировавшая этот файл, запускалась с мастер-паролем, напечатанным в репозитории.

Настройки попадают в контейнеры только через блок environment: в docker-compose.yml — образ не содержит .env. Переменная, не указанная там, получает значение по умолчанию из кода, что бы ни лежало в вашем .env. GET /healthz сообщает таймеры ревью так, как их фактически разрешил процесс, — так вы проверяете, что реально дошло.

Эти таймеры задокументированы как набор в .env.example вместе с инвариантом, который их связывает:

REVIEW_LLM_TIMEOUT_SECONDS × (1 + RETRY_FACTOR)  ≤  REVIEW_TIMEOUT_SECONDS

Увеличите один — за ним должен последовать другой; это проверяется тестом.

Операции

docker compose logs -f api            # follow the API
docker compose exec api analyzer graph-stats <repo>   # what parsed, what did not
./scripts/backup.sh                   # Postgres + volumes
./scripts/restore.sh <archive>

Администрирование → Мониторинг показывает глубину очереди, расходы по рабочим пространствам и настройки моделей для каждого агента. Использование и расходы разбивает расходы по областям продукта, поэтому пакетная сборка документации не выглядит как чат.

Развёртывание на сервер выполняется командой ./scripts/deploy-on-server.sh v0.1.0, запускаемой на сервере: она загружает опубликованные образы, поднимает стек за Caddy и помечает сборку, на которую ссылается нижний колонтитул AGPL. Ничему за пределами этой машины для этого не нужны учётные данные. См. docs/ORACLE_CICD.md или docs/HETZNER.md для обычной виртуальной машины.

Локальная разработка

# Postgres and Qdrant from compose, everything else on the host
docker compose up -d postgres qdrant

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

alembic upgrade head
uvicorn src.api.main:app --reload --port 8000

cd web && npm install && npm run dev     # http://localhost:3000

pytest -q                # the suite
ruff check .             # lint, ratcheted at zero
cd web && npx tsc --noEmit

Справочник по CLI

analyzer устанавливается командой pip install -e .; внутри Docker используйте docker compose exec api analyzer …. У каждой команды есть --help.

Сгруппированные подкоманды: analyzer repo, analyzer group, analyzer auth, analyzer mcp, analyzer scip.

Архитектура

                      ┌──────────────┐
   GitHub / GitLab ──▶│   webhook    │──┐
   Bitbucket          └──────────────┘  │
                                        ▼
   Browser ──▶ web (Next.js) ──▶ api (FastAPI) ──▶ Postgres   jobs, policies, audit
                                     │              Qdrant     embeddings
                                     │              sandbox    untrusted execution
                                     ▼
                              model provider
                       (direct, or via a LiteLLM gateway)

• Postgres хранит задания, политики, историю запусков, расходы и журнал аудита. Устойчивая очередь заданий — это таблица: извлечение из очереди выполняется через SELECT … FOR UPDATE SKIP LOCKED, и воркер продлевает свою аренду, пока работает, а не угадывает длительность заранее.

• Qdrant хранит эмбеддинги: одна коллекция на инсталляцию, изоляция рабочих пространств обеспечивается фильтром.

• sandbox запускает всё недоверенное — набор тестов, сборку — под собственным uid в собственной сети, без базы данных, без ключей и с корневой файловой системой только для чтения.

• LiteLLM необязателен. Задайте LITELLM_PROXY_URL и LITELLM_MASTER_KEY вместе — и каждый вызов пойдёт через шлюз; оставьте любую из них пустой — и будут напрямую использоваться ключи провайдера.

Устранение неполадок

Контейнер не запускается. docker compose logs <service>. API при запуске сообщает, какие опциональные функции недоступны и почему, а не молча выходит из строя.

Проверки не дают результатов. Проверьте в GET /healthz итоговые значения таймеров, затем docker compose logs api | grep agent_. Каждый агент записывает в лог затраченное время, свою модель и код сбоя.

Тайм-аут, а не сбой. local_timeout означает, что собственный срок этой инсталляции истёк раньше, чем ответил провайдер, — увеличьте REVIEW_LLM_TIMEOUT_SECONDS. Это намеренно не сообщается как сбой провайдера.

Q&A не приводит источники. Вероятно, репозиторий не проиндексирован либо проиндексирован без эмбеддингов. Репозитории показывает состояние каждого; analyzer graph-stats <repo> показывает, что было разобрано.

Песочница постоянно занята. SANDBOX_SLOTS — сколько заданий выполняется одновременно; это регулятор, который определяет расход памяти. SANDBOX_SLOT_WAIT — как долго вызывающий ждёт в очереди, прежде чем ему скажут вернуться позже.

Структура проекта

src/
  api/          FastAPI app, routers, schemas
  review/       PR review — agents, orchestrator, providers, policies
  indexing/     parsers, symbol graph, embeddings
  qa/           retrieval and answer composition
  generation/   documentation vault
  llm/          provider clients, error taxonomy, cost ledger
  sync/         git providers, the durable job queue, workers
  sandbox/      the isolated execution server
  mcp_server/   the MCP surface
  security/     redaction, patterns, log filtering
web/            Next.js UI (App Router, 16 locales)
tests/          5200+ tests
deploy/         Caddy overlay and the LiteLLM gateway config
docs/           deploy guides and the end-to-end walk-through
bench/          benchmark harness and results

Происхождение и права

Этот репозиторий имеет единственный корневой коммит объёмом около ста тысяч строк — так выглядит для сканера происхождения кодовая выкладка неясного происхождения, и это нуждается в объяснении, а не в пожатии плечами. Объяснение есть: PROVENANCE.md содержит позицию по лицензии и происхождение кода — разработка велась в частном порядке до этого коммита, и ничего из неё не нужно, чтобы собрать, проверить или форкнуть то, что здесь находится.

Этот файл — фиксация фактов, а не лицензия. Лицензия — AGPL-3.0, с одним исключением: всё, что находится в ee/, и любой файл, в имени которого есть .ee., покрывается LICENSE_EE вместо неё. В ee/ сегодня нет кода продукта — граница была проведена до первого тега, потому что добавление её позже означает необходимость заново спрашивать каждого участника, который уже прислал работу под безоговорочной AGPL.

Всё, что здесь публикуется, распространяется под AGPL, включая части, которые выглядят коммерческими: консоль аудита, использование и расходы, проверки соответствия, метрики инсталляции. Меры безопасности никогда не бывают доступны только в enterprise-версии — аудиторский журнал пишется под AGPL и всегда будет писаться под ней. См. CONTRIBUTING.md о том, куда идёт новый код.