ResolveConflicts Разрешить merge-конфликты так, чтобы сохранить намерения обеих веток. При высокой уверенности — завершить задачу до готового staged-состояния. При риске ошибки — остановиться и перейти в управляемый диалог с пользователем. Конфликтные маркеры — это симптом. Решение должно опираться на цель изменений в обеих ветках. Любое решение обосновывается фактами: история коммитов, итоговые diff от merge-base, контекст использования кода. Все сообщения оператору (вопросы, план, отчёты, итоговые решения) формулируй на русском языке. Английский допустим только для кода, команд, идентификаторов и технических терминов. Применяй изменения автоматически только при достаточной уверенности и отсутствии критичных сомнений. После автоматического разрешения обязательно проверь код: используй . Если есть неоднозначность, влияние на архитектуру или риск регрессии — переходи в диалог и не форсируй auto-resolve. Native IDE tools для чтения/редактирования/поиска — основной режим. Terminal для git-анализа и верификации: . Понять merge-контекст и список конфликтов. Прочитай ``. Зафиксируй: - `current_branch`, `incoming_branch`, `merge_base`; - список `` и их `path`, `status`, `kind`, `conflictRegions`, `binary`. Если `binary=true`, не пытайся редактировать бинарный файл автоматически: пометь как manual. Построить понимание, зачем меняли каждый конфликтующий файл в обеих ветках. Для каждого конфликтующего текстового файла: 1. Найди unique commits incoming-ветки для файла: от `merge_base..incoming`. 2. Найди unique commits current-ветки для файла: от `merge_base..current`. 3. Для каждой стороны зафиксируй: - краткий intent; - критичность (low/medium/high/critical); - масштаб (localized/global); - ключевые изменения. 4. Если commit history слишком большая, сначала возьми последние релевантные изменения, но не теряй критические правки (security/hotfix). Принять решение по каждому конфликтному региону. Для каждого конфликтного региона выбери стратегию: - `take-current` - `take-incoming` - `merge-both` - `rewrite` Для каждого региона сформируй: - `analysis`: почему возник конфликт; - `strategy`: выбранный подход; - `resolvedCode`: итоговый код без маркеров; - `confidence` (0-100); - `riskFlags`: список рисков (архитектура, безопасность, API-совместимость, тестовый пробел). Общие правила приоритета: 1. Критичный hotfix/security не теряется. 2. Рефакторинг не должен ломать исправления багов. 3. Если изменения совместимы — объединяй, а не отбрасывай. Выбрать режим: автоматическое применение или диалог с пользователем. - Примени resolvedCode ко всем регионам. - Удали конфликтные маркеры. - Выполни `git add` только для файлов, полностью разрешённых без сомнений. - Перейди к STEP_5. - Не выполняй auto-apply для спорных регионов. - Перейди в диалог с пользователем. - Покажи 1-3 точечных вопроса по развилке и предложи рекомендуемый вариант. - Для каждого спорного региона дай краткое сравнение вариантов (`current`, `incoming`, `merge`) и ожидаемые последствия. - Остановись и жди ответа пользователя. - Не вноси автоматические изменения в спорные участки. - Сформируй план ручного разрешения с приоритетами и рисками. - Запроси решение пользователя по каждому блокирующему региону. - Остановись и жди ответа пользователя. STEP_4 выбрал auto-apply для всех регионов или спорные регионы уже подтверждены пользователем. Проверить результат и отчитаться прозрачно. 1. Verify: 2. Сформируй отчёт: - какие файлы разрешены автоматически; - какие стратегии применены; - итоговый confidence по файлам; - какие команды проверки выполнены и их результат. 3. Если проверки упали — покажи причину и предложи дальнейшие шаги. 4. Не выполняй `git commit` автоматически. Итог должен содержать: - `Resolved Automatically` (список файлов и стратегии), - `Needs User Decision` (если есть), - `Verification` (какие команды и статус), - `Next Steps` (что сделать пользователю дальше).