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.4 KiB
2.4 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | questionStatus | verifiedOn |
|---|---|---|---|---|---|---|---|---|---|
| QUESTION | a05-f003-capabilitysupport-constraints | CapabilitySupport.constraints 의 경계가 타입에 없다 | multitenancy-isolation | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:a05-f003-capabilitysupport-constraints | OPEN |
CapabilitySupport.constraints 의 경계가 타입에 없다
능력 선언의 제약 목록이 경계가 있다고 서술되지만 십만 자 문자열도 받아들인다. 그 목록은 액추에이터 리포트 모델에 포함된다.
사실
십만 자 제약 문자열이 받아들여진다.
능력 목록은 플랫폼 리포트를 통해 액추에이터 엔드포인트 모델에 포함된다.
현재 출하 조립은 짧은 정적 리터럴만 만든다.
가정
외부나 동적 생산자가 임의 제약을 넣지 않을 것이라고 전제하고 있다. 그 전제를 확인하지 않았다.
미지수
외부나 포크나 동적 생산자가 공개 API 에 임의 제약을 넣는 실제 경로가 있는가.
경계를 타입이 소유해야 하는가 리포트 투영이 소유해야 하는가.
제약
현재 조립에서는 사고가 아니다. 공개 API 불변식의 공백이며, 포크나 동적 조립에서는 경계가 호출자 규율에 의존한다.
선택지
타입 수준 최대 길이나 어휘를 강제한다 공개 API 를 쓰는 모든 생산자에 적용된다.
리포트 투영에서 경계를 건다 공개되는 지점에서만 자른다. 값 자체는 자유롭다.
다음 검증
공개 API 의 외부 생산자와 포크 확장점을 추적하고, 과대 제약에 대한 생성자와 리포트 경계 테스트를 추가한다.
동적이나 외부 생산자가 확인되면 경계를 타입이나 리포트 투영에서 강제하고 이 항목을 Case 로 승격한다.
없다면 공개 불변식과 문서를 현재 조립의 보장 수준으로 좁힌다.
관계
- 진단 리포트가 살아 있는 리소스를 담지 않도록 값 타입을 좁혔다 같은 값 타입의 다른 제약이다.
- 관측을 위해 수집한 데이터가 관측 대상보다 위험할 수 있다 리포트로 공개되는 값의 성질이다.
- 카디널리티 경계를 타입으로 표현하기 경계를 타입에 두는 같은 계열의 개념이다.