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>
5.0 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a18-f001 | 출하되는 web 어댑터의 스위치가 활성화 모델 밖에 있다 | composition-root-and-bootstrap | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a18-f001 | 2026-09-01 |
|
|
|
출하되는 web 어댑터의 스위치가 활성화 모델 밖에 있다
이 어댑터는 두 런타임의 구성원이라 빌드 전용 예외가 아니다. 그런데 네 스위치가 조건 안의 문자열 리터럴로만 존재해 마스터 스위치 자바독이 경계하는 상태다. 다만 이 어댑터는 성질이 달라 그 모델에 그대로 넣을 수 없다.
관계
- 이 leaf의 리액티브 절반 29개 파일은 어떤 출하 배포에서도 활성화될 수 없다 같은 어댑터의 조립 미해결 사례다.
- 능력 프로퍼티 이름을 만드는 코드와 실제 게이트가 다른 접두사를 쓴다 같은 계열의 스위치 이름 사례다.
- 무엇을 스위치로 부를지 정하기 전에는 활성화 모델에 넣을 수 없다 이 사례가 그 규칙의 형태다.
문제
이 조립 루트는 선택 어댑터의 활성화를 명시적 스위치 모델로 다룬다.
전부 기본 꺼짐이고, 환경 키 파일에 행이 있고, 삼자 일치 테스트가 강제한다.
웹 어댑터가 그 모델 안에 있는지 확인했다.
결론
밖에 있다.
이 어댑터는 두 런타임의 구성원이므로 빌드 전용 예외에 해당하지 않는다.
그런데 그 네 스위치가 조건 안의 문자열 리터럴로만 존재한다.
마스터 스위치의 자바독이 경계하는 상태다. 조건 곳곳에 문자열 리터럴로 흩어지면 이름 변경이 조용한 활성화 변경이 된다는 것이다.
다만 이 어댑터는 다른 넷과 성질이 다르다.
두 전송 스위치가 없으면 참으로 처리되도록 되어 있어 기본이 켜짐이다. 그러므로 선택 어댑터가 아니다.
마스터 스위치가 규정하는 명시적 스위치 모델에 그대로 넣을 수 없다.
그리고 그 어댑터의 조립 자체가 미해결이다. 훑기에서 다섯 패키지를 빼고 넘겨받는 자동 설정을 만들지 않은 상태다.
기록하는 것은 순서다.
이 어댑터의 스위치를 활성화 모델에 넣는 것은 어떤 자동 설정이 무엇을 소유하는가를 먼저 정한 뒤에 할 수 있는 일이다.
지금은 무엇을 스위치로 부를지가 결정되지 않았다.
판정은 P3 다.
검증 환경
Spring Boot : 4.0.8 확인 방식 : 스위치 선언 위치 확인과 활성화 모델 대조 소스 수정 : x
재현 조건
원문은 final/evidence/raw/188 계열에 있다.
- 활성화 모델의 규칙 셋을 확인한다.
- 이 어댑터의 런타임 구성원 목록을 확인한다.
- 네 스위치가 어디에 선언되어 있는지 확인한다.
- 두 전송 스위치의 기본값을 확인한다.
- 마스터 스위치 자바독의 경계 문장을 읽는다.
본문
adapter-inbound-web은 두 런타임 멤버이므로 build-only 예외에 해당하지 않는다(§4.1).
MasterSwitch 참조 위치
:::evidence key="analysis-finding-a18-f001" alt="코드베이스에서 MasterSwitch 를 검색한 출력 17줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="MasterSwitch 코드베이스 검색 — 17줄 · exit 0" zoom="true" :::
네 스위치가 문자열 리터럴로만 존재한다
backend.web.mvc.enabled · backend.web.webflux.enabled(둘 다 matchIfMissing=true, 기본 켜짐) · backend.web.budgets.enabled · app.web-platform.durable-operations.enabled가 MasterSwitch에도 env-keys.yaml 341개 키에도 없다. MasterSwitch의 javadoc이 경계하는 상태다 — "Spread across conditions as string literals, a rename becomes a silent activation change."
다만 web은 다른 넷과 성질이 다르다
MVC/WebFlux 스위치는 matchIfMissing = true로 기본 켜짐이므로 "옵션 어댑터"가 아니고, MasterSwitch가 규정하는 explicit switch 모델(전부 기본 꺼짐, env-keys.yaml에 행이 있고 삼자 일치 테스트가 강제)에 그대로 넣을 수 없다. 그리고 모듈 14 §8.1이 확인했듯 web의 조립 자체가 미해결이다.
기록하는 것은 순서다
web의 스위치를 활성화 모델에 넣는 것은 모듈 14 §8.1(어떤 자동설정이 무엇을 소유하는가)을 먼저 정한 뒤에 할 수 있는 일이다. 지금은 "무엇을 스위치로 부를지"가 결정되지 않았다. P3.
확인하지 못한 것
스위치 이름을 바꿔 조용한 활성화 변경이 일어나는지 재현하지 않았다.