After an EPUB package alone has been edited, do not begin another export immediately. Design a lineage plan that identifies which manuscript and settings revisions a later recovery should start from. This article does not produce a recovered EPUB. It produces an explainable plan containing the connected pre-incident line, the package-only orphan branch, and the intended future branch, using source, settings, and artifact IDs.
The available Rune Studio evidence stops at Stage 1 documentation and Stage 2 code. It does not establish the current screen or a completed operation from input through regenerated output. The article therefore stays within recovery planning and lineage design for a later isolated test.
Inventory incident evidence before moving it
A package-only edit changes a file inside a generated EPUB without recording the same change in manuscript source or publishing settings. Starting another export can erase that edit or make the authoritative version impossible to explain.
The first section of the plan inventories four existing items: the manuscript, settings record, pre-fix EPUB, and post-fix EPUB. It reserves fields for acquisition time, original location, current identifier, and a no-overwrite treatment. At this stage, the plan identifies preservation targets without moving or modifying them.
The example uses source-v03, settings-v02, book-build17, and book-build17-packagefix. They are illustrative lineage IDs, not Rune Studio outputs or measured operation results.
Draw the package difference as an orphan branch
Next, define the fields that a later comparison of the pre-fix and post-fix artifacts must fill. If a chapter-two sentence exists only in the edited package while source-v03 retains the earlier sentence, the plan draws that difference as an orphan branch.
The planned record reads “parent=book-build17,” “orphan=book-build17-packagefix,” “difference=target sentence in chapter two,” and “input status=not reflected.” Leave approval and rationale blank until a responsible person decides them. The plan must not infer that the package change is correct.
Do not add comprehensive cover, navigation, package-metadata, or spine scoring. STUDIO-122 owns static artifact acceptance, and STUDIO-233 owns defect-type responsibility mapping. This plan follows only the temporal parent-child relationship of one incident.
Select the last explainable pair as a recovery-point candidate
The newest timestamp is not automatically the recovery point. Choose as a candidate the last pair for which existing evidence can explain, “this manuscript plus these settings produced this artifact.” The example places source-v03 + settings-v02 → book-build17 on the pre-incident line.
Do not select a manuscript without a corresponding generation record or settings whose origin is unknown. Mark an unknown relationship unknown and list it as an investigation item. Drawing this candidate line is a planning result, not proof from a completed recovery operation.
Design the future owner and planned IDs
For an approved orphaned change, specify which editable input would own it. A body-text difference points to a manuscript candidate; a publishing-condition difference points to a settings candidate. If ownership cannot be decided, mark it pending and do not advance it into the export plan.
For a hypothetical chapter-two source change, use planned-source-v04, retain settings-v02, and reserve planned-book-recovery01:
planned-source-v04 + settings-v02 → planned-book-recovery01
The planned- prefix means no operation has occurred. This article does not apply the change or generate the artifact. Keep book-build17-packagefix as incident evidence outside the intended authoritative line.
Write the future Stage 4 acceptance conditions
Add four acceptance conditions for a later isolated recovery run:
- The approved difference was applied only to the planned manuscript or settings revision
- The actual input IDs and artifact ID were recorded
- The generated artifact contains the approved difference at the affected location
- The generation record points to the actual manuscript and settings revisions
Only a record containing the command, inputs, exit status, artifact, time, and development build can establish a Stage 4 recovery result. That record does not exist here, so planned-book-recovery01 is not a successful artifact.
Separate the EPUB 3 standard from Rune Studio implementation
EPUB 3 is a W3C distribution and interchange format for digital publications. It is not a Rune Studio-specific standard. Rune Studio documentation that mentions EPUB 3 output and current code related to EPUB 3 generation are recorded separately as product support for an existing standard.
Rune Studio’s workspace, manuscript editing, preview, and metadata, navigation, and cover-setting scope are product-specific. Documentation evidence remains Stage 1, while static code evidence remains Stage 2. Neither establishes the current interface, successful operation, automatic detection of package-only edits, or complete restoration of an arbitrary EPUB.
Close when the recovery plan is explainable
For a package-only edit incident, inventory the four evidence items, draw the internal change as an orphan branch, select the last explainable source-settings-artifact relationship as a candidate, and record the intended owner, planned IDs, and Stage 4 acceptance conditions.
The reader leaves with a recovery plan that explains what must be tested next, not with a recovered or successfully regenerated artifact. Actual source modification and artifact verification remain incomplete until a separate Stage 4 operation records the evidence.
