Übergang zur Paketarchitektur

WebBlocks CMS wird derzeit als Root-verwaltete Laravel-Anwendung ausgeliefert, bei der die CMS-Kerndateien direkt im Installationsstammverzeichnis neben den benutzereigenen Anwendungsdateien liegen. Dieses Modell macht Upgrades fragil, weil sich CMS-Produktcode und installationsspezifischer Projektcode dasselbe oberste Dateisystem teilen.

Wenn CMS-Updates durch Ersetzen oder Kopieren Root-verwalteter Dateien angewendet werden, ist nicht garantiert, dass upstream entfernte Kerndateien auch aus nachgelagerten Installationen verschwinden. Eine veraltete, entfernte Kerndatei kann im Installationsstammverzeichnis verbleiben, weiterhin von Laravel automatisch geladen oder gerendert werden und neueres ausgeliefertes Verhalten stillschweigend überschreiben. Genau diese Problemklasse wurde kürzlich durch eine veraltete Root-Blade-Datei in einer nachgelagerten Installation bestätigt.

Die aktuelle Architektur hält CMS-Updates außerdem eng an den Git-Zustand und die Root-weite Dateisynchronisierung gekoppelt. Das erschwert es, über Eigentumsgrenzen nachzudenken, installationsspezifische Anpassungen sicher zu bewahren und Updates über bestehende Installationen hinweg vorhersehbar zu machen.

Die Zielarchitektur ist ein Composer-verwaltetes Laravel-Paket:

• Paketname: fklavyenet/webblocks-cms
• Installationspfad: vendor/fklavyenet/webblocks-cms
• Kanonische Quelle der Wahrheit des installierten Pakets: vendor/fklavyenet/webblocks-cms

Im Zielmodell wird der CMS-Kerncode als normales Composer-Paket installiert und aktualisiert, statt in das benutzereigene Laravel-Projektstammverzeichnis kopiert zu werden.

Das bedeutet:

• CMS-PHP-Quellcode gehört in das Paketverzeichnis src/
• Laravel-Paketressourcen bleiben in den Paketverzeichnissen config/, database/, resources/, routes/, public/ und stubs/
• src/ ist nicht der Ort, an den jede Paketdatei gehört
• das benutzereigene Laravel-Stammverzeichnis sollte app/, config/, database/, public/site/, resources/, routes/, storage/ und composer.json besitzen

System Update muss sich an diesem Composer-Paketlayout ausrichten. Bei installierten, paketnativen Konsumenten wendet der Updater paketbezogene Release-Artefakte auf vendor/fklavyenet/webblocks-cms an; er darf packages/webblocks-cms nicht als zweite aktive, aktualisierte Laufzeitkopie beibehalten. Ein packages/webblocks-cms-Baum gehört ausschließlich zu quellverwalteten Entwicklungs-Checkouts oder zu Altlasten aus der Übergangsphase.

Wenn eine Alt-Installation im Composer-Vendor-Verzeichnis Repository-förmig ist, normalisiert System Update vendor/fklavyenet/webblocks-cms auf das flache Paketstammverzeichnis. Nach der Normalisierung liegen src/, docs/, routes/, resources/, database/, public/, config/ und stubs/ direkt unter vendor/fklavyenet/webblocks-cms; Reste des Repository-Stammverzeichnisses wie artisan, app/, bootstrap/, packages/, plugins/ und tests/ werden aus dem Paketstamm-Ersatz entfernt.

project/ darf während des Übergangs vorübergehend als Kompatibilitätsschicht bestehen bleiben, sollte aber nicht das langfristig verpflichtende Anpassungsmodell für installationsspezifisches Verhalten bleiben.

Die erwartete Richtung für das Starter-Projekt ist ein separater Laravel-Starter wie fklavyenet/webblocks-cms-starter, bei dem das benutzereigene Projektstammverzeichnis das CMS-Paket einbindet, statt alle CMS-Kerndateien direkt einzubetten.

Die Bereitschaft des Konsumenten-Pakets hat nun begonnen, ist aber bewusst partiell und explizit:

• frische Laravel-Konsumenten können das Paket installieren und webblocks:install ausführen
• das Paket verwendet für saubere Konsumenten-Installationen einen fokussierten Migrationspfad für Frischinstallationen, statt die gesamte historische Root-Migrationskette erneut abzuspielen
• Paketmigrationen des Wartungs-Repositorys bleiben standardmäßig durch Guards deaktiviert und wirkungslos
• App\Models\User bleibt in v1.32.8 die vorübergehende Auth-Grenze des Konsumenten
• der Paketinstaller patcht App\Models\User automatisch mit einem Paket-Trait und schreibt zuvor ein Backup mit Zeitstempel
• paketeigene Anmeldung, Abmeldung, Installationshinweis, Admin-Schutz, öffentliche Startseite, Views und Assets reichen nun für den ersten sauberen Konsumenten-Pfad aus
• dies ist noch kein separates Starter-Repository und beseitigt die app-eigene User-Grenze noch nicht

Der Anwendungsbaum eines echten Composer-Konsumenten kann minimal sein, während die CMS-Laufzeit aus vendor/fklavyenet/webblocks-cms lädt. Das Wartungs-Repository spiegelt diese Grenze jetzt genauer wider: Das Root-Verzeichnis app/ behält standardmäßig keine Wrapper mit Paket-Gegenstücken mehr.

Entfernte Wrapper-Kategorien:

• Konsolenbefehle mit Paket-Gegenstück, mit Ausnahme des Host-eigenen ProjectInitCommand
• CMS-Admin-/Public-Controller und Middleware mit Paket-Gegenstück, deren Routen jetzt auf Paketklassen zeigen, mit Ausnahme der Install-Redirect-Middleware der Wartungs-Shell
• Admin-/Public-Form-Requests mit Paket-Gegenstück
• Mailables mit Paket-Gegenstück
• CMS-Modelle mit Paket-Gegenstück
• Support-Klassen mit Paket-Gegenstück in den Bereichen Blöcke, Medien, Seiten, Sites, System, Updates, Suche, Besucher sowie operative Transfer-/Promotion-Domänen

Bewusst weiterhin Root-eigen oder zurückgestellt:

• app/Models/User.php, der Basis-Controller.php und die Service-Provider bleiben Host-eigene Laravel-Shell-Dateien.
• Auth-/Profil-/Installationsdateien, einschließlich der Install-Redirect-Middleware, bleiben Host-eigen, bis die Starter-/Installationsgrenze bewusst neu gestaltet wird.
• Auth, Profil, Installation und die Projektschicht bleiben Host- oder Übergangsgrenzen.
• die Alt-Asset-Shims Asset, AssetFolder, BlockAsset und App\Support\Assets\... wurden entfernt; die Medienmodelle und Support-Klassen des Pakets sind jetzt die maßgebliche Laufzeit- und Testoberfläche.
• App\Support\WebBlocks wurde entfernt; Root-Konfiguration, Views und Tests verwenden jetzt WebBlocks\Cms\Support\WebBlocks als Quelle für Produktidentität und Version.
• leere Root-Verzeichnisse unter app/ mit Paket-Gegenstück werden entfernt, statt als Übergangsmarker erhalten zu bleiben.
• Root-Migrationen, Konfigurations-Overrides, das Laufzeitverzeichnis public/cms, Root-Blade-Kompatibilitäts-Wrapper und Root-Seeder-Wrapper bleiben außerhalb dieser Bereinigung.

Die Bereinigung verbessert den Paketübergang und die Starter-Bereitschaft, weil das Wartungs-Repository jetzt dieselbe minimale App-Annahme testet wie ein frischer Paket-Konsument. Sie macht das Repository jedoch noch nicht vollständig Starter-bereit: Installation/Auth, User, die Root-Migrationsautorität, die operative Root-Update-/Installationsautorität und die Kompatibilitätspfade für Root-Laufzeit-Assets bleiben die letzten Blocker.

Der langfristige Update-Ablauf sollte Composer-/paketverwaltet und Git-unabhängig sein.

Die Ziel-Update-Architektur lautet:

• kein Root-weites Kopieren von CMS-Kerndateien
• CMS-Kern wird über Composer-Pakete installiert und aktualisiert
• kontrollierte Laufzeit-Upgrade-Schritte nach dem Paket-Update, einschließlich Migrationen
• Cache-Leerung, wo nötig
• explizite Katalogreparatur als separater Operator-Wartungsworkflow, wenn nötig
• kontrolliertes Veröffentlichen oder Synchronisieren von Assets nur, wenn tatsächlich erforderlich

So bleiben installationseigene Root-Dateien von paketeigenen CMS-Kerndateien getrennt, und es wird verhindert, dass entfernte CMS-Kerndateien unbegrenzt in nachgelagerten Installationen verbleiben, nur weil sie einmal im Stammverzeichnis existierten.

Das Composer-Paket und das Wartungs-Repository sind Konsumenten statischer Assets, keine Hosts einer Frontend-Build-Kette. WebBlocks CMS darf für CMS-eigene Assets weder Vite, das Laravel-Vite-Plugin, Tailwind, npm, Node, Paket-Lockfiles, public/build, public/hot noch @vite-Laufzeit-Hooks ausliefern oder voraussetzen.

CMS-eigene Assets gehören für die Wartungslaufzeit in das Root-Verzeichnis public/cms und für Release-Artefakte in das Paketverzeichnis packages/webblocks-cms/public/cms. WebBlocks UI bleibt ein vorgelagertes UI-Projekt, das über gepinnte veröffentlichte Assets konsumiert wird, und WebBlocks UI Manager bleibt das First-Party-Operator-Plugin für Release-/CDN-Veröffentlichungsworkflows. Verschieben Sie die WebBlocks-UI-Quellkompilierung, npm-Build-Skripte, dist-Generierung oder Hot-File-Annahmen nicht in den CMS-Kern oder sein Release-Paket.

Angestrebte paketeigene CMS-Pfade:

• packages/webblocks-cms/src/ während der Übergangsphase im Repository
• später vendor/fklavyenet/webblocks-cms/src/ in installierten Umgebungen
• Paket-config/
• Paket-database/
• Paket-resources/
• Paket-routes/
• Paket-public/
• Paket-stubs/

Angestrebte benutzereigene Pfade im Projektstammverzeichnis:

• app/
• config/
• database/
• public/site/
• resources/
• routes/
• storage/
• composer.json

Diese Aufteilung belässt das Eigentum an der Laravel-Anwendung bei der Installation, während das CMS-Produkteigentum in das Paket wandert.

Paket-first-CMS-Installationen müssen die Grenzen der Host-Anwendung wahren, wenn das CMS neben einem anderen Laravel-Produkt installiert wird. Das CMS sollte Routen-, Konfigurations-, View- und Tabellenkollisionen mit der Host-App vermeiden und darf nicht annehmen, dass die /admin-Route der Host-App dem CMS gehört.

Das kanonische CMS-Admin-Präfix ist /webadmin, wobei ein konfigurierbares Präfix weiterhin die Zielrichtung für künftige Koexistenz-Flexibilität ist. Host-eigene Anmeldung und CMS-eigene Autorisierungsentscheidungen sind unter Coexistence dokumentiert. Statische CMS-Assets bleiben unter public/cms und werden über /cms/... ausgeliefert.

Wenn paketeigene CMS-Auth-Routen aktiv sind, gehört /webadmin/login zur Paketgrenze. Seine Blade-Oberfläche muss im View-Namespace webblocks-cms:: bleiben, die WebBlocks-UI-Gast-Auth-Shell verwenden, das gepinnte WebBlocks-UI-CSS/JS plus /cms/css/guest.css laden und Produkt-Marken-/Logo-Assets aus /cms/brand auflösen. CMS-Produkt-Marken-Assets müssen Favicon-/Browser-Tab-Varianten für normal, dunkle Oberfläche, auf Akzent/invers und hohen Kontrast bereitstellen, damit der Kontrast von Auth- und Produkt-Shell mit expliziten Assets statt mit CSS-Filtern gelöst wird.

Admin-Routen-Präfixe dürfen keine physischen öffentlichen Asset-Verzeichnissegmente wiederverwenden. Das ausgemusterte Admin-Präfix /cms kollidierte mit dem aktiven Asset-Verzeichnis public/cms, weil Nginx-try_files /cms/ als Verzeichnis auflösen kann, bevor Laravel die Route erhält. Die aktuelle Paketarchitektur behält daher /webadmin/... für CMS-Admin- und Paket-Login-Routen, reserviert /cms/... ausschließlich für statische Assets und verbietet CMS-eigene /cms-Aliasse, /cms-Weiterleitungen und wiederhergestellte CMS-eigene /admin-Routen. Die alte public/cms/index.php-Übergabe ist nicht Teil der Paketgrenze und muss sowohl in den Root- als auch in den Paket-Public-Assets abwesend bleiben.

