m1nga/Schleifen-Systemarchitekt

Loop-Systemarchitekt

Verwandle eine wiederholte Aufgabe in ein beobachtbares Kontrollsystem, das sein Ergebnis ausführen, belegen, nach einer Unterbrechung wiederherstellen und sich verbessern kann, ohne seinen Zweck neu zu schreiben.

Wähle den Modus

• Audit: Untersuche einen bestehenden Workflow und melde fehlende oder offene Schleifenteile. Keine Bearbeitung, es sei denn, es wird darum gebeten.
• Design: Erstelle den Vertrag, das Zustandsschema, das Rollendiagramm, die Evaluierungen und das Laufzeitdesign.
• Operationalize: Implementiere den Controller, die Adapter, die Persistenz, die Belege und einen Ein-Befehl-Ausführungspfad.
• Evolve: Analysiere abgeschlossene Läufe, validiere einen vorgeschlagenen Loop-/Wissens-/Fähigkeitsverbesserung und fördere oder lehne ihn ab.

Wenn der Benutzer darum bittet, etwas zu „bauen“ oder „zum Laufen zu bringen“, schließe die Operationalisierung ein. Ein reiner Markdown-Plan ist kein betriebsfähiger Loop.

Beginne mit der gelebten Realität

1. Lese die Repository-Anweisungen und die Artefakte, die der Benutzer in den Gültigkeitsbereich gelegt hat.
2. Untersuche die tatsächlichen Werkzeuge, Einstiegspunkte, Zustandsdateien, Tests, Scheduler, Agenten-CLIs und den nicht bereinigten Arbeitsbaum.
3. Trenne aktuelle autoritative Eingaben von Referenzmaterial. Verwende kein Modellgedächtnis, um Lücken zu füllen.
4. Klassifiziere den Loop:
   • Terminal: Ein Ziel mit einer demonstrierbaren Ziellinie.
   • Wiederkehrend: Jeder Lauf endet, während der Monitor/Dienst bis zur Beendigung weiterläuft.
5. Gib an, was existiert, was fehlt und was nur behauptet wird, bevor du etwas änderst.

Für ein vollständiges Audit lies audit-rubrik.md.

Erfordere einen geschlossenen Regelkreis

Identifiziere und verbinde alle folgenden Elemente:

1. Zielsetzung und Eigentümer;
2. Abschlussbedingung oder Erfolgsbedingung pro Lauf;
3. Grenzen und Herkunft autoritativer Quellen;
4. Auslöser und kostengünstiger Vorabcheck;
5. Sensor und gesammeltes Signal;
6. Komparator, Fenster und Schwelle/Regel;
7. Regler und endlicher Entscheidungsraum;
8. Aktuator und der Pfad, der das neue Ergebnis zum Sensor zurückführt;
9. Persistenter Zustand, Cursor, Ereignisprotokoll und Belegspeicher;
10. Verantwortlichkeiten von Orchestrator, Ausführer und unabhängigem Verifizierer;
11. Offene Fähigkeits-/Skill-Entdeckung und Erstellung von Kandidaten-Skills;
12. Autorisierungsgrenzen und geschützte Felder;
13. Akzeptanzevaluierungen und erforderliche Belege;
14. Wiederholungen, Zeitüberschreitungen, Backoff, Fehlerklassifizierung und Rollback;
15. Idempotenz, Deduplizierung, Parallelitätssperre und Nebenwirkungs-Engpass;
16. Token-, Kosten-, Turn- und Wanduhrzeit-Budgets;
17. Beobachtbarkeit, Warnungen und ein No-op-Erfolgszustand;
18. Direkter Ersatz der ersetzten aktiven Wahrheit;
19. Erfahrungsdestillation und kontrollierte Beförderung;
20. Stopp-, Pause-, Abbruch- und Ruhestandsbedingungen.

