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.

[lindixu6-hash]

Re-reviewed the current head (1873ac6). The configuration-boundary issue from my earlier review is resolved: project-scoped remote-provider fields are now rejected before merge, and the new regression covers the global OpenAI → project Atlas case. I also verified the focused tests (13/13), full suite (465 pass / 4 platform skips), typecheck, and web build locally.

One original blocker is still unresolved. atlas-cloud remains functionally an openai-chat preset: it adds defaults for model/endpoint/key plus a session tag, but the PR does not explain what Atlas-specific product behavior requires a first-class provider instead of the existing neutral OpenAI-compatible configuration. Please either document and justify that dedicated provider decision, or reduce this to a neutral configuration example.

The user-facing documentation also needs to state explicitly that auto-capture/profile prompts, responses, and relevant conversation context are transmitted to the external api.atlascloud.ai endpoint when this provider is selected. Finally, please disclose any affiliation with Atlas Cloud (or explicitly state that there is none) so maintainers can evaluate the integration transparently. Holding approval until these governance and disclosure points are addressed.