---

Работаем в существующем репозитории snl-integration-audit.

Цель: полностью проверить текущие изменения по задаче SNL-1128 в офисной среде, где должны быть доступны корпоративные Maven-репозитории и зависимости. Нужно не только проанализировать код, а реально выполнить сборку, тесты, запуск приложения и проверить фактически сгенерированную OpenAPI-спецификацию.

ВАЖНЫЕ ОГРАНИЧЕНИЯ:

1. Работай только в репозитории snl-integration-audit.
2. Текущая рабочая ветка должна быть feature/SNL-1128.
3. Не переключай ветку.
4. Не выполняй commit, push, merge, rebase, reset, stash.
5. Не меняй бизнес-логику приложения.
6. Не меняй runtime-сигнатуру метода ConsumeEventController.logEvent:
   - @RequestBody String message;
   - @RequestHeader("Service-Name") String serviceName;
   - @RequestHeader("Event-Name") String eventName;
   - вызов consumeEventService.consume(message, serviceName, eventName).
7. api-docs-2.yaml — только справочный пример Сергея. Не добавляй его в Git и не копируй из него спецификацию вручную.
8. OpenAPI должен генерироваться из Java-кода через springdoc.
9. Не создавай AuditEventSchema, AuditParamSchema или другие искусственные DTO только ради документации, если из-за них возникает массив params без доказуемого maxItems.
10. Не добавляй maxItems, minimum, maximum или format без подтверждения кодом или бизнес-ограничением.
11. Не документируй ответы 400 и 500, если текущий код и обработчики исключений не гарантируют именно эти HTTP-статусы.
12. Если проблема вызвана корпоративным Maven settings.xml, сертификатами, сетью или отсутствующим артефактом, не маскируй её изменениями pom.xml. Покажи точную причину.

Сначала выполни строгую диагностику текущего состояния.

ЭТАП 1. ПРОВЕРКА РЕПОЗИТОРИЯ

Выполни:

git branch --show-current
git status --short
git diff --stat
git diff
git ls-files api-docs-2.yaml
git check-ignore -v api-docs-2.yaml || true

Подтверди:

- текущая ветка feature/SNL-1128;
- какие файлы изменены;
- какие файлы созданы;
- api-docs-2.yaml не отслеживается Git;
- AuditEventSchema.java и AuditParamSchema.java отсутствуют;
- runtime-сигнатура ConsumeEventController не изменена.

Если текущая ветка не feature/SNL-1128 — остановись и ничего не меняй.

ЭТАП 2. ПРОВЕРКА JAVA И MAVEN

Выполни:

java -version
mvn -version

Затем найди Maven settings:

ls -la ~/.m2 || true
test -f ~/.m2/settings.xml && echo "SETTINGS_FOUND" || echo "SETTINGS_NOT_FOUND"

Не показывай пароли, токены и содержимое секций servers из settings.xml.

ЭТАП 3. ЗАГРУЗКА И АНАЛИЗ ЗАВИСИМОСТЕЙ

Выполни:

mvn -U -DskipTests dependency:resolve
mvn help:effective-pom -Doutput=target/effective-pom.xml
mvn dependency:tree -Dincludes=org.springdoc
mvn dependency:tree -Dincludes=io.swagger.core.v3
mvn dependency:tree -Dincludes=ru.sbt.pvm

Определи:

1. Какая версия springdoc реально подключена.
2. Через какую прямую или транзитивную зависимость она приходит.
3. Присутствуют ли:
   - ufs-platform-audit-starter:6.0.8.3;
   - audit-client-core2:6.3.0.2;
   - pvm-sdk-transport-db:6.0.8.3;
   - pvm-sdk-pull-processing-db:6.0.8.3.
4. Нет ли конфликтов версий springdoc или swagger annotations.
5. Является ли свойство springdoc.version в pom.xml реально используемым или «мёртвым».

Если dependency:resolve или dependency:tree завершается ошибкой, зафиксируй:

- точную Maven-команду;
- полный текст основной ошибки;
- groupId, artifactId и version недоступного артефакта;
- URL репозитория, если Maven его показывает;
- используется ли ~/.m2/settings.xml;
- относится ли проблема к сети, сертификату, авторизации или отсутствию артефакта.

После этого не вноси случайные зависимости в pom.xml.

ЭТАП 4. КОМПИЛЯЦИЯ

Выполни:

mvn -U -DskipTests clean compile

Если компиляция не проходит:

1. Определи, ошибка относится к:
   - текущим изменениям;
   - отсутствующим корпоративным зависимостям;
   - неверным import;
   - несовместимой версии swagger/springdoc;
   - Checkstyle;
   - Java-версии.
2. Если это ошибка именно текущего Java-кода — исправь минимально.
3. Не меняй бизнес-логику.
4. После исправления повтори clean compile.

ЭТАП 5. ПРОВЕРКА ТЕСТА OPENAPI

Сначала прочитай фактическое содержимое OpenApiGenerationTest.java.

Проверь, что тест действительно обращается к работающему endpoint springdoc и проверяет фактический ответ приложения, а не искусственно созданную строку.

Затем выполни:

mvn -U -Dtest=OpenApiGenerationTest test

Если тест ошибочен или не компилируется, исправь его минимально так, чтобы он проверял фактически сгенерированную спецификацию.

Тест должен проверять как минимум:

