[andershaig]

I'm going a bit broader with my system but it's similar. Instead of trying to predict future behavior, I'm focusing on capturing new, meaningful information, preparing it for human review (no fully automatic writes) and pairing with an ongoing review process, deduplication and treating it like a resource I manually curate (with help to make that easier of course).

I think context needs to be treated primarily globally with the addition of some project specific data. For example, my coding preferences don't change between projects, nor does my name. Other data like the company I work for can change, but infrequently and some values change frequently and are expected to.

I also use Claude Code a lot more for thinking or writing these days so there's less separation between topics than there are in separate repos.

[davegoldblatt]

The global vs. project-specific split is the right question and has real tradeoffs. You're right that preferences, identity, and coding style don't change between repos. Right now Total Recall is project-scoped, so if you're using it across multiple projects you'd be maintaining separate memory for each, which of course is redundant for that kind of context.

The tension is that some things genuinely are project-specific (decisions, architecture, people involved) and mixing those into a global tier makes retrieval noisier and may degrade performance to the point where its useless. I think the answer is probably both: a global layer for durable personal context and project-scoped registers for everything else. Haven't built that yet but it's the obvious next step. Am going to add this to my next sprint.

Also, your point about using Claude Code for thinking and writing beyond just coding resonates too. The more you use it outside of repo-scoped work, the more project-level memory feels like the wrong boundary. Will report back when ive come up with a potential solution.