We had trainers for SD1.x/SDXL, Z-Image and Wan — none for the architectures the
LoRAs people actually publish for video today. All three new ones are the same
training problem as Wan (encode references to VAE latents, encode the prompt once,
adapt the transformer's attention projections, regress the rectified-flow
velocity), so rather than a fourth, fifth and sixth copy of that loop there is one
shared _train_flow_dit driven by a per-architecture description in
codai/api/lora_archs.py: which classes to import, the latent shape, the timestep
shift, the text-encoder contract.

Selection: `target` accepts image | video | wan | ltx2 | h3 | krea. `video` keeps
meaning Wan for existing configs but now reads the model id, so an LTX-2 or H3 path
routes itself; the explicit names force one. The character studio exposes the same
choice as --target and a dropdown.

Availability differs per architecture and fails with a message that says so rather
than an ImportError from inside a training job: LTX-2 works on this diffusers
(0.38 has LTX2VideoTransformer3DModel + AutoencoderKLLTX2Video), while H3 and
Krea 2 need >= 0.40 — and Krea 2 additionally needs access to the gated
krea/Krea-2-* weights.

Verified: architecture detection and routing for every target/model combination,
and that each trainer's classes either load or explain what they need. NOT run
against real weights for any of the three — the contracts match the proven Wan
path, but the first real run should be treated as a debugging session.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY