Challenge 3 — Solution

Task: Explain why MEMORY.md loads its full index at cold start while
individual memory files don't — what specific tradeoff does this
design avoid?

The tradeoff this avoids is loading a large amount of mostly-irrelevant
information into every single conversation, just in case a small part
of it turns out to matter.

The rules set (permanent_rules.md, language_rules.md, kanji_rules.md,
and the rest) is relatively small, and every rule inside it is
genuinely relevant to essentially any course-generation task in this
project - there's no real cost to loading all of it in full every
time, since almost none of it is wasted context.

Memory is structurally different: over a long relationship with a
project, the number of individual memory files can grow substantially
larger, and any one specific conversation is likely to only actually
need a small fraction of them - a memory about French lesson
formatting isn't relevant while working on a PHP course, for instance.
If every individual memory file's own full content were loaded in full
at every single cold start regardless of relevance, most of that
content would simply be wasted context on any given task, and the
wasted portion would keep growing as more memories accumulate over
time.

Loading only MEMORY.md's own short index - one line per memory,
naming what it's about - solves this: it's cheap enough to load in
full every time (unlike the memories themselves), and it's enough
information to recognize WHICH memories are actually relevant to the
current conversation, so only those specific files get read in full,
on demand, when something in the conversation actually calls for them.

Notes:
- This is a genuine engineering tradeoff, not an accident of the
  system's design - loading everything upfront would be simpler to
  reason about, but would scale badly as the memory set grows; loading
  a lightweight index and reading selectively scales much better at
  the cost of a small amount of extra indirection.
- This mirrors a similar shape to Chapter 7's own separate
  course_folder_mapping.md vs. course_name_index.md distinction - two
  files serving genuinely different purposes (a rich, detailed record
  vs. a lightweight, fast-to-scan lookup) rather than merging
  everything into one large file that's harder to use efficiently for
  either purpose.