ONLINE CONTROL PLANE E305/P348 / C218 / R201 (30.10.2026)
Zuerst CONTROL_PLANE_E305.md lesen: alle3 Konfigurationsorte, Installation, Online-Grenzen und Prüfgrenzen.

CEL OC E304 / Plugin P347 – lokale Build- und Übernahmevorbereitung

E304/P347: gemeinsame GC-Regeln und flexible Zusatzsegmente (0–16, Standard4; Freigabe5%/5Minuten), native Verwaltung im CEL-S-Prozess mit gRPC oder HTTP. ABI38/Direct23/Extra8 verlangt passende DLL/CEL-S und vollständigen Neustart. Konfiguration, Schlüssel und config/data/context erhalten. Windows-/IIS-Abnahme noch offen.

1. Vollständige Quellen nach cel_wp_object_cache entpacken. Die Quellpakete enthalten keine fertig gebauten Windows-DLLs/EXEs. Auf dem Entwicklungsrechner vorhandenes Windows-PHP8.3-x64-NTS-/Visual-Studio2022-Umfeld verwenden.
2. Native Werkzeuge N2 separat vorhalten: CEL_gRPC_Native_20261029_181908.zip. In derselben PowerShell-Konsole CEL_GRPC_NATIVE_TOOLS_ZIP und CEL_GRPC_NATIVE_SDK_ROOT wie management/native/BUILD_NATIVE.md setzen. Das SDK/Compiler gehören nicht in die Serverauslieferung.
3. build_all.bat ausführen. Keine Pflichtgates überspringen. Native Verwaltung wird über build_management.bat gebaut; gRPC/HTTP teilen dieselbe Vierplatzqueue und denselben CEL-S-Owner.
4. Erwartete neue Ergebnisse: bin/cel_short_memory_service_3.3.305.exe, die beiden passenden Probes, bin/cel_sm_management_3.3.305.dll, bin/cel_management_key_3.3.305.exe, bin/cel_management_verify_3.3.305.exe sowie die PHP-DLL-Varianten unter extension/celphpninja/build. Der Buildbeleg erfasst auch die drei Verwaltungsartefakte. Der lokale Gesamtbuild erzeugt nach seinen Abnahmen P348.zip.
5. Vorhandene Konfigurationsdateien und Schlüssel NICHT durch Vorlagen ersetzen. config/cel-s-management.ini bleibt optional, Vorlagen ausgeschaltet. Transport grpc oder http über numerisches Loopback. Schlüsselhilfe erstellt ausschließlich fehlende Schlüssel. Gemeinsame Regeln gehören zu CEL-S; Site-Freigabe/Kaltalter bleiben getrennt.
6. Controls C217 lokal bauen, Ziel bin/cel_controls_1.3.117.exe. Bestehende Live-/Participants-/Authority-Ziele und Startargumente erhalten. Gemeinsamen Systemschlüssel über den vorhandenen Konfigurationsweg eintragen; kein Site-Schlüssel als Systemberechtigung.
7. Nach lokalem Build-PASS passenden DLL/CEL-S-Verbund, Verwaltungsbibliothek, P347/Drop-in und Resilient R200 gemeinsam übernehmen. Dienstdefinition auf die neue EXE aktualisieren. Alte PHP-Worker beenden und vollständigen Neustart gemäß bestehendem Ablauf durchführen. Bestehende memory-restart.json-Ziele auf die tatsächlich übernommenen EXE/Probe-Pfade prüfen; übrige Ziele/Pools/Argumente erhalten.
8. Danach native Identitäten, gRPC und HTTP getrennt, berechtigtes Lesen/Speichern/frisches Rücklesen und verlorene Speicherantwort ohne blinde Wiederholung prüfen. Reale PHP-Worker und tools/s3_segments_stress.php verwenden; --minutes=1 ist nur ein privater Kurztest, --minutes=5 prüft den Standard separat. GET-Latenz und physische RAM-Rückgabe sind hier nicht gemessen.

Profile: PHP ohne eigene Extension erhält keine neue Verwaltungspflicht; native ohne CEL-S benötigt diese Bibliothek nicht für seinen Cachepfad. Shared ist unmittelbar betroffen. Portable Quellen-/Modellprüfungen sind kein Windows-/IIS-Laufzeitnachweis.

Weiter offen: Poolquoten/Fairness, Outside-Fallback bei Überlast, große GC-Uhrsprünge und alte Site-Anzeigezähler. Kein Duplex, keine Linux-Produktportierung in diesem Abschluss.