1. endpoint OpenAPI возвращает успешный ответ;
2. openapi = 3.0.1 либо совместимая версия, реально выдаваемая springdoc;
3. info.title = "СНЛ.Интеграции.Аудит";
4. info.description непустой;
5. info.version = "1.0.0";
6. существует POST /api/v1/audit/event;
7. operation.summary непустой;
8. operation.description непустой;
9. параметр Service-Name:
   - in = header;
   - required = true;
   - type = string;
   - description непустой;
10. параметр Event-Name:
    - in = header;
    - required = true;
    - type = string;
    - description непустой;
11. requestBody:
    - required = true;
    - description непустой;
    - application/json присутствует;
    - schema.type = string;
12. ответ 200 имеет непустое description;
13. в components отсутствуют AuditEventSchema и AuditParamSchema;
14. генерация не создаёт массив params без maxItems.

Не требуй наличия ответов 400 и 500, если они не гарантированы реальным кодом.

ЭТАП 6. ВСЕ ТЕСТЫ

Выполни:

mvn -U test

Если тесты падают:

- перечисли каждый упавший тест;
- укажи первопричину;
- исправляй только ошибки, непосредственно вызванные текущими изменениями;
- существующие посторонние падения не маскируй.

После исправления текущих ошибок повтори mvn test.

ЭТАП 7. ФАКТИЧЕСКИЙ ЗАПУСК И ГЕНЕРАЦИЯ OPENAPI

Запусти приложение доступным для проекта способом. Предпочтительно:

mvn spring-boot:run

Если проект требует профиль или переменные окружения, сначала изучи application.yaml и существующую конфигурацию. Не придумывай секреты и значения.

После успешного запуска проверь последовательно:

curl -f http://localhost:8088/v3/api-docs -o /tmp/snl-audit-api-docs.json

curl -f http://localhost:8088/v3/api-docs.yaml -o /tmp/snl-audit-api-docs.yaml

Если порт отличается, возьми фактический порт из конфигурации или логов.

Не используй api-docs-2.yaml как результат проверки. Проверяй только файлы, полученные с реально запущенного приложения.

ЭТАП 8. ПРОВЕРКА ФАКТИЧЕСКОЙ СПЕЦИФИКАЦИИ

Проанализируй /tmp/snl-audit-api-docs.json или /tmp/snl-audit-api-docs.yaml.

Проверь требования архитектурного контроля:

API-REST-3-5:

- info.title указан;
- info.description указан;
- info.version указан и равен 1.0.0;
- POST /api/v1/audit/event имеет summary;
- POST /api/v1/audit/event имеет description;
- Service-Name имеет description;
- Event-Name имеет description;
- requestBody имеет description;
- response 200 имеет description;
- используемые схемы и их поля имеют description, если схемы присутствуют.

API-REST-8-4:

- каждый массив обязан иметь maxItems;
- в нашей спецификации не должно появиться искусственного массива params без maxItems;
- если массивы всё же есть, перечисли точный JSON Path каждого массива и его maxItems;
- не добавляй фиктивное maxItems без бизнес-обоснования.

API-REST-9-4:

- для integer/number должно быть указано format либо допустимый диапазон;
- перечисли все integer/number-поля спецификации;
- укажи их JSON Path, type, format, minimum и maximum;
- если таких полей нет в документируемом endpoint, так и укажи.

Сравни фактически сгенерированный результат с api-docs-2.yaml только концептуально:

- структура endpoint;
- title, description, version;
- описания заголовков;
- описание тела;
- описание ответа;
- тип тела String.

Не копируй event-specific examples и список params из api-docs-2.yaml, потому что это только пример и состав params зависит от Event-Name.

ЭТАП 9. ПРОВЕРКА, ЧТО БИЗНЕС-ЛОГИКА НЕ ИЗМЕНИЛАСЬ

Сравни ConsumeEventController до и после изменений.

Подтверди отдельно:

- URL endpoint не изменился;
- HTTP-метод не изменился;
- названия заголовков не изменились;
- обязательность заголовков не изменилась;
- тело запроса осталось String;
- порядок аргументов consumeEventService.consume не изменился;
- возвращаемый тип не изменился;
- изменения состоят только из OpenAPI-аннотаций и документации.

ЭТАП 10. ФИНАЛЬНЫЙ GIT-КОНТРОЛЬ

Выполни:

git status --short
git diff --check
git diff --stat
git diff
git ls-files api-docs-2.yaml
git check-ignore -v api-docs-2.yaml || true

Не выполняй commit и push.

ФИНАЛЬНЫЙ ОТЧЁТ

Выдай отчёт со следующими разделами:

1. Ветка и git status.
2. Версии Java и Maven.
3. Использованный Maven settings.xml.
4. Результат загрузки корпоративных зависимостей.
5. Реальная цепочка зависимости springdoc.
6. Результат clean compile.
7. Результат OpenApiGenerationTest.
8. Результат всех тестов.
9. Результат запуска приложения.
10. URL фактического OpenAPI endpoint.
11. Таблица проверки:
    - API-REST-3-5;
    - API-REST-8-4;
    - API-REST-9-4.
12. Все внесённые изменения по файлам.
13. Подтверждение неизменности runtime-поведения.
14. Оставшиеся проблемы и точные причины.
15. Итоговый вердикт:
    - ГОТОВО;
    - ГОТОВО, НО НУЖНА ПРОВЕРКА В CI;
    - НЕ ГОТОВО.

Обязательно разделяй:

- что реально подтверждено выполненной командой;
- что установлено чтением кода;
- что остаётся предположением.

Не заявляй, что сборка, тесты или OpenAPI прошли, если соответствующая команда фактически не была успешно выполнена.