fix: builtin override on name and type

[jmpTeixeira02]

Fix: Built-in Plugin Override on Name and Type Collision

Bug Fix

🐛 Resolved an issue where two built-in plugins of different types but with the same name would cause the loadPluginAsBuiltIn function to incorrectly match and use the first plugin's implementation, leading to inconsistent behavior.

Changes

• pkg/catalog/catalog.go: Updated the matching condition in loadPluginAsBuiltIn to require both builtin.Name() == pluginConfig.Name and builtin.Name() == pluginConfig.Type, ensuring that a built-in plugin is only selected when both the name and type match — preventing false matches across plugins of different types that share the same name.

• 🔄 Regenerate and Update Summary

---

📬 Subscribe to the Hyperspace PR Bot DL to get the latest announcements and pilot features!

PR Bot Information

Version: 1.17.91 | 📖 Documentation | 🚨 Create Incident | 💬 Feedback

• Correlation ID: 80661740-1884-11f1-9178-53854736be74
• Event Trigger: issue_comment.edited

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Mar 5, 2026, 10:16 AM

[hyperspace-insights]

The pull request contains a critical logic error in the fix: the second condition compares builtin.Name() against pluginConfig.Type (a name vs. a type), which will never be true in normal usage, meaning no built-in plugin will ever be found. The correct fix requires comparing builtin.Type() against pluginConfig.Type, as noted in the review comment.

PR Bot Information

Version: 1.17.91 | 📖 Documentation | 🚨 Create Incident | 💬 Feedback

• LLM: anthropic--claude-4.6-sonnet
• Correlation ID: 5f58b890-187b-11f1-8d4a-0c0d57366279
• Event Trigger: pull_request.opened