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 | analysis-finding-a02-f005 | messaging schema qualification boundary | multitenancy-isolation | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:analysis-finding-a02-f005 | OPEN |
messaging schema qualification boundary
현재 검사는 JDK 만으로 자원과 다이제스트와 선택된 의미 벡터를 검증한다. 실제 JSON 스키마 검증기와의 호환성은 그 검사만으로 주장할 수 없다.
사실
현재 테스트는 JDK 만 쓴다. 정확한 자원과 다이제스트와 선택된 의미 벡터를 검증한다.
그 테스트는 통과한다.
가정
JDK 만으로 만든 의미 벡터가 실제 검증기의 해석과 같을 것이라고 전제하고 있다. 그 전제가 확인되지 않았다.
미지수
채택할 검증기가 커밋된 스키마와 긍정 부정 벡터를 동일하게 해석하는가.
제약
검증기를 테스트 클래스패스에 추가하면 이 리프의 의존이 늘어난다. 프레임워크 없는 계약 리프를 유지하려는 방침과 충돌할 수 있다.
선택지
별도 소스셋이나 레인에서 실제 검증기로 실행한다 리프의 기본 의존을 늘리지 않으면서 증거를 만든다.
현재 상태를 유지하고 표현을 좁힌다 JDK 만으로 확인한 것이 무엇인지 문서에 적고 호환성 주장을 하지 않는다.
다음 검증
채택할 검증기로 커밋된 스키마와 긍정 부정 벡터를 실행하고 결과를 증거로 남긴다.
실제 검증기가 동일한 의미 벡터를 통과해야 호환성을 주장한다.
실패하면 스키마나 지원 범위를 수정하고 JDK 전용 게이트의 표현을 좁힌다.
관계
- 문서와 상수가 서로 일치하는 것으로는 아무것도 증명되지 않는다 이 질문이 다루는 증거의 성질이다.
- 능력 등급은 코드가 아니라 실행된 증거에서 파생한다 호환성 주장에 증거가 필요한 이유다.