refactor(build,ci): 현재 상태 검증을 걷어내고 불변조건만 남기는 검증 표면 축소

외부 리뷰("현재 상태를 유지하기 위한 검증이 너무 많고, 그 검증 자체를
다시 검증하는 구조까지 생겼다")를 설계 문서로 정리하고 코드로 반영한다.
설계·판단 근거는 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/ci-cd/boundary.md

@@ -0,0 +1,73 @@
+# CI/CD 경계 — GitHub Actions는 CI, Argo CD는 CD
+
+## 결론
+
+GitHub Actions는 **검증하고 아티팩트를 만든다**. Argo CD는 **배포한다**. 두 역할은 겹치지 않는다.
+
+GitHub Actions 워크플로는 `kubectl apply`, `helm upgrade`, `argocd app sync` 중 어느 것도 하지
+않는다. 그러므로 CI에는 클러스터 자격증명(kubeconfig, 서비스 계정 토큰)이 들어가지 않는다.
+
+## 흐름
+
+```text
+   git push / tag
+        │
+        ▼
+  GitHub Actions  ─────────────── CI ───────────────┐
+   • 테스트 · 정적분석 · 아키텍처 검증               │
+   • 컨테이너 이미지 빌드                            │
+   • 취약점 스캔 (Trivy)                             │
+   • SBOM 생성                                       │
+   • 레지스트리에 이미지 push                        │
+        │                                            │
+        │ 이미지 태그(다이제스트)를 manifest에 기록  │
+        ▼                                            │
+  GitOps 저장소 (배포 희망 상태)  ──────────────────┘
+        │
+        │ Argo CD가 watch
+        ▼
+     Argo CD  ──────────────────── CD ───────────────
+        │ auto-sync
+        ▼
+   Kubernetes
+```
+
+용어 한 줄 풀이:
+
+- **GitOps 저장소** — 클러스터에 무엇이 떠 있어야 하는지를 적어 둔 Git 저장소. 애플리케이션 소스와
+  분리한다.
+- **manifest** — Kubernetes에 넣을 YAML(Deployment, Service 등).
+- **auto-sync** — Argo CD가 GitOps 저장소의 변경을 스스로 감지해 클러스터에 반영하는 모드. 이걸 쓰면
+  CI가 Argo CD API 서버에 접근할 필요가 없다.
+
+## 왜 이렇게 나누나
+
+1. **자격증명 반경.** CI가 배포하면 CI 러너가 프로덕션 클러스터에 대한 쓰기 권한을 갖는다. 포크된
+   PR, 서드파티 액션, 캐시 오염이 모두 그 권한에 닿는다. auto-sync를 쓰면 그 권한은 클러스터 안의
+   Argo CD에만 있고, CI는 Git에 커밋만 한다.
+2. **현재 상태의 소유자가 하나.** 클러스터에 무엇이 떠 있는지는 GitOps 저장소가 답한다. CI가 직접
+   apply 하면 답이 두 개가 된다 — Git에 적힌 것과 실제로 떠 있는 것.
+3. **롤백이 revert.** 배포를 되돌리는 것이 `git revert`가 된다.
+
+## 이 저장소의 현재 위치
+
+| 항목 | 상태 |
+| --- | --- |
+| 이미지 빌드/스캔/push | `release.yml`이 수행 |
+| SBOM | `release.yml`이 생성 |
+| 이미지 서명 · provenance attestation | **없음.** 추가 대상 |
+| GitOps 저장소 | **없음.** 별도 저장소로 만들 예정 |
+| Argo CD Application 정의 | **없음.** GitOps 저장소에 둘 예정 |
+| CI에서의 클러스터 접근 | 없음 — 유일했던 `kubectl apply`는 제거됨 |
+
+`fileserver-certification.yml`은 예외처럼 보이지만 아니다. PVC 매니페스트가 여전히 ReadWriteOnce를
+선언하는지 **파일만** 확인하고, 클러스터에는 아무것도 적용하지 않는다. 실제 클러스터에서의 인증은
+운영자가 `infra/fileserver/kubernetes/pvc-certification-job.yaml`을 직접 실행하고
+`docs/fileserver/storage-certification.md`에 기록한다. 이름을 `fileserver-release.yml`에서 바꾼 이유가
+이것이다 — 이 워크플로는 릴리스하지 않는다.
+
+## 규칙
+
+- 워크플로에 클러스터 자격증명 secret을 추가하지 않는다.
+- 배포 대상이 바뀌면 GitOps 저장소의 manifest를 바꾼다. 워크플로를 바꾸지 않는다.
+- CI가 만드는 것은 **불변 다이제스트로 지정된 이미지**다. `latest` 태그로 배포하지 않는다.

docs/ci-cd/template-vs-consumer.md

@@ -0,0 +1,50 @@
+# Template maintainer와 Template consumer의 검증은 다르다
+
+## 결론
+
+이 저장소에는 성격이 다른 두 종류의 검증이 섞여 있다.
+
+1. **스켈레톤을 만드는 사람**에게 필요한 검증 — sample 모듈이 정말 제거 가능한가, optional 모듈
+   조합이 모두 빌드되는가, 레지스트리가 확장 가능한가.
+2. **스켈레톤을 가져다 서비스를 만드는 사람**에게 필요한 검증 — 내 애플리케이션의 테스트,
+   아키텍처 방향, 보안, 릴리스.
+
+파생 프로젝트가 1번을 그대로 물려받으면, 자기 서비스와 아무 상관 없는 게이트를 평생 유지하게 된다.
+이 문서는 어느 쪽이 어느 쪽인지 적어 둔다.
+
+## Template 전용 (파생 프로젝트는 삭제해도 된다)
+
+| 대상 | 무엇을 지키는가 |
+| --- | --- |
+| `:app-bootstrap:sampleOffTest`, `ci-quality-gates.yml`의 `sample-off` job | sample 픽스처를 지워도 애플리케이션이 빌드·부팅되는가 |
+| `sample-portfolio` leaf 전체 | 참조 구현 |
+| `Dockerfile.sample`, `docker-compose.*` 중 sample 관련 | 위와 동일 |
+| `docs/superpowers/**` | 이 템플릿을 만든 과정의 설계/계획 기록 |
+| `gradle/qualification/**` | 이 템플릿이 벤더링한 플랫폼(JPA, messaging)의 인증 체계 |
+| `*-certification.yml`, `*-qualification.yml`, `jpa-next-*.yml` | 템플릿이 광고하는 지원 매트릭스의 근거 |
+
+## Consumer 필수 (파생 프로젝트가 유지해야 한다)
+
+| 대상 | 무엇을 지키는가 |
+| --- | --- |
+| `architectureCheck` | Clean Architecture 의존 방향. 이 템플릿의 존재 이유 |
+| 각 leaf의 `check` | 컴파일 · 단위 테스트 · 포맷 · 스타일 · Error Prone |
+| `qualityCheck` | SpotBugs / FindSecBugs |
+| `configContractCheck` | 환경변수 계약 |
+| `verifyDependencyLocks` | 재현 가능한 의존성 해석 |
+| `dependency-vulnerability.yml` | dependency-review + Trivy |
+| `ci-quality-gates.yml` | PR 게이트 |
+| `release.yml` | 이미지 · SBOM 생산 |
+| action의 full SHA 핀 | 공급망 |
+
+## 파생 프로젝트가 할 일
+
+1. Template 전용 표의 항목을 삭제한다. 삭제는 대부분 파일 삭제 + `config/architecture/modules.json`
+   에서 leaf 항목 제거로 끝난다 — 레지스트리가 leaf 목록의 SSOT이고, 개수를 따로 적어 둔 곳은 없다.
+2. `docs/ci-cd/boundary.md`의 경계를 그대로 유지한 채 자기 GitOps 저장소를 연결한다.
+3. `.trivyignore.yaml`과 CODEOWNERS는 그대로 쓴다.
+
+## 아직 하지 않은 것
+
+Template CI와 Generated Application CI를 **물리적으로** 분리하지는 않았다(생성기 없음). 지금은 이
+문서가 그 경계다. 생성기를 만든다면, 위 표의 "Template 전용" 열이 생성기가 벗겨 내야 할 목록이다.