Nacho vio un post vivo lleno de emojis y pidió rehacerlo — y que los publicados llevaran botón para eso. Construido: en el detalle de un artículo PUBLICADO, «🔁 Rehacer» pregunta qué está mal y encarga al Redactor la reescritura COMPLETA con el estilo de la casa (la única excepción permitida a la doctrina de injerto, y solo existe vía ese botón): mismo título/meta/slug, datos del vivo verificados, cero emojis, mínimo 1000 palabras. El resultado entra de BORRADOR y el post vivo no cambia hasta que lo apruebes. De propina, el bug más gordo del día: al aprobar un borrador de refresh, Simón solo publicaba la META — el cuerpo trabajado jamás llegaba al post vivo. Arreglado, y blindado con una revisión adversarial de 22 agentes que confirmó 19 minas antes de desplegar: jamás pisar un post por secciones (y ante una lectura dudosa, no tocar: prueba positiva o nada), el frontmatter nunca llega al post, un candado de frescura que se niega a pisar el vivo si otro carril lo tocó después del borrador, verificación con huella que distingue de verdad el cuerpo nuevo del viejo, memoria de fallos (al 3º se para y lo mira un humano, nada de reintentar eternamente contra un error determinista), y el encargo de rehacer no puede ser secuestrado por las rutinas de injerto ni pisarse con el borrador de otro encargo del mismo post.

Dos órdenes directas de Nacho aplicadas en los cuatro sitios donde se redacta (artículos nuevos, refresh, mini-artículos del linkbuilder y frases de injerto): CERO emojis en todo lo publicable y ninguna sección «Introducción»/«Conclusión» — huella de IA pura. Y a petición suya, consulta formal a los tres especialistas del Open Brain (SEO, Copywriting/Edición y AIO/GEO) con tres agentes en paralelo: sus 24 reglas, fusionadas, entraron al estilo de la casa. Las que más pesan: cada sección abre respondiendo su pregunta en un párrafo autocontenido de 40-70 palabras (los motores de IA citan secciones sueltas, no posts — doctrina común de los tres); secciones de 100-300 palabras que se entienden arrancadas del texto; lo más citable en el primer 30% y un dato concreto también en el cierre; cifras siempre con año y fuente PRIMARIA (las volátiles, como rango); una cita textual atribuida por pieza; cubrir entidades en vez de repetir la keyword (el stuffing RESTA visibilidad en IA); y el catálogo anti-huella de IA: sin «no es solo X, es Y», sin hedging, sin tríos compulsivos, sin negritas mecánicas, y en español sin gerundio de posterioridad ni Title Case.

La estampa que amargó el día: una tarjeta aprobada a mediodía seguía en Aprobadas por la noche… con el trabajo HECHO desde hacía horas (el borrador existía y llevaba el enlace encargado). La causa: el cierre de las propuestas de refresh dependía de que lo recordara el AGENTE tras entregar, y el carril express — que entrega directo, sin agente — no pasaba por ahí: su tarjeta quedaba «aprobada» para siempre, mintiendo. Arreglo de raíz: el cierre vive ahora en el SERVIDOR, en el momento exacto de recibir la entrega, para TODOS los caminos presentes y futuros — la propuesta pasa a «aplicada» con verificación pendiente y el verificador re-mira el enlace contra la web viva cuando el borrador se publique. Regla grabada: quien RECIBE la entrega cierra la tarjeta; jamás depender de que el que entrega se acuerde.

Un injerto de encargo — una frase con un enlace en un post vivo — no necesita un agente de 15-35 minutos: necesita código y UNA llamada al modelo. El carril express se dispara con el timbre del aprobar: baja el post por el MCP, comprueba que el enlace no esté ya, le pide al modelo barato que elija el párrafo y escriba la frase (con reintento si elige mal: la guardia rechaza listas, títulos, tablas y código), inserta por código solo en párrafo real y entrega el borrador con la frase injertada. Probado en vivo: aprobada a las :45:05, borrador entregado a las :45:55 — 50 segundos. Blindado con la revisión adversarial de rigor (14 hallazgos, 2 críticos corregidos antes de desplegar): marcas persistentes contra el doble trabajo, respeto absoluto al agente cuando ya está escribiendo esa pieza, y a los 2 fallos la hereda el agente de siempre. Las cuarentenas del agente entran también al express: son sus mejores clientas.

Nacho lo cazó a la primera: «ayer blindaste todo… pues falla». Tres candidatos de artículo APROBADOS llevaban más de una hora sin que nadie los tocara — habían entrado por una puerta que no dejaba la marca interna, y todas las contramedidas de ayer dependían de esa marca; el vigilante de salud los cantaba, pero cantar no es hacer. Lección aplicada de raíz: las contramedidas ya no dependen de marcas sino del ESTADO — todo lo aprobado pendiente de generar, sin marca o con ella, se detecta y se dispara solo en el siguiente tick; un disparo sin entrega en 45 minutos se re-dispara; al tercer intento sin entrega pasa a cuarentena con motivo visible (reintentar eternamente es quemar dinero). Además: el verificador de entregas ya no solo detecta las «aplicadas» que la web desmiente — a los 3 rojos las REABRE para que el ciclo las re-haga (una sola reapertura; si vuelve a fallar, se para y lo mira un humano), y se apagó una falsa alarma que llevaba días sonando cada 15 minutos («el despachador no corre» con el despachador corriendo: un tipo de dato mal parseado — una alarma que siempre suena es peor que ninguna). Verificado en vivo: al primer tick el rescate cazó los 3 huérfanos y una cuarta recién aprobada, y la primera quedó entregada en minutos.

