[AI-assisted] This PR was generated using Claude Code.

Summary

• Problem: The short-term memory promotion pipeline in extensions/memory-core recorded markdown skeleton placeholders — bare list markers (-, *, +), heading-only lines, and heading + empty-bullet ranges — as promotable recall candidates. During relocation, broad substring matching could also anchor a meaningful candidate onto a bare-marker window (e.g. a target containing - matching a - line at quality 1), so empty/structurally meaningless blocks could be appended into MEMORY.md.
• Why it matters now: These placeholders carry no durable content but still consume recall-store slots, accrue ranking signals, and can be promoted as empty blocks into long-term memory, contaminating it with markdown skeleton noise (issue Memory: skip markdown placeholder snippets during short-term promotion #80582).
• Intended outcome: Placeholder snippets are dropped at every entry point (recall recording, grounded-candidate recording, store load/normalization, and ranking), and relocation substring matching refuses to anchor onto placeholder ranges. Real notes (including CJK and heading-with-body lines) are unaffected.
• Out of scope: No change to dreaming-contamination filtering (already present), no change to scoring weights, no change to the on-disk store format.
• Success looks like: Placeholder snippets never reach the recall store or ranking, and a meaningful candidate no longer relocates onto a bare marker line.
• Reviewer focus: The placeholder detection helpers (isMarkdownPlaceholderLine, isPlaceholderShortTermSnippet, isUnpromotableShortTermSnippet) and the narrow guard added to compareCandidateWindow.

Linked context

Closes #80582

Related: the issue includes a patch sketch; this PR implements it with one justified deviation (see "Risk checklist").

Real behavior proof

• Behavior or issue addressed: Short-term memory promotion recorded markdown skeleton placeholders (bare -/*/+, heading-only lines, heading + empty-bullet ranges) as promotable candidates and anchored relocation substring matches onto them (Memory: skip markdown placeholder snippets during short-term promotion #80582).
• Real environment tested: Windows 10 Enterprise LTSC 2019, Node v22.22.3, OpenClaw extensions/memory-core short-term-promotion shard.
• Exact steps or command run after this patch: Ran the memory-core short-term-promotion vitest shard via node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-memory.config.ts with the shard include filter pointed at extensions/memory-core/src/short-term-promotion.test.ts, once with the production fix reverted and once with the fix applied.
• Evidence after fix (terminal capture): Shard run via node scripts/run-vitest.mjs after the fix. Terminal capture (console output):

 Test Files  1 passed (1)
      Tests  83 passed (83)
   Start at  22:04:49
   Duration  57.06s

• Observed result after fix: After the fix all 83 tests pass, including the 5 new regression tests (bare markers, skeleton ranges, grounded placeholders, store-load drop, and relocation-onto-placeholder). Before the fix the same shard reported 5 failed | 78 passed (83) — the 5 new tests failed because placeholders were recorded/ranked and a candidate relocated onto a bare - line (applied was 1, expected 0).
• What was not tested: macOS/Linux not tested; the full pnpm test suite was not run locally (scoped to the memory-core shard plus format/tsgo/lint/build); pnpm check:host-env-policy:swift is skipped on Windows (no Swift); a live long-term dreaming promotion run against a real workspace was not executed end-to-end.
• Proof limitations or environment constraints: Local verification is Windows-only. The placeholder filtering is pure logic exercised directly through the real recordShortTermRecalls / recordGroundedShortTermCandidates / rankShortTermPromotionCandidates / store-normalization / relocation code paths in the extension shard; CI runs the same shard on Linux Node 24.
• Before evidence: Shard run with the production fix reverted (placeholders not filtered). Terminal capture (console output):

 Test Files  1 failed (1)
      Tests  5 failed | 78 passed (83)

The relocation regression failed with expected 1 to be 0 (applied.applied was 1), confirming the candidate relocated onto the bare - line before the fix.

Tests and validation

• Commands run: pnpm exec oxfmt --check (both files clean), pnpm tsgo (clean), pnpm exec oxlint --type-aware on the changed files (clean), pnpm build, and pnpm test:extension memory-core (short-term-promotion shard: 83/83 pass).
• Regression coverage added: 5 new tests in extensions/memory-core/src/short-term-promotion.test.ts — bare marker recording, multi-line skeleton range recording, grounded placeholder recording, store-load placeholder drop, and relocation-onto-placeholder refusal.
• What failed before this fix: the 5 new tests failed against the unpatched production code (5 failed | 78 passed); they pass after the fix (83 passed).
• Pre-existing unrelated Windows failures observed in the broader memory-core shard (manager.watcher-config.test.ts chokidar watcher tests and one qmd-manager.test.ts case failing on ENOENT mkdir '...Notes #1: blue' because Windows disallows : in directory names) were confirmed to also fail on clean main without this PR's changes.

Risk checklist

Did user-visible behavior change? No

Did config, environment, or migration behavior change? No

Did security, auth, secrets, network, or tool execution behavior change? No

What is the highest-risk area? Correctness of the placeholder detector — it must not drop legitimate notes. A heading line that also carries a list item with body text (e.g. ## Notes - real content) is intentionally kept, and ordinary prose/list lines are never placeholders.

How is that risk mitigated? The detector only treats a line as a placeholder when it is empty, a bare -/*/+, or a heading line without an inline list item carrying body text. The existing 78 tests (including CJK heading-prefixed relocations and bullet-prefixed dreaming snippets) still pass, and the new tests assert real notes are kept while placeholders are dropped.

Deviation from the issue's patch sketch: the issue suggests an isMeaningfulRelocationSubstring token-count guard for relocation. That check splits on [^A-Za-z0-9_]+, which treats CJK characters as separators and would reject legitimate non-English relocations (the suite has CJK rehydration tests). This PR instead uses a narrower placeholder-only guard in compareCandidateWindow that blocks substring matches only when either side is a placeholder — achieving the issue's stated goal ("avoid matching onto placeholders") without regressing CJK relocations. The exact-match branch is unchanged.

Current review state

Next action: await CI and maintainer/ClawSweeper review.

Waiting on: CI (format/lint/tsgo/build + memory-core shard on Linux Node 24).

Bot/reviewer comments addressed: none yet (PR just opened).