vlm-code-context-mcp

Полноценная команда AI-инженеров. Один npm-пакет. Нулевая потеря контекста.

📖 Руководство по началу работы — Вы здесь впервые? Начните отсюда!

Владелец продукта. Архитектор. QA. Безопасность. Два разработчика. Scrum-мастер. Менеджер. Ведущий разработчик. Все выполняют реальные спринты. Все взаимодействуют с вашей кодовой базой. Все внутри одной базы данных SQLite.

npm install vlm-code-context-mcp
npx code-context-mcp setup .
npx code-context-dashboard ./context.db

Почему это существует

Каждый инструмент для AI-программирования натыкается на одну и ту же стену: модель расходует свое контекстное окно, просто читая вашу кодовую базу, прежде чем сможет сделать что-то полезное. Затем сессия заканчивается, и в следующий раз все начинается сначала.

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

vlm-code-context-mcp решает обе проблемы. Он предварительно индексирует весь ваш проект в структурированную базу данных SQLite, чтобы агенты запрашивали метаданные вместо исходного кода — в 25 раз меньше токенов, в 26 раз меньше данных для кодовой базы из 224 файлов. И он облекает этот интеллект в полноценную виртуальную scrum-команду, которая проводит реальные спринтовые церемонии через 81 инструмент MCP, с контрольными точками, ретроспективами, отслеживанием скорости работы и интерактивной React-панелью управления.

Это не трекер задач с прикрученным Claude. Это операционная система для разработки с использованием AI.

Что вы получаете за 60 секунд

Step 1/4 — Indexing files into context.db...
  Indexed 25 files, 142 exports, 87 dependencies

Step 2/4 — Loading scrum schema...
  Created 10 scrum tables

Step 3/4 — Importing team from .claude/agents/...
  Loaded 9 agents, 3 sprints, 24 tickets

Step 4/4 — Writing .mcp.json...
  Configured MCP server entry

=== Setup complete! (my-project) ===

Затем откройте панель управления:

npx code-context-dashboard ./context.db
# Opens at http://localhost:3333

Вот и все. Ваша AI-команда готова. Никаких API-ключей. Никаких внешних сервисов. Никакой зависимости от облака. Все живет в context.db.

Команда

У каждого агента есть определенная роль, системный промпт, доступ к инструментам, ограниченный их обязанностями, и показатель настроения, основанный на загрузке тикетами и настроении на ретроспективе. Система отслеживает признаки выгорания на протяжении спринтов.

Процесс спринта

Спринты проходят через 10 принудительных фаз с автоматическими проверками на контрольных точках:

preparation → kickoff → planning → implementation → qa → refactoring → retro → review → closed → rest

Контрольные точки реальны. Спринт не перейдет к QA, пока тикеты не будут назначены и оценены. Он не закроется, пока не будут зафиксированы результаты ретроспективы. Скорость работы отслеживается автоматически на протяжении каждого спринта и отображается на панели управления.

Панель управления

6 страниц. 68 компонентов. Живые обновления SSE.

Каждое изменение — смена статуса тикета, обновление настроения агента, переход фазы спринта — вызывает мгновенное обновление панели управления через мониторинг SQLite WAL. Никакого опроса. Никакого ручного обновления.

• Доска спринта — Канбан, вид планирования, трекер контрольных точек QA, диаграмма сгорания

• Проводник кода — Дерево файлов, граф зависимостей, карта экспорта/импорта, история изменений

• Управление проектом — Временная шкала Ганта, трекер вех, конвейер обнаружения, редактор видения

• Команда — Карточки состояния агентов, тренды настроения, распределение нагрузки

• Ретроспектива — Результаты по категориям, анализ паттернов между спринтами, отслеживание действий

• Маркетинг — Примечания к выпуску, позиционирование, анимация видения Remotion

📸 [скриншот здесь]
📸 [скриншот здесь]

Уровень моста

Самая сложная проблема в агентских инструментах — это двусторонняя связь, заставляющая UI и AI действительно общаться друг с другом в реальном времени.

src/bridge/ реализует хук PreToolUse, который соединяет Claude Code с панелью управления. Действия, поставленные в очередь в UI, обрабатываются запущенной сессией Claude Code. Именно это заставляет команду чувствовать себя живой, а не статической доской.

