Installation L114 / 1.0.14 – Live gRPC G1

Controls C214 und Live L114 ergänzen den ausdrücklich wählbaren gRPC-Weg. HTTP und gRPC benutzen denselben Live-Speicher. Originale Beobachtungsbytes und getrennte Hash-/Epoch-/Revisionsbestätigung bleiben erhalten. Participants1.0.8, Authority0.1.4 und OC E303/P346 bleiben unverändert; kein RPC im Shared-GET. R196 synchronisiert nur Dokumentation und Buildkennung. Bestehende INI-Dateien bleiben erhalten; ohne neue Optionen weiterhin HTTP.

Einmaliger lokaler Pilot: beide Pakete frisch entpacken, bestehende Konfigurationen übernehmen und Go1.27.3 verwenden. Die vorbereitete Windows-SDK liegt bereits im privaten Werkzeugordner, z.B. C:\Services\CEL_gRPC_Tools_20261028_221025\windows-sdk\go\bin. Diesen Pfad nur für das verwendete Build-Terminal voranstellen, dann go version kontrollieren. Kein SDK oder Downloadbestand gehört in die Produktpakete. Vorhandene build_all.bat-Einstiege samt Versions-/Vertrags-/Test-/Vet-Gates benutzen; Vendor erlaubt den Quellenbau ohne erneuten Moduldownload. Go selbst muss vorhanden sein.

Live: im bestehenden config\live.ini den neuen Abschnitt ergänzen:
[grpc]
enabled=true
bind=127.0.0.1:19094

Controls: im vorhandenen Abschnitt [live_state] von config\controls.ini die zwei neuen Schlüssel ergänzen (die bisherigen Werte url/job_id/topic/timeout_ms erhalten):
transport=grpc
grpc_target=127.0.0.1:19094

Port19094 ist ein konfigurierbares Beispiel, keine Behauptung lokaler Verfügbarkeit. Beide Enden müssen denselben freien numerischen Loopback-Port verwenden. Kein Listener auf0.0.0.0 und kein externer Zugriff im ersten Piloten.

Nach erfolgreichen lokalen Builds Controls/Live über bestehende Stop-/Install-/Startwege vollständig wechseln: Live zuerst starten, dann Controls. Zielprogramme bin\cel_live_1.0.14.exe und bin\cel_controls_1.3.114.exe. Dienstnamen, Konten, /config, data/ und eigene context/-Bestände erhalten. Kein CEL-S-/PHP-/OC-/Participants-/Authority-Neustart nur wegen dieser Transportetappe. Live beginnt wie bisher mit leerer neuer Epoch; Teilnehmerverbindungen entstehen nach Controls-Neustart nur durch neue Anmeldung, keine Wiederherstellung alter Verbindungen aus dem Mirror.

Tatsächlichen gRPC-Zugang read-only aus dem Controls-Quellroot prüfen:
go run ./tools/live_rpc_health -target 127.0.0.1:19094

Erwartet result=OK, transport=grpc, LiveV1.0.14/LIVE_GRPC_G1 und korrekte Jobidentität. Das ist Erreichbarkeit/Identität, noch keine bestätigte Observation. Danach einen frischen vollständigen Site-Abruf auslösen und dessen bestätigten Stand ansehen. Passende vorhandene Health-/Verify-Einstiege zusätzlich erhalten. Für die echte private Gesamt-Prozessprüfung gibt es tests/manual/g1_process_chain.py (optionalPython3, kein Runtime-Erfordernis). Sie benötigt die aktuellen beiden EXEs und den separat aus tools/g1_proxy gebauten privaten Testproxy; eigene Ports/temporäre Daten, keine produktiven Sites oder Dienste. Genaue Aufrufe unten.

Rückweg: Controls transport=http setzen, vorhandene url erhalten und Controls neu starten; Live gRPC bei Bedarf über enabled=false und Live-Neustart abschalten. Kein automatischer Fallback nach unklarem Schreiberfolg. Die derzeitige Abnahme verlangt den passenden aktuellen Gesamtstand, keine Mischstandmatrix.

Prüfbericht VERIFICATION.json ist aktuell. Portable echte Prozesse, gezielte Races und Windows-Zielcompiles sind kein tatsächlicher Windows-Dienst-/IIS-Nachweis. Auf dem Server nach lokaler Abnahme laufen lassen und längere Beobachtung bei Bedarf prüfen. Native PHP-/DLL-/CEL-S-/GET-Leistung wurde hierdurch nicht neu abgenommen. E302-Vergleich ausdrücklich entfallen.


RPC-Vertrag und Generierung:
Kanonisch Controls contracts/live-rpc/source/cel/live/v1/observation.proto; Live enthält die gepinnte Offlinekopie contracts/live-rpc/cel/live/v1/observation.proto. Wire-Paket cel.live.v1, Quellrevision CEL_LIVE_RPC_SOURCE_1; Komponentenstände und bestehende JSON-Verträge sind eigene Versionen. Protoc36.2, protoc-gen-go1.36.12, protoc-gen-go-grpc1.6.2; Runtimegrpc-go1.85.0/protobuf-go1.36.12, geprüftGo1.27.3. Erzeugte Dateien internal/transport/livegrpc/pb/*.pb.go nicht bearbeiten. Normale Builds prüfen LOCK, Schema, erzeugte Bytes, go.mod/go.sum und Vendorinventar read-only; kein Nachgenerieren oder Reparieren. Teilnehmer-Vertragsquellen/Lock bleiben unverändert.

Explizite Entwicklergenerierung aus dem jeweiligen Root mit installierten gepinnten Generatoren (X steht für cel_controls oder cel_live; S für contracts/live-rpc/source oder contracts/live-rpc):
protoc -I S --go_out=. --go_opt=module=X --go_opt="Mcel/live/v1/observation.proto=X/internal/transport/livegrpc/pb;livev1" --go-grpc_out=. --go-grpc_opt=module=X --go-grpc_opt="Mcel/live/v1/observation.proto=X/internal/transport/livegrpc/pb;livev1" cel/live/v1/observation.proto

Nur nach absichtlicher Vertrags-/Tool-/Abhängigkeitsänderung: beide Kopien ausdrücklich generieren, neue Quellrevision und Lock/Pin/Abhängigkeitshashes bewusst aktualisieren und prüfen. Keine generelle Regeneration im Build. Vendor-Quellen wurden aus Go-geprüften Modulen erzeugt; vollständige Quellen/Lizenzen und VENDOR_SHA256SUMS werden pro Komponente mitgeliefert, der SDK/Moduldownloadcache nicht.

Private optionale Windows-Prozessprüfung aus Controls nach beiden lokalen Builds (Python3 benötigt, kein Produktbetrieb):
go build -trimpath -o logs\g1_proxy.exe ./tools/g1_proxy
python tests\manual\g1_process_chain.py --source . --controls bin\cel_controls_1.3.114.exe --live ..\cel_live\bin\cel_live_1.0.14.exe --proxy logs\g1_proxy.exe --output logs\g1_acceptance
Mit --benchmark nur dieselben beiden aktuellen Binaries/direkte Endpunkte vergleichen: je3Warmups+20bestätigte Vollabrufe, identischeObservation, p50/p95/p99. Kein Shared-GET-/WordPress-/SLO-Test. Keine produktiven Dienste stoppen oder Cache füllen; Quellen und existierende Konfiguration werden nicht geändert. Bei erneutem Lauf anderen output-Ordner für erhaltene Belege wählen. Der Testspeicher ist nach Beendigung entfernt; Ergebnis/Protokolle stehen ausschließlich unter output. Kein Testproxy im normalen Dienstbetrieb.