get_project_context returns empty array — heat decay drives all memories to zero

[kodi]

Hey @amanhij

Me again :D

I haven't use one project for ~4 days, and today returned to it, and found that it returns an empty context.

Once again I let the LLM do the investigation (since stats cli showed that there are 111 memories for that project, and I even forced some of them by hand in chat to remember/anchor) but it didn't return anything:

---

Bug: get_project_context returns empty despite 111 memories existing for the project

Summary

get_project_context(directory) always returns an empty array because all memories have decayed to heat: 0.0000. The heat decay/consolidation cycle appears to aggressively zero out heat without respecting access patterns or protection status. This makes get_project_context — the primary tool for session-start context loading — completely non-functional.

Environment

• Zikkaron version: v1.4.0
• Total memories: 342
• Memories for affected project: 111
• Protected memories: 8

Steps to Reproduce

1. Seed a project with seed_project or accumulate memories over multiple sessions
2. Wait for consolidation cycles to run (in my case, over ~8 days of usage)
3. Call get_project_context("/path/to/project")
4. Observe: returns { "memories": [] }

Expected Behavior

get_project_context should return relevant memories for the project directory. At minimum, seed memories, protected/anchored memories, and recently accessed memories should be returned.

Actual Behavior

Returns empty array. Every single memory in the database has heat: 0.0000:

HEAT
  Min: 0.0000  |  Avg: 0.0000  |  Max: 0.0000
  cold (<0.01)           342  ########################################
  cool (0.01-0.1)          0
  warm (0.1-0.5)           0
  hot (0.5-0.9)            0
  burning (0.9+)           0

Diagnosis

• recall works fine when called with min_heat: 0 — it bypasses the heat filter and successfully retrieves memories via semantic search. This confirms the memories exist, have valid embeddings, and are retrievable.
• get_project_context silently filters them out because it applies a minimum heat threshold that none of the memories meet.
• Protected memories (8 total) also have zero heat. According to the docs, anchor creates memories with "max heat" and is_protected=True, and they should be "ALWAYS included in post-compaction restoration regardless of other scoring." Yet they have decayed to zero heat like everything else.
• Access count is near-zero for most memories (302 out of 342 never accessed), suggesting that recall/access operations are not boosting heat, or the boost is immediately overridden by the next decay cycle.

Root Causes (suspected)

1. Heat decay is too aggressive — consolidation cycles decay heat to zero without a floor. Even active memories can't maintain heat between sessions.
2. Protected memories are not exempt from decay — is_protected=True should prevent heat from decaying below a meaningful threshold, but it doesn't.
3. get_project_context has no fallback — when all memories are cold, it returns nothing instead of falling back to semantic search or ignoring heat for protected/seed memories.

Suggested Fixes

1. Protected memories should have a heat floor — if is_protected=True, heat should never decay below a usable threshold (e.g., 0.5).
2. get_project_context should always include protected and seed memories regardless of heat score.
3. Heat decay should have a minimum floor for any memory that has been accessed at least once, or apply a slower decay curve.
4. Consider a "warm start" boost — when get_project_context or recall is called, bump heat on returned memories so they remain findable in subsequent calls within the same session.

Workaround

Calling recall(query, min_heat=0) instead of get_project_context does return memories, but this defeats the purpose of having a dedicated project context tool and requires knowing to pass min_heat=0 explicitly.