fix: Ban qwen3 tito model and handle non-tool appended messages in TITO dummy assistant

[guapisolo]

Summary

• Globally ban --tito-model=qwen3 — Qwen3's context-sensitive template (last_query_index, <think> block) breaks the dummy-prefix diff, producing wrong incremental tokens. Raises ValueError at arg validation with a clear message.
• Remove the reasoning_content: " " workaround from _build_dummy_assistant (no longer needed with Qwen3 banned)
• _build_dummy_assistant now counts all tool messages in appended (not just leading contiguous), using tool_indices for correct indexing
• Adds test_dummy_prefix_match (GLM47-only) to guard the prefix invariant
• TITO parametrized tests scoped to GLM47 only

Test plan

• 48 tests pass (GLM47 parametrized + Qwen3 boundary + factory)
• Verified GLM47 prefix match for all trajectory × split combinations
• Verified ValueError raised when --tito-model=qwen3

Made with Cursor

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the _build_dummy_assistant function to correctly handle leading tool messages within appended_messages, ensuring proper turn-transition tokens are rendered. Feedback suggests restoring the reasoning_content field to maintain consistency with reasoning models and simplifying the tool_calls list comprehension using enumerate on a slice of the messages.

[gemini-code-assist]

The reasoning_content field was removed from the dummy assistant message. This field was present in the previous implementation (line 32) and is often necessary for reasoning models to correctly render turn boundaries (e.g., to ensure the reasoning block is closed). Unless its removal was intentional to fix a specific issue, it should be restored.

Additionally, the tool_calls generation can be simplified using enumerate on a slice of appended_messages.

Suggested change

	assistant: dict[str, Any] = {"role": "assistant", "content": ""}
	if num_leading_tools > 0:
	assistant["tool_calls"] = [
	{
	"id": resp.get("tool_call_id") or f"call0000{i}",
	"id": appended_messages[i].get("tool_call_id") or f"call0000{i}",
	"type": "function",
	"function": {
	"name": resp.get("name") or "dummy_func",
	"name": appended_messages[i].get("name") or "dummy_func",
	"arguments": {},
	},
	}
	for i, resp in enumerate(tool_responses)
	],
	}
	for i in range(num_leading_tools)
	]
	assistant: dict[str, Any] = {
	"role": "assistant",
	"content": "",
	"reasoning_content": " ",
	}
	if num_leading_tools > 0:
	assistant["tool_calls"] = [
	{
	"id": msg.get("tool_call_id") or f"call0000{i}",
	"type": "function",
	"function": {
	"name": msg.get("name") or "dummy_func",
	"arguments": {},
	},
	}
	for i, msg in enumerate(appended_messages[:num_leading_tools])
	]

[maocheng23]

For my sanity check, now our TITO would only support GLM style? Can we still keep it flexible somehow?

If it would be too hard to support Qwen3 chat template, I think it's still good here

[maocheng23]

And we don't need reasoning_content any more?

[guapisolo]

For my sanity check, now our TITO would only support GLM style? Can we still keep it flexible somehow?

If it would be too hard to support Qwen3 chat template, I think it's still good here

This walkaround for glm 4.7 break qwen impl. Need fix to qwen3 chat template. Unblock TITO dev.