Jenseits von final-final: Manuskriptversionen, verbindliche Quellen und Project-Sicherungen

Um 23 Uhr erhält eine Autorin von ihrem Buchdesigner eine Nachricht: „Weshalb fehlt die freigegebene Änderung in Kapitel zwölf von Band zwei?“ Sie bereitet Band zwei für das erste Layout vor und arbeitet zugleich Korrekturen von Lesenden in eine Neuauflage von Band eins ein. Der Ordner enthält „author final“, „editor review“ und final-final; das synchronisierte Laufwerk hat eine Konfliktkopie hinzugefügt. Jeder Name klingt plausibel. Nichts zeigt, welches Werk, welche Version und welche Kapitel jetzt in die Produktion gehen sollen.

Der Designer findet den Fehler, bevor der alte Entwurf in Paginierung und Korrektur des Buches einfließt. Die Autorin erkennt, dass final-final drei voneinander unabhängige Aufgaben erfüllen sollte: das aktuell für die Veröffentlichung gewählte Manuskript bestimmen, den tatsächlichen Wortlaut eines früheren Zeitpunkts bewahren und nach einem Geräte- oder Bedienfehler das vollständige Project wiederherstellen. Ein Dateiname kann nicht alle drei Zuständigkeiten tragen.

Kennzeichnen Sie diese Übergabe eindeutig

Scroll verwendet einen gewöhnlichen lokalen Project-Ordner, den die Autorin oder der Autor auswählt. In einem Project lassen sich ein oder mehrere Werke registrieren. So behalten eine Neuauflage von Band eins und eine Erstauflage von Band zwei getrennte Grenzen, statt sich ein mehrdeutiges „aktuelles Manuskript der Reihe“ zu teilen.

Ein geänderter Serienfakt bedeutet nicht, dass alle drei Manuskripte aktualisiert wurden. Die Autorin entscheidet zuerst, ob eine Änderung die Reihe, ein bestimmtes Werk oder eine einzelne Manuskriptphase betrifft. Scroll überträgt Story-Daten nicht automatisch zwischen getrennten Projects und entscheidet nicht, dass eine frühere Ausgabe einen späteren Fakt übernehmen muss.

Die Autorin wählt das Werk für Band zwei, prüft dessen Manuskriptversionen und Quelle und hält die für die Veröffentlichung vorgesehene Version und Quelle als Veröffentlichungsversion fest. Nun kann sie dem Designer sagen: „Verwenden Sie diesen Kapitelsatz für die Erstauflage von Band zwei; die Überarbeitung von Band eins ist ein eigenes laufendes Werk.“ Statt aus Dateinamen zu raten, prüfen beide eine ausdrückliche Entscheidung.

Das ist kein Verwaltungsaufwand um seiner selbst willen. Korrekturen in Band eins und die Bearbeitung von Band zwei können gleichzeitig fortschreiten, ohne dass eines der Manuskripte seine Identität verliert. Sobald eine Entscheidung über mehrere Bücher feststeht, wendet die Autorin oder der Autor sie gemäß der eigenen Project-Konvention an.

Versionsnamen bewahren Entscheidungen; separate Dateikopien bewahren Inhalte

Die Manuskriptquelle bleibt das Markdown, das die schreibende Person öffnet, bearbeitet und speichert. Das Registrieren einer Manuskriptversion kopiert oder fixiert diese Dateien nicht und erzeugt keinen Verlauf nach Art von Git. Wenn sich der Quellordner weiter verändert, wird aus der Versionsbezeichnung kein neuer Snapshot. Prüfen Sie vor einer weiteren Übergabe Kapitelumfang, Reihenfolge und ungelöste Markierungen erneut.

Bedeutungsvolle redaktionelle Meilensteine brauchen deshalb tatsächliche Kopien: vor der Rückgabe durch das Lektorat, nach der Strukturüberarbeitung oder vor dem Korrekturlauf. Die Kopie bewahrt den Wortlaut. Der Versionsdatensatz erklärt, welche Rolle dieser Wortlaut im Werk gespielt hat.

Halten Sie neben einer wichtigen Kopie eine kurze Notiz fest: Werk, Prüfphase, Status der Faktenprüfung und weshalb eine spätere Quelle sie abgelöst hat. Das ist wichtig, wenn zwei Dateien gleichermaßen gültige Dokumente sind, aber nur eine die aktuelle Entscheidung darstellt. Das Änderungsdatum allein kann die Verbindlichkeit nicht bestimmen.

Eine Sicherung des vollständigen Projects schützt mehr als Kapitel