Consultado el MCP: el blog ya admite portada por post (campo image) e imágenes dentro del cuerpo (markdown), y las actuales viven en el servidor de medios de BreatheCode — Nacho eligió alojar ahí las nuevas (opción 2). Construido: conexión mínima en Conexiones → «BreatheCode (Medios)» con el login alojado (la contraseña se teclea en la página de BreatheCode, el panel solo guarda el token — intenta capturar el token PERMANENTE de la academia, que no caduca), proxy de subida para Simón (dedup automático por hash, URL pública estable del mismo formato que las portadas actuales) y aviso en salud 48 h antes de que caduque un token de login. CIRCUITO COMPLETO Y VERIFICADO el mismo día: Nacho conectó su cuenta (token válido hasta ago-2027), el Redactor de Simón ganó la herramienta subir_media y el flujo de portadas (portada de marca por artículo + como mucho una ilustración, ALT = keyword, dentro del borrador para revisión), y la prueba de fuego pasó de punta a punta — Simón generó una portada de marca con Gemini y quedó servida en la URL pública oficial de medios (comprobada en vivo: JPEG 800×400). Bonus del mismo repaso: el verificador de entregas daba 5 rojos falsos en plantillas que renderizan el cuerpo en el navegador (el enlace viaja en el JSON de la página, no como href en el HTML crudo) — corregido: solo la ausencia total del enlace es fallo. Y dos mejoras más a petición de Nacho, probadas en vivo: las portadas ahora integran UN MOTIVO del tema del artículo (monedas para salarios, portátil con código para bootcamps…) sobre el fondo de marca, con triple candado para que la IA no pinte texto; y TODAS las imágenes de marca salen selladas con la MARCA DE AGUA del logo oficial (esquina inferior derecha, translúcida), compuesta por la propia app sin dependencias nuevas.

Tres aprobaciones cayeron 13 segundos después del último disparo y el anti-rebote de 45s se tragó sus avisos: quedaron a merced del tick de 5 min. Arreglo de raíz, no parche: (1) el disparo inmediato ahora es un TIMBRE que jamás olvida — 500 aprobaciones seguidas = ni un aviso perdido, el bucle repite pasadas hasta que el timbre calla; (2) el clic «Generar» nunca más contesta «espera a que termine»: entra EN COLA con marca persistente + vigía, y se dispara solo al liberarse el carril (sobrevive a deploys: el tick re-arma huérfanos desde la base); (3) el flujo de artículos queda definitivo y sin esperas muertas: Por generar → «Generar» deja el borrador → lo apruebas → Simón lo publica al momento; (4) vigilante «al momento» en salud: nada aprobado >20 min con Simón libre — si pasa, alarma visible Y re-disparo automático (con tope de 3 intentos: si no surte efecto, lo canta y pasa el testigo al humano). Antes de desplegar, el parche pasó una revisión adversarial de 20 agentes: 16 hallazgos, 12 confirmados y corregidos — cerrojos atómicos contra el doble disparo del Redactor (doble gasto y artículos duplicados), nada se aprueba ni publica sin tu OK (una entrega con encargo inventado se queda en borrador), clics indelebles ante el freno de gasto o Simón dormido, y sesiones de base cortas en las esperas largas.

Tras cazar una «aplicada» sin el trabajo hecho, auditoría TOTAL de las 113 aplicadas contra la web viva: 99 verificadas de verdad, 6 esperando en borradores buenos, 2 mentirosas devueltas a la cola y rehechas (una ya re-verificada en vivo), 2 inconclusas (no se reabre a ciegas) y 4 sin prueba HTML fiable. Y para siempre: contrato del encargo en la ingesta (un borrador sin SU enlace no entra), verificador en vivo cada pocos minutos, y el check «Lo aplicado está DE VERDAD en la web» en el panel de salud.

Página nueva «Extensión Chrome» en Settings, visible SOLO para el owner: genera el código de emparejamiento de un solo uso (caduca en 10 minutos, con cuenta atrás y copiar al clic), con los 3 pasos para instalarla (descargar desde Linkbuilder, cargar descomprimida, pegar el código). El código lo emite el motor a través del backend: el navegador jamás ve credenciales, y el motor solo acepta la petición del dueño autenticado.

Dictada por Nacho tal cual: «cuando apruebo, Simón trabaja; si está ocupado, espera a que se desocupe; pero nada más». Antes, aprobar disparaba solo el ciclo mecánico al instante y el resto esperaba al reloj de 5 minutos; y una aprobación masiva se quedaba a medias (el ciclo aplica ~15 por pasada). Ahora, en los TRES sitios donde se aprueba (Aprobar, Artículos y el MCP), el clic arranca un trabajador que: (1) mira si Simón está ocupado y, si lo está, espera con paciencia (sondeo cada 20 segundos, hasta 90 minutos) a que se libere; (2) dispara los DOS carriles (mecánico y barato) saltándose el margen de gracia; (3) si aprobaste 500 seguidas, repite el baile ronda a ronda hasta vaciar la cola — contando fresco en cada ronda, así recoge también lo que apruebes mientras trabaja; (4) freno anti-martilleo: si una pasada no baja la cola, para y lo heredan el reloj y el renovador. Un solo disparador: se retiró el aviso viejo para que jamás corran dos ciclos aplicando lo mismo a la vez.

