[FEATURE] Custom Project Identifier for Memory Directory

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The auto-memory directory path is derived from the absolute file system path:

/Users/alice/dev/foobar-project
→ ~/.claude/projects/-Users-alice-dev-foobar-project/memory/

This path-based identifier breaks in common development scenarios:

• Folder renames → memory lost
• Multiple checkouts → isolated memory silos
• Different machines → no memory continuity

Proposed Solution

Allow an optional projectId field in .claude/CLAUDE.md:

<!-- .claude/CLAUDE.md -->
projectId: foobar-project

# Project Instructions
...

The memory directory would then use the stable identifier:

~/.claude/projects/foobar-project/memory/MEMORY.md

---

Why Not Just Use CLAUDE.md for Everything?

There's an important distinction between two types of knowledge:

| Type | Storage | Shared? | Content |
|------|---------|---------|---------|
| Team conventions | .claude/CLAUDE.md | ✅ Via git | Architecture patterns, coding standards, project structure |
| Personal learnings | ~/.claude/.../memory/MEMORY.md | ❌ Personal | Mistakes made, patterns discovered, workflow context |

CLAUDE.md is intentionally committed to the repo — it's curated team knowledge.

MEMORY.md (auto-memory) captures things you don't consciously curate:

• Claude learning from your mistakes
• Patterns discovered during debugging sessions
• Context accumulated organically over time

Putting personal learnings in CLAUDE.md would:

• Create merge conflicts between team members
• Pollute the repo with individual workflow noise
• Require manual curation of what should be automatic

Alternative Solutions

I used a symlink like:

ln -s ~/.claude/projects/dbel-platform
  ~/.claude/projects/-Users-nickyweber-dev-some-project

But this is fragile and manual.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

A solo developer working on foobar-project across different contexts:

# Primary development
/Users/dev/foobar-project

# Experimenting with risky refactor
/Users/dev/foobar-project-refactor

# Clean checkout for release testing
/Users/dev/foobar-project-release

# After reorganizing projects folder
/Users/dev/projects/foobar-project

Current behavior: Each path creates a separate memory directory. Claude "forgets" everything learned in other checkouts.

With projectId: foobar-project: All checkouts share the same memory. Learnings from debugging in the refactor branch are available when doing release testing.

Concrete Example

While working in /Users/dev/foobar-project, Claude learns:

<!-- MEMORY.md (auto-generated) -->
## Calculation Pipeline
- Sound sources use `barrier.height`, not `emission.dimensions[2]`
- `onTopOf` relation adds building height; `insideOf` does not
- Always check `v2-model-helpers.ts` for coordinate transformations

## Common Mistakes
- Forgetting to run `npm run build` before testing CLI changes
- The `--receivers` flag expects a lookup file, not a GeoJSON

When the developer creates a hotfix checkout at /Users/dev/foobar-project-hotfix, this accumulated knowledge is lost — Claude starts fresh with no memory.

---

Use Case: Team with Multiple Checkouts

Team members working on foobar-project:

# Alice - main work
/Users/alice/dev/foobar-project

# Alice - feature branch (separate worktree)
/Users/alice/dev/foobar-project-feature-auth

# Alice - urgent hotfix
/Users/alice/dev/foobar-project-hotfix

# Bob - different path convention
/Users/bob/code/foobar-platform

Current behavior:

• Alice has 3 separate memory silos
• Bob has his own isolated memory
• Knowledge doesn't transfer between checkouts

With projectId: foobar-project:

• Alice's checkouts share memory — learnings from feature work help with hotfixes
• Bob still has separate memory (personal), but it persists across his own reorganizations
• Team conventions remain in CLAUDE.md (version-controlled, shared)

Additional Context

Benefits

| Scenario | Current | With projectId |
|----------|---------|------------------|
| Rename /dev/foo → /dev/projects/foo | ❌ Memory lost | ✅ Memory preserved |
| Multiple worktrees for same repo | ❌ Separate silos | ✅ Shared memory |
| Clone to new machine (same path) | ⚠️ Works by accident | ✅ Works by design |
| Team member with different path | ❌ Isolated | ✅ Personal memory portable |

Summary

• Team knowledge → CLAUDE.md (already works, commit to repo)
• Personal learnings → MEMORY.md with portable projectId (this feature request)

The projectId makes auto-memory work the way developers expect — tied to the project, not the path.