Проектам с экспортированным исходным кодом нужна проверка переносимости

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

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

Проекты с экспортированным исходным кодом всё ещё могут зависеть от конструктора

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

Часто смешивают три разных утверждения. Доступ к исходникам означает, что вы можете изучать файлы. Независимость сборки означает, что вы можете создавать артефакты без обращения к конструктору. Независимость во время работы означает, что эти артефакты продолжают обслуживать реальные запросы без конструктора. Поставщик может выполнить первое обещание и не выполнить два остальных.

Это различие напрямую влияет на договор. Если он обещает «экспорт исходного кода», вы можете получить каталог React, манифест пакетов и README, но всё равно нуждаться в проприетарном SDK или размещённом шлюзе. Просите не файлы, а операционный результат: уполномоченный инженер должен уметь собрать и запустить принятый релиз в чистой среде, используя аккаунты, принадлежащие заказчику.

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

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

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

Отслеживайте приложение во время реальных сценариев

Обратные вызовы во время работы проявляются, когда вы наблюдаете DNS, исходящие соединения, запросы браузера и фоновые задачи во время типичных сценариев. Мало того, что загрузилась главная страница. Проверьте вход, восстановление пароля, загрузку файлов, поиск, изменения оплаты, доставку писем, запланированные задачи, административные действия и все функции с AI, которые продукт действительно продаёт.

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

Инструменты разработчика в браузере важны, потому что некоторые зависимости никогда не затрагивают ваш сервер. Очистите хранилище, откройте новую сессию и изучите вкладку Network. Проверьте хосты запросов, неудачные preflight-запросы, WebSocket-соединения, загруженные скрипты и перенаправления. Фронтенд может обращаться к API конструктора напрямую, даже если серверный репозиторий выглядит самодостаточным. Service worker тоже может сохранять старое поведение, поэтому перед повторным тестом отмените его регистрацию.

В Unix-подобном дереве исходного кода этот поиск даст полезный первый список:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

Ожидайте строки вида path/to/file:line:matching text. Lock-файлы, созданные инструментами, проверяйте отдельно от кода приложения, поскольку домен в метаданных пакета не доказывает вызов во время работы. И наоборот, чистый поиск не доказывает независимость: переменные окружения могут собирать хосты, DNS-псевдонимы могут их скрывать, а бинарные зависимости могут выполнять собственные запросы.

Отдельно ищите термины поставщика, импорты SDK и префиксы переменных окружения. Затем изучите lock-файлы, чтобы понять, пакеты берутся из публичного или частного реестра поставщика. Здесь вас может обмануть успех из кэша. Удалите кэши пакетов языка в изолированной тестовой среде и пересоберите проект, используя только документированные учётные данные реестра.

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

Не принимайте слова «этот обратный вызов относится только к телеметрии», пока не проверите его отказ. Заблокируйте его и повторите сценарий. Необязательная телеметрия должна быстро завершаться по тайм-ауту или падать без влияния на действие пользователя. Я видел вызовы логирования внутри транзакции запроса, из-за которых безобидный сбой аналитики приводил к ошибке сохранения. Риск определяет не ярлык, а путь выполнения кода.

Проприетарным SDK нужен путь удаления или лицензирования

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

Составляйте список зависимостей и по манифестам, и по импортам в исходном коде. Для JavaScript изучите package.json и lock-файл. Для Go проверьте go.mod и контрольные суммы. Для Flutter проверьте pubspec.yaml и lock-файл. Отметьте пакеты из Git-репозиториев, частных реестров, локальных путей или архивов. В таких местах часто скрываются компоненты под контролем конструктора.

Для каждого сомнительного пакета ответьте на четыре конкретных вопроса:

1. Может ли новый агент сборки под контролем заказчика скачать точную версию?
2. Разрешает ли лицензия использовать пакет в рабочей среде после окончания договора с конструктором?
3. Обращается ли пакет к сервису, на который заказчик может оформить прямой договор?
4. Достаточно ли мал интерфейс для замены и покрыт ли он тестами?

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

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

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

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

Аутентификация выходит за пределы дерева исходного кода

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

Начните с изображения пути входа как реальных переходов. Браузер обращается к приложению, приложение перенаправляет к провайдеру идентификации, провайдер возвращает пользователя на зарегистрированный обратный вызов, а бэкенд обменивает или проверяет учётные данные. На каждом переходе зафиксируйте владельца и место конфигурации. Если какая-либо консоль доступна только через организацию конструктора, до приёмки нужен перенос или замена.

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

OpenID Connect определяет claim sub как локально уникальный, никогда не переназначаемый идентификатор в области действия issuer. Issuer имеет значение. Если считать один sub глобально переносимым, после смены клиента можно привязать не ту запись приложения. Храните и сравнивайте issuer вместе с subject, а затем разработайте явное сопоставление для миграции.

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

Ищите в репозитории URI перенаправления, ID клиентов, имена issuer, домены cookie, значения audience и ссылки на ключи подписи. Не храните секреты в репозитории, но включите в документацию по развёртыванию их имена, владельцев, шаги создания и ротации, а также обязательные форматы. Пример файла окружения должен описывать договор без действующих значений:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