Führen Sie den Paketarchitekturplan ein und erstellen Sie ein Paketgerüst im Repository, ohne bereits Laufzeitcode zu verschieben. Das Verhalten der Root-App bleibt unverändert.

Fügen Sie den Paket-Service-Provider und die lokale Path-Composer-Verdrahtung hinzu, damit das Paket als echte installierbare Einheit im Repository existiert. Halten Sie die Boot-Logik bewusst minimal und vermeiden Sie Änderungen am Laufzeitverhalten.

Verfeinern Sie den Paket-Service-Provider so, dass er den Bootstrap-Vertrag für künftige paketeigene Ressourcen definiert, ohne diese Ressourcen bereits maßgeblich zu machen.

In dieser Phase darf der Provider abgesichertes Laden und die Publish-Registrierung für die Paketverzeichnisse config/, routes/, resources/views/, database/migrations/, public/ und stubs/ gefahrlos vorbereiten, jedoch nur, wenn echte Paketdateien existieren.

Das aktuelle Root-Laufzeitverhalten bleibt weiterhin unverändert, weil das Paketgerüst nur Platzhalter enthält. Bis Laufzeitdateien in späteren Phasen tatsächlich in das Paket verschoben werden, bleibt die Root-Laravel-Anwendung die maßgebliche Quelle für aktive CMS-Routen, Views, Konfiguration, Migrationen und öffentliche Assets.

Der erste paketeigene Standard-Konfigurationspfad hat nun mit der Paketdatei config/webblocks-updates.php begonnen. Während des Übergangs liefert diese Paketdatei CMS-eigene Standardwerte, während die bestehende Root-Datei config/webblocks-updates.php als Override auf Installationsebene und als abwärtskompatible Anwendungs-Konfigurationsdatei bestehen bleibt.

Die aktuellen Dateien im Root-Verzeichnis config/ fallen in zwei Übergangsgruppen.

Kandidaten für CMS-Produkt-Standardwerte:

• webblocks-cms.php
• cms.php
• contact.php
• demo_media.php
• webblocks-updates.php

Laravel-app-eigene oder installationseigene Konfiguration, die Root-eigen bleiben sollte:

• app.php
• auth.php
• cache.php
• database.php
• filesystems.php
• logging.php
• mail.php
• queue.php
• services.php
• session.php

Die aktuelle risikoarme Übergangsregel lautet, CMS-eigene Standardkonfiguration nur dann zu verschieben, wenn dabei stabiles Produktverhalten und klare Override-Semantik der Installation erhalten bleiben. Der paketeigene Standardsatz umfasst jetzt webblocks-cms.php, cms.php, contact.php, demo_media.php und webblocks-updates.php. Die Root-Konfigurationsdateien für bestehendes CMS-Verhalten bleiben während des Übergangs als Overrides auf Installationsebene und abwärtskompatible Einstiegspunkte der Anwendungskonfiguration bestehen. webblocks-cms.php ist vorerst paketexklusiv und besitzt die Übergangssteuerungen: Diagnoserouten, öffentliche Statusrouten, Admin-Statusrouten und das Laden von Paketmigrationen bleiben standardmäßig deaktiviert, während das Laden der Paket-Admin-Routen aktiviert ist, damit paketeigene Admin-Routen maßgeblich werden können.

Beginnen Sie, CMS-eigenen PHP-Quellcode in kleinen, überprüfbaren Abschnitten in das Paketverzeichnis src/ zu verschieben, und aktualisieren Sie Namespaces und das Service-Provider-Bootstrapping nur, sobald der jeweils verschobene Bereich bereit ist.

Der Paket-Konsolen-Bootstrap ist jetzt zusätzlich durch den schreibgeschützten Diagnosebefehl webblocks:package-status nachgewiesen. Dieser Befehl ist paketeigen, wird nur in Konsolenkontexten registriert und meldet das Vorhandensein des Paket-Bootstraps, ohne Dateien, Datenbankzustand, Cache, Konfiguration oder Update-Zustand zu verändern.

Die erste Verschiebung von PHP-Quellcode sollte ebenso konservativen Kriterien folgen: CMS-eigen, klein, leicht nachvollziehbar, ohne Datenbank- oder Eloquent-Abhängigkeit, ohne Controller- oder Request-Abhängigkeit und mit eng begrenzten Referenzaktualisierungen. Die erste verschobene Klasse ist SearchTextNormalizer, ein reiner Suchtext-Helfer, der jetzt dem Paketverzeichnis src/Support/Search/ gehört.

Aktuelle Grenze des Such-Supports:

• jetzt paketeigen: SearchTextNormalizer, PublicSearchRebuildResult, PublicSearchIndexer, PublicSearchQuery, PublicSearchSchema, SearchablePageResolver, BlockSearchTextExtractorRegistry und ReindexesPublicSearch
• keine Search-Support-Klasse muss derzeit aus projektspezifischen Gründen root-eigen bleiben; das Root-Shim App\Support\Search\ReindexesPublicSearch wurde entfernt

Aktuelle Audit-Grenze für Nicht-Search-Support:

• in diesem Audit-Schritt wurde kein weiterer Nicht-Search-Support-Helfer verschoben, da keiner der geprüften Kandidaten die aktuellen risikoarmen Kriterien für Paketeigentum erfüllte
• MediaKindResolver ist klein und deterministisch, hängt derzeit jedoch von den Konstanten von App\Models\Media ab und wird aus einem Controller-Pfad referenziert; daher ist er für diese Phase noch nicht unabhängig genug
• DatabaseExecutionStrategyResolver bleibt vorerst root-eigen, da er die Ausführungsstrategie für Datenbank-Dump oder -Wiederherstellung, die Umgebungsprüfung und die Laufzeitsicherheit von Backup oder Wiederherstellung direkt beeinflusst
• SiteHandle bleibt vorerst root-eigen, da er von Modellen, Requests sowie Site-Transfer- oder Klon-Abläufen verwendet wird; eine Verschiebung würde daher Routing-, Portabilitäts- und persistenznahe Grenzen zu früh überschreiten
• SiteDomainNormalizer bleibt vorerst root-eigen, da er weiterhin von Modellen, Requests, der Routenauflösung und Migrationen verwendet wird, was die frühere Risikoeinschätzung bestätigt

Support-Grenze für Contact:

• jetzt paketeigen: ContactMessageNotificationResult
• vorerst root-eigen: ContactMessageNotifier, da er weiterhin Mail-Transport-Aufrufe, die Interaktion mit dem Contact-Modell und die konfigurationsbasierte Empfängerauflösung besitzt
• ContactMessageNotificationResult konnte sicher verschoben werden, da es ein kleines unveränderliches Ergebnisobjekt ohne Kopplung an Modelle, DB, Requests, Konfiguration, Mail, Migrationen oder serialisierte Payloads ist und nur eine eng begrenzte Aktualisierung der Notifier-Referenz erforderte

Support-Grenze für Blocktypen:

• jetzt paketeigen: BlockTypeContract
• vorerst root-eigen: BlockTypeContractRegistry, da sie weiterhin von Block-Modellen, Katalog-Sync-Definitionen, dem Verhalten der Übersetzungs-Registry, der Ressourcenpfad-Inspektion sowie den root-eigenen Audit- oder Admin-Abläufen abhängt, die diese aufgelösten Contracts konsumieren
• BlockTypeContract konnte sicher verschoben werden, da es ein kleines Contract-DTO mit ausschließlich im Konstruktor gesetztem Zustand und deterministischer Array-Serialisierung ist, ohne Kopplung an Modelle, DB, Requests, Konfiguration, Befehls-Nebenwirkungen, Migrationen oder serialisierte Payloads

Grenze für Seiten-Layout-Markup:

• vorerst root-eigen: LayoutMarkup
• LayoutMarkup wurde in diesem Schritt nicht verschoben, da es zwar zustandslos und klein ist, aber direkt von Form-Requests des Seiten-Layouts, der Logik des Page-Layout-Managers, der öffentlichen Slot-Wrapper-Auflösung und einem Admin-Blade-Formular verwendet wird; eine Verschiebung würde jetzt Grenzen der Request-Validierung und des öffentlichen Renderings innerhalb des größeren Pages- oder PublicRendering-Bereichs überschreiten, der bewusst noch root-eigen ist

Support-Grenze für Formatierung:

• jetzt paketeigen: InlineRichTextRenderer
• vorerst root-eigen: SafeRichTextRenderer, da er weiterhin den umfangreicheren HTML-Sanitization-Contract, das Verhalten erlaubter Tags, die DOM-Parsing-Regeln und die öffentliche Rich-Text-Rendering-Semantik besitzt
• InlineRichTextRenderer konnte sicher verschoben werden, da er ein kleiner deterministischer Formatter ohne Kopplung an Modelle, DB, Requests, Konfiguration, Migrationen oder serialisierte Payloads ist und nur eine eng begrenzte Aktualisierung von Blade- und Unit-Test-Referenzen erforderte

Migrationskarte der Support-Quellen:

• Search: paketeigen für die aktuelle Laufzeitunterstützung, einschließlich des Reindex-Traits, das von Paketmodellen verwendet wird. Die Root-Shims App\Support\Search\... sollten nicht wiederhergestellt werden.
• Formatting: Kandidat nach Abhängigkeitsisolierung. InlineRichTextRenderer ist jetzt als risikoarmer Formatierungshelfer paketeigen, während SafeRichTextRenderer root-eigen bleibt, da er das risikoreichere Sanitization-Verhalten definiert.
• BlockTypes: Kandidat nach Abhängigkeitsisolierung. BlockTypeContract ist ein kleines Wertobjekt, aber der Namespace ist durch BlockTypeContractRegistry, Admin-Routen und einen Root-Konsolen-Audit-Befehl verankert.
• BlockTypes: Kandidat nach Abhängigkeitsisolierung. BlockTypeContract ist jetzt als eng begrenzte Wertobjekt-Verschiebung paketeigen, aber der Namespace ist weiterhin durch BlockTypeContractRegistry, Admin-Routen und einen Root-Konsolen-Audit-Befehl verankert.
• Media und Assets: paketeigene Medienmodelle und Support-Klassen sind maßgeblich für die entfernten Legacy-Asset-Shims. Verbleibende Medienarbeiten sollten es vermeiden, die Root-Wrapper Asset, AssetFolder, BlockAsset oder App\Support\Assets\... wiederherzustellen.
• Pages und PublicRendering: root-eigen bis zu einer dedizierten Migrationsphase. Diese Klassen steuern Routenauflösung, Layout-Auswahl, Seiten-Assets, Slot-Wrapper, öffentliche Presenter, Seitenduplizierung oder -import und das öffentliche Rendering-Verhalten mit durchgängiger Modell- und Request-Kopplung.
• Pages und PublicRendering: root-eigen bis zu einer dedizierten Migrationsphase. LayoutMarkup wurde als mögliche Ausnahme geprüft, bleibt aber root-eigen, da es weiterhin direkt auf Seiten-Layout-Requests, der Slot-Wrapper-Auflösung und dem Rendering von Admin-Views aufsitzt, obwohl seine eigene Logik zustandslos ist.
• Blocks: root-eigen bis zu einer dedizierten Migrationsphase. Dieser Bereich besitzt Block-Payload-Schreibvorgänge, Übersetzungspersistenz, Blocklöschung, Katalog-Sync, die Extraktion vertrauenswürdigen HTMLs und request-gebundene öffentliche Registries, die direkt auf der Blockpersistenz und den Renderer-Contracts aufsitzen.
• SharedSlots und Revisions: root-eigen bis zu einer dedizierten Migrationsphase. Diese Klassen hängen von Blockbäumen, Revisionstabellen, Schemaprüfungen, Übersetzungszeilen und Wiederherstellungs- oder Snapshot-Semantik ab.
• Sites, Sites\\ExportImport und SitePromotion: root-eigen bis zu einer dedizierten Migrationsphase. Diese Bereiche sind eng an Modelle, Routing, Portabilität, Archive, serialisierte Transfer-Payloads, Klon- oder Löschabläufe, Sicherheits-Backups bei der Promotion und die öffentliche Site-Auflösung gekoppelt.
• System und System\\Updates: root-eigen bis zu einer dedizierten Migrationsphase. Diese Klassen besitzen Einstellungspersistenz, den Status der installierten Version, Backup oder Wiederherstellung, SQL-Validierung, den Download- oder Entpackablauf von Updates und die Ausführungsstrategie der Datenbank.
• Install und ProjectLayer: noch nicht verschieben. Diese Klassen berühren den Installer-Ablauf, .env-Schreibvorgänge, das Laden von Routen oder Providern, Prüfungen des Installationsstatus und Anpassungsgrenzen der Projektwurzel.
• Navigation, Locales, Users, Visitors, Contact und Icons: Kandidat nach Abhängigkeitsisolierung. Jede Gruppe enthält einige kleinere Helfer oder Ergebnisobjekte, aber die aktuellen Implementierungen stützen sich weiterhin auf Modelle, Auth, Mail, Schemainspektion, HTTP-Abrufe oder einstellungsgestütztes Laufzeitverhalten.
• Navigation, Locales, Users, Visitors, Contact und Icons: Kandidat nach Abhängigkeitsisolierung. ContactMessageNotificationResult ist jetzt als eng begrenzte Wertobjekt-Verschiebung paketeigen, während sich die übrigen Gruppen weiterhin auf Modelle, Auth, Mail, Schemainspektion, HTTP-Abrufe oder einstellungsgestütztes Laufzeitverhalten stützen.
• Admin, Audit und Database: Kandidat nach Abhängigkeitsisolierung. AdminPagination, CurrentActorResolver und DestructiveDatabaseCommandGuard sind klein, aber jede dieser Klassen hängt weiterhin an Root-Einstellungen, Auth oder Sicherheits-Hooks der Anwendung.
• WebBlocks: das paketeigene WebBlocks\Cms\Support\WebBlocks ist jetzt die Quelle für Produktidentität und Version sowohl für Paketkonsumenten als auch für die Wurzel des Wartungs-Repositorys.

