The previous commit's fx.sh was silently checked out with CRLF line
endings because this clone's core.autocrlf was true -- git converted
LF to CRLF on checkout, and every subsequent edit/copy carried that
corruption forward. Undetected by `sh` on the dev host (tolerant of
CRLF), but busybox ash on the actual AdaptiveOS target is not: booting
the resulting apkovl produced real syntax errors and ": not found" on
every corrupted line, confirmed by testing the rebuilt ISO in QEMU.
Fix: stripped all CR bytes, set core.autocrlf=false locally, and added
.gitattributes (* text=auto eol=lf) so this can't recur for any future
clone regardless of the cloning user's global git config.
Previously fx() stripped the "[source-label]" prefix before handing a
chosen fix to f(), so once a fix landed in p, a manually-typed fix, a
locally-known fix, and an LLM-guessed fix (70-local-llm.sh,
80-remote-api.sh) were byte-for-byte indistinguishable. That silently
undermines 80-remote-api.sh's own documented trust boundary, which
requires LLM-sourced fixes to stay visually distinguishable from
verified ones -- and the distinction was permanently lost once p is
disk-persisted across a reboot (adaptive-loop.sh).
fx() now records "cmd=source-file" to FX_TRACE_FILE (default ./p.trace)
alongside every fix it hands to f(), using the same "record intent, not
confirmed success" timing f() already uses for p itself. Verified
end-to-end against a stub 80-remote-api.sh-style source: p and p.trace
both populate correctly, and the retried command actually succeeds.
Daveswo