스키마로 검사하는 AI 제공업체·모델 카탈로그에 항목 추가하기

## 마치기 전에 저장소 자체의 검증·빌드 명령 실행하기 카탈로그 데이터를 변경하기 전에 저장소에 문서화된 검증, 빌드, 개발 명령을 확인하세요. 영향을 받는 작업 공간에 맞는 패키지별 명령과 프로젝트에서 이미 선택한 런타임을 사용하세요. - 카탈로그 변경을 완료된 것으로 간주하기 전에 표준 구성 검증기를 실행하세요. - 작업에 빌드가 필요할 때만 영향을 받는 인터페이스나 패키지를 빌드하세요. - 저장소에 전용 테스트 프레임워크가 없다면 테스트 명령을 임의로 만들지 말고, 저장소가 실제로 제공하는 검증 및 빌드 절차를 사용하세요. - 작업에서 명시적으로 요구하지 않는 한 개발 서버를 시작하지 마세요. 저장소에서 요구하는 모든 절차를 유지하면서 변경된 패키지에 비례하는 범위로 검증하세요. ## TypeScript 타입은 스키마에서 만들고 두 번 쓰지 않기 엄격한 검증 스키마를 단일 기준으로 취급하세요. 병렬 인터페이스를 별도로 유지하지 말고 해당 스키마에서 TypeScript 타입을 추론하며, 활성 스키마가 엄격한 경우 알 수 없는 필드를 거부하세요. - 저장소에서 정한 모듈 형식과 로컬 가져오기 확장자 규칙을 따르세요. - 필요한 경우 공개 API 계약을 위한 인터페이스를 내보내되, 스키마 구조를 중복 정의하지 말고 내보낸 스키마 상수에서 검증된 데이터 타입을 추론하세요. - 값, 함수, 타입, 스키마에 지정된 이름 지정 규칙을 사용하고, 의도적으로 사용하지 않는 값은 저장소의 밑줄 규칙에 따라 표시하세요. - 구조화된 오류를 반환하는 안전한 파싱을 우선하고, 오류 계약에서 지원하는 경우 근본 원인을 유지하세요. - 비교와 정렬에서 `undefined`를 명시적으로 처리하고, 의도한 의미를 유지할 수 있을 때 선택적 체이닝과 널 병합 연산자를 사용하세요. - 파일 작업에는 `async`/`await`와 비동기 반복을 사용하고, 저장소의 표준인 경우 런타임의 기본 glob, 파일, 쓰기 API도 함께 사용하세요. 스키마의 사실을 직접 작성한 타입에 중복하지 말고, 검사되지 않은 타입 변환으로 구조화된 검증을 우회하지 마세요. ## 모노레포에서 카탈로그를 맡은 패키지에서 고치기 편집하기 전에 핵심 검증, 사용자 인터페이스, 배포 가능한 함수를 어느 작업 공간이 담당하는지 확인하세요. 카탈로그 원본을 해당 기준 디렉터리에 유지하고, 이를 사용하는 패키지에서 변경하세요. - 핵심 생성, 정적 인터페이스 출력, 배포된 함수 코드 사이에 선언된 관계를 유지하세요. - 작업 공간 패키지 전반에서 런타임과 모듈 선택을 일관되게 유지하세요. - 영향을 받는 패키지를 먼저 검증하고, 변경된 계약이 패키지 경계를 넘을 때만 패키지 간 빌드를 실행하세요. - 하나의 기여를 단순화하려는 목적으로만 구성의 소유권을 옮기지 마세요. 특정 호스팅 제공업체, 프레임워크, 디렉터리 이름이 아니라 책임을 기준으로 아키텍처 결정을 일반화하세요. ## 새 제공업체에는 테마에 맞는 로고를 꼭 넣고, 가능하면 동기화 모듈 추가하기 필수 제공업체 리소스를 병합 차단 요인으로 취급하세요. 모든 새 제공업체는 제공업체 전용 디렉터리에 규정을 준수하는 벡터 로고를 포함해야 합니다. - 확장 가능한 벡터 형식과 테마에 맞게 조정되는 `currentColor` 채우기 또는 선을 사용하고, 가급적 정사각형 `viewBox`를 사용하세요. - 밝은 테마와 어두운 테마 모두에서 제대로 작동하지 않는 고정 크기나 하드코딩된 색상을 사용하지 마세요. - 신뢰할 수 있는 API나 카탈로그가 필수 데이터를 채울 수 있거나 더 이상 제공하지 않는 항목을 안정적으로 식별할 수 있다면 동기화 모듈을 추가하세요. - 빈약하거나 불완전한 출처가 필수 필드를 채울 수 없거나 항목 삭제를 공신력 있게 판단할 근거가 될 수 없다면 수동으로 작성하여 유지하세요. 출처가 충분히 완전하다면 동기화 모듈은 강력한 권고 사항이지만, 신뢰할 수 있는 출처가 없을 때는 차단 요인이 아닙니다. 카탈로그의 완전성을 입증할 수 없는 출처를 근거로 삭제를 자동화해서는 안 됩니다. ## 공통 모델 정보는 기본 모델에서 상속하고 복사하지 않기 기준 모델 메타데이터 항목이 있는 경우 제공업체별 레코드는 저장소의 기본 참조 메커니즘을 통해 제공업체와 무관한 사실을 해당 항목에서 상속해야 합니다. 공유 사실을 레코드 안에 직접 복사하지 마세요. - 일치하는 기준 메타데이터 항목이 없을 때만 전체 인라인 정의를 사용하세요. - 모든 `base_model` 참조가 실제 메타데이터 파일로 해석되도록 하세요. - 가격, 제공업체 식별 정보, 실험 상태, 추론 제어, 인터리빙 동작, 수명 주기 상태와 같은 제공업체별 값은 필요한 경우 제공업체 레코드에 유지하세요. - 해석된 출력에 병합된 사실은 포함하되, 생성 과정에서만 사용하는 `base_model` 또는 `base_model_omit` 지시문은 포함하지 마세요. 상속은 중복을 줄이는 동시에 제공업체에 따라 실제로 달라지는 값을 숨기지 않아야 합니다. ## 추론 설정은 제공업체 API에 실제로 있는 것만 선언하기 추론 모델로 표시된 모든 레코드는 제공업체 API에서 실제로 제공하는 기능을 반영하는 `reasoning_options`를 선언해야 합니다. - 검증된 켜기/끄기, 예산 또는 기타 제어를 스키마에서 요구하는 정확한 옵션 타입으로 표현하세요. - 제공업체가 특수한 요청 구조를 사용하는 경우 정확한 API 요청 구문을 가까운 TOML 주석에 기록하세요. - 예산 제어에 대해 검증된 최솟값과 최댓값을 기록하고, 다른 제공업체를 근거로 한도를 추론하지 마세요. - 모델이 추론하지만 사용자가 조정할 수 있는 검증된 제어를 제공하지 않는 경우 `reasoning_options = []`를 사용하세요. 모델이 추론을 지원한다는 이유만으로 스위치를 만들어 내지 마세요. 카탈로그에서는 추론 능력과 제어 가능한 추론 동작을 구분해야 합니다. ## 모델 정보를 상속할 때 객체는 깊게 병합하고 배열은 바꿔 넣기 저장소의 정확한 해석 계약에 따라 메타데이터 상속을 구현하세요. - 한도와 모달리티 같은 일반 객체를 깊이 병합하세요. - 배열과 원시 값은 하위 항목의 값으로 전체를 교체하세요. - 하위 항목에서 생략한 모든 제공업체 필드를 상속하세요. - 병합 후 `base_model_omit`를 적용하고, 없는 경로는 무시하며, 그 결과 비게 된 상위 객체를 제거하세요. - 참조된 기본 메타데이터 파일이 없으면 실패 처리하세요. 배열 교체, 객체의 깊은 병합, 생략된 경로, 빈 객체 제거를 집중적으로 다루는 테스트를 추가하세요. 객체, 배열, 원시 값의 병합이 모두 같은 방식으로 동작한다고 가정해서는 안 됩니다. ## 모델 ID는 파일 이름에서 가져오고 가격은 확인된 지역별 값으로 적기 저장소 계약에서 정한 경우 파일 이름에서 식별자를 도출하고, 자동으로 삽입되는 식별자를 데이터 파일 안에 절대 중복하지 마세요. 날짜가 포함된 접미사, 최신 별칭, 지역 접두사, 버전 태그, 구분자를 비롯한 제공업체별 이름 문법을 유지하세요. 활성 상태의 엄격한 스키마를 사용하여 사람이 읽을 수 있는 필수 메타데이터, 필수 기능 불리언 값, 필수 비용/한도/모달리티 객체와 선택적인 제품군, 지식, 온도, 구조화된 출력, 수명 주기 필드를 구분하세요. 추가 필드를 묵인하지 말고 거부하세요. 컨텍스트가 200K를 초과하면 스키마의 중첩 비용 객체로 임계값 기반 가격을 표현하세요. 일반적인 캐시 읽기/쓰기 비율인 10%/125%가 30%/375%로 명시된 지역별 변형에도 적용된다고 가정하지 말고, 검증된 제공업체 및 지역 동작을 인코딩하세요. ## 출처 인용은 동기화해도 사라지지 않는 곳에 두기 데이터를 변경하는 기여에는 신뢰할 수 있는 가격 페이지, 모델 문서 또는 API 참조를 인용해야 합니다. 인용이 없다는 사실만으로 자동 차단되지는 않지만, 더 엄격한 검토와 독립적인 검증이 필요합니다. 동기화가 카탈로그 파일을 파싱하고 다시 직렬화하는 경우 첫 번째 키 위의 선행 주석 블록에 출처 인용과 근거를 배치하세요. 동기화 과정에서 주석을 버린다면, 지속적으로 보존해야 하는 주석을 섹션 사이 또는 개별 키 위에 배치하지 마세요. 주석 위치를 외관상의 선호가 아니라 지속성 제약으로 취급하세요. 다음 동기화 실행에서도 향후 데이터 검토에 필요한 모든 출처가 유지되는지 확인하세요. ## 카탈로그 변경을 검토할 때 차단 문제와 권장 사항 나누기 검토 중에는 강제 차단 요인과 권고 사항을 구분하세요. 필수 리소스 누락, 유효하지 않은 기본 참조, 필수 추론 제어 누락, 스키마 위반 또는 검증 실패는 승인을 차단해야 하며, 권장 동기화 모듈이나 출처 인용은 문서에 규정된 권고 수준에 따라 판단해야 합니다. 완료 전: - 표준 카탈로그 검증기를 실행하세요. - 필요한 경우에만 영향을 받는 패키지를 빌드하세요. - 필수 리소스, 상속, 추론 제어, 이름 지정, 가격, 수명 주기 필드를 확인하세요. - 인용이 동기화 후에도 유지되는지 검증하세요. - 최종 차이에서 관련 없는 데이터나 중복 데이터를 확인하세요. 어떤 검사를 실행했는지, 어떤 검사를 의도적으로 범위에서 제외했는지, 해결되지 않은 권고 사항이 무엇인지 보고하세요. 권고 사항을 차단 요인으로 제시하거나 차단 요인을 단순한 조언으로 약화하지 마세요.