Не принимайте общий клиент конструктора как постоянное решение лишь потому, что миграцию можно провести «позже». Миграция идентификации затрагивает каждого активного пользователя и все предположения об авторизации. Либо передайте контроль до подписания, либо сделайте замену оценённым и проверенным условием сделки.

Переносимость базы данных включает поведение и эксплуатацию

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

Начните с пустого экземпляра PostgreSQL под контролем заказчика на документированной основной версии. Примените миграции репозитория по порядку. Если в проекте нет миграций и требуется импортировать дамп схемы, созданный поставщиком, зафиксируйте это как дефект. Дамп может сохранить сегодняшнее состояние, но не объясняет, как безопасно меняется это состояние в следующем релизе.

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

Затем проверьте путь данных контролируемым циклом:

1. Создайте запись через публичный сценарий приложения.
2. Прочитайте её вторым авторизованным пользователем там, где предполагается общий доступ.
3. Убедитесь, что неавторизованный пользователь не может её прочитать или изменить.
4. Обновите и удалите её через приложение.
5. Восстановите базу в другом чистом экземпляре и повторите чтение.

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

Считайте объектное хранилище частью границы базы данных, если строки ссылаются на загруженные файлы. Экспортируйте бакеты, метаданные объектов, правила доступа, правила жизненного цикла и настройки генерации URL. Восстановленная база, полная ключей объектов, бесполезна, если сами файлы остались в бакете под контролем конструктора. То же предупреждение относится к поисковым индексам и векторным хранилищам: решите, переносить их или пересоздавать, и подтвердите процедуру пересоздания.

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

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

Отсутствие CI-конвейера означает отсутствие знания о продукте

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

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

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

Компактный журнал приёмки может выглядеть так:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

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

Не требуйте секретный механизм развёртывания продавца, если он вам не нужен. Требуйте достаточно инструкций и конфигурации, чтобы воспроизвести результат. Переносимый конвейер может работать в другом продукте CI, если выполняет те же обязательные этапы и не ослабляет контроль выпуска.

Мобильные приложения добавляют активы подписания, идентификаторы пакетов, аккаунты магазинов и учётные данные push-уведомлений. Их легко не заметить, потому что исходная сборка может работать в эмуляторе без них. Проверьте, что аккаунты распространения принадлежат заказчику, и задокументируйте ротацию сертификатов. Для серверных и веб-приложений включите в упражнение по выпуску проверку домена, выпуск TLS-сертификата, изменения DNS и сброс кэша.

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

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

Не допускайте секреты в журналы CI, одновременно подтверждая, что конвейер может получить их из хранилища под контролем заказчика. Тест должен создать краткоживущие учётные данные для тестовой среды, передать их документированным способом и сменить без редактирования исходного кода. Если секрет нужно вставлять в панель поставщика силами сотрудников поддержки, зафиксируйте эту зависимость, а не прячьте её в заметках по настройке.

Предположения о хостинге проявляются при развёртывании в чистой среде

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

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

Проверьте приложение на предположения о доступных для записи локальных дисках, фиксированных портах, закреплённых сессиях, заголовках доверенного прокси, названиях регионов, внедрённых именах хостов и специфичных для платформы переменных окружения. Методология Twelve-Factor App советует хранить конфигурацию в окружении и рассматривать вспомогательные сервисы как подключённые ресурсы. Эти идеи по-прежнему полезны, но одни переменные окружения не описывают владельцев, форматы и создание. Добавьте к каждой переменной операционную запись.

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

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

Наблюдайте завершение работы так же внимательно, как запуск. Отправьте сигнал завершения, пока активны запросы и фоновые задания. Процесс должен перестать принимать новую работу, завершить или безопасно вернуть взятые задания, закрыть соединения и завершиться в пределах льготного периода хоста. Управляемый конструктор мог скрывать резкие остановки длинными тайм-аутами или повторами, которых нет у нового хоста.

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

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

Koder.ai поддерживает экспорт исходного кода, развёртывание и хостинг, пользовательские домены, снимки и откат. Если вы оцениваете экспортированный проект Koder.ai на предмет независимой работы, применяйте тот же стандарт чистой среды: проверьте экспортированные компоненты React, Go с PostgreSQL или Flutter в среде, которой собираетесь владеть, и задокументируйте каждый сервис, который решите сохранить.

Внесите условия прохождения и провала в договор

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

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

Используйте критерии прохождения, которые может наблюдать третья сторона. Формулировка «нет критической проприетарной зависимости» приглашает к спору. Формулировка «тестовое приложение завершает сценарии от A до F, пока отозваны все учётные данные под контролем конструктора и заблокированы домены конструктора» проверяема. Назовите разрешённые зависимости и владельца аккаунта, чтобы команда не сочла утверждённый управляемый сервис ошибкой.

Потребуйте передать исходный код и операционные материалы на зафиксированной ревизии: lock-файлы, миграции, определения сборки, конфигурацию инфраструктуры при наличии, каталог переменных окружения, реестр зависимостей, экспорт данных, план переноса идентификации, инструкции по эксплуатации, уведомления о лицензиях и активы подписания или распространения, принадлежащие заказчику. Явно фиксируйте исключения. Молчание не должно означать согласие.

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

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

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

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

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

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

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