Это все еще находится в стадии доработки. PR приветствуются.

Эффективность контекста

Измерено на кодовой базе этого проекта (224 файла, 54 тыс. строк, 2,1 МБ):

Методология: задача "понять и изменить функцию" — поиск соответствующих файлов, понимание экспортов/импортов/зависимых элементов, просмотр недавних изменений. Без MCP агент читает ~20 необработанных файлов (в среднем по 9 200 символов каждый). С MCP он запрашивает структурированные метаданные через search_files, find_symbol и get_file_context — сводки, списки экспорта и графы зависимостей вместо исходного кода.

Первая индексация стоит дороже — файлы должны быть прочитаны для генерации метаданных. Каждый последующий запрос в 25 раз дешевле. Окупаемость после 1 использования. Экономия масштабируется с размером кодовой базы: проект из 25 файлов дает 3-кратное сокращение, этот проект из 224 файлов — 25-кратное.

Краткий обзор

История проекта

Построен полностью через собственный scrum-процесс. Виртуальная команда завершила 22 вехи, 69 продуктивных спринтов и 211 тикетов, составив в сумме 534 стори-пойнта с текущей скоростью ~20 пойнтов/спринт.

Результаты ретроспективы за 19 спринтов

Что прошло хорошо (основные паттерны):

• Подход "сначала исследование" последовательно устранял бесполезную реализацию. Проверка 3-4 подходов перед написанием кода сэкономила дни переделок (S59, S65, S68).

• Параллельное выполнение агентами значительно сократило время реализации. 4 агента работали над независимыми тикетами одновременно, пока основной поток координировал их (S59, S65, S67).

• Исследование перед кодом выявляло тупики на ранней стадии. S68 устранил 3 варианта мостовых подходов (именованные каналы, unix-сокеты, подписки на ресурсы MCP) за часы, а не дни.

• Паттерн миграции схемы (таблица schema_versions) сделал инкрементные изменения БД безопасными и повторяемыми. Ноль регрессий при 7 добавлениях схемы (S53, S55).

• Параллельный аудит безопасности выявил 2 ВЫСОКИЕ находки до того, как был выпущен какой-либо код (S68). Проведение аудитов параллельно с реализацией, а не после — правильный паттерн.

• Волновое выполнение — сначала выпуск фундамента, затем параллельное создание функций поверх него — привело к нулевым переделкам (S57).

• SSE + WAL watcher для реактивной панели управления устранили ручное обновление. Каждое изменение MCP вызывает мгновенное обновление UI (S53).

Что пошло не так (основные паттерны):

• Тесты помечены как ГОТОВО без их запуска. Агенты писали тесты, но не могли их выполнить — проверка сборки должна происходить до пометки ГОТОВО (S61, S65, S66).

• Существующие сбои тестов создавали шум, маскирующий реальные регрессии. Устаревшие тесты от старых изменений схемы продолжали всплывать (S53, S67, S68).

• Скорость исследования была обманчивой. В S56 было зафиксировано 46sp, но все тикеты были только документационными. Пойнты исследования должны отслеживаться отдельно от реализации.

• Общие заголовки тикетов без описаний или критериев приемки сделали QA невозможным. Каждый тикет нуждается в конкретном объеме работ (S53).

• Накопился технический долг фронтенда — компоненты на 800+ строк, 850+ встроенных стилей, ноль тестов. Нужно было заняться этим раньше (S59).

• Мост работает только тогда, когда Claude активно делает вызовы инструментов. Нет механизма "подталкивания", чтобы разбудить Claude для действий в очереди (S68).

Попробовать в следующий раз (основные пункты действий):

• Запускать npm run build после завершения работы каждого агента, перед пометкой тикета ГОТОВО (S65, S66, S67).

• Добавлять критерии приемки к каждому тикету в момент создания (S55).

• Проверять текущее состояние перед созданием тикетов на исправление — некоторые из них уже были решены (S58).

• Каждый новый инструмент write-MCP должен вызывать уведомление SSE — добавить как пункт чек-листа (S53).

• Реализовать каналы для истинной сигнализации на основе push, когда API стабилизируется (S68).

• Отслеживать пойнты исследования отдельно от скорости реализации (S56).