Hinweis zum Quell-Checkpoint der Phase 2:

• die ersten risikoarmen Verschiebungen von Helfern und Wertobjekten wurden bis v1.31.60 erfolgreich abgeschlossen
• die lokal mit dem Paket verdrahtete Entwicklungsumgebung wurde nach v1.31.60 erfolgreich aktualisiert, was bestätigt, dass der Checkpoint mit dem gepflegten lokalen Workflow kompatibel bleibt
• opportunistische risikoarme Verschiebungen von PHP-Quellcode sind jetzt bewusst pausiert
• verschieben Sie keine laufzeitlastigen Klassen weiter ohne einen dedizierten, fokussierten Phasenplan und ein Abhängigkeits-Audit

Aktuelle Blocker für Gruppen mit höherem Risiko:

• direkte Kopplung an App\Models\... oder Eloquent-Abfragen in Search, Pages, Blocks, Sites, Navigation, Locales, Icons, Visitors und System
• Request-, Routen-, Controller- oder View-Kopplung in Admin, Pages, PublicRendering, Formatting und einigen BlockTypes-Helfern
• Schema-, Migrationsform- oder Tabellenexistenzprüfungen in Search, SharedSlots, Revisions, Visitors, Install und System
• Kopplung an Konfiguration, Env, HTTP, Mail, Dateisystem, Prozesse, Backup, Update und lokale Laufzeit in Contact, Icons, Install, System und Updates
• Kopplung an serialisierte Archiv- oder Transfer-Payloads in Sites\\ExportImport, SitePromotion, dem Seitenimport und Legacy-Helfern für Asset-Kompatibilität

Verschieben Sie eindeutig paketeigene Konfiguration, Routen, Views, Migrationen, Seeder, öffentliche Assets und Stubs in Laravel-Ressourcenordner auf Paketebene. Führen Sie das Lade- und Publish-Verhalten des Pakets schrittweise ein statt alles auf einmal.

Der aktuelle Seeder-Abschnitt der Phase 3 deckt jetzt die paketeigene Katalog-Seeder-Grenze sowie ihren paketeigenen Aggregator ab:

• jetzt paketeigen: CoreCatalogSeeder, IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder unter packages/webblocks-cms/database/seeders/
• Root-Kompatibilitäts-Einstiegspunkte verbleiben in database/seeders/, damit bestehende Installationen, Tests und aktuelle Laufzeit- oder Update-Einstiegspunkte weiterhin Database\Seeders\... aufrufen können
• der paketeigene CoreCatalogSeeder bleibt eine reine Eigentumsverschiebung: er delegiert weiterhin an die root-eigenen PageLayoutSeeder und BlockTypeSeeder, und der aktuelle Root-DatabaseSeeder sowie die Update-Einstiegspunkte rufen weiterhin den Root-Kompatibilitätswrapper auf
• vorerst weiterhin root-eigen: PageLayoutSeeder, BlockTypeSeeder, DatabaseSeeder und die aktiven Post-Install-Befehle des System Updates
• das Paket-Seeder-Eigentum in dieser Phase betrifft nur die Migration von Namespace und Grenze, nicht die Änderung der aktuellen Root-Update-Autorität

Der nächste Übergangsfokus nach v1.31.60 ist das Eigentum an Paketressourcen, nicht weitere opportunistische Helfer-Verschiebungen.

Der Checkpoint v1.31.62 macht die Paketressourcen-Grenze zu einem expliziteren und testbaren Pilot, ohne bereits aktives Laufzeit-Eigentum zu übertragen.

• die Paketverzeichnisse routes/, resources/views/, database/migrations/, public/ und stubs/ existieren jetzt als explizit reservierte Paket-Grenzverzeichnisse mit Marker-Dateien, die die zukünftige Eigentumsabsicht dokumentieren
• die Standardwerte der Paketkonfiguration bleiben CMS-eigen im Paketordner config/
• die passenden Root-Konfigurationsdateien bleiben die Override-Ebene auf Installationsebene und die abwärtskompatiblen Einstiegspunkte der Anwendungskonfiguration
• der Paket-Service-Provider hält das Paket-Publishing explizit und paket-getaggt, aber das Publishing bleibt inaktiv, solange ein Entwickler nicht bewusst vendor:publish ausführt
• der Paket-View-Namespace webblocks-cms ist jetzt als sicherer Pilot der Paketgrenze registriert, ohne die aktuelle Auflösung von Root-Admin- oder öffentlichen Views zu ändern
• Paketrouten, Paket-Views, Paketmigrationen, öffentliche Paket-Assets und Paket-Stubs sind in dieser Phase weiterhin kein aktives maßgebliches Laufzeit-Eigentum
• webblocks:package-status meldet jetzt die Bereitschaft der Paketressourcen (reserviert versus befüllt) auf strikt schreibgeschützte Weise

Dieser Pilot verschiebt keine aktiven Root-Routen, Root-Views, Root-Migrationen, öffentlichen Root-Assets, Controller, Requests, Modelle, Services oder das Verhalten des System Updates.

Der Checkpoint v1.31.63 macht den zuvor reservierten Paket-View-Namespace zu einer konkreten, testbaren paketeigenen Diagnosegrenze, ohne aktives Laufzeit-Eigentum zu ändern.

• die Paketdatei resources/views/diagnostics/package-status.blade.php existiert jetzt als echte paketeigene interne Diagnose-Blade-View
• die Diagnose-View wird nur über den Namespace webblocks-cms:: gerendert und ist über keine Admin- oder öffentliche Route zugänglich
• webblocks:package-status kann jetzt optional mit --view-check diese Diagnose-View auf strikt schreibgeschützte Weise rendern und bestätigen, dass der Paket-View-Namespace korrekt aufgelöst wird
• die Standardausgabe von webblocks:package-status bleibt schlank und schreibgeschützt, und auch die optionale View-Prüfung führt keine Datei-, Cache-, Konfigurations- oder Datenbank-Schreibvorgänge und keine Änderungen am Installationsstatus durch
• aktive Root-Admin- und öffentliche Views bleiben maßgeblich, und in dieser Phase ändert sich kein bestehender Root-View-Pfad und kein Eigentum an Laufzeitrouten

Dieser Pilot belegt das Laden des Paket-View-Namespace mit einer echten paketeigenen Blade-Datei und vermeidet dabei bewusst jede Verschiebung aktiver Root-Admin- oder öffentlicher Views.

Der Checkpoint v1.31.64 macht die zuvor reservierte Paketrouten-Grenze zu einem konkreten, testbaren Diagnoserouten-Pilot, ohne aktives Routen-Eigentum zu ändern.

• die Paketdatei routes/diagnostics.php existiert jetzt als echte paketeigene Diagnose-Routendatei für zukünftige paketinterne Diagnosen
• der Paket-Service-Provider hält das Laden der Paket-Diagnoserouten explizit hinter webblocks-cms.diagnostics.load_routes abgesichert, sodass Paket-Diagnoserouten standardmäßig nicht in die normale Laufzeit geladen werden
• webblocks:package-status meldet jetzt das Vorhandensein der Paketrouten-Grenze, den Status der Paket-Routendatei, die Existenz der erwarteten Diagnose-Routendatei, den abgesicherten Routenladezustand und ob die Diagnoseroute aktuell geladen ist
• aktive Root-Admin- und öffentliche Routen bleiben maßgeblich, und in dieser Phase wurden keine bestehenden Root-Admin- oder öffentlichen Routendateien verschoben oder geändert

Dieser Pilot belegt die Paketrouten-Grenze mit einer echten paketeigenen Diagnose-Routendatei und vermeidet dabei bewusst jede Migration des aktiven Eigentums an Admin- oder öffentlichen Routen.

Der Checkpoint v1.31.65 schließt die verbleibenden nicht laufzeitbezogenen Paketgrenzen-Piloten für Migrationen, öffentliche Assets, Stubs und das Composer-verwaltete Update-Flow-Ziel ab, ohne aktives Laufzeit-Eigentum zu verschieben.

• die Paketverzeichnisse database/migrations/, public/ und stubs/ enthalten jetzt eine klarere Dokumentation der reservierten Grenzmarkierungen für ihre zukünftigen paketeigenen Rollen
• das Laden von Paket-Migrationen ist jetzt über webblocks-cms.boundaries.load_migrations explizit per Schutzschalter deaktiviert, sodass Paket-Migrationen inaktiv bleiben, bis eine spätere fokussierte Laufzeitphase sie gezielt anbindet
• die Veröffentlichung paketeigener Public-Assets und Stubs bleibt explizit und paketgetaggt; sie veröffentlicht jetzt den ersten paketeigenen Asset-Marker und Starter-Stubs, ohne Root-Laufzeit-Assets oder den aktuellen Installer zu ersetzen
• webblocks:package-status meldet jetzt den Status der Migrationsgrenze, den Status der Public-Asset-Grenze, den Status der Stub-Grenze, den Hinweis auf das Composer-verwaltete Update-Ziel sowie die weiterhin geltende Regel, dass die Root-Laufzeit maßgeblich bleibt
• das aktuelle Root-Composer-Verhalten, das Laden der Root-Laufzeit und das System-Update-Verhalten bleiben in diesem Checkpoint unverändert

Dieser Checkpoint schließt die Pilotphase der Paketgrenzen ab. Das Repository verfügt jetzt über konkrete, testbare Paketgrenzen für Routen, Views, Migrationen, Public-Assets, Stubs und die Composer-verwaltete Update-Absicht, während die aktive Laufzeitverantwortung weiterhin bei der Root-Anwendung liegt.

• wählen Sie einen schmalen Laufzeit-Slice, der eindeutig paketeigen und risikoarm genug ist, um vollständig verschoben zu werden
• verschieben Sie erst, wenn die Regeln für Routen-, View-, Migrations-, Asset- oder Laufzeitverantwortung für diesen Slice explizit sind
• prüfen Sie Abwärtskompatibilität und Installationserwartungen, bevor aktive Laufzeitautorität vom Root auf das Paket übergeht
• lassen Sie das System-Update-Verhalten unverändert, bis eine spätere dedizierte Update-Flow-Phase es gezielt neu gestaltet

Das Release v1.32.0 ist der erste Checkpoint eines echten paketeigenen Laufzeit-Slices. Es beginnt die paketeigene Laufzeitarbeit mit drei bewusst kleinen, abgesicherten Slices, die die Paket-Laufzeitverantwortung nachweisen, ohne die aktuelle CMS-Laufzeit zu verdrängen.

Phase 1: abgesicherter Paket-Diagnose-Laufzeit-Slice

• die Paketdatei routes/diagnostics.php verweist jetzt auf einen paketeigenen Controller unter packages/webblocks-cms/src/Http/Controllers/Diagnostics/PackageDiagnosticsController.php
• dieser Controller rendert die vorhandene Paket-Diagnose-View webblocks-cms::diagnostics.package-status
• die Diagnose-Route bleibt weiterhin standardmäßig hinter webblocks-cms.diagnostics.load_routes deaktiviert
• dies ist bewusst nur ein reservierter interner Paketpfad und ersetzt keine Root-Admin- oder öffentliche Laufzeit-Route

Phase 2A: erster fokussierter Paket-Admin-Slice

