Сравнение версий с REA: что изменило обновление?

01. Конкретизируйте регрессию

«Обновление сломало экспорт» оставляет слишком много места для догадок. Запишите ввод, действие и различие: например, заголовок с кавычкой до обновления экспортировался корректно, а теперь даёт некорректную строку CSV.

Поместите две версии приложения в отдельные папки. Запишите обозначения выпусков и хеши артефактов. Сравнивайте равнозначные артефакты: дерево исходников для разработки и минифицированная производственная сборка — разные виды данных.

npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. Сравните сохранённые данные анализа

Сохраняйте полные исходные результаты JSON. Процесс сравнения ожидает данные анализа приложения с подтверждённой подлинностью; вручную отредактированное резюме или список файлов их не заменят.

Попросите подключённого агента изучить доступную схему compare_application_versions и передать два результата в соответствии с ней. Так не придётся угадывать вложенные поля, которые могут меняться между выпусками. CLI может показать тот же контракт.

npx -y rea-agents@6.4.0 compare-application-versions --schema

Используй REA compare_application_versions с полными данными анализа приложения из before.json и after.json. Сначала проверь схему установленного инструмента. Сосредоточь отчёт на экспорте CSV: изменённые модули, связанные пути вызовов и неразрешённые соответствия. Не считай отсутствие узла при частичном охвате доказательством удаления.

03. Сравнивайте функцию, а не минифицированные имена

Начните с уже знакомой кнопки, канала IPC или средства форматирования. Проследите функцию в обеих версиях и изучите изменённый код. Минифицированные имена переменных часто меняются при пересборке без изменения поведения.

Хеш модуля может установить точную идентичность. Переименование функции или новый номер фрагмента сборки сами по себе не доказывают изменение смысла. Явно показывайте в отчёте несопоставленные и частично разобранные области.

• Есть ли в обеих версиях соответствующая точка входа функции?
• Какой участок кода действительно отличается?
• Влияет ли изменённая ветвь на неудачный ввод?
• Может ли различие объясняться упаковкой, конфигурацией или неполным охватом?

04. Повторите одинаковый ввод в обеих версиях

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

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

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

05. Напишите полезный отчёт об ошибке

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

Хорошее сравнение даёт следующее действие: регрессионный тест, обходной путь для совместимости или узкую замену. Это руководство описывает процесс; оно не заявляет о регрессии в конкретном коммерческом выпуске.