Nacho preguntó lo que había que preguntar: «¿no hay nada que verifique el trabajo?». Un enlace encargado salió «✓ Aplicada», el borrador del Redactor ni siquiera traía el enlace (el control genérico se conformaba con que hubiera *algún* enlace interno, no *el* encargado) y la página viva seguía sin él — tres verdes y cero trabajo. Tres piezas nuevas: (1) CONTRATO DEL ENCARGO en la ingesta: si la propuesta pedía un enlace concreto, el borrador que no lo trae NO ENTRA (rechazo con motivo y reintento del Redactor); (2) VERIFICADOR DE ENTREGAS: cada pocas horas baja la página viva de las aplicadas de enlaces y comprueba que el href está de verdad (si el cambio viaja en un borrador aún sin publicar, queda «pendiente de publicación» y se re-mira al publicar); (3) check nuevo en «¿Funciona todo?»: «Lo aplicado está DE VERDAD en la web» — canta con nombre las que la web desmiente. Auditoría retroactiva de las 8 entregas de la vía Redactor: 7 tenían el trabajo bien hecho en su borrador; 1 no (el post de frameworks) — borrador rechazado con motivo y tarea devuelta a la cola, que ahora la rehará bajo el contrato nuevo.

Última clase de atasco de la saga: cuando el sistema convertía un enlace aprobado en encargo del Redactor, la conversión salía SIN peso → caía como refresh «completo» a «Por generar», un carril que espera un clic humano que nadie sabía que debía dar. Diez tareas aprobadas esperando en un carril invisible, más un generador creando DUPLICADOS (hasta 3 copias de la misma tarea, cada una pidiendo tu aprobación). Arreglos: (1) toda conversión al Redactor nace ya como injerto LIGERO con el destino real extraído del enlace original (antes podía quedar «enlace a » vacío) — el carril barato la ejecuta sola; (2) el renovador AUTO-SANA las que ya estaban mal (10 migradas en el acto) — corre cada 5 minutos, así que esta clase no puede volver a acumularse; (3) duplicados colapsados (se queda la más antigua, el resto rechazada con nota de a cuál duplica) y dedup en la conversión. Verificado: la cola pasó de 15 quietas a 1 mecánica en ventana normal + 10 ligeros en el carril automático.

Un post enlazaba «programa de NodeJS» a una página que nunca existió (/es/blog/landing/curso-node-js, soft-404). El barrido lo cazaba pero lo enrutaba a «rehacer artículo» — un rodeo: quien clica un ancla de curso/programa busca la OFERTA. Ahora, si el ancla del enlace roto promete curso/programa/bootcamp/carrera, el barrido crea una tarea de reparación por cada página de origen (cambia solo el href hacia la money page, el ancla queda igual) que pasa por Aprobar y la aplica Simón por MCP. Los destinos rotos sin ancla comercial siguen como candidato de artículo. De paso, cazado un bug de duplicados: la clave de dedup comparaba el slug largo contra el corto guardado y cada barrido creaba otro candidato idéntico — arreglado y duplicado borrado. Primera tarea real ya en Aprobar: el enlace del post de NodeJS al programa full-stack.

Un 301 aprobado (consolidar dos posts que competían) se quedó en bucle: el CMS exige confirmación para redirigir una página VIVA, el aplicador no la pasaba, el «ok» engañaba y la verificación lo tumbaba una y otra vez — con la tarjeta encima etiquetada DEV y el chip prometiendo «la aplica Simón». Arreglado con CINCO capas: (1) el aplicador distingue consolidaciones aprobadas (tu OK es la confirmación humana) y solo entonces pasa la confirmación del CMS — el veto a ciegas sigue para todo lo demás; (2) una prueba del despliegue de Simón aborta si alguien rompe ese contrato; (3) el renovador re-arma UNA vez las consolidaciones que cayeron por este bug; (4) la puerta de despliegue del backend rechaza cualquier kind aplicable por MCP etiquetado como DEV (mentira de etiqueta); (5) la UI gana el estado «⏳ Intentada — la verificación no la dio por buena» con el motivo. El 301 de bootcamp-de-programacion está aplicado y verificado en la web viva.

Tras investigar OpenRouter con 4 agentes (caching, enrutado por precio, modelos alternativos, fees): (1) la ESCRITURA de artículos pasa de Sonnet a GLM-5.3-Flash (~40× más barato por token) — compensado con un bloque de ESTILO calcado de los 5 posts con más tráfico del blog (H2 con gancho, responder en 3 frases, ejemplos numerados, tabla si compara, cifras con fuente, muletillas de IA vetadas), porque a un modelo flash hay que darle el estilo masticado; su primer artículo pasó el control de calidad a la primera. (2) El modelo mediano se sirve desde el proveedor barato (mismo modelo exacto, ~10 $/mes menos, con respaldo abierto). (3) Contador de tokens de caché real en el libro de gasto: la única prueba de que el caching funciona es ese número, no la bajada de coste. DESCARTADO con criterio: cambiar el modelo del bucle de agente (funciona rodado y el riesgo no vale 42 $/mes) y los modelos gratis para el bucle o el SDR (privacidad). El juicio crítico de seguridad sigue en Sonnet.

Simón tiene un freno duro de gasto diario: al llegar al tope rechaza todo el trabajo automático hasta mañana. Bien pensado — pero era INVISIBLE: los «Generar», la cola de Aprobar, todo rebotaba y el panel decía «Esperando a Simón» eternamente sin el porqué. Ahora el rechazo por freno sale en el banner del panel con el motivo y el remedio («se reanuda mañana — o sube el tope»), el registro del despachador dice la verdad (antes escribía «avisado» aunque el aviso fallara), y el tope queda en 5 $/día por decisión de Nacho.

