MacBookで小説原稿からEPUBまで進めるなら、入力原稿、編集場所、生成物、検査用複製の受け渡し先を先に固定します。そのうえで、識別できる入力を同じ四地点へ2回通します。Pass 1とPass 2の入力、生成物、検査対象、結果を別行で追えば、2回目に古いEPUBを誤って検査した事故を見つけられます。
この記事では、HarborNovelに01_inbox、02_workspace、03_output、04_inspectionを用意します。Pass 1はharbor-source-r01からharbor-book-build01.epub、Pass 2は変更印を持つharbor-source-r02からharbor-book-build02.epubまでを往復します。候補A/Bの優劣や設定保持を比べるSTUDIO-030、欠陥種類ごとの責任区画を作るSTUDIO-233とは分け、ここではMacBook内の受け渡しが2回とも正しいファイルで閉じたかを判定します。
四地点とTwo-Pass票を先に固定する
一般的なファイル制作では、編集前の受領物と編集後の成果物を同じ場所へ置くと、どちらを送るべきか分からなくなります。そこで、アプリを開く前に役割の異なる四地点を作ります。
01_inbox：受け取った原稿を置く入口02_workspace：編集アプリが使う作業場所03_output：生成したEPUBを受け取る出口04_inspection：検査へ渡す複製と結果を置く場所
フォルダ名は別の名前でも構いません。重要なのは、入口へ生成物を戻さないこと、作業場所を納品場所にしないこと、検査用の複製を次の編集元にしないことです。
受け渡し票には、Pass番号、入力ID、期待印、作業場所、生成物ID、検査対象ID、検査結果、前Passとの差の八欄を作ります。合否表ではなく、何がどこを通ったかを追う票です。アプリ機能の比較点や設定再現の点数は入れません。
2回分の入力と期待差を宣言する
01_inboxでは、Pass 1の二章原稿をharbor-source-r01として登録し、ファイル名、章数、受領日時を記録します。期待印は「第二章冒頭に帰港確認文なし」です。受領状態を変えず、作業用複製だけを次へ渡します。
Pass 1の結果が戻った後、承認済みの変更を作業元へ反映した入力をharbor-source-r02として01_inboxへ登録します。期待印は「第二章冒頭に帰港確認文あり」です。変更内容と入力IDの両方が違うため、Pass 2の検査でr01やbuild01を誤って開けば差分欄で検出できます。
これは一字改稿を候補A/Bへ配る比較ではありません。使用する作業経路は一つです。変更印は受け渡し識別用であり、アプリの設定保持や品質優劣を採点しません。正本へ不要な確認文を混ぜず、実案件で承認された改稿か試験用複製を使います。
Pass 1でr01を四地点へ通す
Pass 1では、01_inboxのharbor-source-r01から作業用複製を02_workspaceへ渡します。受け渡し票にプロジェクト名と入力IDを書き、そこから生成したEPUBだけを03_outputへ受け取ってharbor-book-build01.epubと名付けます。
次に、build01の複製だけを04_inspectionへ渡します。検査票の対象IDがbuild01であることを確認し、期待印「帰港確認文なし」と一致するか、実施した構造確認の結果とともに戻します。結果が受け渡し票のPass 1行へ戻った時点で、1回目の往復を閉じます。
一時ファイルや自動保存ファイルを03_outputへ混ぜません。検査用複製を次の編集元にも使いません。Pass 1の四地点はr01 → workspace → build01 → build01の検査複製 → 結果という一つの鎖です。
Pass 2でr02を同じ四地点へ通す
Pass 2では、変更印を持つharbor-source-r02を01_inboxから02_workspaceへ渡します。作業場所で参照中の入力IDがr02であることを確認してから生成し、03_outputでharbor-book-build02.epubという新しいIDを発行します。build01を上書きしたり、build01へ新しいラベルだけを付けたりしません。
04_inspectionへはbuild02の複製だけを渡し、検査票の対象ID、作成日時、元入力IDがすべてPass 2行と一致するか確認します。期待印「第二章冒頭に帰港確認文あり」をbuild02で確認し、構造確認の結果とともにPass 2行へ戻します。
生成に失敗したのに古いEPUBが残っている場合、検査対象IDがbuild01ならPass 2は未完了です。古い結果を複製して行を閉じず、「build02未生成」または「期待印未確認」と記録します。これが2回目を独立した通過にする境界です。
2回の入力・判定・差分を照合する
2行が戻ったら、少なくとも四つの差を横に並べます。入力はr01からr02、期待印は「なし」から「あり」、生成物はbuild01からbuild02、検査対象もbuild01からbuild02へ変わっている必要があります。検査結果には、各対象で観測した期待印と実施した確認だけを書きます。
Pass 2の入力がr02なのに検査対象がbuild01なら、旧生成物混入です。対象がbuild02でも期待印がないなら、入力の取り違え、保存漏れ、生成漏れのどこかに境界問題があります。この時点では責任者を推定せず、差分の不一致をそのまま記録します。
本記事の判定は経路の追跡可能性です。表紙、EPUBナビゲーション文書、パッケージ文書、spineを網羅採点するのでも、STUDIO-233のように欠陥を責任区画へ割り当てるのでもありません。入力IDと検査対象IDが対応し、期待差を観測できたかに限定します。
Rune Studioで確認済みなのはPass 1相当だけ
2026年8月11日の専用Macワークスペースでは、表紙なし二章EPUB cover-free-01.epubを一回生成し、valid=true、EPUBナビゲーション文書、パッケージ書誌、spine順を確認しました。補助的なNCXも存在しました。これは、同じMac上の作業場所から一つの生成物を構造検査へ渡したPass 1相当のStage 4証拠です。
変更印を持つ2番目の入力から別の生成物を作り、Pass 2として検査へ渡す操作はRune Studioで未実施です。表紙付き生成物、設定保持、外部リーダー、ストア受理、固定レイアウトも確認済み範囲へ含めません。前節のTwo-Pass Testは次に実施する一般手順であり、製品が2回とも合格済みという主張ではありません。
Rune Studioを作業場所に使う場合も、入口・作業場所・出口・検査先の四地点と2行の受け渡し票を残します。一つのアプリが複数工程を担っても、Passごとのファイル境界は消しません。
四地点を2回通して往復を閉じる
MacBookのTwo-Pass Testでは、Pass 1のr01を四地点へ通してbuild01の結果を戻し、Pass 2の変更印付きr02を同じ四地点へ通してbuild02の結果を戻します。2行の入力、生成物、検査対象、期待差が対応して初めて、2回の往復を閉じます。
まず四つの場所を作り、実案件で承認された小さな差を持つ2入力へ別IDを付けてください。各Passの出力を別IDで受け、検査用複製と結果を同じ行へ戻します。Pass 2にbuild01が現れたら止める。この明確な2回の通過により、候補比較や責任地図へ寄らず、MacBook内の古い生成物取り違えを検出できます。
