Context
Follow-up to #91 / #93. The v3 Experiment Designer (v0.21) now derives the rig's supported plugins from the rig YAML and shows a non-blocking orange "Rig mismatch" box in Settings → Plugins when the protocol declares a plugin the loaded rig doesn't enable (or the rig enables one the protocol doesn't use).
That assist is intentionally light-touch ("assists, never rewrites"), but it has two visibility gaps that make it easy to miss a real problem:
- Browse… only. The mismatch check runs only when
rigIsCurrent() is true — i.e. the rig was picked via Browse… this session and the path still matches. If the user just types a new rig: path into the field, loadedRig goes stale → no warning at all, and the add-plugin dropdown silently reverts to the flat registry list. (Browsers can't read a path string, so a typed path is opaque — this is a real constraint, not a bug, but the UX consequence is silent.)
- Drawer-only visibility. The warning lives inside the Settings → Plugins drawer, so it's only visible while that drawer is open. There's no always-on banner/badge, and it never appears in the always-visible export-warnings banner (
collectExportWarnings is rig-unaware).
Net effect today: a protocol that uses a plugin the new rig disallows still exports cleanly with that plugin/commands intact; the mismatch only actually bites at MATLAB runtime.
Proposed enhancements (take on later)
Pointers
experiment_designer_v3.html — rigIsCurrent(), loadedRig, the Settings → Plugins mismatch block; renderExportWarnings() / #exportWarnings banner.
js/plugin-registry.js — diffRigVsProtocol().
js/protocol-yaml-v3.js — collectExportWarnings() (would need rig context threaded in).
Out of scope
Anything that auto-removes or rewrites the user's plugins: — this stays an assist.
Context
Follow-up to #91 / #93. The v3 Experiment Designer (v0.21) now derives the rig's supported plugins from the rig YAML and shows a non-blocking orange "Rig mismatch" box in Settings → Plugins when the protocol declares a plugin the loaded rig doesn't enable (or the rig enables one the protocol doesn't use).
That assist is intentionally light-touch ("assists, never rewrites"), but it has two visibility gaps that make it easy to miss a real problem:
rigIsCurrent()is true — i.e. the rig was picked via Browse… this session and the path still matches. If the user just types a newrig:path into the field,loadedRiggoes stale → no warning at all, and the add-plugin dropdown silently reverts to the flat registry list. (Browsers can't read a path string, so a typed path is opaque — this is a real constraint, not a bug, but the UX consequence is silent.)collectExportWarningsis rig-unaware).Net effect today: a protocol that uses a plugin the new rig disallows still exports cleanly with that plugin/commands intact; the mismatch only actually bites at MATLAB runtime.
Proposed enhancements (take on later)
unsupported/unusedplugin mismatches show alongside the other soft warnings (still non-blocking). Consider a new warningkind(e.g.rig-plugin-unsupported/rig-plugin-unused).rig:path (rather than Browse…),loadedRiggoes stale and all rig-awareness disappears silently. Options: surface a subtle "rig not loaded — Browse to enable plugin checks" hint when arig:path is set but no rig is loaded for it; or persist/remember the last-loaded rig contents keyed by path.Pointers
experiment_designer_v3.html—rigIsCurrent(),loadedRig, the Settings → Plugins mismatch block;renderExportWarnings()/#exportWarningsbanner.js/plugin-registry.js—diffRigVsProtocol().js/protocol-yaml-v3.js—collectExportWarnings()(would need rig context threaded in).Out of scope
Anything that auto-removes or rewrites the user's
plugins:— this stays an assist.