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,58 +0,0 @@
---
-kind: REFERENCE
-slug: digest-must-be-length-framed-and-versioned
-title: digest는 길이 프레이밍하고 버전을 붙인다
-topic: owner-safe-state-machines
-project: clean-architecture-backend-template
-status: 게시 전
-sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
-rootTreeNode: reference:digest-must-be-length-framed-and-versioned
-verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---
-
-# digest는 길이 프레이밍하고 버전을 붙인다
-
-## 목적
-
-다이제스트가 서로 다른 입력에 대해 같은 값을 내거나, 구성이 바뀐 뒤 옛 값과 비교되는 것을 막는다.
-
-## 규칙
-
-1. 무엇을 덮는지가 정책이다
-   다이제스트가 빠뜨린 입력은 두 개의 다른 대상이 같은 값을 낼 수 있는 입력이다. 그 목록은 구현 세부가 아니라 정책이므로 자기 타입을 갖는다.
-
-2. 결과를 덮는다
-   누가 언제 했는지만 덮으면 무엇을 했는지가 다른 두 전이가 같아진다.
-
-3. 길이 프레이밍한다
-   구성 요소가 가변 길이 텍스트이고 그중 하나라도 이 플랫폼이 제약할 수 없는 값이면, 구분자로 이었을 때 서로 다른 목록이 한 문자열로 렌더링될 수 있다.
-
-4. 버전을 붙이고 구성이 바뀌면 올린다
-   저장된 다이제스트가 구성 경계를 넘어 비교되지 않게 한다.
-
-5. 비교 실패를 조용히 처리하지 않는다
-   버전이 다르면 같다고도 다르다고도 결론 내리지 않는다.
-
-## 적용 조건
-
-재생 판정이나 중복 판정에 쓰이는 모든 다이제스트
-
-멱등성 키와 요청 지문
-
-## 예외
-
-캐시 키처럼 충돌이 성능 문제일 뿐 정확성 문제가 아닌 경우는 이 규칙이 과하다.
-
-## 예시
-
-전이 다이제스트가 전이 종류와 연산과 소유자와 시도와 리비전만 덮어, 재시도 가능한 실패와 포기한 실패가 같은 값을 냈다. 서로 다른 응답을 담은 두 완료도 마찬가지였다.
-
-소유자 토큰은 이 플랫폼이 형식을 제약하는 값이 아니므로 길이 프레이밍이 필요하다.
-
-## 관계
-
- **transition digest가 누가와 언제만 덮고 무엇을 덮지 않아 다른 전이를 같다고 보고했다**
-  이 규칙을 만든 사례다.
- **서명된 커서의 구조와 검증 순서**
-  같은 계열의 형식 결정을 다룬다.
-
@@ -1,58 +0,0 @@
---
-kind: REFERENCE
-slug: expired-claim-and-expired-execution-differ
-title: 만료된 claim과 만료된 실행은 다르게 다뤄야 한다
-topic: owner-safe-state-machines
-project: clean-architecture-backend-template
-status: 게시 전
-sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
-rootTreeNode: reference:expired-claim-and-expired-execution-differ
-verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---
-
-# 만료된 claim과 만료된 실행은 다르게 다뤄야 한다
-
-## 목적
-
-리스 만료를 한 가지로 처리해, 실행을 시작했던 소유자의 작업을 두 번 수행하는 것을 막는다.
-
-## 규칙
-
-1. 만료된 청구는 인계한다
-   자리를 잡았지만 아직 아무것도 실행하지 않은 소유자를 밀어내도 외부 효과가 없다.
-
-2. 만료된 실행은 조정으로 넘긴다
-   그 소유자가 무엇을 어디까지 했는지 알 수 없다. 다시 실행하면 그 작업이 두 번 일어날 수 있다.
-
-3. 조정 결과는 별도 값이어야 한다
-   성공이나 실패로 접으면 그 구별이 사라진다. 결과 타입에 세 번째 변형이 필요하다.
-
-4. 해제도 같은 구별을 따른다
-   실행이 시작된 청구는 해제할 수 없다. 해제는 아직 실행하지 않은 청구에만 허용한다.
-
-5. 재시도 가능 실패는 인계 대상이다
-   그 상태는 이미 결과가 확정된 것이므로 새 소유자가 처음부터 시작해도 된다.
-
-## 적용 조건
-
-청구와 실행을 별도 상태로 갖는 모든 상태 기계
-
-멱등성 저장소와 인박스와 아웃박스
-
-## 예외
-
-실행이 외부 효과를 남기지 않는 것이 구조적으로 보장되면 두 상태를 같이 다뤄도 된다. 그 보장을 적어 둔다.
-
-## 예시
-
-청구 결정 트리가 만료된 청구는 재설정하고 만료된 실행은 복구 필요로 답한다. 복구 필요 결과는 시도 번호를 함께 들고 간다.
-
-해제 경로는 이미 실행이 시작된 경우 실행 시작됨으로 답하고 해제하지 않는다.
-
-## 관계
-
- **만료된 CLAIMED는 takeover하고 만료된 EXECUTING은 조정을 요구하도록 갈랐다**
-  이 규칙을 만든 사례다.
- **모르는 것은 성공도 실패도 아닌 세 번째 결과여야 한다**
-  세 번째 규칙이 기대는 상위 규칙이다.
-