# ADR-0013: 검증 전략 및 Phase 1 테스트 계획

## Status

Accepted

## Context

KernBench는 시스템 레벨 시뮬레이터이며, 그 정확성은 다음으로 정의된다:

- SPEC에 정의된 불변식 준수,
- 결정성과 디버깅 가능성,
- 라우팅과 레이턴시의 명시적 모델링.

진화하는 구현을 고려할 때, 점진적 개발을 허용하면서도 아키텍처적
편향(drift)을 방지하는 안정적인 검증 전략이 필요하다.

본 ADR은 Phase 1 검증 계획과 초기 구현에 대해 "올바른 동작"이 무엇인지를
정의한다.

---

## Decision

### D1. 검증은 계약 기반이다

검증은 반드시 다음으로부터 도출되어야 한다:

- SPEC 요구사항,
- 채택된 ADR들.

테스트는 부수적인 구현 세부사항이 아니라 아키텍처 계약을 검증해야 한다.

---

### D2. Phase 1 검증 범위

Phase 1 검증은 다음에 초점을 둔다:

- 메시지 계약 유효성 (ADR-0012),
- IO_CPU 경계에서의 라우팅과 팬아웃 시맨틱 (ADR-0009),
- PA-우선 메모리 주소 지정 및 샤드 태깅 (ADR-0011),
- 핵심 레이턴시 및 트레이스 불변식 (SPEC 0.1, R2).

마이크로아키텍처 정확도, 대역폭 경합, 사이클 레벨 동작은 Phase 1의
범위에서 명시적으로 제외된다.

---

### D3. 필수 Phase 1 검증 케이스

다음 검증 케이스는 구현에서 반드시 지원되어야 한다:

#### V1. 메시지 스키마 검증

- 텐서 샤드 중 어느 하나라도 `(sip, cube, pe)`가 누락된 KernelLaunch
  요청은 반드시 거부되어야 한다.
- 목적지/소스 배치 태그가 누락된 MemoryWrite/MemoryRead 요청은 반드시
  거부되어야 한다.
- Completion 결과는 반드시 `ok / error_code / error_message` 계약을
  따라야 한다.

#### V2. IO_CPU 팬아웃과 집계

다음 조건이 주어졌을 때:

- SIP 1개, CUBE 1개, PE 2개로 구성된 토폴로지,
- 서로 다른 PE를 대상으로 하는 두 개의 텐서 샤드를 포함하는
  KernelLaunch 요청,

시스템은 반드시:

- 단일 KernelLaunch를 IO_CPU에 제출하고,
- 내부적으로 두 PE에 작업을 팬아웃하며,
- 완료를 집계하여 호스트에 단일의 결정론적 완료를 반환해야 한다.

#### V3. 레이턴시 및 트레이스 불변식

모든 유효한 요청에 대하여:

- 홉별 트레이스는 반드시 비어 있지 않아야 한다,
- 총 레이턴시는 반드시 0보다 커야 한다,
- 동일한 입력으로 반복 실행 시 반드시 동일한 트레이스를 생성해야 한다.

#### V4. 토폴로지 독립성과 교차 도메인 커버리지

검증 케이스는 다음을 포함한 다양한 토폴로지 형태에서 통과해야 한다:

- 최소: (SIP 1, CUBE 1, PE 1)
- 다중 PE: (SIP 1, CUBE 1, PE N개)
- SIP 내 다중 CUBE: (SIP 1, CUBE M개, CUBE당 PE ≥1)
- 다중 SIP 트레이: (SIP K개, SIP당 CUBE ≥1, CUBE당 PE ≥1)

다중 CUBE 및 다중 SIP 토폴로지에 대해 Phase 1 검증은 다음에 초점을
둔다:

- 명시적 연결성(필요한 링크가 존재함),
- 결정론적 라우팅과 제어 경로 순회,
- 대표적인 교차 도메인 요청(CUBE 간 및 SIP 간 경로)에 대해 비어 있지
  않은 트레이스와 레이턴시 > 0.

테스트는 토폴로지 크기, 노드 ID, 링크 수를 하드코딩해서는 안 된다.
대신 컴파일된 토폴로지 메타데이터로부터 기대값을 도출해야 한다.

---

### D4. Phase 1 산출물

Phase 1은 다음을 포함할 수 있다:

- 검증 전용 테스트 코드,
- 토폴로지 픽스처,
- 트레이스 검사 유틸리티.

Phase 1은 다음을 요구해서는 안 된다:

- 단지 테스트를 만족시키기 위한 프로덕션 코드 변경,
- 진행을 위한 테스트의 약화 또는 제거.

---

### D5. Phase 2 강제

Phase 2(Apply)는 반드시:

- Phase 1 검증 케이스를 실행하고,
- 검증이 실패하면 모든 변경을 롤백하며,
- 테스트를 권위 있는 계약으로 보존해야 한다.

---

## Consequences

- 아키텍처 정확성은 초기에 강제된다.
- 테스트는 시스템 동작의 실행 가능한 문서로 기능한다.
- 구현은 엄정성을 잃지 않으면서도 유연성을 유지한다.

---

## Links

- SPEC 0.1, R2, R6
- ADR-0011 (메모리 주소 지정 — PA / VA / LA)
- ADR-0012 (Host ↔ IO_CPU 메시지 스키마)
- ADR-0009 (커널 실행 시맨틱)