Fehlende Sensor-Aktuator-Rückkopplung bedeutet offene Schleife. Fehlender persistenter Zustand bedeutet eine wiederholte Eingabeaufforderung. Fehlende Verifiziererbelege bedeutet selbstbehaupteten Abschluss. Fehlender Regler/Auslöser bedeutet eine von Menschen zu bedienende Prozedur.

Minimalprofil

Nicht jeder Loop benötigt alle zwanzig Elemente. Für einen Single-Operator-Cron-fähigen Loop – ein Benutzer, eine Maschine, geringer Schadensradius, keine gemeinsamen Nebenwirkungen – ist ein Vertrag mit acht Elementen ausreichend:

1. Zielsetzung und Eigentümer;
2. Erfolgsbedingung (Abschluss oder pro Lauf);
3. Auslöser und kostengünstiger Vorabcheck;
4. Aktuator und sein Nebenwirkungspfad;
5. Persistenter Zustand und Cursor;
6. Idempotenz/Deduplizierung auf dem Nebenwirkungspfad;
7. Beobachtbarkeit: wo das letzte Ergebnis und die nächste Aktion zu sehen sind;
8. Ruhestandsbedingung.

Erkläre die Auslassungen explizit, anstatt sie leer zu lassen: setze learning.enabled: false und setze capabilities.discovery: "none" mit einem reason-Feld. Der Linter akzeptiert beides. Siehe loop.contract.minimal-example.json für ein erfolgreiches Minimalbeispiel. Führe ein Upgrade auf den vollständigen Vertrag durch, wenn der Loop gemeinsame Nebenwirkungen, einen zweiten Betreiber, externe Mandanten oder jede Form von Selbstmodifikation erhält.

Erstelle ein Loop-Paket

Passe die Namen an das Repository an, behalte aber einen kanonischen maschinenlesbaren Vertrag und einen Zustandsdatensatz bei. Loop-Pakete, Status und Belege leben im Projekt des Benutzers, niemals innerhalb dieses Skill-Pakets. Das Standardpaket ist:

loop/
├── LOOP-CONTRACT.md          menschenlesbarer Betriebsvertrag
├── loop.contract.json       maschinenlesbarer kanonischer Vertrag
├── RUN-STATE.json           aktueller Lauf, Cursor, Versuche, nächste Maschinenaktion
├── events/                  nur-anhängbare Laufereignisse oder ein gleichwertiger Ereignisspeicher
├── evidence/                vom Verifizierer lesbare Quittungen
├── evals/                   deterministische und semantische Akzeptanzprüfungen
├── knowledge/               typisiertes gefördertes Wissen, keine Rohprotokolle
├── candidates/              nicht geförderte Lektionen und Skill-Änderungen
└── scripts/run-loop         Ein-Befehl-Controller oder projektnative Entsprechung

Verwende loop-contract.md für den Feldvertrag. Kopiere loop.contract.template.json, fülle jeden Platzhalter aus und führe dann aus:

python3 scripts/loop_lint.py /path/to/loop.contract.json

Verwende die Kopie innerhalb dieses Skills, wenn das Projekt den Linter nicht bereitgestellt hat. Wenn nichts auf die Festplatte geschrieben werden kann, gib den Vertrag und den Controller als kopierbaren Text aus und sage, was noch auf die Festplatte gelegt werden muss, bevor der Loop betriebsbereit ist.

Baue den Controller, nicht nur die Anweisungen

Der Controller muss sicherstellen, dass ein einziger Aufruf den Loop voranbringt, ohne dass der Benutzer zwischen Agenten kopieren und einfügen muss:

