Exercise 2 — Solution

Task: Explain what would actually go wrong, concretely, if this
repository's own Key Paths table were moved into the global
~/.claude/CLAUDE.md file instead of staying in the project's own file.

Concretely: the Key Paths table lists real, specific folder paths that
only exist inside THIS repository - e.g. where course HTML lives,
where kanji pages live, where sidebar pages live, all relative to this
project's own Folder-Structure/ tree. If that table were moved into the
global file, every single project the user ever opens Claude Code in -
not just this website - would have those exact paths loaded into
context as if they were universally meaningful instructions.

The concrete failure: working in a completely unrelated project (say,
a Node.js API with no concept of "course HTML" or "kanji pages" at
all), Claude would still be carrying instructions like "course HTML
goes in content/<subject>/<course>/" - paths that don't exist in that
other project, and content types that have no equivalent there at all.
At best this is simply irrelevant noise taking up context space in every
unrelated project; at worst, if the other project happened to have a
similarly-named folder structure by coincidence, it could actively
cause Claude to save a file to the wrong place, following a rule that
was only ever meant to apply to this website.

Notes:
- This is exactly why the chapter frames the risk as rules "leaking"
  into other projects - the Key Paths table isn't wrong information,
  it's just information that stops being true (or even meaningful) the
  moment it's read outside the one repository it actually describes.
- The fix, already in place, is keeping the Key Paths table inside
  this repository's own local CLAUDE.md, where it's only ever loaded
  when Claude Code is actually working inside this specific project.