Four Memory Types
In one line: Four types — User (rare), Feedback (append-only), Project (every session), Reference (when patterns change) — declared in YAML frontmatter so each is treated appropriately.
What: Memory files are classified into four types, each with a different purpose and update pattern, declared in the file's YAML frontmatter.
User Memories — encode the developer's preferences, working style, and non-negotiable rules.
---
name: feedback_autonomous_operation
description: Preference for autonomous operation — never ask, just proceed
type: feedback
---
Content: decisions about how to work. "Always use subagent-driven development." "Never use this specific test number as an example." "Design before code." These are not technical constraints — they are working style preferences that the AI should follow without asking for confirmation each time.
Update pattern: rarely updated. Created when a preference is established, modified only when the preference changes.
Feedback Memories — capture corrections, insights, and process improvements that emerged from actual development experience.
---
name: feedback_minio_cleanup
description: Never blanket-delete MinIO objects — branding logos share the bucket
type: feedback
---
Content: hard-won knowledge from mistakes. "Never blanket-delete MinIO objects because branding logos share the bucket with case documents." "Docusaurus is a core methodology principle, not just a tooling choice." Each feedback memory traces to a specific incident where the wrong approach was taken and the correction should be permanent.
Update pattern: append-only in spirit. New feedback memories are created when new lessons are learned. Existing ones are updated only to add clarification, not to change the lesson.
Project Memories — describe the current state of the project: what has been built, what is planned, what is blocked.
---
name: pillar-progress
description: Status of all architectural pillars — what is complete, what is next
type: project
---
Content: point-in-time observations about the project. Pillar status, feature inventory, session summaries, technical debt tracking, upcoming tasks. These files are the most frequently updated because the project state changes with every development session.
Update pattern: updated regularly. After completing a feature, update pillar progress. After a session, update the session summary. After discovering debt, update the debt tracking file.
Reference Memories — document stable technical patterns and conventions that change rarely.
---
name: technical-patterns
description: Key technical patterns used across the codebase — reference for implementation
type: reference
---
Content: established patterns to follow. Async signal patterns, mock-mode flag conventions, caching strategy, routing logic, database access patterns. The "how we do things here" knowledge a new team member would need to learn.
Update pattern: updated when patterns change (e.g., migrating from raw SQL to an ORM Repository pattern), but otherwise stable.
Evidence: The frontmatter type field is the mechanism — it lets the AI treat each memory appropriately: feedback memories carry warnings ("never do X"), reference memories give implementation guidance ("always do X this way"), project memories give current state that may be stale and must be verified. Reproducible: the type is in the file header, not inferred. See appendix-d-memory.md.