AIのプロバイダーとモデルのカタログに、スキーマに合う形で項目を足す

## 終える前に、リポジトリのバリデーターとビルドのコマンドを動かす カタログデータを変更する前に、リポジトリで文書化された検証、ビルド、開発の各コマンドを確認する。影響を受けるワークスペースに対応したパッケージ固有のコマンドと、プロジェクトが選定済みのランタイムを使う。 - カタログの変更を完了扱いにする前に、正規の構成バリデーターを実行する。 - タスクでビルドが必要な場合に限り、影響を受けるインターフェースまたはパッケージだけをビルドする。 - リポジトリに専用のテストフレームワークがない場合、テストコマンドを作り出さず、実際に用意されている検証ゲートとビルドゲートを使う。 - タスクで明示的に求められていない限り、開発サーバーを起動しない。 リポジトリで必須とされるすべてのゲートを維持しながら、変更したパッケージに見合う範囲で検証する。 ## TypeScriptの型はスキーマから作り、二重に書かない 厳格な検証スキーマを正本として扱う。並行するインターフェースを保守せず、そのスキーマからTypeScriptの型を推論し、現行スキーマが厳格な場合は未知のフィールドを拒否する。 - リポジトリで確立されたモジュール形式と、ローカルインポートの拡張子規則に従う。 - 必要な場合は公開API契約用のインターフェースをエクスポートする。ただし、検証済みデータの型は、スキーマの形を重複定義せず、エクスポートされたスキーマ定数から推論する。 - 値、関数、型、スキーマについて所定の命名規則を使い、意図的に未使用とする値にはリポジトリ所定のアンダースコア規則を適用する。 - 構造化されたエラーを返す安全なパースを優先し、エラー契約が対応している場合は根本原因を保持する。 - 比較と並べ替えでは`undefined`を明示的に扱う。意図した意味を保てる場合は、オプショナルチェーンとnull合体演算子を使う。 - ファイル操作には`async`/`await`と非同期反復を使い、それがリポジトリの標準である場合は、ランタイム標準のglob、ファイル、書き込みAPIも使う。 手書きの型にスキーマの事実を重複させたり、未検査の型キャストで構造化検証を迂回したりしない。 ## モノレポの中で、カタログを受け持つパッケージで直す 編集前に、コア検証、ユーザーインターフェース、デプロイ可能な関数をどのワークスペースが所有しているかを特定する。カタログのソースは正規ディレクトリに保ち、それを利用するパッケージで変更する。 - コアの生成処理、静的インターフェースの生成物、デプロイ対象の関数コードの間で宣言済みの関係を維持する。 - ワークスペースの各パッケージで、ランタイムとモジュールの選択を一貫させる。 - まず影響を受けるパッケージを検証し、変更した契約がパッケージ境界をまたぐ場合に限り、パッケージ横断ビルドを実行する。 - 1つのコントリビューションを簡単にするだけの目的で、構成の所有先を移さない。 アーキテクチャ上の判断は、特定のホスティング事業者、フレームワーク、ディレクトリ名ではなく、責任を基準に汎用化する。 ## 新しいプロバイダーにはテーマに合うロゴを必ず付け、できれば同期モジュールを足す 必須のプロバイダー資産が欠けている場合は、マージを止める。新しいプロバイダーには必ず、そのプロバイダーが所有するディレクトリに準拠したベクターロゴを含める。 - 拡大縮小可能なベクター形式を使い、塗りまたは線にはテーマに適応する`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リファレンスを引用することが望ましい。引用がないだけで自動的にブロッカーにはならないが、より厳密な精査と独立した検証が必要になる。 同期処理がカタログファイルをパースして再シリアライズする場合は、ソースの引用と理由を、最初のキーより前に置く先頭コメントブロックへ記す。同期処理が破棄する場合は、保持すべきコメントをセクション間や個々のキーの直前に置かない。 コメントの配置は見た目上の好みではなく、永続性の制約として扱う。後日のデータレビューに必要なすべての出典が、次回の同期処理でも保持されることを確認する。 ## カタログの変更を見る時、止めるべき問題と提案を分ける レビューでは、ハードブロッカーと推奨事項を区別する。必須資産の欠落、無効なベース参照、必須の推論制御の欠落、スキーマ違反、検証失敗がある場合は受け入れを止めなければならない。推奨される同期モジュールや出典の引用は、文書化された強さに従って判断する。 完了前に次を行う。 - 正規のカタログバリデーターを実行する。 - 必要な場合に限り、影響を受けるパッケージだけをビルドする。 - 必須資産、継承、推論制御、命名、価格、ライフサイクルの各フィールドを確認する。 - 同期後も引用が保持されることを確認する。 - 最終差分を確認し、無関係なデータや重複データがないか調べる。 実行した検査、意図的に対象外とした検査、未解決の推奨事項を報告する。推奨事項をブロッカーとして扱ったり、ブロッカーを単なる助言へ弱めたりしない。