veomni-develop

## Impact Analysis Before implementing, check which areas your change affects: | Area | What to check | Why it matters | |------|--------------|----------------| | `veomni/trainer/` | All trainer subclasses (`TextTrainer`, `VLMTrainer`, `DitTrainer`, RL trainers) | Changing `BaseTrainer` method signatures breaks all subclasses | | `veomni/data/data_collator.py` | All modalities (text, VLM, DiT) | Collators are tightly coupled to model-specific preprocessing | | `veomni/distributed/` | Both FSDP2 and legacy FSDP1 paths | Shared distributed code is used differently by each path | | `veomni/models/auto.py`, `loader.py` | Model registry, import-time side effects | `MODELING_REGISTRY` is populated at import time; moving registrations breaks loading | | `configs/` | YAML config keys | Renaming config keys breaks existing training configs silently | | `veomni/models/transformers/*/` | `__init__.py` version gates | Models have v4/v5 transformers branches; changes must work on both | ## Refactoring Safety Rules When restructuring code (same behavior, better structure): 1. **Baseline first**: run `pytest tests/` before any change, record results. 2. **One change per commit**: ONE structural change → update ALL callers → verify tests match baseline → commit. 3. **Never batch multiple refactoring steps into one commit.** 4. Check baseline again at the end — results must be identical. ## Common Traps - `veomni.models.auto` registration depends on **import-time side effects** — movi...