Files
document-haness/docs/clean-architecture-backend-template/final/evidence/raw/325-grpc-block-is-entirely-unreachable.txt
T
DongHyeonkaandClaude Opus 5 b2963105a8 docs(keycloak-session-store): import the session-storage lab as a new project
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.

Follows the import procedure in README.md.

  source/     the originating repository verbatim — 78 documents, 28 SVGs,
              8 manifests, plus .source-revision recording the commit
  final/      the SSOT
    document.md   729 lines written from the 29 experiment documents, not
                  concatenated: what was predicted, what was measured, and
                  where the measurement itself was wrong
    evidence/raw    125 outputs, flattened to <experiment>__<file> because
                    the originals collided (01-baseline.txt appeared three
                    times) and the audit only globs the top level
    evidence/meta   one per raw file; command and exitCode are null and the
                    README says why rather than inventing them
    evidence/browser  22 captures
    assets/       three diagrams through techviz
    .techviz/     their VizSpecs

A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.

Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.

verify-pipeline.py passes. audit-records.py reports no issues.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 22:51:59 +09:00

126 lines
8.5 KiB
Plaintext

# 주제: gRPC 플랫폼 18개 리프 전체가 어떤 배포에도 도달하지 않는다 (블록 수준 사실)
# revision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
# 이 파일은 grpc-* 18개 리프 문서 전부가 인용하는 공통 근거다.
# ---- (1) 18개 전부 runtime_memberships: [] ----
# command: modules.json 에서 id 가 grpc- 로 시작하는 항목 전수
leaf memberships allowed_dependencies
grpc-core-api [] 0:
grpc-policy [] 1: grpc-core-api
grpc-proto-contract [] 1: grpc-core-api
grpc-observability [] 1: grpc-core-api
grpc-operation-ledger-jpa [] 1: grpc-core-api
grpc-advanced-bootstrap [] 1: grpc-core-api
grpc-server [] 2: grpc-core-api, grpc-policy
grpc-client [] 2: grpc-core-api, grpc-policy
grpc-admin [] 2: grpc-core-api, grpc-server
grpc-codegen [] 2: grpc-core-api, grpc-proto-contract
grpc-discovery [] 2: grpc-client, grpc-core-api
grpc-advanced-diagnostics [] 3: grpc-advanced-bootstrap, grpc-client, grpc-core-api
grpc-advanced-edition [] 3: grpc-advanced-bootstrap, grpc-core-api, grpc-proto-contract
grpc-advanced-streaming [] 3: grpc-advanced-bootstrap, grpc-core-api, grpc-policy
grpc-advanced-compat [] 5: grpc-advanced-bootstrap, grpc-client, grpc-core-api, grpc-policy, grpc-server
grpc-advanced-resilience [] 5: grpc-advanced-bootstrap, grpc-client, grpc-core-api, grpc-discovery, grpc-policy
grpc-spring-boot-starter [] 10: admin, client, codegen, core-api, discovery, observability,
operation-ledger-jpa, policy, proto-contract, server
grpc-testkit [] 10: (동일 10개)
# => 18/18 이 빈 멤버십이다. messaging 은 25개 중 8개가 app-bootstrap 에 속한다.
# ---- (2) grpc 밖에서 이 코드를 import 하는 파일이 0건 ----
# command: git grep -ln "import dev.caskeleton.grpc" -- src | grep -v "^src/grpc/" | grep -v "^src/grpc-advanced/"
# exit: 1 (출력 없음)
# => 29,245 LOC 짜리 플랫폼 전체의 외부 소비자가 0이다.
# ---- (3) app-bootstrap 이 의존하는 것은 다른 계보다 ----
# command: grep -n "grpc" src/app-bootstrap/build.gradle
# 199: conditionalTransportTestImplementation project(':adapter:inbound:grpc')
# => (a) src/grpc/* 가 아니라 src/adapter/inbound/grpc 다.
# (b) conditionalTransportTestImplementation — **테스트 전용 구성**이다.
#
# src/adapter/inbound/grpc/build.gradle 헤더:
# "Driving adapter: gRPC API (skeleton machinery, transport-only)."
# "A SmartLifecycle bean (GrpcServerRunner) owns the io.grpc Netty server, so this module depends
# on NO third-party grpc-spring-boot starter"
# "The skeleton compiles NO protobuf: there is no `com.google.protobuf` plugin and no `.proto`
# here — health + reflection come from grpc-services at runtime, and a future consuming feature
# owns its `.proto`/services."
# => 저장소에 gRPC 구현이 **두 계보** 있다:
# A. src/adapter/inbound/grpc — 스켈레톤, protobuf 없음, app-bootstrap 이 테스트 의존
# B. src/grpc/* + src/grpc-advanced/* — 18리프 플랫폼, 소비자 0
# 두 계보 사이에 코드 참조가 없다.
# ---- (4) 빌드에는 포함된다 ----
# src/settings.gradle 은 grpc 를 명시하지 않는다. 대신:
# id 'ca.architecture-registry'
# "Reads and validates config/architecture/modules.json, then includes every registered project"
# => 18개 리프는 레지스트리를 통해 빌드에 포함되고, 컴파일·테스트·정적분석 게이트를 전부 통과한다.
# 배포 그래프에만 들어가지 않는다.
# ---- (5) 테스트는 전부 통과한다 ----
# command: ./gradlew :grpc:*:test :grpc-advanced:*:test --console=plain
# exit: 0 (BUILD SUCCESSFUL, 81 tasks up-to-date — 입력 불변이므로 이 revision 의 결과다)
grpc-admin tests=27 failures=0 skipped=0
grpc-client tests=31 failures=0 skipped=0
grpc-codegen tests=21 failures=0 skipped=0
grpc-core-api tests=63 failures=0 skipped=0
grpc-discovery tests=15 failures=0 skipped=0
grpc-observability tests=10 failures=0 skipped=0
grpc-operation-ledger-jpa tests=10 failures=0 skipped=0
grpc-policy tests=151 failures=0 skipped=0
grpc-proto-contract tests=13 failures=0 skipped=0
grpc-server tests=41 failures=0 skipped=0
grpc-spring-boot-starter tests=12 failures=0 skipped=0
grpc-testkit tests=56 failures=0 skipped=0
grpc-advanced-bootstrap tests=17 failures=0 skipped=0
grpc-advanced-compat tests=27 failures=0 skipped=0
grpc-advanced-diagnostics tests=11 failures=0 skipped=0
grpc-advanced-edition tests=13 failures=0 skipped=0
grpc-advanced-resilience tests=31 failures=0 skipped=0
grpc-advanced-streaming tests=30 failures=0 skipped=0
TOTAL tests=579 failures=0 skipped=0
# 컨테이너 IT 는 없다 (testcontainers 의존을 가진 grpc 리프가 없다).
# ---- (6) 규모 ----
leaf files loc main test
grpc-policy 80 7581 62 18 <- 최대
grpc-testkit 34 3652 26 8
grpc-core-api 39 2823 32 7
grpc-server 22 1836 17 5
grpc-advanced-resilience 20 1517 16 4
grpc-client 17 1512 13 4
grpc-advanced-compat 22 1485 17 5
grpc-admin 17 1403 13 4
grpc-advanced-streaming 18 1262 14 4
grpc-codegen 13 1139 9 4
grpc-proto-contract 4 929 3 1
grpc-advanced-bootstrap 11 889 9 2
grpc-spring-boot-starter 5 735 4 1
grpc-discovery 9 629 7 2
grpc-advanced-edition 8 537 6 2
grpc-observability 5 526 4 1
grpc-advanced-diagnostics 5 506 4 1
grpc-operation-ledger-jpa 4 484 3 1
TOTAL 332 29245 255 77
# ---- 중요: 이 상태는 이미 정확히 문서화되어 있다 (grpc-testkit 분석 중 발견) ----
# src/grpc/CLAUDE.md:74-98 이 위 측정과 같은 내용을 스스로 서술한다:
# "registry의 모든 grpc:* leaf는 현재 runtime_memberships가 비어 있다. …
# **배포 아티팩트가 싣고 있지 않다.** build-only다."
# "애플리케이션에 배선하려면 registry의 runtime_memberships를 먼저 바꾸고
# verifyRuntimeModuleMembership을 통과시켜야 한다. 코드만 추가하는 것으로는 런타임에 들어가지 않는다."
# "현재 adapter:inbound:grpc는 이 family에 의존하지 않는다 — registry의 allowed_dependencies를
# 보라. 배선은 별도 결정이며, 그때 registry edge와 브리지가 함께 들어간다."
# "messaging:*의 MSG-015(bridge 부재)를 반복하지 않는 것이 이 family의 목표다."
# => 이 파일이 측정한 것은 **드리프트가 아니라 확인**이다. 미배선은 인지되고 서술된 상태이며,
# 두 계보가 분리되어 있는 것도 의도된 것이다.
# 각 리프 문서의 §12.1 은 이 사실을 기준선으로 쓰되, 그것을 결함으로 제시해서는 안 된다.
# (CLAUDE.md 의 세 주장 중 "GrpcStableReleaseGate가 그 구분을 코드로 붙들고 있다" 만
# 절반만 성립한다 — EVD-330 참조.)
# ---- 판정 ----
# messaging 플랫폼은 "설계는 완성되었고 조립이 부분적" 이었다 — 발행 경로는 살아 있고
# 소비 경로가 배선되지 않았다. gRPC 플랫폼은 그것과 다르다: **조립이 아예 없다.**
# 18개 리프가 서로를 의존하며 닫힌 그래프를 이루고, 그 그래프 밖으로 나가는 참조가 하나도 없다.
# 이 사실이 각 리프 문서의 §12.1 판정 기준선이며, 개별 리프의 "미사용" 은
# 그 리프의 결함이 아니라 블록 전체의 상태다.