互動文字冒險的結果文字顯示到一半中斷，該接著讀還是重新提交？
結果文字沒顯示完，不能據此判斷行動失敗。以寄送包裹的虛構案例，依確認已執行、確認未執行、執行狀態不明三種情況填寫恢復文案表，寫清楚補讀、重新提交與確認結果各自的前提。
開篇導讀
結果文字顯示到一半中斷，先說明可確認的行動狀態，再告訴玩家下一步會做什麼。確認行動已生效且原結果可補回，才寫「繼續閱讀」；確認未執行，才提供「重新提交」；執行情況不明，就先說明「結果待確認」。文字沒送達，不等於行動沒發生。
以下用寄送包裹示範一張可重複使用的恢復文案表。這是虛構教學案例，並非真實使用者經歷、實測結果或 DramaFork 產品功能。案例中的狀態紀錄、原文保留與查詢入口都是明確設定的前提，實際作品須分別實作。
先區分行動狀態與文字顯示範圍
玩家選擇「把包裹交給值班人員」，畫面顯示到「值班人員接過包裹，翻開登記簿……」便中斷。這段殘文容易讓人以為寄送已完成，但恢復提示不能只憑敘事語氣判斷狀態。
作者先核對兩件事：這次寄送是否已確認生效；這次結果文字顯示到哪裡。前者決定能否重做，後者決定從哪裡補讀。即使玩家只看到半句，行動也可能已完成；即使殘文寫了「接過」，也不能取代這次行動的確認依據。
本例設定：確認紀錄對應這次提交；「寄送完成」表示包裹已交出，相關行動結果已落實。若只能確認已收到請求，就不能寫成寄送成功。無法證明「已執行」或「未執行」時，一律進入待確認分支，不能憑等待時間猜測。
已顯示範圍也須如實填寫。知道最後一個完整句子，就記下該句；只知道顯示過部分內容，就寫「部分文字，中斷位置不明」。不知道中斷位置，仍可展示保留的完整結果，但不能承諾「恰好從中斷處接續」。
用五欄表規範每個恢復入口
把表格中的一列當作一份文案依據。先填狀態與可恢復內容，最後命名入口，避免先寫下「重試」，再讓所有異常共用它。
| 已知執行狀態 | 已顯示範圍 | 可恢復內容 | 入口措辭 | 不可承諾 |
|---|---|---|---|---|
| 確認已寄送，原結果完整保留 | 已知停在登記簿那句 | 同次寄送的剩餘原文 | 繼續閱讀寄送結果 | 重新寄送；再次完成交接 |
| 確認已寄送，原文未保留 | 部分文字，中斷位置不明 | 已確認的寄送狀態 | 查看已確認狀態 | 恢復原文；補齊所有細節 |
| 確認此次寄送未執行 | 曾顯示交接開頭 | 無本次已生效結果可補讀 | 重新提交寄送 | 寄送已完成；繼續閱讀結果 |
| 此次寄送是否執行仍不明 | 曾顯示部分回饋 | 僅有殘文，結果仍待核對 | 確認寄送結果 | 寄送成功；寄送失敗；可安全重做 |
最後一列的入口以確實能核對結果為前提。若作品沒有查詢或人工核對管道，就只能顯示「寄送結果待確認」，並說明暫時無法恢復，不能放一個實際會重新提交的「確認結果」按鈕。
表格寧可少承諾一些，也別把「已確認狀態」包裝成「完整劇情」。這會犧牲部分閱讀連貫性，卻能保住玩家對包裹去向的判斷。
確認已寄送時，讓補讀只承接同一次行動
第一個分支設定為：寄送已確認，完整結果仍保留，中斷位置也已知。恢復提示寫：「此次寄送已完成，結果文字未顯示完整。繼續閱讀會補上同一次寄送的剩餘文字，不會再次提交寄送。」入口為「繼續閱讀寄送結果」。
接著先放一個簡短標記「以下接續上次寄送結果」，再顯示原文：「登記簿上添了你的名字。值班人員把收件回執推到你面前，示意你收好。」這段內容屬於原先保留的結果，不是補讀時又發生一次登記。
不要改寫成「你再次把包裹遞過去，值班人員終於收下了」。「再次」與「終於」把顯示恢復寫成行動重做，還暗示前一次沒成功。即使只是想讓語句順暢，也會改變玩家對事件次數的理解。
若中斷位置不可靠但全文仍在，可改用「重看本次完整結果」，先說明會包含已經讀過的部分。重複閱讀比漏掉重要的一句更容易察覺，但須標明是重看。若原文已遺失，只剩寄送完成的確認依據，就寫：「此次寄送已完成，原結果文字暫時無法補回。」不能臨時編造收件回執的細節冒充原文。
未執行與狀態不明，分別提供不同的下一步
第二個分支設定為：此次寄送已確認未執行。即使殘文出現「接過包裹」，也須明確更正：「此次寄送未執行，剛才顯示的交接文字不代表行動已生效。你可以重新提交寄送。」入口為「重新提交寄送」。
重新提交表示再次發起行動，不保證下一次一定成功。若提交前須重新核對條件，應先進入核對步驟，不沿用殘文中的結局。只有取得新的確認，才能顯示對應結果；不能為了補齊句子，直接接上「登記完成」。
第三個分支設定為：無法確認此次寄送是否執行。提示寫：「寄送回饋中斷，目前無法確認此次行動是否生效。請先確認結果，避免重複寄送。」入口為「確認寄送結果」，且只用於核對原提交。
核對後若確認已完成，就轉至補讀或查看狀態；確認未執行，才開放重新提交；仍然不明，就保留「結果待確認」。不要寫「查不到，所以寄送失敗」，因為缺乏確認與確認未執行，是兩種不同依據。
狀態不明會讓流程暫時停住，這是它的代價。作者可解釋目前能做什麼，但不能保證「稍後一定恢復」，也不能用「再點一次即可繼續」掩蓋可能重複行動的問題。
交稿前，逐一檢查入口的實際作用
檢查時把提示、入口及入口後的第一段放在一起讀。玩家應能回答：包裹是否已確認交出；這個入口會顯示文字、核對結果，還是重新發起寄送。若須猜測「繼續」「恢復」「重試」指什麼，就補上對象與動作。
再逐項撤掉案例中的條件：原文不在，是否仍承諾完整補讀；中斷位置不明，是否仍保證接續時不會重複；執行情況不明，是否仍出現成功語氣；核對仍無結論，是否誤開放重做。這是文案推演，並非已完成的產品測試。
尤其須核對「不會再次提交」這類保證是否符合入口行為。若入口實際包含重新執行，單靠換一個按鈕名稱也不能把它變成補讀，須調整行為或重寫提示。恢復過程中再次中斷，也應依新的可確認狀態重新選列，不能預設前一步已完成。
本表適用於單次行動的結果文字傳送中斷。劇情明確拒絕寄送、連續指令僅部分完成，或寄送同時觸發多個尚未核清的後果，都須另列狀態，不能硬塞進「成功或失敗」。交稿時保留表格、三種提示及各自成立的前提，讓後續改稿能核對每句承諾的依據。
