Add AI Providers and Models to a Schema-Checked Model Catalog

## Run the repository's own validator and build commands before finishing Before changing catalog data, inspect the repository's documented validation, build, and development commands. Use the package-specific command for the affected workspace and the runtime already chosen by the project. - Run the canonical configuration validator before treating a catalog change as complete. - Build only the affected interface or package when the task requires a build. - If the repository has no dedicated test framework, do not invent test commands; use the validation and build gates it actually provides. - Do not start a development server unless the task explicitly requires one. Keep validation proportional to the changed package while preserving every repository-required gate. ## Derive TypeScript types from the schemas instead of writing them twice Treat strict validation schemas as the source of truth. Infer TypeScript types from those schemas instead of maintaining parallel interfaces, and reject unknown fields when the active schema is strict. - Follow the repository's established module format and local import-extension rules. - Export interfaces for public API contracts when required, but infer validated data types from exported schema constants instead of duplicating schema shapes. - Use the prescribed naming conventions for values, functions, types, and schemas; mark intentionally unused values with the repository's underscore convention. - Prefer safe parsing that returns structured errors, and retain the underlying cause when the error contract supports it. - Handle `undefined` explicitly in comparisons and sorting; use optional chaining and nullish coalescing where they preserve the intended semantics. - Use `async`/`await` and asynchronous iteration for file operations, together with the runtime's native glob, file, and write APIs when those are the repository standard. Do not duplicate schema facts in hand-written types or bypass structured validation with unchecked casts. ## Edit catalog data in the monorepo package that owns it Identify which workspace owns core validation, the user interface, and deployable functions before editing. Keep catalog sources in their authoritative directory and make changes in the package that consumes them. - Preserve the declared relationships among core generation, static interface output, and deployed function code. - Keep runtime and module choices consistent across workspace packages. - Validate the affected package first, then exercise a cross-package build only when the changed contract crosses that boundary. - Do not move configuration ownership merely to simplify one contribution. Generalize architecture decisions by responsibility rather than by a particular hosting vendor, framework, or directory name. ## Require a theme-friendly logo for new providers and add sync where a source allows Treat required provider assets as merge blockers. Every new provider must include a compliant vector logo in its provider-owned directory. - Use scalable vector format, theme-adaptive `currentColor` fills or strokes, and preferably a square `viewBox`. - Do not use fixed dimensions or hardcoded colors that fail across light and dark themes. - Add a synchronization module when an authoritative API or catalog can populate the required data, or can reliably identify entries it no longer serves. - Keep thin or incomplete sources hand-authored when they cannot populate required fields or support authoritative removal. The synchronization module is a strong recommendation when the source is sufficiently complete, not a blocker when no authoritative source exists. Never automate removal from a source that cannot prove catalog completeness. ## Inherit shared model facts from a base model instead of copying them When a canonical model metadata entry exists, provider-specific records must inherit provider-agnostic facts from it through the repository's base-reference mechanism. Do not copy shared facts inline. - Use a full inline definition only when no matching canonical metadata entry exists. - Require every `base_model` reference to resolve to a real metadata file. - Keep provider-specific values such as pricing, provider identity, experimental state, reasoning controls, interleaving behavior, and lifecycle status in the provider record when needed. - Ensure resolved output contains the merged facts but not manufacturing-only `base_model` or `base_model_omit` directives. Inheritance should reduce duplication without hiding values that genuinely vary by provider. ## Declare reasoning settings only as the provider's API actually offers them Any record marked as a reasoning model must declare `reasoning_options` that reflects the provider's actual API surface. - Represent verified toggle, budget, or other controls with the exact option type expected by the schema. - Place the precise API request syntax in a nearby TOML comment when a provider uses a specialized request shape. - Record verified minimum and maximum bounds for budget controls; do not infer limits from another provider. - Use `reasoning_options = []` when the model reasons but exposes no verified user control. Do not invent a switch merely because a model supports reasoning. The catalog must distinguish reasoning capability from controllable reasoning behavior. ## Deep-merge objects but replace arrays when inheriting model data Implement metadata inheritance according to the repository's exact resolution contract. - Deep-merge plain objects such as limits and modalities. - Replace arrays and primitive values wholesale with the child value. - Inherit any provider field that the child omits. - Apply `base_model_omit` after the merge, ignore missing paths, and prune ancestor objects that become empty. - Fail when the referenced base metadata file does not exist. Add focused coverage for array replacement, deep object merging, omitted paths, and empty-object pruning. Never assume that object, array, and primitive merges behave the same way. ## Take model IDs from filenames and record verified prices per region Derive identifiers from filenames when that is the repository contract; never duplicate an auto-injected identifier inside the data file. Preserve provider-specific naming grammar, including dated suffixes, latest aliases, region prefixes, version tags, and separators. Use the active strict schema to distinguish required human-readable metadata, required capability booleans, required cost/limit/modality objects, and optional family, knowledge, temperature, structured-output, or lifecycle fields. Reject extra fields instead of silently accepting them. Represent threshold pricing with the schema's nested cost object when context exceeds 200K. Do not assume common cache read/write ratios of 10%/125% apply to regional variants that document 30%/375%; encode the verified provider and region behavior. ## Put source citations where the sync process will keep them Data-changing contributions should cite authoritative pricing pages, model documentation, or API references. Missing citations are not automatically a blocker, but they require greater scrutiny and independent verification. Place source citations and rationale in a leading comment block above the first key when synchronization parses and reserializes catalog files. Do not place durable comments between sections or above individual keys if the synchronization process discards them. Treat comment placement as a persistence constraint, not a cosmetic preference. Verify that the next synchronization run will retain every source needed to review the data later. ## Separate blockers from suggestions when reviewing catalog changes Separate hard blockers from recommendations during review. Missing required assets, invalid base references, absent required reasoning controls, schema violations, or failed validation must block acceptance; a recommended synchronization module or source citation should be judged according to its documented strength. Before completion: - run the canonical catalog validator; - build only the affected package when required; - confirm required assets, inheritance, reasoning controls, naming, pricing, and lifecycle fields; - verify that citations survive synchronization; - inspect the final diff for unrelated or duplicated data. Report which checks ran, which checks were intentionally out of scope, and any recommendation that remains unresolved. Do not present a recommendation as a blocker or weaken a blocker into advice.