• die Paketdatei routes/admin.php führte ursprünglich einen kleinen paketeigenen Admin-Laufzeitstatus-Slice ein: admin.webblocks-cms.runtime-status, jetzt eingebunden unter /webadmin/_webblocks-cms/runtime-status
• diese Status-Route verwendet einen paketeigenen Controller und eine paketeigene Blade-View unter packages/webblocks-cms/resources/views/admin/runtime-status.blade.php
• das Laden der Paket-Admin-Routen ist jetzt standardmäßig aktiviert, und der aktive CMS-Admin-Routenbaum wird jetzt aus der Paketdatei routes/admin.php geladen
• die reservierte Admin-Status-Route selbst bleibt standardmäßig hinter webblocks-cms.admin.load_status_route deaktiviert
• Paket-Admin-Routen behalten, wo angemessen, die üblichen Middleware-Anforderungen für Installation, Authentifizierung, Admin-Zugriff und Super-Admin-Systemzugriff
• die aktive Admin-Laufzeitverantwortung ist jetzt paketeigen für Seiten, Blöcke, Medien, Shared Slots, Navigation, Blocktypen, Seiten-Layouts, Sites, Site-Domains, Site-Variablen und Sprachen (Locales), während Benutzer, System, Installation/Update, Backup/Wiederherstellung, Export/Import, Promotion, Auth/Profil, Migrationen und Root-Laufzeit-Assets im Root-Besitz bleiben

Phase 2B: erster fokussierter öffentlicher Paket-Slice

• die Paketdatei routes/public.php führte ursprünglich einen kleinen paketeigenen öffentlichen Laufzeitstatus-Slice ein: webblocks-cms.public.runtime-status unter /_webblocks-cms/runtime-status
• diese Route verwendet einen paketeigenen Controller und eine paketeigene Blade-View unter packages/webblocks-cms/resources/views/public/runtime-status.blade.php
• das Laden der öffentlichen Paket-Routen ist jetzt standardmäßig aktiviert, und der aktive öffentliche CMS-Routenbaum wird jetzt aus der Paketdatei routes/public.php geladen
• paketeigene öffentliche Einstiegs-Controller verarbeiten jetzt Startseite, lokalisierte Startseite, Suche, lokalisierte Suche, Suche als JSON, Seitenanzeige, lokalisierte Seitenanzeige, das Absenden von Kontaktnachrichten, die Synchronisierung der Datenschutz-Einwilligung sowie die internen Domain-Endpunkte admin-api.*
• paketeigene öffentliche Einstiegs-Views decken jetzt die Seiten- und Such-Einstiegstemplates über webblocks-cms::public.pages.show und webblocks-cms::public.search.show ab
• die reservierte öffentliche Paket-Status-Route selbst bleibt standardmäßig hinter webblocks-cms.public.load_status_route deaktiviert
• die Laufzeitautorität für Public-Assets und die Installations-/Update-Grenzen bleiben außerhalb der explizit verschobenen paketeigenen öffentlichen Routen-, Modell-, Support- und View-Slices weiterhin im Root-Besitz

Warum diese Slices teilweise abgesichert bleiben

• die Root-Laufzeit bleibt für Installationen außerhalb der gezielt verschobenen paketeigenen Slices maßgeblich
• die reservierten Paketpfade vermeiden Routennamen- und Pfadkonflikte mit der bestehenden Admin- und öffentlichen Laufzeit
• die separat abgesicherten Status-Routen erlauben es, Paket-Bootstrap, Routenladen, View-Laden, Middleware-Verhalten und Statusberichte zu testen, ohne diese reservierten Diagnosepfade in die normale Laufzeit zu zwingen
• die verschobene Laufzeitautorität ist weiterhin bewusst partiell, sodass risikoreiche Gruppen wie Modelle, die meisten Admin-Implementierungsklassen, breitere Support-Schichten, Migrationen, Assets und das System-Update-Verhalten eine verfrühte Paketverantwortung vermeiden

• reduzieren Sie das Kompatibilitätsladen der Root-Routen erst weiter, nachdem die verbleibenden Admin- und Public-Implementierungen hinter den Paket-Routendateien verschoben oder bewusst im Root-Besitz belassen wurden
• halten Sie reservierte Diagnose- und Runtime-Status-Routen explizit abgesichert, auch wenn die normalen CMS-Admin- und öffentlichen Routenbäume paketautoritativ sind
• bewahren Sie Routennamen, Pfade, Middleware und Weiterleitungsverhalten, solange die Paket-Routenautorität der tieferen Laufzeit-Extraktion vorausläuft
• behandeln Sie zukünftige Routenbereinigungen als Phase der Kompatibilitätsreduzierung, nicht als Beweis, dass das CMS bereits als Consumer-Paket bereit ist

• verschieben Sie echte paketeigene Views nur in fokussierten Folgephasen, gruppiert nach Laufzeitbereich, zum Beispiel zuerst paketeigene Diagnosen, später sorgfältig geprüfte Admin- oder Public-View-Verantwortung
• halten Sie Routenverantwortung und View-Verantwortung aufeinander abgestimmt, damit eine künftig verschobene View nur eingeführt wird, wenn der zugehörige Laufzeitpfad gezielt paketverwaltet ist
• bewahren Sie klare Regeln für Install-Overrides und Root-Autorität, bis jede Phase der Routen- oder View-Verantwortung explizit entworfen und verifiziert ist

• Das Paketverzeichnis config/ sollte weiterhin die CMS-eigenen Standardwerte definieren.
• Das Root-Verzeichnis config/ bleibt während der Übergangsphase die install-eigene Override-Schicht.
• Eine Paket-Konfigurationsdatei sollte erst dann für das Laufzeitverhalten maßgeblich werden, wenn das Override-Konzept und die Bootstrap-Verdrahtung explizit und stabil sind.

• Paket-Migrationen sollten nicht maßgeblich bleiben, bis echte paketeigene Migrationen existieren und ihre Verantwortung gezielt verschoben wird.
• Wenn die Migrationsverantwortung beginnt, bevorzugen Sie das Paketladen für CMS-eigene Migrationsdateien und explizite Veröffentlichungshinweise nur dort, wo eine install-lokale Anpassung wirklich erforderlich ist.
• Vermischen Sie Arbeiten an der Migrationsgrenze nicht mit unabhängigen Laufzeit-Refactorings.
• Das Root-Verzeichnis database/migrations/ bleibt die Kompatibilitäts- und Autoritätsschicht für quellcodeverwaltete Installationen. Der quellcodeverwaltete Update-Pfad erfordert das Root-Composer-Autoload-Signal des Wartungs-Repositorys für WebBlocks\\Cms\\ => packages/webblocks-cms/src/; das bloße Vorhandensein eines packages/webblocks-cms-Verzeichnisses in einer Consumer-Installation reicht nicht aus. Paket-Consumer-Updates müssen explizite paketeigene Update-Migrationen verwenden und dürfen nicht implizit die Migrationen der Host-Laravel-Anwendung ausführen.
• Frische Paket-Consumer-Installationen verwenden das paketeigene Schema database/migrations/fresh über webblocks:install. Der Installer prüft vor dem Ausführen dieses Schemas auf partielle CMS-Tabellen, stoppt standardmäßig mit Diagnosen und benennt leere partielle Tabellen nur um, wenn der Operator --repair-partial angibt.
• PageLayoutSeeder und BlockTypeSeeder bleiben vorerst im Root-Besitz, weil sie weiterhin den Seiten-Layout-Katalog, die Blocktyp-Synchronisierung und breitere Laufzeitgrenzen von Seiten und Blöcken überschreiten. DatabaseSeeder bleibt ebenfalls im Root-Besitz als aktiver Installations-Einstiegspunkt und Schreiber der installierten Version.

• Die Paket-Routenverantwortung ist jetzt für die CMS-Admin- und öffentlichen Laufzeitbäume über die Paketdateien routes/admin.php und routes/public.php aktiv.
• Die Root-Datei routes/web.php ist jetzt auf Installation, Authentifizierung, Profil und das Kompatibilitätsladen dieser paketeigenen CMS-Routendateien reduziert.
• Routenverschiebungen müssen weiterhin Middleware, Bindings, Namen, Pfade, Modal-Abläufe, Weiterleitungen und nachgelagerte Installationserwartungen bewahren.
• Die Diagnose-, Admin-Runtime-Status- und öffentlichen Runtime-Status-Routen bleiben separat abgesicherte reservierte Pfade und sind nicht Teil der normalen, dauerhaft aktiven CMS-Routenoberfläche.
• Routenautorität bedeutet noch keine vollständige Paket-Laufzeitverantwortung, da viele Handler hinter diesen Routen weiterhin von Root-Modellen, Support-Code, Views und Assets abhängen.

• Das Paketverzeichnis resources/views besitzt jetzt die Diagnose-View, die abgesicherten Admin- und öffentlichen Runtime-Status-Views, die Admin-Views des Icon-Katalogs, die öffentliche Layout-Shell, die öffentlichen Seiten- und Such-Shells, das öffentliche Such-Modal und die paketeigenen Slot-Einstiegs-Views.
• Das Root-Verzeichnis resources/views enthält jetzt Kompatibilitäts-Wrapper für verschobene öffentliche Layout-, Seiten-, Slot- und Such-Einstiegs-Views, bleibt aber weiterhin maßgeblich für die meisten Admin-Bildschirme und für den breiteren öffentlichen Block-Renderer-Kompatibilitätsbaum, der noch nicht vollständig extrahiert wurde.
• View-Verschiebungen sollten mit dem zugehörigen Laufzeitpfad abgestimmt bleiben, damit die Paket-Routenautorität nicht zu weit vor der tatsächlich zuständigen View- und Controller-Schicht liegt.
• Root-Views bleiben der Kompatibilitätspfad für den Großteil des aktiven CMS-Renderings außerhalb der gezielt verschobenen webblocks-cms::-Oberflächen.

• Das Paketverzeichnis public/ sollte letztlich die CMS-eigenen veröffentlichbaren Assets besitzen.
• Die Übergangsarbeit sollte CMS-eigene Paket-Assets von install-eigenen public/site/...-Overrides unterscheiden.
• Asset-Veröffentlichung oder -Synchronisierung sollte nur stattfinden, wenn echte Paket-Assets existieren und der Update-Flow klar definiert, wann eine Veröffentlichung erforderlich ist.
• Die aktuelle Veröffentlichungsabsicht bleibt paketgetaggt und explizit. public/cms/package-boundary.json ist das erste paketeigene veröffentlichbare Asset und kann über webblocks-cms-assets veröffentlicht werden.
• Das Paketverzeichnis public/cms/ enthält jetzt auch die öffentlichen Layout-CSS- und JS-Dateien, die vom verschobenen paketeigenen öffentlichen Layout verwendet werden; die aktuellen Root-Asset-URLs unter public/cms/... bleiben jedoch aus Kompatibilitätsgründen in der aktiven Laufzeit maßgeblich, während install-eigene public/site/...-Assets für Site-spezifische Overrides maßgeblich bleiben.
• Das Paketverzeichnis public/cms/ darf keine index.php enthalten; der CMS-Admin-Einstieg ist /webadmin, keine Front-Controller-Brücke aus dem statischen Asset-Verzeichnis.
• Das WebBlocks-UI-CDN-Pinning und die Standardquelle für die Icon-Manifest-Synchronisierung bleiben in dieser Phase unverändert.

• Das Paketverzeichnis stubs/ sollte wiederverwendbaren Vorlagen für generierte Dateien vorbehalten sein, die zum CMS-Produktverhalten gehören.
• Installations- oder projektspezifisches Scaffolding sollte standardmäßig nicht in die CMS-Paket-Stubs verschoben werden.
• Starter-orientierte Stubs liegen jetzt unter dem Paketverzeichnis stubs/starter/; das aktuelle Installer-Verhalten und das Root-Projekt-Scaffolding bleiben jedoch maßgeblich, bis ein dediziertes Starter-Paket sie gezielt übernimmt.

• webblocks-cms-config ist dafür reserviert, paketeigene CMS-Standard-Konfigurationsdateien in das Installations-Root zu veröffentlichen, wenn ein Entwickler diesen Workflow gezielt benötigt.
• webblocks-cms-assets veröffentlicht paketeigene öffentliche CMS-Assets in den aktiven Laufzeit-Kompatibilitätspfad unter public/cms.
• webblocks-cms-stubs veröffentlicht paketeigene Starter-Stubs.
• Diese Tags ändern das Laufzeitverhalten nicht von sich aus und bleiben inaktiv, bis vendor:publish explizit ausgeführt wird.