Nacho aprobó un enlace editorial y la pantalla dijo «en cola, la aplica Simón» para siempre: en realidad el aplicador la había rechazado 3 veces (la propuesta nació sin frase-ancla mecánica) y estaba en cuarentena INVISIBLE. Tres arreglos: (1) un RENOVADOR corre en cada tick del despachador y barre todo lo aprobado atascado — si su error tiene regla, lo re-enruta a quien SÍ puede hacerlo (el Redactor escribe la frase que el aplicador mecánico no puede; Dev recibe lo que el MCP no puede tocar), y la verdad vive en la base de datos: un reinicio del servidor no le pierde trabajo; (2) el error de formato «falta Ancla:» pasa al Redactor al PRIMER fallo, sin quemar 3 intentos; (3) la página Aprobar ya no miente: una propuesta en cuarentena enseña «⛔ el aplicador la rechazó N veces» con su motivo real, y una re-enrutada enseña «↪ pasada al Redactor». Probado en vivo: la propuesta atascada de nodejs salió de cuarentena, se convirtió en injerto ligero y entró sola al carril barato.

El panel «¿Funciona todo?» llevaba HORAS caído por una variable muerta que compilaba perfecta, y la autocomprobación de cada 15 minutos moría en silencio (usaba un logger sin definir: fallaba hasta su propio manejador de errores). Nadie lo vio porque los despliegues eran a mano, sin puerta. Ahora AI Growth OS se despliega SOLO por desplegar-aigrowthos.sh, que: (1) pasa pyflakes al backend entero y se NIEGA a desplegar si hay un solo nombre sin definir — el barrido inicial cazó 15: el crash de salud, 13 llamadas a un logger inexistente y un MONEY_PAGES fantasma, todos arreglados; (2) compila todo; (3) etiqueta las imágenes vivas antes de construir; (4) tras desplegar, ejecuta un SMOKE en caliente dentro del contenedor (importa todos los routers y servicios y corre la revisión de salud entera contra la base real) y comprueba los endpoints por HTTP; (5) si CUALQUIER cosa falla, ROLLBACK automático a la imagen anterior. Probado en real: su primer despliegue se autorechazó por un fallo del propio smoke e hizo el rollback limpio — la puerta funciona incluso contra sí misma.

Nacho pulsó «Generar» en un refresh, Simón corrió y gastó modelo… y no llegó ningún borrador, sin un solo error a la vista. La causa: el Redactor pedía sus pendientes por el canal equivocado (el scope que a propósito esconde los refresh completos del ciclo mecánico), recibía lista vacía y se iba con «no hay trabajo». Arreglado y BLINDADO con cuatro capas para que la clase entera de fallo no vuelva: (1) el Redactor pide ahora exactamente sus tipos (kinds), no por scope; (2) una prueba nueva del despliegue de Simón se NIEGA a desplegar si alguien vuelve a romper ese contrato; (3) cada disparo de «Generar» queda grabado en la propuesta, y el panel «¿Funciona todo?» tiene un vigilante nuevo que a los 35 minutos sin borrador NI rechazo lo canta con nombre y apellidos — da igual cuál sea la causa futura; (4) si el backend le da lista vacía para un encargo con id concreto, el Redactor lo reporta como error a gritos en vez de «no había trabajo». Además, la marca «Generando…» del botón caduca a los 45 min: un run muerto ya no lo secuestra para siempre.

La sección «Qué hacer con lo que hay» de La web enseñaba candidatos a 301 y hubs por crear… y ahí se quedaban, sin ir a ningún sitio. Fuera de La web: ahora, al final de cada auditoría, los candidatos a 301 (dos URLs del mismo idioma compitiendo) entran como propuestas de redirección en APROBAR —tú das el OK y Simón las aplica por MCP, nada se aplica solo— y los hubs sin pilar entran como tickets de «crear hub» al tablero DEV (crear una página es estructura, no la puede hacer el MCP). Con dedup: lo ya propuesto o rechazado no vuelve a entrar. La poda (páginas sin impresiones) NO se convierte a propósito: sin fecha de publicación no se distingue «nadie la quiere» de «es nueva», y una poda mal hecha tira tráfico real.

La sección ③ del Panel enseñaba «Página sin optimizar» con detecciones del sistema viejo que no llevaban a ningún sitio. Fuera: los errores nuevos ya viajan SOLOS a su cola (Aprobar si lo aplica Simón por MCP, Dev si necesita manos, Artículos si hay que escribir) — el Panel no tiene que operar nada. En su lugar, la sección enseña LOS ÚLTIMOS ARREGLOS reales del diario: qué se aplicó o publicó, dónde, hace cuánto, con su etiqueta (ARREGLO·MCP / ARTÍCULO) y el detalle al desplegar. Con enlaces directos a las tres colas y al diario completo.

Los tickets de Aprobar y del tablero Dev llevan códigos de detector (SDT-01, CAN-01, GEO-26…) que hasta ahora solo el auditor entendía. Ahora hay un diccionario con apartado PROPIO en el menú (Settings → «Diccionario», ya no dentro de Usuarios), visible para cualquier usuario —un editor o un dev también leen códigos en sus tableros—, con los 31 códigos agrupados en 13 familias (metadatos, canonical, hreflang, enlaces internos, datos estructurados, GEO/AIO, contenido…), cada uno con su nombre, su porqué explicado en cristiano, su prioridad y QUIÉN lo arregla (🤖 Simón por MCP, 🧑‍🔧 el equipo Dev, o ✍️ el Redactor). Con buscador. Se lee del catálogo real del auditor, así que si mañana se añade un detector nuevo, aparece solo — no puede desincronizarse.

