Transición de la arquitectura de paquete

WebBlocks CMS se distribuye actualmente como una aplicación Laravel gestionada desde la raíz, donde los archivos del núcleo del CMS residen directamente en la raíz de la instalación junto a los archivos de aplicación propiedad del usuario. Ese modelo hace que las actualizaciones sean frágiles, porque el código de producto del CMS y el código de proyecto específico de la instalación comparten el mismo sistema de archivos de nivel superior.

Cuando las actualizaciones del CMS se aplican reemplazando o copiando archivos gestionados desde la raíz, no se garantiza que los archivos del núcleo eliminados en el origen desaparezcan de las instalaciones derivadas. Un archivo del núcleo eliminado pero obsoleto puede permanecer en la raíz de la instalación, seguir siendo autocargado o renderizado por Laravel y anular de forma silenciosa el comportamiento más reciente distribuido. Esta es exactamente la clase de problema confirmada recientemente por un archivo Blade obsoleto en la raíz de una instalación derivada.

La arquitectura actual también mantiene las actualizaciones del CMS estrechamente acopladas al estado de Git y a la sincronización de archivos en toda la raíz. Eso dificulta razonar sobre los límites de propiedad, preservar de forma segura la personalización específica de la instalación y hacer que las actualizaciones sean predecibles en las instalaciones existentes.

La arquitectura objetivo es un paquete de Laravel gestionado con Composer:

• Nombre del paquete: fklavyenet/webblocks-cms
• Ruta de instalación: vendor/fklavyenet/webblocks-cms
• Fuente de verdad canónica del paquete instalado: vendor/fklavyenet/webblocks-cms

En el modelo objetivo, el código del núcleo del CMS se instala y se actualiza como un paquete normal de Composer en lugar de copiarse en la raíz del proyecto Laravel propiedad del usuario.

Esto significa:

• el código fuente PHP del CMS pertenece a src/ del paquete
• los recursos del paquete Laravel permanecen en config/, database/, resources/, routes/, public/ y stubs/ a nivel de paquete
• src/ no es el lugar al que deba ir cada archivo del paquete
• la raíz Laravel propiedad del usuario debería ser dueña de app/, config/, database/, public/site/, resources/, routes/, storage/ y composer.json

System Update debe alinearse con esta disposición de paquete de Composer. En los consumidores nativos de paquete instalado, el actualizador aplica artefactos de versión con raíz en el paquete a vendor/fklavyenet/webblocks-cms; no debe mantener packages/webblocks-cms como una segunda copia de ejecución activa y actualizada. Un árbol packages/webblocks-cms pertenece únicamente a copias de trabajo de desarrollo mantenidas desde el código fuente o a restos heredados de la transición.

Cuando una instalación heredada del vendor de Composer tiene forma de repositorio, System Update normaliza vendor/fklavyenet/webblocks-cms a la raíz plana del paquete. Tras la normalización, src/, docs/, routes/, resources/, database/, public/, config/ y stubs/ residen directamente bajo vendor/fklavyenet/webblocks-cms; los restos de la raíz del repositorio, como artisan, app/, bootstrap/, packages/, plugins/ y tests/, se eliminan del reemplazo de la raíz del paquete.

project/ puede permanecer temporalmente como capa de compatibilidad durante la transición, pero no debería seguir siendo el modelo de personalización obligatorio a largo plazo para el comportamiento específico de la instalación.

La dirección prevista para el proyecto inicial es un starter de Laravel independiente, como fklavyenet/webblocks-cms-starter, en el que la raíz del proyecto propiedad del usuario compone el paquete del CMS en lugar de incrustar directamente todos los archivos del núcleo del CMS.

La preparación del paquete para consumidores ya ha comenzado, pero es intencionadamente parcial y explícita:

• los consumidores con una instalación Laravel nueva pueden instalar el paquete y ejecutar webblocks:install
• el paquete utiliza una ruta de migración específica para instalaciones nuevas en los consumidores limpios, en lugar de repetir toda la cadena histórica de migraciones de la raíz
• las migraciones del paquete del repositorio de mantenimiento siguen desactivadas por guarda e inertes de forma predeterminada
• App\Models\User sigue siendo el límite temporal de autenticación del consumidor en v1.32.8
• el instalador del paquete parchea App\Models\User automáticamente con un trait del paquete y escribe antes una copia de seguridad con marca de tiempo
• el inicio de sesión, el cierre de sesión, el aviso de instalación, la protección del administrador, la página de inicio pública, las vistas y los recursos propiedad del paquete ya son suficientes para la primera ruta limpia de consumidor
• esto sigue sin ser un repositorio starter independiente y todavía no elimina el límite de User propiedad de la aplicación

El árbol real de la aplicación consumidora de Composer puede ser mínimo mientras el tiempo de ejecución del CMS se carga desde vendor/fklavyenet/webblocks-cms. El repositorio de mantenimiento refleja ahora ese límite con mayor fidelidad: el app/ de la raíz ya no conserva de forma predeterminada envoltorios equivalentes a los del paquete.

Categorías de envoltorios eliminadas:

• comandos de consola equivalentes a los del paquete, salvo ProjectInitCommand, propiedad del host
• controladores de administración y públicos del CMS y middleware equivalente al del paquete cuyas rutas ahora apuntan a clases del paquete, salvo el middleware de redirección de instalación del shell de mantenimiento
• form requests de administración y públicos equivalentes a los del paquete
• mailables equivalentes a los del paquete
• modelos del CMS equivalentes a los del paquete
• clases de soporte equivalentes a las del paquete en los dominios de bloques, medios, páginas, sitios, sistema, actualizaciones, búsqueda, visitantes y transferencia/promoción operativa

Elementos que siguen siendo intencionadamente propiedad de la raíz o están aplazados:

• app/Models/User.php, el Controller.php base y los service providers siguen siendo archivos del shell de Laravel propiedad del host.
• los archivos de autenticación, perfil e instalación, incluido el middleware de redirección de instalación, siguen siendo propiedad del host hasta que el límite de starter/instalación se rediseñe de forma deliberada.
• la autenticación, el perfil, la instalación y la capa de proyecto siguen siendo límites del host o de la transición.
• los shims heredados de recursos Asset, AssetFolder, BlockAsset y App\Support\Assets\... se han eliminado; los modelos de medios y las clases de soporte del paquete son ahora la superficie autorizada de ejecución y de pruebas.
• App\Support\WebBlocks se ha eliminado; la configuración, las vistas y las pruebas de la raíz utilizan ahora WebBlocks\Cms\Support\WebBlocks como fuente de identidad y versión del producto.
• los directorios vacíos de app/ en la raíz equivalentes a los del paquete se eliminan en lugar de mantenerse como marcadores de transición.
• las migraciones de la raíz, las sobrescrituras de configuración, el public/cms de ejecución, los envoltorios de compatibilidad Blade de la raíz y los envoltorios de seeders de la raíz quedan fuera de esta limpieza.

La limpieza mejora la transición del paquete y la preparación del starter, porque el repositorio de mantenimiento prueba ahora la misma suposición de aplicación mínima que un consumidor nuevo del paquete. Aun así, no deja el repositorio totalmente listo como starter: la instalación/autenticación, User, la autoridad de migraciones de la raíz, la autoridad operativa de actualización/instalación de la raíz y las rutas de compatibilidad de recursos de ejecución de la raíz siguen siendo los bloqueadores finales.

El flujo de actualización a largo plazo debería estar gestionado por Composer y el paquete, y ser agnóstico respecto a Git.

La arquitectura de actualización objetivo es:

• sin copia de archivos del núcleo del CMS en toda la raíz
• el núcleo del CMS instalado y actualizado mediante paquetes de Composer
• pasos controlados de actualización en tiempo de ejecución tras la actualización del paquete, incluidas las migraciones
• limpieza de caché cuando sea necesario
• reparación explícita del catálogo como flujo de trabajo de mantenimiento del operador independiente cuando haga falta
• publicación o sincronización controlada de recursos solo cuando sea realmente necesario

Esto mantiene los archivos de la raíz propiedad de la instalación separados de los archivos del núcleo del CMS propiedad del paquete y evita que los archivos del núcleo del CMS eliminados permanezcan indefinidamente en las instalaciones derivadas simplemente porque en algún momento existieron en la raíz.

El paquete de Composer y el repositorio de mantenimiento son consumidores de recursos estáticos, no anfitriones de una cadena de compilación de frontend. WebBlocks CMS no debe distribuir ni requerir Vite, el plugin Vite de Laravel, Tailwind, npm, Node, archivos de bloqueo de paquetes, public/build, public/hot ni hooks de ejecución @vite para los recursos propiedad del CMS.

Los recursos propiedad del CMS pertenecen a public/cms en la raíz para el tiempo de ejecución de mantenimiento y a packages/webblocks-cms/public/cms del paquete para los artefactos de versión. WebBlocks UI sigue siendo un proyecto de interfaz aguas arriba consumido mediante recursos publicados y fijados por versión, y WebBlocks UI Manager sigue siendo el plugin de operador de primera parte para los flujos de trabajo de publicación de versiones y CDN. No traslade la compilación del código fuente de WebBlocks UI, los scripts de compilación de npm, la generación de dist ni las suposiciones sobre el archivo hot al núcleo del CMS ni a su paquete de versión.

Rutas objetivo del CMS propiedad del paquete:

• packages/webblocks-cms/src/ durante la fase de transición dentro del repositorio
• más adelante vendor/fklavyenet/webblocks-cms/src/ en los entornos instalados
• config/ del paquete
• database/ del paquete
• resources/ del paquete
• routes/ del paquete
• public/ del paquete
• stubs/ del paquete

Rutas objetivo de la raíz del proyecto propiedad del usuario:

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

Esta división mantiene la propiedad de la aplicación Laravel en la instalación mientras la propiedad del producto CMS se traslada al paquete.

Las instalaciones del CMS orientadas a paquete deben preservar los límites de la aplicación anfitriona cuando el CMS se instala junto a otro producto Laravel. El CMS debería evitar colisiones de rutas, configuración, vistas y tablas con la aplicación anfitriona, y no debe dar por supuesto que la ruta /admin de la aplicación anfitriona pertenece al CMS.

El prefijo canónico de administración del CMS es /webadmin, y un prefijo configurable sigue siendo la dirección objetivo para dar más flexibilidad a la coexistencia futura. El inicio de sesión propiedad del anfitrión y las decisiones de autorización propiedad del CMS se documentan en Coexistence. Los recursos estáticos del CMS permanecen bajo public/cms y se sirven desde /cms/....

Cuando las rutas de autenticación del CMS propiedad del paquete están activas, /webadmin/login forma parte del límite del paquete. Su superficie Blade debe permanecer bajo el espacio de nombres de vistas webblocks-cms::, utilizar el shell de autenticación de invitado de WebBlocks UI, cargar el CSS/JS fijado de WebBlocks UI junto con /cms/css/guest.css y resolver los recursos de marca y logotipo del producto desde /cms/brand. Los recursos de marca del producto CMS deben proporcionar variantes normal, para superficie oscura, sobre color de acento/inversa y de alto contraste para el favicon y la pestaña del navegador, de modo que el contraste de la autenticación y del shell del producto se resuelva con recursos explícitos en lugar de con filtros CSS.