1. Erwerbe eine Parallelitätssperre und leite einen Idempotenzschlüssel ab;
2. Lade und prüfe den Vertrag und den Zustand;
3. Überprüfe die Hashes der eingefrorenen Quellen oder die aktuelle Quellenautorität;
4. Führe den kostengünstigen Auslöser/Vorabcheck aus und zeichne einen No-op-Erfolg auf, wenn keine Arbeit existiert;
5. Löse die erforderlichen Fähigkeiten auf;
6. Erstelle ein minimales Kontextpaket für den Orchestrator/Ausführer;
7. Führe in einem isolierten Arbeitsbereich aus, wenn Änderungen möglich sind;
8. Erfasse Ausgaben, Kosten, Tool-Aufrufe, Diffs und Belege;
9. Führe einen unabhängigen Verifizierer aus, der seine eigenen Schreibvorgänge nicht zertifizieren kann;
10. Bei Fehlern klassifiziere und leite eine begrenzte Reparatur, Wiederholung, Rollback oder einen Stopp ein;
11. Bei Bestehen befördere das Ergebnis atomar und aktualisiere den aktuellen Zustand;
12. Hänge ein unveränderliches Ereignis/eine Quittung an;
13. Rufe die Destillation nur auf, wenn ihr Auslöser erfüllt ist;
14. Gib die Sperre frei und lege die nächste maschinenausführbare Aktion offen.

Minimale Verifiziererunabhängigkeit, nach Engine:

• Claude Code (oder jede Laufzeit mit Unteragenten): Führe den Verifizierer als Unteragenten mit frischem Kontext aus, der nur den Vertrag, die Akzeptanzprüfungen und die Belegpfade erhält – nicht das Gespräch des Ausführers.
• Kein Unteragentenmechanismus: Führe den Verifizierer als separaten Prozess oder separaten Aufruf aus, der die Belege von der Festplatte neu einliest und ein Urteil gegen die Akzeptanzprüfungen zurückgibt.
• Keines von beidem verfügbar: Derselbe Kontext, der seine eigene Arbeit überprüft, ist Selbstüberprüfung – Leistung, nicht Verifikation. Sage dies im Audit, anstatt es als Verifizierer zu bezeichnen.

Bevorzuge deterministischen Code für Auslöser, Zustandsübergänge, Schema-Prüfungen, Berechtigungen, Wiederholungen, Hashes und Beförderung. Verwende LLMs für Urteile, Planung, Diagnose und Inhalte, die nicht mechanisch entschieden werden können.

Entdecke oder erstelle Skills ohne statische Zulassungsliste

Verwende offene Entdeckung mit kontrollierter Ausführung:

1. Leite einen Fähigkeitenvertrag aus der Aufgabe ab: Eingabe, Ausgabe, Nebenwirkungen, Belege, Risiko.
2. Durchsuche installierte Skills und Projektfähigkeiten nach Metadaten und Vertragspassung.
3. Überprüfe Herkunft und Abhängigkeiten; importiere keine eingebettete Projektidentität als Wahrheit.
4. Sandboxe einen Kandidaten-Skill und führe fähigkeitsspezifische Evaluierungen durch.
5. Wenn keiner passt, erstelle einen Kandidaten-Skill isoliert mit eigenen Beispielen und Evaluierungen.
6. Befördere eine Version nur, nachdem sie Sicherheits-, Datenschutz-, Funktions- und Regressionstests bestanden hat.
7. Registriere standardmäßig lokal. Die externe Veröffentlichung folgt der separaten Richtlinie der besitzenden Umgebung.

Offene Entdeckung gewährt keine offene Autorität. Mandate, Datenumfang, Nebenwirkungsrichtlinie und Laufzeitberechtigungen schränken jeden Skill weiterhin ein.

Destilliere Erfahrung in nutzbares Wissen

Füttere niemals ein ständig wachsendes Protokoll an jeden Agenten. Halte rohe Belege, episodische Zusammenfassungen, Kandidatenlektionen, kanonisches Wissen, prozedurale Skills und Evaluierungen getrennt.

Führe den Beförderungspfad aus:

Trace + Ergebnis
→ normalisierte Episode
→ Kandidatenlektion
→ deduplizieren und auf Konflikte prüfen
→ gegen vorherige Läufe und Gegenbeispiele abspielen
→ Schatten- oder Vorabversion
→ eine Version befördern
→ die nächsten Läufe überwachen
→ behalten oder zurückrollen

