[FEATURE] Route memory writes by metadata.type — user/feedback should be user-level, not project-scoped

Preflight Checklist

• [x] I have searched existing requests and this hasn't been filed
• [x] Single feature request

Problem Statement

The memory system's frontmatter declares a scope hierarchy that the storage
location doesn't honor.

The system prompt instructs Claude to write memories with metadata.type
of user, feedback, project, or reference. The first two are
inherently cross-project — they describe the user and how Claude
should work for this user, not facts about one repo. But all memories,
regardless of type, are stored at a single project-scoped path:

~/.claude/projects/<encoded-project-path>/memory/

So user- and feedback-type memories — which are 80% of what actually
gets written in practice — are trapped in a per-project directory:

• They don't carry between repos. A correction the user makes in repo A

doesn't reach Claude when working in repo B.

• They duplicate content already in ~/.claude/CLAUDE.md (user-level

instructions), producing two parallel rule systems with no clear
separation.

• They get rediscovered and refiled in every new project the user opens.

The mismatch is between the content of the memory (cross-project
preferences) and the storage (project-scoped path).

Case study

A user with ~25 saved memories in one project's directory: ~17 are
feedback_* files about how the user wants Claude to work
("ask before naming," "no speculation," "red/green tests," "don't push
without asking," "presentations are HTML," etc.). All of these apply to
every project the user has, but they live in one project's directory and
do not load elsewhere. Only ~4 are genuinely project-specific facts
(e.g. internal service identities, project-only conventions).

Proposed Solution

Route memory writes by metadata.type:

• user and feedback → ~/.claude/memory/ (user-level, loads in every

session)

• project → ~/.claude/projects/<encoded-project-path>/memory/

(current location, loads when cwd is in that project)

• reference → either, based on whether the resource is project-bound

(a project-specific dashboard URL) vs general (an Anthropic docs link)

Or, less invasive: keep the storage location as-is but also load
~/.claude/memory/ in every session so user-level memories can live
there if explicitly written there. Today the system prompt does not even
acknowledge a user-level memory dir as a possibility.

Either way, the type field needs to mean something about scope, or it
should be dropped.

Alternative Solutions

• Add a scope: user | project field to the frontmatter explicitly, and

let the user decide per-file. Default by metadata.type.

• Make ~/.claude/CLAUDE.md the canonical home for feedback-type

content and stop writing feedback_*.md files entirely.

Priority

Medium — Significant friction for users who work across multiple repos.

Feature Category

Memory / system prompt conventions