## Problem/Motivation `ExportRecipe::doExport()` generates a complete recipe directory — `recipe.yml`, `composer.json`, `README.md` and `config/` — from a model and its dependencies. The intent is that the exported recipe is a derived artifact, so that a model stays the single source of truth and the recipe can be regenerated whenever the model changes. In practice a real, shipped library recipe cannot be produced by the exporter, so it gets hand-edited after export and can never be regenerated without losing that work. `drupal-eca-recipe/eca_lib_0038` is a concrete example. Three things in it are unreachable from `getRecipe()`: **1. There is no short description.** `getRecipe()`, `getComposer()` and `getReadme()` are all handed `$owner->getDocumentation($entity)`. For a documented model that is long-form markdown — several screens of it, with headings. It is right for the README and wrong for `recipe.yml`'s `description` and `composer.json`'s `description`, both of which are one-line summaries shown in listings. The shipped recipe therefore carries a hand-written one-sentence description that the exporter would overwrite. **2. `recipes:` cannot be expressed.** A recipe frequently needs to include another recipe — for `eca_lib_0038`, `core/recipes/article_tags`, so the model's `node.type.article`, `body`, `field_tags` and `tags` vocabulary dependencies are provisioned rather than assumed. `getRecipe()` emits only `name`, `description`, `type`, `install` and `config`. **3. `config.actions` cannot be expressed.** `getRecipe()` builds `actions` solely for `user.role.*` config, to turn a role into `ensure_exists` + `grantPermissions`. Any other config action — for `eca_lib_0038`, `setComponents` on `core.entity_form_display.node.article.default` so the model's new fields appear on the form — has to be added by hand. The consequence is that the recipe stops being derived. It becomes a hand-maintained artifact that happens to have been generated once, and the "single source of truth" property is lost. ## Proposed resolution Let the model carry the metadata the exporter is missing, so a complete recipe is reachable from the model alone. - **A `summary` alongside `documentation`** in the `modeler_api` third-party settings envelope: a one-line description for `recipe.yml` and `composer.json`, with `documentation` continuing to feed the README. Fall back to the first paragraph or the first sentence of `documentation` when `summary` is absent, so existing models keep working. - **Recipe composition metadata** on the model, covering the recipes to include and any extra config actions to apply, which `getRecipe()` then emits as `recipes:` and merges into `config.actions`. The exact storage shape is worth discussing before implementation — these are properties of *packaging* rather than of the workflow, so it may be cleaner to keep them in a dedicated key rather than scattering them through the existing envelope. Once this lands, `eca_lib_0038` should be reproducible by export with no hand-editing, and that is the acceptance test worth writing. ## Remaining tasks - [ ] Agree the storage shape for `summary` and the composition metadata - [ ] Add `summary` with a documented fallback - [ ] Emit `recipes:` from the model - [ ] Merge model-supplied `config.actions` with the generated role actions - [ ] Verify by regenerating `eca_lib_0038` and diffing against the shipped recipe ## Related Part of the ECA Guide library publishing rework, `drupal/documentation/eca#96` on gitlab.lakedrops.com, where the decision was taken that the recipe should be generated in full rather than hand-maintained.