Crash recovery from a journal
Recovery is: load the newest snapshot, then replay the journal from its sequence number + 1. Crash the writer mid-frame, flip a bit in an old frame, and watch the scan decide between "truncate and carry on" and "stop loudly".
The model: 32 week-9 commands (Add, Reduce, Cancel) are encoded into real frames. The repo's journal (crates/journal) writes [len u32][seq u64][crc u32][payload] with a CRC-32/IEEE over the first 12 bytes and the payload; the week 9 and 18 drills use CRC-32C with the CRC first or last. Switch layouts: the scan is the same. The file grows on append (not preallocated), so a crash leaves a prefix of the frame in flight. After every N-th command the engine writes a snapshot (tmp + rename, so it is all or nothing) labelled with last_seq and its state hash. Recovery follows the week 18 rules: an empty end or a frame that runs past EOF is a torn tail (truncate to valid_len, fsync, resume); a bad CRC with non-zero bytes after it, or a sequence gap, is mid-log corruption (refuse to start). A bad CRC on the very last frame looks exactly like a torn write, so it is truncated too. The state hash is FNV-1a 64 over week 9's canonical bytes, which include the applied count. One segment is shown; recovery time ≈ snapshot load + tail ÷ replay rate, and at 3 M commands/s a snapshot every 100k commands bounds the tail at about 33 ms.