DongHyeonkaandClaude Opus 5
ef947e5bb0
외부 리뷰("현재 상태를 유지하기 위한 검증이 너무 많고, 그 검증 자체를
다시 검증하는 구조까지 생겼다")를 설계 문서로 정리하고 코드로 반영한다.
설계·판단 근거는 docs/superpowers/specs/2026-09-16-verification-surface-reduction-design.md.
삭제
- .github/ci-gate-matrix.yml(1,025줄) + verify-gate-matrix.sh(568줄):
Gradle task graph와 workflow graph에 이미 있는 정보의 3중 복제
- verify-gradle-wrapper.sh(799줄): workflow 바이트 해시 잠금.
wrapper 검증은 gradle/actions/wrapper-validation(full SHA 핀)에 위임
- DeveloperExperienceContractTest 등의 CI YAML mutation 테스트:
애플리케이션 test suite가 GitHub Actions YAML 파서를 검증하던 계층 역전
- 문서 drift 파서: verifyReadmeCommands, verifyRunbookReferences,
verifyDocumentedLeafCount, verifyTestSourceSetRegistry
- 빈 레지스트리를 지키던 커스텀 YAML 파서: verifyTrivyignore,
verifyQuarantineSunset, flaky-quarantine.yaml
- verifyConfigurationPropertiesProcessor, verifyOneTypePerFile:
각각 ca.spring-config convention과 Checkstyle OneTopLevelClass가 대체
- 정상 입력으로도 성공할 수 없던 messaging always-fail task
- ModuleRegistry의 JSON 필드 집합 정확 일치, sample-portfolio negative guard
이동
- java/quality/spring 공통 설정을 configure(subprojects) 블록에서
ca.java-conventions / ca.quality-conventions / ca.java-library /
ca.spring-library convention plugin으로
- 아키텍처 검증을 ca.architecture로, JPA·messaging qualification을
gradle/qualification/ 아래로, verifyEnvKeys를 :app-bootstrap 소유로
완화
- Git revision은 releaseCheck·아카이브 생성에서만 요구. 일반 빌드는 SNAPSHOT
- SpotBugs/FindSecBugs는 로컬 check에서 빼고 qualityCheck 레인으로
task 계층
- leaf check는 그 leaf만. architectureCheck / qualityCheck /
configContractCheck / integrationCheck / ci / releaseCheck로 이름 분리
CI
- _reusable-gradle.yml 신규. checkout + wrapper validation + JDK/캐시 공통화
- fileserver-release.yml -> fileserver-certification.yml (CD가 아니라 certification)
- GitHub Actions = CI + artifact, Argo CD = CD 경계를 docs/ci-cd/boundary.md로 고정
순증감 +3,274 / -7,483.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs
저장소의 모든 문서는 이 디렉터리 아래에 있다. 어떤 문서를 어디에 두는지가 유일한 규칙이고, 파일 목록은 디렉터리를 직접 읽는다. 개수를 여기에 적으면 다음 문서가 추가되는 순간 틀린 글이 된다.
어댑터별 운영 문서
각 어댑터의 지원 범위, 설정, 보안, 운영, 마이그레이션 문서다. 코드와 함께 갱신되어야 하는 문서이고,
docs/httpclient/ 는 scripts/verify-httpclient-docs.py 가 코드에서 뽑은 이름과 대조한다.
| 디렉터리 | 대상 |
|---|---|
fileserver/ |
파일 서버 어댑터 |
httpclient/ |
HTTP 클라이언트 플랫폼 |
jpa/ |
JPA·PostgreSQL 영속성 |
messaging/ |
메시징 어댑터 |
mongodb/ |
MongoDB 문서 영속성 (advanced/, runbooks/ 포함) |
notification/ |
알림 전달 플랫폼 (adr/ 포함) |
redis/ |
Redis 캐시·세션 |
횡단 문서
| 디렉터리 | 대상 |
|---|---|
adr/ |
아키텍처 결정 기록 |
architecture/ |
공개 API 표면 스냅숏 |
evidence/ |
작업 단계별 증거·체크포인트 |
registries/ |
env 키·에러 코드·메트릭·헤더 등 레지스트리 SSOT |
reviews/ |
모듈 코드 리뷰 결과 |
runbooks/ |
장애 코드별 대응 런북 (template.md 기준) |
security/ |
공개 경로 스냅숏 |
설계와 계획
| 디렉터리 | 대상 |
|---|---|
superpowers/specs/ |
설계서. YYYY-MM-DD-<주제>-design.md |
superpowers/plans/ |
구현·확장 계획서. YYYY-MM-DD-<주제>-plan.md |
superpowers/packages/ |
외부에서 납품된 설계 패키지의 README와 정적 검증 결과 |
superpowers/packages/<어댑터>/ 는 설계서가 처음 전달됐을 때의 안내와 VALIDATION.md 검증 이력을
남긴 기록 보관소다. 설계서·계획서 본문은 전부 specs/ 와 plans/ 에 있으므로 이 디렉터리에서
문서를 찾을 필요는 없다. 각 README 상단의 보존 안내가 무엇이 옮겨졌고 무엇이 제거됐는지 밝힌다.
계획서 본문에는 당시 계획한 경로와 명령이 그대로 남아 있다. 그중 일부는 실제 구현에서 다른 위치로
조정됐고, 저장소에 어떻게 대응시켰는지는 각 어댑터의 repository-adaptation.md 또는
module-mapping.md 가 기록한다. 계획서를 사후에 고치지 않는 이유는 그렇게 하면 계획의 기록이 아니라
결과를 계획처럼 보이게 만든 글이 되기 때문이다.
여기에 없는 것
- 실행되는 검증 스크립트는 문서가 아니다.
scripts/와.github/scripts/에 있다. - 모듈 레지스트리·Gradle 정책은
src/config/architecture/modules.json과src/build.gradle이 소유한다. - 각 모듈의 지역 규칙은 해당 모듈의
src/**/CLAUDE.md가 소유한다.