Thread

1. rafram · 1790354717 · focus · HN ↗

   > When you change your mind, the old line is marked superseded, not deleted

   To me, this seems like a design error. You're polluting context with false/outdated information (even if the LLM is instructed to ignore it). The biggest issue with the memory systems built into Claude et al. is that they're terrible at pruning old/conflicting information as the project evolves, so I'd hope a replacement would do something to improve that.

   1. majkinetor · 1790354940 · focus · HN ↗

      Is it outdated? Its an avenue already visited, tried and abandoned, so valuable info regarding architectural decisions.

      1. stronglikedan · 1790355628 · focus · HN ↗

         > Its an avenue already visited, tried and abandoned

         I suppose if you could guarantee that the nondeterministic model can not only know all of those disparate pieces of information, but connect them together in that order, and arrive at a decision that it was abandoned because it was already visited and tried, every time.

   2. jergason · 1790354973 · focus · HN ↗

      From reading the readme, it looks like superseded decisions are not added to context.

      > Next session, the relevant lines are added to Claude's context.

      At least that's how I interpret it? If it is adding superseded decisions, that does seem bad.

   3. stuaxo · 1790355084 · focus · HN ↗

      It's such a Claudism.

      Everything is inundated with info about other things tried.

      Comments and docs flooded with things found out in the process when you want something about the info you need to know now.

   4. airstrike · 1790355138 · focus · HN ↗

      I've recently started trying out a little approach that half makes me cringe as I think of gastown, but sharing FWIW

      - All decisions get logged to DECISIONS.md, sequentially

      - Before writing a decision, read through past decisions to see if any conflicts

      - If no conflicts, encode the decision into the CODE.md

      - If any conflicts, ask a Tribunal of 3 agents to find a resolution—each of them should be prompted in slightly different ways

      I've only done this for one pretty big project but so far it seems to be working well

   5. avinashjetwani · 1790356840 · focus · HN ↗

      Good question — the file keeps history, recall does not. Superseded lines stay in JEVMEM.md (linked to the new id, so blame/history survive), but injection and decide only use live lines via store.active(). So the model does not get the old and new instruction together.

      Separately, jevmem audit can flag live lines that no longer match the repo as [stale?]. Happy to make the "superseded = out of context" rule louder in the README if that was unclear.

   6. avinashjetwani · 1790362187 · focus · HN ↗

      jergason read it right. Superseded lines stay in JEVMEM.md for history (and git blame), but recall only injects live lines: kind is not superseded, and there is no supersededBy. On UserPromptSubmit it ranks candidates and injects the top few above a relevance floor. So the file keeps the trail; the prompt gets the current answer. Pruning the file itself further is still open; audit can mark [stale?].
   7. shetritr · 1790374043 · focus · HN ↗

      [dead]

   8. rearclabs · 1790375959 · focus · HN ↗

      Keeping history and using history are two different things though

      You may want the old decision in the audit trail so you know why something changed without putting that old decision back into the model context every time

      I think memory systems need a pretty strict separation between active memory and historical memory

Unofficial Hacker News client; not affiliated with Y Combinator.