Operation catalogue duplicates ops per “pipeline family”, causing UI bloat and wrong abstraction

[nathabee]

Problem

The current PipelineCatalogue defines multiple OpSpec entries that represent the same conceptual operation (e.g. Resize, Threshold, Morphology) but are duplicated under different IDs such as:

• op.seg.resize vs op.edge.resize
• op.seg.threshold vs op.edge.threshold
• op.seg.morphology vs op.edge.morphology

These duplicates exist only to carry different dispatchId / tuningId namespaces (e.g. segmentation.resize vs edge.resize), not because the operation itself is different.

Why this is a real problem

1. Wrong abstraction for Builder

   • In the visual Builder, operations should be generic building blocks that can be used in any pipeline.
   • Duplicating ops per “pipeline family” makes the operations list huge and repetitive (multiple “Resize” cards, etc.).
   • This breaks usability (excess scrolling, drag & drop becomes impractical).

2. Pipelines are dynamic, not fixed families

   • User pipelines can combine operations freely, so hard-wiring “Segmentation vs Edge” into op IDs does not scale.
   • The catalogue currently encodes context into the op ID, instead of keeping ops context-free.

3. Tuning scoping is coupled to op IDs

   • Parameters are (or should be) scoped per pipeline/recipe in the tuning system.
   • Today the tuning namespace is indirectly encoded via tuningId strings like segmentation.resize, which forces duplicated ops.
   • This prevents having a single Resize operation that is reusable across pipelines.

Desired behavior

• The catalogue should define one OpSpec per conceptual operation, e.g.

  • op.image.resize
  • op.image.threshold
  • op.mask.morphology

• A pipeline (and/or selected recipe) should supply the tuning context:

  • tuning should be resolved as (pipelineId, recipeId?, opId) rather than (pipeline-family-specific tuningId string).

• Dispatch should be mapped by opId (or a stable engine op key), not duplicated per pipeline family.

Consequences / Acceptance criteria

• Builder “All operations” list shows each op once (no duplicate Resize/Threshold/Morphology entries).
• Any operation can be added to any user pipeline without needing a family-specific op ID.
• Tuning values remain pipeline/recipe-scoped and do not require op duplication.
• Existing stored pipelines may require a migration from old op IDs (op.seg.resize) to new generic op IDs (op.image.resize).

Notes

• This is a structural refactor: it touches catalogue op IDs, built-in pipeline definitions, stored user pipelines, and the tuning resolution path.
• A proper migration strategy is required (mapping old IDs to new generic IDs).