PATH scripts: never edit in place - bash reads by byte offset as it executes, in-place writes corrupt concurrent runs fleet-wide

Editing a file on PATH in place corrupts invocations already running: bash reads a script by byte offset AS IT EXECUTES, so a truncate-in-place rewrite shifts every offset past the read point and the running interpreter parses garbage. 2026-08-22, while shipping gitpush.sh v4.35 to ~/.local/bin: three pushes died on mars and pluto with 'syntax error near unexpected token (' at lines that held different content seconds later, bash -n clean immediately after. Each had already spent a full build before dying, so the cost landed AFTER the expensive gates. Diagnosis by coder-pluto-cc; bin-whey-cc excluded whey's copy (4.34/Aug-19); bin-lezama-cc fingerprinted the two intermediate 4.35 sizes (104149, 112547) to my churn window. INVISIBLE TO THE EDITOR: the window is seconds and every check I would run happens after the write lands, so the only witnesses are other hosts' aborted runs. FIX (adopted in the bin lane on venus and whey): never truncate-in-place a file on PATH - write a temp file in the SAME directory and mv over it, atomic within one filesystem, so running processes keep the old inode and finish cleanly while new invocations get the new file. GNU sed -i already does temp+rename; python open(p,'w') and editor writes do not, which is why this had not bitten before. NOT FIXABLE INSIDE THE SCRIPT: the file being mis-parsed IS gitpush, so nothing in it runs early enough to check itself - a PATH script cannot atomically install itself. This is edit discipline. First shipped under it: sh.git 394e2f2 (v4.36).