# Agent Composer Configuration and Lifecycle

Composer stores runtime policy in versioned Config Sets. Only one validated Config Set is active per WordPress site. The active set is immutable; administrators clone it to create an editable working copy. New, cloned, imported, and restored sets remain inactive until explicit validation and activation.

## Starting presets

**Universal Gutenberg** supplies a minimal theme-neutral page contract using stable core blocks. **SmartCloud Recommended** adds a portable hero, feature grid, steps, optional FAQ, and closing action. **Detected Theme Starter** creates a safe site-local starter from a suitable registered pattern in the active theme and records its source plus current theme and capability fingerprints.

Selecting any preset creates a uniquely identified inactive working Config Set. It never overwrites or activates existing configuration. Site-specific WP Suite reference blueprints are not part of these three public starting paths.

## Site Contract

The Site Contract contains rules shared by all page types. Typical fields include allowed post types, editorial language, typography and visual guidance, common template expectations, media treatment, and design constraints such as theme-preset-only styling. It must not contain secrets, executable callbacks, PHP, JavaScript, or provider credentials.

For structured records, the content-model plugin remains responsible for registering each custom post type, REST-visible field, relation storage rule, sanitization, and capability mapping. The Site Contract only grants explicit Composer read/write access and, for a relation, declares the admitted target post types, statuses, cardinality, order, and maximum item count. Composer owns the generic relation lookup and governed draft write workflow; a site plugin should not duplicate Composer's relation-search Ability.

WordPress core or the responsible provider likewise registers and attaches each taxonomy. The Site Contract's **Composer taxonomy access** policy can then allow search, assignment, and explicitly confirmed creation per post type and taxonomy, with a fixed `append` or `replace` mode and maximum item count. Hierarchical creation is root-only unless the policy names an allowlist of durable parent slugs. The generic workflow is `get-taxonomy-contract` -> `search-taxonomy-terms` -> reuse an exact `matches[].term_id` or, only when justified, `create-taxonomy-term` -> `assign-taxonomy-terms` -> `inspect-taxonomy-terms`. Composer exposes no term edit or delete ability.

Remote media ingestion is separately opt-in. Enabling it requires exact approved HTTPS hosts, admitted raster MIME types, and a byte limit. It is not a general upload permission: redirects, URL credentials, fragments, custom ports, unsafe network destinations, non-approved hosts, and invalid or oversized image responses are rejected. The operator remains responsible for source terms and reuse rights.

## Blueprints

A Blueprint defines one semantic `page_type`. It selects the target WordPress post type and theme template, allowed patterns and Gutenberg blocks, required pattern sequence, word and H1 constraints, optional provider requirements, excerpt policy, and SEO behavior.

The excerpt policy is independent for each Blueprint:

- `required`: 80 to 300 characters;
- `optional`: empty, or 80 to 300 characters;
- `disabled`: must remain empty.

The Yoast meta description is separate and remains required at 120 to 160 characters.

## Editing and activation

Entity edits are staged in the browser. **Apply modifications** writes the complete changeset as one optimistic-concurrency-protected transaction; **Discard** performs no WordPress write. A successful apply recalculates the Config Set hash and modified time. Concurrent changes return a conflict instead of overwriting either version.

Before activation, **Theme & providers -> Rescan site** should confirm every referenced template, pattern, block, and provider. Validation creates a short-lived receipt bound to the exact checksum, site, and administrator. Activation is allowed only with a fresh receipt.

## Portability and rollback

**Compare to active** compares the selected set to the runtime configuration. **Restore archived as active** revalidates an archived configuration and requires confirmation. Exported Config Sets and full backups use checksums, exclude secrets and the site-specific audit chain, and always restore as inactive working sets.

## Agency handoff example

If an agency has already designed a `case_study` custom post type, the theme continues to own its frontend presentation. A site-specific Blueprint can require the existing title, client context, challenge, implementation, result, call-to-action, image metadata, taxonomies, SEO fields, theme template, patterns, blocks, and sequence.

The client's compatible agent loads that Blueprint and the design context, validates the complete structure, and creates a draft. A human checks facts and presentation before approval. WordPress publishing or an optional Static Publisher release remains a separate action. The Blueprint describes that site's existing case-study model; it is not a universal WP Suite layout.