# Tech-Log candidate recall audit — cycle 2

> 대상: `/shared/document-detail/clean-architecture-backend-template` 의 canonical module SSOT **61편**
> 목적: 61개 SSOT 에서 발견된 material semantic unit 이 `candidate-ledger.json` 에서 전부 설명되는지에 대한 coverage proof.
> 판정 기준: verifier 가 인벤토리하는 앵커(`analysis/**/*.md` 의 `P1|P2|P3` 헤딩과 미해결 질문 절의 번호 항목)마다
> `EMITTED | MERGED | REJECTED | BLOCKED` 중 하나가 존재해야 한다. `unaccounted` 는 0 이어야 한다.

## 전체 수치

| 항목 | 값 |
|---|---:|
| canonical module SSOT | 61 / 61 |
| verifier inventory 앵커 | 425 |
| 그중 nested leaf SSOT | 226 |
| §17 explicit finding (61 SSOT) | 392 |
| candidate ledger total | 605 |
| EMITTED | 555 |
| MERGED | 49 |
| REJECTED | 0 |
| BLOCKED | 1 |
| **unaccounted** | **0** |

## 모듈별

| module | explicit findings | CASE | OPEN QUESTION | DECISION | CONCEPT | REFERENCE | MERGED | REJECTED | BLOCKED | unaccounted |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| `adapter-inbound-graphql` | 12 | 9 | 0 | 0 | 0 | 0 | 3 | 0 | 0 | 0 |
| `adapter-inbound-grpc` | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `adapter-inbound-web` | 19 | 16 | 0 | 0 | 0 | 0 | 3 | 0 | 0 | 0 |
| `adapter-inbound-websocket` | 3 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
| `adapter-outbound-cache-redis` | 11 | 7 | 0 | 0 | 0 | 0 | 4 | 0 | 0 | 0 |
| `adapter-outbound-fileserver` | 6 | 4 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| `adapter-outbound-httpclient` | 7 | 6 | 0 | 0 | 0 | 1 | 2 | 0 | 0 | 0 |
| `adapter-outbound-identifier` | 6 | 5 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
| `adapter-outbound-messaging` | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `adapter-outbound-notification` | 11 | 9 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| `adapter-outbound-objectstorage` | 6 | 3 | 0 | 0 | 0 | 0 | 3 | 0 | 0 | 0 |
| `adapter-outbound-persistence-jpa` | 34 | 26 | 1 | 0 | 0 | 0 | 7 | 0 | 0 | 0 |
| `adapter-outbound-persistence-mongo` | 28 | 24 | 0 | 0 | 0 | 0 | 4 | 0 | 0 | 0 |
| `adapter-outbound-support` | 6 | 3 | 1 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| `app-bootstrap` | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `application-core` | 4 | 1 | 2 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| `domain-core` | 2 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
| `grpc-admin` | 4 | 5 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| `grpc-advanced-bootstrap` | 6 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-advanced-compat` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-advanced-diagnostics` | 3 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-advanced-edition` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-advanced-resilience` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-advanced-streaming` | 3 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-client` | 4 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-codegen` | 5 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-core-api` | 6 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-discovery` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-observability` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-operation-ledger-jpa` | 3 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-policy` | 8 | 10 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
| `grpc-proto-contract` | 5 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-server` | 4 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-spring-boot-starter` | 4 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `grpc-testkit` | 6 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `messaging-admin-api` | 9 | 9 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
| `messaging-admin-runtime` | 11 | 12 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-claim-check` | 5 | 2 | 1 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-cloudevents` | 5 | 1 | 1 | 1 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-core-api` | 6 | 4 | 2 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
| `messaging-inbox-jdbc-postgresql` | 6 | 4 | 1 | 0 | 1 | 4 | 0 | 0 | 0 | 0 |
| `messaging-kafka` | 6 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `messaging-kafka-share-experimental` | 6 | 1 | 1 | 0 | 0 | 4 | 0 | 0 | 0 | 0 |
| `messaging-nats-experimental` | 4 | 6 | 0 | 0 | 0 | 3 | 0 | 0 | 0 | 0 |
| `messaging-observability` | 7 | 5 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| `messaging-outbox-jdbc-postgresql` | 8 | 9 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `messaging-policy` | 7 | 3 | 1 | 0 | 0 | 3 | 0 | 0 | 0 | 0 |
| `messaging-pulsar-experimental` | 3 | 4 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-rabbit` | 5 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `messaging-reliability-api` | 8 | 4 | 1 | 0 | 1 | 4 | 0 | 0 | 0 | 0 |
| `messaging-runtime-core` | 7 | 3 | 0 | 0 | 0 | 4 | 0 | 0 | 0 | 0 |
| `messaging-schema-api` | 3 | 1 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-schema-avro` | 5 | 2 | 0 | 0 | 0 | 3 | 0 | 0 | 0 | 0 |
| `messaging-schema-json` | 3 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| `messaging-schema-protobuf` | 4 | 1 | 1 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
| `messaging-security` | 8 | 5 | 1 | 0 | 0 | 5 | 0 | 0 | 0 | 0 |
| `messaging-spring-boot-starter` | 6 | 8 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| `messaging-spring-cloud-stream-bridge` | 6 | 0 | 1 | 0 | 0 | 5 | 0 | 0 | 0 | 0 |
| `messaging-testkit` | 8 | 8 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| `messaging-transport-spi` | 4 | 2 | 0 | 0 | 1 | 4 | 0 | 0 | 0 | 0 |
| `shared-contract` | 5 | 0 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| **합계** | **392** | **313** | **22** | **1** | **6** | **60** | **35** | **0** | **0** | **0** |

## candidate 0건 모듈

없음 — 61개 모듈 전부 최소 1건.

## 분류 근거

kind 는 임의로 정하지 않았다. 우선순위는 다음과 같다.

1. **SSOT 자신의 kind hint.** 다수의 리프 SSOT 가 finding 말미에 `- **다음 단계.** … CASE 후보 / REFERENCE 후보 /
   OPEN QUESTION 후보` 를 적어 둔다. 그 힌트가 있으면 그것을 따랐다(88건). verifier 도 같은 힌트를
   `allowedKinds` 로 강제하므로, 힌트와 어긋난 kind 는 실패로 잡힌다.
2. **힌트가 없으면 finding 의 성격.** 구체적 사건·재현 가능한 결함은 CASE, 재사용 가능한 판단 기준은 REFERENCE,
   현재 근거로 닫을 수 없는 질문은 OPEN QUESTION.
3. **P1/P2/P3 는 kind 를 정하지 않는다.** 우선순위는 candidate 의 `priority` 로만 남는다.

## MERGED 판정 기준

`MERGED` 는 causal unit · semantic unit · verification unit 이 **모두** 같을 때만 썼다. "주제가 비슷하다" 는
근거가 아니다. 예로 `messaging-kafka` 의 트랜잭션 검증기 미배선 · 일시정지 파티션 재개 누락 · 오염된 재시도 헤더의
무한 pause · 트랜잭션 레거시 API 잔존은 전부 독립 노드로 냈다. 같은 리프의 신뢰성 주제라는 것은 병합 근거가 아니다.

## §17 밖 recall

문제 finding 외에 다음 절도 검토 대상이었다 — 모듈 정체와 경계, 계약·불변식, 상태 모델, 성공/실패 메커니즘,
transaction/concurrency/lifecycle, negative-space 결과, "확인된 설계(문제 아님)", 소스 주석에 남은 결함 이력.

여기서 나온 CONCEPT/REFERENCE/DECISION 은 TOPIC 17~22 에 있다(CONCEPT 5 · CASE 17 · REFERENCE 11).
정상 설계에서 뽑은 CONCEPT 의 예 — 능력 선언의 세 출처, 원자 타입 위의 검사 후 실행과 비교 후 교체,
bounded/unbounded 오버로드를 나란히 둔 포트, 8단계 종료 순서 계약, 승인·검증·실행의 분리.

kind 별 quota 는 만들지 않았다. 어떤 모듈에 특정 kind 가 0 인 것은 정상이며, 그 경우 위 표의 해당 칸이 0 으로
남고 그 모듈의 finding 이 전부 다른 kind 로 설명된다는 사실이 같은 행에서 확인된다.

## integration/family 문서

`analysis/19-messaging-platform.md` 의 material finding 6건은 leaf candidate 로 환원되지 않는 cross-leaf 사실이라
별도로 disposition 했다 — EMITTED 5(TOPIC 32 `cross-leaf-integration-facts`), MERGED 1(문서 계약 테스트의
커버리지 경계는 기존 CASE 와 같은 사건·같은 검증 단위).