Runnable now — the foobar2000 component's clean-profile install

Also not hardware-gated, and it is the only functional check the component has. NFR §8 names this file as where the answer lives, because no CI runner can load foobar2000 — the same gap the macOS path has (ADR-0115, Negative).

Two things make this a real check rather than a formality. It must run against the released zip, not plugin-foobar/build.ps1 -Install — an artifact that has only ever been installed over its own build directory has never exercised the path a user takes, and the release route additionally exercises the SDK fetch, the runner’s MSVC and the three-zip count. And the dev box already carries %APPDATA%\foobar2000-v2\user-components-x64\foo_ritmolux\ from that inner loop, so remove it first, or an older copy shadows the one under test and the version check means nothing.

• RUN 2026-08-16 — v0.70.0, foobar2000 v2.25.10, AMD iGPU dev box. Installs and renders; one new defect, worse than either expected failure. Taken against the published release zip, into a profile with the build.ps1 -Install copy removed first. (a) Pass — Components list reads Light Music Visualizer 0.70.0 / foo_lmv. This is also the first evidence that the component archive’s layout is right: nothing outside a real foobar2000 can confirm that an archive with an empty root and only x64/foo_lmv.dll installs, and build-component.ps1 asserts that layout from documentation rather than observation. It loaded into a host well past the pinned 2025-03-07 SDK, which is one data point against the staleness risk packaging/foobar/sdk-pin.ps1 admits nothing guards. (b) Did NOT reproduce — the docked panel was never black. It rendered a correct attractor at full panel size immediately. (b’) NEW, and it is the finding of this run — the panel rendered at 6.5 fps / 154 ms per frame from the session’s first sample, pegging one thread and starving foobar2000’s own UI: the status bar froze at 0:00 under playing audio and the playlist painted no rows, while Responding stayed True. Adding an album to the playing playlist took it to 17.6 ms at 57 fps — 8.7x — with preset, draw_calls and gpu_bytes byte-identical across the transition. That is backlog 0102’s named stream-format revival path, reached accidentally, with a symptom that entry does not predict. Filed there; priority raised Medium -> High. A follow-up run with a populated playlist showed only a brief slow patch at the first track, then correct: the bad state runs from panel creation until playback starts, so it is worst for a user who looks before pressing play. (e) Confirmed failing, as expected — backlog 0103: the panel’s right-click shadows foobar2000’s layout-edit menu, so Remove is unreachable. (f) Pass — %APPDATA%\light-music-visualizer\ is present and shared; the component wrote plugin-diagnostics.log there during the run. Noted, not a component defect: that library held 76 presets against the 40 the repo ships, because seeding is write-if-absent and never deletes. 36 retired presets from earlier cohorts are still live in it, including pre-rename rose_* files. Anyone judging the shipped set from a long-lived profile is judging the wrong set.

• The renamed component loads, and the old one is gone. Nothing in CI can check this: the component’s filename is validated by foobar2000 itself, so a rename is only proven by a host that accepts it. Install foo_ritmolux.fb2k-component, then confirm (a) the Components list reads Ritmolux, not Ritmolux; (b) the pop-out opens from View → Ritmolux and renders; (c) nothing named foo_ritmolux remains under %APPDATA%\foobar2000-v2\user-components-x64\ — VALIDATE_COMPONENT_FILENAME means the old and new components have different filenames and both load, so the old one must be removed through Preferences rather than left to be shadowed; (d) an existing Default UI layout still holds the panel — the component’s GUIDs were deliberately not changed, and this is the only thing that proves it. (Plan 0150 Phase 9. A failure here is a defect in the rename, not a new backlog entry.)

• Install the released component into a clean profile and play something. Download ritmolux-v<version>-foobar2000-component.zip from the Releases page, unzip, and install via File → Preferences → Components. Then, in this order: (a) the Components list shows the released version, not the dev build’s; (b) dock it as a Default UI panel before playing anything and record whether it comes up black — this is backlog 0102, which says the panel renders without presenting and revives only at a track boundary, and one reporter’s account is all the evidence there is; (c) open the pop-out from View → Ritmolux; (d) play a track, confirm it reacts, change track, press Space a few times; (e) in layout-editing mode, right-click the panel and check whether Remove is reachable — this is backlog 0103, expected to fail, and confirming it on a second machine is worth the ten seconds; (f) %APPDATA%\Ritmolux\ exists and is the same folder the standalone uses. Escalation: a failure is a new backlog entry or a followup plan, never a re-opened plan — on-device checks do not gate closes here. (b) and (e) failing is the expected result and confirms two filed defects rather than finding new ones; anything else is new. (Plan 0102 Phase 5, carried forward at that plan’s close 2026-08-16.)

