A study, late afternoon. A chalkboard against one wall, mostly erased. The PROFESSOR sits with a coffee gone cold. The STUDENT arrives mid-thought, already talking.

STUDENT: I keep running into the same problem. I’ve got several projects that are related: they all support one system. But I keep them as separate repositories. One manages infrastructure, one handles backups, one manages routing, one holds content. And I run my AI assistant from the directory that contains all of them.

PROFESSOR: And?

STUDENT: And it keeps wandering. I ask it to fix something in the routing project, and it starts making assumptions about the content project. It second-guesses why I split things up the way I did. So, should I just combine them? One repository, one source of truth?

PROFESSOR: Why did you split them up in the first place?

STUDENT: Different lifecycles. Different risk. A mistake in the backup scripts is annoying. A mistake in the routing config takes a live site down. I didn’t want a single careless edit to reach across all of that.

PROFESSOR: Then a merge doesn’t solve your problem. It removes the one thing that was working, the boundary, and keeps the thing that wasn’t.

STUDENT: Then what is the thing that isn’t working?

PROFESSOR: Where do you start the assistant from?

STUDENT: The parent directory. The one that holds all four projects. It’s convenient: I don’t have to remember which sub-folder I need before I’ve even opened the tool.

PROFESSOR: So the boundary between your projects is real, on disk, in your version control history. And then every session, you hand the assistant a window that includes all of them at once, with nothing marking where one ends and the next begins.

STUDENT: …I built the wall and then opened a door in it out of habit.

PROFESSOR: Convenience usually is a door. So, two fixes, not one. First: when the work belongs to a single project, start there. Let the directory itself be the boundary, not a rule someone has to remember to enforce.

STUDENT: And second?

PROFESSOR: Second, for the times you need the wide view, because some work really is cross-cutting, write the rule down somewhere the assistant reads every time. Not “remember not to wander.” Something more specific: name the boundary, and say that crossing it out loud is required, silence is not.

STUDENT: I thought about just telling it to remember, in the moment.

PROFESSOR: Two different kinds of remembering, and they don’t behave the same way. One is a note the assistant keeps on its own, tied to where you happened to be sitting when you said it. Useful, but it won’t necessarily follow you if you start from somewhere else next time. The other is a standing instruction, loaded fresh at the start of every session, everywhere, regardless of which door you walked in through.

STUDENT: So the standing instruction is just the safer bet.

PROFESSOR: For a habit you want to hold everywhere, yes. The situational note is right when the thing you’re recording only matters in that one place. Use the wrong one and it either shows up when you didn’t want it, or vanishes exactly when you needed it.

STUDENT: There’s something almost funny about it. The tidy answer would be “one repository or four.” The actual fix wasn’t about the repositories at all.

PROFESSOR: It rarely is. People reach for restructuring because it feels decisive. Most of the time the structure was already correct, and the leak was upstream of it: in a habit, not a schema.

STUDENT: So I keep the four repositories.

PROFESSOR: You keep the four repositories. You change where you stand when you start working. And you write down, once, what should happen on the days you stand somewhere else on purpose.

STUDENT: That’s a smaller fix than I expected.

PROFESSOR: The correct one usually is.

The STUDENT leaves already composing the note. The PROFESSOR reaches for the coffee, remembers it’s cold, drinks it anyway.

Technical footnote

For readers running their own AI coding assistant, the mechanics behind the story:

A global preferences file loads in full, every session, unconditionally. A file such as ~/.claude/CLAUDE.md is read in its entirety at the start of every session, regardless of which directory it’s launched from. This is a fixed load: the whole file, every time, no relevance filtering. It’s the right place for a rule that has to hold no matter where you’re standing when you start.

A per-project rules file loads in full too, but only when you’re inside it. Some assistants also support a rules file scoped to a single repo. It loads conditionally on location, only when the session’s working directory is inside (or below) that repo.

Memory loads conditionally on relevance, and it’s scoped to where you launched from. A persistent memory system typically keeps a short index always in context (one line per saved memory) and pulls in the full content of an individual memory only when it’s topically relevant to the current conversation. That’s a second axis of “conditional,” this time on content rather than location.

But the memory store itself is commonly namespaced by the exact directory a session was launched from. Two sessions started from two different directories, even when one is a subfolder of the other, can end up writing to two entirely separate memory stores. That’s the literal mechanism behind the play’s “door in the wall”: a note saved while standing in the parent directory doesn’t automatically follow you into a session started inside one of its subdirectories. It has to be written somewhere that loads regardless of which door you used, which is why it belongs in the fixed, global file, not in memory.

The rule that ended the scene, verbatim:

## Multi-project directories

Some directories (e.g. `~/Documents/claude_projects`) group independent repos
as subdirectories. Each subdirectory is its own scope, even when a session is
launched from the parent.

- Before editing a file, confirm which subdirectory/repo it belongs to.
- If a change would touch more than one subdirectory, say so explicitly
  before making it — don't cross silently.

This applies whether the session was launched scoped inside one repo or from
the shared parent — the second case is exactly when a cross-boundary edit is
easiest to make by accident.