Eine Kopie des Manuskriptordners kann die Prosa bewahren, während Aufgaben, gespeicherte Story-Ansichten, Leinwände, Project-Einstellungen und Übergabedatensätze fehlen. Eine Sicherung des vollständigen Projects bewahrt nach dem Schließen von Scroll den gesamten Project-Ordner einschließlich versteckter Dateien und Ordner. Das unterstützte Verfahren ist in der aktuellen Dokumentation zu Datensicherheit und Wiederherstellung beschrieben.

Local-first bedeutet, dass die Autorin oder der Autor Speicherort und Strategie der Sicherung wählt. Eine vollständige Kopie des geschlossenen Projects kann auf einem anderen Laufwerk, einem externen Datenträger oder an einem vertrauenswürdigen Cloud-Sicherungsort liegen. Das bedeutet nicht, dass lokale Dateien nicht verloren gehen können. Auch eine erfolgreiche Synchronisierungsanzeige beweist nicht, dass der Dienst die Versionsbedeutung des Manuskripts versteht.

Führen Sie vor einer Strukturüberarbeitung, einem Gerätewechsel oder einer formalen Übergabe eine kleine Wiederherstellungsprüfung durch. Kopieren Sie die Sicherung an einen temporären Speicherort, öffnen Sie das Project und prüfen Sie das erste und das letzte Kapitel, Aufgaben der Autorin oder des Autors und die Werkangaben. Ziel ist nicht nur die Wiederherstellung des Textes, sondern die Fortsetzung der Arbeit mit ihrem aktuellen Kontext.

Verbinden Sie bei einer lang laufenden Reihe einige Wiederherstellungspunkte mit bedeutungsvollen Phasen: Strukturüberarbeitung abgeschlossen, an das Lektorat übergeben, bereit für Scribe. Das Risiko bestimmt die Häufigkeit. Wenige nachvollziehbare und geprüfte Wiederherstellungspunkte sind nützlicher als viele Kopien, an deren Zweck sich niemand erinnert.

Externe Lektorate und mehrere Geräte können weiterhin Konflikte erzeugen. Bewahren Sie beide Fassungen, bevor Sie sie manuell vergleichen. Eine Konfliktkopie ist eine tatsächliche Datei, über die entschieden werden muss. Ein neuerer Zeitstempel macht sie nicht verbindlich, und Scroll führt die kreativen Entscheidungen beider Fassungen nicht automatisch zusammen.

Die Buchproduktion benötigt weiterhin eine ausdrückliche Übergabe

Wenn das Manuskript stabil ist, übernimmt Scribe Erscheinungsstil, Paginierung, PDF, EPUB und weitere unterstützte Veröffentlichungsausgaben. Scroll hält Werk, Manuskriptversion und den vorgesehenen Quellordner fest. Die Autorin oder der Autor öffnet dasselbe Project in Scribe und prüft dort das erkannte Werk, die Veröffentlichungsversion, den Quellordner, die Kapitelzahl und die Kapitelreihenfolge.

Dies ist kein Upload und macht Scroll nicht zur Layout-Anwendung. Eine vorgelagerte Bereitschaftsprüfung beweist weder, dass Scribe die vorgesehene Quelle erkannt hat, noch dass dessen Seiten korrekt sind. Erst nachdem Quellordner, Kapitelzahl, Reihenfolge und Manuskriptversion in Scribe geprüft wurden, beginnt die Seitenarbeit.

Eine ausdrückliche Übergabe begrenzt den praktischen Schaden. Gerät ein alter Entwurf in die Produktion, können erneute Paginierung, wiederholte Korrekturläufe, verworfene Korrekturabzüge oder eine verzögerte Veröffentlichung folgen. Eine eindeutige Quelle verhindert nicht jeden Fehler. Sie verhindert aber, dass ein mehrdeutiger Dateiname einen einzelnen Fehler durch den gesamten Produktionsprozess trägt.

Nutzen Sie Fünf Anzeichen dafür, dass ein Manuskript für Scribe bereit ist für die vollständige Vorabprüfung und den Workflow für Scroll und Scribe für die umfassendere Arbeitsteilung. Wenn die Strukturüberarbeitung noch nicht abgeschlossen ist, beginnen Sie mit Ein Workflow für die Strukturüberarbeitung nach dem ersten Entwurf. Schreibende von Reihen können die Ansätze unter Project- und Versionswerkzeuge für Buchreihen vergleichen.

Wenn die Autorin oder der Autor beantworten kann: „Was ändere ich, welche Quelle ist jetzt maßgeblich und wo kann ich das Project wiederherstellen?“, wird final-final wieder zu einem gewöhnlichen Dateinamen statt zu einem Beleg für Verbindlichkeit. Kehren Sie zum Workflow für lange Texte in Scroll zurück, oder sehen Sie auf der Scroll-Produktseite, wie Scroll lokale Projects, Werke und Veröffentlichungsquellen organisiert.