Los prefijos de rutas de administración no deben reutilizar segmentos físicos de directorios de recursos públicos. El prefijo de administración retirado /cms colisionaba con el directorio de recursos activo public/cms, porque try_files de Nginx puede resolver /cms/ como un directorio antes de que Laravel reciba la ruta. Por ello, la arquitectura de paquete actual mantiene /webadmin/... para la administración del CMS y las rutas de inicio de sesión del paquete, reserva /cms/... únicamente para recursos estáticos y prohíbe los alias /cms, las redirecciones /cms y las rutas /admin propiedad del CMS restauradas. El antiguo traspaso public/cms/index.php no forma parte del límite del paquete y debe seguir ausente tanto de los recursos públicos de la raíz como de los del paquete.

Presente el plan de arquitectura de paquete y cree un esqueleto de paquete dentro del repositorio sin mover todavía el código de ejecución. El comportamiento de la aplicación raíz permanece sin cambios.

Añada el service provider del paquete y el cableado de Composer con ruta local para que el paquete exista como una unidad instalable real dentro del repositorio. Mantenga la lógica de arranque intencionadamente mínima y evite cambiar el comportamiento en ejecución.

Refine el service provider del paquete para que defina el contrato de arranque de los futuros recursos propiedad del paquete sin convertir todavía esos recursos en autoritativos.

En esta fase, el provider puede preparar con seguridad la carga protegida y el registro de publicación de config/, routes/, resources/views/, database/migrations/, public/ y stubs/ del paquete, pero solo cuando existan archivos reales del paquete.

El comportamiento actual en ejecución de la raíz sigue sin cambios porque el esqueleto del paquete solo contiene marcadores de posición. Hasta que los archivos de ejecución se muevan realmente al paquete en fases posteriores, la aplicación Laravel de la raíz sigue siendo la fuente autoritativa de las rutas, vistas, configuración, migraciones y recursos públicos activos del CMS.

La primera ruta de configuración predeterminada propiedad del paquete ya ha comenzado con config/webblocks-updates.php del paquete. Durante la transición, ese archivo del paquete proporciona los valores predeterminados propiedad del CMS, mientras que el config/webblocks-updates.php existente en la raíz se mantiene como archivo de configuración de la aplicación, sobrescritura a nivel de instalación y compatible con versiones anteriores.

Los archivos actuales de config/ en la raíz se dividen en dos grupos de transición.

Candidatos a valores predeterminados del producto CMS:

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

Configuración propiedad de la aplicación Laravel o de la instalación que debería seguir siendo de la raíz:

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

La regla de transición actual, de bajo riesgo, consiste en mover la configuración predeterminada propiedad del CMS solo cuando se preserve un comportamiento estable del producto y una semántica clara de sobrescritura por parte de la instalación. El conjunto de valores predeterminados propiedad del paquete incluye ahora webblocks-cms.php, cms.php, contact.php, demo_media.php y webblocks-updates.php. Los archivos de configuración de la raíz para el comportamiento existente del CMS se mantienen durante la transición como sobrescrituras a nivel de instalación y puntos de entrada de configuración de la aplicación compatibles con versiones anteriores. webblocks-cms.php es por ahora exclusivo del paquete y es dueño de los controles de transición: las rutas de diagnóstico, las rutas públicas de estado, las rutas de estado del administrador y la carga de migraciones del paquete permanecen desactivadas de forma predeterminada, mientras que la carga de rutas de administración del paquete está habilitada para que las rutas de administración propiedad del paquete puedan volverse autoritativas.

Comience a mover el código fuente PHP propiedad del CMS a src/ del paquete en porciones pequeñas y revisables, actualizando los espacios de nombres y el arranque del service provider solo a medida que cada área trasladada esté lista.

El arranque de consola del paquete también está ahora demostrado mediante el comando de diagnóstico de solo lectura webblocks:package-status. Ese comando es propiedad del paquete, se registra únicamente en contextos de consola e informa de la presencia del arranque del paquete sin modificar archivos, el estado de la base de datos, la caché, la configuración ni el estado de actualización.

El primer traslado de código fuente PHP debería seguir criterios igual de conservadores: propiedad del CMS, pequeño, fácil de razonar, sin dependencia de la base de datos ni de Eloquent, sin dependencia de controladores ni de requests, y con actualizaciones de referencias acotadas. La primera clase trasladada es SearchTextNormalizer, un ayudante puro de texto de búsqueda ahora propiedad de src/Support/Search/ del paquete.

Límite actual del soporte de búsqueda:

• ahora propiedad del paquete: SearchTextNormalizer, PublicSearchRebuildResult, PublicSearchIndexer, PublicSearchQuery, PublicSearchSchema, SearchablePageResolver, BlockSearchTextExtractorRegistry y ReindexesPublicSearch
• actualmente ninguna clase de soporte de Search necesita seguir siendo propiedad de la raíz por motivos específicos del proyecto; el shim raíz App\Support\Search\ReindexesPublicSearch se ha eliminado

Límite actual de la auditoría de Support ajeno a Search:

• en este paso de la auditoría no se ha trasladado ningún otro helper de Support ajeno a Search, porque ninguno de los candidatos revisados cumplía los criterios actuales de bajo riesgo para pasar a propiedad del paquete
• MediaKindResolver es pequeño y determinista, pero actualmente depende de constantes de App\Models\Media y se referencia desde una ruta de controlador, por lo que todavía no es lo bastante independiente para esta fase
• DatabaseExecutionStrategyResolver sigue siendo propiedad de la raíz por ahora, porque afecta directamente a la estrategia de ejecución de volcado o restauración de la base de datos, a la inspección del entorno y a la seguridad en tiempo de ejecución de la copia de seguridad o la restauración
• SiteHandle sigue siendo propiedad de la raíz por ahora, porque lo utilizan modelos, requests y los flujos de transferencia o clonación de sitios, de modo que moverlo ahora cruzaría demasiado pronto los límites de enrutamiento, portabilidad y persistencia
• SiteDomainNormalizer sigue siendo propiedad de la raíz por ahora, porque todavía lo utilizan modelos, requests, la resolución de rutas y las migraciones, lo que confirma la evaluación de riesgos anterior

Límite del soporte de Contact:

• ahora propiedad del paquete: ContactMessageNotificationResult
• propiedad de la raíz por ahora: ContactMessageNotifier, porque todavía es responsable de las llamadas de transporte de correo, de la interacción con el modelo de contacto y de la resolución de destinatarios basada en configuración
• ContactMessageNotificationResult se pudo mover con seguridad porque es un objeto de resultado inmutable y diminuto, sin acoplamiento a modelos, base de datos, requests, configuración, correo, migraciones ni cargas serializadas, y solo requería actualizar una referencia acotada en el notifier

Límite del soporte de tipos de bloque:

• ahora propiedad del paquete: BlockTypeContract
• propiedad de la raíz por ahora: BlockTypeContractRegistry, porque todavía depende de los modelos de bloque, de las definiciones de sincronización del catálogo, del comportamiento del registro de traducciones, de la inspección de rutas de recursos y de los flujos de auditoría o administración de la raíz que consumen esos contratos resueltos
• BlockTypeContract se pudo mover con seguridad porque es un pequeño DTO de contrato con estado establecido solo en el constructor, más una serialización a array determinista, y sin acoplamiento a modelos, base de datos, requests, configuración, efectos secundarios de comandos, migraciones ni cargas serializadas

Límite del marcado de layout de página:

• propiedad de la raíz por ahora: LayoutMarkup
• LayoutMarkup no se movió en este paso porque, aunque no tiene estado y es pequeño, lo utilizan directamente los form requests de layout de página, la lógica del gestor de layouts de página, la resolución del wrapper de slots públicos y un formulario Blade de administración; moverlo ahora cruzaría los límites de validación de requests y de renderizado público dentro del área más amplia de Pages o PublicRendering, que sigue siendo intencionadamente propiedad de la raíz

Límite del soporte de formato:

• ahora propiedad del paquete: InlineRichTextRenderer
• propiedad de la raíz por ahora: SafeRichTextRenderer, porque todavía es responsable del contrato de saneamiento de HTML más rico, del comportamiento de etiquetas permitidas, de las reglas de análisis del DOM y de la semántica de renderizado público de texto enriquecido
• InlineRichTextRenderer se pudo mover con seguridad porque es un formateador pequeño y determinista, sin acoplamiento a modelos, base de datos, requests, configuración, migraciones ni cargas serializadas, y solo requería actualizar una referencia acotada en Blade y en las pruebas unitarias

Mapa de migración de las fuentes de Support:

• Search: propiedad del paquete para el soporte de tiempo de ejecución actual, incluido el trait de reindexación que utilizan los modelos del paquete. Los shims raíz App\Support\Search\... no deben restaurarse.
• Formatting: candidato tras aislar dependencias. InlineRichTextRenderer ya es propiedad del paquete como helper de formato de bajo riesgo, mientras que SafeRichTextRenderer sigue siendo propiedad de la raíz porque define el comportamiento de saneamiento de mayor riesgo.
• BlockTypes: candidato tras aislar dependencias. BlockTypeContract es un pequeño objeto de valor, pero el espacio de nombres está anclado por BlockTypeContractRegistry, por rutas de administración y por un comando de auditoría de consola en la raíz.
• BlockTypes: candidato tras aislar dependencias. BlockTypeContract ya es propiedad del paquete como traslado acotado de un objeto de valor, pero el espacio de nombres sigue anclado por BlockTypeContractRegistry, por rutas de administración y por un comando de auditoría de consola en la raíz.
• Media and Assets: los modelos de medios y las clases de soporte propiedad del paquete son la referencia autorizada para los shims heredados de assets ya eliminados. El trabajo restante en medios debe evitar restaurar los wrappers raíz Asset, AssetFolder, BlockAsset o App\Support\Assets\....
• Pages and PublicRendering: propiedad de la raíz hasta una fase de migración específica. Estas clases controlan la resolución de rutas, la selección de layout, los assets de página, los wrappers de slots, los presenters públicos, la duplicación o importación de páginas y el comportamiento de renderizado público, con acoplamiento a modelos y requests en todo el recorrido.
• Pages and PublicRendering: propiedad de la raíz hasta una fase de migración específica. LayoutMarkup se revisó como posible excepción, pero sigue siendo propiedad de la raíz porque continúa apoyándose directamente en los requests de layout de página, en la resolución de wrappers de slot y en el renderizado de vistas de administración, aunque su propia lógica no tenga estado.
• Blocks: propiedad de la raíz hasta una fase de migración específica. Esta área es responsable de las escrituras de payload de bloque, de la persistencia de traducciones, del borrado de bloques, de la sincronización del catálogo, de la extracción de HTML de confianza y de los registros públicos con ámbito de request, que se apoyan directamente en la persistencia de bloques y en los contratos del renderizador.
• SharedSlots and Revisions: propiedad de la raíz hasta una fase de migración específica. Estas clases dependen de árboles de bloques, tablas de revisiones, comprobaciones de esquema, filas de traducción y la semántica de restauración o instantánea.
• Sites, Sites\\ExportImport y SitePromotion: propiedad de la raíz hasta una fase de migración específica. Estas áreas están fuertemente acopladas a modelos, enrutamiento, portabilidad, archivos comprimidos, cargas serializadas de transferencia, flujos de clonación o borrado, copias de seguridad de seguridad en la promoción y resolución de sitios públicos.
• System and System\\Updates: propiedad de la raíz hasta una fase de migración específica. Estas clases son responsables de la persistencia de ajustes, del estado de la versión instalada, de la copia de seguridad o restauración, de la validación de SQL, del flujo de descarga o extracción de actualizaciones y de la estrategia de ejecución de la base de datos.
• Install and ProjectLayer: no mover todavía. Estas clases tocan el flujo del instalador, las escrituras en .env, la carga de rutas o proveedores, las comprobaciones del estado de instalación y los límites de personalización de la raíz del proyecto.
• Navigation, Locales, Users, Visitors, Contact and Icons: candidatos tras aislar dependencias. Cada grupo contiene algunos helpers u objetos de resultado más pequeños, pero las implementaciones actuales todavía dependen de modelos, autenticación, correo, inspección de esquema, peticiones HTTP o comportamiento en tiempo de ejecución respaldado por ajustes.
• Navigation, Locales, Users, Visitors, Contact and Icons: candidatos tras aislar dependencias. ContactMessageNotificationResult ya es propiedad del paquete como traslado acotado de un objeto de valor, mientras que los grupos restantes todavía dependen de modelos, autenticación, correo, inspección de esquema, peticiones HTTP o comportamiento en tiempo de ejecución respaldado por ajustes.
• Admin, Audit and Database: candidatos tras aislar dependencias. AdminPagination, CurrentActorResolver y DestructiveDatabaseCommandGuard son pequeños, pero cada uno sigue colgando de los ajustes, la autenticación o los hooks de seguridad de la aplicación en la raíz.
• WebBlocks: WebBlocks\Cms\Support\WebBlocks, propiedad del paquete, es ahora la fuente de identidad y de versión del producto tanto para los consumidores del paquete como para la raíz del repositorio de mantenimiento.

