Más allá de final-final: versiones del manuscrito, fuentes de referencia y copias de seguridad del Project

A las once de la noche, una autora de una trilogía recibe un mensaje del diseñador de su libro: «¿Por qué falta el cambio aprobado en el capítulo doce del segundo libro?». Está preparando el segundo libro para su primera maquetación mientras incorpora erratas comunicadas por los lectores a una nueva edición del primero. La carpeta contiene «final de la autora», «revisión del editor» y final-final; la unidad sincronizada ha añadido una copia en conflicto. Todos los nombres parecen plausibles. Ninguno indica qué Obra, versión y capítulos deben entrar ahora en producción.

El diseñador detecta el error antes de que el borrador antiguo llegue a la paginación y la corrección de pruebas. La autora comprende que se esperaba que final-final cumpliera tres funciones sin relación entre sí: identificar el manuscrito elegido para la publicación actual, conservar las palabras exactas de un momento anterior y permitir recuperar todo el Project tras un fallo del dispositivo o un error humano. Un nombre de archivo no puede asumir las tres responsabilidades.

Identifique con precisión qué entra en producción

Scroll utiliza una carpeta local corriente que el autor elige para el Project. Un mismo Project puede registrar una o varias Obras, de modo que la nueva edición del primer libro y la primera edición del segundo conserven límites separados en lugar de compartir un ambiguo «manuscrito actual de la serie».

Cambiar un hecho de la serie no significa que los tres manuscritos estén actualizados. El autor decide primero si el cambio pertenece a la serie, a una Obra o a una etapa del manuscrito. Scroll no propaga automáticamente datos de Story entre Projects separados ni decide que una edición anterior deba adoptar un hecho posterior.

La autora selecciona la Obra correspondiente al segundo libro, revisa sus versiones del manuscrito y la fuente asociada, y crea una versión de publicación con la versión del manuscrito y la fuente destinadas a la publicación. Ya puede decir al diseñador: «Utilice este conjunto de capítulos para la primera edición del segundo libro; la revisión del primero es otra Obra en curso». La conversación pasa de adivinar a comprobar una decisión explícita.

No se trata de añadir tareas administrativas porque sí. Esta distinción permite corregir las erratas del primer libro y editar el segundo al mismo tiempo sin que ninguno de los manuscritos pierda su identidad. Cuando una decisión que afecta a varios libros se estabiliza, el autor la aplica conforme a la convención de su Project.

Los nombres de versión conservan decisiones; las copias reales conservan el contenido

La fuente del manuscrito sigue siendo el conjunto de archivos Markdown que el autor abre, edita y guarda. Registrar una versión del manuscrito no copia ni inmoviliza esos archivos, ni crea un historial como el de Git. Si la fuente sigue cambiando, la etiqueta de versión no se convierte por ello en una instantánea. Antes de otro traspaso a producción, vuelva a comprobar el alcance y el orden de los capítulos, además de los marcadores pendientes.

Por tanto, los hitos editoriales importantes necesitan copias reales: antes de recibir las observaciones del editor, después de una revisión estructural o antes de corregir pruebas. La copia conserva las palabras. El registro de versión explica qué función desempeñaron esas palabras dentro de la Obra.

Junto a cada copia significativa, conserve una nota breve que indique la Obra, la etapa de revisión, el estado de la revisión de hechos y por qué una fuente posterior la sustituyó. Esto importa cuando dos archivos son documentos válidos, pero solo uno representa la decisión actual. La fecha de modificación no basta para determinar cuál es la fuente de referencia.

Una copia de seguridad de todo el Project protege más que los capítulos

Una copia del directorio del manuscrito puede conservar la prosa y omitir las tareas, las vistas guardadas de Story, los lienzos, los ajustes del Project y los registros de preparación para publicación. Para hacer una copia de seguridad de todo el Project, cierre Scroll y copie la carpeta completa, incluidos los archivos y las carpetas ocultos. Siga la documentación actual sobre seguridad y recuperación de datos para aplicar el procedimiento compatible.

El modelo local-first significa que el autor elige la ubicación y la estrategia de las copias de seguridad. Una copia completa del Project cerrado puede guardarse en otro disco, un dispositivo externo o un servicio fiable de copias de seguridad en la nube. Esto no significa que los archivos locales no puedan perderse, y el hecho de que la sincronización se haya completado correctamente no demuestra que el servicio entienda el significado de las versiones del manuscrito.

Antes de una revisión estructural, un cambio de dispositivo o un traspaso formal, haga una breve prueba de restauración. Copie el contenido de la copia de seguridad a una ubicación temporal, abra el Project y compruebe el primer y el último capítulo, las tareas del autor y la información de la Obra. El objetivo no es solo recuperar el texto, sino reanudar el trabajo con su contexto actual.

Para una serie de larga duración, vincule algunos puntos de recuperación a etapas significativas: revisión estructural terminada, manuscrito enviado al editor o preparación para entrar en Scribe. El riesgo determina la frecuencia. Un número reducido de puntos de recuperación comprensibles y probados resulta más útil que muchas copias cuyo propósito nadie recuerda.

Los editores externos y el trabajo en varios dispositivos todavía pueden crear conflictos. Conserve ambas versiones antes de compararlas manualmente. Una copia en conflicto es un archivo real que exige una decisión; una fecha de modificación más reciente no la convierte en la fuente de referencia, y Scroll no concilia automáticamente las decisiones creativas contenidas en ambas versiones.

La producción del libro todavía exige un traspaso explícito

Cuando el manuscrito esté estable, Scribe se encarga del Estilo de apariencia, la paginación, el PDF, el EPUB y otros resultados de publicación compatibles. Scroll registra la Obra, la versión del manuscrito y la fuente previstas. El autor abre el mismo Project en Scribe y comprueba qué Obra y qué versión de publicación reconoce, además de la Carpeta fuente, el número de capítulos y su orden.

Este flujo no sube archivos ni convierte Scroll en una aplicación de maquetación. Que la entrega figure como preparada en Scroll no demuestra que Scribe haya reconocido la fuente prevista ni que las páginas sean correctas. Solo después de comprobar en Scribe la Carpeta fuente, el número y el orden de los capítulos y la versión del manuscrito puede el autor empezar a trabajar en las páginas.

Un traspaso explícito reduce el impacto práctico de un error. Si un borrador antiguo entra en producción, puede obligar a repetir la paginación y la corrección de pruebas, descartar pruebas ya preparadas o retrasar el lanzamiento. Una fuente clara no elimina todos los errores, pero evita que un nombre de archivo ambiguo propague uno por todo el proceso de producción.

Consulte cinco señales de que un manuscrito está listo para Scribe para realizar la comprobación previa completa y el flujo de Scroll a Scribe para conocer el reparto de responsabilidades. Si la revisión estructural todavía no ha terminado, empiece por un flujo de revisión estructural después del primer borrador. Quienes escriben series pueden comparar distintos enfoques en herramientas de Project y versiones para series de libros.

Cuando el autor puede responder «¿qué estoy cambiando, qué fuente cuenta ahora y desde dónde puedo recuperar el Project?», final-final vuelve a ser un nombre de archivo corriente, no una prueba de autoridad. Regrese al flujo de escritura de largo aliento de Scroll o consulte cómo organiza Scroll los Projects locales, las Obras y las fuentes de publicación en la página de producto de Scroll.