v0.5.0 — resumable transfer + agent skill

Resumable transfer, the agent CLI contract, and vendor-tolerant container parsing.

sendmecongo moves files out of a physically isolated machine in one direction only — a fountain-coded QR stream on the screen, a phone camera on the other side, and a byte-identical file at the end. No network, no USB, no Bluetooth.

Changes in v0.5.0

Resumable transfer (M2.1–M2.3)

• The receiver checkpoints every run — complete or not — as <recording>.smr.json plus <recording>.smr.bin next to the video, and --resume re-feeds those symbol payloads before the video is opened. The merge key is (session, object_len, symbol_size), so frames from a different preset are dropped at the protocol level. A partial run exits with code 2.
• A partial run now lands on a checkpoint screen: a per-block symbol grid, a retake ETA at the matching preset's rate, and a typeable SMR1 repair code (Crockford base32 + CRC-8, ~23 characters for a single block). Starting a recording whose namesake checkpoint exists resumes it automatically.
• The sender replays repair only: a repair-code box in the GUI (validated live against the prepared container and preset) and --repair-code in the player. A validated code replays only fresh repair symbols past the original broadcast's batch, so a retake takes seconds instead of a full cycle. Codes are re-validated before any window opens.

Agent-driven operation (M2.4–M2.5)

• Machine contract on both ends: --prepare-only dry run, --json aligned across send and recv (status: done|partial, received_file, resume_code, eta_seconds), --play accepted anywhere on the command line, and --file / --resume-code aliases. Documented in docs/AGENT.md.
• skills/sendmecongo/SKILL.md — a prompt plus the repo URL is enough for an agent to drive sending and receiving end to end.

Container parsing, from recordings that real users actually had

• Android recordings carrying vendor blobs around the moov are readable again. Huawei appends a private metadata run after the movie whose first eight bytes parsed as a 1.8 GB box, so a perfectly good recording was refused with box size out of range even though the moov had been found one step earlier. Two more shapes were fixed alongside it: a blob parked before the moov made a readable file report not an MP4/MOV file, and a tail whose bytes happened to line up as a moof made an ordinary recording report fragmented movie, unsupported.
• A bad size at the top level now ends the walk and keeps what was already found, while a tree we are already inside still has to be sane. What a file is gets decided from the moov first: samples in hand mean a plain movie, whatever the tail parses as.
• Legacy AGQ / AGC1 headers are still accepted, so older test recordings keep decoding.

Tooling

• tools/verify-recv.sh --smoke — a baseline-free pass that only asks whether each recording opens and runs to the end (exit 0 and 2 pass, 1 fails). System-camera recordings cannot have a byte-for-byte baseline, because their original never leaves the isolated machine, so they could not enter the acceptance matrix at all — which is how these container bugs reached a user instead of a red test. Both passes now feed the receiver through a symlink under out/, so resume checkpoints stop landing in recordings/.
• README pipeline diagram renders as mermaid.
• 107 unit tests green across the workspace.

Assets — macOS (Apple Silicon, .app inside a DMG)

File	Size	SHA-256
sendmecongo-send-0.5.0.dmg	4.42 MB	75B24C1543B3C05733867786DD6AA7FF043AD98AD849646E1B79BCB0BC9B4FAA
sendmecongo-recv-0.5.0.dmg	4.71 MB	863971B3F3A77F7BBF9ED76BB6E733BE101C9501B5497018EBD162A7B7EE2558

Assets — Windows x86_64, standalone exe

File	Size	SHA-256
sendmecongo-send.exe	18.51 MB	207996AE9D63D56C2918376D07759A98E6DA3DAA9B428FD9576EE3220CA2C4DB
sendmecongo-recv.exe	19.90 MB	B7466EE2B0F97137FED4C0D86EA070436BC3B4824F82EDC96910912D83BACC31