## Summary
- Fixed memory graph stuck on "Loading graph data..." caused by field name mismatch after package rewrite (`memoryEntries` vs `memories`, `type` vs `documentType`)
- Improved MCP app UI to match console-v2 design: golden derives edges (#FBBF24), edge glow pass, node hover effects, dot mode at low zoom, vertical controls with keyboard shortcuts, expandable legend
- Synced local `memory-graph` edgeDerives constant with published npm version
## Test plan
- [ ] Run `cd apps/mcp && bun run dev`, connect via Claude Desktop
- [ ] Verify graph renders with golden derives edges and blue dashed extends edges
- [ ] Verify node hover/selection glow effects
- [ ] Verify Fit (Z), Center (C), zoom (+/-) keyboard shortcuts
- [ ] Verify legend expands/collapses
### TL;DR
Enhanced the `forgetMemory` method to try exact content matching first, then fall back to semantic search with a high similarity threshold for more precise memory deletion.
### What changed?
The `forgetMemory` method now uses a two-step approach: first attempting exact content matching via the API, and if that fails with a 404, falling back to semantic search with a similarity threshold of 0.85. The search method also accepts an optional threshold parameter. Error messages now distinguish between exact matches and semantic matches, including similarity scores in the response.
### How to test?
1. Call `forgetMemory` with the exact content of an existing memory to verify direct deletion
2. Call `forgetMemory` with similar but not identical content to test the semantic search fallback
3. Call `forgetMemory` with completely unrelated content to verify the "no matching memory found" response
4. Verify that success messages indicate whether deletion used exact matching or semantic matching with similarity scores
### Why make this change?
This approach provides more precise memory deletion by prioritizing exact matches while still offering a fallback for similar content. The high similarity threshold (0.85) ensures that only very similar memories are deleted when exact matches aren't found, reducing the risk of accidentally deleting unrelated memories.
### fix(mcp): prevent LLM from overriding x-sm-project container tag
- When `x-sm-project` header is configured, the `containerTag` field is now
excluded from memory/recall/context tool schemas
- This prevents LLMs from overriding the configured project by picking a
different containerTag from the available projects list
- When no header is set, behavior is unchanged — containerTag remains visible
in schemas for manual project selection via listProjects
### TL;DR
TESTING REMAINING. This is my hypothesis. @MaheshtheDev please carry on from here or we can test in prod.
Added a proxy endpoint for OAuth authorization server metadata to support non-compliant MCP clients.
### What changed?
Added a new endpoint `/.well-known/oauth-authorization-server` to the MCP server that proxies requests to the main API. This endpoint fetches the authorization server metadata from the API and returns it to clients.
### How to test?
1. Make a GET request to `/.well-known/oauth-authorization-server` on the MCP server
2. Verify that it returns the same metadata as the main API's `/.well-known/oauth-authorization-server` endpoint
3. Test with a client that expects to find the authorization server metadata on the MCP domain
### Why make this change?
Some MCP clients don't correctly follow the OAuth specification. Instead of using the `authorization_servers` array provided in the protected resource metadata, they look for the authorization server metadata directly on the MCP server domain. This proxy endpoint ensures compatibility with these non-compliant clients without requiring them to be updated.
