Sure, but the pojt here is that if we say "Write in X" we generally understand it to mean "Treat X like a standard and don't get too colloquial with the stylings."

Pedantry is worthwhile, but it can be a diminishing returns game.

    The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of POSIX.1-2017. If the first line of a file of shell commands starts with the characters "#!", the results are unspecified.

    Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in. [...]

    Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed). For example:

        #
        # Installation time script to install correct POSIX shell pathname
        #
        # Get list of paths to check
        #
        Sifs=$IFS
        Sifs_set=${IFS+y}
        IFS=:
        set -- $(getconf PATH)
        if [ "$Sifs_set" = y ]
        then
            IFS=$Sifs
        else
            unset IFS
        fi
        #
        # Check each path for 'sh'
        #
        for i
        do
            if [ -x "${i}"/sh ]
            then
                Pshell=${i}/sh
            fi
        done
        #
        # This is the list of scripts to update. They should be of the
        # form '${name}.source' and will be transformed to '${name}'.
        # Each script should begin:
        #
        # #!INSTALLSHELLPATH
        #
        scripts="a b c"
        #
        # Transform each script
        #
        for i in ${scripts}
        do
            sed -e "s|INSTALLSHELLPATH|${Pshell}|" < ${i}.source > ${i}
        done

It definitely builds outside docker. It's a musl-cross-make toolchain, you can procure the dependencies locally if you don't like the Docker recipes.

Feel free to open an issue if you feel like that's a challenge. Likely, you can get it to work but checksum reproducibility will be hard without a controlled environment like docker.