mem2.eduz.ai

Memory OS — pk's persistent context across Claude sessions. The "auto-memory" that makes returning conversations remember who pk is, what's been decided, what's been built.

v0: stats + schema only. Memory file CONTENT is private — listing it publicly would leak personal context, project decisions, and pk's collaboration preferences. Body views land in v1, auth-gated. Today this page documents what kind of memory exists, how it's organized, and the meta-rules for writing it.

8total memory files

1user memory

2feedback memories

4project memories

1index (MEMORY.md)

Memory types in this universe

type	what it captures	when written	count
user	Who pk is, role, expertise, what pk is building, preferences for how to be addressed	When Claude learns anything material about pk's role or perspective	1 file (`user_eduz.md`)
feedback	Corrections pk gave or non-obvious approaches pk validated. Lead with rule, then Why:, then How to apply:	When pk corrects an approach OR confirms an unusual choice without pushback	2 files (collaboration mode, design principles)
project	Who's doing what, why, by when. Constraints, deadlines, stakeholder asks. Decays fast — keep current.	When new initiatives, bugs, deadlines, or scope decisions land	4 files (nomenclature, m01↔efus3 boundary, working folder, Doppler workplaces)
reference	Pointers to external systems (Linear, Slack, Grafana, etc.) — "where to look"	When pk mentions an external resource and its purpose	0 files (this universe is mostly self-contained)

What's tracked here that isn't in code or git

User role & build context — pk as solo founder of eduz (AI-first education platform for India), the 10 CF accounts, the 31+ domains
Nomenclature — marker-name rule, properties layout, packages/ structure
Design principles — CSS-first, mobile-first, color-distinct per property, repeated CTAs OK for IN
Collaboration mode — slow+robust over fast, no timelines language, CTO-mode, parallel agents
m01 ↔ efus3 boundary — m01 supplies env/credentials; efus3 starts after env present
Working folder — efus3 at ~/zexp1/efus3/, docs subtree renamed docs0a_pk_notes/ → dx0a_pk_notes/
Doppler workplace overflow — 10-project free-tier cap; spin eduz1<letter>-core as overflow; one CLI auth per workplace

(Names only — the content of each memory lives in ~/.claude/projects/-home-pk/memory/ and is intentionally not exposed here.)

How memory is read & written

Read: when Claude starts a conversation, MEMORY.md is loaded automatically (truncated at line 200). Claude pulls individual memory files when relevant.

Write: Claude writes a new file (e.g., feedback_X.md) with frontmatter (name, description, type) + the body, then adds a one-line entry to MEMORY.md.

Decay: project memories decay fast — Claude verifies them against current state before acting. User/feedback/reference are longer-lived.

What NOT to save: code patterns (read from project), git history (use git log), fix recipes (use commit messages), CLAUDE.md duplicates, ephemeral task state.

v1 ideas (auth-gated)

Browse — full memory file content behind allowlist login (auth2 bridge).
Diff over time — git-log of memory/ directory, "what changed when".
Cross-link graph — render the [[name]] links between memories as a graph.
Add memory from the UI — quick capture without a Claude session.
Sync to mem2 cloud DB — persist memory edits to a Supabase/Firestore so multiple devices share state.

Part of the eduz 2-series. Memory source: ~/.claude/projects/-home-pk/memory/ (private — not exposed by this page).
Repo: github.com/zexp1/experiments2 · See 2.eduz.ai for full inventory.