That's a very good point, and it's something I've already been thinking about.
Today, Keep the Why deliberately keeps context/ inside the repository boundary. For multi-repo systems, one future direction is to let a project reference another project's context/ through an explicit URL or project reference, so downstream repos can surface upstream rationale without copying it.
That isn't implemented yet, though. For now, the single-repo boundary is intentional, while cross-project references are a future feature I want to explore.
This is a genuinely useful frame -- asking where it lives, who reads it, and what it remembers before comparing tools by name cuts through a lot of the noise these comparisons usually have. One gap I couldn't find addressed anywhere in the piece, the FAQ, or the spec: all four tools scope rationale to a single repository, but plenty of real decisions span repo boundaries -- a shared platform library's design choice constrains what a dozen downstream consumer repos are even allowed to build, and none of the four seem to have a way to surface or link that upstream rationale into a consumer repo's own context or memory. Drawing on our own multi-repo agent-orchestration work, that becomes a real gap once an org has more than a handful of repos with agents working across them: an agent in the consumer repo has no route to the "why" unless a human manually copies or links it over. Is that a deliberate single-repo boundary for Keep the Why, or just not solved yet?