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>
2.9 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | adapter-outbound-persistence-jpa-c42 | 여섯 package만 스캔하므로 같은 리프 안에서도 도달성이 다르다 | transaction-and-consistency-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-outbound-persistence-jpa-c42 | 2026-09-01 |
|
|
|
adapter-outbound-persistence-jpa |
여섯 package만 스캔하므로 같은 리프 안에서도 도달성이 다르다
JpaAdapterComponentsConfig는 adapter 전체를 넓게 scan하지 않고 audit·failure·idempotency·lock·outbox·transaction 여섯만 명시적으로 component scan한다.
본문
JpaAdapterComponentsConfig는 adapter 전체를 넓게 scan하지 않고 audit·failure·idempotency·lock·outbox·transaction 여섯 package만 명시적으로 component scan한다.
narrow scan이 닿는 범위
:::evidence key="adapter-outbound-persistence-jpa-c42-diagram" alt="스캔 경계 안에 여섯 package 가 두 상자로 들어 있고 두 어댑터가 경계 밖 빗금 상자로 놓인 구조" caption="narrow scan 이 닿는 범위" zoom="false" :::
OutboxStoreAdapter는 baseline scan에 들어가고 app-bootstrap의 OutboxConfig가 OutboxStorePort로 사용한다. DurableOperationStoreAdapter, JpaLiveEventReplayAdapter는 현재 baseline component scan에 들어가지 않고 별도 production constructor/reference도 확인되지 않았다.
JpaAdapterComponentsConfig 참조 위치
:::evidence key="adapter-outbound-persistence-jpa-c42" alt="코드베이스에서 JpaAdapterComponentsConfig 를 검색한 출력 5줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="JpaAdapterComponentsConfig 코드베이스 검색 — 5줄 · exit 0" zoom="true" :::
default composition에 들어가지 않는 것
HibernateCacheGuard, HibernateEnversHistoryReader와 Spring Data auditing candidate도 default composition에 들어가지 않는다. runtime-role verifier 자체는 app-bootstrap bean으로 구성되지만, policy를 적용하는 requireSafe() caller가 없다.
판정을 세 등급으로 나누는 이유
이 차이 때문에 아래 finding은 production, conditional-production, latent를 분리해 판정한다. 정적 composition snapshot은 evidence/raw/072-baseline-capability-reachability.txt에 남겼다.