Function resolve_docker_service 

pub fn resolve_docker_service(name: &str, project_root: &Path) -> String

Resolve a docker: value to a concrete docker-compose service.

Only gpu is logical; every other value passes through untouched, so docker: cuda and docker: rocm remain explicit escapes for anyone who wants to pin a container regardless of the active variant.

Why the container cannot simply BE vendor-neutral the way the cargo feature is: both vendors build from one source tree, so a feature is derivable, but a CUDA image (nvidia/cuda base, nvidia runtime, /dev/nvidia*) and a ROCm image (rocm/dev-ubuntu, /dev/kfd + /dev/dri, render group) are genuinely different artifacts. A service that declared both device sets would fail to start on a host missing either. So the service must be selected, and this is where.

The AMD arm falls back to the CUDA container with a message when no rocm service is defined. This repo and fdl init’s scaffolds both define one now, so the fallback is for a project whose docker-compose.yml predates it (or was hand-trimmed). It stays a message rather than an error because landing in the CUDA container produces the better diagnostic: flodl-sys then reports exactly which part of its ROCm path is missing, where compose’s bare “no such service: rocm” would say less.