#21520: feat(onboard): add Cencori provider.

## Summary - Problem: OpenClaw onboarding does not currently support Cencori as a first-class provider/auth option. - Why it matters: Users can route through Cencori manually, but setup is inconsistent vs other providers and harder to automate. - What changed: Added `cencori-api-key` across interactive and non-interactive onboarding, wired `CENCORI_API_KEY` + `--cencori-api-key`, applied default provider/model config (`cencori/gpt-4o`), and added docs + e2e coverage. - What did NOT change (scope boundary): No changes to runtime inference logic for other providers, no UI redesign, no unrelated auth flow refactors. ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [x] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # (none) - Related # (none) ## User-visible / Behavior Changes - `openclaw onboard` now includes Cencori (`cencori-api-key`) in model/auth selection. - Non-interactive onboarding now supports Cencori via `--auth-choice cencori-api-key` + `--cencori-api-key` or `CENCORI_API_KEY`. - Cencori provider docs are now available and linked in provider/wizard docs. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`Yes`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: - Risk: New token path (`CENCORI_API_KEY`) could be mishandled if not normalized/validated. - Mitigation: Reused existing key validation/normalization patterns and existing auth profile persistence flow. ## Repro + Verification ### Environment - OS: macOS - Runtime/container: local Node - Model/provider: Cencori onboarding path - Integration/channel (if any): N/A - Relevant config (redacted): `CENCORI_API_KEY=***` ### Steps 1. Run `openclaw onboard` and select `cencori-api-key`. 2. Confirm existing `CENCORI_API_KEY` or enter key when prompted. 3. Run non-interactive path with `--auth-choice cencori-api-key` and key/env. ### Expected - Cencori credentials are stored via auth profile. - Default/provider model config is applied correctly. - Docs point to Cencori provider setup. ### Actual - Matches expected. ## Evidence - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) Notes: targeted e2e tests passed after fix: - `src/commands/auth-choice-options.e2e.test.ts` - `src/commands/auth-choice.e2e.test.ts` ## Human Verification (required) - Verified scenarios: - Interactive Cencori auth choice path - Existing `CENCORI_API_KEY` reuse path - Non-interactive option inference/flag wiring - Docs navigation entries - Edge cases checked: - Env-key path without manual prompt entry - `setDefaultModel` behavior via shared default-model helper - What you did **not** verify: - Full end-to-end live request execution against Cencori API endpoint ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`Yes`) - Migration needed? (`No`) - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Avoid selecting `cencori-api-key`, or revert this PR commit. - Files/config to restore: - Revert onboarding/auth files and docs touched by this PR. - Known bad symptoms reviewers should watch for: - `cencori-api-key` selection errors in onboarding - Missing default model/provider mapping for Cencori ## Risks and Mitigations - Risk: Provider config drift (base URL/model ref mismatch). - Mitigation: Single-source constants + e2e coverage + docs alignment. - Risk: Auth-choice mapping regressions with legacy `apiKey` + `tokenProvider`. - Mitigation: Added explicit mapping and test coverage. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds Cencori as a first-class provider to OpenClaw's onboarding flow. The implementation follows established patterns for API key-based providers (similar to LiteLLM, Vercel AI Gateway, etc.) and includes comprehensive coverage across interactive/non-interactive flows, tests, and documentation. **Key changes:** - Added `cencori-api-key` auth choice with `CENCORI_API_KEY` environment variable support - Wired Cencori through all onboarding paths (interactive prompts, CLI flags, env detection) - Applied default provider config (`cencori/gpt-4o` via OpenAI-compatible API at `https://cencori.com/api/v1`) - Added comprehensive e2e test coverage matching existing provider test patterns - Created provider documentation and updated all relevant docs navigation **Code quality:** - Consistently reuses existing auth/validation patterns (`normalizeApiKeyInput`, `validateApiKeyInput`, `resolveEnvApiKey`) - Follows the same structure as other API key providers (LiteLLM, Vercel AI Gateway) - Type definitions are properly extended across all relevant files - Test coverage includes both environment key detection and manual entry paths **Minor issue:** - One broken documentation link in `cencori.md` (line 25) - references non-existent `/docs/ai/gateway` path <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with only one minor documentation fix needed - The implementation follows well-established patterns throughout the codebase, reuses existing validation/security helpers, includes comprehensive test coverage, and makes no changes to runtime inference logic. The only issue is a broken documentation link that should be fixed before merge. Score is 4 (not 5) due to the doc link issue. - Only `docs/providers/cencori.md` needs attention - fix the broken `/docs/ai/gateway` link on line 25 _{Last reviewed commit: f128f3b} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->