• Das langfristige Ziel bleiben Composer-verwaltete Paket-Updates, gefolgt von kontrollierten Laufzeitschritten.
• Erwartete Schritte nach dem Update können später Migrationen, Blocktyp-Synchronisierung, Cache-Leerung oder das Veröffentlichen bzw. Synchronisieren von Assets umfassen, jedoch nur, wenn diese paketeigenen Ressourcen real werden und bewusst angebunden sind.
• Das kanonische Release-Artefakt ist jetzt das Paket-Root selbst, nicht mehr das Root des Wartungs-Repositorys. Update-ZIPs sind gültig, wenn das Archiv-Root oder ein einzelnes Wrapper-Verzeichnis auf oberster Ebene das von fklavyenet/webblocks-cms erwartete Layout aus Paket-composer.json, src/, config/, resources/, database/, routes/ und public/ enthält.
• Die alte root-verwaltete Updater-Archivform ist für moderne paketnative Updates bewusst ausgemustert. Sie bleibt nur als explizites Brücken-Artefakt für Installationen vor der paketnativen Umstellung wie 1.31.53 gültig, deren Updater paketbasierte ZIPs noch nicht validieren kann.
• Paketbasierte Release-Metadaten müssen einen brückenfähigen Updater voraussetzen (minimum_client_version von 1.32.18 oder neuer). Ältere Installationen sollten zuerst die kompatible Brücke erhalten und das moderne paketbasierte Artefakt erst verwenden, nachdem die Brücke paketnativen Validierungs- und Anwendungscode installiert hat.
• Während der aktuellen Übergangsphase bleibt die Root-Laravel-Anwendung installationseigen und führt Wartungsmodus, Migrationen, Seeder, Sync-Befehle, Cache-Leerungen und die Persistenz der installierten Version weiterhin vom Installations-Root aus.
• In-App-Updates wenden das validierte Paket-Artefakt jetzt auf packages/webblocks-cms/ an und, wenn der Composer-Autoload zeigt, dass die aktive Consumer-Laufzeit WebBlocks\Cms\ weiterhin aus vendor/fklavyenet/webblocks-cms/... lädt, auf das passende sichere Vendor-Paket-Laufzeit-Root. Sie überschreiben nicht die installationseigene Root-Hülle, Root-Konfigurations-Overrides, Root-Migrationen, project/, storage/, .env oder public/site/.
• Root-verwaltete Brückenarchive sind keine Lockerung der modernen Validierung. Ein Brückenarchiv muss die alte Form aus artisan plus Root-composer.json ausschließlich für die Kompatibilität mit Legacy-Clients beibehalten und muss Updater-Code installieren, der anschließend die strikte paketbasierte fklavyenet/webblocks-cms-Form durchsetzen kann.
• Der Boundary-Completion-Checkpoint v1.31.65 hält dies nur als Zielnotiz fest. Das aktuelle Root-Composer-Verhalten und der Laufzeit-Update-Ablauf bleiben maßgeblich, bis der erste reale paketeigene Laufzeitabschnitt existiert.

Angestrebter Installationsablauf, sobald die Paket-Starter-Aufteilung bereit ist:

• composer require fklavyenet/webblocks-cms
• das Laravel-Root auf Installationsebene bleibt verantwortlich für .env, das Root-composer.json, storage/, installationseigene Konfigurations-Overrides und alle installationsspezifischen project/-Anpassungen, die während der Übergangsphase noch existieren
• die Paketerkennung sollte WebBlocks\Cms\WebBlocksCmsServiceProvider laden
• Paketdiagnosen wie webblocks:package-status sollten die Paketbereitschaft bestätigen, ohne den Zustand zu verändern

Angestrebter Update-Ablauf, sobald Composer-verwaltete Paket-Updates maßgeblich werden:

• composer update fklavyenet/webblocks-cms
• Migrationen ausführen
• Caches leeren, wo nötig
• Paket-Assets nur veröffentlichen oder synchronisieren, wenn reale Paket-Assets dies erfordern
• Paketdiagnosen wie webblocks:package-status ausführen
• den Zustand der installierten Version nur synchronisieren, wenn das Update einer realen Release-Grenze entspricht
• explizite Katalogreparatur separat ausführen, wenn ausgelieferte Katalogzeilen Wartung benötigen

Aktuelle Kompatibilitätsregel:

• heute sind diese Notizen zum Installations- und Update-Ablauf ausschließlich Zielzustandsdokumentation
• das aktuelle Root-Composer-Verhalten, das Installer-Verhalten und das In-App-System-Update-Verhalten bleiben maßgeblich, bis eine spätere dedizierte Update-Ablauf-Phase sie bewusst ändert

• Die langfristige Richtung bleibt ein separates Starter-Projekt, das von fklavyenet/webblocks-cms als Paket abhängt.
• Das aktuelle Paket im Repository existiert, um Grenzen und Eigentümerschaft festzulegen, bevor diese Aufteilung versucht wird.
• Die Starter-Aufteilung sollte erst erfolgen, nachdem die verbleibenden Root-Grenzen neu gestaltet wurden: die Install-/Auth-/Profil-Laufzeit, das app-eigene User-Modell, die Root-Migrationshoheit, die operative Root-Update-/Install-Hoheit und der aktive Root-Laufzeit-Asset-Pfad public/cms.

• Verschieben Sie jeweils einen Ressourcentyp von der reservierten Grenze in aktive Paket-Eigentümerschaft.
• Beginnen Sie erst, wenn die genaue Laufzeit-Laderegel, die Install-Override-Strategie und das Veröffentlichungs-/Update-Verhalten für diesen Ressourcentyp geklärt sind.
• Bevorzugen Sie fokussierte Phasenpläne wie Paket-Views, Paket-Migrationen oder öffentliche Paket-Assets, statt mehrere Laufzeit-Ressourcentypen in einem Checkpoint zu mischen.
• Halten Sie laufzeitlastige Quellcode-Verschiebungen hinter dedizierten Abhängigkeitsprüfungen, statt sie in die Pilotarbeit an Ressourcengrenzen einzubetten.

Verlagern Sie das Update-Verhalten in Richtung Composer-verwalteter CMS-Paket-Updates plus kontrollierter Schritte nach dem Update wie Migrationen, Cache-Leerung und Asset-Veröffentlichung oder -Synchronisierung bei Bedarf. Die Katalogreparatur bleibt ein expliziter Operator-Wartungs-Workflow statt eines standardmäßigen Update-Schritts.

Der aktuelle Bereitschafts-Checkpoint umfasst jetzt:

• Paket-Composer-Autoload für WebBlocks\Cms\Database\Seeders\
• beibehaltene Root-Path-Repository-Entwicklungsanbindung an packages/webblocks-cms
• explizite Dokumentation, dass das aktuelle Root-System-Update-Verhalten maßgeblich bleibt, bis eine spätere dedizierte Update-Ablauf-Phase es bewusst ändert

Führen Sie die Richtung eines separaten Starter-Projekts ein, etwa fklavyenet/webblocks-cms-starter, damit neue Installationen von einem benutzereigenen Laravel-Root ausgehen, das vom CMS-Paket abhängt, statt das CMS-Core-Repository in das Projekt-Root zu klonen.

Der aktuelle Checkpoint fügt nur Grundlagen für die Grenzbereitschaft dieser zukünftigen Aufteilung hinzu:

• mehr CMS-eigene Seeder liegen jetzt unter dem Paket statt im Root-App-Namespace
• mehr risikoarme Laufzeit-Support-Helfer liegen jetzt unter Paket-src/Support/
• Root-app/-Kompatibilitäts-Wrapper werden standardmäßig nicht mehr beibehalten; PHP-Wrapper mit Paket-Gegenstück wurden entfernt, während Root-Blade-, Seeder- und Laufzeit-Asset-Kompatibilitätspfade dort verbleiben, wo sie noch benötigt werden
• Paket-Composer-Metadaten, Provider-Erkennung, Path-Repository-Entwicklungsanbindung und der dokumentierte Ziel-Ablauf mit composer require oder composer update bilden jetzt die Bereitschaftsbasis für das Starter-Fundament

Bestehende Installationen benötigen einen konservativen Migrationspfad:

• aktuelle Installationen funktionsfähig halten, solange die Paketumstellung unvollständig ist
• große Ein-Schritt-Verschiebungen vermeiden, die Laufzeit-Refactorings mit Packaging-Änderungen mischen
• installationsspezifische Root-Dateien als benutzereigenen Projektzustand bewahren
• nicht länger auf den root-weiten Austausch von CMS-Core-Dateien als Update-Mechanismus setzen
• klare Anleitung zum Entfernen veralteter root-verwalteter CMS-Core-Dateien einführen, sobald deren paketeigene Ersatzdateien existieren

Die Übergangsphase sollte risikoarme, inkrementelle Bewegung gegenüber einem einzigen Rewrite priorisieren.

Die Konsolidierung der Paketumstellung ist für sämtlichen sicher verschiebbaren CMS-eigenen Quellcode in diesem Repository abgeschlossen.

• Die paketeigene Hoheit deckt jetzt die sicher verschiebbaren CMS-Domänen für Routen, Views, Modelle, Seeder, geteilte Partials, Admin-Layout und unterstützenden Laufzeit-Quellcode ab.
• Root-App\...-Klassen mit Paket-Gegenstück wurden aus dem App-Baum des Wartungs-Repos entfernt; Root-Blade-Dateien, Root-Seeder und Root-public/cms/...-Laufzeitkopien bleiben bewusst als Kompatibilitäts-Wrapper oder Kompatibilitätspfade bestehen.
• Aktive Laufzeit-Asset-URLs verwenden weiterhin Root-public/cms/...-Kompatibilitätspfade, selbst wo passende paketeigene Quelldateien unter packages/webblocks-cms/public/cms/... existieren.
• Die verbleibenden letzten Grenzen sind die Install-/Auth-/Profil-Laufzeit, das app-eigene User-Modell, die Root-Migrationshoheit, die operative Root-Update-/Install-Hoheit und das zukünftige Starter-Split-Design.
• Wegen dieser Blocker ist das Paket noch nicht bereit für die Starter-Aufteilung, obwohl die sichere Konsolidierung des CMS-eigenen Quellcodes abgeschlossen ist.

Diese Repository-Änderung ist nur der erste risikoarme Übergangsschritt:

• sie fügt Architekturdokumentation hinzu
• sie erstellt das Paket-Skelett im Repository unter packages/webblocks-cms/
• sie fügt ein minimales Paket-composer.json hinzu
• sie fügt einen WebBlocks\Cms\WebBlocksCmsServiceProvider hinzu
• sie verdrahtet das Root-Projekt so, dass es das Paket lokal per Pfad einbindet

Der Provider definiert jetzt den Paket-Bootstrap-Vertrag für zukünftige Paketressourcen, aber diese Paketressourcen sind noch nicht maßgeblich, weil die aktuellen CMS-Laufzeitdateien weiterhin in der Root-Anwendung liegen.

Der v1.31.62-Pilot macht diese Paketressourcen-Grenzen konkreter, indem er explizite reservierte Grenzmarkierungsdateien unter Paket-routes/, resources/views/, database/migrations/, public/ und stubs/ hinzufügt. Diese Verzeichnisse existieren jetzt als dokumentierte paketeigene Ziele für spätere Phasen, aber ihr Inhalt bleibt in diesem Checkpoint weiterhin ein nicht maßgeblicher Platzhalter.

Der v1.31.63-Pilot bringt nur die Grenze des Paket-View-Namespace voran, indem er eine reale interne Diagnose-Blade-View unter Paket-resources/views/diagnostics/package-status.blade.php und eine optionale schreibgeschützte Render-Probe webblocks:package-status --view-check hinzufügt. Das belegt das namespace-basierte Laden von Paket-Views mit einer konkreten paketeigenen View, während die aktive Auflösung der Root-Admin- und Public-Views maßgeblich bleibt.

Der v1.31.64-Pilot bringt nur die Paket-Routen-Grenze voran, indem er eine reale Paket-Diagnose-Routendatei unter Paket-routes/diagnostics.php hinzufügt, während das Laden der Routen im normalen Betrieb explizit per Guard deaktiviert bleibt. Das belegt die Eigentumsgrenzen für Paket-Routendateien, ohne aktive Root-Admin- oder Public-Routen zu verschieben.

Der v1.31.65-Checkpoint schließt die verbleibenden inerten Grenz-Piloten ab, indem Paket-Migrationen explizit per Guard deaktiviert bleiben, bestätigt wird, dass die Veröffentlichung öffentlicher Paket-Assets und Stubs inert bleibt, bis reale paketeigene Dateien existieren, und Composer-verwaltete Paket-Updates als Zielgrenze dokumentiert werden, ohne den aktuellen Root-Update-Ablauf zu ändern.

Das Release v1.32.0 beginnt diese geplante Verschiebung mit den abgesicherten Laufzeit-Migrationsphasen 1-2:

