Plugin Availability

Plugins currently expose two states that are easy to confuse:

• enabled
• available

enabled

This means:

• whether the plugin is turned on at city scope

Think of it as the lifecycle switch.

available

This means:

• whether the plugin can actually work right now in the current context

Think of it as runtime readiness or health.

A plugin can absolutely be:

• enabled = true
• but available = false

For example:

• a provider is not installed yet
• Python dependencies are missing
• a required model was not downloaded

Why two layers exist

Because "the user enabled it" and "the dependency chain is actually ready" are different facts.

That split lets UI describe:

• switch state
• health state

Static catalog vs runtime availability

Static catalog

The control-plane catalog mainly answers:

• does this plugin exist
• is it enabled at city scope

It does not always have a full runtime context to perform deep checks.

Runtime availability

Runtime availability is closer to:

• can this plugin really work right now

It can combine:

• current config
• dependency inspection
• plugin-specific availability logic

Special case: auth

auth is a special plugin:

• enabled is effectively always true
• available is also treated as available by default

It does not use the normal optional lifecycle semantics.

Safest mental model

Remember it as:

• enabled is the switch
• available is the health

Related docs

• Plugin configuration
• Built-in plugins today