Challenge 1 — Solution

Task: A user says "I got burned last quarter when a mocked test passed
but the real production migration failed — never mock the database in
integration tests again." Which of the four memory types does this
belong to, and why?

This belongs to feedback memory.

Why: this is guidance about HOW to approach work going forward - a
correction, specifically, about a technical practice the user wants
followed differently from now on. It isn't about who the user IS (that
would be user memory), it isn't a fact about current project state or
deadlines (that would be project memory), and it isn't a pointer to
where information lives in an external system (that would be reference
memory). It matches feedback memory's own defining shape exactly: a
correction, given with the REASON behind it (the real incident where
mocked tests diverged from what actually happened in production) -
and that reason is exactly what should be captured, not just the bare
rule "don't mock the database."

A well-saved version of this memory would lead with the rule itself
(integration tests must hit a real database, not mocks), then include
a "Why:" line preserving the real incident that justifies it, and a
"How to apply:" line noting this applies specifically to integration
tests, not necessarily to every kind of test - exactly the structure
this chapter's own example format calls for.

Notes:
- The "Why" is the part that's easy to drop but genuinely matters -
  without it, a future session only knows THAT mocking is disallowed,
  not why, which makes it much harder to judge an edge case (e.g.
  "is this specific test genuinely an integration test, or something
  else entirely?") the way understanding the original incident would.
- This is a correction, not a confirmation - the chapter's own
  description of feedback memory notes both kinds are worth saving,
  and this example happens to be the corrective kind.