• der Paket-Diagnose-Laufzeitabschnitt ist über einen Paket-Controller plus die vorhandene Paket-Diagnose-View durchgängig real und paketeigen, bleibt aber standardmäßig per Guard deaktiviert
• ein fokussierter Admin-Laufzeitabschnitt ist jetzt über Paket-routes/admin.php, src/Http/Controllers/Admin/PackageAdminStatusController.php und resources/views/admin/runtime-status.blade.php durchgängig paketeigen, bleibt aber auf einem reservierten Pfad standardmäßig per Guard deaktiviert
• ein fokussierter Public-Laufzeitabschnitt ist jetzt über Paket-routes/public.php, src/Http/Controllers/Public/PackagePublicStatusController.php und resources/views/public/runtime-status.blade.php durchgängig paketeigen, bleibt aber auf einem reservierten Pfad standardmäßig per Guard deaktiviert
• webblocks:package-status meldet jetzt den Diagnose-Laufzeitabschnitt, den Paket-Admin-Abschnitt, den Paket-Public-Abschnitt und die expliziten Routen-Guards weiterhin schreibgeschützt
• Root-Routen und Root-Views bleiben für die bestehende CMS-Laufzeit außerhalb dieser reservierten, rein paketbezogenen abgesicherten Pfade maßgeblich
• Paket-config/webblocks-cms.php besitzt jetzt explizite Übergangs-Konfigurationswerte: Diagnosen, Public-Status-Routen, Admin-Status-Routen und das Laden von Paket-Migrationen bleiben standardmäßig deaktiviert, während das Laden der Paket-Admin-Routen für die aktive paketeigene Admin-Routen-Hoheit aktiviert ist

Die folgenden historischen Checkpoint-Notizen beschreiben, wie die Paket-Hoheit eingeführt wurde. Wo sie Root-App\...-Wrapper erwähnen, ersetzt die aktuelle umfassende Root-App-Bereinigung diesen Zustand: PHP-Wrapper mit Paket-Gegenstück fehlen jetzt absichtlich, sofern sie nicht im oben beschriebenen aktuellen Root-App-Bereinigungszustand aufgeführt sind.

Der aktuelle Checkpoint zu Schritt 1 (Laufzeit-Hoheit) erweitert diese Grenze weiter:

• aktive CMS-Admin-Routen laden jetzt aus Paket-routes/admin.php, während Root-routes/web.php auf das Laden von Install-, Auth-, Profil- und Kompatibilitätsrouten reduziert ist
• aktive CMS-Public-Routen laden jetzt aus Paket-routes/public.php, einschließlich Startseite, lokalisierter Startseite, Suche, lokalisierter Suche, Such-JSON, Seitenanzeige, lokalisierter Seitenanzeige, Kontaktübermittlungen, Privacy-Consent-Synchronisierung und admin-api.*
• paketeigene Public-Controller stützen diesen öffentlichen Einstiegsabschnitt jetzt unter packages/webblocks-cms/src/Http/Controllers/Public/
• das paketeigene ContactMessageRequest und paketeigene öffentliche Einstiegs-Views stützen jetzt die verschobenen Public-Routen-Einstiegspunkte
• Root-App\Http\Controllers\PageController, PublicSearchController, ContactMessageController, PublicPrivacyConsentController und App\Http\Requests\ContactMessageRequest wurden später als redundante Wrapper mit Paket-Gegenstück entfernt
• Root-Modelle und Support-Klassen verbleiben nur dort, wo sie host-eigene oder explizite Übergangsdomänen bedienen; Users, Install/Profil/Auth, Root-Laufzeitpfade für Public-/Admin-Assets, Migrationen und das System-Update-Verhalten bleiben Grenzen, weshalb das Paket ohne tiefere Extraktion noch nicht als vollständig unabhängige Starter-Laufzeit dienen kann

Der aktuelle Checkpoint zu Schritt 2 (Public-Rendering) erweitert die Paket-Hoheit hinter diesen bereits paketeigenen Public-Routen weiter:

