Files

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

4.9 KiB

Raw Blame History

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-a10-f003

SDK가 선언한 두 진입점에 구현이 없다

caching-and-redis

clean-architecture-backend-template

게시 전

21234e38cdb9a926cbc92bb97a2aee2e4a7d2916

case:analysis-finding-a10-f003

2026-09-01

case-analysis-finding-a10-f003.body.md

key	file
analysis-finding-a10-f003	../../../final/evidence/rendered/analysis-finding-a10-f003.svg

../../../final/evidence/raw/analysis-finding-a10-f003.txt

원본 분석 절은 analysis/10-adapter-outbound-cache-redis.md#L251 이다.

SDK가 선언한 두 진입점에 구현이 없다

동기와 반응형 진입점 인터페이스가 각각 열두 접근자를 선언한다. 개별 표면은 사십삼 종이 모두 구현되어 있는데 두 진입점을 구현하는 클래스는 하나도 없다. 대칭 테스트는 인터페이스끼리만 비교하므로 이것을 가리지 못한다.

관계

README readiness 표가 있는 것을 없다고 적는다 같은 리프의 반대 방향 사례이고 원인은 같다.
미배선 경계가 문서에만 있고 compile 경로에서 닫히지 않는다 같은 형태의 절반 조립이다.
인터페이스끼리 비교하는 test는 구현의 부재를 못 본다 이 사례가 그 규칙의 형태다.

문제

동기 진입점 인터페이스가 자신을 형 있는 API 로의 동기 진입점이라 소개하고, 반응형 인터페이스가 그 짝이다.

두 인터페이스는 각각 열두 접근자를 선언한다. 값과 해시와 리스트와 집합과 정렬 집합과 비트맵과 비트 필드와 확률적 집계와 지리와 스트림과 키와 배치다.

결론

둘 다 구현체가 없다.

리프 전체의 구현 선언을 전수 조사했다. 개별 표면은 전부 구현되어 있다. 동기 스물여섯 종과 반응형 열일곱 종이다.

그런데 두 진입점을 구현한다고 선언한 클래스는 0 건이다.

main 안에서 두 타입을 이름으로 부르는 곳도 없다. 유일한 참조가 반응형 인터페이스 자바독의 링크 하나와 대칭 테스트의 반사 두 줄이다.

결과적으로 이 SDK 를 쓰는 코드는 진입점을 얻을 수 없다.

열두 표면을 각각 어디선가 따로 받아야 하고, 진입점이 약속하는 하나의 객체에서 형 있는 표면 전체는 존재하지 않는다.

접근자를 추가하고 반응형 짝을 맞추는 규율은 실행되고 있다. 그 규율이 만드는 대상을 실제로 만드는 코드가 없다.

판정은 P2 다.

데이터 위험은 없다. 없는 타입은 잘못된 답을 주지 않는다.

위험은 API 계약의 신뢰다. 이 리프의 공개 표면 중 가장 먼저 읽히는 두 타입이 구현되지 않은 상태이고, 대칭 테스트가 그 사실을 가리지 못한다. 인터페이스끼리만 비교하기 때문이다.

같은 리프의 준비도 표 사례와 방향이 반대이면서 원인은 같다. 조립이 절반이다.

수정은 이미 존재하는 구현들을 묶는 두 클래스를 추가하고, 대칭 테스트에 두 진입점이 구현을 가진다는 검사를 더하는 것이다.

검증 환경

확인 방식 : 구현 선언 전수 조사와 이름 참조 검색 소스 수정 : x

재현 조건

원문은 final/evidence/raw/160 계열에 있다.

두 진입점 인터페이스의 접근자 목록을 확인한다.
리프 전체에서 구현 선언을 전수 조사한다.
두 진입점을 구현하는 클래스가 있는지 센다.
main 안에서 두 타입 이름을 검색한다.
대칭 테스트가 무엇과 무엇을 비교하는지 확인한다.

본문

SDK가 선언한 두 진입점에 구현이 없다.