Interne Protokolle · 0.1.0
Grenzen interner Dienste
Scanner-, Updater- und Advisor-Connector-Protokolle sind getrennt von der Control-API dokumentiert.
Die API-Referenz ist auf Englisch.
Diese Protokolle verbinden Komponenten innerhalb der Arbeitsumgebung. Es sind Implementierungsschnittstellen, keine unterstützten Integrationsendpunkte für Dritte. Verwende die Control-API mit unterstützter Clientberechtigung für Anwendungsabläufe.
Gib jedem Dienst eine enge Verantwortung
Koordinator
- Jobworker
Verwaltet die dauerhafte Control-Operation und genaue Dienstbindungen.
Getrennte Protokolle
- Scannerprotokoll
Begrenzte Läufe, seitenweise Befunde und ausdrückliche Ergebnisbestätigung.
- Updaterprotokoll
Vorbereitung und Abgleich geprüfter Komponenten ohne Projektquellzugriff.
- Advisor-Connector-Protokoll
Anbieterarbeit gebunden an genaue Freigaben, Ziele und Abbruchzustand.
Verbindungen
Jobworker zu Scannerprotokoll
Sammle und speichere das genaue Laufergebnis vor Bestätigung der Bereinigung.
Jobworker zu Updaterprotokoll
Verfolge Operationsidentität und Anfragedigest durch Vorbereitung und Wiederherstellung.
Jobworker zu Advisor-Connector-Protokoll
Erteile nur die Anbieterberechtigung für die vorgesehene Advisor-Anfrage.
| Dienst | Aufrufer und Ressourcen | Protokollverantwortung |
|---|---|---|
| Scanner | Worker; autorisierte Quellen, Momentaufnahmen und validierter Cache schreibgeschützt | Laufzulassung, Zustand, begrenzte Befunde, genaue Ergebnisbestätigung und Abbruch. |
| Scannerdaten-Updater | Control-API/Worker; beschreibbarer Cache und geprüfter Downloadverkehr | Dauerhafte Vorbereitung und Veröffentlichung vollständiger Cache-Generationen ohne Projektquellzugriff. |
| Advisor-Connector | Worker; eigene Anbieterautorisierung und genehmigte Netzwerkrouten | Eng erlaubte Anbietertests, Generierung, Beobachtung und Abbruch. |
Der Kern veröffentlicht nur sein Loopback-Eingangsrelay. Diese Dienste sind keine öffentlichen Website-Endpunkte. Scannerinternes Netzwerk, Updater-Ausgang und Advisor-Ausgang sind in Compose getrennt. Mount- und Netzwerkdeklarationen müssen in eingesetzten Images und Containern geprüft werden, bevor sie als beobachtete Isolation gelten.
Laufzeitscanner
Der Worker startet mit POST /runs einen stabilen Lauf, beobachtet dessen Zustand und liest Ergebnisse über begrenzte Befundseiten. Laufidentität und Anfragedigest verhindern den Austausch eines Befehls unter einem bestehenden Lauf. Das versiegelte Manifest ergänzt Ergebnisdigest, Zahlen, Streamidentität, Übersicht und Artefaktdeklarationen.
Seitencursor binden genauen Lauf, Anfrage, Ergebnis und Fortsetzungsposition. Der Worker validiert den gesamten Stream vor Datenbankveröffentlichung. POST /runs/{run_id}/result/ack gibt das genaue temporäre Ergebnis nach dauerhafter Speicherung frei. Abbruch und Bereinigung über DELETE /runs/{run_id} müssen passende Anfrage-/Ergebnisbindung erhalten; es sind keine beliebigen Dateilöschbefehle.
Laufregister und Wiederherstellungsspool sind prozesslokal und zeitlich begrenzt. Scannerneustart erhält den Spool nicht als dauerhaften Nachweis. Auch seine Health-Antwort belegt keine Bereitschaft ausgewählter Binärdateien, Regeln und Datenbanken. Lies Scannerrouten, Laufsteuerung und Commit vor ACK.
Updater ohne Quellzugriff
Der Updater erhält dauerhafte Operationen gebunden an Operations-UUID und Anfragedigest. Sein Executor stellt Operationszustand wieder her und verwaltet begrenzte aktive und wartende Arbeit. Handler bestimmen geprüfte Komponenten, stellen private Kandidatendaten bereit, validieren und versiegeln sie und veröffentlichen eine vollständige Generation. Beliebige Repository-Pfade, Download-URLs oder Shellbefehle ersetzen den geprüften Katalog nicht.
Die private HTTP-Grenze verlangt einen erlaubten Host und lehnt Forwarded-Host-/Protokollheader ab. Das ist eine zusätzliche Anfragegrenze, kein Grund für öffentliche Erreichbarkeit. Der Updater hat keinen Projektquellmount; der Scanner nutzt den validierten Cache schreibgeschützt.
Aktivierung und Abbruch haben verschiedene Ergebnisse. Sobald Veröffentlichung die geschützte Commitphase erreicht, darf Abbruch sie nicht unterbrechen oder die Auswahl zurückrollen. Rollback ist eine separat validierte Operation und verlangt weiterhin kompatible frische Vorgängerdaten. Siehe Updaterstart und Anfragegrenze, Operationsrouten und Vorbereitungsarchitektur.
Advisor-Connector
Lokale und entfernte Advisor-Arbeit laufen beide über den Connector. Der Worker reserviert eine begrenzte Operation oder lässt sie zu, legt die erforderliche Ausführungsfreigabe vor und fordert Generierung an. Der Connector prüft autorisierte Anbieterroute und Modell und validiert die Antwort. Er besitzt eigenes Autorisierungsmaterial und keinen Projektquellmount; der Worker liefert das zugelassene Befundpaket.
Entfernte Generierung verlangt den getrennt bestätigten Einzelbefundweg. Bestätigung bindet Anbieterkonfiguration, Autorisierung, Transport, Ziel, Modellidentität, Befundrevision und Prompthash. Automatische und scanweite Anbieterauswahl bleibt lokal. Entfernter Transport unterstützt geprüfte direkte oder SSH-Ollama-Routen, keine beliebigen Modellanbieter.
Operationszulassung, Beobachtung und Abbruch sind ausdrückliche Endpunkte. Abbruch kann weitere Arbeit stoppen, bereits versandte Inhalte jedoch nicht zurückholen. Der Worker validiert Rat erneut und verwirft ihn bei zwischenzeitlicher Befundänderung. Er ändert Lebenszyklus oder Gate-Richtlinie nicht automatisch.
Siehe Connectoroperationen und Generierungshandler, Workerintegration und Offenlegungsbindung.
Lies Protokoll und Implementierung zusammen
Die interne Referenz beschreibt Deklarationen ihres ausdrücklich benannten API-Snapshots. Einige Handler lesen und validieren Anfrage-JSON direkt. Ein automatisch erzeugtes breites Schema erfasst deshalb nicht jeden erlaubten Schlüssel, jede Operationsbindung oder Autorisierungsbedingung. Lies bei Protokolländerungen Handler und Aufrufer zusammen.
Schemadeklarationen beweisen weder Start, Erreichbarkeit, Anbieterautorisierung, Wiederherstellungsverhalten noch Integrationsunterstützung. Protokolländerungen benötigen abgestimmte Aufrufer-/Dienstvalidierung und Tests von Ablehnungs- und Wiederherstellungswegen. Öffentliche Integrationen sollten nicht von stabilen internen Endpunkten abhängen.