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>
2.1 KiB
2.1 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | questionStatus | verifiedOn |
|---|---|---|---|---|---|---|---|---|---|
| QUESTION | a02-f002-domaincontextkey | DomainContextKey same-name different-type collision | multitenancy-isolation | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:a02-f002-domaincontextkey | OPEN |
DomainContextKey same-name different-type collision
컨텍스트 키의 신원이 이름뿐인데 조회는 요청된 타입으로 캐스팅한다. 같은 이름의 다른 타입 키를 선언하는 것이 금지인지 허용인지 정해져 있지 않다.
사실
키의 신원은 이름만으로 정해진다.
조회는 요청된 타입으로 캐스팅한다.
가정
같은 이름의 키가 하나뿐일 것이라고 전제하고 있다. 그 전제를 강제하는 것이 없다.
미지수
같은 이름의 다른 타입 키 선언이 금지된 계약인가.
허용이라면 캐스팅 실패의 의미가 무엇인가.
제약
키 선언이 여러 모듈에 흩어져 있으면 생성 시점 충돌 탐지가 전역 레지스트리를 요구한다.
선택지
생성이나 등록 단계에서 충돌을 거부한다 같은 이름이 두 번 선언되면 실패한다. 전역 레지스트리가 필요하다.
허용하고 실패 의미를 문서화한다 캐스팅 실패가 언제 어떤 형태로 나타나는지 계약에 적는다.
다음 검증
같은 이름에 다른 타입을 갖는 키 픽스처를 만들고 생성과 조회의 실패를 고정한다. 그다음 레지스트리의 실제 키 선언을 전수 대조한다.
같은 이름 다른 타입이 금지라면 생성이나 등록 단계에서 충돌을 거부한다.
허용이라면 캐스팅 실패 의미와 사용 조건을 계약에 명시한다.
관계
- 이름은 값이 아니라 registry key다 이 질문이 다루는 이름의 성질이다.
- 위험한 조합은 정책이 아니라 생성자가 거부하게 만든다 한쪽 방향의 구현 규칙이다.