Publicación automática en MarkeUP: deploy, launchd y móvil Android
Cómo publicar en MarkeUP: el comando único de deploy, la autopublicación con launchd desde el móvil, cómo escribir sin publicar y la gestión del servicio automático.
Navegando en el blogver navegación en todos los blogs
Publicar en MarkeUP es una sola orden: npm run deploy valida el contenido, construye el sitio, hace el commit y lo sube a internet. Si prefieres no escribir nada, un servicio vigila la carpeta de contenido y publica por ti en cuanto llega un cambio desde el móvil.
Esta guía explica las dos formas de publicar, cómo gestionarlas y qué hacer cuando algo no sale como esperas. Si antes quieres entender el proyecto, empieza por la arquitectura del proyecto y por la guía de operación.
Orden de lectura recomendado: doc-readme → doc-guia → doc-arquitectura → doc-buscador → doc-operacion → doc-publicar → doc-auditoria
Escribe esto y ya está:
npm run deploy
Ese comando hace cinco cosas, en este orden: ejecuta los tests, pasa los tres validadores de contenido, construye el sitio, crea un commit con mensaje autogenerado y sube los cambios a main. A partir de ahí, Cloudflare Pages detecta el envío y despliega solo.
No hace falta escribir el mensaje del commit: si no se lo das, lo genera él contando los archivos cambiados. Cuando quieras un texto propio, se lo pasas con -m:
npm run deploy -- -m "feat(posts): añade la guía de publicación"
| Comando | Para qué sirve |
|---|---|
npm run deploy | Publicar ya. No pregunta nada |
npm run publish | Publicar con diagnóstico y en modo prudente |
npm run deploy:check | Comprobar si producción está al día, sin publicar |
npm run publish -- --dry-run | Ver qué haría, sin tocar nada |
⚠️
npm run deploydespliega en producción de verdad. Si eres un agente de IA, no lo ejecutes por iniciativa propia: pide confirmación al usuario.
El segundo camino es no hacer nada. Un servicio de macOS vigila la carpeta src/content/posts/ y, cada vez que algo cambia, ejecuta la misma cadena: valida, hace commit, publica y despliega.
Como tu Syncthing sincroniza el vault entre el móvil y el Mac, escribir una nota en Obsidian termina publicada sola en uno o tres minutos. No tienes que abrir el ordenador.
El vigilante es watchexec, lanzado por el servicio ai.markeup.autopublish. Solo mira src/content/posts/: el resto del vault —reglas, memoria y plantillas del agente— vive fuera de esa carpeta, así que guardar esos archivos no publica nada. Además agrupa ráfagas con una espera de 30 segundos y no publica más de una vez cada dos minutos, de modo que una sesión de edición intensa se convierte en un puñado de commits, no en uno por guardado.
escribes en el móvil
→ Syncthing copia el archivo al Mac
→ watchexec detecta el cambio
→ valida · commit · push
→ Cloudflare despliega
Un post con draft: true en el frontmatter se guarda y se publica en Git, pero no aparece en el sitio web. Es la forma de redactar tranquilamente desde el móvil: cuando el artículo esté listo, cambias true por false y sale a la luz solo.
Todo se controla con un único comando: npm run autopublish. Sin argumentos muestra el estado; con un argumento, hace lo que le pidas.
npm run autopublish # ¿está activo? ¿qué se publicó últimamente?
npm run autopublish -- install # activar o reparar el servicio
npm run autopublish -- now # publicar ahora mismo, sin esperar a nada
npm run autopublish -- test # simulación: no toca nada
npm run autopublish -- disable # apagar de forma persistente (no vuelve al reiniciar sesión)
npm run autopublish -- logs # ver el registro de publicaciones en vivo
npm run autopublish -- uninstall # desinstalar el servicio
El estado te dice cuatro cosas de un vistazo: si el fichero de servicio está instalado, si macOS lo tiene cargado, si hay un vigilante activo y si los avisos por Telegram funcionan.
La autopublicación es cómoda, pero si un día prefieres control manual, apágala y publica cuando quieras:
npm run autopublish -- disable # deja de publicar solo
npm run deploy # pública tú, cuando te apetezca
Apagarla no pierde nada: los cambios siguen guardándose en el Mac y puedes subirlos todos de golpe cuando lo decidas. La parada es persistente (sobrevive al reinicio de sesión); para volver a activarla, npm run autopublish -- enable.
Por qué hay tres frenos. Hasta el 24 de septiembre de 2026 el vigilante miraba todo
src/content/y publicaba en cuanto pasaban dos segundos sin cambios. Un día de edición intensa produjo 223 commits y otros tantos despliegues en Cloudflare Pages. Los frenos actuales —carpeta acotada asrc/content/posts/, espera de 30 segundos y un mínimo deMARKEUP_MIN_INTERVAL(120 s) entre publicaciones— hacen imposible esa tormenta.
Antes de publicar nada, la cadena ejecuta cuatro validadores y la batería de tests. Si alguno falla, ocurren tres cosas a la vez: el commit se guarda en local, no se sube nada a internet y te llega un aviso.
Ese aviso viaja por Telegram gracias a Hermes Agent, que reutiliza el token del bot sin necesitar que el agente esté encendido. Si algún día no tienes Hermes instalado, la cadena sigue funcionando: el aviso queda escrito en logs/auto-publish.log.
El caso más habitual es un detalle de formato: un tag con tilde, una descripción demasiado corta o una fecha mal escrita. El validador te dice el archivo y el campo exacto, así que basta con corregirlo y esperar: el siguiente cambio publica el conjunto.
| Qué revisa | Comando |
|---|---|
| Los 22 campos del frontmatter, la descripción y la categoría | npm run validate:frontmatter |
Las longitudes y la clave del concept en el title (solo aviso); el campo ausente o con tipo inválido y el title duplicado (bloquea) | npm run validate:seo |
| Que no haya dos posts con el mismo slug o alias | npm run validate:slugs |
| Que los wikilinks resuelvan (bloquea) y que los de párrafo lleven alias (aviso) | npm run validate:wikilinks |
Que cada bookIsbn tenga checksum válido y su ficha en scripts/data/books.json | npm run validate:books |
| Síntoma | Causa probable | Solución |
|---|---|---|
| Los cambios del móvil no llegan a la web | El servicio quedó apuntando a una ruta vieja | npm run autopublish -- install |
| Publico y me llega un aviso de error | Un validador ha rechazado el contenido | npm run validate:frontmatter |
| El sitio no muestra los cambios | Cloudflare aún está construyendo | Espera 1-3 min y prueba npm run deploy:check |
| Un artículo aparece sin imagen de portada | Falta el archivo /img/<slug>.webp | Usa /img/placeholder.webp o sube la imagen |
La primera fila es la avería histórica del sistema, y merece una explicación: el fichero de servicio vive en ~/Library/LaunchAgents/, fuera del repositorio. Cuando los scripts se movieron de carpeta, ese fichero siguió apuntando a la ruta antigua y la cadena dejó de funcionar en silencio durante días.
Por eso conviene que, si sospechas algo, lo primero sea npm run autopublish: te dice si el servicio está cargado y si el vigilante existe. Y la solución casi siempre es reinstalarlo, porque el instalador reescribe el fichero con las rutas actuales del proyecto.
- Un comando:
npm run deploypublica de principio a fin, con validación incluida. - Cero comandos: el servicio
ai.markeup.autopublishpublica solo lo que escribes en el móvil. - Con red: si el contenido no cumple las reglas, no se publica y te avisa por Telegram.
- Con freno:
npm run autopublish -- disabledevuelve el control a tus manos.
Para seguir profundizando, el README de documentación explica la visión general del proyecto y la guía de instalación cubre la puesta a punto de Obsidian, Syncthing y las plantillas.
En esta misma línea, Focusing aborda eugene Gendlin y el Focusing: la experiencia sentida (Felt Sense) como puente entre la emoción, la intuición y la.
Publicación Automática
Explora las ramas del artículo
