feat: add Atlas Cloud memory provider preset

[binyangzhu000-sudo]

Summary

• add a first-class atlas-cloud memory provider backed by the existing OpenAI-compatible Chat Completions implementation
• default Atlas Cloud configurations to https://api.atlascloud.ai/v1, deepseek-ai/deepseek-v4-pro, and ATLASCLOUD_API_KEY while preserving explicit overrides
• keep Atlas sessions isolated under their own provider tag and cover factory wiring, request routing, and config resolution

Testing

• bun test tests/atlas-cloud-provider.test.ts tests/config-resolution.test.ts tests/ai-provider-config.test.ts tests/openai-chat-completion-provider.test.ts (35 passed)
• bun run typecheck
• bun run format:check
• live Atlas Cloud Chat Completions tool-call check with deepseek-ai/deepseek-v4-pro

[lindixu6-hash]

The branch passes its focused suite (35 pass), the full suite available at this commit (347 pass, 0 fail), typecheck, Prettier, and the production build. The Atlas endpoint and current deepseek-ai/deepseek-v4-pro model are also publicly documented. However, the preset is unsafe under the repository’s project-scoped configuration merge.

initConfig() shallow-merges global and project config before buildConfig() applies Atlas defaults. If a user has a global OpenAI manual config (model, URL, and key) and a project config contains only the documented memoryProvider: "atlas-cloud", the merged object still contains all three OpenAI fields. The result is memoryProvider === "atlas-cloud" while requests continue to use the global OpenAI model/endpoint/key and sessions are mislabeled as Atlas. A partial project override can also pair a new endpoint with an inherited credential from the previous provider.

I reproduced this at 911810c with a temporary initConfig() regression: expected the Atlas model, URL, and ATLASCLOUD_API_KEY, but received gpt-global at the first assertion. Clearing provider-specific inherited fields when the project changes memoryProvider made the same test pass. Both the temporary test and mutation were removed; the review worktree is clean.

Please make provider changes reset model/URL/key fields that were not explicitly supplied at the same scope, and add coverage for global OpenAI → project Atlas plus a partial endpoint override so credentials cannot cross provider boundaries.

There is also a product/governance decision to make before adding another first-class provider. Atlas documents its LLM API as OpenAI-compatible, and opencode-mem already supports custom OpenAI-compatible endpoints through openai-chat; this subclass adds only defaults and a session tag. Please either justify the user-facing behavior that requires a dedicated provider or prefer a neutral docs/config example. The contributor’s recent public activity includes multiple AtlasCloudAI/* repositories, so the relationship should be disclosed, and the docs should clearly state that captured prompts/responses are sent to the external Atlas endpoint. The current model/endpoint claims are verifiable; the missing pieces are provider-scoped credential safety and transparent product policy.

[lindixu6-hash]

Following up on the requested changes. Are you still planning to address the review feedback? If not, I can close this PR to keep the queue clean; it can always be reopened later.

[tickernelz]

Skipped: this PR conflicts with main (src/config.ts, src/services/ai/ai-provider-factory.ts, src/services/ai/providers/openai-chat-completion.ts, src/services/ai/session/session-types.ts, src/types/index.ts). The provider surface on main has moved since this branch was cut (e.g. #254 added the orcarouter preset in the same files). Please rebase onto the latest main and resolve the conflicts — it can be included in a future batch.

[binyangzhu000-sudo]

Thanks for actually reproducing it — that made this unambiguous. Synced with main (84 commits) and the branch is mergeable again.

On the config-merge hole. It's real, and it's now fixed — but upstream, not here. Your commit 36b7c89 ("Prevent credential exfiltration through project config") added assertProjectRemoteProviderConfigIsSafe, which makes memoryProvider / memoryApiUrl / memoryApiKey / embeddingApiUrl / embeddingApiKey global-only and throws when a project config sets any of them.

That's a strictly better fix than what you asked me for. You suggested resetting provider-specific fields when the scope changes memoryProvider; upstream instead refuses the scope change outright, which closes the same hole for every provider rather than just patching the Atlas path. Both the "global OpenAI → project Atlas" case and the "partial endpoint override inherits the old credential" case are covered.

I confirmed it rather than assuming: my existing Atlas test started failing after the merge with

Project config cannot set remote provider fields: memoryProvider.

because it had been written against the old contract (project config setting the provider). It now configures the preset globally, and I added a test that pins the rejection — global OpenAI config + project memoryProvider: "atlas-cloud" must throw — so the hole can't quietly reopen.

Conflicts. The usual both-sides-added-a-provider shape: this branch's "atlas-cloud" against your new "orcarouter", across the AIProviderType / MemoryProviderType unions, the provider factory (import, switch case, supported list) and the config surface. Both kept everywhere. Two notes:

• src/config.ts — you inlined the memoryProvider literal union in two interfaces. I kept the MemoryProviderType alias and extended it with "orcarouter" instead, so the union stays defined once. Say the word if you'd rather have the inline form back.
• openai-chat-completion.ts — taking your inlined sessionProviderTag() call left a duplicate method definition next to the auto-merged one (TS2393). Removed the copy this branch carried; yours, with the JSDoc, is what survives. Worth flagging as the kind of thing a textually clean merge hides.

Verification — tsc --noEmit clean; bun test tests/config-resolution.test.ts 11 pass; full suite 456 pass / 9 fail.

Those 9 are all dist/ plugin-loader-contract and bundle-boundary assertions that need a build first. I checked them against a clean upstream/main worktree with the same unbuilt state: identical 1 pass / 9 fail. Not from this branch.