Found by readback_final.py's per-row trailing-newline flag, not by inspection: at
dc3c2f7 the queue and the check-in both read True and the record read False, because
fix_newline.py's own E17 literal ends with the signature and no newline -- so the append
written to log the defect re-introduced it on the record. Fixed by writing one newline
byte; no line of content moved. Record 33,064 B / cfb71db33761... -> 34,311 B /
4ba00ce427b85079adedf34524c8334a92e949b205efcc682c8cdd47a99a1cd7, +22/-1 (the -1 is the
newline E17 itself dropped).
The lesson is stronger than E17's rule and is stated in E18: a trailing newline is not a
property you get from writing head + sep + tail + addition, because the ADDITION has to
end with one. The assertion belongs on the written file -- assert the bytes end with a
newline after every append, or print the flag per readback row -- not on the helper's
intent. Both instances are measured in E18 and neither is deleted.
Nothing deployed, no cp into /root/.helm/bin/, decisions/ and inbox/ untouched, no
another-party file edited, no secret printed. Live state unchanged: snapshot 14,039 B /
aa842b0fd88037f8... / mtime_ns 1791479579475780303, held pin 120 B / 5b6d70716153c3f4...
/ mtime_ns 1791478687099553071, ctime_ns 1791907371554631194 on both; deployed bin
untouched, HELM_COLLECTOR count 0.