daw-smoke

daw-smoke — functional reload/editor verification in a real DAW (REAPER)

Use this when you need proof that a reload / editor / format-adapter behavior actually works inside a host, beyond what auval / pluginval / clap-validator give (those prove scan+load, not functional behavior).

Harness: tools/testing/daw-smoke/reaper_smoke.py (+ insert_and_float.lua and sequence_loop_seek.lua). The scraper + mode dispatch are unit-tested with no REAPER in tools/testing/daw-smoke/test_reaper_smoke.py. Full rules: docs/guides/daw-smoke.md. CLAUDE.md has the one-paragraph policy.

Modes (--mode, default reload)

• reload — the original flow. Seed watched DSP variant A, insert+float the FX, copy variant B over the watched path, scrape swapped DSP / reload rejected.
• live-plugin-swap — a live plugin-INSTANCE swap inside a Pulp host that hosts another plugin in a SignalGraph. Insert+float the host FX, write a swap request to --watched-swap-request, then scrape [live-swap] committed (PASS) vs live plugin swap refused (FAIL). The success marker is NOT logged by the core swap path — SignalGraph::prepare_swap logs ONLY refusals. The host plugin must emit [live-swap] committed itself from its NodeLiveSwapPolicy::on_instance_swapped observer (that is the seam the smoke scrapes and the headless test exercises). The DAW-free, CI-runnable mirror is test/test_signal_graph_live_swap_continuity.cpp, which drives the same stage + prepare_swap commit through process() and asserts sample continuity (no dropout/xrun) across the swap block for every hosted format (VST3/AU/CLAP/ LV2). Use the REAPER mode as the local-only in-host confirmation.
• sequence-loop-seek — set a loop region on the REAPER timeline, play, and perform scripted seeks (into/out of the loop and across the wrap) against a plugin that embeds a sequence. sequence_loop_seek.lua drives the transport via a deferred pump (GetSet_LoopTimeRange + GetSetRepeat + OnPlayButton + SetEditCurPos seeks), handshaking FX_SHOWN→SEEKS_DONE through the status file. The plugin emits per-block markers [seq-loop] blk host_qn=.. seq_qn=.. active=.. jump=.. dropout=..; the scraper (analyze_seq_loop_log) asserts the sequence read position TRACKED the host playhead within --pos-tolerance-qn on every block — a free-running counter that ignores the host jump is caught as drift → FAIL. PASS requires >=1 wrap AND >=1 seek, note activity, and no dropout; otherwise INCONCLUSIVE (a SKIP/INCONCLUSIVE is never a PASS). This is the harness half of Phase-2 DoD Proof #2 — the full proof also needs the embedded-sequence plugin (Gate-5/6) and a real REAPER run. The scraper is unit-tested with synthetic logs (incl. a negative drift/dropout case), so the parse logic is proven without REAPER.
• editor-open — insert the plugin, open its editor, confirm it rendered. For a product whose editor is the product, neither a hot-swap nor a transport scenario applies; the only question is whether it loads in a real host and draws. This is precisely the check the format validators cannot make: auval and clap-validator prove a plugin scans and instantiates, never that its window comes up. After FX_SHOWN it waits before tearing down, because an editor that opens and then throws reports itself in the seconds after the window appears.
• editor-build — generate a patch from inside the host. editor-open proves the window comes up; it does not prove the product behind it works. The generator is spawned by the plugin, and an editor that draws perfectly can still fail to reach it — the standalone once did exactly that, because an app launched from Finder inherits no PATH. Nothing short of triggering a real build inside the host tests that path. The trigger is a file the shell reads (FORGE_MODULAR_TEST_PROMPT), not synthetic clicks — see the gotcha below. The verdict is the generator's own success line plus the file it names, scraped from the plugin's log; never "the click appeared to land."
• All modes share the same REAPER lifecycle (ReaperSession): fresh portable dir, temp scan path, pre-warm scan, scripted insert+float, guaranteed teardown. They differ only in what they SEED, the TRIGGER they fire once the FX is shown, and how they VERIFY the captured log. Add a mode by writing seed/trigger/verify around ReaperSession, not by duplicating the launch plumbing.