Löse die Destillation bei wiederholten Fehlern, wiederholter manueller Arbeit, Drift, Kostenregression, aussagekräftigen Ergebnisbelegen oder einer konfigurierten Stichprobengröße aus – nicht nur, weil Zeit vergangen ist. Lies destillation.md, bevor du die Lernschicht entwirfst oder änderst. Wenn ein dedizierter Destillationsskill (wie experience-pack) installiert ist, überlasse diesem den Destillationsworkflow selbst; dieser Skill entwirft den Loop, der ihn aufruft.

Der Evolutionsprozess kann SOPs, Auslöser, Kontextverpackung, Skripte, Skills, Abruf und Betriebsschwellenwerte innerhalb der delegierten Autorität verbessern. Er darf nicht stillschweigend das Ziel, die Quellengrenze, die Mandanten-/Datenschutzgrenze, das Autoritätsmodell oder die Evaluierung, die den Erfolg definiert, neu schreiben.

Ersetze aktive Wahrheit sauber

Für jedes akzeptierte Update:

1. Berechne den Einflussgraphen über Vertrag, Zustandsschema, Code, Tests, Dokumente, Ansichten und Skills;
2. Deklariere ERSETZT, ENTFERNT und BEHÄLT;
3. Aktualisiere alle Abhängigen;
4. Entferne ersetzte Formulierungen und Werte aus dem aktiven Abruf;
5. Führe Widerspruchs-/Veraltete-Werte-Scans durch;
6. Führe betroffene Happy- und Fehlerpfad-Evaluierungen durch;
7. Führe eine Null-Kontext-Sonde durch, die genau eine aktuelle Antwort wiederherstellen muss;
8. Befördere atomar; behalte frühere Versionen nur in der Versionskontrolle/Event-Historie, nicht im aktiven Kontext.

Kalibriere Autonomie

• Führe reversible, begrenzte Aktionen automatisch aus, wenn die deterministische und unabhängige Verifikation bestanden wird.
• Verwende Vorab-, Schatten-, Dual-Verifikation und Rollback für risikoreichere automatisierte Aktionen.
• Halte nur für den Benutzer an, wenn die Autorität fehlt, eine erforderliche Entscheidung das Ziel ändert oder die Aktion materiell irreversibel und nicht bereits autorisiert ist.
• Mache keine routinemäßige menschliche Genehmigung zu einem versteckten Aktuator in einem Loop, der als autonom beworben wird.

Überprüfe den Abschluss

Bezeichne den Loop erst dann als betriebsbereit, wenn alle folgenden Punkte zutreffen:

• Ein Befehl oder ein konfiguriertes Ereignis kann ihn voranbringen, ohne dass Aufforderungen weitergereicht werden müssen;
• Unterbrechungswiederherstellung setzt den Betrieb ab dem gespeicherten Zustand fort, ohne akzeptierte Arbeit zu wiederholen;
• Doppelte Auslöser können keine doppelten Nebenwirkungen verursachen;
• Verifiziererfehler führt zu einer begrenzten Reparatur oder einem sauberen Stopp;
• Sowohl der Erfolgs- als auch der Fehler-Schließen-Pfad haben Belege;
• Ein Lauf ohne Arbeit wird erfolgreich und kostengünstig beendet;
• Der aktuelle Status, das letzte Ergebnis, die Kosten, der offene Fehler und die nächste Aktion sind beobachtbar;
• Ein Evolutionskandidat wurde wiederholt und entweder befördert oder korrekt abgelehnt (unter dem Minimalprofil mit learning.enabled: false verzichtbar);
• Ein Agent ohne Kontext kann den aktuellen Vertrag und die nächste Aktion allein aus den aktiven Dateien erklären.

Berichte separat: was implementiert ist, was ausgeführt wurde, was mangels eines Live-Sensors ruht und was noch die Autorität des Benutzers erfordert.