A crash mid-write no longer corrupts your transcript; the truncated line is repaired on the next append.
What's wrong with this entry?
Appending to a transcript now detects a last line that was cut off mid-write and writes a leading newline plus a substitute record before adding the new one, so a crash mid-append no longer corrupts what follows.
- A tear is detected from a missing trailing newline or a torn byte count reported by the storage layer.
- When the storage layer is not active, the append falls back to opening the file read-write/append and probing before writing.
- Errors are classified, and recoverable ones note that the synchronous re-stamp runs instead.
the synchronous re-stamp runs instead
Strings lifted out of the shipped bundle, so the claim above can be checked against them.