При переносе старого DLE 13.2 на актуальную версию и переписывании собственных модулей, Codex использовать вполне разумно. Но модуль оплаты — как раз тот случай, где нельзя ограничиваться схемой «Codex написал → залил на сайт». Основные риски здесь не столько в том, что ИИ напишет синтаксически плохой PHP. Код может выглядеть отлично и нормально работать, но иметь ошибку именно в бизнес-логике оплаты.
Например, могут быть критичны ситуации:
- пользователь может подменить сумму заказа;
- статус paid устанавливается после возврата пользователя с платёжной страницы, а не после проверенного серверного callback/webhook;
- подпись webhook проверяется неправильно;
- один callback можно отправить несколько раз и несколько раз начислить баланс;
- order_id можно подменить;
- сумма и валюта из callback не сверяются с созданным заказом в вашей БД;
- секретный ключ оказывается в PHP-файле, Git или логах;
- Codex может использовать устаревшую версию API платёжной системы и т.д.
Как бы я делал обновление старого DLE.
Я бы вообще не начинал с переписывания модулей. Сначала сделал полную копию старого сайта:
DLE 13.2 + БД + uploads + шаблоны + все собственные PHP-файлы.
Затем положил исходный чистый DLE 13.2 рядом с вашей рабочей версией и поручил Codex провести сравнение:
Найди все отличия этой установки от оригинального DLE 13.2.
Не изменяй файлы.
Раздели изменения на:
1. модификации ядра DLE;
2. сторонние модули;
3. изменения шаблона;
4. изменения БД;
5. неизвестные изменения.
Для каждого изменения запросил бы объяснение его предполагаемого назначения. Вот здесь Codex может быть особенно полезен. Он способен исследовать незнакомый код, прослеживать связи между компонентами и объяснить существующую архитектуру. Это как раз один из сценариев, для которых его как раз таки и стоит использовать.
Ну а далее уже "копал" в сторону обновления самого движка и написания модуля оплаты и т.д.
