Anmelden

Site Contracts und Page Blueprints konfigurieren

Composer speichert die Laufzeit-Richtlinie als versionierten Config Set. Die sichtbare Hierarchie ist:

Config Set -> Site Contract -> Blueprints

Erstellen Sie Konfigurationen vom breitesten Regelwerk zum spezifischsten. Halten Sie den aktiven Config Set unveränderlich und kloni ihn, wenn produktives Verhalten geändert werden soll.

1. Arbeits-Config Set erstellen​

Öffnen Sie WP Admin -> SmartCloud -> Agent Composer -> Config sets und erstellen Sie einen neuen Satz oder klone einen bestehenden.

  • Universal Gutenberg für einen minimalen theme-neutralen Seitenvertrag mit stabilen Core-Blöcken.
  • SmartCloud Recommended für eine reichhaltigere portable Seite mit Hero, Features, Schritten, optionaler FAQ und abschließendem Call to Action.
  • Detected Theme Starter für einen sicheren, standortlokalen Starter basierend auf einem geeigneten registrierten Pattern im aktiven Theme. Composer zeichnet Quellpattern, aktuelles Theme und Fähigkeits-Fingerprints auf.
  • Neu für eine saubere Konfiguration.
  • Klonen wenn die aktive Konfiguration als nützliche Basis dient.
  • Importieren nur für ein checksumsicheres Composer-Paket, dem Sie vertrauen.

Preset-basierte, neue, geklonte und importierte Sätze sind inaktiv. Ein Preset wird in einen eindeutig identifizierten Arbeits-Config-Set kopiert; es überschreibt oder aktiviert nie automatisch. Geben Sie jedem Satz ein stabiles, beschreibendes Label, das Zweck statt Umgebung, Kundennamen oder internes Ticket beschreibt.

2. Site Contract definieren​

Der Site Contract ist die Richtlinie, die jeder Blueprint im Config Set teilt. Nutzen Sie ihn für Regeln, die nicht zwischen Seitentypen driften sollen, z. B.:

  • erlaubte WordPress-Posttypen,
  • redaktionelle und Betreibersprache,
  • Typografie- und visuelle Leitlinien,
  • Medienpositionierung und Caption-Regeln,
  • gemeinsame Template-Erwartungen,
  • Designbeschränkungen wie ausschließlich theme-preset-basierte Styles,
  • Sicherheitsanweisungen und providerunabhängige Policies.

Der Contract ist kein ausführbares Theme-Code. Keine Zugangsdaten, API-Schlüssel, Remote-Callbacks, JavaScript, PHP oder Provider-Geheimnisse darin speichern. Portable Paketvalidierung lehnt geheimnisartige Felder ab.

3. Für jeden Seitentypen einen Blueprint hinzufügen​

Ein Blueprint macht einen semantischen Seitentyp zu einem durchsetzbaren WordPress-Ziel. Erstellen Sie einen separaten Blueprint für jede materielle Inhaltsstruktur wie Standardseite, Beitrag, Lösung, Architekturdokument oder Produktseite.

Konfigurieren Sie die Felder bewusst:

  • Seitentyp: stabile Maschinenkennung, die von MCP-Operationen genutzt wird.
  • Ziel-Posttyp: die Seite, der Beitrag oder freigegebene Custom Post Type, die Composer erstellen darf.
  • Ziel-Template: ein von aktivem Theme registriertes Template. Bevorzuge ein H1-freies Template, wenn das genehmigte Pattern bereits die einzige H1 enthält.
  • Erlaubte Patterns: Patterns, die der Agent für diesen Seitentyp verwenden darf.
  • Erforderliche Sequenz: die minimale, geordnete Pattern-Reihenfolge, die jeder gültige Entwurf enthalten muss.
  • Erlaubte Blöcke: vollständige Block-Allowlist inkl. verschachtelte Blöcke jedes freigegebenen Patterns.
  • Einschränkungen: H1, Wortzahl, Embed, Shortcode, Custom HTML und Theme-Preset-Regeln.
  • Exzerpt-Richtlinie: required, optional oder disabled für diesen Seitentyp.
  • SEO-Contract: erforderliches WordPress-Exzerpt und Meta-Description-Verhalten.
  • Inhaltsmodus: document für Gutenberg-Block-Inhalt und fields für strukturierte Datensätze aus registrierten Feldern.
  • Freigegebene Felder: nur REST-sichtbare Felder für Ziel-Posttyp auswählen und Lese-/Schreibrichtlinie definieren.
  • Beziehungsfelder: Kardinalität, Reihenfolge, erlaubte Ziel-Posttypen und -Status sowie maximale Anzahl festlegen.
  • Taxonomie-Zugriff: Suche, Zuordnung oder bestätigte Erstellung nur für Discovery-Taxonomien, die diesem Blueprint-Zielposttyp zugewiesen sind.

