Problem

Memory-core's short-term promotion system hardcodes MEMORY.md as the target file for promoted memories (source: dist/short-term-promotion-BMEmSJk4.js:1257). This causes several issues:

1. Bootstrap truncation: MEMORY.md is subject to OpenClaw's 12KB per-file bootstrap limit. As promotions accumulate, the file grows past this limit and gets truncated — losing critical context that the agent needs at session start.

2. Mixed concerns: Promotion metadata (scores, source references, recall counts) is algorithmically useful but clutters the human-curated bootstrap context. These are two different audiences (algorithm vs. agent) sharing one file.

3. Unbounded growth: Without manual intervention, promotions keep appending to MEMORY.md indefinitely. In our case, 29 promotion blocks consumed ~40% of the file (16KB of a 40KB file), pushing it well past the 12KB bootstrap limit.

Current Workaround

We've disabled the promotion cron job (ID: b38a1c62) and manually moved existing promotions to a separate MEMORY_PROMOTIONS.md file. This keeps MEMORY.md lean (10.4KB, under the 12KB limit) while still allowing memory_search to find promoted content in the separate file.

Proposed Solution

Add a configuration option to specify where promotions are written:

plugins:
  entries:
    memory-core:
      config:
        promotionTarget: "memory/promotions-YYYY-MM.md"  # or "MEMORY_PROMOTIONS.md", etc.

Key behaviors:

• Default: "MEMORY.md" (backward compatible, no change for existing users)
• Support templated paths with date tokens (e.g., YYYY-MM) for time-based organization
• Promoted content should still be searchable via memory_search regardless of target file
• If the target file doesn't exist, create it with appropriate frontmatter

Use Cases

1. Time-based organization: Monthly promotion files (memory/promotions-2026-04.md) keep each file small and organized chronologically
2. Separate concern files: MEMORY_PROMOTIONS.md for algorithmic metadata, MEMORY.md for curated agent context
3. Per-agent wikis: Different agents in the same workspace can promote to their own files
4. Archival: Old promotions can be pruned or archived without touching the active bootstrap file

Related Issues

• [Feature]: Hierarchical wiki vaults with promotion flow #64097 — Hierarchical wiki vaults (related structure concept)
• [Proposal] Built-in Adaptive Memory: hierarchical memory management as a core feature #59095 — Adaptive memory (related memory lifecycle concept)
• [Feature]: Per-agent memory-wiki vault configuration #63829 — Per-agent wiki paths (related per-agent config concept)

None of these address the core issue: the hardcoded promotion target file path.

Environment

• OpenClaw v2026.4.22
• memory-core plugin (bundled)
• 29 promotion blocks accumulated over ~2 weeks before manual intervention

Impact

This affects any OpenClaw deployment that uses Active Memory with promotions enabled for more than a few days. The current behavior degrades agent context quality as promotions accumulate, which is counterproductive — promotions are meant to improve recall, not degrade bootstrap context.