spike(rust/verify): cross-machine verification and retro note

[natashaannn]

User story

As a team member evaluating RFC 0001 (tracked in #90), I want verified cross-machine output and a written retro note, so that the team has a concrete go/no-go recommendation on adopting Rust + agent-driven development before committing to the full rewrite.

Background

RFC 0001 (#90) proposes rewriting the editing pipeline in Rust. To validate that approach, the team ran a spike: port the FFT cross-correlation algorithm from scripts/sync/AudioSyncer.js to a standalone Rust binary (spike tracked in #93).

This is the final issue in the spike. By this point the Rust binary is building and its fixture round-trip test passes on the development machine (#99). This issue runs the same binary and test suite on all three target machines from RFC 0001 §Verification approach and then captures the qualitative findings in a retro note — the primary deliverable of the entire spike.

Target machines:

• Mac M2
• Mac M3
• Windows with NVIDIA GPU

Acceptance criteria

Happy path

Given the spike branch is checked out on Mac M2, Mac M3, and Windows/NVIDIA
When cargo build --release and cargo test are run on each machine
Then all three machines produce identical lag output for the fixture files, and a comment is posted on this issue for each machine documenting the exact output

Given all three machines have been verified
When spike/RETRO.md is written and committed
Then the file ends with an explicit Go or No-go recommendation on proceeding with RFC 0001 Phase 1

Error path / edge case

Given one machine produces a different lag output than the others
When the discrepancy is investigated
Then the root cause is documented in the retro note — this is a finding, not a blocker on closing the issue

Out of scope

• Fixing any discrepancy found during cross-machine runs — document and move to a follow-up issue
• Performance benchmarking — this spike is about correctness and developer ergonomics only
• Cross-compilation (building on one machine for another) — native builds only

Technical context

Commands to run on each machine (from the repo root, on the spike branch):

# Install Rust if not present:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup default stable

# Build and test:
cargo build --release --manifest-path spike/audio-sync/Cargo.toml
cargo test --manifest-path spike/audio-sync/Cargo.toml

# Run against fixtures:
cargo run --release --manifest-path spike/audio-sync/Cargo.toml \
  -- spike/audio-sync/fixtures/video-audio.wav \
     spike/audio-sync/fixtures/audio-track.wav

What to record per machine: copy the full stdout+stderr of cargo test and the binary run into a comment on this issue. Flag if any test fails or if the lag output differs from the Mac M2 baseline.

Retro note content (spike/RETRO.md):

The retro note must address these questions directly (it is the input the team needs to decide whether to proceed):

1. What did the agent-driven Rust dev loop feel like in practice? Were the compiler errors actionable? Did the agent iterate successfully without human intervention on most cycles?
2. What did the Rust compiler catch that would have been a runtime bug in JS or Python?
3. What required human review that the agent got wrong or couldn't fix?
4. Was the Cargo toolchain setup straightforward across all three machines, or were there friction points?
5. Go/No-go: should the team proceed with RFC 0001 Phase 1 (render/compositing engine in Rust)? State this as a clear recommendation, not a list of tradeoffs.

Implementation details

1. Checkout the spike branch on Mac M2. Run the three commands above. Post the output as a comment on this issue.
2. Checkout the spike branch on Mac M3. Run the same commands. Post the output as a comment. Note whether the lag matches Mac M2 exactly.
3. Checkout the spike branch on the Windows/NVIDIA machine. Run the same commands (install rustup if not present — use rustup-init.exe on Windows). Post the output as a comment. Note whether the lag matches Mac M2 exactly.
4. Write spike/RETRO.md addressing the five questions above. The final line must be either **Recommendation: Go** or **Recommendation: No-go** with a one-sentence reason.
5. Commit spike/RETRO.md.
6. Close this issue and the parent spike(rust): port AudioSyncer FFT correlation to Rust to validate agent-driven dev loop #93 once the retro is committed.

Additional test scenarios

• N/A — this issue executes existing tests on new machines; it does not write new tests

Hard constraints

• A comment documenting the output must be posted for all three machines before the retro note is written — the retro must reflect actual observed behavior, not anticipated behavior
• spike/RETRO.md must end with an explicit Go or No-go line — an inconclusive summary is not acceptable
• No changes to files outside spike/RETRO.md

Dependency issues

Depends on #99 (CLI binary + fixture round-trip test must pass on the development machine before cross-machine runs begin).
This is the final issue in the spike — nothing depends on it.

[missabawse]

Mac M2 results

Machine: MacBook Pro, Apple M2, macOS 14 (Sonoma)
Branch: spike/issue-99-cli (post #99 merge)

cargo test

running 19 tests
test tests::find_best_lag_negative_half_frame_regression ... ok
test tests::find_best_lag_all_zeros_no_panic ... ok
test tests::cross_correlation_single_sample_length_one ... ok
test tests::find_best_lag_negative_lag ... ok
test tests::cross_correlation_all_zeros_no_panic ... ok
test tests::find_best_lag_peak_at_n_over_2_is_positive ... ok
test tests::find_best_lag_positive_lag ... ok
test tests::cross_correlation_identical_inputs_peak_at_zero ... ok
test tests::next_power_of_two_known_values ... ok
test tests::cross_correlation_impulse_peak_at_k ... ok
test tests::find_best_lag_tie_break_earliest_wins ... ok
test tests::find_best_lag_positive_lag_nonzero ... ok
test tests::validate_peak_flat_array_returns_not_reliable ... ok
test tests::validate_peak_length_one_no_panic ... ok
test tests::validate_peak_high_snr_returns_reliable ... ok
test tests::validate_peak_zero_std_no_panic ... ok
test tests::validate_peak_negative_lag_modular_wrap ... ok
test tests::find_best_lag_one_frame_at_44100 ... ok
test tests::fixture_roundtrip ... ok

test result: ok. 19 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 13.02s

Binary output

lag: -6.800000s  snr: 9.815

Matches baseline.json (lagSeconds: -6.8, snr: 9.815...) exactly. ✅