Nutzen Sie den registrierten Block-Selektor statt Blocknamen aus dem Gedächtnis zu tippen. Ein von anderem Plugin stammender Block ist nur gültig, solange der Provider installiert, aktiv und auf dieser Site registriert ist.

Für ein Beziehungsfeld registriert das zuständige Plugin den zugrunde liegenden Posttyp, das Metafeld und den Relationsvertrag. Composer übernimmt generisch den Ausführungspfad: smartcloud-agent-composer/get-content-field-contract publiziert den Workflow, smartcloud-agent-composer/search-relation-targets löst Titel/Slugs zu matches[].id auf, smartcloud-agent-composer/update-content-fields schreibt IDs auf einen zugewiesenen Composer-Entwurf, und smartcloud-agent-composer/inspect-content-fields prüft den gespeicherten Wert. smartcloud-agent-composer/list-content-drafts listet bearbeitbare oder adoptierbare Inhalte und darf nicht für Relation-Lookups genutzt werden.

Taxonomiebegriffe separat verwalten​

Das verantwortliche Plugin oder WordPress Core registriert jede Taxonomie und hängt sie an den Ziel-Posttyp an. Unter Composer Taxonomy Access kann der Site Contract unabhängig Suche, Draft-Zuweisung und bestätigte Erstellung für jede entdeckte Taxonomie erlauben. Es kann außerdem eine maximale Item-Anzahl setzen und das Zuweisungsverhalten auf append oder replace festlegen. Hierarchische Erstellung ist standardmäßig nur auf Root-Ebene erlaubt; optionale Allowlist verwendet beständige Parent-Slugs statt site-lokaler IDs.

Der kontrollierte Agentenfluss ist get-taxonomy-contract -> search-taxonomy-terms -> vorhandene matches[].term_id wiederverwenden -> create-taxonomy-term nur für einen gerechtfertigten fehlenden öffentlichen Begriff mit expliziter Bestätigung -> assign-taxonomy-terms -> inspect-taxonomy-terms. Neue Begriffe benötigen einen natürlichen Namen, beständigen Slug, eigene Archivbeschreibung und die Blueprint-Inhaltssprache. Composer stellt keine Begriffsänderungen bereit; jede Zuweisung bleibt auf einen zugewiesenen Composer-Entwurf mit aktuellen Concurrency-Token begrenzt.

4. Aktive Site neu scannen​

Öffnen Sie Theme & provider und wählen Sie Site scannen nach Installation, Aktivierung oder Update eines Themes oder Provider-Plugins.

Prüfen Sie:

  • aktive Theme-Identität und Version,
  • registrierte Templates und Patterns,
  • alle registrierten Gutenberg-Blöcke,
  • im ausgewählten Config Set referenzierte Patterns,
  • optionale Provider-Metadaten und Laufzeitbereitschaft,
  • fehlende Vertragsabhängigkeiten.

Discovery meldet Fähigkeiten, schreibt aber keine Konfiguration um. Wenn sich das Theme geändert hat, klone den aktiven Satz und passe die Arbeitskopie an.

5. Staging und Anwenden​

