Create a way for recipes to check their preconditions

Each may also be summarized in a human-friendly way so that the recipe can provide useful feedback if the condition doesn't check out.

Love this!

In speaking with @phenaproxima it was determined this might not be entirely the correct approach here and likely needs further discussion before proceeding, marking NW to prevent someone spending time on possibly incorrect implementation.

Me and @alexpott had a chat during the DrupalCon Barcelona code sprint.
This issue needs issue summary update.

Primarily we are looking for some system that provides the conform for the recipe.
Intention is to validate that the site already has existing features that the recipe is already providing.

This system should be able to validate that current system state has all the necessary configurations applied.

moved to Drupal Core, per https://www.drupal.org/project/distributions_recipes/issues/3513044 🌱 [meta] DrupalCon Atlanta: Triage issue queue and move any open issues to Drupal core Active

We need something like this for Drupal AI as well.

Marcus created ✨ Create Plugin Action for Recipes to check for installed default provider Active as an idea for this. It won't solve core's issue, but wanted to add it here so folks are aware/

I can add some perspective on what the AI module needs, since its probably a little bit different to most other use cases.

The AI module has at its core a normalization/abstraction layer of AI Providers like OpenAI or Anthropis. This is based on abstracted so called operation types with capabilities. These are usually built on input, output and similarity of feature set.

The most normal operation type is the Chat operation type where a model like gpt-4.1 or claude-3.7 from different providers works. Another could be text-to-image where Stable Diffusion or Dall-E exists.

On top of that we have capabilities, so for instance for an agentic system its vital that the Chat system handles so called tool calling.

To make sure that everyone that creates third party modules that interacts with the abstraction layer, we have made sure that when you install and setup a new provider, it can say that its the default provider/model for any combination of these operation types and capabilities. You also have a settings form where you can set or change this yourself.

At time of writing we have 20+ providers, where almost all of them has a unique use case for the right customer/consumer.

But for the third party app, it doesn't matter which provider is running in the background, it sends input and receives output in a normalized way.

This means two things for recipes where the AI module probably differs:

• When setting up a provider, we only want one recipe per provider, since we can't have 20 composer dependencies and up to 30 prompts asking for different api keys/setup instructions in bash. These recipes can be good for internal usage, where you want to setup the same thing over and over, but generally are not that helpful if you just use them once, since setting up in the GUI is usually easy.
• To not create a lot of boilerplate config, the recipes that actually provides advanced setup of AI functionality, should not have to concern themselves with setting up the AI provider, this should have been done already. They should also not need to depend on a specific provider recipe, since that defeats the purpose of normalization.

So we need a way to determine if an operation type/capability is set and the recipes should just have to verify this part and nothing else. That would be the most optimal way of working for us.

I can note that ✨ Create Plugin Action for Recipes to check for installed default provider Active is a workaround for this, but the config action plugin system is obviously not where this logic belongs.