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 does punish vacations, real limitation. The reason it's clock based today, environments drift on calendar time too (libraries update, configs rotate, services change), regardless of whether you're coding. But session based would serve a returning coder better.

The fix I've been considering, hybrid by category. Clock decay for failure and assumption (environment-specific). Session/recall based for strategy and fact. Not implemented yet.

On spatial, agreed. Project namespacing is the crude version today. Folder paths and file context as retrieval signals would be stronger. On the list.