Nota sobre el punto de control de fuentes de la fase 2:

• los primeros traslados de helpers y objetos de valor de bajo riesgo se completaron correctamente hasta v1.31.60
• el entorno de desarrollo local cableado con el paquete se actualizó correctamente después de v1.31.60, lo que confirma que el punto de control sigue siendo compatible con el flujo de trabajo local mantenido
• los traslados oportunistas de fuentes PHP de bajo riesgo están ahora intencionadamente en pausa
• no continúe moviendo clases con mucha carga de tiempo de ejecución sin un plan de fase específico y una auditoría de dependencias

Bloqueos actuales para los grupos de mayor riesgo:

• acoplamiento directo con App\Models\... o con consultas Eloquent en Search, Pages, Blocks, Sites, Navigation, Locales, Icons, Visitors y System
• acoplamiento a requests, rutas, controladores o vistas en Admin, Pages, PublicRendering, Formatting y algunos helpers de BlockTypes
• comprobaciones de esquema, de forma de las migraciones o de existencia de tablas en Search, SharedSlots, Revisions, Visitors, Install y System
• acoplamiento a configuración, entorno, HTTP, correo, sistema de archivos, procesos, copias de seguridad, actualizaciones y tiempo de ejecución local en Contact, Icons, Install, System y Updates
• acoplamiento a cargas de archivo o transferencia serializadas en Sites\\ExportImport, SitePromotion, la importación de páginas y los helpers de compatibilidad de assets heredados

Mueva a las carpetas de recursos Laravel del paquete la configuración, las rutas, las vistas, las migraciones, los seeders, los assets públicos y los stubs que son claramente propiedad del paquete. Introduzca el comportamiento de carga y publicación del paquete de forma incremental, no todo a la vez.

La porción actual de seeders de la fase 3 cubre ahora el límite de los seeders de catálogo propiedad del paquete, además de su agregador propiedad del paquete:

• ahora propiedad del paquete: CoreCatalogSeeder, IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder, en packages/webblocks-cms/database/seeders/
• los puntos de entrada de compatibilidad de la raíz permanecen en database/seeders/ para que las instalaciones existentes, las pruebas y los puntos de entrada actuales de tiempo de ejecución o de actualización puedan seguir llamando a Database\Seeders\...
• el CoreCatalogSeeder propiedad del paquete sigue siendo únicamente un cambio de propiedad: continúa delegando en PageLayoutSeeder y BlockTypeSeeder, propiedad de la raíz, y el DatabaseSeeder raíz actual, junto con los puntos de entrada de actualización, siguen llamando al wrapper de compatibilidad de la raíz
• siguen siendo propiedad de la raíz por ahora: PageLayoutSeeder, BlockTypeSeeder, DatabaseSeeder y los comandos activos posteriores a la instalación de System Update
• en esta fase, la propiedad de los seeders por parte del paquete se refiere únicamente a la migración de espacios de nombres y de límites, no a un cambio en la autoridad actual de actualización de la raíz

El siguiente foco de la transición después de v1.31.60 es la propiedad de los recursos del paquete, no más traslados oportunistas de helpers.

El punto de control v1.31.62 convierte el límite de recursos del paquete en un piloto más explícito y comprobable, sin transferir todavía la propiedad activa en tiempo de ejecución.

• los directorios routes/, resources/views/, database/migrations/, public/ y stubs/ del paquete existen ahora como directorios de límite del paquete explícitamente reservados, con archivos marcadores que documentan la intención de propiedad futura
• los valores predeterminados de configuración del paquete siguen siendo propiedad del CMS, en el config/ del paquete
• los archivos de configuración correspondientes en la raíz siguen siendo la capa de anulación a nivel de instalación y los puntos de entrada de configuración de la aplicación compatibles con versiones anteriores
• el service provider del paquete mantiene la publicación del paquete explícita y etiquetada, pero la publicación permanece inerte salvo que un desarrollador ejecute intencionadamente vendor:publish
• el espacio de nombres de vistas del paquete webblocks-cms está ahora registrado como piloto seguro de límite del paquete, sin cambiar la resolución actual de vistas públicas o de administración de la raíz
• las rutas, vistas, migraciones, assets públicos y stubs del paquete todavía no constituyen propiedad autorizada y activa en tiempo de ejecución en esta fase
• webblocks:package-status informa ahora, de forma estrictamente de solo lectura, del estado de los recursos del paquete: reservados frente a poblados

Este piloto no mueve rutas, vistas, migraciones ni assets públicos activos de la raíz, ni controladores, requests, modelos, servicios o el comportamiento de System Update.

El punto de control v1.31.63 convierte el espacio de nombres de vistas del paquete, hasta ahora reservado, en un límite de diagnóstico concreto y comprobable propiedad del paquete, sin cambiar la propiedad activa en tiempo de ejecución.

• el archivo resources/views/diagnostics/package-status.blade.php del paquete existe ahora como vista Blade de diagnóstico interno real propiedad del paquete
• la vista de diagnóstico se renderiza únicamente a través del espacio de nombres webblocks-cms:: y no se expone mediante ninguna ruta pública o de administración
• webblocks:package-status puede ejecutar ahora opcionalmente --view-check para renderizar esa vista de diagnóstico de forma estrictamente de solo lectura y confirmar que el espacio de nombres de vistas del paquete se resuelve correctamente
• la salida predeterminada de webblocks:package-status sigue siendo ligera y de solo lectura, mientras que la comprobación opcional de la vista tampoco realiza escrituras de archivos, de caché, de configuración, de base de datos ni cambios en el estado de instalación
• las vistas públicas y de administración activas de la raíz siguen siendo las autorizadas, y en esta fase no cambia ninguna ruta de vista de la raíz ni la propiedad de rutas en tiempo de ejecución

Este piloto demuestra la carga del espacio de nombres de vistas del paquete con un archivo Blade real propiedad del paquete, evitando intencionadamente cualquier traslado de vistas públicas o de administración activas de la raíz.

El punto de control v1.31.64 convierte el límite de rutas del paquete, hasta ahora reservado, en un piloto de rutas de diagnóstico concreto y comprobable, sin cambiar la propiedad activa de las rutas.

• el archivo routes/diagnostics.php del paquete existe ahora como archivo de rutas de diagnóstico real propiedad del paquete, para futuros diagnósticos internos del paquete
• el service provider del paquete mantiene la carga de las rutas de diagnóstico del paquete explícitamente protegida tras webblocks-cms.diagnostics.load_routes, de modo que las rutas de diagnóstico del paquete no se cargan de forma predeterminada en el tiempo de ejecución normal
• webblocks:package-status informa ahora de la presencia del límite de rutas del paquete, del estado del archivo de rutas del paquete, de la existencia del archivo de rutas de diagnóstico esperado, del estado protegido de la carga de rutas y de si la ruta de diagnóstico está cargada actualmente
• las rutas públicas y de administración activas de la raíz siguen siendo las autorizadas, y en esta fase no se ha movido ni modificado ningún archivo de rutas públicas o de administración de la raíz

Este piloto demuestra el límite de rutas del paquete con un archivo de rutas de diagnóstico real propiedad del paquete, evitando intencionadamente cualquier migración de la propiedad de rutas públicas o de administración activas.

El punto de control v1.31.65 completa los pilotos restantes del límite del paquete ajenos al tiempo de ejecución para migraciones, assets públicos, stubs y el destino del flujo de actualización gestionado por Composer, sin mover la propiedad activa en tiempo de ejecución.

• los directorios database/migrations/, public/ y stubs/ del paquete conservan ahora una documentación más clara de marcadores de límite reservado para sus futuros roles propiedad del paquete
• la carga de migraciones del paquete está ahora explícitamente desactivada mediante la guarda webblocks-cms.boundaries.load_migrations, de modo que las migraciones del paquete permanecen inertes salvo que una fase de runtime posterior y acotada las conecte de forma intencionada
• la publicación de assets públicos y de stubs del paquete sigue siendo explícita y etiquetada por paquete; ahora publica el primer marcador de asset propiedad del paquete y los stubs iniciales sin reemplazar los assets de runtime de la raíz ni el instalador actual
• webblocks:package-status informa ahora del estado del límite de migraciones, del límite de assets públicos y del límite de stubs, de la nota sobre el objetivo de actualización gestionado por Composer y de la regla vigente de que el runtime de la raíz sigue siendo autoritativo
• el comportamiento actual de Composer en la raíz, la carga del runtime de la raíz y el comportamiento de System Update no cambian en este punto de control

Este punto de control completa la fase piloto de límites de paquete. El repositorio cuenta ya con límites de paquete concretos y comprobables para rutas, vistas, migraciones, assets públicos, stubs e intención de actualización gestionada por Composer, mientras que la propiedad del runtime activo sigue estando en la aplicación raíz.

• elija una única porción de runtime acotada que sea claramente propiedad del paquete y de riesgo suficientemente bajo como para moverla de extremo a extremo
• muévala solo cuando las reglas de propiedad de rutas, vistas, migraciones, assets o runtime sean explícitas para esa porción
• verifique la compatibilidad hacia atrás y las expectativas de instalación antes de que cualquier autoridad de runtime activo pase de la raíz al paquete
• mantenga sin cambios el comportamiento de System Update hasta que una fase posterior dedicada al flujo de actualización lo rediseñe de forma intencionada

La versión v1.32.0 es el primer punto de control con una porción de runtime real propiedad del paquete. Inicia el trabajo de runtime propiedad del paquete con tres porciones protegidas deliberadamente pequeñas que demuestran la propiedad del runtime por parte del paquete sin desplazar el runtime actual del CMS.

Fase 1: porción de runtime de diagnóstico del paquete, protegida

• el archivo routes/diagnostics.php del paquete apunta ahora a un controlador propiedad del paquete en packages/webblocks-cms/src/Http/Controllers/Diagnostics/PackageDiagnosticsController.php
• ese controlador renderiza la vista de diagnóstico existente del paquete webblocks-cms::diagnostics.package-status
• la ruta de diagnóstico sigue desactivada por defecto tras webblocks-cms.diagnostics.load_routes
• esto es intencionadamente solo una ruta interna reservada del paquete y no sustituye ninguna ruta de runtime de administración o pública de la raíz

Fase 2A: primera porción acotada de administración del paquete

