## 30.10.2026 · E305/P348 · C218/1.3.118 · R201/3.4.201 Online-Verwaltung: aktive Primary-Belegungsgrenzen64..reserviert (kein Remapping), L/O-Budgets, gezielter Cacheklassenreset aller Sites unter Schutz interner Werte, Dienstinstanz/Revision, Persistenz; HTTP↔gRPC-Verwaltung auf demselben Port mit frischem Rücklesen. ABI38/Direct23/Extra8 verlangt passende neue native Artefakte/Workerneustart. Historische Speicherhinweise und Schreibdiagnoselink entfernt; Speicheraufnahme hat echte Fetch-/Body-Zeitgrenzen und Gesamtwächter; CRLF-Schlüsselreader korrigiert, Tabellenlabels gestrafft, irreführender Pflege-Sammelzähler entfernt. Windows-/IIS-/echteWorker-/GET-Latenz-/RAM-Abnahme offen. Poolquoten, Fairness, Outside-Fallback beiÜberlast, großeGC-Uhrsprünge und übrige alteSite-Anzeigezähler bleiben separat offen. Siehe CONTROL_PLANE-Anleitung dieses Pakets mit allen3Konfigurationsorten. Keine Subagenten. ## S7B · Quellpakete für lokalen Windows-Build (29.10.2026) E304/P347, C217/1.3.117 und R200/V3.4.200 sind als zusammenpassende Quellen vorbereitet. Vollständiger OC-source-Workflow:82Stufen bestanden; danach betroffene Versions-/Paketprüfer gezielt erneut geprüft (15Negativ-/Positivfälle, einschließlich Extra8 im Packager). Alle74Resilient-Prüfdateien sind kumulativ bestanden; unveränderte erfolgreiche Fälle wurden wiederverwendet. Die zuvor zehn offenen Fälle sind abgeschlossen. Aktuelle native Snapshot→PHP→UI-Ketten und die tatsächliche UI→Controls→gRPC→C-Owner→Speicherung→frischesRücklesen-Kette bestanden; genau3Speicheraufrufe,40bestätigteWerte nachStopp lesbar. Backendfreie UI-Quellprüfungen benennen erfasste native/PHP-Antworten ausdrücklich als Eingabegrenze; sie ersetzen den separat ausgeführten nativen Verarbeitungstest nicht. Controls-Produktionsquellen sind bytegleich zum bereits geprüften und fürWindowsx64kompilierten S7A-Stand; zusätzlicher gezielter Verarbeitungstest mit tatsächlichem neuem Capture-Einstieg bestanden. Native C++-Bibliothek tatsächlich unterLinux gebaut, keine Linux-Produktportierung. Windows-MSVC-/DLL-/CEL-S-/SCM-/PowerShell5.1-/IIS-Abnahme, realePHP-Worker, GET-Leistung und physischeWindows-RAM-Rückgabe bleiben lokal offen. Erst dortige Build-/Abnahmegates bestehen, dann gemeinsam übernehmen. Bestehende Konfigurationen/Schlüssel/config/data/context bewahren; keine Mischstandabnahme. Die fünf weiter offenen Speicherarbeiten bleiben bestehen: Poolquoten, Fairness, Outside-Fallback beiÜberlast, großeGC-Uhrsprünge und alteSite-Anzeigezähler. Keine dieser Arbeiten wurde durch die Paketfreigabe als erledigt markiert. ## E304/P347 · C217 · R200: native Verwaltung und Releaseabschluss Aktueller Arbeitszweig vom 29.10.2026. Native C/C++-Verwaltung im CEL-S-Prozess, gRPC und HTTP als Auswahl; Shared-GET bleibt direkt. ABI37/Direct22/Extra8 verlangt zusammenpassende DLL/CEL-S und vollständigen Worker-Neustart. Quell-/Versionsgates werden auf diesen Vertrag fortgeschrieben; Windows-/IIS-Abnahme bleibt offen. Bestehende config/data/context und Schlüssel erhalten. Weiterhin offen und nicht still erledigt: Poolquoten und Fairness, Outside-Fallback bei Überlast, große GC-Uhrsprünge, alte Site-Anzeigezähler. Diese Arbeiten folgen separat; keine Linux-Produktportierung oder Duplex-Erweiterung in diesem Releaseabschluss. # Arbeitszweig S3 · noch nicht ausgeliefert ## S3 · flexible Zusatzsegmente und verzögerte Freigabe · Quellstand, nicht ausgeliefert (29.10.2026) Aktueller Stand vor den historischen Abschnitten: Der gemeinsame Systemweg verwaltet jetzt Zusatzanzahl0–16 je fester Klasse (Standard4), Freigabeschwelle0–100% (Standard5%) und Mindestdauer1–10080Minuten (Standard5Minuten). Dies sind drei systemweite Regeln; die zwei Freigabeparameter gelten für jedes Segment einzeln.0% erlaubt nur leere Segmente. Die Datei cel-dynamic-storage.ini bleibt CEL-S zugeordnet, Speichern erfolgt atomar mit Rücklesen. Bestehende Controls-config/data/context erhalten. Alte vollständige Schema1-Regeln werden unter Erhalt ihrer Werte mit den drei neuen Standardwerten eingelesen; keine Mischversionsabnahme beauftragt. Löcher zwischen Zusatzsegmenten beenden die Suche nicht. Jede Wiederverwendung erhält einen neuen Mappingnamen mit Dienst-Epoche und Allokationsgeneration. Das Herabsetzen der Anzahl blendet vorhandene Segmente nicht aus und löscht sie nicht sofort. Erst dauerhaft niedrige Belegung, Freigabevorprüfung und budgetierte Entfernung erlauben die Owner-Freigabe. Geschützte/interne/unbekannte Daten verhindern die Freigabe. Normale Cache-Updates verhindern den Fortschritt nicht; neue geschützte Veröffentlichungen werden unter der bestehenden Klassensperre über einen eigenen privaten Beleg erkannt. Globaler bzw. Klassen-GC-Schalter unterbricht neue Freigaben; eine begonnene Freigabe wird beendet. Beobachtungszeiten beginnen nach Policywechsel konservativ neu.5Minuten sind die Mindestbeobachtung, kein garantierter Fertigstellungstermin. Nutzdaten werden in begrenzten Schritten entfernt (höchstens256Prüfungen/64Entfernungen je Arbeitsschritt, zusätzlich bestehende Klassen- und Zeitbudgets). Owner-Unmap/Close müssen erfolgreich sein; fehlgeschlagene Ressourcen bleiben sichtbar, angerechnet und zur Nacharbeit erhalten. Alte Leseransichten dürfen auslaufen. Ein geschlossener Ownerbezug beweist nicht, dass der letzte Windows-Leser schon geschlossen hat. Kein neuer zentraler Leser-/PID-Katalog und keine harte Gesamt-OS-Quote. Large/Outside bleiben einzelne Werte mit bestehender DEL/Ersetzen/GC-Pflege; kein pauschaler5%-Poolwurf. Deren tatsächlich geschlossene Owner-Speicherblöcke werden getrennt ausgewiesen. Gemeinsame Verwaltung: PolicySchema2/65Felder, ManagementWire3, lokale ProzessleitungVersion2; SM-Struktur4 und gRPC-APIcel.memory.v1 bleiben. Gemeinsames LayoutABI37/Direct22/Extra8 verlangt später passende neue DLL/CEL-S und vollständigen Neustart. Der unveränderte schnelle Shared-HIT bleibt direkt; nur Miss-Suchen berücksichtigen Lücken zuverlässig. Kein gRPC/Duplex in übrigen Extension-Befehlswegen. Im vollständigen portablen x64-Modell wächst die gemeinsame Hauptansicht um78184Byte auf22883160Byte; separate private Owner-Mappingtabelle+9184Byte. Dies umfasst Verwaltungsdaten, keine vorsorglich angelegten Wertsegmente und keine Gesamt-RAM-Zusage. Prüfplan und Ergebnis: tatsächliche native Owner-/Worker-/Schlüssel-/GET-/SET-/DEL-/Scope-/GC-/Freigabe-/Wiederverwendungspfade unter Win32/Zend/IPC/Zeitmodellen (ASan/UBSan, LeakSanitizer aus);25gezielte Fälle bestanden. Tatsächliches UI-JavaScript mit DOM/ASP-Grenzadaptern→Controls→separater Go-Prozess über TCP/HTTP2-gRPC→C-Owner mit Datei-/IPC-Modell bestanden. Alle drei neuen Regeln dauerhaft gespeichert und frisch bestätigt; verlorene Antwort wird nicht als Speichern wiederholt. Vorhandener nativer Scopepfad→tatsächliche PHP-Aggregation geprüft. Beide Windows-Go-Zielkompilierungen bestanden. Kein Browserlayout-, Windows-C/DLL-/SCM-/IIS-/echter PHP-Worker- oder GET-Latenznachweis. Vorbereitet, NICHT ausgeführt: tools/s3_segments_stress.php mit zwei echten PHP-Prozessen, zwei Site-Namensräumen und privatem CEL-S-Kanal. Mehr als vier Zusatzsegmente, mittlere Freigabe, höhere Treffer, Wiederverwendung und frischer Verifikationsprozess; CLI-Quellsyntax geprüft. Läuft erst mit passend neu gebauten ABI37-Artefakten. Beispiel nach lokalem Build: php -d extension=PFAD_ZUR_PASSENDEN_DLL tools/s3_segments_stress.php --limit=8 --minutes=1. Der kürzere private Testwert verändert keine produktive Konfiguration. Fünf Minuten separat mit --minutes=5 prüfen. Profile: php ohne Extension erhält keine neue CEL-S-Pflicht; Plugin-PHP bleibt bytegleich. native ohneCEL-S erhält keine neue Verwaltungsabhängigkeit im eigenen Cachepfad; tatsächliche DLL-Abnahme offen. shared unmittelbar betroffen; portable tatsächliche Quellen geprüft, native Windows-/Mehrprozess-/IIS-/Leistungsabnahme offen. Entfernte Varianten bleiben entfernt. Dies bleibt ein kumulativer Quellcheckpoint auf E303/P346, C216/1.3.116, R199/3.4.199, kein installierbarer Build. Historische Angaben unten sind historische Belege. Alle neuen Versions-/Build-/Paket-/Dokumentations-/Plugin-/ZIP-Gates bleiben vor Produktlieferung Pflicht; kein Gate abgeschaltet. Nächster Abschlussblock: Produktidentitäten und vollständige Paketprüfungen, danach lokale Windows-Abnahme. Zusätzlich offen: Poolquoten/Fairness/Outside-Fallback unter Überlast, große GC-Uhrsprünge und ältere Site-Anzeigefelder. Keine Subagenten, keine E302-Vergleichskampagne. --- # Arbeitszweig S2D · noch nicht ausgeliefert ## S2D · nicht ausgelieferter Speicher-Verwaltungszweig (29.10.2026) CEL-S startet und überwacht optional seinen zum OC gehörenden Verwaltungsprozess. Vorlagen bleiben ausgeschaltet; gRPC/HTTP ausdrücklich auswählbar. Gemeinsame Regeln nur über den getrennten Systemweg, in Resilient zusätzlich mit Authority-Benutzerrecht. Site-Freigabe/Kaltalter und gemeinsame Schwellen/Pausen/Suchgrenzen getrennt. Site-Regler führt Tagesaufnahmen fort, ändert bei cel.shared-gc.v1 keine Schwellen/Pausen. Direkter Shared-GET und übrige Extension-Befehlswege erhalten. Keine neue zentrale Leserregistrierung oder harte Gesamt-OS-Quote. Dies ist ein Quellcheckpoint auf E303/P346, C216, R199, kein neuer Installationsstand. Versions-/Build-/Quellworkflow-/Dokumentations-/Plugin-/ZIP-Gates bleiben vor der späteren Produktlieferung verbindlich. Windows-C/DLL/SCM/IIS und tatsächliche Worker-Latenz noch nicht abgenommen. Nächster Speicherzweig: flexible Zusatzanzahl, lücken- und generationssichere Suche und lazy Freigabe5%/5Min; Poolbegrenzung/Fairness/Outside-Fallback und GC-Uhrkorrektur weiter offen. Keine Subagenten, keine erneute Mischstand-/E302-Kampagne. Bestehende config/data/context bewahren. --- # Aktueller Cache-Stand und Grenzen ## 1.3.116 · 29.10.2026 Authority0.1.5 erhält eine gemeinsame INI, versionierte EXE, native Windows-Dienstverwaltung und einen zusätzlichen gRPC-Zugang zum selben Benutzer-/Sitzungsservice. Controls C216 liefert eine kleine RAM-Projektion seiner tatsächlichen Live- und Registry-Verbindungen. Resilient R199 zeigt sie in Diagnose, mit heller rechter Ergebnisspalte und lokal veraltenden Befunden. HTTP bleibt erhalten; Resilient meldet Benutzer weiterhin über HTTP an. Live L114, Participants1.0.10, OC E303/P346 und Shared-GET bleiben unverändert. ## C215 · 29.10.2026 Controls C215/1.3.115 und Participants1.0.9 verwenden optional einen einzigen bidirektionalen gRPC-Stream. Participants öffnet ihn zu Controls; Anmeldung, signierter Status, Registry-Abruf, Inbox, Annahme, Antwort und die Rückfrage an den Spiegel laufen darüber. Ein Stream ist kein neuer Zustandsbesitzer. HTTP bleibt ausdrücklich auswählbar und ohne neue Optionen Standard. Live L114 mit vorhandenem gRPC-Port19100, OC E303/P346 und Shared-GET bleiben unverändert. R197 aktualisiert nur Dokumentation und Kennung; die Speicheranzeige bleibt geschlossen wie R195. Authority0.1.4 folgt als eigene nächste Etappe. ## C214 · Live gRPC G1 · 28.10.2026 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. ## C213 · Gemeinsame Verträge · 28.10.2026 C213/1.3.113 und Participants1.0.7 verwenden dieselbe kanonische Quelle der sechs Teilnehmer-/Kontextvertragsdateien. Eigenständige Builds prüfen Quelle, Revision, gerenderte Kopien und Buildidentität verpflichtend, ohne Eingaben zu reparieren. Wire-Verträge unverändert. R191 nur Dokumentation/Buildkennung; E302/P345 und GC unverändert. Freiplatzliste folgt nach Abschluss dieses Zweigs. ## C212 · Teilnehmerkoordination C3 · 28.10.2026 C212/1.3.112 löst Teilnehmerkoordination, PollSession und Lifecycle-Nacharbeiten in internal/participants aus. Dasselbe Register und genau ein Coordinator; bisherige HTTP-/Status-/Lease-/Abbruchregeln bleiben erhalten. R190 aktualisiert nur Dokumentation/Buildkennung; E302/P345, C211-Live-Grenze und andere Dienste unverändert. Noch kein gRPC. ## C211 · Controls-Live-Grenze C2 · 28.10.2026 C211/1.3.111 trennt die Live-Bestätigungsregel in internal/observation vom vorhandenen HTTP-Adapter internal/transport/livehttp. Originalbytes/Hash/Read-back, Teilnehmer-/Ereignis-Locks, Cutoff und bisherige Fehlerverträge bleiben erhalten. R189 aktualisiert nur Dokumentation/Buildkennung; E302/P345 und alle anderen Dienste unverändert. Noch kein gRPC. ## C210 · Controls-Module C1 · 28.10.2026 C210/1.3.110 gliedert Controls vor gRPC: echte interne Konfigurations-/Plattformpakete, kleiner Programmeinstieg und thematische Kompatibilitätsdateien. Bestehende Fachabläufe, Zustände und HTTP-Verträge bleiben erhalten. E302/P345 unverändert; R188 synchronisiert ausschließlich Dokumentation und Buildkennung. Windows-Dienst-/IIS-Abnahme lokal erforderlich. Quellpaket E299/P342; native Runtime E298/P341; Resilient R184; Controls C209. Paketbereinigung, keine neue Allokation oder Schlüsselplatzierung. - R-L1, konservativer Large-Modus, Fallback-Off und gesperrter Experimentalpfad sind endgültig entfernt. - Shared-GET hat Vorrang. Produktiver Direct-GET, Wertbehandlung und Large-/Outside-Allokatoren bleiben bytegleich E298. - Freireserve: sieben Primary-Klassen, Low16/High64, Tokens mit Slot/Seq/Generation; bestehender Klassenlock für PHP-Worker und GC. Rückgabe erst nach Löschung und Large-Retire. CEL-S: eine Klasse/100ms, höchstens64 Tokens und256 Slots, 5s Pause nach vollständiger Suchrunde. Testarena-Reserve inaktiv. - 7.960Byte Primary plus7.960Byte inaktive Testarena, zusammen15.920Byte Zusatzmetadaten aus portablem C-sizeof; MSVC-Nachweis bleibt lokal. - Reserve ist passiv: natürlicher Suchbereich bleibt. Sie reduziert für sich allein keine Zusatzsegmente. „Geprüft frei“ ist eine Momentaufnahme, keine Reservierung und keine globale Kapazitätsgarantie. - Probefenster: Standard64, konfigurierbar1..1024, Übernahme erst bei neuer Mapping-Generation nach koordiniertem Neustart. Nicht mit Reservegröße64 verwechseln. - Native ABI33/Direct20/Large5/Extension7; SM-Schema4/History3. E299 erzeugt weiterhin native E298-EXEs .3.3.298.exe. Keine .299-Neustartpfade erfinden. - GC-v4: Large50%, Outside75%, Pflege60min, Druck5min mit Backoff. Bestehendes Legacy0 nur ausdrücklich umstellen. Nullsteller sind Anzeige-Basislinien; kein Löschen produktiver Cachewerte. - Large-Verweise zählen zu ihrer physischen Direct-Klasse (produktiver Writer: Primary-Pico). Nutzbar, physisch belegt, referenziert, retired/gehalten und öffnungsfähig getrennt ausweisen. Waisen oder fehlerhafte Freigabe sind keine nachgewiesene Ursache. - Outside-Blobs/Large-Payloads sind einzeln verwaltet; ihre heutigen Allocator-, Reader-Pin- und Retire-Verfahren bleiben. Kein neues Outside-/Extension-Reservoir und keine Waisen-GC. - R177-Korrektur bleibt: historisch beendeter Neustartfehler blockiert keinen neuen Aufnahmeversuch; ein aktuell beobachteter Neustart muss abgeschlossen sein. Warnung bedeutet keinen nachgewiesenen Erfolg. - Nutzerbild image(20261024-230047).png bestätigt E297-Neustart und64/64, keine Windows-Abnahme von E298 oder E299. - Native Windows-/IIS-/Mehr-PHP-Worker-/GET-Latenzabnahme bleibt ausdrücklich offen. Quell- und Portabilitätsnachweise stehen ausschließlich im aktuellen VERIFICATION.json. Nächster separater Runtime-Baustein: autoritative Schlüsselzuordnung und Primary-Spill. GET muss jeden gespeicherten Schlüssel finden. Atomare Veröffentlichung, Generation/Seq, Wiederbelegung, Klassenwechsel, parallele SET/GET/DEL/GC und Flush zuerst in der Testarena prüfen. Erst danach beliebige freie Slots produktiv nutzen. TCP, Linux, Android und Controls-Logrotation sind eigene Vorhaben. Die vollständigen früheren Analysen, Zwischenberichte und Nutzerbelege bleiben in den unveränderten früheren Paketen E298/R178/C203 sowie den extern gesicherten Projektberichten erhalten. Sie werden nicht als aktuelle Abnahme wiederholt. ## Berichtsanzeige C206/R181 C206/R181: einzelner Live-Read für Details, kleine ausdrücklich markierte Report-Projektion mit erhaltener Laufzeitdiagnose und Originalhash, frühe authentifizierte Berichtsausgabe und navigationsfester Aktualisierungstimer. OC E299/P342, native E298/P341 sowie GC und Freireserve unverändert. ## C207/R182: JSON-Format im Reporttest C207/R182 korrigiert den C206-HTTP-/Live-/Reporttest: JSON-Einrückung wird beim Vergleich entfernt, Daten und Zahlentoken bleiben exakt geprüft. Einzel-Live-Read, kleine Reportprojektion und R181-Anzeigelogik bleiben erhalten. OC E299/P342, native E298/P341 sowie GC und Freireserve unverändert. ## C208/R183: Speicher-Leseweg C208/R183: Speicheransicht ohne globalen Providerabruf; kleiner geschützter Aufnahme-POST und skalare Live-Bestätigung statt vollständiger POST-Seite. Gespeicherte Aufnahme bleibt datiert sichtbar, neue Aufnahme wird über Quellkennung und Live-Epoche bestätigt; ein abschließender Seitenabruf bleibt. Authentifiziertes Gerüst früh ausgeben. OC E299/P342, native E298/P341 sowie GC und Freireserve unverändert. ## C209/R184: Speicher-Seitenabruf C209/R184: Speicher-Seitenabruf mit kleinem Metadatenkopf und getrenntem, unverändertem Speicherblock. ASP durchsucht nur den kleinen Kopf; vorhandene JavaScript-Anzeigen lesen storage.memory. Neue Teilzeiten für Rahmen, Rendering und Ausgabe. Status-Bestätigung und geschützter Aufnahme-POST bleiben erhalten. OC E299/P342, native E298/P341 sowie GC und Freireserve unverändert.