MemtraceDOCS

Temporal memory & evolution

Bi-temporal, symbol-level change history — what changed, when, with what, and what it did to complexity — plus a daily briefing, hotspots, and session review.

Memtrace records history at save granularity, not just commit granularity. Every file save while a repo is watched becomes a working_tree episode; every commit becomes a git_commit episode. That stream of episodes is what every tool on this page reads — from a single symbol's timeline to a repo-wide daily briefing.

Overview#

Episode stream to daily ritualFLOW
File save
Git commit
Episode streambi-temporal
Daily briefinglast 24h
Hotspotscomplexity × churn
Session reviewclean/review/risky
TRIGGERSERVICESUPPORTINGAGENT / AI

Evolution, timelines & episode replay#

get_evolution is the primary tool for "what changed in this window" and "what did I just break" questions. Give it a from timestamp (and optionally to, defaulting to now) and it walks the episode stream in one of three modes:

ModeShapeUse it for
recentDefault. Per-episode adds/removes/modifies, paginated (default 100/page)Walking exactly what happened, episode by episode
compoundTop-N changed files + top-N touched symbols, rolled upA quick "what moved" summary after a work session
summaryTotals + first/last episode metadata only (cheapest shape)A cheap sanity check on activity volume

get_evolution works across both git_commit and working_tree episodes, so you can diff against uncommitted changes too. A useful pattern: call it with from=<timestamp before your change>, mode=compound right after implementing something, to catch unintended regressions before they land in git.

get_timeline narrows to one symbol: its full version history across every episode, with signature, content, and AST hash at each point — enough to see whether an edit was structural or just whitespace, and whether someone else touched it recently.

detect_changes and get_changes_since answer the same family of question from different entry points. detect_changes takes a diff or a list of changed files and resolves them to the affected symbols and their structural roles (community, process, blast radius) — useful for scoping a PR description precisely. get_changes_since takes a since timestamp (plus optional until and branch) and returns the flat list of episodes in that window with per-episode node/edge add/remove counts and repo-wide totals — a lighter-weight alternative to get_evolution when you just want the window's activity, not a full replay.

get_episode_replay goes one level deeper still: it replays exactly what a single episode (one commit or one save) added, modified, and removed in the graph — the change story behind one change, including abandoned attempts and reversions, without re-running git yourself.

Co-change coupling#

get_cochange_context finds symbols and files that historically change together — i.e., appear in the same commits — ranked by co-occurrence frequency across episodes. This surfaces coupling the static call graph can't show: if two files always change together but never call each other, editing one should still put the other on your checklist. It's the complement to get_impact's structural (caller/callee) blast radius, and it's one of the inputs preflight_check bundles together before you edit an existing symbol.

Daily briefing, hotspots & session review#

Three tools read the same bi-temporal version history to support a daily rhythm around editing:

ToolAnswersDefault window
get_daily_briefingWhat changed recently, with complexity delta per function, new functions, new API endpoints, and per-module change distribution24 hours
find_hotspotsWhich functions rank highest by complexity × churn — where the next bug is likely to live14 days
review_agent_sessionsRecent editing sessions clustered by actor and time gap, each judged clean / review / risky by net complexity addedconfigurable

Use get_daily_briefing at the start of a session to see what moved before you touch anything, and again afterward to check your own net effect — a negative complexity delta means you left the code simpler than you found it. find_hotspots beats a raw complexity ranking for prioritizing refactors, because it weights risk by how often code is actually touched, not just how complex it looks sitting still.

TIP

review_agent_sessions is meant as a self-audit: if your own session comes back "risky", simplify what you added before calling the work done, rather than waiting for a human reviewer to flag it.

Temporal timeline walkthrough

Session attribution#

review_agent_sessions's per-session actor attribution comes from last_agent_id, a field stamped directly onto symbol versions as they're written during an editing session. This means the review is graph-derived, not transcript-derived — Memtrace isn't reading chat logs or tool-call history to figure out who did what; it's reading who last wrote each version of each symbol, straight from the temporal graph itself.

Explorer temporal timeline scrubber showing recent bi-temporal graph episodes below the graph canvas.
Dashboard temporal timeline

For a broader tour of how the graph itself is structured, see the knowledge graph, or for the visual face of this same history, see the dashboard.