• el archivo routes/admin.php del paquete introdujo originalmente una pequeña porción de estado de runtime de administración propiedad del paquete: admin.webblocks-cms.runtime-status, montada ahora en /webadmin/_webblocks-cms/runtime-status
• esa ruta de estado usa un controlador propiedad del paquete y una vista Blade propiedad del paquete en packages/webblocks-cms/resources/views/admin/runtime-status.blade.php
• la carga de rutas de administración del paquete está ahora habilitada por defecto y el árbol de rutas de administración activo del CMS se carga desde routes/admin.php del paquete
• la propia ruta reservada de estado de administración sigue desactivada por defecto tras webblocks-cms.admin.load_status_route
• las rutas de administración del paquete mantienen, cuando corresponde, los requisitos habituales de middleware de instalación, autenticación, acceso de administración y acceso al sistema de super admin
• la propiedad del runtime de administración activo corresponde ahora al paquete para Pages, Blocks, Media, Shared Slots, Navigation, Block Types, Page Layouts, Sites, Site Domains, Site Variables y Locales, mientras que Users, System, instalación/actualización, copia de seguridad/restauración, exportación/importación, promoción, autenticación/perfil, migraciones y los assets de runtime de la raíz siguen siendo propiedad de la raíz

Fase 2B: primera porción pública acotada del paquete

• el archivo routes/public.php del paquete introdujo originalmente una pequeña porción de estado de runtime público propiedad del paquete: webblocks-cms.public.runtime-status en /_webblocks-cms/runtime-status
• esa ruta usa un controlador propiedad del paquete y una vista Blade propiedad del paquete en packages/webblocks-cms/resources/views/public/runtime-status.blade.php
• la carga de rutas públicas del paquete está ahora habilitada por defecto y el árbol de rutas públicas activo del CMS se carga desde routes/public.php del paquete
• los controladores de entrada públicos propiedad del paquete gestionan ahora la portada, la portada localizada, la búsqueda, la búsqueda localizada, la búsqueda en JSON, la vista de página, la vista de página localizada, el envío de mensajes de contacto, la sincronización del consentimiento de privacidad y los endpoints internos de dominio admin-api.*
• las vistas de entrada públicas propiedad del paquete cubren ahora las plantillas de entrada de página y de búsqueda mediante webblocks-cms::public.pages.show y webblocks-cms::public.search.show
• la propia ruta reservada de estado público del paquete sigue desactivada por defecto tras webblocks-cms.public.load_status_route
• la autoridad de runtime sobre los assets públicos y los límites de instalación/actualización siguen siendo propiedad de la raíz fuera de las porciones públicas de ruta, modelo, soporte y vista movidas explícitamente al paquete

Por qué estas porciones siguen parcialmente protegidas

• el runtime de la raíz sigue siendo autoritativo para las instalaciones fuera de las porciones movidas intencionadamente al paquete
• las rutas reservadas del paquete evitan conflictos de nombre de ruta y de path con el runtime de administración y público existente
• las rutas de estado protegidas por separado permiten probar el arranque del paquete, la carga de rutas, la carga de vistas, el comportamiento del middleware y el informe de estado sin forzar esas rutas de diagnóstico reservadas dentro del runtime normal
• la autoridad de runtime movida sigue siendo intencionadamente parcial, de modo que los grupos de alto riesgo, como los modelos, la mayoría de las clases de implementación de administración, las capas de soporte más amplias, las migraciones, los assets y el comportamiento de System Update, evitan una propiedad prematura por parte del paquete

• siga reduciendo la carga de compatibilidad de rutas en la raíz solo después de que las implementaciones de administración y públicas restantes detrás de los archivos de rutas del paquete se hayan movido o se hayan dejado intencionadamente en la raíz
• mantenga las rutas reservadas de diagnóstico y de estado de runtime explícitamente protegidas incluso mientras los árboles de rutas de administración y públicas normales del CMS son autoritativos desde el paquete
• preserve los nombres de ruta, los paths, el middleware y el comportamiento de redirección mientras la autoridad de rutas del paquete vaya por delante de una extracción de runtime más profunda
• trate la futura limpieza de rutas como una fase de reducción de compatibilidad, no como prueba de que el CMS ya está listo como paquete de consumo

• mueva vistas reales propiedad del paquete solo en fases de seguimiento acotadas y agrupadas por área de runtime, por ejemplo primero el diagnóstico propiedad del paquete y más adelante una propiedad de vistas de administración o públicas cuidadosamente auditada
• mantenga alineadas la propiedad de rutas y la de vistas, de modo que una vista movida en el futuro se introduzca solo cuando la ruta de runtime propietaria esté gestionada intencionadamente por el paquete
• preserve reglas claras de override en la instalación y de autoridad de la raíz hasta que cada fase de propiedad de rutas o de vistas se diseñe y verifique explícitamente

• El directorio config/ del paquete debe seguir definiendo los valores por defecto propiedad del CMS.
• El config/ de la raíz sigue siendo la capa de override propiedad de la instalación durante la transición.
• Un archivo de configuración del paquete no debería volverse autoritativo para el comportamiento en runtime hasta que la historia de overrides y el cableado del bootstrap sean explícitos y estables.

• Las migraciones del paquete deben seguir siendo no autoritativas hasta que existan migraciones reales propiedad del paquete y su propiedad se mueva de forma intencionada.
• Cuando comience la propiedad de las migraciones, prefiera la carga desde el paquete para los archivos de migración propiedad del CMS y una guía de publicación explícita solo donde la personalización local de la instalación sea realmente necesaria.
• No mezcle el trabajo sobre los límites de migración con refactorizaciones de runtime no relacionadas.
• El directorio database/migrations/ de la raíz sigue siendo la capa de compatibilidad y autoridad para las instalaciones mantenidas desde el código fuente. La ruta de actualización mantenida desde el código fuente requiere la señal de autoload de Composer en la raíz del repositorio de mantenimiento para WebBlocks\\Cms\\ => packages/webblocks-cms/src/; que una instalación de consumo tenga un directorio packages/webblocks-cms no es suficiente. Las actualizaciones de las instalaciones de consumo del paquete deben usar migraciones de actualización explícitas propiedad del paquete y no deben ejecutar implícitamente las migraciones de la aplicación Laravel anfitriona.
• Las instalaciones nuevas de consumo del paquete usan el esquema database/migrations/fresh propiedad del paquete a través de webblocks:install. El instalador comprueba previamente si hay tablas CMS parciales antes de ejecutar ese esquema, se detiene con diagnósticos por defecto y solo renombra las tablas parciales vacías cuando el operador proporciona --repair-partial.
• PageLayoutSeeder y BlockTypeSeeder siguen siendo propiedad de la raíz por ahora porque aún cruzan el catálogo de page layouts, la sincronización de block types y límites más amplios del runtime de Pages o Blocks. DatabaseSeeder también sigue siendo propiedad de la raíz como punto de entrada activo de la instalación y como escritor de la versión instalada.

• La propiedad de rutas por parte del paquete está ya activa para los árboles de runtime de administración y público del CMS a través de routes/admin.php y routes/public.php del paquete.
• El archivo routes/web.php de la raíz queda ahora reducido a la instalación, la autenticación, el perfil y la carga de compatibilidad de esos archivos de rutas del CMS propiedad del paquete.
• Los movimientos de rutas deben seguir preservando el middleware, los bindings, los nombres, los paths, los flujos modales, las redirecciones y las expectativas de instalación aguas abajo.
• Las rutas de diagnóstico, de estado de runtime de administración y de estado de runtime público siguen siendo rutas reservadas protegidas por separado y no forman parte de la superficie de rutas del CMS siempre activa.
• La autoridad sobre las rutas todavía no implica una propiedad completa del runtime por parte del paquete, porque muchos handlers detrás de esas rutas siguen dependiendo de modelos, código de soporte, vistas y assets de la raíz.

• El directorio resources/views del paquete es ahora propietario de la vista de diagnóstico, de las vistas protegidas de estado de runtime de administración y público, de las vistas de administración del catálogo de iconos, del shell de layout público, de los shells públicos de página y de búsqueda, del modal público de búsqueda y de las vistas de entrada de slot propiedad del paquete.
• El resources/views de la raíz conserva ahora envoltorios de compatibilidad para las vistas movidas de layout, página, slot y entrada de búsqueda públicas, y sigue siendo autoritativo para la mayoría de las pantallas de administración y para el árbol de compatibilidad más amplio del renderizador público de bloques, que todavía no se ha extraído por completo.
• Los movimientos de vistas deberían mantenerse alineados con la ruta de runtime propietaria, para que la autoridad de rutas del paquete no se adelante demasiado a la capa real de vistas y controladores propietaria.
• Las vistas de la raíz siguen siendo la vía de compatibilidad para la mayor parte del renderizado activo del CMS fuera de las superficies webblocks-cms:: movidas de forma intencionada.

• El directorio public/ del paquete debería acabar siendo propietario de los assets publicables propiedad del CMS.
• El trabajo de transición debería distinguir los assets del paquete propiedad del CMS de los overrides public/site/... propiedad de la instalación.
• La publicación o sincronización de assets debería producirse solo cuando existan assets reales del paquete y el flujo de actualización defina con claridad cuándo es necesaria la publicación.
• La intención de publicación actual sigue siendo explícita y etiquetada por paquete. public/cms/package-boundary.json es el primer asset publicable propiedad del paquete y puede publicarse mediante webblocks-cms-assets.
• El directorio public/cms/ del paquete también contiene ahora el CSS y el JS del layout público usados por el layout público propiedad del paquete que se ha movido, pero las URL de assets public/cms/... actuales de la raíz siguen siendo autoritativas en el runtime activo por compatibilidad, mientras que los assets public/site/... propiedad de la instalación siguen siendo autoritativos para los overrides por sitio.
• El public/cms/ del paquete no debe contener index.php; la entrada de administración del CMS es /webadmin, no un puente de front controller desde el directorio de assets estáticos.
• La fijación de la CDN de WebBlocks UI y la fuente de sincronización del manifiesto de iconos por defecto no cambian en esta fase.

• El directorio stubs/ del paquete debería reservarse para plantillas reutilizables de archivos generados que pertenezcan al comportamiento del producto CMS.
• El andamiaje específico de una instalación o de un proyecto no debería pasar por defecto a los stubs del paquete CMS.
• Los stubs orientados al arranque de proyectos viven ahora en stubs/starter/ dentro del paquete, pero el comportamiento actual del instalador y el andamiaje del proyecto raíz siguen siendo autoritativos hasta que un paquete starter dedicado los adopte de forma intencionada.

• webblocks-cms-config está reservado para publicar en la raíz de la instalación los archivos de configuración por defecto del CMS propiedad del paquete, cuando una persona desarrolladora necesite ese flujo de forma intencionada.
• webblocks-cms-assets publica los assets públicos del CMS propiedad del paquete en la ruta de compatibilidad del runtime activo, public/cms.
• webblocks-cms-stubs publica los stubs iniciales propiedad del paquete.
• Estas etiquetas no cambian por sí solas el comportamiento en runtime y permanecen inertes hasta que se ejecute explícitamente vendor:publish.

