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.3 KiB
2.3 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | a-publicly-readable-state-must-be-complete-by-constraint | 공개 읽기 가능한 상태는 완전한 identity를 DB 제약으로 요구한다 | fileserver-state-and-fencing | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:a-publicly-readable-state-must-be-complete-by-constraint |
공개 읽기 가능한 상태는 완전한 identity를 DB 제약으로 요구한다
목적
공개 상태에 도달한 레코드가 필수 값을 빠뜨린 채 존재해, 그 값을 전제한 코드가 나중에 실패하는 것을 막는다.
규칙
-
공개 상태의 요구를 데이터베이스 제약으로 표현한다 애플리케이션 검사로 두면 그 검사를 지나지 않는 경로가 언젠가 생긴다.
-
상태별로 다른 요구를 조건부 제약으로 쓴다 모든 상태에 같은 요구를 걸면 중간 상태를 만들 수 없다.
-
상태와 버전을 함께 가드한다 상태만 조건에 넣으면 같은 상태에서 출발한 두 전이가 모두 성공한다.
-
진실의 출처를 하나로 정한다 파일시스템에 바이트가 있다는 것과 공개 가능하다는 것은 다른 사실이다. 어느 쪽이 정본인지 정하고 그것을 문서에 적는다.
적용 조건
외부에 노출되는 상태를 갖는 모든 레코드
파일이나 객체처럼 저장소와 메타데이터가 따로 있는 자원
예외
내부 처리 단계의 중간 상태는 완전성을 요구하지 않는다. 그 상태가 외부로 새지 않는 것이 보장되어야 한다.
예시
파일 메타데이터의 헤더가 관계형 레코드가 공개 가능 여부를 정한다고 명시하고, 모든 상태 전이가 상태와 버전 양쪽으로 가드된다고 적는다.
관계
- 파일 상태 기계와 READY가 뜻하는 것 이 규칙이 나온 개념이다.
- CAS 튜플을 where 절에 전부 반복하고 update count를 답으로 쓴다 세 번째 규칙의 일반형이다.
- 위험한 조합은 정책이 아니라 생성자가 거부하게 만든다 같은 원칙의 값 타입 판이다.