Fair critique. The methodology doc covers this: both pipelines agree on the high-confidence clusters (security vulnerabilities, bubble predictions) even though they disagree on edge cases. The repo is public specifically so people can spot-check. If you find a claim where the scoring is wrong, I'd genuinely like to know.
> If you find a claim where the scoring is wrong, I'd genuinely like to know.
So you’re asking me to do the work you should have done in the first place? If you didn’t put any effort into it, why should I waste my time checking your non-work and correcting it to your credit?
If you had actually put in the effort then sure, I’d be amenable to helping making this the best it can be. But you didn’t, so what’s the point? Why should anyone spend their time fixing other people’s slop?
Nice, just looked at dory. Cool to see different takes on the same problem. The write gate and the manual curation approach converge on the same insight: the model shouldn't necessarily decide what's permanently important.
Thx! Also, interesting approach on your end. The screen-context angle solves a different problem than what I was going after, but I agree they're complementary. Curated project memory and broad ambient capture serve different retrieval patterns. Good luck with YC!
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.
Agree on human pruning piece for the most part. The system is built on the assumption that the model shouldn't necessarily be trusted to decide what's permanently important.
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.
