<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>Climakers Blog (Espanol)</title>
        <link>https://blog.climakers.com/es/blog</link>
        <description>Operator-grade guides for Confluence migration, docs-as-code, continuity, and AI-ready Markdown workflows.</description>
        <lastBuildDate>Fri, 24 Apr 2026 17:00:00 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>SvelteKit + mdsvex</generator>
        <language>es</language>
        <item>
            <title><![CDATA[La guia definitiva para migrar de Confluence a Docs-as-Code sin perder el formato]]></title>
            <link>https://blog.climakers.com/es/blog/guia-definitiva-confluence-a-docs-as-code-sin-perder-formato</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/guia-definitiva-confluence-a-docs-as-code-sin-perder-formato</guid>
            <pubDate>Fri, 24 Apr 2026 17:00:00 GMT</pubDate>
            <description><![CDATA[Una guia practica para equipos que necesitan Markdown limpio, estructura preservada y una ruta repetible desde Confluence Cloud hacia flujos Docs-as-Code que cumplan los requisitos de evidencia de ISO 9001, ISO 27001, ISO 27017, NIS 2 y SOC 2.]]></description>
            <content:encoded><![CDATA[Confluence suele ser el lugar donde empieza la documentacion critica del negocio, pero casi nunca es el lugar donde deberian terminar los flujos modernos de documentacion. Los equipos que quieren adoptar Docs-as-Code necesitan mucho mas que una exportacion puntual. Necesitan contenido versionable, revisable, sincronizable, buscable, archivado y reutilizable en ingenieria, soporte, cumplimiento e IA. Ahi es donde fallan la mayoria de las migraciones: no en el titular del proyecto, sino en los detalles operativos que importan cuando el primer export ya esta en disco. Por que las exportaciones nativas de Confluence rompen los flujos Docs-as-Code El problema no es que Confluence no pueda exportar contenido. El problema es que las salidas por defecto no producen un patrimonio Markdown durable y amigable para automatizacion. Los fallos habituales se ven asi: - las tablas quedan mal aplanadas o dificiles de revisar en Git - los bloques de codigo pierden una presentacion limpia y consistente - los enlaces internos siguen apuntando a Confluence en lugar del arbol local - la jerarquia se pierde y el espacio deja de comportarse como un conjunto navegable de documentacion - la busqueda, la publicacion estatica y la ingestion para RAG heredan ruido o formatos propietarios Docs-as-Code no es solo una preferencia de formato. Es un modelo operativo. Eso significa que la exportacion debe soportar diffs revisables, rutas predecibles, automatizacion y ejecucion repetida. Empieza con el alcance correcto de migracion Antes de elegir un comando, decide si el trabajo es de precision por pagina o de alcance completo sobre un patrimonio documental. Usa acp2md cuando la unidad real de trabajo es una pagina Usa acp2md cuando la tarea de migracion parte de un ID de pagina, un titulo o una URL y necesitas control exacto. Es ideal para: - paginas de alto valor regulatorio o de cumplimiento - pilotos de migracion sobre un documento concreto - revisar problemas de formato antes de una migracion mas amplia - generar un artefacto Markdown listo para retencion legal o ingestion por IA Usa acs2md cuando el objetivo es un espacio completo Usa acs2md cuando el requisito es mover un espacio completo de Confluence a Markdown portable preservando jerarquia, reescribiendo enlaces internos y soportando refrescos repetibles. Es la opcion correcta para: - migraciones documentales de gran escala - copias de continuidad - flujos gobernados de backup - pipelines CI y tareas programadas - patrimonios Docs-as-Code que deben mantenerse al dia Que formato necesita preservarse de verdad La pregunta real no es si Markdown es mas simple que Confluence. La pregunta real es si la conversion preserva la semantica que importa cuando el contenido sale de Confluence. Para un flujo serio de Docs-as-Code eso suele significar conservar: - encabezados con un esquema de documento utilizable - bloques de codigo en Markdown cercado - listas y estructura anidada - citas, paneles y bloques legibles - tablas revisables en Git - imagenes y medios referenciados - suficiente metadata para generadores estaticos y pipelines internos La familia ac2md trabaja sobre Atlassian Document Format en lugar de hacer una transformacion superficial. Eso importa porque el modelo fuente contiene estructura que un flujo posterior en Markdown puede conservar de forma mucho mas fiable. Un flujo de migracion practico que no se rompe en el segundo paso La ruta mas segura no es exportar primero y limpiar despues. Es descubrir primero, validar la estacion de trabajo, confirmar el alcance y luego exportar. 1. Valida el entorno Tanto acp2md como acs2md documentan un flujo orientado al operador basado en doctor, configuracion y validacion de licencia antes del primer trabajo real. Eso detecta problemas de credenciales, licencia o conectividad antes de lanzar una migracion contra contenido real de Confluence. 2. Confirma el alcance exacto Para trabajo por pagina, confirma antes la pagina correcta. Para trabajo por espacio, inventaria el espacio antes de convertir. Esa secuencia importa porque hace que la planificacion parta del arbol real de paginas y no de suposiciones. 3. Exporta a Markdown portable, no a un artefacto sin salida Cuando el objetivo es Docs-as-Code, la salida debe aterrizar en una estructura que pueda vivir en Git, ser publicada por un sitio estatico o alimentar procesos internos. Para exportacion por pagina: Para exportacion por espacio completo: En ese momento la migracion deja de ser teorica. Ya tienes Markdown controlado por el cliente y almacenado en disco. Donde preservar el formato pasa a ser un problema operativo El formato no es solo una capa visual. Afecta directamente a tres sistemas de salida. Revision en Git Si encabezados, tablas y bloques son inestables, los diffs se vuelven ruidosos y los revisores dejan de confiar en la exportacion. Publicacion estatica Si los enlaces no se reescriben y la jerarquia se pierde, el arbol exportado no se comporta como un sitio de documentacion. Se comporta como un monton de archivos. Pipelines de IA y RAG Si la exportacion elimina demasiada estructura, los fragmentos son mas dificiles de interpretar. Si conserva la semantica correcta, Markdown se vuelve mucho mas util para recuperacion y generacion fundamentada. Por eso Climakers posiciona estas herramientas como herramientas de migracion, continuidad y Markdown listo para IA, y no como simples exportadores. Como ayudan la reescritura de enlaces y el front matter Hay dos capacidades que se vuelven utiles de inmediato una vez que el contenido cae en un repositorio Docs-as-Code. Reescritura de enlaces internos En migraciones de espacio completo, reescribir enlaces internos es lo que separa un patrimonio autocontenido de una exportacion que sigue dependiendo de URLs de Confluence. Front matter El front matter ayuda a conservar contexto util como autor, fechas, estado, IDs y otros atributos operativos. Eso sirve para: - publicacion estatica - retencion y auditoria - indexacion de contenido - validacion de migracion - automatizacion interna El alcance Confluence Cloud importa Las herramientas activas acp2md y acs2md trabajan sobre Confluence Cloud. No soportan Confluence Server ni Data Center. Ese limite importa porque la planificacion empeora cuando un equipo cree que una herramienta cubre mas modelos de despliegue de los que realmente cubre. Los limites de producto claros forman parte de un flujo de migracion seguro. Por que Docs-as-Code tambien es una postura de cumplimiento Migrar de Confluence a Markdown no es solo una decision de herramientas. Es una decision de control de la informacion documentada bajo ISO 9001, ISO 27001, ISO 27017, NIS 2 y SOC 2. El mismo artefacto que hace funcionar Docs-as-Code — un patrimonio Markdown bajo control del cliente en Git — es el artefacto que convierte cada uno de estos marcos en algo que puedes evidenciar de verdad. - ISO 9001:2015 clausula 7.5 exige control sobre la informacion documentada: creacion, actualizacion, distribucion, recuperacion y obsolescencia. Un repositorio Git codifica esas operaciones como commits, pull requests, ramas y etiquetas. No hay un "sistema de evidencia" separado que mantener. - ISO/IEC 27001:2022 trata los procedimientos operativos documentados (A.5.31) y la proteccion de registros (A.5.33) como controles del Anexo A. Cuando el procedimiento es un fichero Markdown bajo control de versiones, puedes producir todo el historial, el aprobador y la fecha de obsolescencia con un solo git log. - ISO/IEC 27017:2015 extiende 27001 al ambito cloud. Almacenar la copia de referencia de la documentacion del cliente cloud fuera del portal del proveedor es justo el tipo de control side-customer que la norma espera. - NIS 2 exige politicas documentadas sobre gestion de riesgos de ciberseguridad, gestion de incidentes y continuidad de negocio. Un patrimonio Markdown es la via mas directa para satisfacer esa obligacion sin atarte a una plataforma SaaS cuya disponibilidad es en si misma un riesgo. - SOC 2 Common Criteria CC2.2 y CC2.3 exigen comunicar politicas documentadas. Markdown bajo control del cliente te permite publicar el mismo contenido fuente en portales internos, paginas de confianza externas y a auditores sin divergencia. Tratar Docs-as-Code como postura de cumplimiento tambien cambia como justificas internamente la migracion. No estas "saliendo de Confluence". Estas trayendo la informacion documentada que sostiene tu negocio bajo controles que tus auditores ya esperan. Una checklist sensata para equipos Docs-as-Code Si quieres la ruta mas corta hacia una migracion controlada, usa esta lista: 1. Decide si el trabajo es por pagina o por espacio completo. 2. Configura credenciales y valida con doctor. 3. Inspecciona la pagina o el espacio antes de convertir. 4. Exporta Markdown a una ruta compatible con Git. 5. Verifica jerarquia, enlaces, bloques de codigo, tablas y medios. 6. Repite la exportacion con --sync o con modos incrementales cuando el objetivo sea continuidad y no una sola corrida. 7. Publica o procesa el Markdown en tu sitio estatico, portal interno o pipeline de IA. Cierre La mejor migracion de Confluence a Docs-as-Code no es la que genera mas archivos mas rapido. Es la que da control, portabilidad y una operacion repetible sin perder los detalles de formato que hacen util la documentacion. Si el problema empieza en una sola pagina, usa acp2md. Si empieza en un patrimonio documental completo, usa acs2md. En ambos casos el objetivo es el mismo: pasar de conocimiento atrapado en un espacio propietario a Markdown controlado por el cliente, listo para migracion, continuidad, publicacion, reutilizacion por IA y la siguiente auditoria de vigilancia ISO 27001. Cuando estes listo, empieza con acp2md para una sola pagina o elige un plan de acs2md para el espacio completo.]]></content:encoded>
            <category>docs-as-code</category>
            <category>confluence</category>
            <category>markdown</category>
            <category>migration</category>
            <category>acp2md</category>
            <category>acs2md</category>
            <category>ai-ready-content</category>
            <category>compliance</category>
            <category>iso-9001</category>
            <category>iso-27001</category>
            <category>nis-2</category>
            <category>soc-2</category>
        </item>
        <item>
            <title><![CDATA[Como crear copias de continuidad de Confluence que se mantienen al dia en Git]]></title>
            <link>https://blog.climakers.com/es/blog/como-crear-copias-de-continuidad-de-confluence-que-se-mantienen-al-dia-en-git</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/como-crear-copias-de-continuidad-de-confluence-que-se-mantienen-al-dia-en-git</guid>
            <pubDate>Thu, 23 Apr 2026 11:00:00 GMT</pubDate>
            <description><![CDATA[Una guia practica para equipos que necesitan copias de continuidad repetibles en Markdown, con enlaces reescritos, jerarquia preservada e historial auditable en Git, alineado con ISO 27001, ISO 27017, NIS 2 y SOC 2.]]></description>
            <content:encoded><![CDATA[El trabajo de continuidad sobre Confluence no deberia empezar con panico. Deberia empezar con una ruta de exportacion repetible que produzca Markdown controlado por el cliente, preserve suficiente estructura para seguir siendo util y pueda refrescarse cuando haga falta. Esa es la diferencia entre tener un artefacto de backup en algun sitio y tener una copia de continuidad que los operadores realmente pueden usar. Cuando un equipo necesita recuperar acceso documental, responder a una auditoria de vigilancia ISO 27001, evidenciar la linea temporal de un incidente NIS 2, superar una prueba de disponibilidad SOC 2, alimentar un portal nuevo o entregar contenido a pipelines de IA, la copia debe ser legible, navegable y actual. La continuidad ya no es opcional para la mayoria de operadores. NIS 2 la convierte en una obligacion del Articulo 21 de gestion de riesgos de ciberseguridad para miles de entidades esenciales e importantes. ISO/IEC 27001:2022 incorporo el control A.5.30 dedicado a la preparacion TIC para la continuidad de negocio. SOC 2 exige evidencia de diseno de backup y pruebas de recuperacion. Y la ISO 9001 siempre ha exigido que la informacion documentada este controlada, vigente y disponible. Una copia de continuidad en Git es una de las maneras mas limpias de generar esa evidencia sin meter una plataforma nueva en el alcance de auditoria. Las copias de continuidad no son lo mismo que un backup Muchos equipos dicen que tienen backup documental cuando en realidad solo tienen un archivo opaco o una exportacion puntual en la que nadie confia. Una copia de continuidad util tiene requisitos distintos: - debe poder leerse sin volver a Confluence - debe preservar la jerarquia lo bastante bien como para comportarse como un patrimonio documental - debe poder refrescarse sin reinventar el proceso - debe poder versionarse para demostrar que cambio y cuando - debe ser portable para publicacion, retencion y flujos de IA La continuidad es operativa. Si la copia no puede inspeccionarse rapido, revisarse en Git y regenerarse con una cadencia clara, no esta resolviendo el problema real. Que debe preservar una copia de continuidad util Muchos equipos se centran en generar archivos y se olvidan de preservar la semantica. Esa es la optimizacion equivocada. Para continuidad, la copia deberia conservar: - encabezados y estructura del documento - enlaces internos reescritos hacia el patrimonio local - bloques de codigo estables en Markdown cercado - tablas que sigan siendo revisables en Git - imagenes y medios referenciados con rutas utilizables - metadata suficiente para auditoria, indexacion y automatizacion interna La razon es simple: los eventos de continuidad rara vez ocurren en un momento comodo. Si los operadores tienen que volver a limpiar la exportacion antes de usarla, la copia ya esta fallando cuando mas importa. Por que Git mejora la continuidad en lugar de complicarla Algunos equipos tratan Git como una comodidad de ingenieria y no como un control de continuidad. Eso pierde el punto. Git aporta varias ventajas practicas: - cada refresco genera un diff en lugar de un blob imposible de inspeccionar - los equipos pueden demostrar cadencia e historial a auditores o stakeholders - una copia conocida como buena puede restaurarse desde un commit etiquetado - el mismo arbol Markdown puede alimentar sitios estaticos, indices de busqueda y pipelines de retrieval Git no arregla una exportacion mala. Pero cuando la exportacion es determinista y portable, Git convierte la continuidad en un proceso gobernado y no en una tarea manual de emergencia. Flujo recomendado para un patrimonio de continuidad repetible La secuencia mas segura es validar el entorno, inspeccionar el alcance, exportar a un directorio controlado por Git y refrescarlo con una cadencia definida. 1. Valida la estacion antes de la primera exportacion Empieza comprobando credenciales, licencia y estado de la estacion de trabajo. Es una comprobacion barata que detecta problemas antes de lanzar una corrida real de continuidad. 2. Inspecciona el espacio objetivo y su arbol de paginas No programes una tarea de sincronizacion sobre un espacio que no has inspeccionado. Ese inventario ayuda a confirmar que la copia debe contener exactamente la jerarquia que esperan los consumidores posteriores. 3. Exporta hacia un directorio de continuidad controlado por Git Cuando el objetivo es un patrimonio reutilizable, la salida debe aterrizar en un directorio pensado para versionarse. Lo importante no es solo que la exportacion termine. Lo importante es que la copia quede en un lugar durable, con enlaces locales reescritos y una ruta de refresco repetible. 4. Haz commit del arbol resultante y revisa los diffs Una vez generada la copia, tratalo como cualquier otro cambio gobernado de contenido. Ese paso crea un rastro auditable y permite comparar un snapshot con el siguiente. 5. Repite con una cadencia y no solo cuando haya un incidente Los flujos de continuidad fallan cuando dependen de la memoria. Una copia generada una sola vez hace meses no es una estrategia. Usa un scheduler, un job de CI o automatizacion interna para ejecutar el refresco con una cadencia alineada con el riesgo operativo. El papel de las rutas estables y la reescritura de enlaces Las copias de continuidad se vuelven utiles en serio cuando las rutas locales son predecibles. Si un incidente obliga a trabajar desde la copia, el equipo no deberia descubrir que cada referencia interna sigue apuntando a Confluence. La reescritura local importa porque convierte la exportacion en un patrimonio autocontenido y no en un monton de archivos desconectados. Las rutas estables tambien importan para: - generacion de sitios - indexacion de busqueda - flujos de retencion - ingestion posterior por IA - handoff operativo entre equipos La predictibilidad forma parte de la recuperabilidad. Como validar una copia de continuidad antes de confiar en ella Antes de dar el flujo por cerrado, inspecciona la copia como la inspeccionaria un operador bajo presion. Comprueba al menos lo siguiente: 1. La estructura principal refleja la jerarquia esperada del espacio. 2. Algunos enlaces internos resuelven dentro del arbol exportado. 3. Los bloques de codigo siguen siendo legibles y coherentes. 4. Las tablas siguen siendo entendibles en Markdown plano. 5. Las paginas borradas o renombradas aparecen como diffs significativos en el siguiente sync. 6. Los medios y diagramas importantes siguen resolviendo. La validacion deberia ocurrir antes de que un evento real de continuidad obligue a usar la copia. Como mapear copias de continuidad a controles ISO, NIS 2 y SOC 2 Los auditores no aceptan "tenemos backup en algun sitio" como evidencia. Buscan un proceso documentado, repetible y comprobable que vincule un objetivo de control a un artefacto concreto. Una copia de continuidad versionada en Git, generada con acs2md, encaja con los requisitos mas comunes de los marcos de referencia: | Marco | Control o clausula | Que aporta la copia de continuidad | | --------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | ISO/IEC 27001:2022 | A.5.30 Preparacion TIC para la continuidad de negocio | Patrimonio Markdown actual y restaurable que puede probarse sin depender de la disponibilidad de Confluence. | | ISO/IEC 27001:2022 | A.5.33 Proteccion de registros | Historial Git versionado que demuestra quien cambio que, cuando y como evoluciono el registro. | | ISO/IEC 27001:2022 | A.8.13 Copia de seguridad de la informacion | Calendario de exportacion repetible, salida determinista y archivo de estado para detectar derivas. | | ISO/IEC 27017:2015 | CLD.12.1.5 Seguridad operacional del administrador en servicios cloud | Acceso GET de solo lectura contra Confluence Cloud, registrado en CI, valido como evidencia para el cliente cloud. | | ISO 9001:2015 | Clausula 7.5 Informacion documentada | Markdown bajo control del cliente que puede revisarse, distribuirse y dejarse obsoleto fuera de un portal de proveedor. | | NIS 2 (Directiva 2022/2555) | Articulo 21(2)(c) Continuidad de negocio, gestion de copias y gestion de crisis | Copia de continuidad refrescable con commits con marca temporal que respaldan la reconstruccion del incidente y los avisos de 24/72 horas. | | SOC 2 (TSC 2017) | A1.2 / A1.3 Disponibilidad: procesos de backup y pruebas de recuperacion | Los commits etiquetados son puntos de restauracion; un job periodico --sync es el procedimiento de recuperacion documentado. | El objetivo no es decir que la herramienta "te hace cumplir". Ninguna lo hace. El objetivo es que el artefacto que produce acs2md es justo el tipo de artefacto que cada marco pide: una copia inspeccionable, fechada y restaurable de la informacion documentada que sostiene tu negocio. Si tu programa de seguridad o calidad confia en Confluence como sistema de registro, una copia de continuidad es la diferencia entre una clausula que evidencias en cinco minutos y una clausula que se convierte en una no conformidad. Que suelen hacer mal los equipos Los fallos mas comunes son operativos, no teoricos. - generar una exportacion una vez y no refrescarla nunca - guardar solo archivos propietarios dificiles de inspeccionar - omitir la reescritura de enlaces y la validacion de rutas locales - no almacenar la copia en Git o en otro sistema auditable - asumir que continuidad y migracion son exactamente lo mismo siempre Migracion y continuidad se solapan, pero la necesidad de continuidad es mas estricta: la copia debe seguir siendo util cuando el sistema original no esta disponible o no es practico. Cuando acs2md es la opcion correcta acs2md es la herramienta correcta cuando la unidad de trabajo es el espacio y no la pagina individual. Eso suele significar: - patrimonios de continuidad para un espacio documental completo - flujos gobernados de backup con refrescos repetibles - copias Git-native usadas para auditoria, recuperacion o publicacion - arboles Markdown que necesitan enlaces reescritos y jerarquia preservada Si la necesidad empieza en una sola pagina, acp2md suele ser el mejor primer paso. Si la necesidad es continuidad a escala de espacio, acs2md es donde deberia vivir el flujo. Cierre El objetivo de una copia de continuidad no es demostrar que una exportacion ocurrio una vez. El objetivo es crear un patrimonio Markdown actual, inspeccionable y repetible que sobreviva a presion de migracion, auditoria y disrupcion de plataforma — y que pueda mostrarse a un evaluador de ISO 27001, ISO 27017, NIS 2 o SOC 2 sin improvisar. Con acs2md, una ruta de exportacion disciplinada y revision en Git, los equipos pueden mantener copias de continuidad de Confluence realmente al dia en lugar de descubrir demasiado tarde que su historia de backup era solo nominal. Cuando estes listo para incorporarlo a tu evidencia de control, compara los planes de acs2md en la tienda.]]></content:encoded>
            <category>continuity</category>
            <category>confluence</category>
            <category>continuity</category>
            <category>backup</category>
            <category>markdown</category>
            <category>acs2md</category>
            <category>audit-ready-content</category>
            <category>iso-27001</category>
            <category>iso-27017</category>
            <category>nis-2</category>
            <category>soc-2</category>
            <category>compliance</category>
        </item>
        <item>
            <title><![CDATA[Como exportar una pagina de Confluence a Markdown limpio con acp2md]]></title>
            <link>https://blog.climakers.com/es/blog/como-exportar-una-pagina-de-confluence-a-markdown-limpio-con-acp2md</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/como-exportar-una-pagina-de-confluence-a-markdown-limpio-con-acp2md</guid>
            <pubDate>Wed, 22 Apr 2026 15:00:00 GMT</pubDate>
            <description><![CDATA[Una guia practica para equipos que necesitan exportar una sola pagina de Confluence a Markdown portable, con formato preservado, salida predecible y control exacto del alcance.]]></description>
            <content:encoded><![CDATA[Muchos proyectos de Confluence a Markdown no empiezan a escala de espacio. Empiezan con una sola pagina que importa lo suficiente como para moverla con cuidado. Esa pagina puede ser un procedimiento de compliance, un runbook ejecutivo, un SOP regulado, un playbook de soporte o un articulo de conocimiento que necesitas preservar antes de tocar el resto del espacio. En esos casos, una exportacion amplia es la jugada equivocada. La jugada segura es control exacto del alcance. Ahí es donde encaja acp2md. Esta pensado para trabajo a nivel de pagina, donde la unidad de valor es un solo documento de Confluence y la salida debe ser portable, revisable y lista para Git o para procesos posteriores. Cuando exportar una sola pagina es el punto de partida correcto Muchos equipos asumen que una migracion desde Confluence tiene que empezar por todo un patrimonio documental. No siempre es asi. La exportacion de una sola pagina suele ser mejor cuando: - una pagina tiene importancia legal, operativa o de auditoria - quieres pilotar fidelidad de formato antes de una migracion mas amplia - el objetivo es un artefacto Markdown listo para IA a partir de una sola fuente de alto valor - un equipo necesita preservar un documento ya, sin esperar una decision mayor de migracion - el espacio alrededor es ruidoso, pero la pagina en si esta bien definida En esos casos, la precision del alcance es una ventaja y no una limitacion. Que debe preservar una buena exportacion de pagina El trabajo no termina cuando existe un archivo .md. Termina cuando la pagina sigue siendo util fuera de Confluence. Para un flujo a nivel de pagina, eso suele significar preservar: - encabezados y estructura de secciones - bloques de codigo cercados que sigan leyendose bien en Git - tablas que sigan siendo entendibles en Markdown plano - enlaces, referencias y listas importantes - una ruta de archivo estable que pueda vivir en un repo documental o en una carpeta de evidencias La barra de calidad es operativa. Si los revisores aun tienen que reparar el resultado antes de usarlo, la ruta de exportacion no esta lista. Por que acp2md es la mejor herramienta para alcance exacto acs2md es la herramienta correcta cuando la unidad de trabajo es el espacio. acp2md lo es cuando el trabajo real es una sola pagina. Eso importa porque los flujos a nivel de pagina se benefician de: - targeting directo por ID, titulo o URL de pagina - menos ruido durante pilotos de migracion - inspeccion mas simple de la fidelidad de formato antes de ampliar el alcance - handoff mas limpio para equipos de compliance, legal o respuesta a incidentes La disciplina de alcance reduce limpieza posterior. Esa es una de las maneras mas rapidas de volver confiables las exportaciones a Markdown. Flujo recomendado para una exportacion exacta de pagina La secuencia mas segura es validar la estacion, confirmar la pagina exacta, inspeccionar la complejidad probable del formato y solo entonces escribir el archivo Markdown. 1. Valida primero el entorno Antes de tocar la pagina, comprueba que la estacion, la licencia y las credenciales estan en buen estado. Ese paso es barato y evita fallos evitables mas adelante en el flujo. 2. Confirma la pagina que realmente quieres Los flujos a nivel de pagina fallan cuando el equipo asume que esta apuntando al documento correcto. Esa es la comprobacion rapida que prueba la identidad de la pagina antes de exportar nada. 3. Inspecciona la complejidad probable del formato Antes de convertir, inspecciona la pagina para ver marcas y formato enriquecido que puedan necesitar una revision mas cuidadosa. Eso ayuda a identificar si la pagina es simple, si tiene mucho formato o si probablemente necesitara validacion mas cercana despues de la exportacion. 4. Exporta a una ruta Markdown estable Cuando la salida importa, escríbela directamente en la ruta donde la organizacion espera conservarla. Eso convierte la pagina en Markdown controlado por el cliente en lugar de dejarla encerrada dentro de una frontera propietaria. 5. Haz commit y revisa el archivo como contenido gobernado Si la pagina es importante, el Markdown exportado deberia revisarse como cualquier otro artefacto controlado. Eso crea un rastro auditable limpio y vuelve el archivo reutilizable en flujos documentales mas amplios. Como validar la pagina exportada antes del handoff Antes de tratar el archivo Markdown como listo para produccion, inspeccionalo con los mismos estandares que aplicarias a un documento escrito a mano. Comprueba al menos lo siguiente: 1. Los encabezados reflejan la estructura original. 2. Los bloques de codigo son legibles y estan cercados correctamente. 3. Las tablas siguen siendo entendibles en revision de texto plano. 4. Los enlaces siguen apuntando a algo util. 5. El nombre y la ruta del archivo coinciden con la forma en que la organizacion espera almacenarlo. La exportacion de pagina es util precisamente porque la validacion es tractable. Aprovecha esa ventaja. Errores comunes en trabajo de migracion a nivel de pagina Los fallos habituales son simples y evitables. - exportar antes de confirmar el ID o la URL exacta de la pagina - tratar un flujo de una sola pagina como si fuera una migracion de espacio completo - escribir la salida en una ruta temporal que nunca entra en Git o en almacenamiento de retencion - asumir fidelidad de formato sin leer el Markdown resultante - ampliar el alcance demasiado pronto en lugar de demostrar calidad en una sola pagina primero La mayoria de los equipos no necesita mas tooling en esta fase. Necesita alcance mas estricto y mejor disciplina de revision. Por que la exportacion de una pagina encaja con SOPs y procedimientos regulados Un procedimiento operativo estandar, un runbook o una instruccion de trabajo regulada rara vez es el lugar correcto para una migracion masiva. Es el lugar donde quieres control quirurgico: un documento, un rastro de aprobacion, un artefacto exportado. Eso es justo lo que produce acp2md, y es por lo que la exportacion por pagina encaja con varios requisitos de control habituales: - ISO 9001:2015 clausula 7.5.2 (creacion y actualizacion de la informacion documentada) pide identificacion, formato y revision adecuados. Un fichero Markdown de una pagina con ruta estable y un commit en Git aporta los tres. - ISO/IEC 27001:2022 A.5.31 (requisitos legales, estatutarios, regulatorios y contractuales) y A.5.37 (procedimientos operativos documentados) piden procedimientos operativos documentados que puedan revisarse y actualizarse. La exportacion por pagina convierte un procedimiento de Confluence en un registro versionado sin arrastrar el resto del espacio. - NIS 2 Articulo 21(2)(b) exige procedimientos documentados de gestion de incidentes. Exportar un runbook de respuesta a incidentes con acp2md produce un artefacto portable que sobrevive a la perdida de acceso a Confluence durante el propio incidente. - SOC 2 Common Criteria CC2.2 exige politicas a nivel de entidad comunicadas y actualizadas. La exportacion por pagina lo soporta sin obligar antes a una migracion de espacio completo. La idea es que una pagina importante suele tener su propio ciclo de vida de cumplimiento. Tratarla como un solo artefacto — exportado, revisado, commit — es el flujo mas ligero que un auditor va a aceptar. Cuando conviene subir de acp2md a acs2md acp2md no es la herramienta incorrecta por ser mas estrecha. Se vuelve incorrecta cuando la necesidad operativa deja de ser especifica de una pagina. Pasa a acs2md cuando: - el objetivo es un espacio documental completo - las copias de continuidad deben mantenerse actualizadas en el tiempo - los enlaces internos deben reescribirse a traves de un patrimonio mas amplio - el flujo esta pasando de piloto a pipeline gobernado de migracion Los programas mas limpios suelen empezar pequeno, demostrar fidelidad en una pagina y luego ampliar el alcance de forma deliberada. Cierre Si una sola pagina de Confluence es la unidad real de riesgo, exporta esa pagina con control exacto en lugar de abrir un frente de migracion mayor del que el equipo necesita. Con acp2md, los equipos pueden crear artefactos Markdown limpios para compliance, operaciones, IA y flujos Docs-as-Code sin esperar una decision de espacio completo. Eso convierte la exportacion de pagina en un primer paso practico y no en una solucion de compromiso. Cuando estes listo, empieza con acp2md en la tienda.]]></content:encoded>
            <category>page-export</category>
            <category>confluence</category>
            <category>markdown</category>
            <category>acp2md</category>
            <category>single-page-export</category>
            <category>compliance</category>
            <category>ai-ready-content</category>
            <category>iso-9001</category>
            <category>iso-27001</category>
            <category>sop</category>
        </item>
        <item>
            <title><![CDATA[Como preparar contenido de Confluence para IA antes de que llegue a tu pipeline RAG]]></title>
            <link>https://blog.climakers.com/es/blog/como-preparar-contenido-de-confluence-para-ia-antes-de-que-llegue-a-tu-pipeline-rag</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/como-preparar-contenido-de-confluence-para-ia-antes-de-que-llegue-a-tu-pipeline-rag</guid>
            <pubDate>Tue, 21 Apr 2026 09:00:00 GMT</pubDate>
            <description><![CDATA[Una guia practica para equipos que necesitan exportar contenido de Confluence a Markdown limpio antes de que el chunking, la indexacion y el retrieval amplifiquen el ruido de formato — y una checklist para que el pipeline de IA siga alineado con ISO 27001, NIS 2 y SOC 2.]]></description>
            <content:encoded><![CDATA[La mayoria de los equipos no tiene primero un problema de IA. Tiene un problema de calidad de contenido que los sistemas de IA vuelven mas caro. Cuando el contenido de Confluence entra directamente en flujos de chunking, embeddings y retrieval sin limpieza previa, cada defecto de formato se amplifica. Una mala estructura genera malos limites de chunks. Una exportacion ruidosa genera retrieval ruidoso. Enlaces defectuosos y tablas aplanadas terminan convertidos en respuestas debiles delante del usuario. Por eso el trabajo de contenido listo para IA debe empezar antes del pipeline RAG. La capa de exportacion tiene que producir Markdown portable con estructura estable, bloques de codigo legibles y rutas predecibles antes de empezar a indexar. Por que las exportaciones crudas de Confluence debilitan la calidad del retrieval Un stack de retrieval solo es tan confiable como los documentos que ingiere. Cuando el contenido llega con mala estructura, los fallos son predecibles: - los chunks se rompen en limites incorrectos porque los encabezados son debiles o inconsistentes - los ejemplos de codigo pierden claridad y son mas dificiles de usar como base para el modelo - las tablas se aplanan en texto de poca señal que perjudica el retrieval - las referencias internas siguen apuntando a Confluence en lugar de apuntar al patrimonio documental durable - markup duplicado o ruidoso contamina los embeddings con tokens irrelevantes Esto no es solo un problema de formato. Es un problema de precision de retrieval. Que debe preservar un Markdown listo para IA Si el objetivo es RAG, busqueda asistida o retrieval interno de conocimiento, el Markdown exportado debe preservar la estructura de la que dependen tanto personas como sistemas. Eso suele significar: - encabezados que reflejen secciones semanticas reales - bloques de codigo que sigan cercados y legibles - tablas que sigan siendo lo bastante entendibles como para resumirlas o revisarlas - nombres de archivo y rutas estables para pipelines de indexacion - metadata que mantenga identidad de la fuente, locale y relaciones entre contenidos Un Markdown limpio da mejores entradas a los chunkers. Mejores entradas suelen producir mejor retrieval. Por que el alcance de pagina y el alcance de espacio importan para preparar IA Algunos trabajos de preparacion para IA empiezan con una sola pagina de alto valor. Otros empiezan con un patrimonio documental entero. Usa acp2md cuando la unidad de valor sea una pagina que necesita tratamiento exacto antes de entrar a un flujo de IA. Usa acs2md cuando la necesidad sea convertir y refrescar un espacio mas amplio de Confluence para que todo el patrimonio pueda alimentar indexacion, retrieval o busqueda asistida. La eleccion no trata solo del formato. Trata de elegir el alcance correcto para que el Markdown exportado siga siendo gobernable. Flujo recomendado antes de que el contenido llegue al stack RAG La secuencia mas segura es validar el entorno, confirmar el alcance de la fuente, exportar a Markdown portable y solo entonces entregar el contenido a las etapas de chunking e indexacion. 1. Valida el entorno del operador Antes de la primera exportacion, comprueba credenciales, licencia y runtime local. Eso elimina fallos evitables antes de que el pipeline de IA vea el contenido fuente. 2. Confirma el alcance real de la fuente Para una sola pagina de alto valor, confirma la pagina directamente. Para un patrimonio de conocimiento mas amplio, inspecciona el espacio objetivo. Eso mantiene la ingesta alineada con el conjunto fuente real y no con suposiciones. 3. Exporta primero a Markdown controlado por el cliente Para una pagina: Para un espacio completo: Ese es el punto de handoff donde el contenido propietario se convierte en Markdown durable bajo control del equipo. 4. Revisa el Markdown antes del chunking No alimentes embeddings directamente con la exportacion sin inspeccion. Revisa si: 1. los encabezados reflejan secciones reales 2. los bloques de codigo se mantuvieron intactos 3. las tablas siguen teniendo significado util 4. los enlaces y nombres de archivo son estables 5. la ruta de salida encaja con la convencion de indexacion Si el Markdown es ruidoso aqui, el sistema RAG normalmente sera ruidoso despues. 5. Indexa solo el patrimonio limpio Una vez que el arbol Markdown es estable, el pipeline de indexacion o chunking puede tratarlo como una fuente gobernada y no como un artefacto temporal de exportacion. Esa separacion importa. Mantiene auditable y reutilizable la capa de preparacion de contenido fuera de cualquier proveedor unico de IA o stack de retrieval. Por que Git sigue importando en flujos de IA Los equipos suelen hablar de embeddings, vector stores y estrategias de chunking mientras saltan el plano de control mas basico: contenido fuente versionado. Git ayuda a los flujos de contenido listo para IA porque da a los equipos: - diffs visibles cuando cambia el conocimiento fuente - checkpoints recuperables para revisiones de contenido indexado - historial revisable para fuentes sensibles a auditoria - un puente durable entre operaciones documentales y operaciones de ML o busqueda Si el Markdown fuente no esta gobernado, la capa de retrieval acaba cargando demasiada ambiguedad. Errores comunes antes de la ingesta RAG Los mismos errores aparecen una y otra vez: - indexar exportaciones crudas antes de comprobar la calidad del formato - dejar que encabezados defectuosos definan los limites de chunks - tratar bloques de codigo y tablas como ruido descartable - perder identidad de fuente y estabilidad de rutas entre refrescos - acoplar demasiado la capa de conocimiento a una sola herramienta posterior La mayoria de estos problemas se resuelve antes de lo que la gente cree. Son problemas de disciplina de exportacion antes de convertirse en problemas de IA. Contenido listo para IA es contenido listo para auditoria Un pipeline RAG no es un permiso para saltarse el control de la informacion documentada. En el momento en que el contenido de Confluence se incrusta en un vector store y se sirve a traves de un asistente, pasa a formar parte de la misma superficie documental que miran tus auditores. - ISO/IEC 27001:2022 A.5.12 (clasificacion de la informacion) y A.5.13 (etiquetado de la informacion) se aplican antes de que el contenido entre al retrieval. Si una pagina es restringida, embeber-la en un indice no restringido rompe el control. Un patrimonio Markdown en Git permite filtrar por ruta o front matter antes de indexar, en vez de pedirle al vector store que aplique una clasificacion que no ve. - ISO/IEC 27001:2022 A.5.33 (proteccion de registros) y A.8.13 (copia de seguridad) siguen aplicando al corpus fuente. El Markdown limpio que alimenta el indice es el sistema de registro. Tratalo como tal. - NIS 2 Articulo 21(2)(d) (seguridad en la cadena de suministro) se interpreta cada vez mas como aplicable a proveedores de IA. Un corpus Markdown bajo control local es una frontera apta para auditoria entre tu conocimiento y un proveedor de modelos externo. - SOC 2 Common Criteria CC6.1 (acceso logico) y CC8.1 (gestion de cambios) piden evidencia de cambio autorizado en sistemas que afectan a la seguridad. Un corpus versionado en Git aporta esa evidencia para el contenido fuente del retrieval, incluso cuando el almacen de embeddings no la aporta. - ISO 9001:2015 clausula 7.1.6 (conocimiento de la organizacion) pide a las organizaciones mantener el conocimiento necesario para la operacion de los procesos. Un corpus Markdown que alimenta tanto a personas como a asistentes es una de las formas mas limpias de cumplir esa clausula sin duplicar la base de conocimiento entre sistemas. La conclusion es simple: el contenido listo para IA tambien es contenido listo para auditoria cuando empieza siendo Markdown bajo control del cliente y bajo control de versiones. Cuando el tooling de Climakers encaja bien acp2md y acs2md encajan bien cuando el equipo quiere Markdown controlado por el cliente antes de que el contenido entre en flujos de IA, busqueda o Docs-as-Code. Eso suele significar: - proyectos de retrieval que necesitan artefactos fuente limpios - sistemas de busqueda asistida que dependen de estructura estable - entornos regulados que necesitan historial fuente apto para auditoria - patrimonios de contenido que deben servir tanto a personas como a sistemas de IA Los pipelines de IA mas solidos suelen empezar con mejor contenido fuente, no con postprocesamiento mas elaborado. Cierre Si el contenido de Confluence va camino de un pipeline RAG, la decision mas importante puede ocurrir antes de que empiece el chunking. Exporta primero el contenido a Markdown limpio, estructurado y controlado por el cliente. Eso da a los sistemas de retrieval una base mejor, mantiene gobernable el patrimonio documental y evita que el ruido de formato se convierta en ruido visible para el modelo a escala. Cuando estes listo para que Markdown sea tu sustrato de IA y de auditoria, elige un plan de acs2md en la tienda o empieza con acp2md para una pagina critica.]]></content:encoded>
            <category>ai-content</category>
            <category>confluence</category>
            <category>markdown</category>
            <category>rag</category>
            <category>ai-ready-content</category>
            <category>acp2md</category>
            <category>acs2md</category>
            <category>compliance</category>
            <category>iso-27001</category>
            <category>nis-2</category>
            <category>soc-2</category>
        </item>
        <item>
            <title><![CDATA[Introduccion a acs2md: que es y por que es util para desarrolladores]]></title>
            <link>https://blog.climakers.com/es/blog/introduccion-a-acs2md-que-es-y-por-que-es-util-para-desarrolladores</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/introduccion-a-acs2md-que-es-y-por-que-es-util-para-desarrolladores</guid>
            <pubDate>Mon, 20 Apr 2026 13:00:00 GMT</pubDate>
            <description><![CDATA[acs2md convierte espacios completos de Confluence en Markdown portable con jerarquia preservada, enlaces reescritos y flujos repetibles a escala, alineados con los requisitos de evidencia de ISO 9001, ISO 27001, ISO 27017, NIS 2 y SOC 2.]]></description>
            <content:encoded><![CDATA[acs2md es el convertidor masivo de espacios dentro del portfolio de Climakers. Esta pensado para el momento en que un equipo deja de preguntar "como exportamos esta pagina" y empieza a preguntar "como movemos o preservamos toda esta base documental sin perder control". Esa diferencia importa. Una herramienta de pagina unica resuelve un problema local. Un convertidor a escala de espacio resuelve migracion, continuidad, cumplimiento, gobernanza e ingestion para IA de forma operativa y repetible. acs2md en una frase acs2md convierte un espacio completo de Atlassian Confluence Cloud en Markdown mientras preserva la jerarquia de paginas, reescribe enlaces internos y sigue futuras actualizaciones mediante .convert-sync-state.json. En la practica, eso permite: - mantener una copia de continuidad fuera de Confluence - preparar una migracion a docs-as-code en Git - construir un corpus repetible de Markdown para RAG o busqueda empresarial - inspeccionar permisos, propiedades e inventario antes de exportar nada - hacer que las siguientes ejecuciones omitan paginas sin cambios Por que les importa a los desarrolladores La mayoria de equipos no compra un convertidor de espacios porque le guste convertir. Lo hace porque hay un flujo mas grande bloqueado. Las razones tipicas del lado tecnico incluyen: - una migracion a sitio estatico necesita estructura, no un monton de archivos planos - un repositorio Git necesita enlaces locales que sigan funcionando despues de exportar - un pipeline RAG necesita Markdown repetible en vez de un formato propietario - un plan de continuidad necesita una copia local que pueda revisarse, respaldarse y auditarse fuera de la plataforma fuente - un programa de migracion necesita comandos de descubrimiento antes de una exportacion masiva La documentacion posiciona acs2md como una herramienta para continuidad, payloads de migracion, exportaciones gobernadas y portabilidad documental a escala. Ese encuadre es mucho mas util que llamarlo solo "CLI de exportacion masiva". Que cubre realmente acs2md acs2md es mas amplio que space convert. La superficie operativa se parece mas a un pequeno toolkit: | Area de comandos | Para que sirve | | ----------------------------------------- | ------------------------------------------------------------------------- | | space convert | Exportar un espacio completo a Markdown | | space get | Descargar payloads nativos de Confluence en ADF JSON o storage HTML | | space list y space pages | Descubrir el alcance antes de una exportacion importante | | space properties y space permissions | Capturar contexto de gobernanza junto al contenido | | subcomandos page ... | Inspeccionar o convertir una sola pagina sin cambiar de binario | | doctor, tree, support, completion | Validar, descubrir, depurar y automatizar la superficie de la herramienta | Esa separacion es util porque las migraciones reales rara vez son un solo comando. Los operadores necesitan validacion, descubrimiento y comprobaciones posteriores. Por que importa para programas de cumplimiento y continuidad Si tu equipo opera en un entorno regulado, acs2md tambien es el artefacto que convierte el contenido de Confluence en evidencia. Varios de los controles que pesan a tus auditores piden lo mismo: una copia actual, restaurable e inspeccionable de la informacion documentada que no dependa de que la plataforma de origen este disponible. - ISO 9001:2015 clausula 7.5 exige que la informacion documentada este controlada, vigente y disponible. Un patrimonio Markdown en Git satisface el requisito de "control de la informacion documentada" sin atrapar el registro dentro del portal de un proveedor. - ISO/IEC 27001:2022 A.5.30 (preparacion TIC para la continuidad de negocio) y A.8.13 (copia de seguridad de la informacion) exigen recuperacion probada y backups repetibles. Una corrida programada de acs2md space convert --sync cumple exactamente eso. - ISO/IEC 27017:2015 CLD.12.1.5 trata la seguridad operacional del cliente cloud. Un acceso GET de solo lectura contra Confluence Cloud, ejecutado desde tu propia automatizacion, es justo el tipo de control admin-side que pide la norma. - NIS 2 Articulo 21(2)(c) exige continuidad de negocio, gestion de copias y gestion de crisis para entidades esenciales e importantes. Una copia versionada en Git te da el artefacto y el rastro auditable de una sola vez. - SOC 2 Disponibilidad (A1.2 y A1.3) pide procesos de backup y pruebas de recuperacion. Los commits etiquetados son puntos de restauracion y acs2md doctor produce evidencia de que la ruta de recuperacion sigue funcionando. Por eso la documentacion habla de continuidad, gobernanza e ingestion para IA en la misma frase: en un patrimonio documental regulado, son el mismo flujo. Cuando acs2md es la herramienta correcta Usa acs2md cuando la pregunta sea sobre toda una base documental. Eso incluye: - migraciones a docs-as-code donde la jerarquia debe sobrevivir - copias de continuidad con refrescos recurrentes - programas de archivo que deben sobrevivir a borrados en Confluence - ingestion para RAG o busqueda que debe regenerarse de forma programada - trabajo de gobernanza donde permisos y metadatos importan tanto como el contenido Si la necesidad real es una pagina exacta, acp2md sigue siendo la herramienta mas precisa. La documentacion lo dice claramente, y tiene sentido: los flujos de pagina y los flujos de espacio no son el mismo problema operativo. Limites que conviene saber desde el principio La documentacion actual deja varias condiciones muy claras: - acs2md soporta solo Confluence Cloud - los binarios publicados estan disponibles para macOS y Linux - la herramienta es de solo lectura y usa peticiones GET contra Confluence - los trabajos largos muestran progreso por stderr para no contaminar stdout No son detalles menores. Te dicen si la herramienta encaja con tu plataforma, tu modelo de seguridad y tu pipeline antes de invertir tiempo. Un flujo realista para el primer operador La primera ejecucion recomendada no es improvisada. La documentacion de cliente y el manual en GitHub coinciden en una secuencia muy concreta: Ese flujo hace cuatro cosas en orden: 1. demuestra que la maquina esta lista 2. confirma que el espacio objetivo es el correcto 3. muestra la jerarquia antes de convertir 4. produce un arbol portable de Markdown con enlaces locales Esa es exactamente la disciplina que los equipos necesitan cuando la exportacion esta ligada a una ventana de migracion, una revision con cliente o un compromiso de backup. Por que el state file importa mas de lo que parece acs2md usa .convert-sync-state.json para comparar las versiones actuales de paginas con las de ejecuciones anteriores. Eso permite que las exportaciones futuras omitan contenido sin cambios y reconviertan solo lo que realmente se movio. Eso importa porque la herramienta no sirve solo para una migracion puntual. Tambien esta pensada para flujos recurrentes de mantenimiento. Ese archivo hace posibles dos modos clave: - --sync para espejos vivos que borran archivos locales si la pagina desaparece del origen - --incremental para exportaciones tipo archivo que conservan el contenido local aunque haya borrados aguas arriba Los dos patrones aparecen constantemente en programas reales de documentacion. Recomendacion final Trata acs2md como una herramienta de control y portabilidad para espacios de Confluence, no solo como un convertidor. Si tu equipo necesita exportaciones repetibles, propiedad local de la documentacion o un corpus Markdown que pueda alimentar Git, cumplimiento o flujos de IA, acs2md es un muy buen punto de partida. Empieza por la vision general y pasa enseguida a la guia de primeros pasos y al documento sobre --sync frente a --incremental. Esa secuencia te lleva de la posicion del producto a un flujo realmente operativo.]]></content:encoded>
            <category>space-conversion</category>
            <category>acs2md</category>
            <category>confluence</category>
            <category>markdown</category>
            <category>docs-as-code</category>
            <category>developer-workflows</category>
            <category>compliance</category>
            <category>iso-27001</category>
            <category>nis-2</category>
        </item>
        <item>
            <title><![CDATA[Primeros pasos con acs2md: instalacion y uso basico]]></title>
            <link>https://blog.climakers.com/es/blog/primeros-pasos-con-acs2md-instalacion-y-uso-basico</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/primeros-pasos-con-acs2md-instalacion-y-uso-basico</guid>
            <pubDate>Sat, 18 Apr 2026 17:00:00 GMT</pubDate>
            <description><![CDATA[Instala acs2md, configura el acceso a Confluence, valida la maquina con doctor y completa tu primera exportacion masiva en el orden correcto.]]></description>
            <content:encoded><![CDATA[La forma mas rapida de tener una mala primera impresion de acs2md es lanzar una exportacion masiva antes de que la maquina este lista. La documentacion oficial evita ese error a proposito: va de instalacion a diagnostico y a descubrimiento antes de la primera conversion real. Ese orden merece mantenerse. Ahorra mucho mas tiempo que cualquier decision inteligente sobre flags al final. Antes de empezar La documentacion de cliente enumera los prerequisitos con bastante claridad. Para una primera ejecucion limpia necesitas: - un sitio Confluence Cloud como mycompany.atlassian.net - un usuario con acceso de lectura a los espacios que vas a exportar - una licencia valida de acs2md, o un archivo de licencia local para entornos restringidos - acceso de red desde la maquina hacia Confluence Cloud - espacio suficiente en disco para la primera exportacion acs2md no soporta Server ni Data Center, y los binarios publicados son actualmente para macOS y Linux. Paso 1: instalar el binario y verificarlo La documentacion separa la instalacion por plataforma: - en macOS se distribuye como .pkg universal - en Linux se distribuye como zip por arquitectura En ambos casos, la primera comprobacion tecnica deberia ser version y ubicaciones: Si esos comandos responden como esperas, la instalacion es correcta y ya sabes donde viven el config y la licencia por defecto. Paso 2: crear configuracion antes de tocar contenido Usa el archivo de configuracion por defecto salvo que tengas una razon real para aislar entornos: La documentacion muestra tres formas soportadas de configurar el acceso a Confluence. Archivo de configuracion Comandos CLI Variables de entorno La documentacion de configuracion es explicita con la precedencia: defaults internos, archivo de configuracion, variables de entorno y por ultimo flags CLI. Eso permite guardar valores duraderos en config y mover secretos o overrides a automatizacion. Paso 3: activar la licencia y validar la maquina Activa una vez en la maquina objetivo: Si trabajas en un entorno aislado, usa --license-file. Despues ejecuta el comando mas importante del producto: doctor comprueba configuracion, credenciales, conectividad con la API, estado de licencia, identidad de maquina y version en una sola pasada. La documentacion recomienda ejecutarlo justo despues de activar la licencia, tras cambios de credenciales y antes de exportaciones programadas o de cara al cliente. Es la costumbre correcta. Paso 4: descubrir el espacio antes de convertirlo La exportacion masiva deberia empezar por descubrimiento, no por optimismo. Usa space list para confirmar el conjunto objetivo: Luego inspecciona el espacio concreto: La documentacion senala un detalle facil de pasar por alto: space pages usa --format json; el flag antiguo --json ya no aplica a la release actual. Eso importa porque la salida de descubrimiento suele ir a notas de proyecto, revision de migracion o validacion con cliente. Paso 5: ejecutar la primera exportacion real Una vez validados la maquina y el alcance, el primer comando real es sencillo: El comportamiento del directorio de salida tambien importa: acs2md anade la key del espacio como subdirectorio, asi que el resultado cae en ./docs/TEAMDOCS y no directamente en ./docs. Desde ahi, la herramienta: - obtiene las paginas del espacio - preserva la jerarquia como carpetas y archivos - genera Markdown - crea .convert-sync-state.json - omite paginas sin cambios en ejecuciones futuras En la documentacion observada, el comportamiento por defecto es incremental cuando no se pasa ni --sync ni --incremental. Si algo falla, sigue la ruta de depuracion soportada La documentacion da un orden de escalado muy limpio: 1. volver a ejecutar acs2md doctor 2. verificar el config activo con acs2md config where 3. confirmar la licencia con acs2md license validate 4. confirmar de nuevo el alcance con space list y space pages 5. reproducir con debug logging y luego generar un support bundle Ese flujo es mejor que depurar de forma ad hoc porque captura entorno, diagnostico y logs recientes en un solo artefacto. Por que estos chequeos tambien son evidencia de cumplimiento La secuencia de configuracion anterior tambien es un flujo silencioso de generacion de evidencia para programas ISO 27001 y SOC 2. - acs2md doctor produce un chequeo de preparacion determinista que mapea directamente con ISO/IEC 27001:2022 A.8.6 (gestion de capacidad) y A.5.37 (procedimientos operativos documentados) — los operadores pueden demostrar que la validacion previa a la exportacion es repetible y no improvisada. - acs2md config where y acs2md license validate producen evidencia de que ISO/IEC 27001:2022 A.5.18 (derechos de acceso) y los compromisos de cumplimiento de licencia se comprueban antes de que el contenido salga de la plataforma fuente. - La via --debug --log-file produce logs aptos para evidencia de SOC 2 CC7.2 (monitorizacion del sistema) y de gestion de incidentes NIS 2 . Conservalos en el mismo esquema de retencion que el resto de los logs operativos. No hace falta meter una segunda herramienta para producir esta evidencia. Los comandos de setup que ibas a lanzar de todos modos ya son el artefacto correcto. Recomendacion final La primera ejecucion correcta de acs2md no es solo "instalar y convertir". Es instalar, verificar, configurar, diagnosticar, descubrir y solo entonces exportar. Si sigues ese orden, la primera exportacion masiva suele ser directa. Si te lo saltas, empujas errores de setup a la parte mas cara del flujo. Empieza con doctor, confirma el espacio con space pages --tree y deja que la primera exportacion ocurra solo cuando la maquina este obviamente lista.]]></content:encoded>
            <category>space-conversion</category>
            <category>acs2md</category>
            <category>installation</category>
            <category>confluence</category>
            <category>onboarding</category>
            <category>bulk-export</category>
            <category>iso-27001</category>
            <category>compliance</category>
        </item>
        <item>
            <title><![CDATA[Funciones avanzadas de acs2md: personalizacion e integracion]]></title>
            <link>https://blog.climakers.com/es/blog/funciones-avanzadas-de-acs2md-personalizacion-e-integracion</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/funciones-avanzadas-de-acs2md-personalizacion-e-integracion</guid>
            <pubDate>Thu, 16 Apr 2026 11:00:00 GMT</pubDate>
            <description><![CDATA[Aprende que flags de acs2md controlan metadatos, enlaces, media y macros, y como integrar la salida con Git, CI, migracion e ingestion para IA.]]></description>
            <content:encoded><![CDATA[El flujo principal de acs2md es intencionadamente simple: convertir un espacio a Markdown. El valor avanzado aparece cuando empiezas a moldear esa salida para el sistema aguas abajo que va a consumirla. En ese punto los flags dejan de ser detalles cosmeticos y se convierten en decisiones de arquitectura. La primera capa de personalizacion: contenido, enlaces y media La documentacion de space convert organiza los controles mas importantes en tres grupos. Contenido y metadatos - --include-metadata anade front matter YAML con titulos, autores, fechas, IDs y estado. - --exclude-marks=true elimina formato inline para una salida mas orientada a texto plano. - --exclude-marks=false conserva formato inline mas rico cuando el render de destino puede aprovecharlo. Esa eleccion cambia si la exportacion esta pensada para publicacion, revision de migracion o ingestion para IA. Enlaces Por defecto, acs2md reescribe URLs de Confluence a rutas locales relativas. Eso es ideal para conjuntos portables de Markdown y documentacion en Git. Desactivarlo solo tiene sentido cuando quieres archivos locales pero necesitas conservar las URLs originales. Imagenes y media La documentacion es bastante clara: incrustar imagenes aumenta el tamano de los archivos. Si el objetivo es un pipeline orientado a texto, desactivar imagenes suele ser el tradeoff correcto. La segunda capa: renderizado de macros y extensiones acs2md expone un conjunto sorprendentemente util de flags para construcciones comunes de Confluence: - --ext-render-toc - --ext-render-recently-updated - --ext-render-listlabels - --ext-render-pagetree - --ext-render-children - --ext-render-contributors - --ext-render-page-signatures - --ext-render-qc-properties - --ext-render-task-report - --ext-render-content-report - --ext-resolve-inline-card-titles Esa superficie importa cuando el contenido exportado debe seguir siendo legible fuera de Confluence y no solo convertirse tecnicamente. Por ejemplo: Estas opciones ayudan a transformar estructuras propias de Confluence en Markdown mas util para revisar, publicar o indexar. Patrones de integracion que aparecen en proyectos reales La pagina de workflows de cliente deja bastante claro cuales son los usos aguas abajo. Un buen modelo mental seria este: | Workflow objetivo | Opciones utiles de acs2md | | ---------------------------- | ---------------------------------------------------------------------------- | | Sitio estatico o docs en Git | --include-metadata, --rewrite-links, --output-dir estable | | RAG o busqueda empresarial | --exclude-marks, --embed-images=false, ejecuciones programadas | | Ingenieria de migracion | space pages --tree, space get --format atlas doc format, luego convertir | | Revision de gobernanza | space list, space properties, space permissions --resolve-users | | Operacion programada | variables de entorno para secretos, --sync, --log-file | La idea clave es que la integracion no es un patron unico. El contrato de salida correcto depende de si el consumidor es una persona, Git, un renderer estatico o un pipeline de indexacion. Cuando space get es la mejor jugada avanzada Uno de los detalles mas utiles de la documentacion es la diferencia entre space convert y space get. Usa space convert cuando quieras Markdown portable. Usa space get cuando quieras primero el payload nativo: Ese es el movimiento correcto para ingenieria de migracion, depuracion de reglas propias o cualquier caso donde quieras la representacion fuente antes de comprometerte con el render a Markdown. CI, logging y ergonomia para operadores La documentacion de configuracion y utilidades completa los detalles de automatizacion: - cualquier clave puede sobreescribirse con variables ACS2MD ... - --log-file puede enviar logs a archivo, stdout o stderr - --no-progress deja limpios los logs de CI - tree --short sirve para runbooks y onboarding - support crea un bundle diagnostico util para escalado Una ejecucion programada practica se parece a esto: Esa es la diferencia entre un comando de demo y una integracion realmente operativa. Como conectar los flags avanzados con un pipeline de cumplimiento Los mismos flags que personalizan la salida tambien producen evidencia de control cuando se usan dentro de un job de CI o de un runner programado. - --log-file con --debug te da un log determinista por corrida, que es justo el artefacto que piden ISO/IEC 27001:2022 A.8.15 (logging) y NIS 2 Articulo 21(2)(f) . Fija el plazo de retencion del log en tu politica de control de registros y el control queda defendible. - --include-metadata y las opciones de front matter conservan la identidad de la fuente y las fechas. Eso permite cumplir ISO 9001:2015 clausula 7.5.3 (control de la informacion documentada) para campos como autor, revision y supersesion. - space get --format atlas doc format produce un snapshot nativo de origen. Ese snapshot, junto con el Markdown renderizado, le da a SOC 2 CC8.1 (gestion de cambios) un artefacto antes/despues limpio. - Ejecutar acs2md desde CI bajo una identidad fija, con --no-progress y logs estructurados, encaja con ISO/IEC 27001:2022 A.8.31 (separacion de entornos) y A.8.32 (gestion de cambios) cuando los entregables documentales salen de un pipeline controlado. En resumen: la superficie avanzada tambien es la superficie de auditoria. Los flags que ibas a usar de todos modos son los que producen la evidencia. Recomendacion final No trates la superficie avanzada de flags como complejidad opcional. Es la capa que permite que el mismo producto alimente un flujo de publicacion en Git, un archivo de cumplimiento, una revision de ingenieria de migracion o un corpus para RAG sin fingir que esos trabajos son iguales. Empieza decidiendo que debe hacer la salida despues de exportar. Luego elige metadatos, enlaces, media, renderizado de macros y modo de seguimiento para ajustarlo a ese contrato. Esa es la forma mas limpia de obtener Markdown util en lugar de solo Markdown convertido.]]></content:encoded>
            <category>space-conversion</category>
            <category>acs2md</category>
            <category>integration</category>
            <category>automation</category>
            <category>migration</category>
            <category>markdown</category>
            <category>iso-27001</category>
            <category>soc-2</category>
            <category>compliance</category>
        </item>
        <item>
            <title><![CDATA[Mejores practicas para usar acs2md en tus proyectos]]></title>
            <link>https://blog.climakers.com/es/blog/mejores-practicas-para-usar-acs2md-en-tus-proyectos</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/mejores-practicas-para-usar-acs2md-en-tus-proyectos</guid>
            <pubDate>Mon, 13 Apr 2026 15:00:00 GMT</pubDate>
            <description><![CDATA[Usa acs2md como un flujo operativo, no como un comando aislado: valida la maquina, confirma alcance, elige bien el contrato de salida y normaliza la depuracion.]]></description>
            <content:encoded><![CDATA[acs2md funciona mejor cuando los equipos lo tratan como un sistema operativo de exportacion y no como un comando aislado. La documentacion lo refuerza varias veces: valida la maquina, descubre el objetivo, elige el modo correcto y guarda evidencia util cuando algo falle. Eso es lo que hace que una exportacion masiva sea aburrida en el mejor sentido. 1. Ejecuta doctor cada vez que cambie el entorno La documentacion de utilidades recomienda doctor despues de activar licencia, despues de cambiar credenciales, antes de la primera exportacion masiva y antes de ejecuciones programadas o de cara al cliente. Ese deberia ser el baseline: Comprueba: - validez del archivo de configuracion - credenciales de Confluence - conectividad real con la API - presencia y validez de la licencia - identidad de maquina - version actual y metadata de build Si te saltas ese paso, empujas errores de entorno a la parte mas cara del flujo. 2. Descubre el alcance antes de convertir nada La guia de primeros pasos y la de workflows colocan el descubrimiento antes de la conversion. Manten ese habito. Por que importa: - confirma que estas exportando el espacio correcto - permite que stakeholders revisen la jerarquia antes del run - reduce exportaciones accidentales durante migraciones o trabajo con cliente Cuando la gobernanza importa, amplia tambien esa superficie: Asi traes metadatos y permisos dentro del mismo programa de exportacion. 3. Decide el contrato de salida antes de elegir flags Muchos equipos eligen flags uno por uno. Un enfoque mejor es decidir que debe representar el directorio final. Ejemplos: - un espejo vivo de documentacion: usa --sync, conserva --rewrite-links, usa un directorio estable - un archivo a largo plazo: conserva el comportamiento incremental por defecto o pasa --incremental - un corpus RAG: usa --exclude-marks, a menudo desactiva imagenes embebidas y mantén refrescos previsibles - un staging de migracion: incluye metadatos para no perder identificadores ni fechas El contrato de salida debe dirigir los flags, no al reves. 4. Saca los secretos del historial del shell cuando puedas La documentacion de configuracion recomienda una separacion limpia: - dejar defaults no secretos en el archivo de configuracion - inyectar secretos por variables de entorno cuando sea posible - usar flags CLI para overrides puntuales y depuracion Eso es especialmente util en CI/CD: Si necesitas entornos separados en una sola maquina, usa --config-file en lugar de editar a mano el mismo config una y otra vez. 5. Elige un directorio estable para trabajos recurrentes El seguimiento de estado depende de un directorio estable porque .convert-sync-state.json vive junto al Markdown exportado. De ahi salen dos reglas practicas: - mantén el mismo --output-dir cuando quieras refrescos solo sobre cambios - evita --conflict-resolution=versioned si esperas que sync o incremental sigan funcionando, porque un directorio con timestamp no es un hogar estable para el state file Es un punto sutil, pero afecta directamente a la eficiencia de ejecuciones futuras. 6. Haz que logs y support bundles sean rutina, no excepcion Los trabajos masivos son mas faciles de confiar cuando dejan evidencia. El bundle de soporte incluye configuracion enmascarada, diagnostico, contexto del entorno y logs recientes. Es valioso incluso dentro de tu propio equipo antes de pensar en soporte externo. 7. Separa workflows por objetivo La pagina de workflows es util precisamente porque no finge que un solo perfil de exportacion sirve para todo. Usa comandos o destinos distintos segun el objetivo: - copia de continuidad: --sync - archivo con retencion: --incremental - planificacion de migracion: space pages --tree, luego space convert --include-metadata - analisis de ingenieria nativa: space get --format atlas doc format - revision de gobernanza: space list, space properties, space permissions Cuando cambia el objetivo, debe cambiar tambien el contrato de salida. Una checklist corta para operadores Antes de una ejecucion real, confirma que todo esto sea verdad: - doctor pasa - el espacio correcto se confirmo con space list y space pages - el modo es explicito cuando el borrado importa - los secretos viven en config o variables, no copiados en notas - hay logs activados para ejecuciones recurrentes o importantes - el directorio destino es estable para el seguimiento de estado Si incluso uno de estos puntos no esta claro, para y corrigelo antes de exportar. Como mapear estas practicas a controles ISO 27001 y SOC 2 Cada una de las practicas anteriores tambien es una declaracion de control que un auditor puede verificar. Si operas dentro de un programa ISO 27001, ISO 27017, NIS 2 o SOC 2, asi se alinean las siete: | Practica | Punto de anclaje en el marco | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | doctor antes de corridas programadas | ISO/IEC 27001:2022 A.5.37 (procedimientos operativos documentados), SOC 2 CC7.2 (monitorizacion del sistema) | | Descubrimiento antes de convertir | ISO/IEC 27001:2022 A.5.10 (uso aceptable), A.5.18 (derechos de acceso) | | Contrato de salida decidido por adelantado | ISO/IEC 27001:2022 A.5.33 (proteccion de registros), RGPD Art. 5(1)(e) (limitacion del plazo de conservacion) | | Secretos fuera del historial de la shell | ISO/IEC 27001:2022 A.8.12 (prevencion de fuga de datos), A.5.17 (informacion de autenticacion) | | Directorio de salida estable para corridas recurrentes | ISO/IEC 27001:2022 A.8.13 (copia de seguridad), SOC 2 A1.2 (procesos de backup) | | Logging y support bundles como rutina | ISO/IEC 27001:2022 A.8.15 (logging), A.8.16 (monitorizacion de actividades), NIS 2 Articulo 21(2)(f) (gestion de logs y eventos) | | Workflows separados por proposito | ISO 9001:2015 clausula 4.4 (enfoque a procesos), ISO/IEC 27001:2022 A.5.30 (preparacion TIC para la continuidad de negocio) | El mensaje practico es que no hay un "modo cumplimiento" extra que activar. El flujo defendible y el flujo productivo son el mismo flujo cuando eliges los valores por defecto correctos. Recomendacion final La mejor practica con acs2md no es un flag concreto. Es disciplina operativa. Los equipos que mas provecho le sacan son los que validan la maquina, confirman alcance, eligen bien el contrato espejo-o-archivo y guardan suficiente logging como para explicar luego lo ocurrido. Asi es como una herramienta de conversion se convierte en una operacion documental confiable.]]></content:encoded>
            <category>space-conversion</category>
            <category>acs2md</category>
            <category>best-practices</category>
            <category>docs-as-code</category>
            <category>governance</category>
            <category>confluence</category>
            <category>iso-27001</category>
            <category>soc-2</category>
            <category>compliance</category>
        </item>
        <item>
            <title><![CDATA[--sync vs --incremental: diferencias y cuando usar cada modo]]></title>
            <link>https://blog.climakers.com/es/blog/sync-vs-incremental-diferencias-y-cuando-usar-cada-modo</link>
            <guid isPermaLink="false">https://blog.climakers.com/es/blog/sync-vs-incremental-diferencias-y-cuando-usar-cada-modo</guid>
            <pubDate>Sat, 11 Apr 2026 09:00:00 GMT</pubDate>
            <description><![CDATA[Entiende como acs2md usa .convert-sync-state.json, por que incremental es el modo por defecto y cuando los archivos borrados deben quedarse o desaparecer — incluyendo las preguntas de retencion de ISO 27001, NIS 2 y SOC 2 escondidas en esa decision.]]></description>
            <content:encoded><![CDATA[Si solo vas a recordar una cosa sobre --sync y --incremental, que sea esta: ambos usan el mismo state file y el mismo mecanismo de deteccion de cambios. La diferencia real es lo que ocurre cuando una pagina desaparece de Confluence. Suena pequeno, pero cambia por completo el significado del directorio de salida. La version corta La documentacion oficial resume la diferencia de forma bastante limpia: | Comportamiento | --sync | --incremental | | --------------------------------- | -------------------------- | -------------------------------------- | | State file | .convert-sync-state.json | .convert-sync-state.json | | Omite paginas sin cambios | Si | Si | | Reconversion de paginas cambiadas | Si | Si | | Si la pagina fuente se elimina | El archivo local se borra | El archivo local se conserva | | Etiqueta del resumen | Deleted | Removed from tracking | | Por defecto | No | Si | | Mejor ajuste | Espejos vivos, continuidad | Archivos, retencion, corpus crecientes | La documentacion tambien indica que --incremental es el comportamiento por defecto en la release documentada. No hace falta pasarlo de forma explicita salvo que quieras dejar la intencion clarisima en scripts y runbooks. Como funciona el state file Cuando ejecutas space convert con cualquiera de los dos modos, acs2md: 1. lee .convert-sync-state.json del directorio de salida 2. obtiene metadatos de las paginas del espacio 3. compara versiones de pagina con lo registrado anteriormente 4. omite paginas sin cambios y reconvierte las que cambiaron 5. reescribe enlaces internos si esa opcion esta activa 6. actualiza el state file con el nuevo estado Por eso las siguientes ejecuciones pueden ser mucho mas baratas que la primera. Cuando sync es la decision correcta Usa --sync cuando el directorio local deba comportarse como un espejo vivo: Es la opcion correcta cuando: - una copia de continuidad debe reflejar el estado actual del espacio fuente - un sistema aguas abajo espera que los archivos obsoletos desaparezcan - un publish hacia sitio estatico no debe conservar paginas que ya no existen arriba - un procedimiento de recuperacion depende de un espejo actualizado Si una pagina se elimina en Confluence, --sync borra el archivo Markdown correspondiente y limpia su entrada del state file. El resumen mostrara Deleted: N. Cuando incremental es la opcion mas segura Usa --incremental cuando la preservacion importe mas que el espejo exacto: Encaja mejor en: - exportaciones orientadas a archivo - retencion para cumplimiento y auditoria - conjuntos historicos que deben sobrevivir a borrados aguas arriba - corpus para RAG o busqueda que no deberian perder contenido ya exportado por accidente Si una pagina se elimina en Confluence, --incremental conserva el archivo Markdown local y solo retira la entrada de seguimiento. El resumen mostrara Removed from tracking: N. Una regla de decision util Hazte una sola pregunta antes de elegir modo: El directorio local debe representar el estado actual del espacio, o debe preservar documentacion aunque el origen cambie? - Estado actual del origen: elige --sync - Preservacion tras borrados: elige --incremental Esa es toda la decision. No hace falta complicarla mas. Errores comunes que conviene evitar La documentacion subraya varios detalles que merece la pena explicitar: - --sync y --incremental son mutuamente excluyentes - --conflict-resolution=versioned desactiva el comportamiento sync/incremental porque un directorio con timestamp no es una ubicacion estable para el state file - cambiar el directorio de salida entre ejecuciones reinicia en la practica el valor del seguimiento de estado - la reescritura de enlaces corre despues de una conversion correcta cuando esta activada Dicho de otra forma: las exportaciones con estado necesitan un directorio estable y un ciclo de vida claro. Ejemplos segun caso de uso | Caso de uso | Modo recomendado | | -------------------------------------------------------- | ---------------- | | Mantener un espejo documental en Git al dia | --sync | | Mantener una copia de continuidad para recuperacion | --sync | | Construir un archivo que nunca pierda documentos | --incremental | | Alimentar un corpus creciente para RAG | --incremental | | Publicar una fuente programada para sitio estatico | --sync | | Retener evidencia de auditoria tras un borrado en origen | --incremental | Ese mapeo es consistente entre la documentacion de producto y las recetas guiadas. La pregunta de cumplimiento que se esconde en la eleccion de modo --sync y --incremental parecen una decision operativa. Tambien son una decision de gestion de registros bajo la mayoria de los marcos modernos. - ISO/IEC 27001:2022 A.5.33 (proteccion de registros) te pide definir como se retienen, protegen y eliminan los registros. --incremental encaja con registros que deben sobrevivir a borrados aguas arriba. --sync es apropiado cuando la copia local es un espejo vivo, no un registro. - NIS 2 Articulo 21 y la guia de transposicion esperan que los operadores de servicios esenciales e importantes conserven evidencia de incidentes, configuraciones y decisiones durante el plazo que indique la autoridad nacional. Si la documentacion forma parte de esa evidencia, --incremental suele ser el modo correcto. - SOC 2 Common Criteria CC7.4 (respuesta a incidentes) asume que puedes reconstruir como estaba el sistema durante un incidente. Borrar archivos Markdown porque la pagina origen se quito de Confluence puede eliminar justo el artefacto que CC7.4 espera que conserves. - RGPD Articulo 5(1)(e) (limitacion del plazo de conservacion) apunta en sentido contrario. Los datos personales no deberian permanecer en una copia de continuidad mas alla de lo necesario para la finalidad lawful. Si una pagina de Confluence contenia datos personales y se elimino por ese motivo, --sync es el modo mas seguro para ese patrimonio. En resumen: el modo correcto depende de si el directorio funciona como espejo (donde los borrados deben propagarse) o como registro (donde los borrados deben preservarse como evidencia). Distintos espacios de la misma organizacion pueden necesitar modos distintos por esa misma razon. Recomendacion final Elige --sync cuando el borrado local sea una caracteristica deseable. Elige --incremental cuando la retencion local sea la caracteristica deseable. Ambos modos te dan refrescos solo sobre cambios gracias a .convert-sync-state.json. La unica pregunta importante es si las paginas eliminadas en Confluence deben desaparecer del disco o permanecer como evidencia exportada. Decide eso una vez, documentalo en el runbook y las siguientes ejecuciones seran mucho mas faciles de razonar.]]></content:encoded>
            <category>space-conversion</category>
            <category>acs2md</category>
            <category>sync</category>
            <category>incremental</category>
            <category>continuity</category>
            <category>archive</category>
            <category>retention</category>
            <category>iso-27001</category>
            <category>nis-2</category>
            <category>soc-2</category>
        </item>
    </channel>
</rss>