• die Paketdatei resources/views/layouts/public.blade.php besitzt jetzt die aktive öffentliche Layout-Hülle unter dem Namespace webblocks-cms::
• die Paketdateien resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php sowie die Paketdateien pages/partials/slot*.blade.php besitzen jetzt die aktive öffentliche Seiten-Hülle, die öffentliche Such-Hülle, das öffentliche Such-Modal und die Rendering-Schicht für Slot-Einträge
• die Root-Dateien resources/views/layouts/public.blade.php, resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php, resources/views/pages/partials/slot.blade.php und resources/views/pages/partials/block.blade.php verbleiben jetzt nur noch als Kompatibilitäts-Wrapper, die auf die paketeigenen Namespace-Views verweisen
• die paketeigene Unterstützung für das öffentliche Rendering umfasst jetzt PageRouteResolver, PublicPagePresenter, PublicSharedSlotResolver, SlotWrapperResolver, SiteAssetResolver, PublicSearchQuery, PublicOverlayRegistry, PublicBodyEndRegistry, TrustedHtmlOverlayExtractor, SiteResolver, ResolvedSite und VisitorEventLogger
• die Root-Klassen App\Support\... für diese Belange des öffentlichen Renderings wurden später entfernt, nachdem Paket-Interna und Routen sie nicht mehr benötigten
• das Paketverzeichnis resources/views/pages/partials/blocks/* besitzt jetzt den vollständigen mitgelieferten Partial-Baum des öffentlichen Block-Renderers als ein zusammenhängendes Paket-Batch
• die Root-Dateien resources/views/pages/partials/blocks/ verbleiben jetzt als dünne Kompatibilitäts-Wrapper, die an die passenden webblocks-cms::pages.partials.blocks.-Views delegieren
• Block::publicRenderView() löst mitgelieferte Kern-Blocktypen jetzt zuerst zu paketeigenen Namespace-Block-Partials auf, während installationsspezifische oder benutzerdefinierte Root-Block-Renderer über den bestehenden Root-Fallback-Pfad weiterhin verfügbar bleiben, wenn kein passendes Paket-Partial existiert
• das öffentliche Modellfundament lebt jetzt unter dem Paketverzeichnis src/Models/; die passenden Root-Wrapper App\Models\... wurden später entfernt, nachdem Paket- und Fresh-Consumer-Tests belegt hatten, dass sie unnötig waren
• Page, PageTranslation, PageSlot und Block leben jetzt ebenfalls unter dem Paketverzeichnis src/Models/, ohne passende Root-Wrapper
• User bleibt bewusst app- und root-eigen und ist nicht Teil des Migrationsziels für Paketmodelle
• das Paketverzeichnis public/cms/ enthält jetzt die aktiven öffentlichen Laufzeit-CSS- und JS-Dateien, die von der verschobenen paketeigenen öffentlichen Layout- und Block-Rendering-Schicht benötigt werden, und vendor:publish --tag=webblocks-cms-assets veröffentlicht diese echten Paket-Assets jetzt in den Root-Kompatibilitätspfad public/cms
• die aktive Laufzeit liefert public/cms/... aus Kompatibilitätsgründen weiterhin aus der Root-Installation aus, wobei Installation und System Update die paketeigenen CMS-Assets in diesen Pfad auffrischen
• die Root-Migrationen bleiben maßgeblich für quellgepflegte Checkouts mit dem expliziten Root-Composer-Autoload-Signal, während paketnative System Updates die Migrationen der Host-Laravel-Anwendung überspringen und nur dedizierte Paket-Update-Migrationen ausführen, sofern vorhanden
• System Update, Installationsablauf, Backup oder Restore und die breitere Laufzeit der Projektschicht bleiben in diesem Batch unverändert
• die Validierung als Consumer- oder Starter-Paket ist nach diesem Checkpoint weiterhin nicht realistisch, weil die Laufzeit noch von Root-Migrationen, Root-Kompatibilitäts-Asset-Pfaden, root-eigenen Admin- sowie Installations-/Update-Abläufen und der bewusst app-eigenen Root-Modellgrenze User abhängt

Der aktuelle Checkpoint der Site- und Locale-Admin-Laufzeit verschiebt eine weitere zusammenhängende Admin-Scheibe hinter den paketeigenen Admin-Routenbaum:

• paketeigene Controller übernehmen jetzt die Site-Verwaltung, die Site-Domain-Verwaltung, die Site-Variable-Verwaltung und die Locale-Verwaltung unter packages/webblocks-cms/src/Http/Controllers/Admin/
• paketeigene Form Requests, die Modelle SiteLocale und SiteVariable sowie die direkt unterstützenden Site- oder Locale-Support-Services leben jetzt unter dem Paketverzeichnis src/, ohne passende Root-Wrapper App\...
• die Paketverzeichnisse resources/views/admin/sites/, resources/views/admin/sites/domains/, resources/views/admin/domains/ und resources/views/admin/locales/ besitzen jetzt die aktiven Blade-Bäume der Site-, Domain- und Locale-Verwaltung über den Namespace webblocks-cms::
• die Root-Blade-Dateien für Site, Domain und Locale verbleiben jetzt als dünne Kompatibilitäts-Wrapper, die die passenden paketeigenen Views rendern
• dieses Batch verschiebt bewusst keine Migrationen, Installations-/Update-Abläufe, Backup/Restore, Auth-/Profil-/User-Eigentum, Root-Config-Eigentum oder die Autorität über public/cms-Assets

Die paketeigene Standardkonfiguration hat jetzt für webblocks-updates begonnen, während die Root-Config-Datei während des Übergangs weiterhin als Installations-Override maßgeblich bleibt.

Die paketeigene Standardkonfiguration hat jetzt auch für contact begonnen, während die Root-Config-Datei während des Übergangs weiterhin als Installations-Override maßgeblich bleibt.

Die paketeigene Standardkonfiguration hat jetzt auch für demo_media begonnen, während die Root-Config-Datei während des Übergangs weiterhin als Installations-Override maßgeblich bleibt.

Die paketeigene Standardkonfiguration hat jetzt auch für cms begonnen, während die Root-Config-Datei während des Übergangs weiterhin als Installations-Override maßgeblich bleibt.

Der paketeigene Konsolen-Bootstrap ist jetzt auch über den schreibgeschützten Diagnosebefehl webblocks:package-status nachgewiesen.

Der Paket-View-Namespace webblocks-cms ist jetzt ebenfalls sicher als Pilot für die Paketgrenze registriert, und v1.31.63 belegt diesen Namespace mit einer echten paketeigenen Diagnose-View. Die aktive Root-View-Auflösung bleibt weiterhin maßgeblich, weil keine aktiven Admin- oder öffentlichen Views der CMS-Laufzeit in das Paket verschoben wurden.

Die Paket-Routengrenze ist jetzt ebenfalls mit einer echten paketeigenen Diagnose-Routendatei nachgewiesen, aber die aktive Root-Auflösung der Admin- und öffentlichen Routen bleibt maßgeblich, weil die Paket-Diagnoserouten im normalen Laufzeitbetrieb per Guard deaktiviert bleiben und keine aktiven Root-Routendateien in das Paket verschoben wurden.

Die Grenzen für Paket-Migrationen, öffentliche Assets und Stubs sind jetzt ebenfalls ausdrücklich als inerte, reservierte Piloten abgeschlossen, und die Composer-verwaltete Update-Flow-Grenze ist jetzt nur als Zielrichtung dokumentiert. Es wurden noch keine aktiven Root-Migrationen, öffentlichen Root-Assets, Root-Stub-Verhalten oder Root-Update-Flow-Verhalten in die Paketautorität überführt.

Die erste paketeigene Verschiebung von PHP-Quellcode ist jetzt für SearchTextNormalizer abgeschlossen, verschoben von app/Support/Search/ in das Paketverzeichnis src/Support/Search/, bei unverändertem Verhalten.

Die Search-Support-Grenze bleibt in dieser Phase bewusst schmal: SearchTextNormalizer und das kleine Ergebnis-Wertobjekt PublicSearchRebuildResult sind jetzt paketeigen, während die Suchindizierung und die Abfrage-Orchestrierung root-eigen bleiben, bis ihre DB- und Laufzeitabhängigkeiten gezielt migriert werden.

Das erste Support-Audit außerhalb von Search ist jetzt ebenfalls dokumentiert: MediaKindResolver, DatabaseExecutionStrategyResolver, SiteHandle und SiteDomainNormalizer wurden geprüft, und keine weitere Klasse wurde verschoben, weil jede noch mindestens eine aktuelle Risikogrenze der frühen Phase überschreitet.

Die erste Verschiebung von Contact-Support-Quellcode ist jetzt ebenfalls für ContactMessageNotificationResult abgeschlossen, verschoben von app/Support/Contact/ in das Paketverzeichnis src/Support/Contact/, bei unverändertem Verhalten, während der Notifier-Service und der Contact-Laufzeitablauf root-eigen bleiben.

Die erste Verschiebung von BlockTypes-Support-Quellcode ist jetzt ebenfalls für BlockTypeContract abgeschlossen, verschoben von app/Support/BlockTypes/ in das Paketverzeichnis src/Support/BlockTypes/, bei unverändertem Verhalten, während die Registry, der Admin-Contract-Modal-Pfad und der Audit-Befehl root-eigen bleiben.

LayoutMarkup wurde jetzt ebenfalls als mögliche schmale Verschiebung eines Pages-Helfers geprüft und bleibt vorerst root-eigen, weil seine aktuellen Referenzen noch die Request-Validierung des Seitenlayouts, das Rendern von Admin-Formularen und das öffentliche Slot-Wrapper-Verhalten durchqueren.

Die erste Verschiebung von Formatting-Support-Quellcode ist jetzt ebenfalls für InlineRichTextRenderer abgeschlossen, verschoben von app/Support/Formatting/ in das Paketverzeichnis src/Support/Formatting/, bei unverändertem Verhalten, während SafeRichTextRenderer und sein Sanitisierungsvertrag root-eigen bleiben.

Der nächste risikoarme Laufzeit-Support-Checkpoint ist jetzt ebenfalls abgeschlossen, für vier schmale Helfer, die nah an den Belangen von Admin-Abfragezustand und Paginierung bleiben:

• AdminPagination lebt jetzt im Paketverzeichnis src/Support/Admin/
• BlockTypeIndexState lebt jetzt im Paketverzeichnis src/Support/BlockTypes/
• MediaIndexState lebt jetzt im Paketverzeichnis src/Support/Media/
• PageIndexState lebt jetzt im Paketverzeichnis src/Support/Pages/
• die Root-Wrapper App\Support\... für diese Helfer wurden später entfernt; die Paket-Importe sind maßgeblich

Die erste paketeigene Verschiebung der Seeder-Grenze ist jetzt ebenfalls für risikoarme Kataloge abgeschlossen:

• jetzt paketeigen: IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder
• jetzt ebenfalls paketeigen: CoreCatalogSeeder als Grenzverschiebung des Katalog-Aggregators
• die Root-Klassen Database\Seeders\... verbleiben als Kompatibilitäts-Wrapper
• CoreCatalogSeeder hält die Root-Einstiegspunkte weiterhin stabil, indem er über den Root-Wrapper delegiert und dabei die root-eigenen PageLayoutSeeder und BlockTypeSeeder weiter aufruft
• PageLayoutSeeder, BlockTypeSeeder und das aktive System-Update-Seeding bleiben bis zu einer späteren fokussierten Phase root-eigen

Das nächste isolierte paketeigene Laufzeit-Batch ist jetzt ebenfalls für die Icon-Katalog-Verwaltung abgeschlossen:

• jetzt paketeigen: SyncWebBlocksUiIconsCommand, IconCatalogController, IconCatalogItemUpdateRequest, IconCatalog und WebBlocksIconManifestSyncer
• die Root-Klassen App\Http\Controllers\Admin\IconCatalogController, App\Http\Requests\Admin\IconCatalogItemUpdateRequest, App\Support\Icons\... und App\Console\Commands\SyncWebBlocksUiIconsCommand wurden später als redundante Paket-Gegenstück-Wrapper entfernt
• die aktiven Admin-Routen des Icon-Katalogs zeigen jetzt direkt auf den Paket-Controller, und icons:sync-webblocks-ui wird jetzt vom Paket-Service-Provider mit der Paket-Befehlsklasse registriert
• die aktiven Admin-Routendefinitionen des Icon-Katalogs leben jetzt in der Paketdatei routes/admin.php statt in der Root-Datei routes/web.php
• die Root-PHP-Wrapper des Icon-Katalogs sind nicht mehr verfügbar; die aktive Routen- und Konsolenautorität liegt im Paket
• jetzt ebenfalls paketeigen: die aktiven Blade-Views für die Admin-Indexseite und das Bearbeitungs-Modal des Icon-Katalogs unter packages/webblocks-cms/resources/views/admin/system/icons/
• die Root-Blade-Dateien des Icon-Katalogs verbleiben als Kompatibilitäts-Wrapper, die die Paket-Namespace-Views einbinden, aber der Paket-Controller rendert webblocks-cms::admin.system.icons.index direkt
• dieses Batch bleibt ausschließlich beim Belang der Icon-Katalog-Verwaltung und -Synchronisierung und verschiebt bewusst kein breiteres Laufzeit-Eigentum an Pages, Blocks, Suchindizierung, Sites, Updates, Install, Backup oder Restore, Export oder Import oder öffentlichem Rendering
• webblocks:package-status meldet jetzt als Teil der schreibgeschützten Übergangsdiagnose die paketeigenen Icon-Laufzeitdateien und das Fehlen passender Root-PHP-Wrapper

Das nächste größere Extraktions-Batch der Admin-Laufzeit ist jetzt ebenfalls für die zentralen redaktionellen und Katalog-Verwaltungsoberflächen abgeschlossen:

• die Paketdatei routes/admin.php ist jetzt nicht nur für die Icon-Katalog-Verwaltung maßgeblich, sondern auch für die aktiven Admin-Routen-Handler von Pages, Blocks, Media, Shared Slots, Navigation, Block Types und Page Layouts
• jetzt paketeigen: die maßgeblichen Admin-Controller für diese Scheiben unter packages/webblocks-cms/src/Http/Controllers/Admin/
• jetzt paketeigen: die maßgeblichen Admin-Form-Requests für diese Scheiben unter packages/webblocks-cms/src/Http/Requests/Admin/
• jetzt paketeigen: die unterstützenden Services für Block, Medien, Navigation, Seite, Seitenlayout und Shared Slot unter packages/webblocks-cms/src/Support/
• jetzt paketeigen: die aktiven Admin-Blade-Bäume unter packages/webblocks-cms/resources/views/admin/blocks/, admin/media/, admin/navigation/, admin/block-types/, admin/pages/, admin/shared-slots/, admin/page-layouts/ und admin/page-layout-slots/
• die Root-PHP-Wrapper App\Http\Controllers\Admin\..., App\Http\Requests\Admin\... und App\Support\... für diese verschobenen Scheiben wurden später als redundante Paket-Gegenstück-Wrapper entfernt
• die Root-Dateien resources/views/admin/... für diese verschobenen Bäume verbleiben jetzt als Kompatibilitäts-Wrapper, die die passenden webblocks-cms::admin.*-Views einbinden
• eine Ausnahme bleibt bewusst konkret im Root: resources/views/admin/blocks/types/partials/rich-text-editor.blade.php behält weiterhin das echte Markup, weil die Kompatibilitätsabdeckung diese Root-Datei direkt liest, statt sie nur über den Paket-Namespace aufzulösen
• dieses Batch verschiebt bewusst nicht Users, Backups, Updates, Systemeinstellungen, den Installationsablauf, Migrationen, Root-Laufzeit-Asset-Pfade oder das app-eigene Modell User
• webblocks:package-status sowie die fokussierte Bootstrap-Abdeckung melden jetzt die breiteren paketeigenen Admin-Laufzeitdateien und dass passende Root-PHP-Wrapper fehlen

Das fokussierte operative Admin-Laufzeit-Batch ist jetzt ebenfalls paketeigen:

• paketeigene Controller übernehmen jetzt das Dashboard, die Admin-Prüfoberfläche für Contact Messages, die Visitor-Reports-Oberfläche und die Status- bzw. Rebuild-Oberfläche der System Search unter packages/webblocks-cms/src/Http/Controllers/Admin/
• der paketeigene Support-Layer umfasst jetzt auch den Abfrageservice für Besucherberichte und den leichtgewichtigen Statushelfer für das öffentliche Suchschema; die vollständige Such-Indexierungsarchitektur und das Verhalten des Befehls search:rebuild bleiben hinter Root-Kompatibilitätseinstiegspunkten unverändert
• die Paketdateien resources/views/admin/dashboard.blade.php, admin/contact-messages/*, admin/reports/visitors/index.blade.php und admin/system/search.blade.php besitzen jetzt über den Namespace webblocks-cms:: die aktiven operativen Admin-Blade-Oberflächen
• die Root-Controller-, Support- und Blade-Dateien dieser operativen Oberflächen bleiben als dünne Kompatibilitäts-Wrapper bestehen
• dieser Batch verschiebt bewusst nicht System Update, System Backup, Backup/Restore, Site-Export/-Import, Site-Promotion, den Installer, die auth/profile/User-Zuständigkeit, Migrationen, die Root-Konfigurationszuständigkeit oder die Root-Asset-Hoheit unter public/cms

Die verbleibende sichere Folgearbeit an den aktiven operativen Routen ist jetzt ebenfalls abgeschlossen:

• paketeigene Controller übernehmen jetzt auch Slot Types und System Settings unter packages/webblocks-cms/src/Http/Controllers/Admin/
• die paketeigenen Requests umfassen jetzt auch SystemSettingsRequest unter packages/webblocks-cms/src/Http/Requests/Admin/
• die Paketdateien resources/views/admin/slot-types/index.blade.php und resources/views/admin/system/settings.blade.php besitzen jetzt über den Namespace webblocks-cms:: die aktiven Blade-Oberflächen
• die Root-Klassen App\Http\Controllers\Admin\SlotTypeController, App\Http\Controllers\Admin\SystemSettingsController, App\Http\Requests\Admin\SystemSettingsRequest und die zugehörigen Root-Blade-Dateien bleiben als Kompatibilitäts-Wrapper bestehen
• diese Folgearbeit verschiebt weiterhin bewusst nicht die System-Update-Implementierung, Backup oder Restore, den Installer, die auth/profile/User-Zuständigkeit, Migrationen, die Root-Konfigurationszuständigkeit oder die Laufzeit-Asset-Hoheit unter dem Root-Pfad public/cms

Der Status der Admin-Shell und der Asset-Grenze ist:

• paketeigene Admin-Views erweitern webblocks-cms::layouts.admin, und der Root-Kompatibilitäts-Wrapper resources/views/layouts/admin.blade.php wurde entfernt, sodass Namespace-Fehler von Paketkonsumenten lokal sofort fehlschlagen
• das Paketverzeichnis public/cms/ enthält außerdem Admin-CSS- und JS-Quelldateien, die dem aktiven Root-Admin-Asset-Bestand entsprechen, während die Root-Pfade public/cms/... die aktive Laufzeit-Kompatibilitätsschicht bleiben
• Migrationen, Updater, Backup/Restore, Export/Import, Promotion, auth/User, Installer, Root-Konfiguration und die Laufzeit-Asset-Hoheit bleiben außerhalb der unmittelbaren Paket-Grenze der Admin-Shell

Die ausgewählten Batches gemeinsamer Admin-Partials/-Komponenten sind jetzt paketeigen:

• jetzt paketeigen: webblocks-cms::admin.partials.page-header, flash, listing-filters, page-actions, pagination und audit-actor
• jetzt paketeigen: webblocks-cms::components.admin.form-actions, aus Paket-Views über <x-webblocks-cms::admin.form-actions> eingebunden
• jetzt paketeigen: webblocks-cms::layouts.admin, aus paketeigenen Admin-Views über @extends('webblocks-cms::layouts.admin', ...) eingebunden
• die Root-Dateien resources/views/admin/partials/{page-header,flash,listing-filters,page-actions,pagination,audit-actor}.blade.php bleiben als Kompatibilitäts-Wrapper bestehen
• die Root-Datei resources/views/layouts/admin.blade.php existiert nicht mehr; Plugin- und Paket-Admin-Views dürfen den historischen Pfad layouts.admin nicht verwenden
• die Root-Datei resources/views/components/admin/form-actions.blade.php bleibt als Kompatibilitäts-Wrapper für die bestehende Verwendung von <x-admin.form-actions> erhalten
• paketeigene Admin-Views bevorzugen jetzt für das Admin-Layout und die ausgewählten gemeinsamen Partials/Komponenten den Paket-Namespace
• webblocks:package-status meldet jetzt die Grenze der ausgewählten gemeinsamen Admin-Partials/-Komponenten sowie das Admin-Laufzeit-View-Inventar, das nun das paketeigene Admin-Layout und den Root-Wrapper einschließt
• die Root-Admin-Asset-URLs und die Laufzeit-Hoheit unter public/cms, Markenassets, die auth/profile/install/app/guest-Grenzen, Migrationen, der Updater, Backup/Restore sowie Release-/Versionsarbeiten bleiben unverändert

Der Paketgrenzen-Durchlauf in v1.32.15 fügt ein statisches Release-Gate-Audit für paketeigene Admin-Laufzeitreferenzen hinzu:

• das Audit durchsucht packages/webblocks-cms/src/*/.php, packages/webblocks-cms/resources/views/*/.blade.php und packages/webblocks-cms/routes/*/.php
• es schlägt bei rein Root-bezogenen Admin-Referenzen fehl, etwa view('admin.'), View::make('admin.'), response()->view('admin.'), @include('admin.'), @includeIf('admin.'), @extends('layouts.admin'), <x-admin., <x-auth-password-field, component('admin.') und direkten admin.blocks.types.-Root-Block-Admin-Referenzen
• die einzigen akzeptierten Ausnahmen sind exakte Datei-und-Muster-Allowlist-Einträge, bei denen die Paketlaufzeit zuerst den Namen webblocks-cms::... prüft und den Root-Namen nur als expliziten Kompatibilitäts-Fallback für bestehende installationsspezifische Overrides verwendet

