feat: gate the suspended midi domain behind MUSE_ENABLE_MIDI
The midi domain plugin is fully maintained but not registered by default, pending its own security and performance audit -- unrelated to code quality, purely a focus decision while the code domain ships to the general public first. Previously the only way to re-enable it was uncommenting its import and registry entry directly, which flips the default for every user of that checkout with nothing to remind you to revert it.
Replaced that with an explicit opt-in: setting MUSE_ENABLE_MIDI=1 adds MidiPlugin to the registry at import time; unset (the default), the registry is byte-for-byte the same six domains as before. Needed to unblock a local midi demo without touching the public default.
Tests: tests/test_plugin_registry.py::TestMidiOptInGate -- three new tests, each spawning a fresh interpreter (registry state is built once at import time) to prove: midi absent with no env var, midi present with MUSE_ENABLE_MIDI=1, and resolve_plugin() actually returns a working MidiPlugin for a midi-domain repo when opted in (the exact 'Unknown domain' failure this fixes). Full regression sweep across test_domain_schema/test_plugin_registry/test_domain_command_registry(_wiring)/ test_cli_plugin_dispatch/test_cmd_domains_hardening: 314 passed.
Version bump to 0.2.1rc4 -- a real, tested CLI change worth publishing through the normal release channel rather than living only as a local site-packages reinstall.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Semantic Changes
13 symbols
Files Changed
~3
1185 in snapshot
0 comments
muse hub commit comment sha256:7fbbeb1aea57e54e882cb3f5cf6c5071fa82142953df8675d44ab1082d4eb783 --body "your comment"
No comments yet. Be the first to start the discussion.