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.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | questionStatus | verifiedOn |
|---|---|---|---|---|---|---|---|---|---|
| QUESTION | one-boot-would-settle-two-findings | 부팅 한 번으로 확증 가능한 두 건이 아직 정적 추론으로만 남아 있다 | assembly-ownership | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:one-boot-would-settle-two-findings | OPEN |
부팅 한 번으로 확증 가능한 두 건이 아직 정적 추론으로만 남아 있다
관측 no-op 과 outbox 사슬 미조립은 둘 다 정적 도달성으로 판정했다. 브로커 없이 부팅 한 번이면 둘 다 직접 관측된다.
사실
messagingPublisher 빈이 6인자 생성자를 호출하고 그 생성자가 NO_OBSERVATION 을 넘긴다.
관측 방출자 넷의 main 참조가 0 이다.
outbox 와 inbox 저장소 구현의 main 참조가 0 이다.
JdbcOutboxRepository 에 스프링 스테레오타입이 없고 그것을 생성하는 main 코드도 없다.
가정
액추에이터 메트릭 목록이 조립되지 않은 관측을 시리즈 부재로 드러낼 것이라고 전제하고 있다. 다른 경로로 같은 이름의 시리즈가 등록될 가능성은 배제하지 않았다.
미지수
actuator 메트릭에 messaging 으로 시작하는 시리즈가 실제로 없는가.
조건 평가 리포트가 outbox 사슬 미충족을 어떤 사유로 보고하는가.
제약
브로커 없이 부팅해야 한다. 이 확인에 실제 카프카는 필요하지 않다.
애플리케이션 소스를 수정하지 않는다.
선택지
한 번 부팅해 둘을 함께 캡처한다 messaging 을 켜고 브로커를 카프카로 지정하고 debug 를 켜서 부팅한다. 메트릭 목록과 시작 로그의 부정 매치를 한 번에 얻는다.
정적 판정을 유지하고 확인하지 못한 것으로 남긴다 비용은 없지만 두 Case 의 확인하지 못한 것 항목이 계속 남는다.
다음 검증
app.messaging.enabled 를 참으로, app.messaging.broker 를 kafka 로, debug 를 참으로 두고 한 번 부팅한다. 그다음 두 가지를 캡처한다.
액추에이터 메트릭의 시리즈 목록 시작 로그의 부정 매치 중 MessagingReliabilityAutoConfiguration 항목
브로커가 없어도 둘 다 가능하다.
두 관측이 정적 판정과 일치하면 두 Case 의 확인하지 못한 것을 지우고 이 질문을 닫는다.
어긋나면 모듈 분석을 먼저 갱신한다.
관계
- 관측을 필수 생성자 인자로 만든 수정을 조립이 6인자 생성자로 되돌렸다 이 질문이 확증하려는 첫 번째 판정이다.
- outbox가 둘이고, 출하되는 것은 messaging 플랫폼 쪽이 아니다 이 질문이 확증하려는 두 번째 판정이다.