Increase data-agent GRPO completion budget

[bingran-you]

What changed

• Raises the full Qwen3.5 data-agent recipe's aggregate GRPO completion budget from 16,384 to 40,960 tokens.
• Allows only a non-decreasing runtime.max_completion_length change when resuming a persisted run.
• Keeps dataset, model, reward, optimizer, LoRA, and epoch settings immutable.
• Documents that an interrupted GRPO stage restarts cleanly from the saved SFT checkpoint after the budget increase.

Why

The live strict red-wine run completed 16/16 teacher coverage, one-epoch LoRA SFT, and a 15/16 GRPO gate. GRPO then failed on a valid reward-1 OpenCode rollout because its exact causal sequence contained 37,367 tokens including masked tool feedback. Both retries for a later rollout were about 37.1k, so the existing 16k cap is below normal data-agent trajectories.

The bridge already fits each served model prompt to 49,152 tokens and the SFT recipe supports 40,960-token rows. Matching the aggregate rollout budget to 40,960 accepts these healthy traces while remaining below the server context contract.

The failed GRPO stage had loss=0, grad_norm=0, and zero reward variance through its first eight steps, so restarting from the preserved SFT checkpoint loses no learned GRPO update.

Validation

• 223 package contract tests pass.
• 87 focused config/pipeline tests pass.
• Ruff check/format, Python compilation, and git diff --check pass.
• The red-wine v3 recipe validates and plans with max_completion_length=40960.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e39ef31640

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Invalidate GRPO when accepting budget increases

When --resume is used on a run that already produced grpo-merged/train_metrics.json under the old limit, this compatibility check accepts a larger runtime.max_completion_length; _train_grpo can then reuse the existing checkpoint because _grpo_checkpoint_is_current does not compare the completion budget. The updated plan/score can therefore claim the new rollout cap while the model and evaluations still come from the old cap, so completed runs should be rejected or have GRPO artifacts invalidated when this field changes.

Useful? React with 👍 / 👎.