Codex PowerShell audit-log append can write UTF-16LE tails and force an H-05 override

[SUaDtL]

Problem

On Windows PowerShell 5.1, using the H-05-sanctioned >> append path against an existing UTF-8 .codearbiter/sprint-log.md wrote the new record as a UTF-16LE tail. This introduces NUL bytes, makes the audit log binary to text tools, and requires a destructive, logged H-05 override to restore the proven prefix and re-append the same record as UTF-8.

This has now happened more than once in governed Academy work.

Reproduction

1. Start with an existing UTF-8 append-only audit log.
2. Append a Markdown sprint entry from Windows PowerShell 5.1 using >>.
3. Inspect the appended bytes: the new tail is UTF-16LE while the existing file remains UTF-8.

Impact

• H-05 correctly disallows ordinary patch edits to audit logs.
• The currently suggested >> remediation can itself corrupt encoding on Windows PowerShell 5.1.
• Recovery needs a one-time override, exact byte boundary/prefix proof, and UTF-8 re-append.

Requested fix

Update the H-05 guidance/hook-safe append recipe to use an explicit UTF-8-no-BOM append mechanism that is safe in Windows PowerShell 5.1 (and document verification). The hook should not direct users to a mechanism that writes UTF-16LE by default.

Evidence from this occurrence

The corrupted SD-139 tail was exactly 1,892 bytes beginning at byte 405,681. Its pre-append prefix SHA-256 was verified before repair; the override and corrected UTF-8 append are logged in the repository audit trail.