Verify a Wit-produced .als actually opens in Ableton Live

[sepehrsadri]

Wit has never been verified to produce a file that a DAW will actually open. Everything else in the project is downstream of this: if a merged or restored .als is rejected by Ableton Live, the design does not work.

What we know today

docs/EXPERIMENTS.md §5 records a clean 3-way merge of two disjoint edits that produced a structurally valid, re-gzipped 431 KB .als. It parses as XML and round-trips. It has never been opened in Live, because no DAW was launched during the research.

The task

1. Reproduce the merge from EXPERIMENTS.md §5 (base = save 5, "Alice" = save 6, "Bob" = save 5 with one different track's volume changed).
2. Open the merged file in Ableton Live.
3. Report: does it open? Are both edits present and correct? Any warnings, missing devices, or silent data loss?
4. Repeat for a file that has only been round-tripped (gunzip → gzip, no edits) to isolate whether any failure comes from merging or from repacking.

Why this is a blocker

If round-tripping alone corrupts a set, that is a much more fundamental problem than merge semantics, and we need to know which one we have.

Please report the exact Live version. Do not test on work you care about — copy the project first.

[sepehrsadri]

Scope note (M0.5 truth-up): this blocks the write-path roadmap (docs/ROADMAP.md → "After 0.0"), not the 0.0 pilot. The 0.0 slice is read-only by design (ADR-0006) — no Wit-produced project file is ever written, so "does a restored project open in the DAW" doesn't apply until Phase 1 resumes.