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.5 KiB
2.5 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | runtime-membership-decides-severity | runtime_memberships를 먼저 읽고 심각도를 정한다 | self-disclosure-grading | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:runtime-membership-decides-severity |
runtime_memberships를 먼저 읽고 심각도를 정한다
목적
같은 형태의 결함에 같은 심각도를 매겨, 배포되지 않는 코드의 문제와 지금 도는 코드의 문제를 구별하지 못하는 것을 막는다.
규칙
-
레지스트리를 먼저 읽는다 그 리프가 어떤 런타임 컴포지션에 속하는지가 첫 질문이다.
-
멤버십이 비어 있으면 오늘의 사고가 아니다 배포되지 않는 코드의 미조립은 프로덕션 영향이 0 이다.
-
그렇다고 기록하지 않는 것은 아니다 배선되는 날 한꺼번에 오늘의 사고가 된다. 그날의 목록이 지금 있어야 한다.
-
배포되지 않는 상태가 테스트로 고정되어 있는지 확인한다 규약으로만 지켜지면 실수로 배선될 수 있다.
-
문서가 그 상태를 공시하는지 확인한다 레지스트리가 비어 있는데 지원 매트릭스가 그 능력을 싣고 있으면, 심각도 판정과 문서가 어긋난다.
적용 조건
발견의 심각도를 매기는 모든 분석
플랫폼 가족처럼 배포 여부가 리프마다 다른 구조
예외
보안 결함은 배포되지 않아도 기록 우선순위가 높을 수 있다. 배선 시점에 그것이 함께 배포되기 때문이다.
예시
웹소켓 어댑터의 런타임 멤버십이 비어 있고, 조건부 전송 조립 계약 테스트의 빌드 전용 목록이 그 사실을 고정한다.
gRPC 가족 18개 리프 전부의 멤버십이 비어 있고, 호환성 문서가 출시되지 않았다고 공시한다.
같은 형태의 미조립이라도 messaging 쪽은 출하 아티팩트에 실리므로 심각도가 다르다.
관계
- build-only 등급이 90개 파일의 미조립을 오늘의 사고에서 면제한다 이 규칙을 만든 사례다.
- gRPC 플랫폼은 build-only로 두고 애플리케이션 도달 경로를 먼저 정한다 이 규칙이 결정으로 표현된 사례다.
- Bean 애너테이션이 있다는 것은 조립 증거가 아니다 같은 계열의 확인 규칙이다.