# 검증 및 체크리스트

## 기본 검증

- 변경 범위와 직접 관련된 모듈만 수정했는지 확인합니다.
- core 변경은 `:01-api-core:compileJava`를, 실행 모듈 변경은 `:02-api-admin:compileJava`, `:03-api-front:compileJava`를 최소 검증으로 사용합니다.
- 실행 설정이나 빈 구성이 바뀌면 admin/front를 각각 기동하거나 관련 테스트를 실행합니다.
- 검증하지 못한 항목은 사유를 명확히 남깁니다.

## 모듈 완료 검증

- 구현 중에는 관련 모듈의 `compileJava`와 필요한 단위 테스트를 수시 실행합니다.
- 모듈 작업을 완료하면 Core와 해당 실행 모듈의 `build`를 실행합니다.
- 통합 테스트는 Spring, MyBatis, Security, DB 등 해당 기능의 연결 범위를 검증합니다.
- 실제 연동 검증은 `API -> DB -> 조회 API`를 기본으로 합니다.
- Redis, 파일, 외부 API, 메시지 등은 해당 기능이 실제로 사용할 때만 추가 검증합니다.
- 실제 개발 데이터를 변경한 테스트는 테스트 데이터를 삭제하거나 원복합니다.

## 업무 이관

- Java Mapper, Mapper XML, namespace, id, DTO 패키지 참조를 함께 변경합니다.
- 범용 처리는 `standard`, 업무 전용 처리는 `bespoke` 기준으로 배치했는지 확인합니다.
- core에 Form, 화면 전용 VO, Controller가 들어가지 않았는지 확인합니다.
- admin/front에 다른 서버 전용 Controller가 포함되지 않았는지 확인합니다.
- Controller가 core DTO/VO, core Service 또는 Mapper를 직접 참조하지 않는지 확인합니다.
- admin/front Service가 core standard/bespoke 호출 조합과 트랜잭션 경계를 소유하는지 확인합니다.
- bespoke Service/Mapper/XML id가 기준 테이블과 기능명, 결과 형태 규칙을 같은 이름으로 사용하는지 확인합니다.

## 보안

- admin은 `ADMIN` scope와 `adminAccessToken`으로 인증되는지 확인합니다.
- front는 `USER` scope와 `accessToken`으로 인증되는지 확인합니다.
- 공개 경로와 역할 정책은 각 서버 `SecurityConfig`에서 확인합니다.
- Swagger Basic 인증과 API JWT 인증이 각각 의도대로 동작하는지 확인합니다.

## 설정과 리소스

- admin/front의 `application*.yaml`, 로그 설정, banner, robots 리소스가 각 모듈에 있는지 확인합니다.
- core Mapper XML이 두 bootJar에서 모두 classpath로 읽히는지 확인합니다.
- `MainDataSourceConfig`가 `mapper/standard`, `mapper/bespoke`의 이관된 XML만 읽는지 확인합니다.
- migration DataSource를 사용하지 않는 환경에서는 `migration.datasource.*.enabled`가 활성화되지 않았는지 확인합니다.
- 파일 또는 TUS를 변경하면 저장 경로, nginx, tusd, SecurityConfig를 함께 확인합니다.

## 빌드 산출물

- `:02-api-admin:bootJar` 결과가 `api-admin.jar`인지 확인합니다.
- `:03-api-front:bootJar` 결과가 `api-front.jar`인지 확인합니다.
- admin JAR에 front Controller가, front JAR에 admin Controller가 포함되지 않는지 확인합니다.