pi-ai resolves an OAuth provider from a stored OAuth credential alone, and this adapter builds its Models collection with no credential store and runs no login flow. `openai-codex` — the one installed provider declaring `auth.oauth` with no `auth.apiKey` — was therefore offered on the Models page with the keyless placeholder every pi-ai route carries, and every request on it failed `Provider is not configured` before going out. `catalogProviderTakesApiKey()` answers whether pi-ai's installed provider for a route declares the one method this adapter can supply, and the directory skips the catalog routes that fail it. Catalog membership is unchanged, so `declared` still answers what pi-ai ships; the profile half of the union stays unconditional, so a route a settings document already names keeps its entry and can be edited or deleted. Resolution is untouched: a profile naming `apiKeyEnv` on such a route still builds a working provider.
7 lines
432 B
YAML
7 lines
432 B
YAML
# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
|
|
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
|
# after editing either side, bring the other along and re-record with:
|
|
# pnpm run verify-translation-pairing --write packages/llm/llm-pi-ai/README.md
|
|
README.md: 6120f8d982c6d475cd508e6cf9e41cabfc9ba159
|
|
README.zh.md: 4b47976c6c6c67968b5b93edbdfd5dfa9530eb1d
|