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.7 KiB
2.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, decisionStatus, decidedOn, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | decisionStatus | decidedOn | source | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PROJECT_DECISION | only-the-certification-lane-carries-no-docker-guard | 인증 레인만 Docker 가드를 달지 않는다 | what-a-gate-does-not-prove | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | decision:only-the-certification-lane-carries-no-docker-guard | ADOPTED | 2026-08-30 |
|
인증 레인만 Docker 가드를 달지 않는다
결정문
컨테이너를 쓰는 모든 suite 는 Docker 가 없으면 이유를 적고 건너뛰되, 인증 레인만은 건너뛰지 않는다.
판단 이유
건너뛰는 레인은 아무도 시작하지 않은 브로커에 대해 성공을 보고한다. 인증은 그 브로커에 대해 무언가를 주장하는 일이므로, 주장의 근거가 없을 때 성공을 내는 것은 인증의 반대다.
다른 컨테이너 suite 는 사정이 다르다. 그것들은 개발자의 랩톱에서도 돌아야 하고, Docker 가 없다는 이유로 빌드가 깨지면 그 suite 는 곧 꺼진다.
그래서 인증 레인은 기본 test 에서 태그로 제외한다. 랩톱 빌드는 깨지지 않고, 인증은 전용 워크플로에서만 돌아간다.
그 워크플로가 도는 것은 레인이 아니라 게이트다. 게이트가 레인에 의존하므로 레인을 빠뜨리면 게이트가 실패한다. 워크플로가 레인 이름을 직접 부르면, 레인이 추가될 때 워크플로를 함께 고쳐야 하고 잊으면 조용히 빠진다.
영향
감수하는 것
인증 레인은 로컬에서 기본 빌드에 포함되지 않는다. 개발자가 그것을 돌리려면 명시적으로 태스크를 지정해야 한다.
Docker 가 없는 CI 환경에서는 인증 워크플로 자체가 실패한다. 그것이 의도이지만, 인프라 문제와 코드 문제가 같은 빨간불로 보인다.
얻는 것
인증 결과의 초록불이 실제로 브로커가 떠 있었다는 뜻이 된다.
레인이 추가될 때 워크플로를 고칠 필요가 없다. 게이트가 의존성을 갖기 때문이다.
근거
- 아무것도 발견하지 못한 레인은 성공이 아니라 실패여야 한다 이 결정과 같은 원칙의 레인 규약이다.
- 아무도 돌리지 않는 레인의 게이트는 마지막으로 돌린 사람이 본 것을 보고한다 이 결정이 막으려는 상태다.
- 릴리스 게이트가 읽는 증거를 아무도 생산하지 않는다 게이트가 레인에 의존하지 않을 때의 결과를 보여 주는 사례다.