DongHyeonkaandClaude Opus 5
b2963105a8
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>
4.5 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | body | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a19-f018 | claim-check는 starter에 배선 코드가 한 줄도 없다 | messaging-and-outbox | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a19-f018 | 2026-09-01 | case-analysis-finding-a19-f018.body.md |
|
|
|
claim-check는 starter에 배선 코드가 한 줄도 없다
출하 리프의 두 진입 타입이 주 참조 0 건이고 신뢰성 자동 설정에 그 이름이 아예 나오지 않는다. 프로파일은 임계값을 선언할 수 있고 검증도 받는데 그것을 수행하는 코드가 조립되지 않는다.
관계
- 상호운용 규격 leaf는 출하되고 starter의 의존이며 소비자가 없다 같은 가족의 같은 형태다.
- 두 개의 outbox 중 하나만 조립되어 있다 같은 계열의 조립 문제다.
- 조용한 잘못된 성공이 아니라 시끄러운 실패다 판정을 낮춘 이유다.
문제
청구 확인 리프가 출하된다. 주 파일 여섯에 사백여 줄이다.
바깥에서 들어오는 경로가 있는지 확인했다.
결론
없다.
발행자와 해석기의 주 참조가 0 건이고, 신뢰성 자동 설정에 이 이름의 문자열이 등장하지 않는다.
무결성 가드와 정책과 저장소는 리프 내부에서 서로를 참조한다. 그러므로 리프는 내부적으로 일관되다.
다만 바깥에서 들어오는 경로가 없다.
목적지 프로파일 검증기는 이 기능을 알고 있다.
임계값이 최대 크기보다 크면 거부한다.
즉 프로파일은 임계값을 선언할 수 있고 검증도 받는데, 그 임계값을 넘는 적재물에 대해 이 기능을 수행하는 코드가 조립되지 않는다.
임계값은 설정 가능하고 효과는 없다.
같은 가족의 발신함 사례보다 낮은 등급으로 두는 이유가 있다.
이 기능은 부재 시 동작이 명확하다.
적재물이 그대로 전송되고, 크기 한도에 걸리면 전용 예외로 명시적으로 실패한다.
조용한 잘못된 성공이 아니라 시끄러운 실패다.
판정은 P3 다.
검증 환경
확인 방식 : 참조 계수와 자동 설정 문자열 검색 소스 수정 : x
재현 조건
원문은 final/evidence/raw/252 계열에 있다.
- 리프의 주 파일과 줄 수를 센다.
- 두 진입 타입의 주 참조를 센다.
- 신뢰성 자동 설정에서 이 이름을 검색한다.
- 리프 내부의 상호 참조를 확인한다.
- 목적지 프로파일 검증기의 관련 규칙을 확인한다.
본문
messaging-claim-check(6 main, 418 LOC, 출하)의 ClaimCheckPublisher·ClaimCheckResolver는 main 참조 0건이고, MessagingReliabilityAutoConfiguration에 ClaimCheck 문자열이 등장하지 않는다.
ClaimCheckPublisher 참조 위치
:::evidence key="analysis-finding-a19-f018" alt="코드베이스에서 ClaimCheckPublisher 를 검색한 출력 2줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ClaimCheckPublisher 코드베이스 검색 — 2줄 · exit 0" zoom="true" :::
leaf는 내부적으로 일관되고 바깥 경로가 없다
ClaimCheckIntegrityGuard·ClaimCheckPolicy·ClaimCheckStore는 leaf 내부에서 서로를 참조한다.
임계값은 설정 가능하고 효과는 없다
DestinationProfileValidator는 claim check를 알고 있다 — profile.payload().claimCheckThresholdBytes() > profile.payload().maxBytes()를 거부한다. 즉 프로파일은 claim check 임계값을 선언할 수 있고 검증도 받지만, 그 임계값을 넘는 payload에 대해 claim check를 수행하는 코드가 조립되지 않는다.
P3으로 두는 이유
claim check는 outbox와 달리 부재 시 동작이 명확하다 — payload가 그대로 전송되고, 크기 한도(BoundedByteSink, §4.1)에 걸리면 MessageTooLargeException으로 명시적으로 실패한다. 조용한 잘못된 성공이 아니라 시끄러운 실패다.
확인하지 못한 것
임계값을 넘는 적재물을 보내 그대로 전송되는 것을 재현하지 않았다. 조립 부재상 그 결과가 나온다.