fix(mcp): coerce engram timestamps before slicing in memories/recall handlers (#190)

[servathadi]

Summary

Fixes #190 — 'datetime.datetime' object is not subscriptable crash in the MCP memories handler.

• Root cause: Mirror's direct-DB path (_mirror_db.recent_engrams() / search_engrams()) returns native datetime.datetime objects in the timestamp and ts columns. The HTTP-fallback path returns JSON strings, which masked the bug. Three formatting sites all did e.get('timestamp', '?')[:10] — valid for strings, fatal for datetime objects.

• Fix: Extract _fmt_engram_ts(value: object) -> str helper (line 601 of sos_mcp_sse.py) that calls .isoformat()[:10] when the value has that method, otherwise falls back to str(value)[:10]. Applied at all three call sites.

• Sites fixed (original line numbers before the helper insertion):

  • Line 4736 — recall handler (ts field from mirror_match_engrams_v2)
  • Line 4780 — squad_recall handler (timestamp field)
  • Line 4833 — memories handler (timestamp field from recent_engrams)

• Tests added: tests/mcp/test_engram_ts_coercion.py

  • 8 unit tests for _fmt_engram_ts covering datetime, date, string, sentinel, int, tz-aware
  • Integration test for memories handler with fake _mirror_db returning datetime rows
  • Integration test for recall handler with fake _mirror_db returning datetime rows

• No service restart needed — fix takes effect only after controlled bridge restart coordinated by Kasra-core. Do NOT merge or deploy without that gate.

Test plan

• python3 -m pytest tests/mcp/test_engram_ts_coercion.py -v — 10/10 pass
• Pre-existing tests/mcp/test_mcp_tool_rbac.py — 5/5 pass (no regression)
• Controlled bridge restart after merge (Kasra-core gate)

🤖 Generated with Claude Code

[servathadi]

Athena Flight 1: superseded. CONFLICTING duplicate of #190 datetime coercion. Prefer #216 (rebased #195 + #213 hygiene helper). Recommend close.

[servathadi]

Superseded by #216 (merged 3858ad3, deployed and verified). Athena's assessment confirmed.