feat(hooks): validate-memory-location — flag misplaced auto-memory files

[breferrari]

Problem

~/.claude/projects/<project>/memory/ should hold only MEMORY.md per CLAUDE.md. Everything else belongs in brain/ topic notes.

Agents drift here — the vocabulary ("this is a memory, goes in the memory dir") fights the convention. Misplaced files aren't versioned, fork the source of truth, and silently desync from the brain/ index.

Fix

PostToolUse hook on Write|Edit. Detects writes to ~/.claude/projects/<x>/memory/<file>.md where basename != MEMORY.md. Emits a warning at write time with migration pointer to the right brain/ note.

PostToolUse can't block; visibility is the lever.

Shape

.claude/scripts/validate-memory-location.ts, ~70 lines, matches the existing validate-write.ts pattern.

• Reads stdin JSON, checks tool_input.file_path
• POSIX + Windows path separators
• Allows MEMORY.md
• hookSpecificOutput.additionalContext lists target brain/ notes (Patterns / Gotchas / Key Decisions / Memories / new topic)
• Silent on:
  • Vault paths
  • Paths with 'memory' substring elsewhere (e.g. brain/Memories.md)
  • Other .claude/projects/<x>/ subdirs (transcripts, hook-output)
  • Bad input (null stdin, missing tool_input, non-string file_path)
• Subprocess integration tests in tests/validate-memory-location.test.ts

Wires into existing PostToolUse Write|Edit block alongside validate-write and qmd-refresh.

[breferrari]

A couple of design questions worth surfacing before the implementation lands.

1. Inline in validate-write.ts vs. dedicated script

The original spec proposes a new validate-memory-location.ts (~70 lines). An alternative — keep the surface smaller by adding a guard predicate to lib/frontmatter.ts and wiring it into the existing validate-write.ts:

// lib/frontmatter.ts
/**
 * Return true if the path is a memory file in ~/.claude/ that should be blocked.
 * Only MEMORY.md (the index) is allowed — all actual memories go to brain/ notes.
 */
export function isBlockedMemoryPath(filePath: string): boolean {
    const normalized = filePath.replaceAll("\\", "/");
    if (!normalized.includes("/memory/")) return false;
    if (!normalized.includes("/.claude/")) return false;
    const base = basename(normalized);
    return base !== "MEMORY.md";
}

// validate-write.ts — after the file_path string check, before shouldSkipFile
if (isBlockedMemoryPath(filePath)) {
    writeHookOutput(
        eventName,
        "Do NOT create memory files in ~/.claude/ — all memories go to brain/ notes in the vault (git-tracked, Obsidian-browsable). Only MEMORY.md (the index) is allowed here. Write the memory to the appropriate brain/ topic note instead.",
    );
    process.exit(0);
}

Tradeoff: one new exported function, one new branch in validate-write, no new hook entry in settings.json. Loses a clean separation but the rule is small and tightly coupled to validate-write's existing responsibility (PostToolUse on Write/Edit). Tests fit in the existing frontmatter.test.ts + validate-write.test.ts instead of a new file.

Path-substring care: the predicate requires BOTH /.claude/ AND /memory/ segments and exempts MEMORY.md by basename, so it won't false-positive on vault paths like brain/Memories.md, project paths containing the word "memory", or other .claude/projects/<x>/ subdirs (transcripts, hook-output, etc.) — matching the silent-on list in the issue body.

2. PostToolUse warn vs. PreToolUse block

The issue notes "PostToolUse can't block; visibility is the lever." Accurate — the file is on disk by the time the hook fires. Two failure modes to weigh:

• PostToolUse warn: misplaced file lands, agent sees the warning next turn, has to remediate (delete + rewrite under brain/).
• PreToolUse block: same predicate, fires before disk touch, agent's Write call gets rejected and it retries to brain/. Cleaner outcome but the hook contract is slightly different and the test surface is harder.

A pragmatic middle ground that the sketch above leans on: PostToolUse with strong-warning prose (using the word "Do NOT" / "BLOCKED:" so the model treats it as a hard signal, not a soft heads-up). Trusts the agent to remediate; avoids the PreToolUse complexity.

Suggestion

If the inline + strong-PostToolUse variant is acceptable, the patch is ~15 lines including the wire-up. Happy to open the PR.