Загрузка данных
Работаем в существующем репозитории:
snl-integration-audit
Ветка для анализа:
develop
Контекст задачи:
Есть дефект SNL-1128, связанный с архитектурным контролем в META.
Целевой API:
- META API ID: 399066
- текущее название: СУДИР SCIM API
- требуемое название: СНЛ.Интеграции.СУДИР
- формат: OpenAPI 3.0.1
- версия API: 4.6.3
- имя выгружаемого файла: СНЛ.Интеграции.СУДИР.json
Из отчёта архитектурного контроля известны нарушения:
1. API-REST-3-5:
отсутствуют обязательные description и/или summary.
2. API-REST-8-4:
у массива отсутствует maxItems.
Уже найден конкретный объект:
- API: СУДИР SCIM API
- schema: UserPPRBScimResponse
- property: schemas
3. API-REST-9-4:
у числовых значений отсутствует допустимый диапазон и/или format.
OpenAPI JSON генерируется из Java/Spring-кода. Редактировать итоговый JSON вручную как основное исправление нельзя. Нужно найти первопричину генерации ошибок.
Сейчас выполни только анализ проекта.
СТРОГИЙ РЕЖИМ ТОЛЬКО ДЛЯ ЧТЕНИЯ.
Запрещено:
- изменять любые файлы;
- создавать новые файлы;
- удалять файлы;
- переименовывать файлы;
- применять quick fix;
- выполнять автоформатирование;
- выполнять git add;
- выполнять git commit;
- выполнять git push;
- создавать или переключать ветки;
- обновлять зависимости;
- запускать команды, которые могут перезаписать сгенерированные файлы;
- генерировать OpenAPI с записью на диск;
- исправлять код;
- предлагать создание нового Spring Boot приложения.
Нужно проанализировать именно существующий проект.
1. Определи структуру проекта
Покажи основные директории:
- src/main/java
- src/main/resources
- src/test/java
- .github
- .gitlab-ci.yml
- Jenkinsfile
- .gigacode
- pom.xml
- Dockerfile
- Helm/openshift/deployment-конфигурации
- скрипты сборки и запуска
Укажи:
- главный класс Spring Boot;
- контроллеры;
- DTO;
- конфигурационные классы;
- application.yml/application.yaml/application.properties;
- профили конфигурации;
- корпоративные стартеры.
2. Проанализируй pom.xml
Уже известно:
- Spring Boot 3.5.7
- Java 17
- artifactId: snl-integration-audit
- присутствуют зависимости:
- ru.sbt.pvm:ufs-platform-audit-starter
- ru.sbt.pvm:audit-client-core2
Прямых зависимостей springdoc/swagger/openapi/springfox в просмотренной части pom.xml не найдено.
Нужно определить:
- есть ли OpenAPI-зависимости напрямую;
- могут ли они приходить транзитивно;
- через какой корпоративный starter они могут подключаться;
- есть ли Maven-плагины генерации OpenAPI;
- есть ли профили Maven;
- есть ли dependencyManagement в родительском pom;
- влияет ли корпоративный starter на Swagger/OpenAPI.
Не запускай команды, которые изменяют файлы.
Разрешены только команды чтения, например:
- mvn dependency:tree
- mvn help:effective-pom
- grep
- find
- git status
- git log
- git branch --show-current
Если Maven-команда может скачать зависимости или изменить локальное состояние, сначала не запускай её, а укажи, что она могла бы показать.
3. Найди механизм формирования OpenAPI
Выполни поиск по всему репозиторию по строкам:
- springdoc
- swagger
- openapi
- OpenAPI
- springfox
- api-docs
- /v3/api-docs
- swagger-ui
- io.swagger
- io.swagger.v3
- @OpenAPIDefinition
- @Info
- @Operation
- @Parameter
- @ApiResponse
- @Schema
- @ArraySchema
- GroupedOpenApi
- OpenApiCustomizer
- OperationCustomizer
- ModelConverter
- Docket
- SwaggerConfig
- OpenApiConfig
- springdoc.api-docs
- springdoc.swagger-ui
- apiDocs
- generate
- export
- META
- meta.sberbank
- metahub
Для каждого совпадения укажи:
- полный путь к файлу;
- номер строки;
- фрагмент кода;
- роль этого фрагмента в генерации спецификации.
4. Найди REST-контроллеры
Найди все классы с аннотациями:
- @RestController
- @Controller
- @RequestMapping
- @GetMapping
- @PostMapping
- @PutMapping
- @PatchMapping
- @DeleteMapping
Составь таблицу:
класс
→ базовый path
→ методы
→ request DTO
→ response DTO
→ OpenAPI-аннотации
→ источник summary
→ источник description.
Отдельно проверь, есть ли в этом проекте контроллеры, относящиеся к:
- /scim/v2/Users
- /scim/v2/SberRoles
- /scim/v2/SberFosNodes
- /scim/v2/ServiceProviderConfig
- UserPPRBScimEndpoint
- RoleSudirPPRBScimEndpoint
- FosScimEndpoint
- ServiceProviderConfigScimEndpoint
Если таких классов нет, явно укажи, что API СУДИР не реализован в данном репозитории.
5. Найди классы из OpenAPI-спецификации
Выполни поиск по следующим именам:
- UserPPRBScimResponse
- UserPPRBListScimResponse
- ErrorScimResponse
- CreateUserPPRBScimRequest
- UpdateUserPPRBScimRequest
- PatchUserPPRBScimRequest
- RoleSudirPPRBListScimResponse
- FosScimListResponse
- ScimServiceProviderConfigResponse
- SudirUser
- Email
- EnterpriseUser
- FunctionalBlock
- PhoneNumber
- Unit
Для каждого результата укажи:
- полный путь;
- Java-тип;
- поля;
- аннотации;
- где используется;
- генерируется ли из него OpenAPI schema.
Если ни одного класса не найдено, зафиксируй, что спецификация СУДИР формируется не из исходников этого репозитория.
6. Исследуй источник названия API
Найди источник значений:
- СУДИР SCIM API
- СНЛ.Интеграции.СУДИР
- API управления доступом через СУДИР на основе SCIM V2
- 4.6.3
- СНЛ.Интеграции.СУДИР.json
Проверь:
- Java-аннотации;
- application.yml;
- properties;
- environment variables;
- Maven properties;
- Docker/Helm-конфигурацию;
- CI/CD;
- markdown-документацию;
- ресурсы;
- JSON/YAML-файлы.
Для каждого значения укажи точный источник.
7. Проанализируй нарушение API-REST-8-4
Известный объект:
- schema: UserPPRBScimResponse
- property: schemas
- type: array
- отсутствует maxItems
Найди Java-источник этого поля.
Проверь наличие:
- List
- Set
- Collection
- массивов
- @Size
- @ArraySchema
- @Schema
- Bean Validation
- jakarta.validation
- javax.validation
Определи:
- Java-класс;
- поле;
- тип поля;
- почему springdoc или другой генератор не добавил maxItems;
- можно ли получить maxItems из @Size(max = ...);
- есть ли бизнес-ограничение в коде, тестах или документации.
Не придумывай значение maxItems.
8. Проанализируй нарушение API-REST-9-4
Найди все числовые поля и параметры:
- byte
- short
- int
- long
- float
- double
- Integer
- Long
- BigDecimal
- BigInteger
- Number
Для каждого проверь:
- format;
- minimum;
- maximum;
- exclusiveMinimum;
- exclusiveMaximum;
- @Min;
- @Max;
- @DecimalMin;
- @DecimalMax;
- @Positive;
- @PositiveOrZero;
- @Negative;
- @Digits;
- @Schema(format = ...);
- @Schema(minimum = ...);
- @Schema(maximum = ...).
Особенно проверь параметры:
- startIndex
- count
Определи:
- какие числовые поля проходят проверку за счёт format;
- какие нарушают правило;
- точный Java-источник;
- почему генератор не добавил format или диапазон.
9. Проанализируй нарушение API-REST-3-5
Проверь наличие description и summary для:
- info;
- tags;
- operations;
- parameters;
- requestBody;
- responses;
- schemas;
- properties.
Найди Java-источники:
- @OpenAPIDefinition
- @Info
- @Tag
- @Operation
- @Parameter
- @RequestBody
- @ApiResponse
- @Schema
Составь список всех мест, где описание отсутствует.
Важно:
Не считать автоматически, что отсутствие аннотации является ошибкой. Сначала установить, действительно ли данный Java-элемент попадает в целевую спецификацию.
10. Проверь корпоративные стартеры
Проанализируй использование:
- ufs-platform-audit-starter
- audit-client-core2
Определи:
- какие автоконфигурации они подключают;
- могут ли они создавать REST-контроллеры;
- могут ли они подключать springdoc транзитивно;
- могут ли они генерировать OpenAPI;
- есть ли в коде импорт классов из этих стартеров;
- можно ли увидеть их конфигурацию через IDE External Libraries или effective-pom.
Не придумывай содержимое закрытых библиотек. Если исходный код недоступен, так и напиши.
11. Проверь CI/CD
Найди:
- Jenkinsfile;
- GitLab CI;
- pipeline yaml;
- Dockerfile;
- Helm values;
- Kubernetes manifests;
- shell-скрипты;
- команды запуска Spring Boot;
- обращения к /v3/api-docs;
- curl с сохранением JSON;
- загрузку файла в META;
- упоминания API ID 399066.
Определи полную возможную цепочку:
Java-код
→ запуск приложения
→ endpoint OpenAPI
→ сохранение JSON
→ загрузка в META.
Если цепочка не найдена, явно это зафиксируй.
12. Проверь историю Git
Только чтение.
Найди коммиты, связанные с:
- OpenAPI;
- Swagger;
- META;
- API;
- SNL-1128;
- SNL-964;
- генерацией документации;
- архитектурным контролем.
Укажи:
- commit hash;
- сообщение;
- изменённые связанные файлы.
Ничего не переключай и не изменяй.
13. Сделай итоговый вывод
Ответ должен содержать:
1. Является ли `snl-integration-audit` источником API СУДИР.
2. Найдены ли в нём SCIM-контроллеры и DTO.
3. Найден ли механизм генерации OpenAPI.
4. Используется ли springdoc напрямую или транзитивно.
5. Какой endpoint может отдавать OpenAPI.
6. Где задаются info.title, description и version.
7. Найден ли Java-источник UserPPRBScimResponse.schemas.
8. Найдены ли источники ошибок API-REST-3-5, API-REST-8-4 и API-REST-9-4.
9. Какие выводы подтверждены кодом.
10. Какие выводы пока являются предположениями.
11. Какой репозиторий или модуль нужно открыть дальше, если данный проект не является источником СУДИР.
12. Какие команды можно использовать для проверки, но пока не запускать.
13. Подтверждение: ни один файл не был изменён.
Формат таблицы для найденных нарушений:
Правило
→ путь в OpenAPI
→ Java-источник
→ текущие аннотации
→ причина генерации
→ потенциальный способ исправления
→ степень уверенности.
Не вноси изменения.
После завершения анализа остановись.