Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/runtime-reachability-and-composition/case/case-messaging-runtime-core-f02.md
T
DongHyeonkaandClaude Fable 5.1 b25357c48a docs(clean-architecture-backend-template): fold analysis into final and re-select one topic
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다
- 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5
  (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를
  techviz 로 만들었다
- 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs
  돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다.
  Concept 이 인용한 코드가 SSOT 에 없어 뺐다
- candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-07 12:39:20 +09:00

3.5 KiB

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module, priority
kind slug title topic project status sourceRevision rootTreeNode evidenceCapturedOn assets evidence source module priority
CASE messaging-runtime-core-f02 소비 오케스트레이터가 조립되지 않는다 runtime-reachability-and-composition clean-architecture-backend-template 게시 전 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 case:messaging-runtime-core-f02 2026-09-01
key file
messaging-runtime-core-f02 ../../../final/evidence/rendered/messaging-runtime-core-f02.svg
key file
messaging-runtime-core-f02-diagram ../../../final/assets/diagrams/messaging-runtime-core-f02.svg
../../../final/evidence/raw/messaging-runtime-core-f02.txt
원본 분석 절은 final/document.md#a19-messaging-runtime-core#L719 이다.
messaging-runtime-core P2

소비 오케스트레이터가 조립되지 않는다

DefaultDeliveryProcessor는 leaf 밖 참조 0, src/main 생성 0, src/test 생성 1이다. 이 클래스가 고친 문제("각 어댑터가 retry/dead-letter의 뜻을 각자 결정")가 배선 없이는 그대로 남는다.

관계

  • 만들어 두고 흘리지 않는 진단값은 진단이 아니다 같은 분석 리프에서 끌어낸 규칙이다.
  • 증가한다고 문서화한 값이 리터럴이면 그 사실을 적는다 같은 분석 리프에서 끌어낸 규칙이다.
  • 안정 코드는 운영자의 행동이 갈리는 지점마다 나눈다 같은 분석 리프에서 끌어낸 규칙이다.
  • CompletionStage를 반환하는 메서드는 동기적으로 던지지 않는다 같은 분석 리프에서 끌어낸 규칙이다.

문제

DefaultDeliveryProcessor는 leaf 밖 참조 0, src/main 생성 0, src/test 생성 1이다.

이 클래스가 고친 문제("각 어댑터가 retry/dead-letter의 뜻을 각자 결정")가 배선 없이는 그대로 남는다.

결론

그리고 DeclaredDestinationAccess가 consume 권한을 빈 집합으로 두는 것과 정합적이다 — 기본 구성은 소비를 상정하지 않는다.

검증 환경

OpenJDK : 21.0.12 java -version 으로 확인 Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인 확인 방식 : DefaultDeliveryProcessor 참조 7건 검색으로 leaf 밖 참조와 src/main 생성 수 확인 소스 수정 : x

재현 조건

원문은 final/document.md#a19-messaging-runtime-core#L719 에 있다.

본문

DefaultDeliveryProcessor는 leaf 밖 참조 0, src/main 생성 0, src/test 생성 1이다.

경로가 열리지 않는 이유

:::evidence key="messaging-runtime-core-f02-diagram" alt="발행 경로만 조립되는 것 안에 놓이고 DefaultDeliveryProcessor 가 바깥에 빗금으로 놓인다" caption="경로가 열리지 않는 이유" zoom="false" :::

DefaultDeliveryProcessor 참조 위치

:::evidence key="messaging-runtime-core-f02" alt="코드베이스에서 DefaultDeliveryProcessor 를 검색한 출력 7줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="DefaultDeliveryProcessor 코드베이스 검색 — 7줄 · exit 0" zoom="true" :::

이 클래스가 고친 문제가 그대로 남는다

"각 어댑터가 retry/dead-letter의 뜻을 각자 결정" 이다. 그리고 DeclaredDestinationAccess가 consume 권한을 빈 집합으로 두는 것과 정합적이다 — 기본 구성은 소비를 상정하지 않는다.

확인하지 못한 것

파생 프로젝트가 이 오케스트레이터를 직접 조립하는지 확인할 방법이 이 저장소 안에 없다.