Der erste risikoarme Quell-Checkpoint für Helfer und Value Objects gilt für diese Phase jetzt als erfolgreich und abgeschlossen. Auch die lokale Entwicklungsumgebung wurde nach v1.31.60 erfolgreich aktualisiert, was bestätigt, dass die aktuelle Paketverdrahtung in der gepflegten Entwicklungsumgebung funktioniert.

Weitere opportunistische, risikoarme PHP-Quellverschiebungen sind jetzt pausiert. Künftige laufzeitlastige Quellverschiebungen erfordern einen dedizierten, fokussierten Phasenplan und ein Abhängigkeitsaudit statt weiterer kleiner opportunistischer Migrationen.

Diese Arbeit verschiebt noch keinen bestehenden CMS-Laufzeitcode, ändert nicht das Verhalten von System Update, erstellt kein Starterprojekt und ändert nicht die aktuell aktiven Laufzeit-Zuständigkeitsgrenzen.

Schritt 1 hat die aktive CMS-Routenhoheit für die Admin- und die öffentliche Laufzeit in das Paket verschoben, ebenso den öffentlichen Routen-Einstiegsteil für Seiten-, Such-, Kontaktnachricht- und Datenschutz-Einwilligungsanfragen. Der nächste Batch sollte den größten verbleibenden Bereich doppelter Zuständigkeit hinter dieser Paket-Routenhoheit reduzieren, statt einen weiteren engen Pilotversuch zu starten.

Modelle, die eine unabhängige Paketlaufzeit noch blockieren:

• vorerst Root-eigen mit dokumentierter Paketabhängigkeit: Admin-Content-Modelle wie BlockType, Media, SharedSlot, PageAsset, PageLayout, PageRevision, NavigationItem, SiteExport und SiteImport
• paketeigen mit Root-Kompatibilitäts-Wrappern: Locale, Site, SiteDomain, SiteLocale, SiteVariable, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent und SystemSetting
• voraussichtlich bald paketfähig als enge Folgearbeit zu einem bereits paketeigenen Teilbereich: IconCatalogItem
• sollte App-eigen bleiben: User

View-Grenzen, die eine unabhängige Paketlaufzeit noch blockieren:

• das öffentliche Paket-Layout, die Seiten-Shell, die Such-Shell, das Such-Modal, die Slot-Eintrags-Views und der mitgelieferte öffentliche Block-Renderer-Partial-Baum sind jetzt über den Namespace webblocks-cms:: maßgeblich
• das Root-Verzeichnis resources/views/pages/partials/blocks/* bleibt bewusst als Kompatibilitäts-Wrapper-Schicht bestehen, damit installationsspezifische Root-Block-Renderer und direkte Root-View-Referenzen während des Übergangs weiter funktionieren
• das Paket-Admin-Rendering ist jetzt für admin/pages/, admin/blocks/, admin/shared-slots/, admin/media/, admin/navigation/, admin/block-types/, admin/page-layouts/, admin/page-layout-slots/, admin/sites/, admin/domains/ und admin/locales/* über den Namespace webblocks-cms:: maßgeblich, während die zugehörigen Root-Blade-Dateien als Kompatibilitäts-Wrapper bestehen bleiben
• das Root-Admin-Rendering bleibt für die noch nicht verschobenen Bildschirme maßgeblich, insbesondere für die install/auth/profile-Wrapper und App-eigene User-Sonderfälle, während das Paket-Rendering für die aktiven Admin-Bildschirme für Site-Transfer und Promotion über webblocks-cms:: maßgeblich ist

Support- und Service-Grenzen, die eine unabhängige Paketlaufzeit noch blockieren:

• für den öffentlichen Rendering-Teil jetzt paketeigen: Routenauflösung, Seitenpräsentation, Shared-Slot-Präsentation, Slot-Wrapper-Auflösung, Extraktion vertrauenswürdiger HTML-Overlays, öffentliche Overlay- oder Body-End-Registries, Orchestrierung öffentlicher Suchabfragen, öffentliche Site-Auflösung, Site-Asset-Auflösung und Besucher-Event-Protokollierung
• erst nach den Modellverschiebungen verschieben: die verbleibenden Schichten von Pages oder PublicRendering, Blocks, Such-Indexierung, Navigation, SharedSlots oder Revisions, die noch direkt auf Root-Modellen oder breiteren Admin-Abläufen aufsetzen
• vorerst Root-eigen belassen: Media, Sites-Portabilitätsabläufe, Formatting-Bereinigung, Admin- oder Audit-Helfer
• sollte Install-Root-eigen bleiben: Install, System oder Updates, Backup oder Restore, Writer für installierte Version und Umgebung

Blocker bei Requests, Befehlen, Assets, Migrationen und dem Update-Ablauf:

• viele Admin-Form-Requests können später mit Root-Wrappern verschoben werden, sobald die zugehörigen Batches für Seiten, Blöcke, Shared Slots, Medien, Sites und Navigation verschoben sind
• viele redaktionelle Admin-Form-Requests sind inzwischen bereits mit Root-Wrappern verschoben, aber System-, Site-Portabilitäts-, Update-, Backup-, Install- und andere betriebsorientierte Requests bleiben weiterhin Root-eigen
• die vom Paket genutzten Befehle für Update, Backup, Import, Export, Promotion und den Installer sollten ausdrücklich abgegrenzt bleiben, weil sie weiterhin von Umgebungs-, Dateisystem-, Archiv-, Composer-, Migrations- und Installationsstatus-Verhalten abhängen
• die Root-Assets unter public/cms/* bleiben die aktiven maßgeblichen Laufzeitpfade, auch wenn das Paketverzeichnis public/cms/ jetzt ebenfalls die verschobenen CSS- und JS-Dateien des öffentlichen Layouts enthält und sie über webblocks-cms-assets veröffentlichen kann
• Root-Migrationen bleiben maßgeblich für quellgepflegte Checkouts mit Root-Composer-Autoload-Hoheit des Wartungs-Repositorys; paketnative frische Konsumenten, die mit webblocks:install installiert wurden, dürfen während des System Updates keine Migrationen der Host-Laravel-Anwendung ausführen
• der WebBlocks UI Manager wird nicht mehr innerhalb der CMS-Paketlaufzeit ausgeliefert. Sein Quellcode liegt für Wartungs-Builds unter plugins/webblocks-ui-manager, und Betreiber installieren ihn manuell als Plugin-ZIP, wenn sie WebBlocks-UI-Release-/CDN-Workflows benötigen.
• die Plugin-Paketreife aus Phase 5 hält plugineigene Klassen, Views, Routen, Befehle, Konfiguration, Einstellungs-Namespaces und Datenbankpräfixe den Plugin-Handles zuordenbar; deaktivierte oder inkompatible Plugins bleiben inert und werden nicht zu CMS-Kernverantwortlichkeiten
• System Updates von Paketkonsumenten führen nur dedizierte paketeigene Update-Migrationen aus vendor/fklavyenet/webblocks-cms/database/migrations/updates aus, sofern vorhanden, und überspringen andernfalls die Migrationsausführung, ohne beliebige Host-Migrationen als ausgeführt zu markieren
• System Update bleibt eine eigene Phase, weil seine Blocker Umgebungsmutation, Dateisystem-Schreibzugriffe, Composer-Ausführung, Backups, Migrationen, Persistenz der installierten Version und der operative Root-Zustand sind — nicht die Routen- oder Controller-Zuständigkeit

• Sichere Konsolidierung CMS-eigener Quellen: abgeschlossen
• Verbleibende Inversionsbereinigung der verschobenen Helfer: abgeschlossen (WebBlocks\Cms\Support\Blocks\BlockTranslationWriter und CoreBlockTypeCatalogSyncer besitzen jetzt die Implementierung; die Root-Klassen unter App\Support\Blocks\... bleiben nur als Kompatibilitäts-Wrapper bestehen)
• Konsolidierung der aktiven Laufzeit-Asset-URLs: bewusst unvollständig; der Root-Pfad public/cms/... bleibt der Kompatibilitäts-Laufzeitpfad
• Bereitschaft für die Starter-Aufteilung: nicht bereit
• Verbleibende finale Grenzen: die install/auth/profile-Laufzeit, das App-eigene User-Modell, die Root-Migrationshoheit, die Root-Update-/Installationshoheit und das künftige Design der Starter-Aufteilung

Empfohlener Batch: Führen Sie eine fokussierte Modell-/Support-Kompatibilitätsbereinigung für bereits paketeigene Laufzeitbereiche durch, oder starten Sie den nächsten Durchlauf zur Admin-Asset- und Markenstrategie, jetzt da das Admin-Layout sowie die Admin-CSS- oder JS-Quelldateien paketeigen sind. Behalten Sie die aktive Root-Hoheit über die Admin-Assets unter public/cms bei, bis die Admin-Asset-Strategie explizit festgelegt ist.

In diesem Checkpoint abgeschlossener Umfang:

• öffentliche Shell- und Seiten-Views: layouts.public, pages.show, search.show und search/partials/modal
• die Rendering-Partials für Seiten-Slot-Einträge unter resources/views/pages/partials/slot*.blade.php
• die mitgelieferten öffentlichen Block-Renderer-Partials unter resources/views/pages/partials/blocks/*
• der öffentliche Rendering-Support-Layer für Routenauflösung, öffentliche Seitenpräsentation, Shared-Slot-Präsentation, Slot-Wrapper-Auflösung, Extraktion vertrauenswürdiger HTML-Overlays, Overlay-Registries, Orchestrierung von Suchabfragen, Site-Auflösung, Site-Asset-Auflösung und Besucher-Event-Protokollierung
• Root-Kompatibilitäts-Wrapper an den Stellen, an denen Routen-, Controller-, Request- oder View-Referenzen noch rückwärtskompatible Root-Einstiegspunkte benötigen

Bewusst aus diesem Batch zurückgestellter Umfang:

• paketeigene Eloquent-Modellextraktion für Locale, Site, SiteDomain, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent und SystemSetting
• maßgebliche Paket-Laufzeit-Asset-URLs und der Veröffentlichungsablauf
• Neugestaltung der Root-Migrationshoheit
• Extraktion von System Update und dem Install-/Update-Ablauf

Warum dieser Batch als Nächstes ansteht:

• die Paket-Hoheit über Admin-Routen, Controller, Requests, Support und Views existiert jetzt bereits über die großen Admin-Laufzeitbereiche hinweg
• die ausgewählten gemeinsamen Admin-Partials/-Komponenten und ihre engen Sonderfälle sind jetzt verschoben, sodass größere Shell-/Asset-Grenzen übrig bleiben
• das paketeigene Admin-Layout und die paketeigenen Admin-CSS- oder JS-Quelldateien stützen sich weiterhin auf das aktive Laden von Root-Laufzeit-Assets und Markenressourcen, daher sollte der nächste Schritt eine bewusste Admin-Asset- und Markenstrategie sein statt einer weiteren Shell-Verschiebung
• die nächste hochwertige Extraktionsarbeit besteht darin, verbleibende Modell-/Support-Kompatibilitätsannahmen zu reduzieren oder die Admin-Asset-/Markenstrategie zu entwerfen, ohne in Migrationen, Updater, Backup/Restore, Export/Import, Promotion, auth/User, Installer, Root-Konfiguration oder Asset-Hoheit einzusteigen

• Site-Portabilitäts-Batch: Export oder Import plus Promotion sollten warten, bis ihre Archiv-, Backup- und Transfergrenzen explizit auditiert sind
• Migrationen, aktive Laufzeit-Assets, Installer, Backup/Restore, auth/User und System Update müssen separate dedizierte Phasen bleiben

Fallback-Batch: eine fokussierte Bereinigung der verbleibenden Modell-/Support-Kompatibilität für bereits paketeigene Laufzeitbereiche.

Dies ist nur dann der Fallback, wenn die gemeinsamen Partials eine unerwartete Kopplung an auth, Updater, Backup oder Installation offenlegen, die das dünne Root-Wrapper-Muster für einen kleinen Implementierungs-Batch zu unruhig macht.