Dos perfiles nuevos en Usuarios: Editor (puede editar, aprobar y generar en Artículos, y nada más) y Dev (puede mover estados, verificar y decidir SOLO los tickets del tablero Dev). Ambos ven todas las páginas: su límite es de escritura, no de vista. De paso, dos arreglos gordos: (1) la lista de páginas de Settings era de una versión vieja del panel — ofrecía páginas que ya no existen y no dejaba conceder Artículos o Dev Team, por eso «dar permisos» parecía no hacer nada; ahora enseña las páginas reales del menú. (2) Dieciocho apartados del servidor aceptaban cambios de CUALQUIER usuario logueado, aunque fuera un viewer «solo lectura»: ahora toda escritura exige el nivel que toca (los perfiles de área solo en su área, el viewer en ninguna) y Simón sigue trabajando igual porque entra con su llave de administrador.

La app se relanzó limpia: 1.092 propuestas y 114 fichas de artículo a cero, y la cola reconstruida ya con TODAS las reglas nuevas. (1) Ningún borrador entra sin su LINKBUILDING INTERNO: mínimo 2 enlaces internos en artículo nuevo (la regla editorial: 1 al pilar de su hub con ancla de entidad + laterales a hermanos) y 1 en refresh; si la pieza tiene hub, el enlace a su pilar es obligatorio — lo comprueba el código al ingerir, como el mínimo de 1000 palabras. (2) Ninguna reparación propone un enlace roto: el destino se valida contra el sitemap; si es un índice con hijas vivas (como /en/location) no vale un sustituto «parecido». (3) Cuando falta la página de destino: si es del blog, se propone ESCRIBIR el artículo (entra a «Por generar»); si es estructura fuera del blog, va a Dev. (4) Botón ⟲ Reset en Aprobar y en Artículos (solo admin, doble confirmación) para volver a relanzar limpio cuando quieras.

Las dos colas de trabajo —«Aprobar» (lo que se aplica solo por MCP) y «Dev Team» (lo que necesita manos humanas)— tienen ahora un desplegable para filtrar por tipo de tarea. En Aprobar es muy útil porque ahí se mezclan cientos de propuestas de once tipos (actualizar artículo, enlace al comparador, reparar enlaces, poner ALT, redirecciones…): eliges un tipo y ves solo esos. El desplegable se rellena solo con los tipos que hay en cada pestaña y su número (p.ej. «Enlace editorial (212)»), y el filtro corre en el servidor, así que no miente aunque la cola sea larga. Dev Team lleva el mismo filtro para cuando entren varios tipos de ticket.

Las listas de Artículos (Borradores, Aprobados, Publicados y Rechazados) ahora se filtran por idioma (🇪🇸/🇬🇧) y por rango de fechas (desde/hasta), igual que «Por generar». El filtro corre en el servidor ANTES del límite de página —así no miente aunque haya cientos de artículos— y usa la fecha real de cada pieza: la de publicación si ya está en la web, la de alta si aún no. Cada fila enseña además su fecha, y un contador dice cuántos artículos casan con el filtro.

Ahora NADA se escribe solo: los refrescos, las herramientas nuevas que caza el radar (Discover 🔭) y los encargos de Alejandro (✍️) entran TODOS a Artículos → «Por generar» como candidatos, y no se crea ningún borrador hasta que tú pulsas «Generar». La lista se filtra por tipo (Refresh / Discover / Alejandro), por hub comercial y por rango de fechas, con desplegables que se rellenan solos con lo que hay. Cada candidato lleva su icono de origen, su hub y su fecha. Por dentro: los candidatos viven como propuestas en el backend (no en ficheros sueltos de Simón), con su hub derivado de la categoría; Simón los empuja con una herramienta nueva (aio_candidato) desde el radar y desde Slack; y el generador a demanda sabe escribir tanto un refresh de un post vivo como un artículo NUEVO (con enlace interno obligatorio al pilar de su hub). Se ha quitado el auto-disparo de refrescos del despachador: el gasto se controla no generando solo, no con un cupo. Probado de punta a punta en producción: un candidato Discover aparece, filtra por tipo y hub, y se limpia.

Tres mejoras en la página de Linkbuilder. (1) Un desplegable «Objetivos» lista las URLs de 4geeks con su keyword —lo que Simón envía en las rondas— con aviso si el perfil de anclas está sobre-optimizado (demasiada keyword de dinero, que Google penaliza). (2) «Reforzar» ahora pide la URL Y la keyword (ancla): eliges un objetivo de la lista o lo escribes, y Simón publica con esa ancla concreta. (3) La autopublicación diaria tiene tres modos —Mínimo, Medio, Máximo— que se adaptan solos al número de canales conectados y a la cadencia de cada medio, en vez de un número suelto. Además las tarjetas dicen de verdad cuántos enlaces son dofollow (pasan autoridad SEO) y cuántos nofollow, con el número real de cada uno, y cada artículo marca su rel claro. Publica siempre Simón con su navegador (lo que esquiva el antibot).

La página de Linkbuilder (debajo de Backlinks) tenía los fondos, bordes y textos oscuros cableados a mano, así que en modo claro se veía como un parche negro sobre el panel blanco. Ahora usa los tokens del tema como el resto del panel: en claro son tarjetas blancas con texto legible y sombras suaves; en oscuro se ve igual que antes. Los badges (idioma ES/EN, nofollow, caído) mantienen su color en ambos modos.

