Module publish 

fdl publish: put a run where the fleet can pull it — resolve a source spec into a served directory, build it once as a gate, and write the manifest that makes the controller the authority for what a run is. fdl publish — put a run where the fleet can pull it.

The controller side of compiling on the node. It resolves a source spec into a served directory, builds it once, and writes the run manifest workers read. Chaining trainings on a standing fleet is then one command: publish again and every box picks the new run up on its next dial, with nothing to edit on any worker.

The build is validation, not an artifact. One build gates the publish; each worker still compiles its own, because a controller producing binaries for N worker variants is the build matrix this design deleted. A gate needs no GPU libtorch either — compiling without a GPU feature against the cheap CPU variant catches user-code errors just as well — so the cost of having it on by default is rustup plus fdl libtorch download --cpu. What it buys is that a tree which cannot compile never reaches the fleet, where N boxes would each discover it separately, in logs nobody is watching.

It proves the tree for the CONTROLLER’s variant only. A break that exists solely under --features rocm passes a CUDA gate and lands on a worker; superset check, not a proof.

Functions

run

Run fdl publish. args_tail is everything after a standalone --: the training binary’s own arguments, which belong to the RUN and therefore to the manifest rather than to any worker’s config.