Files
document-haness/docs/clean-architecture-backend-template/final/evidence/raw/analysis-finding-a14-f019.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

16 lines
2.6 KiB
Plaintext

### 48.1 P1 — 크로스 스택 게이트가 검증하는 조립은 픽스처의 조립이고, 플랫폼의 조립이 아니다
이 leaf는 이 저장소에서 가장 정교한 검증 장치를 갖고 있다 — 여섯 소스셋, 다섯 커스텀 레인, 세 런타임 패리티 비교, 실제 Nginx 컨테이너, 실제 소켓 고장 주입. 그리고 §47.1이 보여주듯 **그 장치가 세우는 애플리케이션은 픽스처 애플리케이션이다.**
`BudgetFixtureApplication`이 `FilterRegistrationBean<WebMvcBudgetFilter>`를 손수 등록한다. `JettyWebBudgetIT` · `ReactiveWebBudgetIT`가 그 애플리케이션을 띄워 예산 계약을 세 런타임에서 증명한다. 증명되는 명제는 "**이 필터가 등록되면** 예산이 지켜진다"이고, "플랫폼이 이 필터를 등록한다"는 명제는 어떤 레인도 세우지 않는다 — 그리고 §16.1이 확인했듯 플랫폼은 등록하지 않는다.
같은 구조가 스로틀(§16.1) · 멱등성(§20.1) · SSE(§36.1) · 요청 컨텍스트(§12.1)에 반복된다.
**빠진 검증은 하나다** — 두 자동설정(`WebMvcPlatformAutoConfiguration` · `WebFluxPlatformAutoConfiguration`)이 세운 컨텍스트에 무엇이 있는지 확인하는 테스트. `WebMvcPlatformAutoConfigurationTest`(112줄)와 `WebFluxPlatformAutoConfigurationTest`(112줄)가 존재하지만 자동설정이 **선언한** 빈들을 확인할 뿐, 필터 체인에 예산·스로틀·멱등성이 있는지는 묻지 않는다 — 자동설정이 그것들을 선언하지 않으므로 확인할 것도 없다.
**이 sub-scope에 P1을 두는 이유** — 결함은 픽스처에 있지 않다. 픽스처는 정확하고 계약은 잘 쓰였다. 결함은 **검증 전략의 경계**에 있다: 이 leaf는 "능력이 올바른가"를 다섯 레인으로 묻고 "플랫폼이 능력을 설치하는가"를 묻는 레인을 하나도 갖지 않는다. 그 공백이 §12.1 · §16.1 · §20.1 · §36.1 · §40.1 다섯 개의 P1/P2가 초록색 스위트 아래에서 성립할 수 있게 한 단일 원인이다.
**권고** — 픽스처를 하나 더 만드는 것이 아니라, **아무것도 등록하지 않는** 픽스처를 하나 만든다: `@SpringBootConfiguration` + `@EnableAutoConfiguration`만 있고 `@Bean`이 없는 애플리케이션을 띄워 필터 체인·컨트롤러 조언·인터셉터 목록을 스냅샷으로 고정한다. 그 스냅샷이 §16.1 · §20.1을 즉시 드러내고, 이후 회귀도 막는다. `WebPlatformContractRecording`이 이미 기록·비교 형태를 갖고 있으므로 형식은 있다.
### 48.2 — testkit·레인 자체의 결함: 없음