• El objetivo a largo plazo sigue siendo actualizaciones de paquete gestionadas por Composer seguidas de pasos de runtime controlados.
• Los pasos posteriores a la actualización previstos podrán incluir más adelante migraciones, sincronización de tipos de bloque, limpieza de caché o publicación o sincronización de recursos, pero solo cuando esos recursos propiedad del paquete sean reales y estén conectados de forma intencionada.
• El artefacto de publicación canónico es ahora la propia raíz del paquete, no la raíz del repositorio de mantenimiento. Los ZIP de actualización son válidos cuando la raíz del archivo, o un único directorio contenedor de primer nivel, contiene el composer.json del paquete y la estructura src/, config/, resources/, database/, routes/ y public/ que espera fklavyenet/webblocks-cms.
• La antigua forma de archivo del actualizador gestionada desde la raíz se retira de forma intencionada para las actualizaciones modernas nativas de paquete. Solo sigue siendo válida como artefacto puente explícito para instalaciones anteriores al modelo nativo de paquete, como 1.31.53, cuyo actualizador todavía no puede validar ZIP con raíz de paquete.
• Los metadatos de publicación con raíz de paquete deben exigir un actualizador capaz de hacer de puente (minimum_client_version de 1.32.18 o posterior). Las instalaciones más antiguas deberían recibir primero el puente compatible y usar después el artefacto moderno con raíz de paquete, una vez que el puente haya instalado el código de validación y aplicación nativo de paquete.
• Durante la transición actual, la aplicación Laravel raíz sigue perteneciendo a la instalación y continúa ejecutando el modo de mantenimiento, las migraciones, los seeders, los comandos de sincronización, las limpiezas de caché y la persistencia de la versión instalada desde la raíz de instalación.
• Las actualizaciones dentro de la aplicación aplican ahora el artefacto de paquete validado en packages/webblocks-cms/ y, cuando el autoload de Composer muestra que el runtime consumidor activo sigue cargando WebBlocks\Cms\ desde vendor/fklavyenet/webblocks-cms/..., también en la raíz de runtime del paquete vendor segura correspondiente. No sobrescriben el shell raíz propiedad de la instalación, las sobrescrituras de configuración de la raíz, las migraciones de la raíz, project/, storage/, .env ni public/site/.
• Los archivos puente gestionados desde la raíz no son una relajación de la validación moderna. Un archivo puente debe conservar la antigua forma con artisan más composer.json en la raíz únicamente por compatibilidad con clientes heredados, y debe instalar código de actualización capaz de imponer después la forma estricta con raíz de paquete de fklavyenet/webblocks-cms.
• El punto de control de finalización de límites v1.31.65 mantiene esto solo como nota de objetivo. El comportamiento actual de Composer en la raíz y el flujo de actualización en runtime siguen siendo la referencia hasta que exista la primera porción real de runtime propiedad del paquete.

Flujo de instalación objetivo una vez que la separación paquete-starter esté lista:

• composer require fklavyenet/webblocks-cms
• la raíz Laravel del nivel de instalación sigue siendo responsable de .env, del composer.json raíz, de storage/, de las sobrescrituras de configuración propiedad de la instalación y de cualquier personalización específica de la instalación en project/ que todavía exista durante la transición
• el descubrimiento de paquetes debería cargar WebBlocks\Cms\WebBlocksCmsServiceProvider
• los diagnósticos del paquete, como webblocks:package-status, deberían confirmar la disponibilidad del paquete sin modificar el estado

Flujo de actualización objetivo una vez que las actualizaciones de paquete gestionadas por Composer sean la referencia:

• composer update fklavyenet/webblocks-cms
• ejecutar las migraciones
• limpiar las cachés donde sea necesario
• publicar o sincronizar los recursos del paquete solo cuando recursos reales del paquete lo requieran
• ejecutar los diagnósticos del paquete, como webblocks:package-status
• sincronizar el estado de la versión instalada solo cuando la actualización corresponda a un límite de publicación real
• ejecutar la reparación explícita del catálogo por separado cuando las filas del catálogo distribuido necesiten mantenimiento

Regla de compatibilidad actual:

• hoy, esas notas sobre los flujos de instalación y actualización son únicamente documentación del estado objetivo
• el comportamiento actual de Composer en la raíz, el comportamiento del instalador y el comportamiento de System Update dentro de la aplicación siguen siendo la referencia hasta que una fase posterior dedicada al flujo de actualización los cambie de forma intencionada

• La dirección a largo plazo sigue siendo un proyecto starter independiente que dependa de fklavyenet/webblocks-cms como paquete.
• El paquete actual dentro del repositorio existe para establecer límites y responsabilidades antes de intentar esa separación.
• La separación del starter solo debería producirse una vez rediseñados los límites restantes de la raíz: el runtime de instalación/autenticación/perfil, el modelo User propiedad de la aplicación, la autoridad sobre las migraciones de la raíz, la autoridad operativa de actualización/instalación en la raíz y la ruta activa de recursos de runtime public/cms de la raíz.

• Mueva un tipo de recurso cada vez desde el límite reservado hacia la propiedad activa del paquete.
• Empiece solo cuando la regla exacta de carga en runtime, la historia de sobrescritura en la instalación y el comportamiento de publicación/actualización estén claros para ese tipo de recurso.
• Prefiera planes de fase acotados, como vistas del paquete, migraciones del paquete o recursos públicos del paquete, en lugar de mezclar varios tipos de recursos de runtime en un mismo punto de control.
• Mantenga los movimientos de código con mucha carga de runtime detrás de auditorías de dependencias dedicadas en lugar de incorporarlos al trabajo piloto de límites de recursos.

Desplace el comportamiento de actualización hacia actualizaciones del paquete del CMS gestionadas por Composer, más pasos posteriores controlados como migraciones, limpieza de caché y publicación o sincronización de recursos cuando sea necesario. La reparación del catálogo sigue siendo un flujo de mantenimiento explícito del operador en lugar de un paso de actualización por defecto.

El punto de control de disponibilidad actual incluye ahora:

• autoload de Composer del paquete para WebBlocks\Cms\Database\Seeders\
• la conexión de desarrollo mantenida mediante repositorio de ruta en la raíz hacia packages/webblocks-cms
• documentación explícita de que el comportamiento actual de System Update en la raíz sigue siendo la referencia hasta que una fase posterior dedicada al flujo de actualización lo cambie de forma intencionada

Introduzca la dirección de proyecto starter independiente, como fklavyenet/webblocks-cms-starter, para que las instalaciones nuevas partan de una raíz Laravel propiedad del usuario que dependa del paquete del CMS, en lugar de clonar el repositorio del núcleo del CMS en la raíz del proyecto.

El punto de control actual solo añade trabajo previo de preparación de límites para esa futura separación:

• más seeders propiedad del CMS viven ahora en el paquete en lugar del namespace de la aplicación raíz
• más helpers de soporte de runtime de bajo riesgo viven ahora en src/Support/ del paquete
• los wrappers de compatibilidad de app/ en la raíz ya no se conservan por defecto; se han eliminado los wrappers PHP homólogos del paquete, mientras que las rutas de compatibilidad de Blade, seeders y recursos de runtime de la raíz permanecen donde siguen siendo necesarias
• los metadatos de composer del paquete, el descubrimiento del proveedor, la conexión de desarrollo mediante repositorio de ruta y el flujo objetivo documentado de composer require o composer update forman ahora la base de disponibilidad de la fundación del starter

Las instalaciones existentes necesitarán una ruta de migración conservadora:

• mantener las instalaciones actuales en funcionamiento mientras la transición al paquete esté incompleta
• evitar movimientos grandes de un solo paso que mezclen refactorizaciones de runtime con cambios de empaquetado
• preservar los archivos raíz específicos de la instalación como estado de proyecto propiedad del usuario
• dejar de depender de la sustitución de archivos del núcleo del CMS en toda la raíz como mecanismo de actualización
• introducir orientación clara para eliminar los archivos obsoletos del núcleo del CMS gestionados desde la raíz una vez que existan sus sustitutos propiedad del paquete

La transición debería priorizar el movimiento incremental de bajo riesgo frente a una reescritura única.

La consolidación de la transición al paquete está completa para todo el código propiedad del CMS que se puede mover con seguridad en este repositorio.

• La autoridad del paquete cubre ahora los dominios de código de runtime de rutas, vistas, modelos, seeders, partials compartidos, layout de administración y soporte del CMS que se podían mover con seguridad.
• Las clases App\... homólogas del paquete se han eliminado del árbol app del repositorio de mantenimiento; los archivos Blade de la raíz, los seeders de la raíz y las copias de runtime en public/cms/... de la raíz permanecen intencionadamente como wrappers o rutas de compatibilidad.
• Las URL de recursos de runtime activos siguen usando las rutas de compatibilidad public/cms/... de la raíz incluso donde existen archivos fuente homólogos propiedad del paquete en packages/webblocks-cms/public/cms/....
• Los límites finales restantes son el runtime de instalación/autenticación/perfil, el modelo User propiedad de la aplicación, la autoridad sobre las migraciones de la raíz, la autoridad operativa de actualización/instalación en la raíz y el diseño de la futura separación del starter.
• Debido a esos bloqueos, el paquete todavía no está listo para la separación del starter, aunque el trabajo seguro de consolidación del código propiedad del CMS esté completo.

Este cambio en el repositorio es solo el primer paso de transición de bajo riesgo:

• añade documentación de arquitectura
• crea el esqueleto del paquete dentro del repositorio en packages/webblocks-cms/
• añade un composer.json mínimo para el paquete
• añade un WebBlocks\Cms\WebBlocksCmsServiceProvider
• conecta el proyecto raíz para requerir el paquete localmente por ruta

El proveedor define ahora el contrato de arranque del paquete para futuros recursos del paquete, pero esos recursos del paquete todavía no son la referencia porque los archivos de runtime actuales del CMS siguen viviendo en la aplicación raíz.

El piloto v1.31.62 concreta más esos límites de recursos del paquete añadiendo archivos marcadores de límite reservados explícitos en routes/, resources/views/, database/migrations/, public/ y stubs/ del paquete. Estos directorios existen ahora como destinos documentados propiedad del paquete para fases posteriores, pero su contenido sigue siendo un marcador de posición no vinculante en este punto de control.

El piloto v1.31.63 avanza únicamente en el límite del namespace de vistas del paquete añadiendo una vista Blade de diagnóstico interno real en resources/views/diagnostics/package-status.blade.php del paquete y una sonda de renderizado opcional de solo lectura webblocks:package-status --view-check. Esto demuestra la carga de vistas basada en el namespace del paquete con una vista real propiedad del paquete, dejando activa la resolución de vistas de administración y públicas de la raíz.

El piloto v1.31.64 avanza únicamente en el límite de rutas del paquete añadiendo un archivo de rutas de diagnóstico real del paquete en routes/diagnostics.php, manteniendo la carga de rutas explícitamente desactivada en el runtime normal. Esto demuestra los límites de propiedad de los archivos de rutas del paquete sin mover ninguna ruta activa de administración o pública de la raíz.

El punto de control v1.31.65 completa los pilotos de límites inertes restantes manteniendo las migraciones del paquete explícitamente desactivadas por guarda, confirmando que la publicación de recursos públicos y stubs del paquete sigue siendo inerte hasta que existan archivos reales propiedad del paquete, y documentando las actualizaciones de paquete gestionadas por Composer como el límite objetivo sin cambiar el flujo de actualización actual de la raíz.

La versión v1.32.0 inicia ese movimiento previsto con las fases 1-2 de migración de runtime protegidas por guardas:

