Verified Riemann Zeta in Lean: https://github.com/davegoldblatt/openai-zeta-proof-check
50 karma · joined May 19, 2015
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.
Remove-gates are a good extension of the same philosophy. Right now /recall-maintain lets you manually review and clean up, but it doesn't proactively surface "hey, you haven't referenced this in two weeks, still relevant?" That would be the natural counterpart to the write gate: system surfaces candidates, human decides.
Am going to think on this, but will likely add. Appreciate you!
Concurrent sessions: it's a real edge case but the blast radius is small. Daily logs are append-only by convention, so two sessions writing at the same time would mean interleaved or lost entries at worst. Registers and CLAUDE.local.md are theoretically higher risk since they get modified rather than appended to, but promotion is user-initiated via /recall-promote, so you'd have to be promoting in both sessions at the same time to hit it. The race window exists (edit tool does read-then-write, not atomic append) but I haven't hit it in practice.
Cleanest fix if it ever matters: per-session log files (YYYY-MM-DD-session-abc.md) so there's no conflict on capture, and recall-promote just reads all of them. Not worth adding file locking or restructuring for a problem that hasn't bitten anyone yet.
Write gate consistency: in my experience the model errs conservative (misses things) rather than permissive (saves junk). For me I actually prefer that direction since saving too much degrades the whole system over time, while missing something important is easy to fix. You just say "remember this" and it bypasses the gate. That explicit override (item 5 on the gate) has been more reliable than trying to tune the automatic criteria to be more permissive.
How It Works Think of it like a kitchen with four storage areas:
Counter (CLAUDE.local.md): The stuff you reach for every day. Loads automatically, every session. Kept small on purpose, around a page of text.
Pantry (memory/registers/): Organized by category. Your preferences, key decisions, project details, people you work with. Claude checks here when it needs something specific.
Daily notebook (memory/daily/): Timestamped scratch notes from each day. Everything gets written here first. You decide later what's worth keeping permanently.
Storage closet (memory/archive/): Old stuff that's done or outdated. Still searchable, but never loaded automatically.
The key idea: notes hit the daily notebook first, then you promote the keepers. Claude doesn't get to decide on its own what's important enough to remember permanently. You do.
For teams that do want shared context, I’ll document a “team mode” gitignore pattern that commits only selected registers (e.g. decisions/projects) while keeping daily logs + preferences/people local.