fix(adapter): enforce tool_use/tool_result adjacency in _strip_orphaned_tool_blocks

[fsaad1984]

Problem

After context compression, messages can be inserted between a tool_use block and its corresponding tool_result. The previous implementation of _strip_orphaned_tool_blocks only checked whether a matching tool_result ID existed anywhere in the conversation — but Anthropic requires it to be in the immediately following user message.

This causes a non-retryable HTTP 400 error:

messages.2: `tool_use` ids were found without `tool_result` blocks
immediately after: toolu_01X.... Each `tool_use` block must have a
corresponding `tool_result` block in the next message.

The error surfaces to the user as:

⚠️ The model provider failed after retries.

Root Cause

# OLD: global ID lookup — misses positional adjacency requirement
tool_result_ids = set()
for m in result:
    if m["role"] == "user" ...:
        for block in m["content"]:
            if block.get("type") == "tool_result":
                tool_result_ids.add(block.get("tool_use_id"))

After compression, tool_use at position i may have its result at position i+3 instead of i+1. The IDs still match globally, so the old code kept the tool_use — but Anthropic rejects it.

Fix

Two-pass approach:

Pass 1: For each assistant turn with tool_use blocks, collect tool_result IDs only from result[i+1] (the immediately following user message). Strip tool_use blocks not covered by that adjacent set.

Pass 2: Rebuild the surviving tool_use ID set after pass 1, then strip any tool_result blocks whose ID no longer has a matching tool_use anywhere.

The existing _thinking_signature_invalidated flag is preserved for the case where stripping a tool_use leaves a signed thinking block in the same turn.

Testing

All 40 existing guardrail tests pass unchanged:

tests/run_agent/test_agent_guardrails.py         ✅ 35 passed
tests/run_agent/test_session_meta_filtering.py   ✅  5 passed

Reproduction

Trigger: long conversation with tool calls → context compression fires → next message hits HTTP 400.

[teknium1]

Thanks for the focused adapter fix. The premise is real on current main: _strip_orphaned_tool_blocks still uses a global tool_result_ids set at agent/anthropic_adapter.py:2093-2105, so it can keep a tool_use whose result exists later but not adjacent.

Problems

• The new adjacency check should match the final Anthropic payload, not the pre-merge list. Current main calls _strip_orphaned_tool_blocks(result) and then _merge_consecutive_roles(result) at agent/anthropic_adapter.py:2390-2391. Since the PR checks result[i + 1] inside the strip helper, it can strip a pair that would become valid after consecutive user messages are merged.
• The PR diff changes only agent/anthropic_adapter.py; there is no regression test for the non-adjacent/global-ID-match failure or the merge-order control case.

Suggested changes

• Run the adjacency sanitizer after _merge_consecutive_roles, or make it validate against an equivalent merged/normalized view.
• Add tests in tests/agent/test_anthropic_adapter.py for both the broken non-adjacent case and the consecutive-user-message case.

Automated hermes-sweeper review.

[teknium1]

This checks adjacency before convert_messages_to_anthropic runs _merge_consecutive_roles on the result. If the tool_result is in the next consecutive user message, the final wire payload would be valid after merge, but this pass strips it first; consider validating after role-merge or against a merged copy.

[fsaad1984]

Thanks for the detailed review @teknium1.

Both issues are now addressed:

1. Merge order fixed — _merge_consecutive_roles now runs before _strip_orphaned_tool_blocks at anthropic_adapter.py:2345-2346. The adjacency check therefore operates on the final normalized message list, matching exactly what Anthropic sees.

2. Tests added (tests/agent/test_anthropic_adapter.py):

• test_strips_non_adjacent_tool_use — asserts that a tool_use separated from its tool_result by an intervening assistant turn is stripped
• test_consecutive_user_messages_merged_before_adjacency_check — asserts that a valid pair is preserved when consecutive user messages are merged, making the result adjacent

All 9 related tests pass.