• la porción de runtime de diagnósticos del paquete es real y propiedad del paquete de extremo a extremo, mediante un controlador del paquete más la vista de diagnóstico existente del paquete, pero sigue desactivada por guarda de forma predeterminada
• una porción acotada de runtime de administración es ahora propiedad del paquete de extremo a extremo mediante routes/admin.php, src/Http/Controllers/Admin/PackageAdminStatusController.php y resources/views/admin/runtime-status.blade.php del paquete, pero sigue desactivada por guarda de forma predeterminada en una ruta reservada
• una porción acotada de runtime público es ahora propiedad del paquete de extremo a extremo mediante routes/public.php, src/Http/Controllers/Public/PackagePublicStatusController.php y resources/views/public/runtime-status.blade.php del paquete, pero sigue desactivada por guarda de forma predeterminada en una ruta reservada
• webblocks:package-status informa ahora de la porción de runtime de diagnósticos, la porción de administración del paquete, la porción pública del paquete y las guardas de ruta explícitas, todavía de forma de solo lectura
• las rutas y vistas de la raíz siguen siendo la referencia para el runtime existente del CMS fuera de esas rutas reservadas al paquete y protegidas por guardas
• config/webblocks-cms.php del paquete posee ahora valores de configuración de transición explícitos: los diagnósticos, las rutas públicas de estado, las rutas de administración de estado y la carga de migraciones del paquete siguen desactivados de forma predeterminada, mientras que la carga de rutas de administración del paquete está activada para dar autoridad activa a las rutas de administración propiedad del paquete

Las siguientes notas históricas de puntos de control describen cómo se introdujo la autoridad del paquete. Cuando mencionan wrappers App\... de la raíz, la limpieza amplia actual de la aplicación raíz reemplaza ese estado: los wrappers PHP homólogos del paquete ahora están intencionadamente ausentes, salvo que se indiquen en el estado actual de limpieza de la aplicación raíz descrito más arriba.

El punto de control actual de autoridad de runtime del paso 1 amplía aún más ese límite:

• las rutas de administración activas del CMS se cargan ahora desde routes/admin.php del paquete, y routes/web.php de la raíz queda reducido a la carga de instalación, autenticación, perfil y compatibilidad
• las rutas públicas activas del CMS se cargan ahora desde routes/public.php del paquete, incluidas home, home localizada, búsqueda, búsqueda localizada, búsqueda JSON, visualización de página, visualización de página localizada, envíos de contacto, sincronización de consentimiento de privacidad y admin-api.*
• controladores públicos propiedad del paquete respaldan ahora esa porción de entrada pública en packages/webblocks-cms/src/Http/Controllers/Public/
• un ContactMessageRequest propiedad del paquete y vistas de entrada pública propiedad del paquete respaldan ahora los puntos de entrada de rutas públicas movidos
• los App\Http\Controllers\PageController, PublicSearchController, ContactMessageController, PublicPrivacyConsentController y App\Http\Requests\ContactMessageRequest de la raíz se eliminaron después por ser wrappers homólogos redundantes del paquete
• los modelos y clases de soporte de la raíz permanecen solo donde sirven a dominios propiedad del host o de transición explícita; Users, instalación/perfil/autenticación, las rutas de recursos de runtime públicas/de administración de la raíz, las migraciones y el comportamiento de System Update siguen siendo límites, así que el paquete todavía no está listo para servir como runtime starter totalmente independiente sin una extracción más profunda

El punto de control actual de renderizado público del paso 2 amplía aún más la autoridad del paquete detrás de esas rutas públicas ya propiedad del paquete:

