Как перенести производственный интерфейс, не теряя того, на что на самом деле полагаются пользователи

Каждая команда, пытавшаяся перенести реальное производственное приложение на новую платформу; Angular для React, Vue для Svelte, jQuery для чего угодно или даже просто обновление до новой основной версии с другой библиотекой компонентов — попадает в одну и ту же ловушку. Либо вы получите визуальную и поведенческую регрессию (кнопки, которые выглядят почти правильно, таблицы, которые сортируются по-другому, модальные окна, которые всплывают, а не скользят так, как у пользователей есть мышечная память), или миграция незаметно превращается в полный редизайн, потому что «пока мы там» неотразимы. Шесть месяцев спустя никто не может объяснить, почему новый экран счетов не работает так, как старый. Последние несколько недель я потратил на настоящую миграцию — несколько производственных приложений разного возраста, разные библиотеки пользовательского интерфейса, ни одна из которых не задокументирована — в одну общую систему проектирования, где ИИ-агент занимается чтением, каталогизацией и сборкой. Далее следует процесс, который помог нам пройти через это, не потеряв при этом того, что действительно важно: не точного CSS, а окончательного внешнего вида и поведенческого контракта, который уже известен пользователям. Это не руководство для конкретной платформы. В тематическом исследовании задействованы кодовые базы Angular, а в конвейере — токены, снятие отпечатков пальцев,