fix(hyperagent): sticky thread for agentic tool loops (Claude Code)

[artickc]

Summary

Follow-up to #7994.

When a reverse-conversion proxy (e.g. tools→text Intent+JSON for web models, then text→native tool_calls for Claude Code) rewrites the assistant message between turns, conversationFingerprint(prefix) no longer matches the key stored after turn 1. HyperAgent then created a new thread, so multi-turn tool results looked like a cold start (model re-states protocol instead of continuing).

Changes

• Sticky key by root user task (rootUserFingerprint) after normalizing common agentic user-pin wrappers (My current task:, etc.)
• Flatten Anthropic tool_use / tool_result content blocks in extractMessageText so Claude Code histories contribute to fingerprints + lastUserText
• Store root key on every successful turn; resolve via prefix → root → last-assistant (legacy)
• Regression tests: mutated-assistant tool loop, Anthropic tool_result flatten, root key skips pure observations

Tests

node --import tsx --test tests/unit/executor-hyperagent.test.ts

19/19 PASS

Risk

Low — only HyperAgent thread cache keying; chat body / SSE protocol unchanged. Cookie isolation preserved (projectKey still gates lookups).

[diegosouzapw]

Thanks for the detailed follow-up to #7994 — this is a well-documented fix and the reproduction of the reverse-conversion tool-loop cold-start problem makes sense. We ran your test suite as-is (node --import tsx/esm --test tests/unit/executor-hyperagent.test.ts) and confirmed 19/19 green, and lint is clean on both touched files.

One thing we want to work through before merging: the new rootUserFingerprint fallback key is derived only from the first real user message text, scoped by the HyperAgent cookie (connection), not by conversation. Since a HyperAgent connection is commonly shared across multiple end-users/API keys in an OmniRoute deployment, we found that two unrelated conversations under the same connection that happen to open with the same (normalized) first message — plausible with short/generic agentic templates — get silently routed onto the same cached thread once one of them registers that root key. We reproduced this directly against your branch with a small standalone script exercising storeHyperAgentThreadAfterTurn/resolveHyperAgentThreadBinding.

We'd like to land your fix, but with the root-key fallback made a bit more specific (e.g. requiring some corroborating signal beyond just the first user line, or moving it strictly after the existing last-assistant fallback rather than before it) plus a regression test for the "two different conversations, same opening line" case. Happy to help pair on the exact shape if useful — otherwise feel free to push the update to this branch and we'll re-run the suite.