Reach compiler and Docker runtime: who should own image version pinning for reproducible builds?

Integration boundary

We are adopting Reach (reach.sh) for a DApp project and want a repeatable development environment across laptops and CI. Reach distributes its compiler and standard library as Docker images invoked through the ./reach wrapper script, so the host only needs Docker. That makes the boundary between the Reach toolchain and the Docker runtime the place where reproducibility either holds or silently breaks.

Goal and constraints

Our goal: two machines running the same .rsh source should produce identical compilation output and behave identically against the local devnet. The uncertainty is that the wrapper appears to select image versions, but it is unclear whether it pins mutable tags or content-addressed digests. Tags can drift when re-pulled, so "same Reach release" may not mean "same images." Compilation output also depends on the chosen connector (Algorand vs Ethereum-style), so pinning must cover both compiler and connector. Some of our machines sit behind a corporate proxy, and one developer uses rootless Docker, which may change devnet networking assumptions.

Questions

• Does the Reach wrapper resolve images by tag or digest, and is recording the resolved digest per release the recommended way to anchor reproducibility?
• Is pinning the Reach release version plus connector sufficient, or should we override image references ourselves for byte-identical builds?
• Are rootless Docker or proxied registries known to break the wrapper's devnet networking assumptions?