Este es el contrato de creación y diseño compacto orientado a la IA para WebBlocks CMS. Léelo antes de proponer o aplicar un diseño de página a través del Internal Content API.

Responde cinco preguntas para cada bloque central enviado:

1. ¿Qué contenido permanece editable en el administrador del CMS?
2. ¿Qué configuraciones y variantes compartidas son compatibles?
3. ¿Qué relaciones secundarias y de medios son válidas?
4. ¿Qué público estable HTML emite el renderizador?
5. ¿Qué resultado visual puede producir el bloque sin página sin formato HTML?

Este documento resume el comportamiento respaldado por el código fuente. El descubrimiento de Live API sigue teniendo autoridad para ID específicos de instalación, complementos habilitados, tipos de bloques personalizados, configuraciones regionales, diseños, registros multimedia, menús de navegación y capacidades.

• Repositorio: fklavyenet/webblocks-cms
• Sucursal: main
• Confirmación auditada: 741a44bc0fe00bf38cae0753bd9edb02978b0dbe
• Documentación de versión auditada: 1.40.2
• Fecha de auditoría: 2026-07-14
• Forma del repositorio: paquete Composer de solo paquete
• Filas del catálogo principal publicadas: 51
• Borrador de filas del catálogo heredado: 7
• Filas principales estructuradas que pueden escribirse mediante IA después de que se aplique la siguiente política: 50
• Filas HTML sin formato grabables por IA después de que se aplique la siguiente política: 0

La línea de base anterior sigue siendo la última auditoría completa. Estas entradas fueron corregidas. contra la fuente después en lugar de volver a auditar cada bloque, así que trate cualquier cosa fuera de esta lista como 1.40.2-era y confírmelo mediante el descubrimiento de API en vivo.

• card (1.40.5): existe el estilo de Tarjeta variant. Este documento anteriormente indicó que no existía ningún campo de variante visual de tarjeta compatible, lo cual era incorrecto desde 1.40.5 en adelante.
• link-list (1.40.10): settings.row_layout y settings.list_frame.
• link-list-item (1.40.8): miniatura opcional de media_id.
• 1.91.0: relaciones opcionales de imágenes móviles en ocho bloques de medios nativos.
• 1.91.1: las nueve posiciones de contenido de diapositivas y controles deslizantes.
• 1.93.0: deshacer/rehacer texto enriquecido, modo de enfoque, recuento de palabras y comportamiento de pegado seguro.
• 1.94.0–1.94.2: validación de inicio de complemento administrado, cuarentena, paquetes retenidos y comprobaciones de recuperación de cuentas activas.

H Nota sobre el repositorio histórico: el árbol CMS previo al paquete contenía docs/feature-inventory.md, una amplia matriz de descubrimiento de características del producto. Se eliminó cuando se construyó el árbol del repositorio de solo paquetes y no era un inventario de creación de IA por bloque. El contrato de ejecución ahora se encuentra en resources/contracts/inventory.md.

Familias de fuentes inspeccionadas:

