← Back to context

Comment by cyanydeez

2 days ago

on the other "biological memory" post in so many weeks, I pointed out that the decay rate shouldn't be based on a real clock but a lifetime of it's use within the coding session. Elsewise your memory fades even when there's no process change (eg, coder goes on vacation). I'm not going to check whether thats true here, but it seems like a naive first assumption thats failed conceptualization.

The other comment is that spatial memory is probably a better trigger for memory, so if you're not tracking where the coding session starts, the folders it's visits, etc, then you're not really providing a good associative footpath for the assistant to retrieve whats important for any given project.

Wall clock decay punishing vacation is a issue. The current state of a clock decay is for simplicity but I do see how a session based decay might be helpful.

For failures and strategies it still might work as env drift on calendar anyhow (new version upgrade etc.). But for user preferences it does not.

I agree spatial memory tracking folder visits and session context as retrieval signal would be stronger I agree to that will try to incorporate !