Skip to content

Surface rig–protocol plugin mismatches more forcefully (export banner + typed-path coverage) #94

@mbreiser

Description

@mbreiser

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:

  1. 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.)
  2. 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)

  • Promote rig mismatches into the always-visible export-warnings banner. Thread the loaded rig into the export-warning render path so unsupported/unused plugin mismatches show alongside the other soft warnings (still non-blocking). Consider a new warning kind (e.g. rig-plugin-unsupported / rig-plugin-unused).
  • Decide blocking vs. soft. Should "protocol uses a plugin the rig doesn't enable" be a soft warning or an export blocking error? (Leaning soft, to preserve the assist philosophy — but worth a deliberate call.)
  • Typed-path coverage. When the user types/edits the rig: path (rather than Browse…), loadedRig goes stale and all rig-awareness disappears silently. Options: surface a subtle "rig not loaded — Browse to enable plugin checks" hint when a rig: 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.htmlrigIsCurrent(), loadedRig, the Settings → Plugins mismatch block; renderExportWarnings() / #exportWarnings banner.
  • js/plugin-registry.jsdiffRigVsProtocol().
  • js/protocol-yaml-v3.jscollectExportWarnings() (would need rig context threaded in).

Out of scope

Anything that auto-removes or rewrites the user's plugins: — this stays an assist.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions