Destruktive Operationen

TL;DR

Eine destruktive Operation auf Pipelogic ist jedes Verb, das Plattform-Zustand entfernt — das Löschen einer component, eines backend, einer Datei oder einer node. Jede läuft auf einem Fetch-und-Bestätigungs-Vertrag: Der Aufrufer liest zuerst die betroffene Zeile, bestätigt dann ausdrücklich das Entfernen, und erst dann verschwindet die Ressource.
Der Vertrag ist über alle Oberflächen hinweg derselbe: App, REST API, ppl CLI. Keine Oberfläche bietet einen Pfad, der die Bestätigung überspringt; die Prüfung lebt im Plattform-Vertrag, nicht in einem bestimmten Client.
Die Bestätigungsform hängt von der Ressource ab. Zweistufig für component delete im Agent-Modus (der erste Aufruf liefert die vollständige Zeile in einem Bestätigungs-Envelope; der zweite Aufruf fügt --yes zum Festschreiben hinzu). Einstufig für backend delete im Agent-Modus (die aufrufende Identität ist die Zustimmung). --yes im Voraus für file und node delete (die Zeile wurde bereits beim Fetch geprüft).
Updates sind nicht destruktiv. update-Verben wenden partielle Felder an, nehmen kein --yes und brauchen keine Bestätigung — der schlimmste Fall ist das falsche geänderte Feld, das ein weiteres Update korrigiert, nicht die verschwundene Ressource.
Das Promoten einer prerelease in den released-Katalog ist die empfohlene Übergabe an einen menschlichen Reviewer: Agent-Flows legen die Kandidaten-prerelease offen, und eine Person führt das promote aus. Die Übergabe ist wichtig, weil das Promoten den öffentlichen Vertrag bewegt — was andere backends pinnen, worauf latest und default auflösen.

Warum ein Fetch-und-Bestätigungs-Vertrag existiert

Der Fetch-und-Bestätigungs-Vertrag setzt das Lesen vor das Entfernen: Der Aufrufer sieht, was entfernt wird, solange es noch existiert, statt es im Nachhinein zu entdecken. Die Prüfung ist Teil des Vertrags selbst, keine nachträgliche Nachricht.

Jedes destruktive Verb hat einen Schritt, in dem der Aufrufer die betroffene Ressource betrachtet — entweder durch ein vorheriges separates get oder durch das Lesen der Zeile, die in einem vom ersten Aufruf zurückgegebenen Bestätigungs-Envelope getragen wird. Dieser Schritt ist das Tor, kein Darstellungsdetail. Ihn ohne Lesen zu durchschreiten kostet mehr Mühe als das Lesen, sodass der vorsichtige Pfad der Standard ist.

Dasselbe Tor gilt für jeden Aufrufer. Ein Mensch, der den Lösch-Button der App drückt, sieht die Zeile in einem Bestätigungsdialog. Ein Aufrufer, der ppl component delete im Agent-Modus ausführt, liest das Bestätigungs-Envelope, entscheidet und gibt den Aufruf mit --yes erneut aus. Bei den Löschungen, die --yes im Voraus nehmen, geschah das Lesen während des vorausgehenden Fetch. Keine Oberfläche lässt einen Aufrufer das Lesen überspringen.

Mentales Modell

┌──────────────────────────────────────────────────────────┐
│ 1. ZEILE HOLEN                                             │
│    list / get / versions                                   │
│    (oder Bestätigungs-Envelope beim ersten Aufruf)         │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 2. ZEILE LESEN                                             │
│    Aufrufer prüft: id, workspace, scope,                   │
│    version, tags, Abhängige                                │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 3. BESTÄTIGEN                                              │
│    destruktiver Befehl mit dem Vertrag,                    │
│    den die Ressource verlangt                              │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
                       Ressource weg

Jeder destruktive Aufruf durchläuft diese drei Schritte. Das Fetch kann explizit (ein separater list / get-Aufruf) oder implizit (der erste component delete-Aufruf im Agent-Modus liefert die Zeile in einem Bestätigungs-Envelope) geschehen; so oder so hat der Aufrufer die Zeile vor dem Festschreiben gesehen.

Die Bestätigungsformen

Verwende diesen Abschnitt, um zu wissen, welche Bestätigung gilt, bevor du zu einem Verb greifst.

Zweistufig (component delete im Agent-Modus). Der erste Aufruf liefert ein Success-Envelope, dessen data action: "component.delete.confirmation_required" und die vollständige component-Zeile (oder version-Zeile bei einem Einzelversions-Delete) trägt. Die Zeile ist im Envelope. Prüfen, entscheiden, dann denselben Aufruf mit --yes erneut ausführen, um festzuschreiben. Diese Form gilt, weil das Löschen einer component kaskadiert — Versionen, Releases, Abhängige — sodass der Vertrag offenlegt, was die Kaskade betrifft, bevor der Aufrufer zustimmt. Das Löschen einer component im Agent-Modus erfordert außerdem, dass die component leer ist: zuerst die ephemeren Releases löschen, dann die nun leere component.

