fix(compression): ignore tool output for compaction cards

[simjak]

Summary

• Expose the shared strict compression-marker predicate as is_context_compression_marker().
• Make the streaming auto-compression path reuse that shared predicate instead of its local broad substring matcher.
• Add regressions proving tool output and normal user discussion that merely mention context compression no longer become compression_anchor_summary cards.

Root cause

The WebUI had two different compression-marker detectors:

1. api.compression_anchor._is_context_compression_marker() was strict: it only accepted known synthetic marker prefixes on non-tool messages.
2. api.streaming._is_context_compression_marker() was broad: it returned true if the message text contained phrases like context compression or context compaction anywhere.

_compression_summary_from_messages() scans messages in reverse to find the latest compression marker and persists that text into compression_anchor_summary. Because the streaming detector did not check the message role and did substring matching, an ordinary tool result, for example JSON emitted by a skill/tool whose text happened to describe "context compression", could be selected as the compression summary.

Once persisted, the frontend rendered that tool JSON as a Context compaction reference card. To users this looked like WebUI compacted after the current turn, even though the card was seeded from unrelated tool output that merely mentioned compression.

This patch removes that drift by routing streaming through the same strict shared marker predicate used by compression-anchor helpers. Tool messages are ignored, and user messages that discuss context compression in normal prose are not treated as synthetic compaction markers.

Testing

• python -m py_compile api/compression_anchor.py api/streaming.py
• /home/agent/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_issue2028_compression_anchor_helpers.py tests/test_auto_compression_card.py -q
  • 47 passed
• Full-suite local attempts were not clean in this environment:
  • one run had an order/environment-sensitive tests/test_issue1499_keyless_onboarding.py::TestKeylessChatReady::test_lmstudio_keyless_chat_ready_via_full_status failure; that test passed immediately when rerun alone.
  • another run hit many localhost ConnectionRefused failures in server-dependent tests, consistent with the local test server not being available for those cases.

[nesquena-hermes]

Summary

Read the diff at cron-pr-2803 against origin/master. Two-part change: rename _is_context_compression_marker to a public is_context_compression_marker in api/compression_anchor.py:56 (keeping a backward-compatible alias), and have api/streaming.py:2301 delegate to that shared strict predicate instead of using its own broad substring matcher.

The framing in the PR body is accurate. The streaming module's local detector at api/streaming.py:2299-2309 on origin/master was substring-matching on lowercased message text without checking role, so anything containing the literal 'context compression' or 'context compaction' got matched — including tool JSON output describing compression and user prose discussing compaction. Since _compression_summary_from_messages() at line 2344-2353 walks messages in reverse and grabs the first matched message's text, a stray tool result could "win" and seed compression_anchor_summary, then surface as a Context Compaction reference card in the UI.

Code reference

Old streaming-side detector at api/streaming.py:2299-2309 (master):

def _is_context_compression_marker(msg):
    if not isinstance(msg, dict):
        return False
    text = _message_text(msg.get('content', '')).lower()
    return (
        'context compaction' in text
        or 'context compression' in text
        or 'context was auto-compressed' in text
        or 'active task list was preserved across context compression' in text
    )

Shared strict predicate now at api/compression_anchor.py:56-71:

def is_context_compression_marker(message):
    """Return true for synthetic compression/reference cards, not user turns."""
    if not isinstance(message, dict):
        return False
    role = message.get("role")
    if not role or role == "tool":
        return False
    text = _content_text(...).lower().lstrip()
    return (
        text.startswith("[context compaction")
        or text.startswith("context compaction")
        or text.startswith("[your active task list was preserved across context compression]")
    )

The strict version requires (a) non-tool role and (b) prefix match. The synthetic marker source at api/routes.py:10082 emits "[CONTEXT COMPACTION — REFERENCE ONLY] {headline}\n", which lstrips and lowercases into a prefix match. So real markers still resolve.

Behavior change

One semantic delta worth flagging explicitly: the master streaming detector also accepted 'context was auto-compressed' in text as a substring match. The new strict predicate has no equivalent for that phrase. Looking at where that phrase is generated:

• api/streaming.py:4788 emits a goal_status event with 'message': 'Context auto-compressed to continue the conversation'.
• static/ui.js:5329 has it as a fallback string for the UI.
• static/messages.js:1845 reads String(d.message||'Context auto-compressed to continue the conversation') from the goal_status event.

I don't see this string being persisted into the message array as a marker (it's transient goal_status UI text). So dropping it from the matcher likely doesn't lose any real marker detection. But worth confirming: if any code path injects a synthetic message with body text starting with "Context was auto-compressed..." (note the trailing pre-state vs the current "Context auto-compressed..."), the new strict predicate will miss it. A quick grep -rn in the agent repo + plugins for that phrase as a synthetic content body would close that out.

Test plan

The new test_context_compression_marker_detection_is_prefix_and_role_scoped exercises four realistic cases (real marker prefix, preserved-tasks marker prefix, tool noise with the phrase in JSON, user prose discussing compression). All four assertions are the right direction.

test_compression_summary_ignores_tool_output_that_mentions_compression is the regression test for the exact failure mode the PR fixes:

assert _compression_summary_from_messages([marker, skill_tool_output]) == marker["content"]
assert _compression_summary_from_messages([skill_tool_output]) is None

Both correct — the tool noise is no longer eligible to seed the summary, and a tool-only history returns None instead of accidentally matching.

Verdict

LGTM with the one note above about the dropped 'context was auto-compressed' substring branch — please confirm via a grep over the agent codebase that no message-content path generates that text as a synthetic marker. If clean, the strict-prefix shape is the right contract. CHANGELOG entry is present.

[nesquena-hermes]

Shipped in v0.51.121 via release/stage-batch3 (#2813). The strict predicate is now the single source of truth — tool output that mentions compression no longer false-positives. Thanks for the comprehensive new test coverage.