[rwagwani]

Stacked on #335 (rejection messages and the cookbook spec fix). This PR's own change is the last commit.

Summary

Several transfer settings are accepted without any message in setups where the code never reads them, so users change them and get an unchanged video. Found while validating every parameter of Cosmos3-Nano-Sim-Transfer (checkpoint 23b77384) and Cosmos3-Nano on AV and Robotics inputs. Most of these limits are already in the docs; this PR makes the code say them at run time. It changes no generated video, and every shipped cookbook spec and Sim-Transfer skill request builds exactly as before, with no new warnings.

Warnings (no output change)

• A single-control weight: weights are normalised by their sum, and the causal Sim-Transfer path hard-codes 1.0.
• Single-view distilled causal Transfer: a table (_DISTILLED_TRANSFER_IGNORED_FIELDS) of fields the fixed-step sampler never reads (negative prompt, guidance, sigma_max, shift, normalize_cfg, num_conditional_frames, both guidance windows). It warns only when the sample or CLI sets a non-neutral value, not for values from a defaults file. Also a chunk size unlike num_frames, and model_mode other than video2video.
• --sampler other than unipc on any fixed-step checkpoint (checked once at model load).
• A reversed guidance_interval / control_guidance_interval (lo >= hi), only where that guidance pass would otherwise run.
• Single-view Transfer: a requested fps or num_frames that differs from what the source video gives. This is checked in generate_transfer_sample (and the streaming path), against the length and frame rate generation actually resolves, so there is no second copy of that logic. Also prompt_upsampling=True, and both negative_prompt and negative_prompt_file set explicitly.

Error

• Bidirectional single-view path: negative or all-zero control weights raise ValueError when the sample is built, instead of a bare assert inside build_transfer_batch. The causal path and joint camera+LiDAR transfer do not read these weights, so they are left alone.

Behaviour changes, stated plainly

• The only new error is the control-weight ValueError above. Those requests already failed, later, with a bare AssertionError after model load.
• A built OmniSampleArgs now records which fields the request set (a pydantic private attribute, requested_fields, not serialized), so generation can tell a request from a default. Pydantic includes private attributes in ==, so test_sample_args compares model_dump(). No production code compares samples with ==.

Not changed here (follow-up)

On normal Nano/Super, the built-in video2video defaults always supply a negative_prompt, so a request-level negative_prompt_file is never read, and a missing path is accepted. The cookbook specs set ../assets/negative_prompt.json, whose caption differs slightly from defaults/neg_prompts.json. Fixing this changes cookbook output (precedence, and resolving the path relative to the spec), so it should be its own PR.

Verification

• New L0 tests (transfer_shipped_specs_test.py, plus additions to existing files). They build all six cookbook specs and the six official Sim-Transfer skill requests (written by prepare_hf_sample.py, run with the skill's defaults file and CLI flags) through from_files + build_sample, and assert no errors and no [transfer] warnings. They do not need the Git LFS videos, so they run in CI. A separate spec-vs-video check (fps/num_frames match the asset) runs only where the LFS videos are checked out.
• Touched test files: 384 passed, 1 skipped.
• The CI unit-test job (-m L0, same command as gpu-tests.yml), replicated on a single GB300: running; I will add the result here.
• GPU, Cosmos3-Nano-Sim-Transfer with the skill command (official example2 depth and edge requests) and Cosmos3-Nano with the cookbook depth spec: no new warnings, and the same videos as main within same-seed run-to-run noise. A deliberately mis-set Sim-Transfer request (depth.weight=5, sigma_max=200, fps=10 on a 30 fps video) prints exactly those three warnings and produces the same video as on main.

🤖 Generated with Claude Code

[lfengad]

Thanks for the additional Transfer diagnostics. I reviewed the incremental change on top of #335 and did not find a blocking implementation issue in this pass. This should follow #335 rather than merge ahead of it, since the current diff includes that PR as well. Once #335 is merged, could you please update this branch so the remaining diff is isolated, then satisfy the current-main checks and required approvals? The earlier ValueError for already-invalid weights and the private request-field/equality change are intentional behavior differences, not just message edits; please retain those explicit notes in the description.