## E305/P348 · R201 · Buildfix2: native Test-Vorläufe (30.10.2026) Windows101_tests_e303_native_acceptance.php.log: aktiver Freiplatzlistentest scheitert bereits vor seinem privatenCEL-S-Start. Die Meldung fordertABI38, aber tools/p4_stress.php prüfte noch numerisch37. Auch tools/s3_segments_stress.php enthielt diese veraltete Prüfung und einen fest auf37 gesetzten Berichtswert. Produktnative bleibt ABI38/Direct23/Extra8. Beide Testwerkzeuge lesen Buildidentität aus config/version.ini und ABI/Direct aus include/cel_dx_transport.h. Strikte Ganzzahl-/Versionsprüfung gilt im Hauptprozess und in Worker/Verifikation. Berichte enthalten den tatsächlich geprüften Stand. Neue Pflicht-Quellprüfung führt die gelieferten Hauptprozess-Vorläufe und Kinder-Identitätsfunktionen aus;43Fälle mit passenden/alten/fehlenden/falschtypisierten Vertragsdaten, altem Laufkontext und künftiger Headeränderung. Native Statusmeldungen/Artefaktanwesenheit sind ausdrücklich Testgrenzen; kein Windows-Cachelauf wird simuliert. Vollständiger anschließender P4-Workload separat mit exakt160gelieferten Schlüsseln durch tatsächlicheC-Pfade/ASan/UBSan erneut geprüft:96Kollisionen/32Spill,2TTL-Freigaben/30Spill/94lebendeGETs,2000Worker-Schreib-/Lese-/Löschfolgen überalle8Wertgrößen,160Abschlusswerte,72Micro/64Pico/8Spill/0Large. Diese portablenWorkerpläne sind seriell; echte paralleleWindows-PHP-Prozesse bleiben lokal zu prüfen. Fixture, GC-Budgets, Wartefristen und Folgeassertionen bleiben erhalten. Produkt-C/C++/Header/Plugin-PHP-JS-CSS/Go/SDK unverändert; C218 unverändert. Quellen vollständig getrennt in E305_Buildfix2.zip/P348_Buildfix2.zip/R201_Buildfix2.zip. Abschlussmetadaten zuerst, dann Dokumentationshashes/Lesekopien/Plugin-Baumhash/Prüfsummen. Vollständiger Quellworkflow aus dem fertig gepackten ZIP ist vor Lieferung Pflicht. Keine weiteren SDK-Vorbereitungen. Wegen geänderter Testquellen gilt der alte Buildbeleg nicht mehr; normalen build_all.bat erneut ausführen, bestehende Konfigurationen/Schlüssel/config/data/context und SDK-Buildbaum erhalten. Echte verbleibendeWindows-/IIS-/Last-/RAM-Abnahme und offene Speicherarbeiten bleiben offen. Keine Subagenten. ## E305/P348 · R201 · Buildfix1: Dokumentationshashes (30.10.2026) Der ausgelieferte E305-Quelltest scheiterte an source_hash_mismatch:build/release_layout.json. Ursache: Abschlussmetadaten wurden nach dem Quellworkflow geändert; Quellhash und abgeleitete Lesekopien wurden nicht danach erneuert. Der Prüfer bleibt unverändert und strikt. Buildfix1 aktualisiert Dokumentationshashes/Lesekopien nach den endgültigen Metadaten und prüft den vollständigen Quellworkflow aus dem fertig gepackten ZIP. Die frühere Aussage zu bestandenen83Quellstufen bezog sich auf den Arbeitsbaum vor dieser Abschlussänderung, nicht auf ein bestandenes ausgeliefertes ZIP. Produktcode, Produktversionen, native Verträge ABI38/Direct23/Extra8, Tests und SDK unverändert. C218 bleibt unverändert. E305-, P348- und R201-Pakete jeweils vollständig getrennt. Bestehende Konfigurationen/Schlüssel/config/data/context erhalten; vorhandenen SDK-Buildbaum weiterverwenden. Windows-MSVC/SCM/IIS/echteWorker/GET-Latenz/RAM und alle weiter offenen Speicherarbeiten bleiben offen. ## 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. ## S6 · native Verwaltung im CEL-S-Prozess · Quellcheckpoint (29.10.2026) Aktuell maßgeblich: Der bisherige separate Verwaltungsprozess und die Go-DLL-Versuchslinie sind im neuen OC-Arbeitszweig durch eine native C/C++-Bibliothek im CEL-S-Prozess ersetzt. gRPC und HTTP bleiben auswählbar; Vorlagen bleiben ausgeschaltet. Der Verwaltungsaufruf erreicht dieselbe begrenzte Vierplatzqueue und den alleinigen C-Owner. Lesen, Speichern und frisches Rücklesen benutzen weiterhin cel.memory.v1, ManagementWire3, Policy2/65Felder; die private native C-API ist jetzt2 und verlangt passende Buildidentität sowie SDK-Runtime58. Schneller Shared-GET und übrige Extension-Befehlswege behalten ihren direkten Pfad. Kein Duplex und keine zusätzliche GET-Verwaltung. Native Quellen aus dem unveränderten N2-Werkzeugpaket: gRPC1.85.0/Core58.0.0, ProtobufC++7.35.1 mit eigenem protoc35.1, CivetWeb1.16 mit drei exakt gehashten Upstreamkorrekturen und nlohmann/json3.11.3 als strikter JSON-SAX-Vorlauf. SDK liegt außerhalb des Produktpakets. Kein Go/cgo/MinGW im nativen OC-Build. Bestehende INIs, Schlüssel und Controls-config/data/context bewahren. backend.probe_executable wird als bisheriger Konfigurationsschlüssel akzeptiert, aber nicht ausgeführt. Prüfung: zwölf gezielte echte HTTP-/gRPC-Transportfälle mit tatsächlichem C++-Transport, C-Owner, Datei-/Win32-/Zend-Grenzmodellen; inklusive tatsächlichem Resilient-JavaScript über DOM-/ASP-Adapter und Controls. Lesen/Speichern/Rücklesen, ungültige Eingaben, ausbleibende Speicherantwort ohne Wiederholung, Dateifehler, Ablauf eines wartenden Auftrags, wartender Stopp und verzögerter Callback bestanden. Unvollständiger Stopp hält Queue/Modul und verweigert Neustart bis zum abgeschlossenen Nachlauf. ASan/UBSan für eigene Fassade, CivetWeb und C-Modelle; unverändertes SDK nicht instrumentiert, LeakSanitizer aus. Loader-Modell, native Schlüsselhilfe einschließlich Nichtüberschreiben/Unicode/BOM und tatsächliche DLL-ABI-/Build-/Runtimeprüfung auf Linux bestanden. Windows-PowerShell-Einstieg mit echtem Parser geprüft, exakte CMake-TAR-Auswahl mit4958Dateien verifiziert. Das ist keine Windowsausführung. Dies ist weiterhin kein Installationsbuild. Native Windows-C/DLL/SCM, PowerShell5.1-Ausführung, IIS, echte PHP-Worker sowie GET-Latenz und Windows-RAM-Rückgabe NICHT ausgeführt. Vor Produktlieferung: neue konsistente E/P/R-Identitäten, vollständige Pflichtgates und separate vollständige Komponenten-/Plugin-ZIPs. Bereits ausgelieferte E303/P346, C216/1.3.116 und R199/3.4.199 bleiben unverändert. Historische S2D-/S4-Aussagen zu Go-/Prozessverwaltung beschreiben verworfene Zwischenstände. Weitere Speicherarbeiten: Poolquoten/Fairness/Outside-Fallback unter Überlast, große GC-Uhrsprünge und alte Site-Zähler. Keine E302-Vergleichskampagne, keine Subagenten. --- # 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. --- # 28.10.2026 – E302/P345/R187 ## V3.4.199 · 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. ## R198 · 29.10.2026 Participants 1.0.10 erhält eine gemeinsame config/participants.ini für Windows-Dienst und Konsole sowie die native Dienstverwaltung CELParticipants. Die Startskripte enthalten keine eigenen Port- oder Transportvorgaben mehr. HTTP und der bestehende bidirektionale gRPC-Stream bleiben auswählbar; C215 und L114 bleiben unverändert. R198 aktualisiert Dokumentation und Kennung, die Speicheranzeige bleibt unverändert. OC E303/P346, Shared-GET, Authority und andere Produkte sind nicht betroffen. ## R197 · 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. ## R196 · Live-gRPC-Dokumentation · 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. SpeicheranzeigeR195 unverändert, bis langer Lauf neue Betrachtung erfordert. ## R195 · verständliche Speicheranzeige · 28.10.2026 R195 strafft die Speicheranzeige: nutzbare Werte, Wertgröße und Site-Anteil an der gemeinsamen Kapazität zuerst; Aufräumregeln, Verweise und Schreibzähler aufklappbar. Nulltabellen werden zusammengefasst, fehlende Angaben bleiben unbekannt. GC-Regeln, Nullsteller und schneller Leseweg bleiben erhalten. E303/P346 und alle Dienste unverändert. Der Benutzer verzichtet auf den E302-Vergleich; die beobachtete Geschwindigkeit ist betrieblich akzeptiert, kein numerischer Benchmark. Paketierung: veraltete doppelte Status-/Prüfberichte entfallen; aktuelle Prüfung in VERIFICATION.json. Inhaltskontrolle ohne Logs, temporäre Ausgaben oder überholte Ergebnisse gehört zum Build-Plan. ## R194 · Primary-Freiplatzliste · 28.10.2026 E303/P346 aktiviert die Primary-Freireserve für Micro bis Medium. Ein nicht verdrängbares Schlüsselverzeichnis macht Plätze außerhalb des natürlichen Suchfensters auffindbar. CEL-S erstellt neue Zuordnungen; direkte PHP-Worker bearbeiten vorhandene Werte koordiniert. ABI36/Direct21 verlangt passende DLL/CEL-S und einen vollständigen Neustart. Large-/Outside-GC-Standards und gespeicherte Regeln bleiben erhalten. R194 aktualisiert die Dokumentation; Controls C213, Live L113, Participants1.0.8 und Authority0.1.4 bleiben. P.4 aktiviert die Freiplatzreserve der festen Primary-Klassen. Der normale Suchweg bleibt zuerst dran. Nach dessen Miss sucht GET zusätzlich im nicht verdrängbaren Primary-Verzeichnis. Nur CEL-S erzeugt neue Zuordnungen; direkte Worker nutzen den gemeinsamen Schreibkoordinator für vorhandene Werte. DEL, GC, Klassenwechsel, Fehlerversuche und Flush geben Zuordnung und Platz kontrolliert zurück. Grenzen:1024Routenzellen×32Byte=32768Byte plus48Byte Deskriptoren, im portablen vollständigen Layout einschließlich Ausrichtung32832Byte zusätzlich jeCEL-S. Keine Kopie jeWorker, keine Schlüsselduplikate und kein vergrößerter Wertplatz. Füllstand des Verzeichnisses ist keine physische Klassenbelegung. Ist der begrenzte Suchzug/das Verzeichnis voll, bleibt der natürliche Zusatz-/Ablehnungsweg erhalten. Leere Freiliste beweist keine volle Klasse. Owner-Demand-Refill sucht maximal einmal die tatsächliche Klasse unter deren bestehender Sperre und stoppt beiHigh64; Hintergrundpflege bleibt budgetiert256. Dieser seltene Schreibweg ist lokal auch auf Latenz zu prüfen. Keine garantierte100%-Kapazitätsnutzung oder allwissende Waisen-GC. Die konfigurierbare64 des natürlichen Probefensters bleibt getrennt von Low16/High64 der Reserve. Bestehende Einstellungen erhalten; aktive Suchgrenzen nur durch abgestimmten Neustart wechseln. Large-Werte bleiben separat gemappt; ihr auffindbarer Handle kann im physischen Pico liegen. Outside und seine direkte API bleiben eigenständig. GC-v4-Standards Large50%/Outside75%, Pflege60min/Druck5min sowie gespeicherte eigene Regeln erhalten. R-L1 und entfernte Varianten bleiben entfernt. TCP/gRPC/Linux/Android getrennt. Prüfstand: tatsächliche portable Startup-/Owner-/nativeWorker-/GET-/GC-/Reuse-/Fehlerpfade unterASan/UBSan bestanden, einschließlich siebenKlassen, voll/busy/Writer-Cache-Verdrängung, Large-Retire/Fehler und Parallelität. Der historische GET-Quellguard bleibt mit exakt begrenztem, rückführbarem E303-Delta aktiv; keine alten erwartetenHashes umgeschrieben. Ein unveränderter Trefferpräfix ersetzt keine Leistungsmessung. Vollständige PHP-Quellgates kumulativ bestanden. Tatsächliche E303-Windows-Kompilierung, PHP-Prozesse, IIS und GET-Leistung hier NICHT ausgeführt/gemessen. Profile:php bleibt beim gemeinsamen requestlokalen Minimalreferenzvertrag ohneSharedLocator; nativeohneCEL-S behält seinen separaten Speicher, echte aktuelle Windows-DLL-Prüfung lokal erforderlich; shared ist unmittelbar betroffen, portable echte Quellpfade bestanden, Windows-Mehrprozess-/IIS-/Leistungsabnahme ausstehend. Keine Behauptung fertiger Hosting-Produkte. ## R193 · Strukturgrenzen · 28.10.2026 Participants1.0.8 trennt Mirror und Anmeldung/Lease/Inbox von HTTP. Authority0.1.4 trennt Benutzer-/Sessionregeln von Datei, Audit und HTTP. R193 aktualisiert die Dokumentation und Buildkennung. Controls C213, Live L113, E302/P345 und die Speicheranzeige bleiben unverändert. Damit sind die vorgesehenen inneren Grenzen des Strukturzweigs vorbereitet. Nach lokaler Abnahme folgt die aktive Freiplatzliste mit gezieltem Stressprogramm über echte Mehr-Worker-Zugriffswege. Danach die Speicheranzeige straffen; tatsächliches gRPC als eigener Zweig. ## R192 · Live-Kerngrenze · 28.10.2026 L113/1.0.13 trennt Live-Speicherkern und Anwendungsabläufe vom HTTP-Adapter sowie von Konfiguration und Dienststart. Rohdaten, Hash, Revisionen, Ereignisring und atomarer Reset bleiben erhalten. R192 aktualisiert Dokumentation und Buildkennung. C213/Participants1.0.7, E302/P345 und die Speicheranzeige bleiben unverändert. Zuerst die inneren Grenzen von Participants und Authority abschließen, dann aktive Freiplatzliste mit gezieltem Mehr-Worker-Stressprogramm. Tatsächliches gRPC danach als eigener Zweig. Nach dem Freiplatzlistentest die Speicheranzeige auf nutzbaren Bestand, Kapazität/Belegung und Handlungsbedarf konzentrieren; Details aufklappbar, kurze einfache Hinweise für Administratoren, Operatoren und Entwickler. ## R191 · Vertragsdokumentation · 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. ## R190 · Controls-C3-Dokumentation · 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. ## R189 · Controls-C2-Dokumentation · 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. ## R188 · Controls-Dokumentation · 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. E302/P345 und R187 teilen die physische Suche fester Klassen zwischen unabhängig fälligen Sites. Eigene Schwellen, Cursor, Pausen und Löschquoten bleiben erhalten. Gemeinsame Fälligkeit anhand des globalen Bestands beim Start; begonnene Arbeit läuft auch nach sinkendem Druck bis zur eigenen Quote beziehungsweise Turngrenze. Höchstens 8192 physische Besuche je Turn und unverändert nominal 5 ms, keine Vervielfachung mit der Site-Zahl. Getrennte physische/Site-Zähler und letzter globaler Startbeleg je Klasse. Sekundärer v4-Suchplaner und produktiver GET/SET unverändert. ABI35; passende DLL/CEL-S gemeinsam wechseln. Controls C209 unverändert. Bisherige Site-/Globalsummen zählen logische Site-Arbeit. Neue physische Primary-Zahlen sind separat versioniert. Getrennte Cursor können Restbesuche und weitere erlaubte Arbeitsschritte benötigen. Kein behaupteter CPU-Beschleunigungsfaktor oder vollständiger Waisennachweis. Aktive Reserve/Locator bleiben P.4; kein allumfassender gemeinsamer Rundgang über Primary und sekundäre Lanes. 80 Pflicht-Quellstufen, 178 PHP-Dateien, 70 Node-Dateien, sechs aktuelle portable C-Programme und acht C/PHP/Anzeige-Ketten bestanden; Windows E302/IIS nicht ausgeführt. # 28.10.2026 – E301/P344/R186 E301/P344 korrigiert die zeitabhängige Vorbereitung der nativen Shared-GC-Abnahme: zehn Sekunden TTL für den Workerwechsel, protokollierte Zeitgrenzen und Ablauf vor GC-Aktivierung. R186 aktualisiert die Dokumentation. Speicher-, GET-/SET- und GC-Algorithmen bleiben auf E300; Controls C209 unverändert. Befund: Windows-E300-Kompilierung und vorangehende Abnahmen erfolgreich; erster Worker-GET eines TTL1-Wertes schlug vor GC-Aktivierung fehl. Der konkrete alte Ablaufzeitpunkt fehlt. Kein Nachweis eines GC-/Verweisfehlers aus diesem Protokoll. Neue Windows-Abnahme noch erforderlich. # Aktueller Stand E300/P343 und R185 E300/P343 und R185: Large-/Outside-v4 teilen überlappende Suchabschnitte bei eigenen Site-Cursorn, Regeln und Budgets. Neue globale physische Suchzähler; Primary/Legacy und GET/SET bleiben. ABI34 erfordert gemeinsam neue DLL/CEL-S und PHP-Worker-Neustart. R185 korrigiert Bearbeitungszustand und Revisionsdarstellung, verbirgt den alten Stand während Neuermittlung und kürzt GC-Anzeigen. Controls C209 unverändert. Native Windows/IIS-Abnahme lokal erforderlich. Quelle, portable native Verarbeitung und Anzeigeprüfungen bestanden. Windows-/IIS-Abnahme noch lokal auszuführen. # Aktueller Cache-Stand und Grenzen 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.