v2.15.2 - Exact recall, guided setup, attribution, and Docker fixes

What changed since v2.14.0

This release catches up the public release notes from v2.14.1 through v2.15.2. The main theme is simple: MARM is easier to start, better at finding exact technical details, safer to run in Docker, and cleaner for multi-project use.

Faster setup with marm-init

marm-init is now the recommended setup path. Instead of making users piece together install docs, MCP config, transport choices, and client commands by hand, the skill walks through the setup inside the agent environment.

It can handle local Python or Docker installs, HTTP or STDIO transport, dashboard startup, protocol loading, and connecting multiple clients to the same memory server. The manual install paths are still documented, but they are no longer the main path for a new user.

Exact recall for code, config, commands, and APIs

MARM now has an exact retrieval lane for syntax-heavy queries. Searches like RECALL_SCAN_LIMIT, --generate-key, settings.py, marm_smart_recall, HTTP routes, URLs, and command strings can route through deterministic FTS/BM25 with a LIKE fallback instead of relying on semantic similarity.

The default is exact_mode="auto", so agents and users get this behavior without changing their normal recall calls. Power users can still force exact_mode="exact" or exact_mode="semantic" when they need tighter control.

Project and platform attribution

Memories, logs, and notebook entries now carry nullable project and platform metadata. MARM can keep work from different repositories, clients, and agent surfaces in the same local database while still letting recall filter by project or platform when needed.

This also makes consolidation safer. Exact duplicate checks and semantic merge checks now respect the current project/platform scope, which reduces the risk of one project quietly merging into another.

Docker, CI, and dependency fixes

Docker and CI builds now avoid the CUDA Torch dependency flood. Runtime installs use the CPU Torch wheel path, and CI validates through requirements.txt before installing the editable package with --no-deps.

Docker ignore files were also tightened so local pytest caches, temp databases, and test scratch folders do not get sent into image build contexts.

Email signup prompt and community polish

MARM now has a one-time, server-side email signup prompt after meaningful usage. It is controlled by environment settings, stored in user_settings, and guarded against MCP response-size limits.

The README also got a cleanup pass: clearer setup flow, friendlier contribution language, updated badges, a new contributors file, issue templates, Discord/Discussions links, and updated visual assets.

Security reporting

A new SECURITY.md explains how to report sensitive issues privately through support@marmsystems.com. The contributors file now includes a security acknowledgments section for responsible disclosures.

Upgrade notes

• Docker users should rebuild or pull the new image instead of reusing older local layers.
• If you run shared HTTP deployments, keep using MARM_API_KEY.
• If you rely on technical recall for config keys, commands, routes, or file paths, leave exact_mode on the default auto unless you have a reason to force another lane.

Contributors

Thanks to the contributors whose work landed in this release range:

• @vaishnavidesai09 for the exact retrieval lane in PR #71.
• @sarvesh1327 for preserving compaction trigger environment overrides in PR #43.
• @zza-830 for config safety clamping and recall debug observability in PR #54.
• @OI-OS for the earlier STDIO transport work now reflected in the contributor docs.
• The responsible security researcher who privately reported a Docker/HTTP auth-boundary issue affecting earlier deployment guidance.