# 주제: messaging-admin-runtime 안에 완결된 토폴로지 검증 스택이 두 벌 있고,
#       문서화된 판단이 서로 어긋나며, 둘 다 프로덕션 호출부가 없다
# revision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916

# ---- Stack A ----
#   BrokerTopologyInspector (SPI)
#     -> CompositeTopologyValidator.validate(List<TopologyManifest>)
#        -> TopologyValidator.compare(manifest, observed) -> List<TopologyIssue>  (severity 있음)
#     -> TopologyValidationReport
#        -> requireAcceptable() -> MessagingConfigurationException("TOPOLOGY_MISMATCH")
#
# ---- Stack B ----
#   TopologyValidationRuntime.TopologyReader (SPI)
#     -> TopologyValidationRuntime.validate(List<TopologyManifest>)
#        -> TopologyManifest.differencesFrom(...) -> List<String>                 (severity 없음)
#     -> 직접 throw MessageTopologyException("TOPOLOGY_MISMATCH")

# ---- 두 스택이 어긋나는 지점 ----
# (1) 파티션 수가 선언보다 **많을** 때
#   Stack A — TopologyValidator.java:58-66
#     } else if (observed.partitions() > manifest.partitions()) {
#       // Scaling a topic up is a legitimate operation; refusing to start would punish it.
#       issues.add(TopologyIssue.advisory(...));
#     }
#     클래스 javadoc:16-18 "A partition count that is *higher* than declared is advisory rather
#                           than blocking: extra partitions do not break durability, and someone
#                           scaling a topic up deliberately should not be met with a refusal to start."
#   Stack B — TopologyManifest.differencesFrom (messaging-admin-api/TopologyManifest.java:57-59)
#     if (actualPartitions != partitions) { differences.add("partitions expected … but found …"); }
#     -> 많든 적든 차이면 problems 에 들어가고 TopologyValidationRuntime:53-57 이 예외를 던진다.
#   => 토픽을 의도적으로 스케일 업한 배포에 대해 A 는 기동을 허용하고 B 는 거부한다.
#      A 쪽에는 그 판단의 근거가 주석으로 명시되어 있다.
#
# (2) physicalName 불일치 — A 는 BLOCKING 으로 검사(TopologyValidator:45-49), B 는 검사하지 않는다.
# (3) severity — A 는 BLOCKING/ADVISORY 구분, B 는 전부 치명.
# (4) 예외 타입 — A: MessagingConfigurationException, B: MessageTopologyException. 코드 문자열은
#     둘 다 "TOPOLOGY_MISMATCH" 로 같다.
# (5) 부재 처리 — A: DestinationTopology.absent(...) 후 BLOCKING issue,
#                 B: reader.read() == null -> "… does not exist" 문자열.

# ---- 두 스택 모두 프로덕션 호출부가 없다 ----
# command: git grep -n "TopologyValidationRuntime\|TopologyReader\|ObservedTopology" -- src
#   src/main 등장: TopologyValidationRuntime.java 자기 자신뿐 (18,20,27,42,62,70,80,83)
#   나머지는 전부 TopologyValidationRuntimeTest.java
#   => Stack B: 프로덕션 호출부 0건.
#
# command: git grep -n "validateTopology" -- src        (EVD-302 재확인)
#   MessagingAdminService:32 (선언) + DefaultMessagingAdminService:106 (구현). 호출 0건.
#   => Stack A: 프로덕션 호출부 0건.

# ---- 오케스트레이션 계층이 어디에서도 생성되지 않는다 ----
# command: git grep -nE "new ([a-zA-Z0-9_.]+\.)?<T>\s*\(" -- src   (T별 집계)
  DefaultMessagingAdminService     src/main=0 src/test=0     <-- 어디에서도 생성되지 않음
  ReplayService                    src/main=0 src/test=0     <-- 어디에서도 생성되지 않음
  RedriveService                   src/main=0 src/test=1     (RedriveResumptionTest 만)
  CompositeTopologyValidator       src/main=1 src/test=1     (스타터)
  TopologyValidator                src/main=1 src/test=6     (CompositeTopologyValidator 내부 필드)
  TopologyValidationRuntime        src/main=0 src/test=4
  InMemoryAdminOperationJournal    src/main=1 src/test=3     (스타터)
  JdbcAdminOperationJournal        src/main=0 src/test=2
#
# src/main 생성 상세 (전 저장소에서 2건뿐):
#   MessagingAdminAutoConfiguration.java:57  new InMemoryAdminOperationJournal();
#   MessagingAdminAutoConfiguration.java:84  new CompositeTopologyValidator(inspector);
#
# => DefaultMessagingAdminService 257줄 — 계획/승인/저널/실행을 잇는 유일한 오케스트레이터이며
#    클래스 javadoc 이 "Execution runs four checks, in this order, and the order is the point" 이라고
#    쓰는 그 클래스 — 는 프로덕션에서도 테스트에서도 인스턴스화되지 않는다. 실행 커버리지 0.
#    ApprovedPlanExecutionTest 11건은 Approved*Plan 타입을 직접 검증하며 이 서비스를 거치지 않는다.

# ---- DestructiveMessagingAdmin 은 구현체가 없다 ----
# command: git grep -n "DestructiveMessagingAdmin" -- src
#   DestructiveMessagingAdmin.java:21  (선언)
#   MessagingAdminService.java:21      ({@link} 참조)
#   MessagingAdminAutoConfiguration.java:22 ({@link} 참조)
# command: git grep -n "DestructiveMessagingAdmin.Approved\|new Approved(\|DestructiveResult" -- src
#   (선언 파일 제외 후 출력 없음)
# => implements 0건, Approved/DestructiveResult 사용 0건.
#    DestructiveOperation 5개 상수 중 PURGE / OFFSET_RESET / DELETE_DESTINATION 3개는
#    이 저장소 어디에도 실행 경로가 없다. (REPLAY/REDRIVE 만 서비스가 있다.)