• el paquete resources/views/layouts/public.blade.php es ahora propietario del shell de layout público activo bajo el espacio de nombres webblocks-cms::
• los archivos del paquete resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php y pages/partials/slot*.blade.php son ahora propietarios del shell de página público activo, del shell de búsqueda público, de la ventana modal de búsqueda pública y de la capa de renderizado de entradas de slot
• los archivos raíz 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 y resources/views/pages/partials/block.blade.php permanecen ahora únicamente como envoltorios de compatibilidad que apuntan a las vistas con espacio de nombres propiedad del paquete
• el soporte de renderizado público propiedad del paquete incluye ahora PageRouteResolver, PublicPagePresenter, PublicSharedSlotResolver, SlotWrapperResolver, SiteAssetResolver, PublicSearchQuery, PublicOverlayRegistry, PublicBodyEndRegistry, TrustedHtmlOverlayExtractor, SiteResolver, ResolvedSite y VisitorEventLogger
• las clases raíz App\Support\... correspondientes a esos aspectos del renderizado público se eliminaron más adelante, una vez que los internos del paquete y las rutas dejaron de necesitarlas
• el paquete resources/views/pages/partials/blocks/* es ahora propietario de todo el árbol de parciales del renderizador público de bloques incluido, como un único lote coherente del paquete
• los archivos raíz resources/views/pages/partials/blocks/ permanecen ahora como finos envoltorios de compatibilidad que delegan en las vistas webblocks-cms::pages.partials.blocks. correspondientes
• Block::publicRenderView() resuelve ahora los tipos de bloque del núcleo incluidos primero hacia los parciales de bloque con espacio de nombres propiedad del paquete, mientras que los renderizadores de bloque raíz específicos de la instalación o personalizados siguen disponibles a través de la ruta de reserva raíz existente cuando no existe un parcial equivalente en el paquete
• la base del modelo público vive ahora bajo src/Models/ del paquete; los envoltorios raíz App\Models\... correspondientes se eliminaron más adelante, una vez que las pruebas del paquete y de consumidores nuevos demostraron que eran innecesarios
• Page, PageTranslation, PageSlot y Block viven ahora también bajo src/Models/ del paquete, sin envoltorios raíz equivalentes
• User sigue siendo propiedad de la aplicación y de la raíz de forma intencionada y no forma parte del objetivo de migración de modelos al paquete
• el directorio public/cms/ del paquete incluye ahora los archivos CSS y JS de tiempo de ejecución público activos que necesitan la capa de layout público y de renderizado de bloques movida al paquete, y vendor:publish --tag=webblocks-cms-assets publica ahora esos recursos reales del paquete en la ruta de compatibilidad raíz public/cms
• el tiempo de ejecución activo sigue sirviendo public/cms/... desde la instalación raíz por compatibilidad, y la instalación y System Update actualizan los recursos del CMS propiedad del paquete en esa ruta
• las migraciones raíz siguen siendo autoritativas para las copias mantenidas desde el código fuente con la señal explícita de autoload de Composer en la raíz, mientras que las System Updates nativas del paquete omiten las migraciones de la aplicación Laravel anfitriona y solo ejecutan las migraciones de actualización específicas del paquete cuando existen
• System Update, el flujo de instalación, la copia de seguridad o restauración y el tiempo de ejecución más amplio de la capa de proyecto permanecen sin cambios en este lote
• la validación con consumidores o paquetes de inicio sigue sin ser realista después de este punto de control, porque el tiempo de ejecución todavía depende de las migraciones raíz, de las rutas de recursos de compatibilidad raíz, de los flujos de administración e instalación/actualización propiedad de la raíz y del límite intencionado del modelo User raíz propiedad de la aplicación

El punto de control actual del tiempo de ejecución de administración de Site y Locale traslada otra porción coherente de la administración detrás del árbol de rutas de administración propiedad del paquete:

• los controladores propiedad del paquete gestionan ahora la administración de Site, la gestión de Site Domain, la gestión de Site Variable y la administración de Locale bajo packages/webblocks-cms/src/Http/Controllers/Admin/
• las Form Requests propiedad del paquete, los modelos SiteLocale y SiteVariable y los servicios de soporte directamente relacionados con Site o Locale viven ahora bajo src/ del paquete, sin envoltorios raíz App\... equivalentes
• los directorios del paquete resources/views/admin/sites/, resources/views/admin/sites/domains/, resources/views/admin/domains/ y resources/views/admin/locales/ son ahora propietarios de los árboles Blade activos de administración de Site, Domain y Locale a través del espacio de nombres webblocks-cms::
• los archivos Blade raíz de Site, Domain y Locale permanecen ahora como finos envoltorios de compatibilidad que renderizan las vistas equivalentes propiedad del paquete
• este lote no mueve intencionadamente las migraciones, los flujos de instalación/actualización, la copia de seguridad/restauración, la propiedad de autenticación/perfil/User, la propiedad de la configuración raíz ni la autoridad sobre los recursos de public/cms

La configuración predeterminada propiedad del paquete ha comenzado ya para webblocks-updates, mientras que el archivo de configuración raíz sigue siendo autoritativo como anulación de la instalación durante la transición.

La configuración predeterminada propiedad del paquete ha comenzado también para contact, mientras que el archivo de configuración raíz sigue siendo autoritativo como anulación de la instalación durante la transición.

La configuración predeterminada propiedad del paquete ha comenzado también para demo_media, mientras que el archivo de configuración raíz sigue siendo autoritativo como anulación de la instalación durante la transición.

La configuración predeterminada propiedad del paquete ha comenzado también para cms, mientras que el archivo de configuración raíz sigue siendo autoritativo como anulación de la instalación durante la transición.

El arranque de consola propiedad del paquete queda demostrado también mediante el comando de diagnóstico de solo lectura webblocks:package-status.

El espacio de nombres de vistas del paquete webblocks-cms está ahora también registrado de forma segura como piloto del límite del paquete, y v1.31.63 demuestra ese espacio de nombres con una vista de diagnóstico real propiedad del paquete. La resolución de vistas raíz activa sigue siendo autoritativa porque no se ha movido al paquete ninguna vista de administración o pública activa del tiempo de ejecución del CMS.

El límite de rutas del paquete queda ahora también demostrado con un archivo de rutas de diagnóstico real propiedad del paquete, pero la resolución de rutas raíz de administración y públicas activas sigue siendo autoritativa, porque las rutas de diagnóstico del paquete permanecen deshabilitadas por guardas en el tiempo de ejecución normal y no se ha movido al paquete ningún archivo de rutas raíz activo.

Los límites de migraciones, recursos públicos y stubs del paquete están ahora también explícitamente completados como pilotos reservados e inertes, y el límite del flujo de actualización gestionado por Composer queda documentado únicamente como dirección objetivo. Todavía no se ha trasladado a la autoridad del paquete ninguna migración raíz activa, ningún recurso público raíz, ningún comportamiento de stubs raíz ni ningún comportamiento del flujo de actualización raíz.

El primer traslado de código PHP propiedad del paquete está ya completo para SearchTextNormalizer, movido de app/Support/Search/ a src/Support/Search/ del paquete manteniendo el comportamiento sin cambios.

El límite del soporte de búsqueda sigue siendo intencionadamente estrecho en esta fase: SearchTextNormalizer y el pequeño objeto de valor de resultado PublicSearchRebuildResult son ahora propiedad del paquete, mientras que la indexación de búsqueda y la orquestación de consultas siguen siendo propiedad de la raíz hasta que sus dependencias de base de datos y de tiempo de ejecución se migren de forma deliberada.

También queda documentada la primera auditoría de Support ajena a la búsqueda: se revisaron MediaKindResolver, DatabaseExecutionStrategyResolver, SiteHandle y SiteDomainNormalizer, y no se movió ninguna clase adicional porque cada una sigue cruzando al menos uno de los límites de riesgo actuales de esta fase temprana.

El primer traslado de código de soporte de Contact está ya también completo para ContactMessageNotificationResult, movido de app/Support/Contact/ a src/Support/Contact/ del paquete manteniendo el comportamiento sin cambios, mientras que el servicio de notificación y el flujo de tiempo de ejecución de contacto siguen siendo propiedad de la raíz.

El primer traslado de código de soporte de BlockTypes está ya también completo para BlockTypeContract, movido de app/Support/BlockTypes/ a src/Support/BlockTypes/ del paquete manteniendo el comportamiento sin cambios, mientras que el registro, la ruta de la ventana modal de contratos en la administración y el comando de auditoría siguen siendo propiedad de la raíz.

LayoutMarkup también se ha auditado como posible traslado acotado de un ayudante de Pages y sigue siendo propiedad de la raíz por ahora, porque sus referencias actuales todavía cruzan la validación de peticiones de page layout, el renderizado de formularios de administración y el comportamiento público de los envoltorios de slot.

El primer traslado de código de soporte de Formatting está ya también completo para InlineRichTextRenderer, movido de app/Support/Formatting/ a src/Support/Formatting/ del paquete manteniendo el comportamiento sin cambios, mientras que SafeRichTextRenderer y su contrato de saneamiento siguen siendo propiedad de la raíz.

El siguiente punto de control de soporte de tiempo de ejecución de bajo riesgo está ya también completo para cuatro ayudantes acotados que se mantienen cerca del estado de consulta de la administración y de la paginación:

• AdminPagination vive ahora en src/Support/Admin/ del paquete
• BlockTypeIndexState vive ahora en src/Support/BlockTypes/ del paquete
• MediaIndexState vive ahora en src/Support/Media/ del paquete
• PageIndexState vive ahora en src/Support/Pages/ del paquete
• los envoltorios raíz App\Support\... de estos ayudantes se eliminaron más adelante; las importaciones del paquete son autoritativas

El primer traslado del límite de seeders propiedad del paquete está ya también completo para los catálogos de bajo riesgo:

• ahora propiedad del paquete: IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder
• ahora propiedad del paquete también: CoreCatalogSeeder, como traslado del límite del agregador de catálogos
• las clases raíz Database\Seeders\... permanecen como envoltorios de compatibilidad
• CoreCatalogSeeder sigue manteniendo estables los puntos de entrada raíz delegando a través del envoltorio raíz mientras continúa llamando a PageLayoutSeeder y BlockTypeSeeder, propiedad de la raíz
• PageLayoutSeeder, BlockTypeSeeder y el seeding activo de System Update siguen siendo propiedad de la raíz hasta una fase posterior específica

El siguiente lote aislado de tiempo de ejecución propiedad del paquete está ya también completo para la gestión del catálogo de iconos:

• ahora propiedad del paquete: SyncWebBlocksUiIconsCommand, IconCatalogController, IconCatalogItemUpdateRequest, IconCatalog y WebBlocksIconManifestSyncer
• las clases raíz App\Http\Controllers\Admin\IconCatalogController, App\Http\Requests\Admin\IconCatalogItemUpdateRequest, App\Support\Icons\... y App\Console\Commands\SyncWebBlocksUiIconsCommand se eliminaron más adelante por ser envoltorios redundantes de sus equivalentes en el paquete
• las rutas activas de administración del catálogo de iconos apuntan ahora directamente al controlador del paquete, y icons:sync-webblocks-ui lo registra ahora el service provider del paquete con la clase de comando del paquete
• las definiciones activas de rutas de administración del catálogo de iconos viven ahora en routes/admin.php del paquete en lugar de en routes/web.php de la raíz
• los envoltorios PHP raíz del catálogo de iconos ya no están disponibles; la autoridad activa de rutas y consola reside en el paquete
• ahora propiedad del paquete también: las vistas Blade activas de índice y de ventana modal de edición del catálogo de iconos en la administración, bajo packages/webblocks-cms/resources/views/admin/system/icons/
• los archivos Blade raíz del catálogo de iconos permanecen como envoltorios de compatibilidad que incluyen las vistas con espacio de nombres del paquete, pero el controlador del paquete renderiza webblocks-cms::admin.system.icons.index directamente
• este lote se mantiene únicamente dentro del ámbito de la administración y la sincronización del catálogo de iconos y no mueve intencionadamente la propiedad del tiempo de ejecución de Pages, Blocks, indexación de Search, Sites, Updates, Install, Backup o Restore, Export o Import ni del renderizado público en un sentido más amplio
• webblocks:package-status informa ahora de los archivos de tiempo de ejecución de iconos propiedad del paquete y de la ausencia de los envoltorios PHP raíz correspondientes, como parte del diagnóstico de transición de solo lectura

El siguiente lote, más amplio, de extracción del tiempo de ejecución de la administración está ya también completo para las superficies principales de gestión editorial y de catálogos:

• routes/admin.php del paquete es ahora autoritativo no solo para la gestión del catálogo de iconos, sino también para los manejadores de rutas de administración activos de Pages, Blocks, Media, Shared Slots, Navigation, Block Types y Page Layouts
• ahora propiedad del paquete: los controladores de administración autoritativos de esas porciones, bajo packages/webblocks-cms/src/Http/Controllers/Admin/
• ahora propiedad del paquete: las form requests de administración autoritativas de esas porciones, bajo packages/webblocks-cms/src/Http/Requests/Admin/
• ahora propiedad del paquete: los servicios de soporte de bloques, medios, navegación, páginas, page layouts y shared slots, bajo packages/webblocks-cms/src/Support/
• ahora propiedad del paquete: los árboles Blade de administración activos bajo packages/webblocks-cms/resources/views/admin/blocks/, admin/media/, admin/navigation/, admin/block-types/, admin/pages/, admin/shared-slots/, admin/page-layouts/ y admin/page-layout-slots/
• los envoltorios PHP raíz App\Http\Controllers\Admin\..., App\Http\Requests\Admin\... y App\Support\... de esas porciones movidas se eliminaron más adelante por ser envoltorios redundantes de sus equivalentes en el paquete
• los archivos raíz resources/views/admin/... de esos árboles movidos permanecen ahora como envoltorios de compatibilidad que incluyen las vistas webblocks-cms::admin.* correspondientes
• una excepción permanece intencionadamente concreta en la raíz: resources/views/admin/blocks/types/partials/rich-text-editor.blade.php sigue conservando el marcado real, porque la cobertura de compatibilidad lee ese archivo raíz directamente en lugar de resolverlo solo a través del espacio de nombres del paquete
• este lote no mueve intencionadamente Users, copias de seguridad, actualizaciones, ajustes del sistema, el flujo de instalación, las migraciones, las rutas de recursos de tiempo de ejecución raíz ni el modelo User propiedad de la aplicación
• webblocks:package-status, junto con una cobertura de arranque específica, informa ahora de los archivos de tiempo de ejecución de administración propiedad del paquete, más amplios, y de que los envoltorios PHP raíz correspondientes están ausentes

El lote específico del tiempo de ejecución operativo de la administración es ahora también propiedad del paquete:

• los controladores propiedad del paquete gestionan ahora la interfaz de Dashboard, la de revisión de Contact Messages en la administración, la de Visitor Reports y la de estado o reconstrucción de System Search, en packages/webblocks-cms/src/Http/Controllers/Admin/
• las clases de soporte propiedad del paquete incluyen ahora el servicio de consultas de informes de visitantes y el ayudante ligero de estado del esquema de búsqueda pública; la arquitectura completa de indexación de búsqueda y el comportamiento del comando search:rebuild siguen sin cambios detrás de los puntos de entrada de compatibilidad de la raíz
• en el paquete, resources/views/admin/dashboard.blade.php, admin/contact-messages/*, admin/reports/visitors/index.blade.php y admin/system/search.blade.php son ahora los propietarios de las superficies Blade operativas activas de la administración a través del espacio de nombres webblocks-cms::
• los archivos de controlador, soporte y Blade de la raíz para esas superficies operativas siguen siendo wrappers de compatibilidad ligeros
• este lote no traslada intencionadamente System Update, System Backup, la copia de seguridad y restauración, la exportación/importación de sitios, la promoción de sitios, el instalador, la propiedad de auth/perfil/User, las migraciones ni la propiedad de la configuración de la raíz, como tampoco la autoridad sobre los recursos de public/cms en la raíz

El seguimiento seguro restante de las rutas operativas en producción también está completo:

• los controladores propiedad del paquete gestionan ahora también Slot Types y System Settings en packages/webblocks-cms/src/Http/Controllers/Admin/
• las Form Request propiedad del paquete incluyen ahora también SystemSettingsRequest en packages/webblocks-cms/src/Http/Requests/Admin/
• en el paquete, resources/views/admin/slot-types/index.blade.php y resources/views/admin/system/settings.blade.php son ahora los propietarios de las superficies Blade activas a través del espacio de nombres webblocks-cms::
• en la raíz, App\Http\Controllers\Admin\SlotTypeController, App\Http\Controllers\Admin\SystemSettingsController, App\Http\Requests\Admin\SystemSettingsRequest y los archivos Blade correspondientes de la raíz siguen siendo wrappers de compatibilidad
• este seguimiento sigue sin trasladar intencionadamente la implementación de System Update, la copia de seguridad o la restauración, el instalador, la propiedad de auth/perfil/User, las migraciones ni la propiedad de la configuración de la raíz, como tampoco la autoridad sobre los recursos en tiempo de ejecución de public/cms en la raíz

El estado del shell de administración y del límite de recursos es el siguiente:

• las vistas de administración propiedad del paquete extienden webblocks-cms::layouts.admin, y el wrapper de compatibilidad de la raíz resources/views/layouts/admin.blade.php se ha eliminado, de modo que los errores de espacio de nombres en los consumidores del paquete fallan localmente
• en el paquete, public/cms/ contiene también archivos fuente CSS y JS de administración que coinciden con el conjunto activo de recursos de administración de la raíz, mientras que las rutas public/cms/... de la raíz siguen siendo la capa de compatibilidad en tiempo de ejecución
• las migraciones, el actualizador, la copia de seguridad y restauración, la exportación/importación, la promoción, auth/User, el instalador, la configuración de la raíz y la autoridad sobre los recursos en tiempo de ejecución quedan fuera del límite inmediato del shell de administración del paquete

Los lotes seleccionados de partials y componentes compartidos de la administración ya son propiedad del paquete:

• ahora propiedad del paquete: webblocks-cms::admin.partials.page-header, flash, listing-filters, page-actions, pagination y audit-actor
• ahora propiedad del paquete: webblocks-cms::components.admin.form-actions, consumido desde las vistas del paquete mediante <x-webblocks-cms::admin.form-actions>
• ahora propiedad del paquete: webblocks-cms::layouts.admin, consumido desde las vistas de administración propiedad del paquete mediante @extends('webblocks-cms::layouts.admin', ...)
• en la raíz, resources/views/admin/partials/{page-header,flash,listing-filters,page-actions,pagination,audit-actor}.blade.php siguen siendo wrappers de compatibilidad
• en la raíz, resources/views/layouts/admin.blade.php ya no existe; las vistas de administración de plugins y del paquete no deben usar la ruta histórica layouts.admin
• en la raíz, resources/views/components/admin/form-actions.blade.php sigue siendo el wrapper de compatibilidad para el uso existente de <x-admin.form-actions>
• las vistas de administración propiedad del paquete prefieren ahora el espacio de nombres del paquete para el layout de administración y para esos partials y componentes compartidos seleccionados
• webblocks:package-status informa ahora del límite seleccionado de partials y componentes compartidos de la administración, además del inventario de vistas de administración en tiempo de ejecución, que ya incluye el layout de administración propiedad del paquete y su wrapper en la raíz
• las URL de los recursos de administración de la raíz y la autoridad en tiempo de ejecución sobre public/cms, los recursos de marca, los límites de auth/perfil/instalación/app/guest, las migraciones, el actualizador, la copia de seguridad y restauración y el trabajo de publicación y versiones siguen sin cambios

La revisión de límites del paquete de la v1.32.15 añade una auditoría estática, como puerta de publicación, para las referencias de administración en tiempo de ejecución propiedad del paquete:

• la auditoría analiza packages/webblocks-cms/src/*/.php, packages/webblocks-cms/resources/views/*/.blade.php y packages/webblocks-cms/routes/*/.php
• falla ante referencias de administración exclusivas de la raíz como view('admin.'), View::make('admin.'), response()->view('admin.'), @include('admin.'), @includeIf('admin.'), @extends('layouts.admin'), <x-admin., <x-auth-password-field, component('admin.') y las referencias directas admin.blocks.types. de administración de bloques en la raíz
• las únicas excepciones admitidas son entradas exactas de archivo y patrón en la lista de permitidos, en las que el código en ejecución del paquete comprueba primero el nombre webblocks-cms::... y solo usa el nombre de la raíz como reserva de compatibilidad explícita para las sobrescrituras existentes específicas de la instalación

