docs(memory): add Supermemory PR draft and cleanup

SUPERMEMORY_PR_DRAFT.md

@@ -0,0 +1,82 @@
+Title
+feat(memory): add Supermemory memory provider
+
+Summary
+This PR adds Supermemory as a native Hermes memory provider.
+
+It implements the upstream `MemoryProvider` interface rather than the general hook-based plugin system, so it works with the current memory-provider lifecycle and setup flow. The provider supports automatic recall, cleaned turn capture, session-end conversation ingest, and four explicit memory tools.
+
+What is included
+- `plugins/memory/supermemory/plugin.yaml`
+- `plugins/memory/supermemory/README.md`
+- `plugins/memory/supermemory/__init__.py`
+- focused tests for provider behavior and failure modes
+
+Behavior
+When enabled, the provider can:
+- prefetch relevant memory context before turns
+- include profile facts on the first turn and on a configurable cadence
+- store cleaned user-assistant turns after each completed response
+- ingest the full session on session end via Supermemory conversations API
+- expose explicit tools for memory store, search, forget, and profile access
+
+Tools
+- `supermemory_store`
+- `supermemory_search`
+- `supermemory_forget`
+- `supermemory_profile`
+
+Setup
+Use the standard memory setup flow:
+
+```bash
+hermes memory setup
+```
+
+Select `supermemory`, then provide:
+- `SUPERMEMORY_API_KEY` in `.env`
+- optional non-secret config written to `$HERMES_HOME/supermemory.json`
+
+Config surface
+The provider currently supports:
+- `container_tag`
+- `auto_recall`
+- `auto_capture`
+- `max_recall_results`
+- `profile_frequency`
+- `capture_mode`
+- `entity_context`
+- `api_timeout`
+
+Design notes
+- Implemented as a native memory provider so it fits Hermes's pluggable memory system and `hermes memory setup` / `status` flow.
+- The implementation preserves the useful behavior of a working local Supermemory integration, but removes local-only naming and packaging assumptions.
+- Recall context is fenced and stripped before capture to avoid recursive memory pollution.
+- `on_memory_write()` is intentionally conservative in v1 and mirrors `add` writes only. Supermemory is not a simple CRUD table, so pretending replace/remove are lossless would be dishonest.
+- Session-end ingest is kept in the provider because Supermemory's conversation ingestion endpoint is a meaningful part of the backend's graph-building behavior.
+
+Failure behavior
+- `is_available()` performs no network calls
+- missing API key or missing SDK leaves the provider unavailable without crashing Hermes
+- recall, capture, and ingest failures degrade quietly and do not break the agent loop
+
+Validation
+Ran:
+
+```bash
+python3 -m pytest tests/plugins/memory/test_supermemory_provider.py tests/agent/test_memory_provider.py tests/agent/test_memory_plugin_e2e.py -q
+```
+
+Result:
+- `76 passed`
+
+Reviewer-facing summary
+This PR adds Supermemory as a first-class Hermes memory provider in the same structural shape as the existing built-in providers. It is setup-compatible, failure-tolerant, and intentionally conservative where backend semantics differ from simple CRUD expectations.
+
+The main reason for this PR is straightforward: Supermemory is a real external memory backend, and the right way to integrate it upstream is through the native `MemoryProvider` interface, not through a user-local hook plugin.
+
+Points to review
+- provider shape and config UX alignment with other memory providers
+- recall formatting and profile cadence behavior
+- whether the add-only `on_memory_write()` bridge is the right v1 scope
+- test coverage for the provider lifecycle and failure paths

plugins/memory/supermemory/README.md

@@ -17,7 +17,7 @@ Or manually:
 
 ```bash
 hermes config set memory.provider supermemory
-echo "SUPERMEMORY_API_KEY=***" >> ~/.hermes/.env
+echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env
 ```
 
 ## Config

tests/plugins/memory/test_supermemory_provider.py

@@ -1,6 +1,4 @@
 import json
-from pathlib import Path
-from unittest.mock import MagicMock
 
 import pytest