Keep the flight's source recordings in the S3 backup, with the recipe

[openipc-ai]

The two original recordings behind /low-latency's flight comparison (#401) are now backed up once in S3 at boards/flights/mabur-2026-10/ with a SHA256SUMS. I uploaded them from the host's verified copy and downloaded them back to check them; both match.

They go under boards/ because that is the prefix the backup's IAM user may write, and it sits outside the expiring daily/weekly/monthly rotation. media-sources/ is refused. The user cannot delete objects, so a 6-byte write probe stays at boards/flights/probe; it is documented.

tools/flight-ab/README.md now has the full recipe from those objects to what the page streams:

1. Fetch the recordings and verify them against SHA256SUMS.
2. Run run.sh with the poster moment.
3. Publish into v2.

It also lists the offset, window and stats a correct run reproduces. deploy/RESTORE.md points there.

Docs only; nothing deploys.

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Document S3-backed flight sources and the stream rebuild recipe

📝 Documentation 🕐 10-20 Minutes

AI Description

• Document the flight recordings’ one-time S3 backup, checksums, and retention location.
• Add a verified-source-to-published-stream recipe for restoring /low-latency after host loss.
• Correct the restore guide’s claim that the recordings are available only on the host.

Diagram

graph TD
  README["Rebuild recipe"] --> S3[("S3 source recordings")] --> VERIFY["Checksum verification"] --> RUN["Flight encoder"] --> MEDIA["Published media"] --> PAGE["Low-latency page"]
  RESTORE["Restore guide"] --> README

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Back up the rendered streams instead

• ➕ Restores playback without a lengthy rebuild or encoding dependencies.
• ➖ Stores a larger derived tree and does not preserve the originals needed to produce a new encoding ladder.

Recommendation: Keep the originals as the durable backup and rebuild the derived streams. This preserves the ability to regenerate or change the ladder while avoiding a backup of reproducible media; the trade-off is longer playback recovery after host loss. The diff documents this process but does not itself add S3 objects or deploy anything.

Files changed (2) +66 / -14

Documentation (2) +66 / -14

RESTORE.mdIdentify backed-up flight originals in the restore guide +11/-5

Identify backed-up flight originals in the restore guide

• Distinguishes the manually backed-up source recordings from the unbacked-up, reproducible media tree. Points operators to the flight rebuild recipe instead of saying the originals must be recovered from elsewhere.

deploy/RESTORE.md

README.mdDocument flight source objects and end-to-end rebuild steps +55/-9

Document flight source objects and end-to-end rebuild steps

• Records the S3 object paths, sizes, checksums, retention rationale, and undeletable write probe. Adds commands to download and verify the originals, regenerate the v2 streams, and publish them, plus expected results and versioning guidance.

tools/flight-ab/README.md