DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2.1 KiB
2.1 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| REFERENCE | messaging-kafka-share-experimental-f04 | 구성 오류는 한 예외 타입과 안정 코드로 보고한다 | runtime-contract-correctness | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:messaging-kafka-share-experimental-f04 |
|
구성 오류는 한 예외 타입과 안정 코드로 보고한다
관계
- "등록"이 아무것도 등록하지 않고 성공을 반환한다 이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
목적
같은 시작 시점에 같은 종류의 설정 오류를 거절하면서 한쪽만 FailureDescriptor 를 갖게 되면, 운영자가 받는 두 실패 중 하나에만 코드와 카테고리가 붙는다.
규칙
-
같은 검증기 안의 거절들이 같은 예외 타입인지 본다 KafkaShareProfileValidator.java:31-40 에서 !enabled 는 MessagingCapabilityUnavailableException(안정 코드 KAFKA_SHARE_DISABLED)이고, orderingScope != NONE 은 IllegalArgumentException(코드 없음)이다.
-
안정 코드가 없는 거절을 찾아 코드를 준다 코드가 없으면 그 실패는 문자열로만 식별된다.
-
같은 가족 안에서 갈라진 사례를 함께 본다 messaging-security 의 MessageSecurityValidator 는 전부 IllegalArgumentException 이고 BrokerTlsPolicy 는 전부 MessagingConfigurationException 이다. 같은 형태의 분기가 이미 두 곳에 있다.
적용 조건
시작 시점에 설정을 거절하는 검증기 전부. 특히 한 클래스가 여러 규칙을 검사하는 자리.
예외
플랫폼 예외 계층이 닿지 않는 프레임워크 경계에서는 표준 예외가 불가피할 수 있다. 이 검증기는 그 경계가 아니다.
예시
KafkaShareProfileValidator.java:31-40 의 두 throw 문. 확인 방법은 그 둘을 나란히 대조하는 것이다.