Red de seguridad para lo automático. En Artículos, cada borrador generado tiene «↩ Deshacer»: lo borra y, si era un refresh, devuelve su propuesta a «Por generar» para regenerarlo. Y en el Diario de aquí abajo, cada reparación ya aplicada a la web tiene «↩ revertir»: crea una tarea que devuelve la página a su estado ANTERIOR (guardamos el "antes" de cada cambio). Para no tocar la web viva a ciegas, el revert pasa por el mismo gate humano —aparece en Aprobar como «↩ REVERTIR» y tú lo confirmas—. Los cambios que REEMPLAZAN algo (meta, enlaces rotos, texto) se revierten intercambiando antes↔después; los que AÑADEN o CREAN (un enlace nuevo, un redirect) no se deshacen con un intercambio y van a Dev con el detalle para quitarlos a mano. Probado: repair_links y update_post revierten por Aprobar, link_editorial va a Dev.

La barra del tope (el slider de refrescos/artículos por día) tenía el fondo oscuro cableado a mano y en modo claro salía una franja negra — ahora usa los tokens del tema y se ve bien en claro y oscuro. Y en Artículos las tarjetas de arriba (Borradores, Aprobados, Publicados, Rechazados) son clicables como «Por generar»: pulsas una y filtra a ese estado, con la activa resaltada.

