Version: Fusion 0.57.0
Facts: PluginPromptContribution carries an optional condition string, and plugins can declare typed per-plugin settings via manifest.settingsSchema (values editable per project in the plugin settings panel). However, getPromptContributionsForSurface filters only by plugin state === "started", surface, and promptContributions.enabledByDefault !== false; buildPluginPromptSection joins content without ever reading .condition (zero references to contribution.condition in bin.js).
Impact: conditional/gated plugin content cannot be enforced host-side. Our plugin (fusion-dotnet-kit) declares decision-gated skills whose prompt contributions carry conditions like settings["api-style"] === "minimal-apis"; consumers set the enum in the plugin settings panel, but the setting has no effect — the condition is decorative. Without evaluation, per-project gating of plugin guidance (a core plugin use case: activate content only after a project sanctions a stack decision) cannot work.
Request: evaluate condition against the plugin's per-project effective settings when assembling prompt contributions (a minimal grammar would suffice: equality/inequality comparison of one setting key against a string literal, e.g. settings["key"] === "value" / !==). Please document the supported grammar in the SDK types so plugin authors can rely on it.
Version: Fusion 0.57.0
Facts:
PluginPromptContributioncarries an optionalconditionstring, and plugins can declare typed per-plugin settings viamanifest.settingsSchema(values editable per project in the plugin settings panel). However,getPromptContributionsForSurfacefilters only by plugin state === "started",surface, andpromptContributions.enabledByDefault !== false;buildPluginPromptSectionjoins content without ever reading.condition(zero references tocontribution.conditionin bin.js).Impact: conditional/gated plugin content cannot be enforced host-side. Our plugin (fusion-dotnet-kit) declares decision-gated skills whose prompt contributions carry conditions like
settings["api-style"] === "minimal-apis"; consumers set the enum in the plugin settings panel, but the setting has no effect — the condition is decorative. Without evaluation, per-project gating of plugin guidance (a core plugin use case: activate content only after a project sanctions a stack decision) cannot work.Request: evaluate
conditionagainst the plugin's per-project effective settings when assembling prompt contributions (a minimal grammar would suffice: equality/inequality comparison of one setting key against a string literal, e.g.settings["key"] === "value"/!==). Please document the supported grammar in the SDK types so plugin authors can rely on it.