Clever Engines Layer · Zusammenhänge
Betrieb und Nachweise
Quellen, Lebenszyklen und Werkzeuge gezielt zusammenbringen.
Ein System, mehrere Lebenszyklen
Der Betriebsstand besteht nicht aus einer einzigen großen Datei. Controls koordiniert, Live hält Beobachtungen, Participants spiegelt die Teilnehmerstruktur und Resistant besitzt seine eigenen Dateninstanzen. Resilient stellt die daraus lesbaren Sichten dar.
Ein Neustart hat deshalb je nach Baustein eine andere Bedeutung. Ein weiterlaufender Participants-Prozess kann die Registry über einen Controls-Neustart erhalten; nach einem vollständigen Rechnerneustart muss sie neu aufgebaut werden. Live beginnt dann mit einer neuen Epoch. Resistant hat eigene Regeln für dauerhafte Daten.
Von der Anzeige zur Quelle
Ein sinnvoller Befund enthält Ziel, Quelle, Zeitpunkt und das tatsächliche Ergebnis. Für Beobachtungen kommen Observation-ID, Messperiode, Epoch und Revision hinzu. So lässt sich unterscheiden, ob zwei Oberflächen denselben Stand oder unterschiedliche Erfassungszeitpunkte zeigen.
Die Diagnose liest Paketwissen aus den ausgelieferten Indizes. Das ist keine Messung des laufenden Prozesses. Health, Systembild, Teilnehmer, Jobs, Beobachtungen und Ereignisse werden auf ausdrücklichen Abruf über Controls gelesen und im gemeinsamen Terminal ausgegeben.
Eine fehlgeschlagene Abfrage bleibt sichtbar. Sie wird nicht durch einen fiktiven Normalzustand ersetzt. Dokumentation und Werkzeugindex bleiben davon unabhängig lesbar.
Werkzeuge mit klarer Wirkung
Jeder Paketindex enthält den rekursiven BAT-/PowerShell-Bestand. Der Pfad, die Aufgabe und der Aufrufweg erklären, ob ein Skript liest, einen Build erzeugt, Testdaten verändert oder in einen Dienst eingreift. Ein sprechender Name ersetzt diese Unterscheidung nicht.
Die Web-Diagnose ist keine Shell. Ihre benannten Abfragen sind von den lokalen Werkzeugen getrennt. Registrieren, Installieren, Starten, Stoppen, Reorganisieren und Bereinigen bleiben explizite Eingriffe in der jeweiligen Umgebung.
Das WordPress-Runner-Setup verwendet eine gemeinsame PowerShell-Implementierung für Plan, Prüfung und Einrichtung. „INSTALLED“ bestätigt eine angelegte Aufgabe; erst ein späterer Heartbeat belegt den tatsächlich ausgeführten Kontakt.
Ein Paket austauschen
Programmstand und lokale Bestände werden getrennt behandelt. Eine saubere Neuablage des bereinigten Pakets verhindert, dass entfernte Wrapper und alte Historien im Zielverzeichnis liegenbleiben. Die im Paketindex benannten lokalen Konfigurationen und Daten werden gezielt übernommen.
Vor einem Dienstwechsel stehen ein gesicherter Ausgangsstand und ein Rückweg. Nach dem Wechsel folgen Versionsnachweis, Health, eine lesende Abfrage und die Kontrolle der Teilnehmer. Ein erfolgreicher Build allein belegt noch nicht das Zusammenspiel unter IIS und Windows.
Bei einem Controls-Update bleibt der Participants-Mirror für die Übergabe möglichst am Leben. Werden beide Prozesse beendet, ist diese RAM-Kontinuität weg; die Teilnehmer müssen ihre Registrierung wieder aufbauen.
Speicher ist nicht überall gleich
Die Teilnehmerregistrierung und die Live-Beobachtungen sind flüchtig. Die dauerhafte Zulassung in Controls ist davon getrennt. Resetjournal und Mess-Pending-Sicherung besitzen im aktuellen Quellstand weiterhin Dateipfade; sie werden nicht mit dem Registry-Mirror gleichgesetzt.
Resistant unterscheidet flüchtige Overlays und bestätigte dauerhafte Operationen. Ob ein Ergebnis einen Prozess- oder Rechnerneustart übersteht, ergibt sich aus dem benutzten Vertrag, nicht aus dem Paketnamen.
Die Wissensbasis pflegen
Pro Paket ist die index.htm der kanonische Bezug. Möglichkeiten, technische Eigenschaften, Werkzeugbestand und History beschreiben denselben Quellstand. Ihr eingebettetes Kontextobjekt macht diese Angaben maschinenlesbar; daraus entstehen keine zusätzlichen Ausführungsrechte.
Die History hält wenige wesentliche Architekturentscheidungen fest. Kleine Korrekturen bleiben außerhalb des sichtbaren Leseflusses. Der gemeinsame Dokumentexport wird aus den Paketindizes erzeugt und gegen Identitäten, Werkzeugpfade und Prüfsummen geprüft.
Neue Fähigkeiten brauchen einen benannten Vertrag und eine tatsächliche Implementierung. Die Wissensbasis beschreibt sie erst dann als vorhandene Möglichkeit. Damit bleiben Auskünfte für Menschen und eine spätere CEL-AI nachvollziehbar.