• Drive the component’s right-click menu — the whole preset loop. Everything a foobar user can reach lives on one menu since Plan 0107, and CI builds no C++, so this is the only place any of it is exercised. Mid-playback, in this order: (a) right-click → Preset ▸ lists the presets and marks the one showing; pick a different one and it dissolves across and the mark follows; (b) drop a fresh .toml into the presets folder (author one, or copy-rename an existing file with an edited name), then right-click → Reload presets — it appears in the list without restarting foobar2000, and the preset you were watching is still the one showing. Drop a deliberately malformed .toml too: it must be absent from the list, since the list is the core’s roster and not a directory listing; (c) right-click → Open presets folder lands in …\ritmolux\presets itself, not its parent; (d) exit foobar2000 fully and relaunch — the preset from (a) is rendering and carries the mark. Then delete that preset’s file and relaunch again — the component comes up on the roster’s default with nothing surfaced to the user, which is the documented degrade of persist-by-name. Two things to note rather than fix. The restore is a dissolve, not a cut, so a fresh handle starts on the roster’s first entry and crossfades to the remembered one over ~1 s — at every start, and at every mid-playback format change. And the menu still shadows foobar2000’s own in layout-editing mode (backlog 0103), which this plan made larger rather than fixing; Plan 0103 Phase 1 owns it. Escalation: same rule as above — a failure is a backlog entry or a followup plan. Ran 2026-08-24 — all four pass, no finding. Component rebuilt from main first: the profile held a foo_lmv.dll dated 2026-08-16, predating the very menu this item drives, so date the installed artifact before trusting a carried-forward check. Both (b) fixtures were pre-flighted through shot --preset-file so a wrong result would convict the menu, not the file. (a) Pass — mark on the one showing, pick dissolves across, mark follows. (b) Pass — the new .toml appears without a restart, the malformed one is absent, the watched preset survives the reload. (c) Pass — lands in presets itself. (d) Pass — returns with the mark; with the file deleted it comes up on the roster default, nothing surfaced, no ghost entry. One correction this run owes back: the restore lands at the first track boundary, not at launch — before playback starts the panel shows the roster default, so persistence looks broken to anyone who checks before pressing play. The “at every start” phrasing above is what is wrong, not the code; filed as a followup on Plan 0107. Backlog 0103 confirmed failing on a second machine, post-0107: layout-edit right-click still gets the component’s menu instead of Cut / Copy / Replace / Remove. Still open: whether an explicit Reload visibly re-seeds the running scene — this run did not look, and it is cheap to settle next time on a long-trail preset. RE-OPENED 2026-09-01 at Plan 0141’s close — (a) only; (b) through (d) stand. Plan 0141 Phase 1 changed how a menu click is dispatched: it resolves the preset by name against a freshly read roster instead of by the index the submenu item carried, because TrackPopupMenu pumps WM_TIMER and the roster can be reloaded under an open menu. The 2026-08-24 run above passed (a) against a foo_lmv.dll that predates that change, and this item’s own warning — date the installed artifact before trusting a carried-forward check — is exactly what applies to it now. This was the plan’s only behavioral change to shipped code and CI builds no C++, so (a) is the only thing anywhere that exercises it. Re-run (a) against a component rebuilt from main at v0.99.1 or later. The interesting case is the one the old index could get wrong: with the menu open, have a track boundary or a stream-format change land (or drop a .toml into the folder and let a reload happen), then click a preset — the one that starts showing must be the one whose name you clicked. (Plan 0107 Phase 5, carried forward at that plan’s close 2026-08-18; run 2026-08-24; (a) re-opened by Plan 0141 Phase 1 on 2026-09-01.)