Einstufig (backend delete im Agent-Modus). Die aufrufende Identität wird als ausdrückliche Zustimmung behandelt: Agenten, die das backend bereits via get geprüft haben, brauchen kein separates --yes. backend-Löschungen sind während ephemerer Testarbeit häufig, sodass ein zweistufiger Vertrag Round-Trips ohne Sicherheitsgewinn hinzufügen würde; das Identitäts-Tor ist es, das die einstufige Form solide macht.

--yes im Voraus (file delete, node delete). Die Zeile wurde während des vorausgehenden Fetch geprüft (file list --query=… oder node list --query=…). Der Vertrag behandelt dieses Fetch als das Lesen, und das --yes ist die ausdrückliche Bestätigung, dass es das richtige Ziel bestätigte. Diese Form gilt für Ressourcen, deren Lösch-Verhalten lokal und in sich geschlossen ist; das Flag verhindert ein Löschen anhand einer veralteten id, ohne einen separaten Envelope-Round-Trip zu verlangen.

Die Formen unterscheiden sich, weil der Vertrag dem entspricht, was jede Operation tut. Die Plattform wendet den leichtesten Vertrag an, der die Fehlermodus, den die Operation erzeugen kann, dennoch verhindert.

Was nicht destruktiv ist

Updates sind nicht gegated. ppl component update, ppl file update und ppl backend update wenden die übergebenen Felder an und lassen alles andere unberührt. Der schlimmste Fall ist das falsche geänderte Feld, das ein weiteres Update korrigiert; der schlimmste Fall beim Löschen ist die verschwundene Ressource, was nicht passiert. Die Plattform behandelt sie als unterschiedliche Operationen und gibt ihnen unterschiedliche Verträge.

Auflisten, Inspizieren, Holen, Deployen, Redeployen, Undeployen und jedes schreibgeschützte Verb sind ebenfalls nicht gegated. Ein deployment abzubauen ist reversibel — redeploy vom selben backend. Das Prinzip ist konsistent: gate die irreversiblen Entfernungen, lass die reversiblen Operationen ohne Bestätigung.

Promote an einen Menschen übergeben

Das Promoten einer prerelease in den released-Katalog (ppl component promote) bewegt den öffentlichen Vertrag — was andere backends pinnen werden, worauf latest und default auflösen. Der empfohlene Flow behandelt dies als menschliche Entscheidung: Ein automatisierter Flow baut und validiert die prerelease, und eine Person trifft das Festschreiben in den released-Kanal.

Agent-Flows, die zur promote führen, halten beim sicheren Schritt an und legen den Kandidaten offen — die prerelease-id und den Release-Branch. Eine Person nimmt diesen Kandidaten auf, überprüft die Beweisschleife, die ihn erzeugt hat, und führt das promote aus. Diese Übergabe ist es, die eine Änderung am öffentlichen Vertrag zu einer bewussten menschlichen Entscheidung macht.

Siehe Release-Semantik für die vollständige Diskussion.

Wie sich der Vertrag zusammensetzt

Das Fetch-und-Bestätigungs-Muster setzt sich mit den übrigen Schutzmechanismen der Plattform zusammen. Ein Team, das ephemere Test-backends aufräumt, nutzt Leases — das Commit oder Rollback der lease ist selbst die Bestätigung, beschränkt auf genau die Ressourcen, die die lease besitzt. Ein Team, das mit backend-graph-Mutationen experimentiert, verlässt sich auf das Operationslog — destruktive graph-Operationen sind rückgängig machbar, solange das backend selbst nicht gelöscht ist. Ein Team, das Automatisierung schreibt, verlässt sich auf die im Agent-Modus offengelegten Verträge für destruktive Operationen — die Envelope-Formen machen maschinell entscheidbar, ob eine Operation destruktiv ist und eine Bestätigung braucht.

Der Vertrag garantiert, dass ein Löschen nicht in einem einzigen Aufruf ohne ein Lesen geschehen kann, auf jeder Oberfläche und für jeden Aufrufer. Diese Eigenschaft lässt Automatisierung die Plattform steuern, ohne dass jeder Aufrufer sein eigenes Lösch-Bestätigungs-Muster neu erfindet.

Wo das hineinpasst

Destruktive Operationen sind dort, wo die Entfernungs-Verträge der Plattform am direktesten gelten. Der Fetch-und-Bestätigungs-Vertrag, die ressourcenspezifischen Bestätigungsformen und die menschliche Übergabe beim Promoten machen ein Entfernen gemeinsam zu einer zweiteiligen Handlung: die Zeile lesen, dann bestätigen. Jede destruktive Operation kostet ein zusätzliches Lesen oder Flag, und im Gegenzug ist es schwer, versehentlich die falsche Ressource zu löschen.

Verwandt

Agent-Modus-Ausgabe — die Envelope-Formen, die die Verträge nutzen.
Release-Semantik — die menschliche Übergabe beim Promoten.
Der lease-Lebenszyklus — beschränkte Bereinigung, die dieselben Sicherheitshaltungen respektiert.
Backend-Operationen — rückgängig machbare graph-Mutationen unter dem Operationslog.
Mit einem laufenden backend testen — sauberer Abbau via backend undeploy und dann backend delete.