Как проявилась ошибка#
Для queued-заказа движок сохранял ссылку на внешний ID временного именованного пресета. После удаления пресета одного сохранённого opaque-значения в журнале мода было недостаточно, чтобы доказать восстановление настоящего заказа.
Заказ мог существовать, но это ещё не означало, что при выпуске получатся нужные модули, программы и боезапас.
Принятый путь X4FO#
В проверенном срезе используется самостоятельный нативный снимок комплектации существующего временного объекта. Перед допуском покупки сверяется содержимое, затем в заказ попадает значение, которое сериализуется inline.
Временный объект создаётся и удаляется специальным инструментальным путём. Этот способ нельзя выдавать за универсальный бесплатный getter или переносить в обычную игровую логику без контроля побочных эффектов.
Почему нужны две границы#
| Состояние | Что важно доказать |
|---|---|
| queued | План оснащения сохранён ещё до подачи ресурсов |
| active | Уже начатое строительство продолжается после загрузки |
| complete | Существующий корабль совпадает с заказанной комплектацией |
В принятом пакете 0.53 проверены две комплектации одного корпуса Elite: Low и Medium. После queued и active cold load оба настоящих заказа завершились с точным оснащением, шестью программными слотами, боезапасом, пилотами и личным владельцем.
Чего эта проверка не доказывает#
Она не закрывает все типы корпусов, четыре смешанные строки, двадцать физических выпусков или платный refit. Предел очереди 32 проверялся отдельным сценарием заказов и возвратов.
Ключевой приём: сравнивать реальный корабль с исходным планом, а не только два одинаковых поля сетевого журнала.