INDEX — develop/MVP1/interfaces/

계약을 어떻게 쓰는가를 담는다. 스키마 본문은 여기 없다 — 값과 필드의 정본은 ../contracts/의 OpenAPI·AsyncAPI 파일이고, 이 폴더는 그 파일들을 가로질러 읽어야 알 수 있는 규칙만 소유한다.

갱신일 2026-07-26 · 기준: ai@60ee59a · server@bf192cc · web@87e0834 + ../contracts/ 5개 파일

파일	무엇	이럴 때 읽는다
common-conventions.md	세 서비스가 다 지켜야 하는 것 — 버전·경로·식별자(TSID와 그 예외)·인증·오류·멱등성·비밀정보·시간과 SSE 종료	새 엔드포인트·이벤트를 설계할 때 먼저. "이 값 형식이 뭐지"
server-web.md	web ↔ server 경계 — REST·STOMP·SSE 세 프로토콜의 방향과 선택 기준, web 생성물(orval) 경계	web이 무엇을 생성하고 무엇을 수기로 쓰는지 / 어느 프로토콜에 무엇을 얹을지
server-ai.md	server ↔ ai 경계 — 분석 202+callback, 채팅 SSE passthrough, 컨텍스트 pull, 인증 비대칭	분석·채팅 요청이 내부에서 어떻게 도는지 / 왜 한 방향만 인증하는지
api-registry.md	계약 파일 5개의 owner·source·mirror·status·검증·소비자 표	계약을 고치기 전에 항상 — 어느 파일이 원본이고 어디를 고쳐야 하는지
INDEX.md	이 파일	—

읽는 순서

계약을 처음 만진다        → api-registry.md (어디를 고치나) → common-conventions.md (무엇을 지키나)
경계 하나만 파고든다      → server-web.md 또는 server-ai.md
필드·값이 궁금하다        → ../contracts/ 의 해당 yml
흐름 전체가 궁금하다      → server-ai.md §1 분석 · §2 채팅 (내부 구간) → server-web.md (브라우저 구간)

여기 없는 것

찾는 것	어디로
스키마·필드·enum 값 (정본)	../contracts/
3-서비스 전체 그림·서비스 책임	../../MVP1/README.md
데이터 소유권·인프라·배포 형상	../architecture/
채팅 루프의 시퀀스와 경계 규칙 원문	../contracts/agent-chat-flow.md
각 서비스 내부 구조	ai/ · server/ · web/
계약 설계의 근거 (3-서비스 구조)	MVP1/architecture/system-architecture.md
알려진 불일치 원장	pm/2-product/open-issues.md

---

인덱스 갱신 의무 — 이 폴더의 문서를 추가·이동·삭제·개명하면 같은 커밋에서 위 표를 고친다. 상위 폴더 INDEX의 항목 수·설명도 함께 본다. 규칙: AGENTS.md