docs(clean-architecture-backend-template): 제1부가 채택한 것만 글감으로 남기고 다시 고른다

글감 1,001개 중 제1부(§3~§11) 앵커를 하나라도 가진 것은 112개뿐이었다. 나머지 889개는 제2부 모듈 분석 65편의 절 제목에서 나온 것이고, 그것이 재판정이 필요했던 이유다. 주제 44 → 16 (43개가 독자 질문 없이 있었다. 지금은 전부 있다) 글감 1,001 → 123 (제1부 앵커 112 + 제1부가 채택했는데 비어 있던 자리 11) 후보 965 → 1,088 · PENDING 905 → 0 error 3,042 → 0 내려온 889개는 후보 대장에 KEEP_IN_SSOT 로 남는다 — 버린 것이 아니라 분석에 남기고 독립 기록으로 만들지 않기로 한 것이다. 그 글감을 받치던 기록 파일 828개는 지웠다. 계약이 정본이고, 파일이 남아 있다는 이유로 계약에서 뺀 주제가 되살아나면 안 된다. 이력에는 그대로 있다 — git checkout a0ca2bb -- <경로>. 제1부가 채택했는데 글감이 없던 자리 열하나를 채웠다: mongo high-water mark 가 재전달 이벤트를 삼킨 P1, admin plane 이 가드만 켜고 서비스는 켜지 않은 것과 그 짝인 결정, 실패 어휘 세 층과 SQLState 매트릭스 병합 규칙, 부하 아래에서만 새는 admission 경계, 발행 증거와 완료 판정의 분리, keyset·JSONB 결정 둘. Concept 17개에 basis-version 을 채우고, 계약 제목과 기록 제목이 갈라져 있던 23건을 기록 쪽에 맞췄다. candidateScope 에 excludedAnchorPattern 을 적어 제2부 앵커만 가진 글감이 다시 올라올 수 없게 한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 15:02:25 +09:00
parent a0ca2bb72a
commit 1f04117bbf
851 changed files with 5498 additions and 90638 deletions
@@ -1,56 +0,0 @@
---
-kind: PROJECT_DECISION
-slug: state-machines-carry-no-stereotype
-title: 상태 기계 구현은 Spring stereotype을 갖지 않는다
-topic: owner-safe-state-machines
-project: clean-architecture-backend-template
-status: 게시 전
-sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
-rootTreeNode: decision:state-machines-carry-no-stereotype
-decisionStatus: ADOPTED
-decidedOn: 2026-08-30
-source:
-  - src/adapter/outbound/persistence-jpa/src/main/java/dev/caskeleton/adapter/outbound/persistence/postgresql/idempotency
-  - src/adapter/outbound/persistence-jpa/src/main/java/dev/caskeleton/adapter/outbound/persistence/config/JpaAdapterComponentsConfig.java
-  - final/document.md#a05
---
-
-# 상태 기계 구현은 Spring stereotype을 갖지 않는다
-
-## 결정문
-
-소유자 안전 상태 기계 구현 클래스에는 컴포넌트 스캔 대상이 되는 애너테이션을 붙이지 않고, 조립은 명시적으로 한다.
-
-## 판단 이유
-
-이 클래스들은 어떤 데이터소스와 어떤 트랜잭션 경계에 묶이는지가 정확해야 한다. 스캔으로 들어오면 그 결정이 스캔 범위와 조건에 흩어진다.
-
-같은 리프에서 그 흩어짐이 실제로 문제가 된 사례가 있다. 활성 트랜잭션 검사가 어느 데이터소스인지를 묻지 않아, 다른 데이터소스의 트랜잭션 안에서 발행된 변경이 이 저장소의 커넥션에 대해 트랜잭션 밖에서 커밋됐다.
-
-명시적 조립은 그 결정을 한 자리에 모은다. 어떤 데이터소스가 어떤 저장소에 들어가는지가 코드로 보인다.
-
-그리고 스캔되지 않으면 조건을 반복할 필요도 없다. 능력이 꺼진 배포에서 이 클래스들이 후보가 되는 일 자체가 없다.
-
-## 영향
-
-감수하는 것
-
-조립 코드를 사람이 써야 한다. 새 상태 기계를 추가하면 조립 지점도 함께 고쳐야 한다.
-
-조립을 잊으면 그 상태 기계가 없는 채로 배포된다. 스캔은 그 실수를 자동으로 막아 주지만 명시 조립은 그렇지 않다.
-
-얻는 것
-
-데이터소스와 트랜잭션 경계가 조립 지점에서 명시된다.
-
-능력이 꺼진 배포에서 이 클래스들이 조건 평가 대상이 되지 않는다.
-
-## 근거
-
- **활성 트랜잭션 검사가 data source를 묻지 않아 다른 커넥션에서 커밋됐다**
-  조립 결정이 흩어졌을 때의 결과다.
- **꺼짐은 조건의 반복이 아니라 구조여야 한다**
-  같은 계열의 조립 원칙이다.
- **Bean 애너테이션이 있다는 것은 조립 증거가 아니다**
-  명시 조립을 확인할 때 쓰는 규칙이다.
-