El punto de control inicial de bajo riesgo sobre el código fuente de helpers y objetos de valor se considera ya satisfactorio y completo para esta fase. El entorno de desarrollo local también se actualizó correctamente tras v1.31.60, lo que confirma que el cableado actual del paquete funciona en el entorno de desarrollo mantenido.

Los traslados oportunistas adicionales de código PHP de bajo riesgo están ahora en pausa. Los futuros traslados de código con gran peso en tiempo de ejecución requieren un plan de fase específico y una auditoría de dependencias, en lugar de más migraciones pequeñas y oportunistas.

Todavía no traslada el código en ejecución existente del CMS, no cambia el comportamiento de System Update, no crea un proyecto starter ni modifica los límites de propiedad en tiempo de ejecución actualmente activos.

El paso 1 trasladó al paquete la autoridad sobre las rutas activas del CMS, tanto para la administración como para el tiempo de ejecución público, y también trasladó la porción de entrada de rutas públicas para las solicitudes de página, búsqueda, mensaje de contacto y consentimiento de privacidad. El siguiente lote debería reducir la mayor área de doble propiedad que queda detrás de esa autoridad de rutas del paquete, en lugar de iniciar otro piloto reducido.

Modelos que todavía bloquean un tiempo de ejecución independiente del paquete:

• siguen siendo propiedad de la raíz de forma temporal, con una dependencia del paquete documentada: modelos de contenido de administración como BlockType, Media, SharedSlot, PageAsset, PageLayout, PageRevision, NavigationItem, SiteExport y SiteImport
• propiedad del paquete con wrappers de compatibilidad en la raíz: Locale, Site, SiteDomain, SiteLocale, SiteVariable, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent y SystemSetting
• probablemente listos para el paquete en breve, como seguimiento acotado de una porción que ya es propiedad del paquete: IconCatalogItem
• debe seguir siendo propiedad de la aplicación: User

Límites de vistas que todavía bloquean un tiempo de ejecución independiente del paquete:

• el layout público del paquete, el shell de página, el shell de búsqueda, el modal de búsqueda, las vistas de entrada de slot y el árbol distribuido de partials de renderizado público de bloques son ahora autoritativos a través del espacio de nombres webblocks-cms::
• en la raíz, resources/views/pages/partials/blocks/* se mantiene intencionadamente como capa de wrappers de compatibilidad para que los renderizadores de bloques específicos de la instalación en la raíz y las referencias directas a vistas de la raíz sigan funcionando durante la transición
• el renderizado de administración del paquete es ahora autoritativo para 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/ y admin/locales/* a través del espacio de nombres webblocks-cms::, mientras que los archivos Blade correspondientes de la raíz siguen siendo wrappers de compatibilidad
• el renderizado de administración de la raíz sigue siendo autoritativo para las pantallas aún no trasladadas, en especial los wrappers de instalación/auth/perfil y los casos límite de usuario propiedad de la aplicación, mientras que el renderizado del paquete es autoritativo para las pantallas activas de transferencia y promoción de sitios a través de webblocks-cms::

Límites de soporte y de servicios que todavía bloquean un tiempo de ejecución independiente del paquete:

• ya son propiedad del paquete para la porción de renderizado público: la resolución de rutas, la presentación de páginas, la presentación de Shared Slots, la resolución de contenedores de slot, la extracción de superposiciones HTML de confianza, los registros de superposición pública o de fin de body, la orquestación de consultas de búsqueda pública, la resolución del sitio público, la resolución de recursos del sitio y el registro de eventos de visitantes
• trasladar solo después de mover los modelos: las capas restantes de Pages o PublicRendering, Blocks, indexación de Search, Navigation, SharedSlots o Revisions que todavía dependen directamente de modelos de la raíz o de flujos de administración más amplios
• mantener por ahora como propiedad de la raíz: Media, los flujos de portabilidad de Sites, la sanitización de Formatting y los helpers de Admin o Audit
• debe seguir siendo propiedad de la raíz de la instalación: Install, System o Updates, la copia de seguridad o restauración y los escritores de versión instalada y de entorno

Bloqueos en solicitudes, comandos, recursos, migraciones y flujo de actualización:

• muchas Form Request de administración podrán trasladarse más adelante con wrappers en la raíz, una vez que se muevan los lotes correspondientes de página, bloque, Shared Slot, medios, sitio y navegación
• muchas Form Request editoriales de la administración ya se han trasladado con wrappers en la raíz, pero las solicitudes de sistema, portabilidad de sitios, actualización, copia de seguridad, instalación y otras orientadas a operaciones siguen siendo propiedad de la raíz
• los comandos de actualización, copia de seguridad, importación, exportación, promoción e instalación que usa el paquete deben mantenerse acotados explícitamente, porque siguen dependiendo del entorno, del sistema de archivos, de los archivos comprimidos, de Composer, de las migraciones y del estado de la instalación
• en la raíz, public/cms/* sigue conteniendo los recursos que son las rutas autoritativas activas en tiempo de ejecución, aunque public/cms/ incluye ahora también el CSS y el JS del layout público trasladados y puede publicarlos mediante webblocks-cms-assets
• las migraciones de la raíz siguen siendo autoritativas para los checkouts mantenidos desde el código fuente, con la autoridad de autoload de Composer en la raíz del repositorio de mantenimiento; los consumidores nuevos y nativos del paquete instalados con webblocks:install no deben ejecutar las migraciones de la aplicación Laravel anfitriona durante System Update
• WebBlocks UI Manager ya no se distribuye dentro del tiempo de ejecución del paquete del CMS. Su código fuente reside en plugins/webblocks-ui-manager para las compilaciones de mantenimiento, y los operadores lo instalan manualmente como un ZIP de plugin cuando necesitan los flujos de publicación o CDN de WebBlocks UI.
• la preparación de paquetes de plugin de la Fase 5 mantiene las clases, vistas, rutas, comandos, configuración, espacios de nombres de ajustes y prefijos de base de datos propiedad del plugin atribuibles a los identificadores de plugin; los plugins desactivados o incompatibles permanecen inertes y no pasan a ser responsabilidad del núcleo del CMS
• en los consumidores del paquete, System Updates solo ejecuta las migraciones de actualización propias del paquete desde vendor/fklavyenet/webblocks-cms/database/migrations/updates cuando están presentes; en caso contrario omite la ejecución de migraciones sin marcar como ejecutadas migraciones arbitrarias del anfitrión
• System Update sigue siendo una fase aparte porque sus bloqueos son la mutación del entorno, las escrituras en el sistema de archivos, la ejecución de Composer, las copias de seguridad, las migraciones, la persistencia de la versión instalada y el estado operativo de la raíz, y no la propiedad de rutas o controladores

• Consolidación segura del código propiedad del CMS: completada
• Limpieza restante de la inversión de helpers trasladados: completada (WebBlocks\Cms\Support\Blocks\BlockTranslationWriter y CoreBlockTypeCatalogSyncer son ahora los propietarios de la implementación; las clases App\Support\Blocks\... de la raíz siguen siendo solo wrappers de compatibilidad)
• Consolidación de las URL de recursos activos en tiempo de ejecución: incompleta de forma intencionada; public/cms/... en la raíz sigue siendo la ruta de compatibilidad en tiempo de ejecución
• Preparación para la separación del starter: no está lista
• Límites finales restantes: el tiempo de ejecución de instalación/auth/perfil, el modelo User propiedad de la aplicación, la autoridad de migraciones de la raíz, la autoridad de actualización e instalación de la raíz y el futuro diseño de separación del starter

Lote recomendado: realizar una limpieza específica de compatibilidad de modelos y soporte para las porciones de ejecución que ya son propiedad del paquete, o ejecutar la siguiente pasada de estrategia de recursos y marca de la administración ahora que el layout de administración y los archivos fuente CSS o JS de administración son propiedad del paquete. Mantenga la autoridad activa sobre los recursos de administración de public/cms en la raíz hasta que la estrategia de recursos de administración sea explícita.

Alcance completado en este punto de control:

• shell público y vistas de página: layouts.public, pages.show, search.show y search/partials/modal
• los partials de renderizado de entradas de slot de página en resources/views/pages/partials/slot*.blade.php
• los partials distribuidos de renderizado público de bloques en resources/views/pages/partials/blocks/*
• la capa de soporte del renderizado público para la resolución de rutas, la presentación de páginas públicas, la presentación de Shared Slots, la resolución de contenedores de slot, la extracción de superposiciones HTML de confianza, los registros de superposiciones, la orquestación de consultas de búsqueda, la resolución del sitio, la resolución de recursos del sitio y el registro de eventos de visitantes
• los wrappers de compatibilidad en la raíz allí donde las referencias de rutas, controladores, solicitudes o vistas todavía necesitan puntos de entrada retrocompatibles en la raíz

Alcance aplazado intencionadamente en este lote:

• la extracción de modelos Eloquent propiedad del paquete para Locale, Site, SiteDomain, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent y SystemSetting
• las URL autoritativas de los recursos del paquete en tiempo de ejecución y su flujo de publicación
• el rediseño de la autoridad de migraciones de la raíz
• la extracción de System Update y del flujo de instalación y actualización

Por qué este lote es el siguiente:

• la autoridad del paquete sobre rutas, controladores, solicitudes, soporte y vistas de administración ya existe en las principales porciones del tiempo de ejecución de la administración
• los partials y componentes compartidos de administración seleccionados y sus casos límite acotados ya se han trasladado, dejando pendientes los límites mayores de shell y de recursos
• el layout de administración propiedad del paquete y los archivos fuente CSS o JS de administración propiedad del paquete todavía dependen de la carga activa de recursos y de marca en tiempo de ejecución desde la raíz, por lo que el siguiente paso debería ser una estrategia deliberada de recursos y marca de la administración, en lugar de otro traslado de shell
• el siguiente trabajo de extracción de mayor valor es reducir las suposiciones de compatibilidad restantes de modelos y soporte o diseñar la estrategia de recursos y marca de la administración, sin entrar todavía en migraciones, actualizador, copia de seguridad y restauración, exportación/importación, promoción, auth/User, instalador, configuración de la raíz o autoridad sobre los recursos

• lote de portabilidad de sitios: Export o Import junto con Promotion deberían esperar hasta que sus límites de archivo, copia de seguridad y transferencia estén auditados explícitamente
• las migraciones, los activos de runtime activos, el instalador, la copia de seguridad/restauración, la autenticación/User y System Update deben seguir siendo fases dedicadas e independientes

Lote de reserva: una limpieza puntual de la compatibilidad restante de modelos y soporte para las porciones de runtime ya pertenecientes al paquete.

Esta es la opción de reserva únicamente si los partials compartidos revelan un acoplamiento inesperado con la autenticación, el actualizador, la copia de seguridad o la instalación que haga que un patrón de wrapper fino en la raíz resulte demasiado ruidoso para un lote de implementación pequeño.