portability-auditlisted

# portability-audit Most "cross-platform" tools were only ever run on their author's platform, and the first user on the other one hits a wall of dumb, fixable breakage. The hazards are boring and finite — this is a *sweep with a checklist*, not detective work. Grep for each class, verify each hit is a real problem in context, fix it with the idiomatic construct. ## The hazard classes (sweep in this order — ordered by how often they actually break) **1. Shelling out to platform-specific commands.** Search subprocess/exec/spawn/system/backtick calls for `rm -rf`, `cp`, `mv`, `mkdir -p`, `which`, `grep`, `sed`, `awk`, `touch`, `cat`, `curl | sh`, `chmod`. Each has a stdlib replacement (`shutil.rmtree`, `fs.rm`, `os.makedirs`…) — prefer that over a Windows-conditional. Also: `sh -c` doesn't exist on Windows; `shell=True` means *different shells* on each platform, and `cmd.exe` quoting is its own hazard. **2. Path construction and comparison.** - Hardcoded separators: strings built with `'/'` mostly work on Windows APIs but break on display, comparison, and mixed input; `'\\'` breaks everywhere else. Use the path library (`pathlib`, `path.join`/`path.sep`, `filepath.Join`). - Splitting on `'/'` or `':'` (PATH uses `';'` on Windows — use the stdlib's `os.pathsep`, `path.delimiter`). - Comparing paths as strings: case-insensitive filesystems (Windows, default macOS) mean `C:\Foo` == `c:\foo`; normalize before comparing. - Hardcoded `/tmp`, `~`, `$HOME` (use the platform temp/ho