memory-systemlisted

# Memory system Cross-conversation memory is only useful if it stays typed and pruned. Untyped memory becomes a noise pile — after months the directory holds hundreds of entries and nobody knows which still apply, so they get loaded as context and ignored. The discipline below keeps it a navigable graph of load-bearing facts instead. First, derive where this project keeps memory and which conventions it already uses: find the memory directory and its index file (an entry-listing markdown file at the root), read a few existing entries to see the filename prefixes and cross-link style in play, and mirror those. Don't impose a layout the project doesn't use. ## The four types — each has its own lifecycle Every entry is one of four types. The type decides the filename, the lifecycle, and where it eventually goes. 1. **User memory** — who the user is: role, preferences, hard constraints ("prefers one package manager over another", "is on a specific platform — never assume another", "owns all native builds — never run them, delegate"). Lives at the top of the index as an always-loaded section, or as standalone `user_<topic>` entries. Permanent and auto-loaded; never promotes (already top-tier). Changes only when the user's situation changes — and then you update it in place, never accumulate a contradicting second copy. 2. **Feedback memory** — corrections, lessons, anti-patterns the user explicitly flagged. The highest-leverage type, because it encodes what NOT to do. Filena