Хирургия вместо кувалды — инструмент graph_patch

У цикла авто-исправлений (ADR-017) была проблема: единственный инструмент Builder’а для модификации графов был graph_update, требующий отправки всего JSON графа. Для сложной игры это 500-1000 строк. Исправить один аргумент в одном ActionFlow? Регенерировать все 1000 строк. А поскольку LLM — существа креативные — «исправление» одной вещи регулярно ломало три другие.

Мы рассматривали JSON Patch (RFC 6902), но он использует абсолютные индексы массивов (/nodes/14/actions/3). LLM ужасно считают индексы в длинных массивах. Builder гарантированно промахивался мимо нужного узла.

Решение — graph_patch, семантический инструмент патчинга. Вместо индексов он использует уникальные ID, которые Builder сам же и придумал:

• upsertNodes — добавить или заменить конкретные узлы по ID
• removeNodeIds — удалить узлы по ID
• updateSettings — изменить глобальные свойства графа

Сервер обрабатывает мердж. Builder отправляет 10-строчный патч вместо 1000-строчной регенерации. Работающие узлы остаются нетронутыми. Регрессии становятся физически невозможными, потому что Builder буквально не может тронуть узлы, которые не упомянул.

В цикле исправлений Builder теперь инструктирован использовать graph_patch для правок на уровне узлов и graph_update только при фундаментальном изменении архитектуры (переписывание 80%+). plugin_config_update обрабатывает точечные изменения конфигов.

Это был маленький инструмент с массивным эффектом на сходимость цикла исправлений. Радиус поражения снизился с «весь граф» до «конкретные узлы, упомянутые в патче».