feat(context): add Dakera Memory context provider

[ferhimedamine]

Summary

Adds DakeraContextProvider, a new context provider that semantically searches a self-hosted Dakera memory server and injects relevant memories into Continue chat as context items.

Closes #12929

What this does

• New file: core/context/providers/DakeraContextProvider.ts
• Registered in core/context/providers/index.ts Providers array
• Uses extras.fetch (Continue-native) when available, falls back to global fetch
• Graceful error handling — returns [] on any network/parse failure, never throws

Usage

In config.json:

{
  "contextProviders": [
    {
      "name": "dakera",
      "params": {
        "baseUrl": "http://localhost:3000",
        "apiKey": "your-api-key",
        "topK": 10,
        "sessionId": "optional-session-filter"
      }
    }
  ]
}

Then in Continue chat:

@dakera what did I implement last week in the auth module?
@dakera how did we handle rate limiting?

Config options

Option	Default	Description
baseUrl	http://localhost:3000	URL of your Dakera instance
apiKey	(none)	Bearer token if your instance requires auth
topK	10	Max number of memories to return
sessionId	(none)	Filter results to a specific session

API contract

The provider calls POST /v1/memories/search with:

{ "query": "<user query>", "top_k": 10 }

And maps the response ({ memories: [...] } or bare array) to ContextItem[]. Each memory's content, text, or value field becomes the context item content. Relevance score is shown in the item name when present.

Pattern followed

Modeled after HttpContextProvider — same BaseContextProvider extension, same extras.fetch usage, same error-handling approach.

Testing

• Self-hosted Dakera instance: spin up with docker run -p 3000:3000 dakera/dakera (or via the dakera-deploy repo)
• Set baseUrl in config, type @dakera <any question> in Continue chat
• Verified provider is correctly registered and appears via contextProviderClassFromName("dakera")

🤖 Generated with Claude Code

---

Summary by cubic

Adds DakeraContextProvider to search a self-hosted Dakera memory server and inject relevant memories as context items in Continue chat via @dakera. Queries POST /v1/memories/search and defaults to port 3300.

• New Features
  • New core/context/providers/DakeraContextProvider.ts; registered in Providers.
  • Config: baseUrl (default http://localhost:3300), apiKey, topK (default 10), sessionId.
  • Uses extras.fetch when available; otherwise global fetch. Fails gracefully by returning [].
  • Maps results to ContextItem[] and includes relevance in the item name when available.

^{Written for commit 7ddbbae. Summary will update on new commits.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[ferhimedamine]

I have read the CLA Document and I hereby sign the CLA

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[ferhimedamine]

The require-all-checks-to-pass failure is caused by jetbrains-tests: Autocomplete > testAutocomplete() FAILED — this is a pre-existing failure on the main branch unrelated to our change (which only touches core/context/providers/DakeraContextProvider.ts and core/context/providers/index.ts). The main branch CI also shows Main Branch Build as failing. Our added files don't touch the JetBrains autocomplete path at all.

[ferhimedamine]

The jetbrains-tests CI failure is pre-existing — confirmed failing on other unrelated PRs (e.g. e5c68709 run https://github.com/continuedev/continue/actions/runs/28505821947). The testAutocomplete() test in Autocomplete.kt appears to be a flaky or broken IntelliJ integration test unrelated to this change, which only adds a TypeScript context provider with no Kotlin changes.

Our addition passes all other checks (e2e, packages-checks, CLI PR Checks). Happy to rebase once the upstream JetBrains test issue is resolved.

[ferhimedamine]

CI is red on jetbrains-tests → Autocomplete > testAutocomplete() (an IntelliJ UI-robot integration test at Autocomplete.kt:42). This PR only adds a TypeScript context provider under core/context/providers/ and doesn't touch the IntelliJ autocomplete path, so the failure looks unrelated/flaky rather than caused by this change. I pushed a no-op commit to re-run the suite and will follow up if it reproduces.