= 1.0.36 =
* Fix: `GET /projects` (y la tool MCP `editor-ia/list-projects`) devolvía un array JSON plano en la raíz de la respuesta, distinto del resto de los endpoints `list_*` del plugin (`list_menus`, `list_media`, `list_assignments`, `list_revisions`), que siempre envuelven el listado en un objeto (`{menus: [...]}`, `{media: [...]}`, etc.). El protocolo MCP exige que `structuredContent` sea un objeto, no un array — un agente real reportó que `editor-ia-list-projects` fallaba por ese desajuste de formato y tenía que recurrir al fallback REST. Ahora `list_projects()` responde `{"projects": [...]}`, igual que el resto de la familia `list_*`.
* Doc: `GET /info` documentaba `returns` de `/menus` y `/shortcodes` sin la clave `uso` que ambos endpoints devuelven de verdad — corregido, encontrado por el nuevo chequeo `scripts/verify-rest-info-contract.py` (ver abajo).
* Nuevo (equipo, no distribuido al cliente — carpeta `scripts/` excluida del ZIP): dos chequeos mecánicos de código puro, primeros del plugin que no dependen de que un agente los ejecute bien.
  - `scripts/verify-mcp-tools.py`: handshake MCP real (initialize + tools/list + tools/call) contra cada tool de solo lectura sin parámetros requeridos, falla si `structuredContent` no es un objeto — la clase de bug de este mismo changelog.
  - `scripts/verify-rest-info-contract.py`: cruza lo que `GET /info` promete en `returns` para cada endpoint GET (sin parámetros de ruta) contra lo que ese endpoint responde de verdad.

