生成完了は三つの状態を順番に確定して決める
画像入りEPUBの生成完了は、画像台帳を作ったことでも、.epubファイルが現れたことでもありません。planで入力を受理できた状態、exportで検査対象の生成物を固定できた状態、inspectでローカル構造を確認できた状態へ順番に進み、最後の状態まで到達したときに判断します。途中で失敗したら、先へ進まず、その関門が担当する設定へ戻ります。
今回の専用標本は二章、本文画像3枚、表紙1枚です。記事固有のStage 4では、三つの関門を通過し、最終的に画像4件、欠落0件、valid trueを確認しました。ここで重要なのは「4枚を数えた」という作り方ではなく、各関門が何を確定し、何をまだ確定しないかを混ぜないことです。
planでは入力が揃った状態だけを確定する
最初の関門はplanです。専用コピーで原稿を選択して計画を作り、fileCount 2、chapterCount 2、valid trueを確認しました。この時点で確定できるのは、意図した二章が出力対象として認識されたことです。本文画像3枚や表紙1枚が最終パッケージへ入ったとは、まだ判断しません。
fileCountやchapterCountが2でなければ、戻り先は原稿選択です。ここで画像設定や生成後のEPUBを触っても、入力対象のずれは直りません。planの合格条件を「二章を受理」に限定すると、入力ミスを次の関門へ持ち越さずに済みます。
exportでは検査する生成物を一つに固定する
次の関門はexportです。横書き、version 1.0で生成し、成果物はstudio-382-260831.120000.epub、6,472 bytes、SHA-256はa753で始まる値でした。この名前、容量、ハッシュは、次に調べるファイルを取り違えないための識別情報です。
exportが成功しても、画像の収録や読む順序までは確定しません。成果物が作られない、保存先が違う、想定した版ではない場合は、出力設定と保存先へ戻ります。ファイルが存在することを最終合格へ読み替えず、「検査対象を固定できた」という中間状態で止めます。
inspectで初めてローカル構造の完了を判定する
最後の関門はinspectです。専用標本ではentryCount 15、spineItemCount 6でした。spineはcover、title、nav、p001、p002、colophonの順で、nav.xhtmlとNCXはいずれも存在し、章項目は各2件でした。画像は4件、missingは0件、issuesは空、構造判定はvalid trueです。
この結果により、二章がp001とp002として読む順番に入り、本文画像3枚と表紙1枚に対応する4資源が登録され、検査上の欠落が報告されなかった状態まで確定できます。ここで初めて「この専用標本はローカル構造上の生成完了」と判断します。
失敗した関門ごとに戻り先を変える
三つの関門は、同じ確認を言い換えたものではありません。戻り先は次のように分けます。
planで二章にならない：原稿選択と章の分割へ戻るexportで成果物を固定できない：出力設定、ファイル名、保存先へ戻るinspectで本文画像が不足する：章内の画像参照と元画像へ戻るinspectで表紙だけ不足する：表紙設定へ戻るinspectでp001、p002の順や章項目数が違う：章順と目次対象へ戻る
この停止規則なら、最終結果が不一致だったときに、すべてを最初から作り直す必要はありません。どの状態遷移で止まったかが、そのまま修正範囲になります。
valid trueの後にも視覚確認と外部確認が残る
今回のvalid trueは、ローカルに生成したEPUBの構造、読む順序、ナビゲーション、画像登録、欠落一覧に対する結果です。画像の解像感、トリミング、色、見開きでの印象は目視していません。KDPなど外部ストアの受理、実機やすべての閲覧アプリでの表示も未確認です。
したがって、inspectを通過した後は、目的の閲覧環境で見た目を確認します。外部サービスで拒否された場合は、そのサービスの診断結果を別の入口にします。ローカルのmissing 0件を、全環境での表示保証へ広げてはいけません。
Rune Studioの公開機能と今回の状態遷移を分ける
Rune Studioの公開機能には、Markdown原稿からEPUB 3形式を出力し、nav.xhtml、NCX、content.opfのmanifestとspineを構成する処理があります。画像はEPUB内へ取り込まれ、選択した表紙は表紙用資源として登録されます。
今回確認したのは、専用コピーに対する明示的なCLI操作と、そのplan、export、inspectの結果です。Finderやクラウドストレージ上の変更の自動追跡、画像の見た目、ストア審査への適合は証拠に含まれません。公開機能、記事固有の実測、外部確認を一つの成功条件へまとめないでください。
結論：最後の関門を通過するまで生成完了にしない
この画像入りEPUBでは、planで二章の入力を受理し、exportで検査対象を固定し、inspectで画像4件、missing 0件、p001・p002の順、valid trueを確認しました。三つの状態が順番に確定したため、この専用標本はローカル構造上の生成完了です。
中心となる判断は、入力表と生成物を一度照合することではありません。各関門で未確定事項を残したまま先へ進まず、失敗した関門の担当範囲へ戻ることです。.epubができた時点ではなく、最後のinspect状態を受理した時点を完了にしてください。
