fix: skip tool_result messages in save hook exchange count

[sha2fiddy]

Closes #549

Summary

• Skip role: "user" messages where all content blocks are type: "tool_result" in _count_human_messages() (both hooks_cli.py and the inline Python in mempal_save_hook.sh)
• Claude Code sends tool results as role: "user", inflating the exchange count ~2.9x in tool-heavy sessions — subagent-heavy work triggers saves far more often than the intended 15-message interval
• Safe no-op for other LLMs (e.g. OpenAI-compatible) that use role: "tool" for tool results

Related

• fix: skip tool_result messages in _count_human_messages #316 targets the same bug but modifies hooks_cli.py with a different approach — this PR also fixes the inline Python in mempal_save_hook.sh
• Bug: Codex hook message counting does not match Codex transcript schema #347 / fix: count Codex user_message turns in _count_human_messages (#347) #373 address a separate Codex transcript counting issue

Test plan

• Added test_count_skips_tool_results — verifies single and multi-block tool_result messages are skipped
• Added test_count_mixed_content_not_skipped — verifies messages with both tool_result and text blocks still count
• All 34 tests pass

[web3guru888]

This is a well-diagnosed fix. The 2.9x inflation number is striking but makes sense — Claude Code subagent sessions can have dense tool-use loops where the agent barely generates "human" prose, yet every tool result pings the counter.

The predicate is correct. Filtering on "ALL content blocks are tool_result" is the right guard — a mixed message (tool result + follow-up text from the user) IS a genuine human exchange and should count. This is an important nuance that a simpler role-based filter would get wrong.

Dual-location fix matters. hooks_cli.py and the inline Python in mempal_save_hook.sh need to stay in sync — a fix to only one would leave the shell hook broken for anyone using it directly. Good that both are covered here.

One edge case to validate: Some older transcript formats (and a few OpenAI-compatible LLMs) send content as a raw string rather than a list of blocks. Worth confirming the fix handles isinstance(content, str) gracefully — either treating string content as a counting message (safe conservative default) or explicitly checking before iterating. If the code does for block in content directly, a string content will iterate characters, not blocks.

On test coverage: 34 tests for a behavioral change in a save hook is on the lean side — would love to see at least one integration-style test that exercises a full Claude Code-style transcript (interleaved tool calls + real human turns) and confirms the final exchange count is correct end-to-end. That said, the predicate logic itself is straightforward enough that unit coverage probably catches the important cases.

Safe no-op for OpenAI-compatible LLMs using role:"tool" is a nice property — no risk of regression for non-Claude users.

---

[MemPalace-AGI integration — production stats at https://milla-jovovich.github.io/mempalace/integrations/mempalace-agi/]

[web3guru888]

Good fix for a real problem. The 2.9x inflation figure is consistent with what heavy subagent sessions look like — each tool dispatch produces a tool_result block that gets misclassified as a human message, so a session with lots of agent coordination work was triggering saves at roughly 3x the intended rate.

The all(b.get('type') == 'tool_result' for b in content) guard is the right predicate. It's conservative in the right direction: a message with mixed content (text block + tool_result) would still be counted, which is correct since it represents actual human input alongside a tool return.

The dual-site fix (both hooks_cli.py and mempal_save_hook.sh) is important — the inline Python in the shell script is the one actually running in most deployments where the hook is invoked directly, so the hooks_cli.py fix alone wouldn't have been sufficient.

Test coverage is solid. The new test cases cover: pure tool_result skipping, mixed content retention, edge cases on empty blocks. That's exactly the right surface to test.

One minor: the test at line 82 in the pre-PR version was counting list-content messages and it's now clearer how _count_human_messages handles mixed content types. The existing tests for that still pass, but a comment in the test naming what 'mixed content' means (text block + tool_result) would help future readers.

Closes #549 cleanly. LGTM.

[sha2fiddy]

Yeah this is handled already — isinstance(content, str) is checked first (line ~59 in _count_human_messages):

if isinstance(content, str):
    if "<command-message>" in content:
        continue
    # counts as human message
elif isinstance(content, list):
    if all(b.get("type") == "tool_result" for b in content):
        continue

String content hits the first branch and gets counted as a human message. The list iteration only runs inside isinstance(content, list), so no risk of iterating characters on a raw string.

[sha2fiddy]

Rebased on develop (9b35d9f). Conflicts from upstream #1021 resolved — took silent-save shape. 1068/1068 tests pass.