Memory Butler V3.6

Problem

AI sessions often lose context between conversations, while long-term work notes are scattered across Markdown files, chats, and project docs. Decisions, bug fixes, milestones, and toolchain changes need durable capture; otherwise switching machines or taking over a project becomes expensive to reconstruct.

How it works

memory-butler organizes memory locally: user-level preferences are written to ~/.workbuddy/MEMORY.md, workspace logs to .workbuddy/memory/YYYY-MM-DD.md, and the database engine uses SQLite with FTS5 for structured queries. It accepts natural-language commands such as remember, search, entangle, weekly report, and health check. The system extracts 15 high-value signal types, including technical decisions, milestones, bug fixes, and toolchain changes. Its graph layer performs two- or three-hop diffusion, path search, community detection, and centrality analysis, with exports to HTML/D3.js, JSON, and Mermaid. The inference path reads analysis methodologies and turns memory data into weekly reports, trend insights, and knowledge gaps. Health checks cover directory structure, encoding, redundancy, backups, and graph cache integrity, with auto-fix, backup/restore, and multi-format export.

Boundaries

• It mainly processes text files such as .md, .txt, and .json, not images, audio, or video.
• Basic search relies on keywords and fuzzy matching; deeper semantic understanding should use analysis, weekly reports, or knowledge-gap queries.
• Workspace L3 is local-first and needs backup, copy, and restore across devices; L2 is better for cross-project preferences.
• Entry count, log size, graph node count, and search result size have recommended limits; performance degrades beyond them.
• It is not a chatbot, forecasting model, or project management system; it is best used as a durable knowledge layer for long-term work records.