El detector viejo solo marcaba un enlace como roto si había CRAWLEADO la página destino y la vio muerta. Un enlace a un URL que no está en el sitemap —un typo (programos→programas), un post renombrado (what-is-buzz→…-jack-dorsey-slack-alternative), o un 301 que cae en OTRA 404 (soft-404 encadenado)— se colaba como si funcionara. Ahora el auditor valida CADA destino de enlace contra el sitemap y resolviéndolo de verdad (el mismo fetch que ya pasa el WAF). Cada roto se convierte en una propuesta con 3 opciones —redirect 301 / reparar el enlace / rehacer la página— y se enruta solo: con equivalente vivo va a Tareas, sin equivalente (falta el contenido) va a Dev. Verificado end-to-end: caza comparar-programos, programos-de-carrera/*, what-is-buzz y compañía, con el reemplazo correcto sugerido.

Los injertos ligeros (enlaces, citas, entradillas) usan ahora kimi-k2.5, el modelo intermedio: mucha mejor calidad que el barato de antes y una fracción del precio de Sonnet, que queda reservado para lo publicable de verdad. Probado: el router enruta el injerto ligero a kimi y entrega el borrador.

Nuevo modelo para controlar el gasto: el radar y los encargos de Alejandro siguen siendo automáticos, pero los REFRESCOS (reescrituras de posts que ya rankean, lo que usa el modelo caro) ya no se disparan solos. Se acumulan en Artículos → «Por generar» y tú pulsas «Generar con Claude» en el que quieras, cuando quieras. Se ha quitado de raíz el tope diario y el «en pausa hasta mañana» de TODAS partes (barra de actividad, resumen y el check de salud): ya no hay cupo que gestionar porque tú decides cada pieza. Probado de punta a punta: un injerto entregó su borrador de ~1.700 palabras en Artículos.

La barra decía «22 mejoras esperando a Simón, la más vieja de hace 41 min» y no bajaba nunca. Eran 22 ediciones de sección sobre páginas que NO son blog (login, how-to, ubicaciones…), que el MCP no puede tocar: Simón ya las había aparcado en cuarentena tras 3 intentos, pero el contador las seguía sumando como «en espera». La cuarentena se filtraba solo en los refrescos, no en las mecánicas. Ahora una tarea aparcada no cuenta como cola: la barra dice la verdad (0 mecánicas pendientes) en vez de fingir un atasco.

El refresco cuenta las palabras del artículo publicado con «curl … | wc» (la puerta de las 1.000 palabras). «wc» estaba permitido pero «curl» no, y en un comando encadenado deben estarlo TODOS: se bloqueaba la cadena entera y ningún refresco se entregaba. Dado permiso de solo-lectura a curl (Vigía ya lo tenía). Con esto el botón «Generar con Claude» entrega de verdad.

Un refresh aprobado no se aplica en la web: lo redacta Simón y cae de BORRADOR en Artículos para tu revisión. Por eso el mando del tope de refrescos/día se ha movido de la cola de Aprobar —que es solo lo que se aplica solo por MCP— a Artículos, junto al de artículos nuevos. Aprobar queda limpio para las mejoras mecánicas; Artículos gobierna lo que escribe el Redactor: artículos y refrescos.

El despachador disparaba el carril barato (modelo ligero) pero le pedía a Simón «los refrescos más viejos» sin decirle de qué peso, así que le tocaban los pesados —los que necesitan el modelo caro— y el barato no podía con ellos: se rechazaban por el mínimo de palabras y volvían a salir en bucle, sin entregar ninguno en horas. Ahora cada carril pide SOLO los suyos (Simón ya filtraba por peso; solo faltaba pasárselo). Confirmado: entrega en segundos.

El límite diario de refrescos es solo del modelo caro (Sonnet), el que gasta. Antes, al agotarlo —o mientras un refresh caro estaba en marcha— se paraba TODA la cola de refrescos, incluidos los ligeros, que cuestan ~30× menos y no gastan cupo. Ahora hay dos carriles con cerrojo propio: los ligeros (y las mecánicas) siguen avanzando siempre; solo los refrescos de Sonnet esperan a mañana cuando se acaba su cupo del día. Se demostró con pruebas: tope lleno → el ligero avanza y el completo espera; cupo libre → avanzan los dos.

Un TypeError en el despachador (llamaba al Redactor con un argumento de más en la firma) lo tumbaba en cada ciclo, así que NADA aprobado se aplicaba y la web decía «Simón no responde» aunque Simón estaba vivo y alcanzable por Tailscale. El aviso que se veía era el viejo, de cuando el Mac estaba apagado, congelado por el crash. Arreglado. Contramedida: si el despachador vuelve a romperse, la pantalla muestra el ERROR real del código en vez de dejar pegado el aviso de Simón — un fallo del código ya no se disfraza de «Simón caído».

Escribir cuesta 30 veces más con el modelo bueno que con uno normal, y 76 de las 100 tareas en cola solo pedían añadir una frase, unas citas o una entradilla. Ahora hay tres peldaños (ligero, medio y bueno) y cada encargo entra por el que le toca. Si el barato no da la talla, la tarea sube UN peldaño sola —nunca salta al caro— y salta un aviso si eso pasa demasiado, porque entonces el ahorro sería falso.

No es una lista cerrada que haya que ir ampliando: cuando llega una regla nueva, lee lo que PIDE el encargo. Si habla de actualizar cifras, verificar datos o montar una comparativa, va al modelo bueno; si es añadir una frase o unas citas, al barato. Ante la duda, al bueno.

Antes el tope paraba TODO, también lo barato, y la cola se quedaba quieta sin ahorrar casi nada. Ahora solo cuenta lo que escribe el modelo bueno: los encargos ligeros siguen saliendo aunque el cupo esté gastado. Mismo dinero, muchas más tareas al día. Y son dos topes separados: refrescos en Aprobar y artículos nuevos en Artículos.

Estaba clasificado como «rehacer el artículo», así que gastaba el modelo caro, se comía el cupo del día y encima podía chocar con el mínimo de palabras. Es una edición puntual: ahora la hace el ciclo directo sin IA, leyendo la palabra clave del artículo. Verificado: 14 aplicadas en el primer ciclo.

Ponía «100 refrescos esperando» cuando solo 24 usaban el modelo caro y el resto eran injertos baratos; y contaba como «esperando a Simón» lo que en realidad esperaba a mañana por tu propio tope. Ahora separa mejoras, injertos ligeros y refrescos, y dice cuándo algo está en pausa y por qué.

La frase a enlazar se elegía mirando la página publicada, pero se aplica sobre el texto original del gestor: si ahí había un enlace o formato en medio, no coincidía nunca y la propuesta moría tras tres intentos. Ahora se descartan las frases que ya son enlace, las que llevan uno dentro y las que traen comillas o guiones tipográficos; un fallo de este tipo pasa directo al Redactor para que escriba una frase nueva, sin reintentos; y salta un aviso si vuelven a proponerse frases imposibles.

Las 28 de enlaces fallaban todas por lo mismo: la frase que iban a enlazar YA era un enlace en la página, y un enlace dentro de otro no existe. Ahora el selector descarta el texto ya enlazado. De las recuperadas, 14 eran duplicadas del mismo post (se habrían pisado entre ellas) y 6 pasan al Redactor para que escriba una frase donde encaje. Las 19 restantes eran páginas que no son blog: a Dev Team.

Revisión con refutación adversarial de todo el código nuevo. Entre lo cazado: la alarma de atasco no podía saltar nunca (dos espacios de trabajo compartían un mismo contador), los enlaces al dominio viejo se daban por sanos, y los avisos de salud medían «cuándo se aprobó» en vez de «cuándo se aplicó», así que decían 12 donde había 67.

Sus tareas programadas morían con «textoDegenerado is not defined» (la función estaba declarada dentro de otra y la llamaba una tercera): 18 ejecuciones seguidas perdidas, una con 71 pasos de trabajo ya hecho. Y la métrica de ENTREGA valía 0 SIEMPRE, porque el evento que la alimenta no mandaba el nombre de la herramienta: las alarmas de «corrió pero no entregó» nunca podían saltar. Los dos pasaban node --check.

probar-simon.js: 8 comprobaciones sobre el árbol del código y los contratos con esta app (funciones fuera de su ámbito, kinds sin aplicador, campos que los dos lados tienen que compartir). Corre como paso 1 del despliegue y lo ABORTA si algo falla. Sintaxis correcta no es lo mismo que código que funciona.

Una propuesta mandaba 13 enlaces —mentorías, sobre nosotros, código de conducta— los 13 a la home. Ahora el código busca la página que de verdad cubre el tema (mentorías → GeekPAL, sobre nosotros → Sobre la Academia, un bootcamp → su programa de carrera) y descarta los que no estaban rotos: 4 de esos 13 estaban vivos, y uno ni siquiera era un enlace.

Llegaban refrescos de 422 palabras sobre posts vivos de 800, que es adelgazar una página que ya rankea. El guardarraíl está en el código, no en las instrucciones: si no llega al mínimo no se guarda, su propuesta NO se cierra y vuelve a la cola. Tope de 3 intentos para no reintentar en bucle gastando modelo caro.

Barra deslizadora en Aprobar y en Artículos (defecto 5 · 0 para parar · sin límite a la derecha). Solo frena los refrescos, que son los que cuestan dinero: las mejoras mecánicas siguen sin tope. Lo aprobado nunca se pierde, se aplaza al día siguiente.

Simón pedía las 100 primeras propuestas y los 128 refrescos aprobados las llenaban enteras, así que contestaba «no hay nada que aplicar» con 108 esperando. Ahora pide solo los tipos que sabe aplicar, y salta una alarma si hay mejoras aprobadas y ninguna se aplica en una hora.

40 propuestas de texto alternativo apuntaban a páginas de campus y programas, que no son blog: el CMS las rechazaba una y otra vez y taponaban la cola (89 intentos quemados). Ya no nacen, las existentes están en Dev, y cualquier error que signifique «esto no se puede hacer nunca» reclasifica la propuesta al primer intento.

Rediseño del sistema de temas: paletas claro y oscuro premium sobre los mismos tokens (superficies frías por capas, contraste de texto AA, acentos legibles, estados que se leen sobre tarjetas), tokens de sombra para dar profundidad a las tarjetas, y el azul de marca en claro. Se ve muy bien en los dos modos y al alternar es «la misma app, otra piel».

Todo el contenido de un post de blog es del bot: arreglo mecánico limpio → Simón (título/meta, enlaces, reemplazos en el cuerpo con edit_content); si requiere redacción → el Redactor lo deja de borrador en Artículos (refresh_post). En Dev quedan solo plantilla, schema, hreflang, Core Web Vitals, enrutado, páginas no-blog y decisiones. De 43 tareas en Dev a 17, todas justificadas.

El Redactor lee el canal de Slack de Alejandro (un enlace o tweet de una herramienta IA = un artículo a hacer), investiga y entrega el borrador bilingüe en Artículos, no en un fichero suelto. Se arregló que slack_leer no estaba enganchada al bot.

Un despachador cada 5 min reintenta lo aprobado, lee el error real del CMS y marca «bloqueado» ante un rechazo efectivo (en vez de «esperando» indefinido). Una autocomprobación cada 15 min mide la ENTREGA real: detecta la tarea que se ejecuta sin mutar nada y lo reporta en tu parte.

Sondeo cada 4 s: cuando Simón aplica o publica, la tarea se recoloca sin recargar. Al pulsar «Aprobar y aplicar» el contador se actualiza de forma optimista y revierte si el servidor falla. Barra superior con la operación en curso y su progreso.

Dos apartados nuevos: los backlinks que publica Simón + el LINKBUILDER (canal, página, a dónde enlazan, dofollow y fecha — 40 vivos) y los nuevos detectados en el perfil.

Botón para no cargar con las propuestas rechazadas para siempre. Solo borra las rechazadas; nada más se toca.

Un enlace a la página de pago (viva) se clasificaba como «enlace muerto», y 70 páginas con FAQ como «FAQ ausente» — ambos por leer solo el HTML estático. Corregidos: el soft-404 se detecta por señal fiable y el FAQ contabiliza el bloque renderizado en cliente + el schema JSON-LD.

Rastrea el sitio entero (sitemap + enlaces internos) leyendo la página real y detecta lo que impide indexar: noindex, cabecera X-Robots-Tag (invisible en el HTML), robots.txt, canonical a otra URL y errores HTTP. Sin depender de Google ni de su cuota, y sin saturar la web (rastreo cortés). Los noindex de blog se arreglan por MCP con un clic; el resto (cabecera del framework) va a Dev.

El CMS requiere 5 FAQ (minItems 5) y sin ellas la publicación fallaba en silencio: 8 aprobados atascados. Ahora se generan del propio artículo (grounded, sin inventar) y se verifica por MCP que la página quedó viva antes de marcarla. Los 8 → publicados.

Los artículos modernos guardan el cuerpo en secciones HTML, no en un campo plano; el aplicador ahora los edita (su sección, con su propio layout) sin tocar la plantilla que comparten todos. Con guardarraíles: no enlaza a páginas soft-404 ni mete un enlace dentro de otro.

Un mailto al dominio antiguo es una dirección de contacto válida, no un enlace a reparar. El generador dejó de proponer (y de aplicar) sustituir el email por la home.

El disavow subido se marca y deja de computar en los totales y en el análisis de tóxicos de Backlinks, para no penalizar el perfil por enlaces ya renegados ante Google.

31 reglas SEO+AIO sobre el HTML servido: canonical, hreflang, H1, títulos, JSON-LD, FAQ marcada sin texto, soft-404, dominio viejo, enlace al comparador, respuesta directa, huérfanas, profundidad de enlazado, canibalización (GSC), cadenas de redirección, ALT de imágenes, paridad ES/EN… Una descarga por página, todas las reglas encima. Primera pasada: 400 páginas, 551 hallazgos.

Lo que el MCP no puede tocar (plantilla y datos estructurados) ya no se mezcla con lo automatizable: tiene tablero propio, se copia como ticket en Markdown y el reparto lo decide el backend, no la pantalla.

Cada tarea define su criterio de verificación. Botón «Comprobar» y repaso automático cada 6 h: si el HTML servido confirma el arreglo, el ticket se cierra sin intervención.

Aprobar, Artículos y Dev Team revalidan cada 45 s y al recuperar el foco de la pestaña, sin pisar lo que estés escribiendo.

El barrido con desde_cero borraba TODA propuesta pendiente, viniera de donde viniera — se llevó 165 tareas del auditor. Ahora cada propuesta guarda su origen y el barrido solo borra lo suyo.

La aprobación dispara a Simón (host Intel) por Tailscale; ejecuta, verifica en vivo y marca applied. Validado de punta a punta.

240 posts, 960 destinos verificados contra la web viva: 527 arreglos en 125 propuestas (legacy→destino real, muertos→archivo histórico).

Radar de herramientas IA + peticiones + refresh entran como borradores: los lees, editas y apruebas aquí. Publicación por MCP y propuesta de hub detrás.

update_post genera título+meta con IA (regenerable, editable); link_editorial trae la frase-ancla exacta. Tú decides, no redactas.

La app es servidor MCP: 10 tools, claves gestionadas en Conexiones, aprobar desde Claude dispara el mismo ciclo.

Verificación contra el HTML de la página que enlaza: vivo/caído/nofollow/anti-bot, en la pestaña Backlinks.

El estado se prueba contra la API real al guardar (adiós al verde falso de GSC); secretos enmascarados.

De 23 pantallas dispersas a 6 con propósito: Panel, La web, Aprobar, Artículos, El plan, Backlinks.