fix: goal_mode should not break on visible reply without tool_calls

[HouMinXi]

Problem

When a model produces a visible text reply but no tool_calls, the turn loop breaks immediately (process.rs:643). This is correct for normal sessions, but goal_mode has a documented contract: only task_status: done or task_status: question should end the session.

The existing should_retry_no_tool_task_status() already returns true for goal_mode, but the visible_reply break at line 643 fires first, making the retry path unreachable.

This causes models that don't include task_status in their first command_run batch (e.g. non-OpenAI models accessed via OpenAI-compatible endpoints) to have their goal_mode session terminated after a single visible reply.

Root cause

In the original squash commit (05e4bd4), there was no goal_mode and no visible_reply check. In v0.1.33 (a79d322), both were added simultaneously, but the visible_reply break was placed before the goal_mode retry logic. Since GPT-5.6 always includes task_status in its first command_run batch, the visible_reply path was never triggered, and the bug was never discovered.

Fix

In goal_mode, when visible_reply exists but no tool_calls are present, route through the existing retry mechanism instead of breaking. The retry is bounded by should_continue_no_tool_task_status_retry(), which respects the global manas_max_turns limit.

Testing

• Added 2 unit tests verifying the new behavior
• All 16 process.rs tests pass
• Smoke test: mimo-v2.5-pro completes a 6-turn coding task end-to-end (read → task_status doing → apply_patch → test → task_status done) with this fix applied

Verification

$ cargo test --package runtime --lib manas::process::tests
running 16 tests
... all 16 passed

Signed-off-by: Minxi Hou houminxi@gmail.com

[Yohjisakamoto]

hi, HouMinXi,
Thank you for the PR
The goal_mode feature has not been thoroughly tested, so it cannot currently be accessed through TUI commands. I suspect there may be other issues with this mode as well.

The existing balanced mode is already very robust. I once ran it continuously for 37 hours without encountering any issues. You can increase the maximum number of turns to use the Tura runtime for very long-horizon tasks. The default is 256, which means the runtime will be forced to stop on the 257th provider call.

This limit was introduced because earlier versions of Tura were less stable and could occasionally produce extremely long-tail executions, posing a risk when running long-horizon tasks.

I will not merge the PR for now, Because I think there will be other issues with the goal mode,A
Best
Y