---
kind: REFERENCE
slug: messaging-reliability-api-f04
title: 계약만 담는 leaf도 계약의 거절 조건은 자기 레인에서 검증한다
topic: verification-path-coverage
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:messaging-reliability-api-f04
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
source:
  - analysis/messaging/messaging-reliability-api.md#L716
---

# 계약만 담는 leaf도 계약의 거절 조건은 자기 레인에서 검증한다

## 관계

- **inbox 보존 규칙이 문서로만 있다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **포트가 bounded/unbounded purge 두 오버로드를 나란히 노출하고, 호출자가 무제한 쪽을 고른다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **fencing token 경로가 실제 데이터베이스에 대해 실행되지 않는다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.
- **한 인터페이스가 같은 전이의 두 세대를 갖고, 안전하지 않은 쪽에 `@Deprecated`가 없다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.

## 목적

계약 불변식 중 일부는 구현이 우연히 그 조합을 만들지 않으면 한 번도 실행되지 않는다. OutboxCanonicalMetadata 가 schemaUri 있고 schemaSubject 없는 조합을 거절하는 것, OutboxLease 가 token < 1 을 거절하는 것, InboxResult.isSafeToSettle 의 세 값이 그런 것들이다.

## 규칙

1. leaf 에 src/test 가 있는지부터 본다
   messaging-reliability-api 에는 그 디렉터리가 없다. 13개 타입의 record 생성자 검증 여섯과 술어 셋이 이 leaf 의 레인에서 실행되지 않는다.

2. 형제 leaf 의 기준선을 확인한다
   messaging-core-api 79개, messaging-policy 42개다. 계약 leaf 라서 테스트가 없는 것이 아니다.

3. 거절 조건과 술어를 겨냥한 단위 테스트를 둔다
   구현이 지나가는 경로가 아니라 계약이 금지하는 조합을 겨냥한다.

## 적용 조건

타입 선언과 javadoc 만 담는 계약 leaf. 특히 record 생성자가 검증을 갖는 leaf.

## 예외

SSOT 가 이 규칙의 반례를 적지 않았다. 검증이 전혀 없는 순수 인터페이스 leaf 라면 대상이 아니지만, 이 leaf 는 생성자 검증 여섯을 갖는다.

## 예시

ls src/messaging/messaging-reliability-api/src 가 main 만 돌려준다는 것. 원문 근거는 evidence/raw/289 §A 이다.