Entitäten-Änderungen werden im Browser vorgemerkt. Das Speichern im Entity-Modal erstellt noch keine neue Datenbankrevision. Die Aktionsleiste zeigt ausstehende Ergänzungen, Änderungen und bestätigte Löschungen für den ausgewählten Config Set.

  • Änderungen anwenden schreibt den kompletten Staging-Changeset als eine durch Optimistic-Concurrency geschützte Transaktion.
  • Verwerfen entfernt die Staged-Änderungen ohne in WordPress zu schreiben.

Das Anwenden eines Changesets neu berechnet Config Set Hash und Änderungszeit. Wenn ein anderer Administrator dieselbe Entität geändert hat, gibt Composer einen Konflikt zurück statt zu überschreiben.

6. Validieren und aktivieren​

Wählen Sie Validieren nach jeder bedeutsamen Vertrags-, Theme-, Pattern-, Block- oder Provider-Änderung. Fehler vor Aktivierung beheben; prüfen Sie Warnungen im Kontext.

Aktivierung erfordert eine neue Validierungsbestätigung, gebunden an:

  • exakt den Config Set Checksum,
  • die aktuelle WordPress-Site,
  • den aktuellen Administrator,
  • ein begrenztes Gültigkeitsfenster.

Wählen Sie Aktivieren erst nach vollständiger Prüfung des Arbeits-Sets. Der vorherige Satz wird archiviert und bleibt für Vergleich und bestätigte Wiederherstellung verfügbar.

Vergleichen, wiederherstellen, exportieren und sichern​

  • Mit aktivem Satz vergleichen zeigt die Unterschiede zum laufenden Konfigurationssatz.
  • Archiv als aktiv wiederherstellen validiert den archivierten Satz erneut und verlangt explizite Bestätigung; es verwirft keinen ungespeicherten Browser-Edit.
  • Export erstellt ein checksumsicheres Config-Set-Paket.
  • Audit & Portability -> Export all configuration erzeugt vollständiges Backup aller Config Sets.

Portable Exporte schließen gezielt Credentials und den site-spezifischen Audit-Chain aus. Wiederhergestellte Sätze bleiben inaktiv bis validiert und explizit aktiviert.

Agency-Übergabebeispiel: bestehender Case-Study-Workflow​

Nehmen wir an, eine Agentur hat bereits einen Custom Post Type case_study, die Frontend-Templates und die akzeptierte visuelle Aufbereitung erstellt. Das Theme bleibt für die Präsentation verantwortlich; Composer führt kein universelles WP-Suite-Case-Study-Layout ein.

Die Agentur kann einen Config Set erstellen, der nur den relevanten Workflow freigibt, und einen case_study Blueprint mit folgenden Anforderungen hinzufügen:

  • Titel und Kundenkontext,
  • Sektion Challenge, Umsetzung, Resultat,
  • eine freigegebene Call-to-Action,
  • bestehende Mediathek-Metadaten,
  • erlaubte Kategorien, Tags und SEO-Metadaten,
  • das bereits genutzte Template, Patterns, Blöcke und die Reihenfolge.

Wenn der Kunde den kompatiblen Agenten für eine neue Case Study fragt, lädt der Agent dieses Blueprint und den aktiven Designkontext, bereitet Inhalte vor, validiert die vollständige Struktur und erstellt einen Entwurf. Eine menschliche Prüfung von Fakten, Medien und Darstellung erfolgt vor Freigabe. Veröffentlichung per WordPress oder optionalem Static Publisher bleibt ein separater Schritt.

Diese Übergabe macht die Entscheidungen der Agentur in einen wiederholbaren Inhaltsprozess. Composer oder der Kunden-Agent müssen das Site-Design dafür nicht neu entwerfen.

Vor Verbindung eines Agenten prüfen​

Stellen Sie sicher:

  1. genau ein Config Set ist aktiv,
  2. jeder gewünschte Seitentyp hat einen gültigen Blueprint,
  3. alle benötigten Patterns, Templates und Blöcke existieren,
  4. optionale Provider melden bereit oder sind nicht im Blueprint enthalten,
  5. der dedizierte Agenten-Benutzer hat die Rolle smartcloud_agent,
  6. der MCP-Status in Composer den erwarteten Endpunkt meldet.