cross provider handoff support

[billybonks]

1) Every adapter can now sanitize input messages before mapping

In lib/llm_gateway/adapters/adapter.rb:

• input_sanitizer was added to adapter initialization.
• In both chat and stream, messages now go through:
• normalize → sanitize → input_mapper

So cross-provider handoff happens at request time, right before provider-specific input mapping.

2) Generic sanitizer handles reasoning/thinking portability

New file: lib/llm_gateway/adapters/input_message_sanitizer.rb

For assistant messages with metadata (provider, api, model):

• If replaying to the same provider/api/model: keep thinking/reasoning blocks unchanged.
• If replaying to a different provider/api/model:
  • convert thinking / reasoning blocks into normal { type: "text", text: ... }
  • drop empty reasoning text

This prevents provider-specific reasoning block formats from breaking on another provider.

3) OpenAI chat-completions adds tool-call ID normalization

New file: lib/llm_gateway/adapters/open_ai/chat_completions/input_message_sanitizer.rb

On top of generic sanitizing, it normalizes tool IDs:

• tool_use/function IDs are cleaned/truncated (40 chars for OpenAI target)
• linked tool_result.tool_use_id is updated to match

This keeps tool-call/result references valid when handing off transcripts between APIs/providers with different ID constraints.

[managerbot-app]

Reviewed Changes

Managerbot reviewed 15 out of 20 changed files in this pull request and generated 12 comments.

Files not reviewed (5)

• test/fixtures/handoff_live_fixture.json
• test/fixtures/handoff_media_live_fixture.json
• scripts/generate_handoff_live_fixture.rb
• scripts/generate_handoff_media_fixture.rb
• test/utils/readfile_tool_helper.rb

Comments suppressed due to low confidence (2)

lib/llm_gateway/client.rb:65
• (are_you_sure) Falling back to `client.class.name.downcase` instead of raising an error silently accepts unknown providers. This could cause subtle bugs where sanitization comparisons silently pass or fail with unexpected provider strings (e.g. `"llmgateway::clients::someclient"` instead of a short id like `"openai"`). Consider raising for truly unknown types or maintaining an explicit allowlist.
test/unit/input_message_sanitizer_test.rb:33
• (test_completeness) The test uses `{ type: "reasoning", summary: [ { text: "second thought" } ] }` but `extract_reasoning_text` looks for `item[:text]`, `item[:summary_text]`, or `item[:reasoning]` inside a summary array. The hash `{ text: "second thought" }` uses symbol key `:text` which matches `item[:text]`. This test is valid, but there is no test covering the string-keyed variant `{ "text" => "second thought" }` to ensure cross-key compatibility.

[managerbot-app]

message.merge(content: sanitized_content) always uses symbol key :content, but the original message might have used string key "content". This could result in both "content" and :content keys existing in the merged hash, which may cause downstream issues.

[managerbot-app]

When text is non-empty, the block is converted to { type: "text", text: text } with only symbol keys. However if the original block used string keys elsewhere, this inconsistency could cause issues in downstream mappers that expect a uniform key type.

[managerbot-app]

next item if item.is_a?(String) — a plain string item in the summary array would be used as raw text, which seems unintentional given the rest of the logic expects hashes with text fields. Consider removing or clarifying this branch.

[managerbot-app]

stream_api_name is used for both chat and stream methods, but the name implies it is stream-specific. When called from chat, returning a stream-oriented API name could lead to incorrect same_model_replay? comparisons. Consider using a more general method or accepting the API name as a parameter.

[managerbot-app]

message[:content].is_a?(Array) — after super (the base sanitizer) processes the message, the content could now contain symbol-keyed blocks. However the check next message unless message.is_a?(Hash) && message[:content].is_a?(Array) skips messages whose content is a string. Tool messages in OpenAI's chat completions format can have string content; if a message was not transformed by the base sanitizer, its content key might still be a string, causing the normalization to be silently skipped.

[managerbot-app]

block.merge(id: normalized_id) always uses a symbol key :id, which could conflict with an existing string key "id" if the block came in with string keys, resulting in duplicate keys with different types.

[managerbot-app]

For tool_result blocks, the fallback normalize_tool_call_id(original_tool_use_id, target_provider: target_provider) is called when the id is not found in id_map. This means if the corresponding tool_use block was in a different message that was skipped (e.g. non-Array content), the id could be incorrectly normalized independently without the mapping context, leading to a mismatch.

[managerbot-app]

Marshal.load(Marshal.dump(base_transcript)) is used for deep cloning. This is fine functionally, but Marshal can fail on objects that don't support serialization. Consider using a pure Ruby deep-dup approach (e.g. JSON.parse(base_transcript.to_json)) for safety with plain Hash/Array structures.

[managerbot-app]

Same Marshal.load(Marshal.dump(...)) concern as in handoff_live_test.rb. Prefer a JSON round-trip for deep cloning plain data structures.

[managerbot-app]

tool_state.any? || last_item[:type] == "function_call" — if tool_state is truthy but the actual response did not involve tool calls (e.g. stale state from a previous turn), this could incorrectly return "tool_use" as the stop reason. Ensure tool_state is properly reset between turns.