UI 계약 설계 ​

UI 계약은 소비자가 실제로 쓰는 public export 구조에서 시작합니다. 이름이 비슷하다는 이유만으로 인터페이스가 호환된다고 판단하지 않습니다.

설계 순서 ​

1. 소비자가 필요한 함수·객체·팩터리와 실행 환경을 정합니다.
2. 기존 public export 규칙과 base expect 조합을 대조합니다.
3. UI 패턴 검색으로 유사한 선언을 찾습니다.
4. 동일 버전의 실제 export 경로와 소비 코드를 확인합니다.
5. 적합·부분 재사용·부적합·근거 미확인을 구분해 기록합니다.
6. 맞는 규칙이 없으면 필요한 조합이나 규칙을 직접 정의합니다.

세 가지 정보를 구별하세요 ​

구분	기록할 정보
public export 규칙	구조·멤버·입력/반환·동작·환경·생명주기
base expect	목적과 규칙 조합·사용 시점·제공 단위
실제 계약	토큰·scope·owner·수량·패키지/버전·export 경로

객체의 두 멤버가 같은 제공자에서 나와야 하는지, 상태를 어디에서 생성하고 종료하는지도 명시합니다. 웹 SSR과 RN의 반환 타입을 같은 것으로 취급하지 않습니다.

현재 검색의 범위 ​

카탈로그는 계약 이름·설명·선언 사례를 검색합니다. 서버는 public export 구조나 base expect 조합을 구조적으로 검색하지 않으며, 런타임도 named export 멤버 형태를 자동 검증하지 않습니다.

DB 계열의 expect와 UI public export 규칙은 각 소비 목적에 맞게 관리합니다. api: 접두사만으로 DB/UI 분류를 결정하지 않습니다.