• src/Support/Blocks/CoreBlockTypeCatalogSyncer.php
• src/Support/BlockTypes/BlockTypeContractRegistry.php
• src/Support/Blocks/BlockTranslationRegistry.php
• src/Models/Block.php
• src/Http/Requests/Admin/BlockRequest.php
• src/Support/InternalContentApi/InternalContentPlanService.php
• src/Support/InternalContentApi/InternalContentApiOperations.php
• src/Http/Controllers/InternalContentApi/InternalContentResourceController.php
• src/Http/Controllers/InternalContentApi/InternalSharedSlotController.php
• src/Http/Controllers/InternalContentApi/InternalApiDiscoveryController.php
• routes/admin.php
• resources/views/admin/blocks/types/*.blade.php
• resources/views/admin/blocks/settings/*.blade.php
• resources/views/pages/partials/blocks/*.blade.php
• public/cms/css/public.css
• Pruebas de paquetes enfocadas y documentación actual del producto

1. Usa utilizar bloques estructurados. No almacene una página, sección, colección de tarjetas, shell de navegación, formulario o componente visual en Trusted HTML.
2. html es una trampilla de escape exclusiva para humanos. El descubrimiento de API puede identificarlo como no disponible, pero ninguna mutación de API puede crear, actualizar, reemplazar, mover, reordenar, clonar, promover, publicar o eliminar un bloque HTML.
3. No omita la restricción HTML mediante texto enriquecido, <style>, <script>, atributos de controlador de eventos, marcado de iframe, marcado SVG, marcado codificado o configuraciones inventadas.
4. Use solo campos, valores de enumeración, roles de medios y relaciones secundarias documentados aquí y confirmados mediante descubrimiento en vivo.
5. Trate un campo editable por el administrador como parte del contrato de creación admitido. Un valor reconocido únicamente por un renderizador o una ruta de compatibilidad heredada no es un campo de creación de IA normal.
6. Si una región visual no se puede expresar con el contrato admitido, deténgase e informe una brecha de capacidad. No lo aproximes silenciosamente con bloques no relacionados y no recurras a HTML.
7. El sitio CSS puede refinar la tipografía, el espaciado, el color, los bordes, las sombras y la presentación responsiva a través de ganchos públicos estables. No debe convertirse en un almacén de contenido oculto ni reconstruir el marcado semántico faltante.
8. No apunte a los ID de bases de datos, ID de bloques generados, selectores de posición de hermanos ni a :nth-child() para el comportamiento de diseño esencial. Prefiere atributos de tipo bloque, clases nativas wb-*, clases de cuerpo de página y configuraciones documentadas.
9. Mantenga todos los títulos, párrafos, etiquetas, botones, insignias, imágenes, subtítulos, menús y configuraciones de formulario visibles editables a través de su campo CMS nativo o registro relacionado.
10. Validar primero, aplicar solo después de la aprobación explícita del usuario, crear borradores primero y dejar las acciones de actualización del sistema en vivo y las pruebas visuales en vivo al operador humano a menos que se autorice por separado.
11. Trate la tarjeta como una presentación voluntaria, no como la forma predeterminada de copiar una copia relacionada con el grupo. Utilice una Tarjeta solo para una entidad limitada, repetible o procesable de forma independiente, como un producto, complemento, plan de precios, descarga o formulario.
12. Antes de elegir bloques, indique una dirección de diseño a nivel de sitio que cubra carácter, densidad, tipografía, geometría, imágenes, esquinas y contraste. Haga que el árbol de bloques y el sitio CSS implementen esa dirección en lugar de elegir cada sección de forma aislada.
13. Variar el ritmo de la página deliberadamente. Combine regiones estrechas, regulares, anchas y de ancho completo; copia silenciosa alternativa, imágenes dominantes y colecciones estructuradas en lugar de repetir secciones con el mismo peso.

El contrato del producto de destino es:

Esta política se aplica en el código mediante una única clase de política de producto, WebBlocks\Cms\Support\BlockTypes\BlockTypeApiAuthoringPolicy. Cada superficie API la consulta en lugar de repetir la regla: ambos normalizadores de bloques, PATCH de bloques existentes, creación incremental de páginas y Shared Slot, reordenamiento de páginas/Shared Slot, eliminación de subárbol, borrado total de Shared Slot, publicación de páginas y Shared Slot, reemplazo de ranuras de borrador, creación y promoción de actualizaciones por etapas, asignación de Shared Slot y eliminación de páginas API. Los rechazos ocurren antes de cualquier transacción o escritura, devuelven HTTP 422 con el código estable block_type_not_api_writable y no dejan cambios parciales. Ninguna capacidad de token lo anula.

Un diseño es manejable por CMS solo cuando se cumple todo lo siguiente:

• El contenido visible se almacena en campos de traducción nativos, configuraciones, relaciones de biblioteca multimedia, registros de navegación, registros comerciales o bloques secundarios.
• El editor de bloques normal expone los campos necesarios para mantener el resultado.
• El marcado público proviene de un renderizador de paquete o complemento, no del contenido de la página.
• La presentación utiliza variantes documentadas, configuraciones, tokens de tema y ganchos CSS estables.
• Reordenar o editar contenido no requiere editar HTML o CSS.
• El comportamiento móvil proviene del renderizador, WebBlocks UI, o del sitio estable CSS, en lugar de marcas móviles duplicadas en el contenido.

Un renderizador puede reconocer un valor interno o heredado que el formulario de administración normal no expone. Dicho valor se documenta como una entrada de compatibilidad, no como un campo de creación de IA recomendado.

Utilice matrices children anidadas. No envíe ID de relación de base de datos en un plan de contenido.

Convenciones del plan de contenido:

• Coloque la copia de propiedad local directamente en translations para la configuración regional del plan seleccionada.
• Ingrese URL, destino, variante de presentación y otras opciones compartidas en settings.
• Coloque la asignación directa de biblioteca multimedia en media_id.
• slide, image, hero, section, card, cta, content_header y link-list-item también acepta una referencia opcional de nivel superior mobile_media_id un registro de la biblioteca multimedia de imágenes. Se almacena en block_media con rol mobile_image, compartido entre configuraciones regionales y editable a través de los medios de administración selector y PATCH /blocks/{block}. En pantallas de hasta 768 px de ancho reemplaza la imagen predeterminada; una imagen móvil ausente, eliminada o privada vuelve a el valor predeterminado. Envíe null para borrarlo; omitirlo en PATCH lo conserva. Las imágenes de primer plano utilizan <picture><source media="(max-width: 768px)">; Los bloques de fondo utilizan un fondo responsivo CSS. Utilice otro cultivo de la mismo objeto visual: el texto alternativo, los subtítulos, la posición, el ajuste, las superposiciones y los enlaces permanecen compartido. El Visor de galería del bloque de imágenes continúa abriendo la configuración predeterminada imagen de resolución completa. Los elementos de la galería, los logotipos de marcas, los vídeos y el audio no aceptar este campo.
• Colocar elementos de la galería en gallery_items o gallery_media_ids.
• Uuse solo children anidado; no envíe id, parent_id, block_id, slot_type_id o block_type_id.
• La API actualmente acepta un objeto settings de forma amplia. Esa permisividad no es permiso para inventar escenarios; utilice únicamente las claves que se enumeran a continuación.

La representación normal de la ranura principal proporciona:

Los bloques marcados como root-owner colocan data-wb-public-block-type en su propia raíz semántica. Otros bloques de nivel superior normalmente reciben:

Los guiones bajos se normalizan a guiones en data-wb-public-block-type; por ejemplo content_header se convierte en content-header.

El catálogo principal publicado actualmente contiene 55 filas:

Use plain para cualidades, principios, beneficios, resúmenes de procesos y otra copia que no represente objetos independientes. Utilice cards solo cuando cada elemento tenga un límite significativo propio. La cantidad de elementos, especialmente el conocido conjunto de tres, nunca es por sí sola una razón para elegir tarjetas.

No trate un Blade parcial como prueba de que hay un identificador disponible para nuevo contenido API. La fuente actual contiene renderizadores de compatibilidad y filas borrador que no son contratos de creación principales publicados.

Las filas del borrador del catálogo incluyen:

Los identificadores de solo renderizador, alias, parciales o de compatibilidad incluyen ejemplos como:

Reglas:

• Nunca cree estos simplemente porque existe un archivo de renderizado.
• Úsalos solo si el catálogo de bloques autenticado en vivo informa el identificador exacto publicado y utilizable para la instalación actual.
• Prefiere los bloques estructurados canónicos documentados anteriormente.
• Los parciales internos, como el visor de galería y los renderizadores de enlaces de la barra lateral, nunca son tipos de bloques de plan de contenido.

Estos son árboles de bloques administrados, no plantillas fijas. Confirme todos los identificadores en tiempo de ejecución.

Comience desde la receta menos enmarcada que satisfaga el contenido. No repita la misma receta en bandas de páginas adyacentes y no seleccione la receta de la tarjeta de características simplemente porque la fuente contiene tres elementos breves.

Utilice una imagen grande y significativa y un estilo de superficie sobrio. Elija layout:full-bleed cuando la imagen deba convertirse en una banda de apertura sin marco que abarque toda la ventana gráfica; conservar split cuando la imagen sea contenido semántico de primer plano.

Este es el punto de partida normal para cualidades como experiencia, comunicación, atención, rapidez o confiabilidad. Promuévalo a Tarjetas solo cuando los elementos sean procesables de forma independiente o estén limitados.

Uuse esto solo cuando la fila de acción deba ubicarse fuera de la raíz de promoción del héroe. El propio Hero acepta elementos secundarios de Button Link en todos los diseños, incluido el dividido; mantenga las acciones dentro de Hero cuando esa sea la composición prevista.

Todos los títulos, párrafos y acciones se pueden editar de forma independiente. Reserve esta receta para entidades acotadas como productos, complementos, planes, descargas o servicios con acciones propias. Utilice el sitio CSS para obtener una apariencia de tarjeta consistente y específica del sitio a través de ganchos estables; no inyectar tarjeta HTML.

Use utiliza imagen para medios de primer plano. Utilice un bloque con capacidad de fondo solo cuando la imagen sea semánticamente un fondo.

Las etiquetas de navegación y las URL pertenecen a registros de navegación de CMS, no a HTML.

Antes de aplicar un diseño visual, genere una tabla de mapeo:

Para cada región:

1. Identifique cada copia editable, medio, acción, insignia, datos de navegación y registro dinámico.
2. Asigna cada pieza a un campo nativo editable por el administrador.
3. Confirmar reglas padre/secundario y renderizador HTML.
4. Confirme que la composición visual es posible con el DOM documentado.
5. Use el sitio CSS solo para presentaciones que el DOM estable pueda admitir.
6. Si falta algún campo semántico, contenedor, ranura o variante, marque la región como no compatible.
7. Proponga la capacidad de complemento o CMS reutilizable más pequeña: una variante de renderizador, un nuevo bloque estructurado, un patrón compuesto de bloques existentes o un bloque de dominio como una colección de productos de Commerce.
8. No aplique un sustituto de baja fidelidad a sabiendas a menos que el usuario apruebe explícitamente ese compromiso.

Formato de informe de brecha de capacidad:

Utilice capas de estilo en este orden:

1. Primitivas WebBlocks UI ya emitidas por el renderizador.
2. Fichas de tema público y roles de color públicos que reconocen el modo.
3. Configuraciones y variantes de bloques nativos.
4. Estreche el CSS específico del sitio utilizando ganchos estables.
5. Un renderizador reutilizable o un cambio de contrato de bloque cuando falta el DOM requerido.

Los selectores estables incluyen:

No utilice el sitio CSS para:

• insertar texto esencial con pseudoelementos;
• depende de los ID de bloque generados;
• inferir semántica del orden de hermanos;
• hide contenido creado por CMS simplemente para reemplazarlo con contenido CSS;
• reconstruir un diseño faltante con posicionamiento absoluto frágil;
• codificar colores solo claros que interrumpen el modo Claro/Oscuro/Automático.

Estos son hallazgos de implementación, no permisos para inventar comportamientos:

1. Resuelto: este inventario ahora se envía como resources/contracts/inventory.md y GET /webadmin/api/inventory lo entrega a las herramientas.
2. webblocks-cms-docs/docs/block-type-contracts.md dice 42 tipos principales publicados, mientras que el catálogo actual define 51.
3. Varios documentos existentes todavía muestran rutas de renderizado solo previas al paquete en packages/webblocks-cms/...; Las rutas de paquetes actuales comienzan en resources/views/....
4. Resuelto: El HTML de confianza ya no admite escritura mediante API. BlockTypeApiAuthoringPolicy bloquea todas las rutas de mutación de API, incluida la normalización genérica, el PATCH de bloque existente y las operaciones de reordenamiento, eliminación de subárboles, limpieza de todo y publicación de Shared Slot.
5. Resuelto: Hero y CTA son contenedores simples para elementos secundarios button_link tanto en el administrador como en la API. Los campos primary_cta / secondary_cta sobreviven como una taquigrafía de dos botones. La fila del catálogo heredado button no publicado ya no es un bloqueador de creación.
6. Resuelto: el editor de elementos de columna ahora expone el campo de subtítulo que la variante Columnas stats representa como valor de estadística.
7. El audio tiene un selector de medios de administración normal y un procesador de medios públicos, pero la lista de medios permitidos directos del plan de contenido omite el audio.
8. Resuelto: la normalización de iconos tiene un propietario. InternalContentApiOperations contiene la lista canónica PUBLIC_ICON_BLOCK_TYPES más los normalizadores de slug/tono compartidos, y el plan de contenido completo los delega, por lo que los puntos finales de bloques incrementales y los planes validan los íconos de manera idéntica.
9. La configuración del bloque API aún no se rige por un esquema de configuración legible por máquina por bloque. Las configuraciones desconocidas pueden sobrevivir a la normalización incluso cuando ningún renderizador o campo de administración las utiliza.
10. Resuelto: navigation-auto ahora tiene un contrato documentado en BlockTypeContractRegistry y se puede descubrir a través de tipos de bloques y contratos de contenido.
11. WebBlocks UI envía una anatomía wb-footer-* (wb-footer-grid, wb-footer-brand, wb-footer-nav, wb-footer-link, wb-footer-list, wb-footer-item, wb-footer-copy, wb-footer-meta, wb-footer-text, wb-footer-logo) que ningún renderizador CMS emite. En su lugar, un pie de página de ranura compartida compone wb-section/wb-container/wb-grid/wb-stack/wb-cluster genérico, por lo que solo se puede acceder al patrón desde diseños escritos a mano. Cosmetic desde 1.50.0 le dio a .wb-slot-footer su propia superficie; un bloque de composición de pie de página permanece deliberadamente aplazado en lugar de pendiente.
12. Resuelto: GET /content-contract deriva su sección media_library de la tabla de rutas registrada, por lo que supported_operations y unsupported_operations no pueden desviarse de lo que publica openapi.json. La carga, la recuperación remota, la eliminación, el reemplazo y el movimiento se publican según lo admitido con la capacidad que exige cada ruta.
13. Resuelto: el consentimiento tiene una mitad orientada hacia el visitante. El banner de configuración del sistema muestra el patrón de consentimiento de cookies de WebBlocks UI en páginas públicas y lo conecta al punto final POST /privacy-consent/sync existente, y contact_form obtuvo settings.consent_required más un consent_label traducido registrado en cada envío.
14. El repositorio tiene capturas de pantalla de administración de páginas y panel de control, pero no tiene una galería de accesorios visuales canónica por bloque/por variante. Por lo tanto, las descripciones de “Apariencia de ejemplo” en este inventario son referencias doradas derivadas de la fuente, no respaldadas por capturas de pantalla. Hasta que exista esa galería, prefiera composiciones neutrales documentadas y evite reclamar fidelidad visual únicamente a partir de la prosa.
15. Resuelto para la planificación: GET /content-contract ahora publica un contrato de dirección de diseño legible por máquina que cubre carácter, densidad, tipografía, geometría, imágenes, esquinas, contraste, roles de ritmo, política de tarjetas y lagunas de composición conocidas. Deliberadamente no persiste un registro de estilo oculto; Las herramientas de inteligencia artificial indican la dirección en su plan/informe y lo implementan a través de opciones de bloques compatibles, tokens temáticos y el sitio estable CSS.

El producto posee este contrato de ejecución. El repositorio de documentación mantiene una instantánea de la versión generada con una identidad de origen distinta; las ediciones comienzan en el contrato del producto.

Desde CMS 1.94.3, composer test:inventory y composer test:docs validan resources/contracts/inventory-review.json con el contrato actual y las huellas digitales de origen del tiempo de ejecución. Los archivos de tiempo de ejecución modificados, agregados o eliminados y los cambios de versión del producto requieren una nueva revisión explícita. CI y pre-push ejecutan la misma verificación; La preparación del lanzamiento verifica el árbol de trabajo y el generador de artefactos verifica el árbol Git seleccionado.

Después de revisar los campos admitidos, enumeraciones, elementos secundarios, medios, renderizado, comportamiento del editor, permisos y ciclo de vida del complemento, actualice esta prosa y registre la revisión con composer inventory:review -- --reviewed --note="review summary". Un contrato sin cambios después de un cambio de fuente se acepta solo con una explicación explícita --no-authoring-impact="reason". Los registros de revisión nunca deben actualizarse automáticamente mediante CI o scripts de versión.

El registro mecánico captura el catálogo principal publicado, las reglas secundarias, la propiedad de la raíz del renderizador, la política de escritura de API y el soporte de medios móviles de los asistentes reales del producto. PHPUnit compara este registro con los ayudantes actuales y la verificación de fuente requiere un encabezado de inventario único para cada bloque principal publicado. Las huellas dactilares y las comparaciones mecánicas imponen la revisión y la coherencia estructural; no prueban el significado de cada oración. Las explicaciones en prosa y sin impacto siguen siendo responsabilidad del colaborador y del revisor.

El tools/inventory-snapshot.php del repositorio de documentación regenera la instantánea y su procedencia inventory-source.json. Sus comprobaciones rechazan las ediciones manuales de instantáneas y comparan la versión del producto, la huella digital de origen, la suma de verificación de revisión y el contenido del documento con la compra de un producto seleccionado. Las comprobaciones de documentación aisladas verifican la procedencia registrada sin necesidad del producto en tiempo de ejecución. La generación de instantáneas y la publicación de CMS siguen siendo operaciones independientes.

• webblocks-cms-docs/docs/ai-page-building-guide.md
• webblocks-cms-docs/docs/internal-content-api.md
• webblocks-cms-docs/docs/api-discovery.md
• webblocks-cms-docs/docs/block-type-contracts.md
• webblocks-cms-docs/docs/public-block-render-markup.md
• webblocks-cms-docs/docs/block-ui-renderer-contract.md
• webblocks-cms-docs/docs/public-theme-and-tones.md
• webblocks-cms-docs/docs/public-assets.md
• webblocks-cms-docs/docs/media-image-variants.md

Este inventario debería ser el primer documento que lee una IA para seleccionar la capacidad de diseño de página. Las referencias detalladas siguen siendo útiles para los flujos de trabajo de endpoints, la compatibilidad histórica y las notas completas del renderizador.

Instalación de catálogos y ZIP, actualizaciones y activación de panel/API validan la fuente del complemento, inicio del proveedor, comandos y rutas en un nuevo proceso PHP a través de cms:plugin-probe. Se requiere validación incluso cuando no hay ninguna migración pendiente. Una sonda fallida o con tiempo de espera agotado deja el paquete actual activo; Los diagnósticos de subprocesos no se exponen en las respuestas. El tiempo de espera de inicio predeterminado es de 30 segundos (webblocks-plugins.install.boot_timeout_seconds).

Las actualizaciones exitosas conservan el paquete anterior y registran si se ejecutaron las migraciones. Las fallas en la configuración de la base de datos dejan el complemento deshabilitado y preservan sus tablas y paquetes. Las fallas de fuente/ruta en tiempo de ejecución ponen en cuarentena el complemento; una desactivación explícita anula habilitación basada en configuración. Los registros JSON del ciclo de vida utilizan reemplazo atómico.

/webadmin/plugin-recovery y su formulario de inicio de sesión se cargan sin la fuente del complemento instalado, rutas o comandos. Controles de inicio de sesión de CMS existentes, acceso de administrador activo y autorización Super admin, y CSRF se aplica la protección. La recuperación puede deshabilitar un complemento o restaurar el paquete retenido cuando no se ejecutó ninguna migración, después de otra prueba de inicio. Una restauración también vuelve a publicar sus activos. Esta es la recuperación de paquetes administrados por CMS; no aísla proveedores de host arbitrarios o ejecutable de zona de pruebas PHP. La terminación del proceso inatrapable todavía requiere la separación solicitud de recuperación en lugar de un controlador de errores en proceso.

GET /webadmin/api/system/health requiere la capacidad opcional system-health.read y un token de sistema válido para toda la instalación (allowed_site_ids: null), propiedad de un operador activo con access-system. Las credenciales personales y limitadas a sitios no pueden leer la salud de la instalación. El parámetro opcional y validado site_id filtra las comprobaciones del sitio, mientras las de toda la instalación siguen visibles.

El endpoint devuelve claves y parámetros de mensajes seguros, problemas ordenados, estados de categorías (healthy, warning, critical, unknown, not_applicable), resúmenes de sitios, información del sistema y resultados recientes de operaciones. Las observaciones de sitios, copias, almacenamiento, plugins, preparación para actualizar e historial se almacenan en caché durante cinco minutos; las pruebas del planificador se leen en cada solicitud. Las comprobaciones desconocidas y opcionales se distinguen de las satisfactorias. Leer o actualizar la salud no modifica contenido, concilia registros de copias, envía correo, ejecuta limpieza o actualizaciones, obtiene metadatos de versiones ni genera pruebas del planificador. Los informadores de plugins conservan su contrato existente de informes de salud; los mensajes sin procesar y los detalles de excepciones quedan fuera de esta vista.

Las rutas operativas existentes siguen disponibles. Los destinos de Ayuda de los plugins se incorporan a Sistema y los de Mantenimiento se combinan mediante la clave estable del grupo de mantenimiento; el elemento principal de Ayuda enlaza directamente a la documentación. El estado de salud es una prueba para revisión, no una autorización para publicar contenido, restaurar una copia o actualizar un host. Las comprobaciones de búsqueda comparan los ámbitos aptos de páginas e idiomas publicados con las filas del índice; no prueban la actualidad del texto. La disponibilidad de copias no prueba la integridad de la restauración. La preparación para actualizar permanece separada del funcionamiento normal del sitio.