Disable Mem0 and remove seed machinery

[dcellison]

Summary

Disables Mem0 and removes the seed machinery added in #317. Two problems drove this:

Hallucination feedback loop

Track 1 ingests every assistant response via add_exchange() with infer=False - no truth filter. When the assistant fabricates something (a file path, a function name), Mem0 embeds it. On the next turn, semantic retrieval surfaces the fabrication as authoritative context in the [Relevant memories...] block. The model sees its own fiction presented as historical fact and doubles down. This was observed directly in production: Kai hallucinated src/kai/seed_memory.py with a --dry-run flag, Mem0 stored it, and subsequent turns kept referencing it because retrieval kept serving it back. The loop is self-reinforcing and gets harder to escape with every turn.

Seed was Claude Code-specific

seed_from_memory_md() assumed a specific MEMORY.md layout with hardcoded filename mappings (preferences.md, user.md, etc.) and skipped MEMORY.md itself. Users with a flat MEMORY.md (the common case for most installations) got nothing seeded. The attempted fix (dynamic discovery via markdown link parsing) was still too coupled to one tool's memory format. The seed concept needs to be rethought as a simple, backend-agnostic CLI command.

What changed

• main.py: Removed Mem0 init block and seed block from _init_and_run(). MEMORY_ENABLED is now ignored.
• memory.py: Removed _classify_source_file, _parse_topic_file, _is_duplicate, seed_from_memory_md (-271 lines). Core primitives (init_memory, search, add_exchange, add_structured, format_context) retained for future use.
• tests: Removed TestParseTopicFile, TestClassifySourceFile, TestIsDuplicate, TestSeedFromMemoryMd, TestMemorySeedIntegration (-683 lines).
• Net: -1019 lines.

Test plan

• make check clean (ruff lint + format)
• 1719 tests passing, zero failures
• Mem0 init no longer runs regardless of MEMORY_ENABLED setting
• Qdrant collection manually cleared in production

Fixes #320

[dcellison]

Review by Kai

This is a clean deletion PR. The changes are surgical and well-executed. No bugs or security issues found.

Suggestion - orphaned session flags

memory_seeded:{user_id} keys written by the old seed block still exist in the sessions store. No code reads or writes them anymore. They're harmless but will accumulate indefinitely. Worth a one-time cleanup migration or at minimum a note in the tracking issue, especially since any future re-implementation of seed will need to either clear them or account for them.

Suggestion - init_memory / is_enabled are now dead call sites

init_memory is never called (the call was removed from main.py), so _memory is always None at runtime. The remaining primitives (search, add_exchange, add_structured, format_context) all guard on _memory is None and degrade gracefully - that's fine. But is_enabled() will always return False now, which could mislead a future caller. Worth a docstring note on is_enabled or init_memory flagging that neither is wired into the startup path.

Style - minor

test_main.py module docstring update is clean. Path import removal in memory.py is correct. Nothing else to flag.

The root cause analysis in the PR description is solid and the fix is proportionate. The hallucination feedback loop problem is real and this is the right call.

[dcellison]

Review by Kai

The prior review suggestions were addressed: orphaned flags are now cleaned up (better than just noting it), and init_memory has a docstring noting it is not wired in. Two new issues in the cleanup block added to address that suggestion:

---

Warning - Silent exception suppression (main.py, new cleanup block)

except Exception:
    pass  # Non-fatal; flags are harmless if cleanup fails

Completely silences all errors, including AttributeError if sessions._get_db() is renamed or removed. A future maintainer gets no signal that the cleanup never ran. Should be logging.warning("Could not clean up memory_seeded flags", exc_info=True) - same one-liner, free observability.

---

Suggestion - Private method access (main.py, new cleanup block)

sessions._get_db() reaches into a private implementation detail. If the sessions module refactors its connection management (e.g., switches from a single shared connection to a pool), this call breaks and the except Exception: pass above will hide it. If there is a public sessions.execute() or similar, prefer that. If there is not, this warrants a comment flagging the coupling so the next person touching sessions._get_db() knows to update this call site.

---

Everything else is clean. The -1019 line count is appropriate - the removed seed machinery was genuinely broken for the stated reasons and the tests for it were thorough enough that no coverage debt remains. The SQL literal ('memory_seeded:%') is not user-influenced, so no injection risk.

[dcellison]

Review by Kai

Both prior review issues are resolved: the exception handler logs properly with exc_info=True, and the orphaned flag cleanup uses the new public delete_settings_by_prefix() instead of reaching into _get_db() directly. Nothing new to flag.

A few things I verified and found clean:

sessions.py - delete_settings_by_prefix (new function)

The LIKE escaping is correct. memory_seeded: contains a literal _ which would otherwise match any single character under LIKE - the replace("_", "\\_") handles that, and the ESCAPE '\\' clause (a single backslash in the emitted SQL) is valid SQLite. The double _get_db() call (once for execute, once for commit) is consistent with delete_setting and the rest of the module.

One edge case that won't matter in practice: an empty-string prefix would delete all settings. The function is only called from one hardcoded site, so no real risk, but worth keeping in mind if it gets reused.

main.py cleanup block

Runs on every startup. Once flags are gone it's a no-op DELETE - cheap and harmless. The logging.warning(..., exc_info=True) pattern is correct.

Tests

test_delete_settings_by_prefix covers the happy path and no-op case. That's sufficient for a DELETE-by-prefix that has no branching logic.

This is clean. The -1019 line count is appropriate and the remaining memory primitives degrade gracefully while the system is disabled.