donghyeon.kang/document-haness
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs(keycloak-session-store): import the session-storage lab as a new project

Browse Source 
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.

Follows the import procedure in README.md.

  source/     the originating repository verbatim — 78 documents, 28 SVGs,
              8 manifests, plus .source-revision recording the commit
  final/      the SSOT
    document.md   729 lines written from the 29 experiment documents, not
                  concatenated: what was predicted, what was measured, and
                  where the measurement itself was wrong
    evidence/raw    125 outputs, flattened to <experiment>__<file> because
                    the originals collided (01-baseline.txt appeared three
                    times) and the audit only globs the top level
    evidence/meta   one per raw file; command and exitCode are null and the
                    README says why rather than inventing them
    evidence/browser  22 captures
    assets/       three diagrams through techviz
    .techviz/     their VizSpecs

A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.

Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.

verify-pipeline.py passes. audit-records.py reports no issues.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
2026-09-04 22:51:59 +09:00
co-authored by Claude Opus 5
parent 43bccd08a8
commit b2963105a8
5017 changed files with 372751 additions and 4943 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/clean-architecture-backend-template/notes/full-read-completion-gate.md
+35
View File
@@ -0,0 +1,35 @@
# Material production FULL_READ completion gate
- reopened at: `2026-08-31T23:30:00+09:00`
- affected leaves: **23**
- reason: behavior-bearing production implementation remained `STRUCTURAL_ONLY` or was explicitly recorded as not fully read.
- COMPLETE rule: behavior-bearing `src/main` implementation must be read and incorporated into the SSOT.
- `STRUCTURAL_ONLY` remains valid only for generated/declarative/non-semantic repetitive artifacts when the ledger records the reason.
- tests may be selectively read when the document explicitly states what was and was not inspected, but tests supporting a material claim must be read at the assertion/fixture path used by that claim.
- downstream order remains: all module SSOTs COMPLETE -> `99-cross-scope` -> `final/document.md` -> candidate ledger/source manifest -> Root Tree.
## Reopened leaves
- `messaging-kafka`
- `messaging-rabbit`
- `messaging-pulsar-experimental`
- `messaging-nats-experimental`
- `messaging-spring-boot-starter`
- `grpc-core-api`
- `grpc-proto-contract`
- `grpc-codegen`
- `grpc-policy`
- `grpc-server`
- `grpc-client`
- `grpc-discovery`
- `grpc-admin`
- `grpc-observability`
- `grpc-operation-ledger-jpa`
- `grpc-spring-boot-starter`
- `grpc-testkit`
- `grpc-advanced-bootstrap`
- `grpc-advanced-edition`
- `grpc-advanced-streaming`
- `grpc-advanced-resilience`
- `grpc-advanced-compat`
- `grpc-advanced-diagnostics`
docs/clean-architecture-backend-template/notes/root-tree-coverage-rebuild.md
+31
View File
@@ -0,0 +1,31 @@
# Root Tree coverage rebuild — 2026-08-31
- pre-rebuild checkpoint: `checkpoints/root-tree-before-recall-gate-20260831.md`
- explicit priority findings: 200
- findings merged to an existing explicit Case: 38
- repeated-analysis duplicate findings merged: 7
- new Case nodes emitted: 155
- baseline ledger entries for pre-existing untargeted nodes: 135
- ledger total: 335
- unmapped: 0
- root-tree nodes after expansion: 324
- root-tree topics after expansion: 25
Merge policy: an existing Topic/Reference or a broad source section is **not** sufficient evidence for merging. Only the same incident/verification unit is merged.
## Kind correction / explicit-question recall
- explicit analysis candidates: 205 (P1/P2/P3 200 + cross-scope unprioritized questions 5)
- reclassified generated findings: 10 (9 Open Question, 1 Reference)
- cross-scope questions: 3 MERGED, 1 BLOCKED by explicit scope exclusion, 1 new Open Question
- root-tree nodes after correction: 325
- ledger candidates after correction: 340
- unmapped: 0
## Completion
- rootTree.status: `COMPLETE`
- coverageStatus: `VERIFIED_COMPLETE`
- analysis queue project: `COMPLETE`
- analysis queue activeProject: `null`
- completion requires final full-workspace verifier pass recorded after this state transition.
docs/clean-architecture-backend-template/notes/ssot-depth-audit.md
+93
View File
@@ -0,0 +1,93 @@
# Module SSOT depth audit
- audit date: 2026-08-31
- source revision: `21234e38cdb9a926cbc92bb97a2aee2e4a7d2916`
- included registered leaves: **61**
- excluded leaves: **1** (`sample-portfolio`)
- cycle 1 canonical analysis files for 61 leaves: **20 unique files**
- structural defect: `analysis/19-messaging-platform.md` was shared by 25 leaves, `analysis/20-grpc-platform.md` by 18 leaves.
- target: **61 distinct canonical module SSOTs**, plus optional family/integration documents.
## 판단
현재 문서 세트는 코드베이스 분석과 Root Tree 후보 추출에는 많은 근거를 제공하지만, **각 registered leaf의 장기 Tech Log SSOT라는 새 요구사항은 충족하지 못한다.** 특히 family 문서 두 개는 개별 leaf 책임·계약·실패 경로·테스트 증명 범위를 독립적으로 재개방하기 어렵다.
문서 길이를 persistence-jpa와 동일하게 맞추지는 않는다. 대신 persistence-jpa가 보여준 다음 성질을 기준으로 한다: 측정 가능한 denominator, 내부 package/sub-scope 지도, contract/invariant, 실제 wiring, success/failure mechanics, test가 증명하는 범위, negative-space probes, history/rationale, findings backlog, limitations, exact source/evidence provenance.
`application-core`는 1,021 source/test 파일을 FULL_READ로 기록했지만 379줄 문서 한 개가 23 top-level package를 압축하고 있어 module SSOT로는 보강이 필요하다. `shared-contract`도 82 FULL_READ에 161줄로 주요 contract를 요약해 두어 같은 이유로 보강 대상으로 둔다. 반대로 `domain-core`처럼 production 7개 수준의 작은 leaf는 200여 줄이어도 충분할 수 있다.
## Cycle 2 review matrix
| leaf | source path | review | cycle-1 document size/coverage | reason |
|---|---|---|---|---|
| `domain-core` | `src/domain-core` | `REVALIDATE_EXISTING_SSOT` | 215 lines; full 10 / structural 3 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `shared-contract` | `src/shared-contract` | `DEEPEN_REQUIRED` | 161 lines; full 82 / structural 4 | 단일 leaf 문서는 있으나 source 규모 대비 설명이 요약형; claim-level 추적/내부 sub-scope 보강 필요 |
| `application-core` | `src/application-core` | `DEEPEN_REQUIRED` | 379 lines; full 1021 / structural 0 | 단일 leaf 문서는 있으나 source 규모 대비 설명이 요약형; claim-level 추적/내부 sub-scope 보강 필요 |
| `adapter-outbound-support` | `src/adapter/outbound/support` | `REVALIDATE_EXISTING_SSOT` | 645 lines; full 8 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-persistence-jpa` | `src/adapter/outbound/persistence-jpa` | `REVALIDATE_EXISTING_SSOT` | 4674 lines; full 605 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-persistence-mongo` | `src/adapter/outbound/persistence-mongo` | `REVALIDATE_EXISTING_SSOT` | 1496 lines; full 497 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-identifier` | `src/adapter/outbound/identifier` | `REVALIDATE_EXISTING_SSOT` | 188 lines; full 10 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-fileserver` | `src/adapter/outbound/fileserver` | `REVALIDATE_EXISTING_SSOT` | 656 lines; full 119 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-objectstorage` | `src/adapter/outbound/objectstorage` | `REVALIDATE_EXISTING_SSOT` | 793 lines; full 206 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-cache-redis` | `src/adapter/outbound/cache-redis` | `REVALIDATE_EXISTING_SSOT` | 933 lines; full 390 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-httpclient` | `src/adapter/outbound/httpclient` | `REVALIDATE_EXISTING_SSOT` | 716 lines; full 370 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-messaging` | `src/adapter/outbound/messaging` | `REVALIDATE_EXISTING_SSOT` | 379 lines; full 69 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-outbound-notification` | `src/adapter/outbound/notification` | `REVALIDATE_EXISTING_SSOT` | 1062 lines; full 240 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-inbound-web` | `src/adapter/inbound/web` | `REVALIDATE_EXISTING_SSOT` | 1702 lines; full 638 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-inbound-grpc` | `src/adapter/inbound/grpc` | `REVALIDATE_EXISTING_SSOT` | 244 lines; full 18 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-inbound-graphql` | `src/adapter/inbound/graphql` | `REVALIDATE_EXISTING_SSOT` | 1122 lines; full 534 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `adapter-inbound-websocket` | `src/adapter/inbound/websocket` | `REVALIDATE_EXISTING_SSOT` | 546 lines; full 253 / structural 0 | 개별 SSOT 존재; cycle 2에서 새 completion gate 기준으로 재검증 |
| `app-bootstrap` | `src/app-bootstrap` | `DEEPEN_REVIEW` | 571 lines; full 455 / structural 0 | 개별 SSOT는 있으나 큰 composition leaf라 cycle 2에서 깊이 재검증 필요 |
| `sample-portfolio` | `src/sample-portfolio` | `EXCLUDED` | - | 사용자 지시(2026-08-30): 샘플 모듈은 분석 대상에서 제외. |
| `messaging-core-api` | `src/messaging/messaging-core-api` | `SPLIT_REQUIRED` | 1284 lines; full 46 / structural 49 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-schema-api` | `src/messaging/messaging-schema-api` | `SPLIT_REQUIRED` | 1284 lines; full 13 / structural 2 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-schema-json` | `src/messaging/messaging-schema-json` | `SPLIT_REQUIRED` | 1284 lines; full 5 / structural 1 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-schema-avro` | `src/messaging/messaging-schema-avro` | `SPLIT_REQUIRED` | 1284 lines; full 5 / structural 3 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-schema-protobuf` | `src/messaging/messaging-schema-protobuf` | `SPLIT_REQUIRED` | 1284 lines; full 5 / structural 1 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-cloudevents` | `src/messaging/messaging-cloudevents` | `SPLIT_REQUIRED` | 1284 lines; full 6 / structural 0 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-policy` | `src/messaging/messaging-policy` | `SPLIT_REQUIRED` | 1284 lines; full 18 / structural 14 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-transport-spi` | `src/messaging/messaging-transport-spi` | `SPLIT_REQUIRED` | 1284 lines; full 19 / structural 0 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-runtime-core` | `src/messaging/messaging-runtime-core` | `SPLIT_REQUIRED` | 1284 lines; full 12 / structural 0 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-observability` | `src/messaging/messaging-observability` | `SPLIT_REQUIRED` | 1284 lines; full 13 / structural 4 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-security` | `src/messaging/messaging-security` | `SPLIT_REQUIRED` | 1284 lines; full 14 / structural 3 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-kafka` | `src/messaging/messaging-kafka` | `SPLIT_REQUIRED` | 1284 lines; full 24 / structural 37 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-kafka-share-experimental` | `src/messaging/messaging-kafka-share-experimental` | `SPLIT_REQUIRED` | 1284 lines; full 5 / structural 2 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-rabbit` | `src/messaging/messaging-rabbit` | `SPLIT_REQUIRED` | 1284 lines; full 18 / structural 15 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-reliability-api` | `src/messaging/messaging-reliability-api` | `SPLIT_REQUIRED` | 1284 lines; full 15 / structural 0 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-outbox-jdbc-postgresql` | `src/messaging/messaging-outbox-jdbc-postgresql` | `SPLIT_REQUIRED` | 1284 lines; full 16 / structural 12 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-inbox-jdbc-postgresql` | `src/messaging/messaging-inbox-jdbc-postgresql` | `SPLIT_REQUIRED` | 1284 lines; full 9 / structural 4 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-claim-check` | `src/messaging/messaging-claim-check` | `SPLIT_REQUIRED` | 1284 lines; full 7 / structural 4 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-admin-api` | `src/messaging/messaging-admin-api` | `SPLIT_REQUIRED` | 1284 lines; full 10 / structural 18 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-admin-runtime` | `src/messaging/messaging-admin-runtime` | `SPLIT_REQUIRED` | 1284 lines; full 8 / structural 12 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-pulsar-experimental` | `src/messaging/messaging-pulsar-experimental` | `SPLIT_REQUIRED` | 1284 lines; full 7 / structural 5 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-nats-experimental` | `src/messaging/messaging-nats-experimental` | `SPLIT_REQUIRED` | 1284 lines; full 6 / structural 5 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-spring-cloud-stream-bridge` | `src/messaging/messaging-spring-cloud-stream-bridge` | `SPLIT_REQUIRED` | 1284 lines; full 7 / structural 3 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-spring-boot-starter` | `src/messaging/messaging-spring-boot-starter` | `SPLIT_REQUIRED` | 1284 lines; full 26 / structural 18 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `messaging-testkit` | `src/messaging/messaging-testkit` | `SPLIT_REQUIRED` | 1284 lines; full 16 / structural 7 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-core-api` | `src/grpc/grpc-core-api` | `SPLIT_REQUIRED` | 716 lines; full 3 / structural 38 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-proto-contract` | `src/grpc/grpc-proto-contract` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 11 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-codegen` | `src/grpc/grpc-codegen` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 16 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-policy` | `src/grpc/grpc-policy` | `SPLIT_REQUIRED` | 716 lines; full 21 / structural 61 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-server` | `src/grpc/grpc-server` | `SPLIT_REQUIRED` | 716 lines; full 2 / structural 22 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-client` | `src/grpc/grpc-client` | `SPLIT_REQUIRED` | 716 lines; full 2 / structural 17 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-discovery` | `src/grpc/grpc-discovery` | `SPLIT_REQUIRED` | 716 lines; full 1 / structural 10 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-admin` | `src/grpc/grpc-admin` | `SPLIT_REQUIRED` | 716 lines; full 1 / structural 18 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-observability` | `src/grpc/grpc-observability` | `SPLIT_REQUIRED` | 716 lines; full 2 / structural 5 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-operation-ledger-jpa` | `src/grpc/grpc-operation-ledger-jpa` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 7 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-spring-boot-starter` | `src/grpc/grpc-spring-boot-starter` | `SPLIT_REQUIRED` | 716 lines; full 3 / structural 5 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-testkit` | `src/grpc/grpc-testkit` | `SPLIT_REQUIRED` | 716 lines; full 4 / structural 32 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-bootstrap` | `src/grpc-advanced/grpc-advanced-bootstrap` | `SPLIT_REQUIRED` | 716 lines; full 1 / structural 12 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-edition` | `src/grpc-advanced/grpc-advanced-edition` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 11 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-streaming` | `src/grpc-advanced/grpc-advanced-streaming` | `SPLIT_REQUIRED` | 716 lines; full 1 / structural 19 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-resilience` | `src/grpc-advanced/grpc-advanced-resilience` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 23 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-compat` | `src/grpc-advanced/grpc-advanced-compat` | `SPLIT_REQUIRED` | 716 lines; full 2 / structural 23 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
| `grpc-advanced-diagnostics` | `src/grpc-advanced/grpc-advanced-diagnostics` | `SPLIT_REQUIRED` | 716 lines; full 0 / structural 8 | family 문서가 여러 registered leaf를 동시에 소유함; 개별 canonical SSOT 필요 |
## Completion rule
1. 각 included leaf는 `state.json.scopes[].analysisFile`이 서로 다른 canonical 문서를 가리킨다.
2. family/platform 문서는 `INTEGRATION_ONLY`이며 leaf SSOT를 대체하지 않는다.
3. 큰 leaf는 canonical 문서 + leaf-owned subdocument로 나눌 수 있다.
4. 각 canonical SSOT는 `deep-analysis-standard.md`의 completion gate를 충족한다.
5. 61개 leaf가 모두 COMPLETE 된 뒤 `99-cross-scope.md` → `final/document.md` → Root Tree를 다시 생성한다.
6. 그 전에는 Tech Log record generation을 금지한다.
docs/clean-architecture-backend-template/notes/tech-log-candidate-recall-audit.md
+128
View File
@@ -0,0 +1,128 @@
# 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 와 같은 사건·같은 검증 단위).
docs/clean-architecture-backend-template/notes/tech-log-concept-recall-audit.md
+124
View File
@@ -0,0 +1,124 @@
# Tech-Log CONCEPT recall audit — cycle 2
> 대상: canonical module SSOT **61편**. 목적은 "이 프로젝트를 이해하려면 알아야 할, 실제로 구현된 메커니즘"을
> CONCEPT 로 회수했는지에 대한 증명이다. `§17 손볼 것` 은 이 pass 의 입력이 아니다 — CONCEPT 는 SSOT 본문의
> 메커니즘 절(모듈 정체·경계, 계약·불변식, 상태 모델, 실행 흐름, 성공/실패, 트랜잭션·동시성·수명주기,
> 설정·활성화, 외부 시스템 상호작용, "확인된 설계(문제 아님)")에서 나온다.
## 방법
1. 61개 SSOT 의 모든 `##`·`###` 헤딩에서 **메커니즘을 이름 짓는 절**만 후보로 남겼다. finding 절(`P1|P2|P3`)과
bookkeeping 절(denominator·완료 조건·coverage ledger·테스트 레인·Source anchors 등)은 제외했다.
2. 상위 절이 이미 같은 메커니즘을 덮는 하위 절은 **MERGED** — 예: `5. idempotency, inbox, outbox` 아래의
`5.1 idempotency`·`5.2 inbox`·`5.3 outbox`.
3. 독립 기록으로 설명할 본문이 부족한 절(정제 후 120자 미만)은 **REJECTED**.
4. quota 는 만들지 않았다. 모듈당 0~60 까지 편차가 있고, 그 편차는 SSOT 의 메커니즘 밀도를 그대로 따른다.
## 전체 수치
| 항목 | 값 |
|---|---:|
| canonical module SSOT | 61 / 61 |
| concept candidate reviewed (메커니즘 절) | **568** |
| EMITTED CONCEPT | **360** |
| MERGED (상위 메커니즘에 흡수) | **138** |
| REJECTED (본문 부족) | **70** |
| 이번 pass 이전 CONCEPT | 26 |
| 최종 CONCEPT | **386** |
| CONCEPT 0건 모듈 | 5 |
## 모듈별
| module | concept candidates reviewed | emitted CONCEPT | merged | rejected | reason / mechanism summary |
|---|---:|---:|---:|---:|---|
| `adapter-inbound-graphql` | 16 | 13 | 0 | 3 | (8.2) 조건 형제 비교 — off 계약의 두 절반 · (8.2) 조건 형제 비교 — 스키마 해시의 생산자와 소비자 · (8.2) 조건 형제 비교 — 연산 정체성을 정하는 두 구현 … |
| `adapter-inbound-grpc` | 1 | 1 | 0 | 0 | (8.3) 중복 메커니즘 — 인증과 예외 처리의 인터셉터 순서 |
| `adapter-inbound-web` | 24 | 19 | 0 | 5 | (8.2) 조건 형제 비교 — 두 자동설정의 게이트 · (8.4) 문서/구현 드리프트 — 모듈 경계 선언과 실제 트리 · (8.1) 도달성 — 신원 모델의 프로덕션 참조 수 … |
| `adapter-inbound-websocket` | 7 | 5 | 0 | 2 | 이 모듈의 형태 — 하나의 leaf, 세 개의 설정 네임스페이 · (8.1) 도달성 — 정책의 실제 적용 지점 · (8.4) 카운트 — `WebSocketFailureCateg … |
| `adapter-outbound-cache-redis` | 13 | 13 | 0 | 0 | 조립의 순서가 클래스 하나에 고정돼 있다 · Confirmed — raw allowlist 기본값은 없는 · Confirmed — "설계상 부재" 주장 6건이 구현·정책 … |
| `adapter-outbound-fileserver` | 8 | 8 | 0 | 0 | Confirmed — 적재 경로는 auto-configurat · Confirmed — codec이 "canonical"을 왕복 · Confirmed — 상태 전이가 인접 행렬이고 termina … |
| `adapter-outbound-httpclient` | 10 | 9 | 1 | 0 | `ClientProfileValidator` — 34개 위반 · `ClientRuntimeRegistry` — 세대 교체가 틈 · `ObjectBody`의 재생 가능성 판정 — 값의 성질이지 … |
| `adapter-outbound-identifier` | 0 | 0 | 0 | 0 | SSOT 본문이 전부 finding 절이다. 유일한 정상 설계 절(가명화기)은 독립 기록으로 낼 만큼의 메커니즘 서술이 없고 키 취급 규칙은 이미 REFERENCE 로 존재한다. |
| `adapter-outbound-messaging` | 4 | 4 | 0 | 0 | 레지스트리가 "닫혀 있다"는 것의 의미 · 봉투 작성이 파서를 거치지 않는다 · 계약이 컴파일되어 닫힌다 … |
| `adapter-outbound-notification` | 10 | 6 | 0 | 4 | "이름 없는 상태"를 없애는 것이 이 sub-scope의 주제 · (8.3) 중복 메커니즘 — 종료 경로 · (8.1) 도달성 — provider가 준 `Retry-Aft … |
| `adapter-outbound-objectstorage` | 9 | 9 | 0 | 0 | Confirmed — "컴파일이 먼저, 생성은 나중"이 실제 · Confirmed — legacy가 세 겹으로 격리돼 있다 · Confirmed — 후보로 본 unguarded split은 … |
| `adapter-outbound-persistence-jpa` | 82 | 58 | 22 | 2 | Sub-scope 02 — API contracts (`api · Capability API — 실행 기능과 지원 등급을 rep · Error API — provider exception을 st … |
| `adapter-outbound-persistence-mongo` | 9 | 9 | 0 | 0 | opt-in은 네 겹이고, 각 겹이 서로 다른 실패를 막는다 · mapping의 나머지는 manifest를 실제로 강제한다 · 실행 scope의 고정된 순서가 이 sub-scope의 중심이 … |
| `adapter-outbound-support` | 9 | 6 | 2 | 1 | 모듈의 정체와 경계 · `FailOpenDependencyLogger`: 진단을 bu · global masking도 이 보장을 복구하지 않는다 … |
| `app-bootstrap` | 7 | 5 | 0 | 2 | (8.3) 중복 메커니즘 — 세 개의 환경 검증기 · — 다섯 어댑터 범위는 런타임 멤버십 레지스트리와 일치한다 ( · (8.4) 카운트 — `.imports` 여섯 줄과 다섯 능력 … |
| `application-core` | 17 | 11 | 6 | 0 | 모듈 경계와 빌드 의존성 · authorization: permission과 object · transaction: framework vocabulary … |
| `domain-core` | 3 | 3 | 0 | 0 | 관찰: 재사용 가능한 도메인 “내용”보다 도메인 모델링 계약을 · Runtime reachability / wiring · Success / failure mechanics |
| `grpc-admin` | 4 | 2 | 0 | 2 | 건강 레지스트리 — 낙관에서 시작하지 않는다 · 배수 순서 |
| `grpc-advanced-bootstrap` | 4 | 3 | 0 | 1 | 능력 15종과 등급 4종 · 게이트가 세 조건을 순서대로 본다 · 승격 게이트 |
| `grpc-advanced-compat` | 2 | 0 | 0 | 2 | 두 절 모두 '무엇을 거절하는가'로 finding 성격이고 독립 메커니즘 서술이 아니다. |
| `grpc-advanced-diagnostics` | 5 | 2 | 0 | 3 | 모듈의 정체 · 두 겹의 게이트 |
| `grpc-advanced-edition` | 1 | 0 | 0 | 1 | 메커니즘 절이 '모듈의 정체' 하나이고, 두 레인의 성격은 `concept:three-sources-of-a-capability-answer` 와 승격 게이트 노드가 덮는다. |
| `grpc-advanced-resilience` | 3 | 2 | 0 | 1 | 헤징 예산 · xDS 시작 가드 |
| `grpc-advanced-streaming` | 2 | 1 | 0 | 1 | 수동 흐름 제어 |
| `grpc-client` | 2 | 0 | 0 | 2 | '세대와 배수' 절이 있으나 본문이 짧다. 그 메커니즘은 `concept:check-then-act-on-atomic-types` 가 가족 수준에서 덮는다. |
| `grpc-codegen` | 4 | 1 | 0 | 3 | 소비자 컴파일 게이트 |
| `grpc-core-api` | 2 | 1 | 0 | 1 | Stable 모듈 목록과 불변식 |
| `grpc-discovery` | 3 | 1 | 0 | 2 | 생성자가 거부하는 것과 검증기가 보고하는 것 |
| `grpc-observability` | 4 | 3 | 1 | 0 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식 |
| `grpc-operation-ledger-jpa` | 4 | 3 | 0 | 1 | 스키마가 계약이다 · 저장 키와 유니크 제약이 같은 행을 가리킨다 · 상태 전이 |
| `grpc-policy` | 4 | 1 | 0 | 3 | 재개 토큰 — 서명하고, 구분자를 봉인한다 |
| `grpc-proto-contract` | 1 | 0 | 0 | 1 | 메커니즘 절이 '모듈의 정체' 하나뿐이고 본문이 짧다. 이 리프의 실제 메커니즘(규칙 엔진과 게이트)은 TOPIC 3·17 의 CONCEPT 와 CASE 가 이미 덮는다. |
| `grpc-server` | 5 | 1 | 0 | 4 | 인터셉터 순서 계약 |
| `grpc-spring-boot-starter` | 2 | 2 | 0 | 0 | 모듈의 정체와 격리 규칙 · 검증기가 담은 규칙 |
| `grpc-testkit` | 2 | 1 | 0 | 1 | 릴리스 게이트 — 문서가 후속이 아니라 차단 사유다 |
| `messaging-admin-api` | 13 | 7 | 5 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-admin-runtime` | 12 | 7 | 4 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-claim-check` | 11 | 7 | 3 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-cloudevents` | 13 | 8 | 5 | 0 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 패키지/컴포넌트 지도 … |
| `messaging-core-api` | 23 | 8 | 15 | 0 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 패키지/컴포넌트 지도 … |
| `messaging-inbox-jdbc-postgresql` | 15 | 7 | 7 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-kafka` | 4 | 2 | 0 | 2 | 소비자 런타임 — 스레드 규율이 설계다 · 커밋은 연속 워터마크로만 전진한다 |
| `messaging-kafka-share-experimental` | 12 | 7 | 4 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-nats-experimental` | 2 | 2 | 0 | 0 | 능력 선언 · 프로파일이 스스로 거부하는 것 |
| `messaging-observability` | 12 | 7 | 4 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-outbox-jdbc-postgresql` | 13 | 6 | 5 | 2 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-policy` | 16 | 9 | 6 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-pulsar-experimental` | 2 | 1 | 0 | 1 | 실패 분류 — 타입 있는 신호만 본다 |
| `messaging-rabbit` | 2 | 2 | 0 | 0 | 소비·정착·죽은 편지의 세 규율 · 자격증명은 연결 시도마다 해석된다 |
| `messaging-reliability-api` | 16 | 7 | 8 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-runtime-core` | 16 | 7 | 8 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-schema-api` | 14 | 7 | 6 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-schema-avro` | 12 | 7 | 4 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-schema-json` | 11 | 7 | 3 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-schema-protobuf` | 9 | 7 | 1 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-security` | 14 | 7 | 6 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-spring-boot-starter` | 3 | 3 | 0 | 0 | 선택은 닫힌 레지스트리이고, 등록과 조립은 다르다 · 설정이 프로파일이 된다 · 종료 순서가 두 수명 주기의 phase 로 표현된다 |
| `messaging-spring-cloud-stream-bridge` | 14 | 6 | 6 | 2 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `messaging-testkit` | 9 | 8 | 1 | 0 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 패키지/컴포넌트 지도 … |
| `messaging-transport-spi` | 13 | 7 | 5 | 1 | 모듈의 정체와 경계 · 의존성과 런타임 배선 · 계약·불변식·상태 모델 … |
| `shared-contract` | 4 | 4 | 0 | 0 | 주요 계약과 불변식 · Permission · Activation and health snapshot … |
| **합계** | **568** | **360** | **138** | **70** | |
## CONCEPT 0건 모듈과 사유
- `adapter-outbound-identifier` — SSOT 본문이 전부 finding 절이다. 유일한 정상 설계 절(가명화기)은 독립 기록으로 낼 만큼의 메커니즘 서술이 없고 키 취급 규칙은 이미 REFERENCE 로 존재한다.
- `grpc-advanced-compat` — 두 절 모두 '무엇을 거절하는가'로 finding 성격이고 독립 메커니즘 서술이 아니다.
- `grpc-advanced-edition` — 메커니즘 절이 '모듈의 정체' 하나이고, 두 레인의 성격은 `concept:three-sources-of-a-capability-answer` 와 승격 게이트 노드가 덮는다.
- `grpc-client` — '세대와 배수' 절이 있으나 본문이 짧다. 그 메커니즘은 `concept:check-then-act-on-atomic-types` 가 가족 수준에서 덮는다.
- `grpc-proto-contract` — 메커니즘 절이 '모듈의 정체' 하나뿐이고 본문이 짧다. 이 리프의 실제 메커니즘(규칙 엔진과 게이트)은 TOPIC 3·17 의 CONCEPT 와 CASE 가 이미 덮는다.
## CONCEPT 와 REFERENCE 를 쌍으로 둔 자리
같은 source 에서 둘 다 나올 수 있다. 이 pass 는 그 둘을 대체 관계로 쓰지 않았다.
| source 메커니즘 | CONCEPT | REFERENCE |
|---|---|---|
| Kafka 연속 워터마크 커밋 | 커밋은 연속 워터마크로만 전진한다 | 완료된 offset 사이에 gap 이 있으면 commit position 을 넘기지 않는다 |
| 자격증명 회전 | 준비 후 교체 후 배수 | 공유 런타임 교체는 준비 → 원자 교체 → 이전 세대 drain 순서로 한다 |
| 원자 타입 위의 갱신 | 검사 후 실행과 비교 후 교체 루프 | `Atomic*` 타입의 존재는 원자성의 증거가 아니다 |
| bounded/unbounded 오버로드 | 두 형태를 나란히 둔 포트 | 두 형태를 나란히 내놓는 포트는 이미 안전하지 않은 쪽을 고른 것이다 |
| 8단계 종료 계약 | 선언된 순서와 실제 종료 경로 | 선언 순서를 단언하는 테스트는 그 순서를 읽는 코드가 있을 때만 게이트다 |
## REFERENCE semantic audit 결과
REFERENCE 105건을 전수 검토했다. 규칙 형태(rule · purpose · scope · exceptions)를 갖추지 못하고
**관측 문장**으로 남아 있던 41건을 다시 썼다. 그 41건의 규칙 문장은 대부분 SSOT 자신이 괄호로 적어 둔 것이고
(40/41), 나머지 1건은 cycle 1 의 규칙이라 누락된 scope·exceptions 만 채웠다.
재작성 후 105 / 105 가 rule-shaped 다. 구체 사건은 규칙 기록에 섞지 않고 `source` 의 finding 이 소유한다.