fix(provider/compatible): preserve reasoning_content for plain-text assistant turns - #6284

Checked PR #6284 at head 99b7701, the full single-file diff, #6233, #6059, #6269, the top-level/inline/formal review threads, CI status, and adjacent source in crates/zeroclaw-providers/src/compatible.rs and the runtime history builders. There are no prior comments or active review blocks, and CI is green. I did not run local cargo; this pass relies on CI, the author's stated validation, and source inspection.

🔴 Blocking — Plain JSON answers with a content key are no longer replayed verbatim

The new branch accepts any assistant message JSON that has either content or reasoning_content and no tool_calls. That fixes the DeepSeek replay envelope when reasoning_content is present, but it also changes ordinary assistant text that happens to be JSON with a content key.

ChatMessage::content is an opaque string, so a model can legitimately answer with structured JSON. For example, a structured-output assistant answer like {"content":"raw"} used to fall through to the plain-text path, so the next request replayed the original JSON string. With this PR, the new branch treats it as a ZeroClaw replay envelope and sends only raw. If the JSON has a non-string content, the branch can return a native assistant message with no content at all. Both cases change conversation history that is not part of the reasoning_content fix.

The narrow fix is to require an actual parsed reasoning_content field, or another explicit replay-envelope signal, before taking this no-tool branch. Please also add a regression test where assistant content is JSON with a content key but no reasoning_content, and assert that it still falls through verbatim. If content-only JSON is intended to become an internal replay envelope too, that is a broader history-format change and needs to be documented and tested separately from this DeepSeek preservation fix.

🟡 Warning — PR body references a stale gate name

The rollback section says this behavior is gated on an existing support_reasoning_content argument, but the current convert_messages_for_native argument is allow_user_image_parts. Please update that text so the risk and rollback notes match the code being reviewed.

🟢 What looks good — the intended #6233 slice is correctly isolated

The PR is otherwise scoped to the right layer for the original #6233 replay bug. The added positive-path test covers the DeepSeek no-tool-calls envelope, and the unrelated-JSON fallback test is the right kind of guardrail; it just needs the content-key structured-output case as well.

First review of head c2d0090. I read the PR body, the full diff (single-file, crates/zeroclaw-providers/src/compatible.rs), Audacity88's CHANGES_REQUESTED, Audacity88's follow-up comment, and all four regression tests. CI is 13/13 green.

Audacity88's CHANGES_REQUESTED is still formally active on GitHub. Audacity88 explicitly states in their latest comment: "I think this resolves my previous blocker, but I am not submitting an approval review on a head that now includes my maintainer commit." Because their formal review has not been dismissed, I cannot post an approval here per protocol — but I can confirm what the current code does and clear the path to merge.

✅ Resolved — Audacity88's 🔴 block: plain JSON with content key falls through verbatim

The narrowed guard in the current diff requires reasoning_content to be present and to be a string (.and_then(serde_json::Value::as_str)). An assistant message like {"content": "raw"} has no reasoning_content key; as_str() returns None; the let Some(reasoning_content) = ... binding fails; the branch does not fire; the message falls through to the plain-text path and the original JSON string is preserved verbatim on replay. ✓

The four regression tests pin this correctly:

• convert_messages_for_native_round_trips_reasoning_content_without_tool_calls — DeepSeek-style envelope with both fields fires the branch ✓
• convert_messages_for_native_content_only_json_falls_through — {"content": "raw"} (no reasoning_content) falls through verbatim ✓
• convert_messages_for_native_non_string_reasoning_content_falls_through — reasoning_content: null falls through verbatim ✓
• convert_messages_for_native_unrelated_json_falls_through — {"foo": "bar"} falls through verbatim ✓

✅ Resolved — Audacity88's 🟡 warning: stale gate name removed from PR body

The rollback section no longer references a support_reasoning_content argument. It describes the behavior correctly: "limited to native compatible-provider history conversion for assistant JSON payloads that carry string reasoning_content." ✓

🟢 What looks good — branch ordering is correct

The new no-tool branch sits after the existing tool_calls branch (which handles JSON with tool_calls) and before the tool role branch and plain-text fallback. Tool-call assistant turns still win at the earlier branch and are unaffected. The ordering is correct and the code comment at the new branch explains the DeepSeek V4 replay requirement clearly.

Path to merge

@Audacity88 — your formal CHANGES_REQUESTED at the prior head is the only remaining gate. If you're satisfied that the current code resolves your block, dismissing your review or posting a new approval at this head would clear the path. Alternatively, another maintainer with review-dismiss permission can dismiss the stale block. Everything I've read on this head is ready.

Approved. I rechecked the current head after the follow-up commits and the stale blocking review was dismissed. The Compatible plain-text replay path now preserves reasoning_content for assistant turns while keeping the existing content fallback behavior, and the regression coverage is aligned with the provider helper behavior.

CI is green on the current head, and the previous blocker is resolved.