= 1.0.35 =
* Red de seguridad anti scroll-horizontal (`Editor_IA_Renderer::DEFENSIVE_CSS`): `html,body{overflow-x:hidden;max-width:100%}` + `box-sizing:border-box` en `*` ahora se inyecta siempre en el `<head>`, hardcodeado en el plugin — landing modo full, landing modo integrado, componente global en páginas nativas y las 6 Custom Template. Hasta ahora el fix (regla de oro #9 en design.md) dependía por completo de que el agente escribiera ese CSS defensivo en el proyecto; con un modelo económico o apurado podía saltearse, como se repitió en sitios reales (ver skill v4.47/v4.64). Se imprime antes que el CSS del agente, así que sigue pudiéndose sobreescribir puntualmente si un elemento concreto necesita overflow-x controlado.

= 1.0.34 =
* Ajustes > Plantillas propias: simplifica el texto de descripción (ya no lista las 6 plantillas por nombre, las secciones/checkboxes de abajo ya lo dejan claro) y elimina la caja informativa sobre el Componente Global (redundante con el resto de páginas nativas del sitio).

= 1.0.33 =
* AJUSTES_MCP.md: nueva nota junto a la sección de acceso FTP/SFTP/SSH — si el agente necesita abrir wp-admin en un navegador (ej. verificación visual), usar siempre un navegador real o herramienta de automatización de navegador, nunca un cliente HTTP crudo sin cabeceras. Motivo: algunos firewalls (Wordfence) bloquean por IP las peticiones POST con User-Agent y Referer vacíos por ser el patrón típico de un bot — un navegador real siempre manda esas cabeceras y evita el falso positivo. Redactado en tono documentación (no orden), mismo criterio que el resto del archivo.

= 1.0.32 =
* Fix: Custom Code — un snippet PHP con error (ParseError, fatal, excepción) quedaba con el aviso "Snippets con errores de ejecución detectados" en pantalla para siempre, incluso después de corregir el código y que volviera a ejecutar bien. El registro de errores (`store_error()`) solo se borraba manualmente vía "Limpiar avisos", nunca solo. Ahora `execute_global_php()` y `execute_php_shortcode()` llaman a `clear_error()` en cuanto el `eval()` corre sin lanzar excepción, así el aviso desaparece solo cuando el problema ya no existe.

= 1.0.31 =
* Fix: las 6 Custom Template (Entrada, Categoría de entrada, Etiqueta de entrada, Producto, Categoría de producto, Etiqueta de producto) quedaban con el contenido pegado al borde izquierdo/derecho del navegador — el esqueleto PHP de fábrica no traía ningún padding/max-width lateral por defecto, a diferencia de una landing (donde el diseño CSS lo pone el propio agente). Se agrega la clase `.eia-custom-template-container` (`max-width:1200px; margin:0 auto; padding:0 24px`, misma receta que `.container` de `design.md`) al wrapper de cada una de las 6 plantillas, vía el CSS base ya centralizado en `Editor_IA_Custom_Templates::print_head()`. No requiere nada del agente ni de Custom Code — es el default de fábrica del plugin.

= 1.0.30 =
* Custom Template: nuevas plantillas de fábrica para Etiqueta de producto (`product_tag`, WooCommerce, `taxonomy-product_tag.php`) y Etiqueta de entrada (`post_tag`, WordPress core, `tag.php`) — pasan de 4 a 6 plantillas disponibles en Ajustes > Custom Template, mismo criterio incondicional que las 4 ya existentes. Producto/Categoría/Etiqueta de producto se enganchan a `template_include` (prioridad 11, después de WooCommerce); Entrada/Categoría/Etiqueta de entrada usan los filtros dedicados de WP core (`single_template`/`category_template`/`tag_template`, nuevo). Etiqueta de entrada comparte la misma columna de sidebar (`[eia_widget]`) que ya tenían Entrada y Categoría de entrada. `GET /info` (`environment.custom_templates`) y la tool MCP `editor-ia/get-info` ya reportan las 2 plantillas nuevas con sus hooks nativos.

= 1.0.29 =
* Ajustes > Custom Template: sacado el selector "Componente (header/footer/CSS/JS)" por plantilla — las 4 plantillas (Entrada, Categoría de entrada, Producto, Categoría de producto) usan siempre el Componente Global del sitio, sin vínculo propio. Fix de un bug real introducido junto con ese selector (v1.0.22): cuando una plantilla tenía un componente vinculado, el header/footer salía duplicado — una vez desde el vínculo propio de la plantilla (`print_head`/`print_foot`) y otra desde el mecanismo general de Componente Global (`Editor_IA_Renderer::setup_global_component()`, enganchado a `wp_body_open`/`wp_footer` en cualquier página nativa que no sea una landing full-mode, sin excluir estas). Como el editor solo permite un Componente Global por sitio de todas formas, el selector por plantilla no aportaba nada real. Se agrega `Editor_IA_Custom_Templates::will_serve_current_request()` para que `setup_global_component()` no se enganche en páginas que va a servir una Custom Template (que ya inyecta el Componente Global directo en su propio shell). Removido el endpoint `PUT /custom-templates/{key}/component` (ya no aplica) y `Editor_IA_Custom_Templates::get_component()`/`set_component()`; `GET /info` deja de reportar `environment.custom_templates.plantillas.{key}.componente`.

= 1.0.28 =
* Ajustes > Custom Template: el selector "Componente (header/footer/CSS/JS)" de cada plantilla (Entrada, Categoría de entrada, Producto, Categoría de producto) ahora arranca preseleccionado en el Componente Global del sitio (el mismo que ya se usa en páginas nativas vía Condiciones), en vez de "— Ninguno —", cuando esa plantilla todavía no tiene uno elegido explícitamente. Se agrega `Editor_IA_Conditions::get_global_component()`. No cambia el comportamiento en vivo hasta que el admin guarde: sigue pudiendo elegir otro componente o dejarlo explícitamente en "Ninguno" si esa plantilla no debe llevar header/footer.

= 1.0.27 =
* AJUSTES_MCP.md: el paso 0 ahora recomienda explícitamente guardar la conexión MCP como persistente y con alcance solo al proyecto actual (no en la config MCP global del cliente), y agrega .gitignore tanto del archivo de configuración del cliente como del propio AJUSTES_MCP.md — ambos quedan con la contraseña de aplicación en texto plano. No se hardcodea la ruta de config por cliente (`.codex/config.toml`, `.mcp.json`, `.agents/mcp_config.json`, etc.): cada agente ya la conoce para su propio formato, y esa lista crece con el tiempo.

= 1.0.26 =
* Reemplaza el sidebar nativo de WordPress agregado en 1.0.25 para Entrada/Categoría de entrada: se probó en vivo que asignar widgets vía la API REST nativa (wp/v2/widgets) puede perderlos silenciosamente en sitios con varios sidebars registrados (guardados en "Widgets inactivos" en vez del sidebar pedido) — bug de fondo de WordPress al reconciliar `retrieve_widgets()`, reproducido igual contra un sidebar propio de Astra, no algo de Editor IA. Se saca por completo `register_sidebar()`/`dynamic_sidebar()` (ya no aparece nada nuevo en Apariencia > Widgets).
* Nuevo shortcode `[eia_widget type="TIPO" instance='{"campo":"valor"}']`: renderiza cualquier widget nativo o de un plugin (ej. WooCommerce) de forma directa vía la función core `the_widget()`, que no depende de sidebars para nada — usable en cualquier lado (Custom Code, header/footer de un componente, o el contenido de sidebar de una Custom Template).
* Nuevo `PUT /custom-templates/sidebar-content`: setea el contenido (shortcodes/HTML, típicamente uno o más `[eia_widget]`) de la columna de sidebar compartida entre Entrada y Categoría de entrada. Si queda vacío, la columna no se imprime.
* `GET /info` reemplaza `environment.sidebars` por `environment.widgets`: mantiene el catálogo real de tipos de widget del sitio (`widget_types`, vía `wp/v2/widget-types`) y documenta el nuevo flujo por shortcode en vez de la API nativa de asignación (que queda desaconsejada explícitamente).

= 1.0.25 =
* Custom Template de Entrada y Categoría de entrada ahora soportan sidebar: el plugin registra su propio widget area ("Entrada y Categoría de entrada (Editor IA)", Apariencia > Widgets) que funciona igual sin importar el theme activo — no depende de que el theme registre sidebars propios (Astra sí trae los suyos, ej. "Barra lateral de WooCommerce"; el theme Lienzo, en cambio, hoy no registra ninguno). La columna de sidebar solo aparece si el admin le asignó al menos un widget; si está vacía, la plantilla se muestra a una sola columna.
* `GET /info` agrega `environment.sidebars`: lista todos los sidebars registrados en el sitio ahora mismo (id, nombre, si tiene widgets asignados), detectados de forma genérica vía el global nativo de WordPress — sin ningún mapeo hardcodeado por theme. `environment.custom_templates.plantillas.{key}.sidebar` reporta el id del sidebar que usa cada plantilla (hoy solo Entrada/Categoría de entrada).

= 1.0.24 =
* Ajustes > Custom Template: las filas de Producto y Categoría de producto ahora se ocultan por completo cuando WooCommerce no está activo, en vez de mostrarse deshabilitadas con un aviso — el toggle vuelve a aparecer solo con recargar la página una vez que WooCommerce se instala. También se reordenó la lista: Entrada y Categoría de entrada (siempre disponibles) van primero, Producto y Categoría de producto (dependen de WooCommerce) quedan al final.

= 1.0.23 =
* Ajustes: la etiqueta de la key mostrada ahora dice "Site Key MCP Server" en vez de "Key de MCP Server" — ajuste menor de texto.

= 1.0.22 =
* Custom Template ahora se puede vincular a un componente (header.html/footer.html/style.css/script.js) para el look de la plantilla, separado del PHP de Custom Code (que sigue siendo el lugar para la lógica/contenido dinámico enganchado a los hooks nativos). Nuevo endpoint `PUT /custom-templates/{key}/component` (agente, vía API) y selector nuevo en Ajustes > Custom Template (wp-admin). `GET /info` reporta el vínculo en `environment.custom_templates.plantillas.{key}.componente`. `script.js` es un archivo nuevo y opcional para componentes — hasta ahora solo se leían header.html/footer.html/style.css; esta es la única vía que también lee script.js.
* Motivación: hasta ahora la única forma de meter CSS/JS en una Custom Template era un snippet Custom Code type=css/js (texto en base de datos, sin historial de revisiones). Reutilizar el mecanismo de componente le da al agente archivos reales con el mismo sistema de revisiones/rollback que ya usa en landings, en vez de un tercer formato nuevo que aprender.

= 1.0.21 =
* Ajustes > Tracking: se oculta del menú (mientras Google Site Kit cubra GA4 en el sitio) sin desactivar la funcionalidad — la página sigue accesible por URL directa y el guardado de GA4/GTM/Meta Pixel sigue intacto por si se necesita reactivar la opción propia más adelante.

= 1.0.20 =
* Fix: el render de landings (`maybe_render`/`maybe_render_on_page`) pasa de prioridad default (10) a 20 en `template_redirect`. Como ese render termina en `exit()`, si corría antes que otro plugin enganchado al mismo hook a prioridad 10, ese plugin nunca llegaba a ejecutarse. Caso real detectado: Google Site Kit registra su tag de GA4 en `template_redirect` (prioridad 10) y, por el orden alfabético de carga de plugins, nunca le tocaba turno en una landing del Editor IA — el tag sí aparecía en páginas nativas de WordPress, pero no en las landings. Con la nueva prioridad, Site Kit (y cualquier plugin con el mismo patrón) alcanza a registrar su tag antes de que nosotros cortemos la ejecución.

= 1.0.19 =
* Description del plugin (lista de plugins de WordPress) reescrita: "Motor de páginas y skills que tu agente de IA usa para editar y administrar WordPress. Compatible con Claude, Antigravity, Codex y otros." Refleja el alcance actual (skills, no solo landings) y deja lugar a más agentes/plugins sin listar nombres cerrados.

= 1.0.18 =
* Ajustes > Custom Template: texto aclara que quien completa el contenido es el agente de IA ("El agente pone el contenido con Custom Code"), no el usuario a mano; mismo criterio en el aviso amarillo.

= 1.0.17 =
* Ajustes > Custom Template: texto corregido de voseo argentino ("vos ponés", "si activás") a español neutro ("tú pones", "si activas") — criterio de redacción para toda la UI del plugin en adelante.

= 1.0.16 =
* Nombre visible del plugin: "Editor IA" pasa a "Editor IA Buhoflow" en la lista de plugins (Plugin Name) y en el encabezado de Ajustes ("Ajustes — Editor IA Buhoflow"). Slug, namespace REST, capability, CPT, prefijo de shortcodes, constantes EDITOR_IA_* y Text Domain quedan igual — son detalles internos, no el nombre que ve el usuario.

= 1.0.15 =
* Ajustes > Custom Template: texto de la pantalla reescrito, más corto y sin jerga técnica (ganchos/hooks) para un usuario no técnico; el detalle de "hooks nativos" queda solo en el comentario interno de cada archivo de plantilla.
* Orden del menú: "Ajustes" ahora aparece al final (después de Custom Template) en vez de antes.

= 1.0.14 =
* La tool MCP `editor-ia/get-info` (y su descripción en `tools/list`) ahora menciona explícitamente el estado de Custom Template — el dato ya venía completo en la respuesta desde la 1.0.13, faltaba que la descripción corta lo mencionara para que un agente que solo lee `tools/list` sin ejecutar la tool no lo pase por alto.

= 1.0.13 =
* Nueva sección Ajustes > Custom Template: plantillas de fábrica para Producto, Categoría de producto, Entrada y Categoría de entrada, desactivadas por default. Al activar una, reemplaza sin condición lo que WooCommerce/WordPress hubieran usado por HTML propio (mismo criterio "modo full" que las landings, sin CSS/JS del theme activo), conservando la secuencia exacta de hooks nativos de WooCommerce o los filtros dedicados de WordPress core, para que Custom Code (PHP, scope global) pueda engancharse ahí con vocabulario estándar en vez de nombres inventados. No agrega ninguna capacidad nueva de escritura de archivos: las plantillas son código fijo del plugin, y el contenido dinámico sigue pasando por el pipeline ya existente de Custom Code (validación de sintaxis, lista negra de funciones, auto-desactivación ante fatal error). `GET /info` reporta el estado y los hooks disponibles de cada plantilla en `environment.custom_templates`.

= 1.0.12 =
* Nuevo endpoint `GET /shortcodes` (lista `array_keys($shortcode_tags)`, los tags realmente registrados en el sitio ahora mismo) para que el agente pueda verificar, antes de recomendar o insertar cualquier shortcode que no sea uno de los documentados en `GET /info`, si ese plugin/función existe de verdad en este sitio en vez de asumirlo por conocimiento genérico de otros sitios. Motivado por un caso real: un agente recomendó el shortcode de un plugin buscador que nunca estuvo instalado. Documentado en `discover()` (sección de endpoints y advertencia `shortcodes_verificacion`).

= 1.0.11 =
* Fix: el offset de compensación de la admin bar para headers `fixed`/`sticky` (introducido en 1.0.2) nunca se aplicaba en la práctica — el script se imprime en `wp_head`, antes de que exista `<body>`, y capturaba `document.body` como `null` en ese momento; la primera llamada a `sync()` fallaba en silencio (`Cannot read properties of null`) y la clase `eia-at-top` nunca se agregaba. Ahora `sync()` lee `document.body` en cada invocación (con reintento en `DOMContentLoaded` si aún no existe) en vez de capturarlo una sola vez al declarar el script.

= 1.0.10 =
* Custom Code: activar, editar (código o estado activo) o borrar un snippet ahora dispara `Editor_IA_Cache::flush_site()` (misma clase que ya usa `PUT /file` para landings/componentes) cuando el cambio afecta contenido servido activamente. Antes, un snippet `scope: global` podía cambiar sin que un plugin de cache de página (WP Rocket, LiteSpeed, etc.) se enterara — visitantes reales seguían viendo la versión anterior hasta que expirara el TTL.
* `PUT /file` y `PUT/POST /custom-code`: la respuesta ahora incluye un campo informativo `recordatorio_testing` cuando el cambio ya quedó activo en el sitio, recordando verificar con capturas reales (skill `testing`) antes de reportar la tarea como lista.

= 1.0.9 =
* Custom Code: solucionado un error de incompatibilidad en los métodos REST (rest_create y rest_update) que usaban $request->get_json_params() en vez de $request->get_param(). En llamadas sintéticas del servidor MCP (abilities), get_json_params() podía retornar null o WP_Error, ocasionando un TypeError fatal en PHP 8.0+ al intentar evaluar claves de arreglo no existentes. Con get_param() la lectura de parámetros es 100% compatible tanto en llamadas HTTP externas como en invocaciones MCP internas.

= 1.0.8 =
* Ajustes > Accesos para agentes: el checkbox "Activar API de WooCommerce" ahora recuerda su estado entre visitas a la página (antes volvía siempre desmarcado aunque el usuario lo hubiera activado la vez anterior).

= 1.0.7 =
* Nuevo endpoint/tool genérico `PATCH /native/{id}/meta` (ability `editor-ia/set-native-meta`) para escribir custom fields de posts/páginas NATIVAS de WordPress. Delega en el propio wp/v2/{tipo}/{id} vía rest_do_request() en vez de reimplementar permisos o sanitizado — sirve para Yoast SEO, ACF (con "Show in REST API" activo) o cualquier otro plugin que registre sus campos con show_in_rest, sin hardcodear nombres de campos ajenos en el plugin. Reemplaza la instrucción anterior del skill `seo` de armar el PATCH a wp/v2 a mano.
* Detecta y reporta explícitamente (campos `no_guardadas`/`aviso` en la respuesta, o error 400 si son todas) las claves enviadas que WordPress ignora en silencio por no estar registradas para ESE post_type específico (caso real detectado en pruebas: Yoast SEO 27.9 solo registra sus campos para el tipo "post", no para "page" — sin este chequeo la respuesta era 200 con el valor en null, un falso éxito).
* CORS: agregado PATCH a `Access-Control-Allow-Methods` (faltaba desde que se armó la cabecera, sin impacto hasta ahora porque ningún endpoint usaba ese método).

= 1.0.6 =
* Preparación para una eventual publicación en WordPress.org: renombrado el slug/archivo principal del plugin de `editor-ia` a `editor-ia-facilwp` — carpeta (`editor-ia/` → `editor-ia-facilwp/`), archivo principal (`editor-ia.php` → `editor-ia-facilwp.php`), header `Text Domain` y las 74 llamadas de traducción (`__`, `_e`, `esc_html_e`, etc.) actualizadas para coincidir con el nuevo slug. Necesario porque WordPress.org exige que el Text Domain coincida con el slug final para que el sistema de traducciones cargue los `.mo` automáticamente. Sin cambios en el namespace REST (`editor-ia/v1`), capability, CPT, prefijo de shortcodes (`eia_`) ni constantes `EDITOR_IA_*` — son detalles internos que no afectan a WordPress.org y que hubieran arrastrado toda la documentación/skills sin necesidad. El plugin todavía no se envía a publicación en WordPress.org; este cambio es solo preparación.

= 1.0.5 =
* Custom Code: si un snippet `type:php` falla la validación de sintaxis y el código contiene patrones exclusivos de JS (`document.`, `.setAttribute(`, `addEventListener(`, `querySelector(`, etc.), el error ahora incluye una pista de que el tipo correcto probablemente sea `type:js` — el modo PHP `global` corre en `init`, antes de que exista el HTML de la página, así que no puede modificar DOM ya renderizado.
* Ajustes > Accesos para agentes: simplificado el label del checkbox de WooCommerce, quitando el detalle de permisos entre paréntesis que quedaba redundante.

= 1.0.4 =
* GET /info ahora reporta `environment.yoast_seo` (activo, versión, y si sus campos meta están registrados como editables vía REST) — informativo, mismo patrón que Astra/WooCommerce/Elementor. No agrega ninguna tool nueva: la edición de título/meta description de contenido nativo de WordPress con Yoast activo ya es posible con la API REST estándar (PATCH /wp/v2/posts|pages con meta._yoast_wpseo_title / meta._yoast_wpseo_metadesc), documentado en el skill `seo`.

= 1.0.3 =
* GET /info ahora reporta `otros_servidores_mcp`: detección genérica (sin lista de plugins hardcodeada) de servidores MCP de terceros activos en el sitio — servidores dedicados con ruta REST propia (cualquier plugin que registre la suya vía wordpress/mcp-adapter, ej. Astra) y el gateway compartido de WordPress para plugins que solo registran WP Abilities sin servidor propio (ej. WooCommerce, Yoast SEO), listando las abilities detectadas de cada uno.

= 1.0.2 =
* Fix: el offset de compensación de la admin bar para headers fijados/sticky ahora solo se aplica mientras la página está sin scrollear (antes era permanente vía CSS `!important`, y hacía que el header terminara flotando a mitad de página en vez de quedar pegado al viewport al hacer scroll). Afecta solo a usuarios logueados con la admin bar visible.

= 1.0.1 =
* Ajustes > Accesos para agentes: reescrito el label del checkbox de WooCommerce (de pregunta a frase de acción directa), más claro sobre qué habilita.

= 1.0.0 =
* Primer lanzamiento público. El desarrollo interno previo (alpha, no distribuido) queda archivado como referencia del equipo en backups/v3.1.0-pre-1.0.0-reset/CHANGELOG.txt.
* Servidor MCP nativo (Abilities API de WordPress) para que un agente de IA administre el sitio vía tools estructuradas, con fallback completo por API REST clásica para entornos que no pueden hacer POST JSON-RPC.
* Motor de páginas/landings: modo full (HTML/CSS/JS propio, cero interferencia del theme) y modo integrado (usa get_header()/get_footer() del theme activo).
* Sistema de componentes reutilizables (header.html, footer.html, style.css) entre landings, y Componente Global para inyectar header/footer en páginas nativas de WordPress (blog, archivo, single, page) sin afectar las landings del plugin.
* Compatibilidad de theme para el Componente Global: remoción directa de hooks nativos (Astra) en vez de ocultar con CSS, con fallback CSS para temas sin adaptador propio.
* Editor de textos desde el admin de WordPress (meta box), sin tocar código — preserva HTML/formato inline.
* Sistema de revisiones automáticas por archivo (hasta 5 por archivo) con rollback vía API.
* SEO por proyecto (título, meta descripción) con desactivación automática de la salida de Yoast SEO / Rank Math en esas páginas para evitar duplicados.
* Biblioteca de medios de WordPress integrada: subida y listado con todos los tamaños generados, srcset/sizes automático y optimización de imágenes (lazy loading, fetchpriority en la candidata a LCP) sin que el agente tenga que escribirlo a mano.
* Compatibilidad con plugins de cache de página (WP Rocket, WP Super Cache, W3 Total Cache, LiteSpeed Cache, etc.): invalidación automática al editar vía API o admin.
* Custom Code: snippets de PHP, CSS y JS con modos de ejecución shortcode o global, con validación de sintaxis y bloqueo de funciones peligrosas para el caso PHP.
* Integración WooCommerce: shortcode [eia_cart] (carrito nativo con drawer lateral, sin dependencia de theme) y acceso a la API REST de WooCommerce para agentes.
* Sistema de condiciones granular para asignación de componentes.
* Menús dinámicos de WordPress vía shortcode y endpoint dedicado.
* Instrucciones del agente servidas en vivo desde un servicio central (nunca se descargan a disco), organizadas en núcleo + skills especializados por área, con verificación de instalación por dominio.
* Detección informativa de Elementor y Astra (sin tools ni flujos asociados).
