Configure Site Contracts and Page Blueprints

Composer stores its runtime policy as a versioned Config Set. The visible hierarchy is:

Config Set -> Site Contract -> Blueprints

Build configuration from the broadest rules to the most specific. Keep the active Config Set immutable; clone it when you need to change production behavior.

1. Create a working Config Set​

Open WP Admin -> SmartCloud -> Agent Composer -> Config sets and create a new set or clone an existing one.

• Use Universal Gutenberg for a minimal theme-neutral page contract made from stable core blocks.
• Use SmartCloud Recommended for a richer portable page with hero, features, steps, optional FAQ, and a closing action.
• Use Detected Theme Starter to generate a safe site-local starter from a suitable registered pattern in the active theme. Composer records the source pattern and current theme and capability fingerprints.
• Use New for a clean configuration.
• Use Clone when the active configuration is a useful baseline.
• Use Import only for a checksum-protected Composer package you trust.

Preset-based, new, cloned, and imported sets are inactive. A preset is copied into a uniquely identified working Config Set; it never overwrites or activates configuration. Give each set a stable, descriptive label that explains its purpose rather than its environment password, customer name, or internal ticket.

2. Define the Site Contract​

The Site Contract is the policy shared by every Blueprint in the Config Set. Use it for constraints that should not drift between page types, for example:

• allowed WordPress post types,
• editorial and operator language,
• typography and visual-system guidance,
• media placement and caption rules,
• common template expectations,
• design constraints such as theme-preset-only styling,
• safety statements and provider-independent policies.

The contract is not executable theme code. Do not place credentials, API keys, remote callbacks, JavaScript, PHP, or provider secrets in it. Portable package validation rejects secret-shaped fields.

3. Add a Blueprint for each page type​

A Blueprint turns one semantic page type into an enforceable WordPress target. Create a separate Blueprint for every materially different content shape, such as a standard page, article, solution, architecture document, or product page.

Configure these fields deliberately:

• Page type: stable machine identifier used by MCP operations.
• Target post type: the page, post, or approved custom post type Composer may create.
• Target template: a template registered by the active theme. Prefer a no-title template when the approved pattern already contains the single H1.
• Allowed patterns: patterns the agent may assemble for this page type.
• Required sequence: the minimum ordered pattern sequence that every valid draft must contain.
• Allowed blocks: the complete block allowlist, including nested blocks used by every approved pattern.
• Constraints: H1, word-count, embed, shortcode, Custom HTML, and theme-preset rules.
• Excerpt policy: required, optional, or disabled for this page type.
• SEO contract: required WordPress excerpt and meta-description behavior.

Use the registered-block selector instead of typing block names from memory. A block or pattern supplied by another plugin is valid only while that provider is installed, active, and registered on this site.

4. Rescan the active site​

Open Theme & providers and choose Rescan site after installing, activating, or updating a theme or provider plugin.

Review:

• active theme identity and version,
• registered templates and patterns,
• all registered Gutenberg blocks,
• patterns referenced by the selected Config Set,
• optional provider metadata and runtime readiness,
• any missing contract dependency.

Discovery reports capability; it does not rewrite configuration. If the theme changed, clone the active set and adjust the working copy.

5. Stage and apply changes​

Entity edits are staged in the browser. Saving an entity modal does not immediately create a new database revision. The action bar shows the pending additions, edits, and confirmed deletions for the selected Config Set.

• Apply modifications writes the complete staged changeset as one optimistic-concurrency-protected transaction.
• Discard removes the staged changes without writing to WordPress.

Applying a changeset recalculates the Config Set hash and modified time. If another administrator changed the same entity, Composer returns a conflict instead of overwriting either version.

6. Validate and activate​

Choose Validate after every meaningful contract, theme, pattern, block, template, or provider change. Resolve errors before activation; review warnings in context.

Activation requires a fresh validation receipt bound to:

• the exact Config Set checksum,
• the current WordPress site,
• the current administrator,
• a limited validity window.

Choose Activate only after reviewing the complete working set. The previous active set becomes archived and remains available for comparison and confirmed restoration.

Compare, restore, export, and back up​

• Compare to active shows how the selected set differs from the runtime configuration.
• Restore archived as active validates the archived set again and requires explicit confirmation; it does not undo an unsaved browser edit.
• Export creates one checksum-protected Config Set package.
• Audit & portability -> Export all configuration creates a complete backup of every Config Set.

Portable exports intentionally exclude credentials and the site-specific audit chain. Restored sets remain inactive until they are validated and explicitly activated.

Before connecting an agent​

Confirm that:

1. exactly one Config Set is active,
2. every requested page type has a valid Blueprint,
3. all required patterns, templates, and blocks exist,
4. optional providers report ready or are absent from the Blueprint,
5. the dedicated agent user has the smartcloud_agent role,
6. the MCP status in Composer reports the expected endpoint.