# Inhalte, Felder und Status

Werkzeugnamen: `lit-…` sind direkt aufrufbare Tools; `lit/…` sind Abilities, die über
`mcp-adapter-execute-ability` (Name in `ability_name`, Eingaben in `parameters`) aufgerufen werden.

## Inhaltstypen erkennen

- `lit-content-types` ohne Parameter listet alle Inhaltstypen (Seiten, Beiträge, eigene Typen) mit
  Taxonomien, Anzahl und ob Divi dafür aktiv ist.
- `lit-content-types` mit `post_type` liefert zusätzlich alle Felder: Schlüssel, Typ, Pflicht, Auswahlwerte
  (`choices`), Beziehungsziel (`related`) und Schreibstatus:
  - `writable` – sicher beschreibbar (Pods-Feld oder registriertes Meta-Feld),
  - `readonly` – nicht beschreibbar,
  - `unknown` – vorhandener Meta-Schlüssel ohne bekannten Typ; Schreiben geht, der Wert wird unverändert
    gespeichert (Warnung in der Antwort).

## Lesen und Suchen

- `lit-content-query`: Filter `status`, `search`, `taxonomy` (`{taxonomy, terms: [IDs oder Slugs]}`),
  `field` (`{key, value, compare}`), `date_after`/`date_before` (JJJJ-MM-TT), `parent`; Blättern mit
  `next_cursor` → `cursor`. `field` und `taxonomy` sind auf Feld- bzw. Taxonomienamen beschränkt, die
  `lit-content-types` für diesen Inhaltstyp auch anzeigt – ein unbekannter Name wird abgelehnt, keine leere
  Trefferliste. Geliefert werden nur Einträge, die der verbundene Nutzer selbst bearbeiten darf (fremde
  Entwürfe/private Inhalte ohne die passende Berechtigung erscheinen nicht).
- `lit-content-get`: alle Daten eines Eintrags inkl. Feldern, Begriffen, Beitragsbild und `rev`.
  Bei Divi-Seiten fehlt `content`; den Aufbau liest `lit-divi-outline`, geändert wird er mit den
  Divi-Werkzeugen (siehe `divi-structure`); Titel, Auszug, Felder und Begriffe gehen weiter über
  `lit-content-update`.

## Anlegen und Ändern

- `lit-content-create` legt immer einen **Entwurf** an. Felder werden gegen das Schema geprüft; ein Fehler
  bricht den ganzen Aufruf ab (`fields.<schlüssel>` im Fehler nennt die Ursache). Divi-Seiten gleich mit
  Inhalt: `divi` = Liste von Abschnitten in Kurzform (siehe `divi-shortform`) statt `content`; die Antwort
  enthält dann die `tree_rev` für weitere Divi-Änderungen.
- `lit-content-update` ändert nur die übergebenen Werte, der Status bleibt. `rev` aus `lit-content-get` ist
  **Pflicht** – hat jemand parallel gespeichert (Inhalt, Titel, Auszug, Status oder irgendetwas anderes am
  Eintrag), kommt `rev_mismatch`: neu lesen, Änderung auf dem aktuellen Stand wiederholen.
- Begriffe: `terms: {"category": [4, "Neuer Begriff"]}` ersetzt die Zuordnung dieser Taxonomie (IDs oder
  Namen; unbekannte Namen werden angelegt, falls erlaubt).
- Felder leeren: Wert `null`. Pflichtfelder können nicht geleert werden.
- Beziehungsfelder erwarten IDs von Einträgen, die der Nutzer lesen darf; Datei-/Bildfelder Anhang-IDs aus der
  Mediathek.
- Einträge im Papierkorb werden nicht geändert (auch nicht veröffentlicht, geplant oder wiederhergestellt);
  zuerst in WordPress aus dem Papierkorb holen.
- Ist ein geplanter Eintrag über seinen Veröffentlichungszeitpunkt hinaus (verpasster Termin), würde jedes
  Speichern ihn sofort veröffentlichen – `lit-content-update`, `lit/revision-restore` und
  `lit/post-replace-with-copy` verweigern das dann. Mit dem Nutzer klären: jetzt veröffentlichen
  (`lit-post-publish`) oder neu planen (`lit/post-schedule`).

## Status

- Veröffentlichen, Zurückziehen und Planen sind eigene Werkzeuge (`lit-post-publish`, `lit/post-unpublish`,
  `lit/post-schedule` mit `date` = „JJJJ-MM-TT HH:MM“ in der Zeitzone der Website). Nur auf ausdrücklichen
  Wunsch des Nutzers verwenden. Ein **privater** Eintrag wird durch Planen zum Zeitpunkt öffentlich (die
  Antwort warnt davor).
- `lit/post-trash` legt in den Papierkorb (nie endgültig) und braucht `confirm: true` nach Rückfrage. Ist der
  Eintrag Startseite, Beitragsseite oder in Menüs verlinkt, nennen Rückfrage und `warnings` das – dem Nutzer
  weitergeben.

## Sicher überarbeiten

1. `lit/post-duplicate` → Entwurfskopie; die Antwort enthält die `rev` der Kopie für `lit-content-update`.
2. Kopie mit `lit-content-update` bzw. den Divi-Werkzeugen bearbeiten und dem Nutzer die Vorschau zeigen;
   `lit-page-render-summary` fasst den gerenderten Inhalt zusammen.
3. `lit/post-replace-with-copy` übernimmt die Kopie ins Original (ID, URL, Status und Menüeinträge bleiben).
   Voraussetzungen: die Kopie muss noch Entwurf oder ausstehend sein, `rev` des Originals aus
   `lit-content-get` ist Pflicht (sie deckt Titel, Inhalt, Auszug und Status ab – Felder/Meta, die direkt am
   Original geändert wurden, werden dabei überschrieben), und erst nach Rückfrage mit `confirm: true`
   aufrufen. Vorher entsteht eine Revision **und** eine vollständige Sicherung des bisherigen Originals im
   Papierkorb (`backup_id` in der Antwort); danach wandert die Kopie ebenfalls in den Papierkorb. Ist der
   Papierkorb der Website deaktiviert, wird der Austausch verweigert, statt die Kopie endgültig zu löschen.

Jede Änderung liefert `log_id`. Eine `revision_id` (Revision mit dem Stand vorher) liefern nur
`lit-content-update`, `lit/post-replace-with-copy` und `lit/revision-restore`; bei allen anderen Tools ist sie
`null`. Rückgängig: `lit/revisions-list` → `lit/revision-restore` mit der `rev` des Eintrags (aus
`lit-content-get`) und `confirm: true`. Revisionen umfassen Titel, Inhalt und Auszug – Felder und Begriffe
nicht (dafür bei `lit/post-replace-with-copy` die Sicherung `backup_id`).

## Wenn ein Schreibvorgang fehlschlägt

Fehler stecken als JSON (`code`, `message`, `hint`, ggf. weitere Felder) in der Fehlermeldung. Schlägt ein
Schreibvorgang nach ersten Änderungen fehl, ist `code` = `write_failed` (alles wurde zurückgenommen, nichts
wurde gespeichert) oder `partial_write` (die Rücknahme war unvollständig). Bei `partial_write` vor einem
erneuten Versuch immer erst den aktuellen Stand prüfen (`lit-content-get`,
`lit/menu-get` o. Ä.) statt den Aufruf einfach zu wiederholen – dem `hint` folgen.