README

A Drupal recipe that extends Drupal CMS into an AI-agent-ready development platform:

• everything in drupal_cms_starter (Canvas page building, media, SEO, admin UI, the Mercury theme…);
• Droost — the MCP toolkit AI coding agents drive — with its brain, code/semantic search, examples corpus, SDC display composer, and Canvas tree tooling enabled;
• UI Patterns 2 (+ field formatters) as the SDC display substrate for structured entities;
• a shipped design pattern: an event content type whose default display is composed entirely from Single Directory Components — authored deterministically by droost_display_compose and exported here, so a fresh site demonstrates the entity fields → SDC props/slots → render pattern out of the box;
• the Droost Theme theme as the site default: Tailwind v4 browser JIT + daisyUI (no build step — any utility class works immediately), design tokens in one agent-editable css/tokens.css, and a Canvas-clean SDC library. Its own project — droost is the brain, droost_theme the theme layer, and this recipe composes the two. Mercury stays installed (starter ships it) but is no longer default;
• the Droost Playbook (droost_playbook), which declares the methodology itself to agents: the methodology topic in droost_guidelines (and in the AGENTS.md block droost:install writes) teaches the structured-vs-freeform decision, both tool flows, and points at the shipped event pattern as the template to copy.

⚠️ Local development shape. Droost is a local-only toolkit (same class as devel): this recipe is for local and AI-assisted builds. Don't deploy the result to production with Droost enabled.

Requirements & the one manual step

Drupal CMS ships Canvas, and this recipe adds UI Patterns — the two currently fight over the SDC plugin manager (canvas#3561618). Until that lands upstream, the root project must apply the coexistence patch (recipes cannot apply root patches):

// root composer.json
"extra": {
    "patches": {
        "drupal/canvas": {
            "#3561618: coexist with plugin.manager.sdc decorators":
                "patches/canvas-3561618-sdc-manager-decoration-compat.patch"
        }
    },
    "composer-exit-on-patch-failure": true
}

(Patch file: shipped in this repo under patches/; requires cweagans/composer-patches.)

Install

On a fresh Drupal CMS project (or any project about to become one):

composer require cweagans/composer-patches   # if not present
# add the patch block above, copy patches/ into your project, then:
composer require drupal/mcp_server:^2.0@alpha \
  drupal/droost:1.0.x-dev drupal/droost_theme:1.0.x-dev \
  drupal/droost_cms:1.0.x-dev
drush php:eval '\Drupal\Core\Recipe\RecipeRunner::processRecipe(\Drupal\Core\Recipe\Recipe::createFromDirectory("recipes/droost_cms"));'
drush cr
drush droost:install   # wire your AI editor

(droost, droost_theme, and this recipe must be root-required with explicit dev/alpha constraints until they have stable releases: Composer ignores stability flags in non-root packages, so the recipe's own @dev requirements cannot widen stability for you.)

(Why php:eval: as of Drush 13.6 there is no drush recipe command, and core/scripts/drupal recipe mis-resolves the autoloader under a split docroot. The one-liner uses the same core Recipe API either would.)

Validated 2026-07-04 on a fresh drupal/cms 2.1.3 project: the recipe applies on an installed CMS site, enables the nine modules, ships the event pattern (renders through SDCs), Canvas + UI Patterns coexist under the patch, and the MCP server serves the full applicable tool surface.

Applying the recipe on an already-installed Drupal CMS site is supported (drupal_cms_starter re-applies as a no-op when identical).

Known nuance: theme blocks

Droost Theme ships its block placements (branding, main menu, messages, local tasks) as theme config/optional, which recipe-driven theme installs can skip. This recipe therefore ships the same four block configs in its own config/ so a fresh site always gets the navbar. (The theme's optional title block is deliberately not placed: Canvas pages and composed displays carry their own headings.)

What the design pattern demonstrates

config/core.entity_view_display.node.event.default.yml renders every event field through droost_examples:example_card via UI Patterns component formatters — field label → heading prop, field value → content slot through the field's own core formatter. It round-trips byte-identically through droost_display_compose, so an agent can read it with droost_display_get, modify it, and re-compose it deterministically.